On medium and large scale projects, requirements management can become a difficult overhead. Teams that rely on spreadsheet and word-processing software to create and manage requirements documents often find it difficult to maintain the traceability and inter-dependencies between requirements. We all know the value of tracing, tracking and maintaining our requirements documents, but until now… [Read more…]
It’s great to learn new models. I LOVE models. I like to think about how they can be applied, and I get excited about both the predictive ability of models and the capacity for goodness that exists when a model is well executed. But I’ve learned that the reality is that you will never be… [Read more…]
As experienced change practitioners, I’m sure we’ve all worked on projects that have been difficult. The unfortunate truth is that some projects gain so much momentum, they become “too big to fail”. These projects steamroll their way through organizations, and have a tendency to displace anyone that dares to challenge them. Sometimes when working closely… [Read more…]
Several years ago I shared a series of articles in the Rational Edge for IBM that showcased real life applications of use cases and incremental development. Two of those articles focused on replacing a legacy unemployment insurance system. The entire article provides a much more thorough introduction from that example – so take a quick… [Read more…]
The whiteboard. The dry eraser. The multi-color pens. The overbearing meeting participant. Those four things often come together when thinking of brainstorming. It’s a technique among multiple management nexus disciplines and at the heart of agile, business analysis and project management. It can produce great results from a team. The Business Analysis Body of Knowledge… [Read more…]
The last principle of the Agile Manifesto provides for learning and adjustment by the team. This adjustment allows for continuous process improvement. Teams don’t allow themselves to become stagnant or stale – they change and become better. The manifesto doesn’t proscribe how often and allows some leeway. The definition of “at regular intervals” provides sufficient… [Read more…]
Project teams are complex and it’s essential that the team works together productively to achieve the end goal. Every so often, there will be a ‘project maverick’ that upsets the balance. Perhaps they ignore the plan, or escalate an issue straight to the CEO. Mavericks are often seen as a Project Managers worst nightmare, as… [Read more…]
The tenth principle of the Agile manifesto may be my favorite one – simplicity, the art of maximizing the amount of work NOT done. Too often methodologies, frameworks and process improvements get mired down in heavy process and documentation. It’s a balancing act. It’s important to be neither too much, nor too little – just… [Read more…]
The ninth principle of agile brings in important aspects of enterprise architecture and system design. Technical excellence is a board term. it can be applied to hardware, software, network infrastructure, process management, project management, programming, release management, etc. I also think of enterprise architecture I hear technical excellence. While Agile is change driven, that does… [Read more…]
Sprint or marathon? 100 meters, 5k or 26.2? Slow endurance or high intensity interval workout (HIIT)? Anaerobic or aerobic? Rare combination of talent like Michael Johnson (pictured) who excelled at the 200 and 400 meters? If Agile were a workout it would seem to fit in the sprint, 100 meter, high intensity, anaerobic side of… [Read more…]
The seventh principle of the Agile Manifesto is the simplest and shortest one. Working software is the primary measure of progress. That simplicity belies a profound philosophy and modus operandi That is the outcome trumps the process. This philosophy grates and goes against the grain of conventional wisdom. Have a problem, add process.… [Read more…]
Face to face interaction provides for the most effective form of communication. The sixth Agile Manifesto principle advocates face-to-face conversation. A sticking point for adopting Agile is the dominance of virtual teams within an organization and among different organizations (in a vendor – customer relationship or within a supply chain for example). Bringing virtual… [Read more…]
Is it a radical concept, motivate, support and trust people? No. Not really. The Agile principle of building projects around motivated individuals is clearly a Theory Z , Y or Herzberg management approach — people want to achieve and when they do, advance that performance to even higher levels. It doesn’t fit well with the… [Read more…]
Unleashing your developer geeks on unsuspecting business people was quite risky in the 1990′s. Why those geeks may be a bit rough, un-kept and may spill the beans (truth). They clearly have not transformed in “McDreamy” yet (Patrick Dempsey). They’re still commuting to work on their lawn mower. Seems a little silly now. The prevailing… [Read more…]
Steve McConnell (Borland, Independent, then Microsoft) and Philippe Kahn (Borland founder) are two notable software engineers from the late 1980′s to present day. They introduced the concept of a daily build and smoke test in the late 80′s while at Borland. Its ability to roll out cutting edge development tools (Turbo Pascal first, Paradox second)… [Read more…]
Sara Wilson from the Fresh Air Fund reached out to me via email to see if I would share a little bit on the CoachDaveK blog. I checked it out. It’s a great concept. So am adding it to our TAPUniversity blog as well. The Fresh Air Fund provides support to New York City kids… [Read more…]
Re·quire·ment n. 1. Something that is required; a necessity. 2. Something obligatory; a prerequisite.¹ Among the twelve principles of Agile, that one that evokes a good amount of debate is changing requirements, even late in development. This contrasts from plan driven approaches to development that “freeze requirements” and lock those in through development and deployment. … [Read more…]
The four values of the Agile Manifesto (Individuals, Customer, Working Software and Change) are further elaborated in twelve principles. The first principle is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “ The first line provides the goal – satisfy the customer. That customer focus brings Agile… [Read more…]
May 16, 2011 by Adrian Reed (UKAdrianReed)
0