What is Agility, and Why Should You Care?
In one organization, an agile team discovered two weeks into a 5-month project that the work they had planned out would be wasted effort. Why? In collaborating with their customer they determined that working on something else could actually provide 80% of the project's value. Their plan was irrelevant to delivering that value. The team recommended to management that the existing plan be discarded. Management accepted and the team halted, replanned and ran a single four-week iteration, in which they delivered a working system that provided the expected 80% value. The remaining 20% of the project's value was deemed insufficient to justify the cost of the team, but they had wasted only two weeks on the original, now-obsolete plan, and could quickly move on to more valuable projects. Management and customers were ecstatic, and team members were happy with the results: unexpectedly, they had make a much larger contribution to the bottom line of their organization than originally planned.
Another organization's very first Agile pilot project was able to deliver working software in only two weeks. This project had been stalled for two and a half years due to an inability to finalize requirements (a condition known as "analysis paralysis"). The customer for the project loved the initial, albeit imperfect, results. Several stakeholders attended the team's demo of the working software, and valuable feedback was gathered for a new version with more functionality, to be delivered in another week. The development team was proud of their accomplishment, and thrilled with the real feedback they received. Every week the team delivered a working version of the system with more and more functionality, and with adaptations to the previously built functionality to make it better. The customer said he liked the process so much that he would never work on a non-Agile project again, if he had his way.The Benefits of Agile
The benefits of an Agile approach for the business person or end user of software systems are clear: Agile methods allow teams to build higher-quality systems, with faster return on investment. Customers can learn as they build instead of having to "get it all right" at the start. The short, built-in feedback cycle rapidly provides features that satisfy customers' real needs. Agile methods also provide more options for managing change and risk than traditional project management techniques. Furthermore, they allow teams to show off their creativity and problem-solving abilities, in ways that the organization - customers, users, other departments - can actually see, value and use.What's the Down Side?
Agile methods are hard to do right! There is no simple checklist guaranteeing success. Agile adoption takes high levels of discipline, tolerance for failure, trust, truthfulness, visibility, sincerity, patience, striving for excellence, and just plain hard work. In some workplaces, the fruit of all this effort and good intention would be rapidly dissipated by chaos or bureaucracy in the organization. But Agile methods channel this effort into a learning cycle that actually makes a difference incrementally over time.So, What is Agile?
Agile is an umbrella term that encompasses a spectrum of methodologies, ranging from purely management-focused to purely technically-focused. Some well-known examples include Extreme Programming, or XP, Scrum, Dynamic Systems Development Method, Feature-Driven Development, and Lean Software Development. There are others as well, often the result of an organization adapting one or two well-known agile methods to their own circumstances.
XP is infamous for its unusual "pair programming" practice, requiring that all production code be written by two people sitting at a single workstation. However XP has also popularized the use of the XUnit testing frameworks, including JUnit, NUnit, and HTMLUnit, all of which are used in the Agile practice called test-driven development (TDD). This practice is recognized as a key tool for creating software with excellent design quality and extremely low defect rates.
Several agile methods including Scrum and XP feature a very short iterative cycle whereby working software is delivered and then plans are adapted based on feedback from stakeholders. This adaptive planning gives the customer/user of the software two huge advantages compared to a traditional phased development lifecycle: first, the customer can request adjustments to the actual working software based on what they learn as the project progresses, and second, the customer has the option at the end of each iteration to actually use the software in its current state, and start reaping its benefits. Since these iterations are never longer than 30 days in length, any mistakes made along the way are detected and mitigated quickly instead of provoking a crisis near the end of months or years of development.How Agile Must We Be?
There are many other agile practices ranging from continuous integration, task boards and user stories to financial modeling and appropriate metrics. Each agile method defines its own clear set of practices and rules as a starting point. However, choosing a specific method to start with is not the critical decision. Rather, the key success factor is the open and honest communication that supports the learning process. Once a team gets used to regularly and transparently discussing their work, they will see that each practice has its own place, its own benefits and challenges – and each can be implemented in response to a real need, not according to some cookbook plan. Agility resides in the team's ability to modify its own working process, always with a view to providing more value to the enterprise while reducing waste. In this way, the Agile enterprise continues delivering real value in the face of uncertainty and even adversity.Further Reading
Agile Software Development is based on values and principles, rather than lists and prescriptions. The following web pages lay out the foundations upon which the this movement has grown:
Agile Project Management Declaration of Interdependence
Agile Work Axioms
About the Author
Mishkin Berteig is an agile methods coach and trainer based in Toronto. Mr. Berteig has extensive experience coaching teams and organizations in adopting Extreme Programming, Lean Software Development and the Scrum methodology and is developing an agile method to apply to non-software environments. He writes about the human and organizational aspects of agile methods on Agile Advice.
What about contracts and multi-party coordination?
Re: What about contracts and multi-party coordination?
- avoid long approval processes that require chains of management in separate organizations
- put people in the same room together even if it means flying people around the world (that's inexpensive compared to the cost of mistakes due to mis-communication)
- use the "Scrum-of-Scrums" status reporting method where representatives of each team involved regularly share status
These techniques are not easy. They often take considerable management support to put into place. Even more important though is that they require TRUST among the parties involved. This is the underlying foundation for agile methods. It is relatively easy to establish a workable amount of trust in a small team in a single organization. It is much harder to do this in a multi-team, multi-organization environment. Nevertheless, in order to use an agile method, one must be able to establish trust.
If you are unable to establish "agile contracts" with your clients/suppliers, it is likely because of a lack of trust. I'm not an expert on agile contracting (I've focused more on single-organization agile implementations), but I do know that Mary Poppendieck has a lot to say on this topic (www.poppendieck.com) and that Toyota and their relationship with their suppliers is often held up as a good example of trust-based inter-organizational relationships.
How does CMM fit in an agile process?
Re: How does CMM fit in an agile process?