What is Agility, and Why Should You Care?

Posted by Mishkin Berteig on May 16, 2006 12:09 PM

Community

Agile

Topics

Delivering Value,

Methodologies,

Stories & Case Studies

Tags

Introducing Agile

Agile is a set of practices and principles that help teams and organizations work more effectively by empowering teams, amplifying learning and eliminating waste.

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:

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.

1. Back to top

   What about contracts and multi-party coordination?

   May 29, 2006 3:25 AM by Faui Gerzigerk

   Alright, that's all very plausible: TDD, shorter iterations, more customer involvement, quickly adapting plans to feedback, etc. But there are two elephants in the room that need to be talked about: Contracts and coordination between multiple projects/parties. Both have a tendency to contradict agile principles because they are simpler to do when things are cast in stone at a particular time. Re-negotiating contracts, interfaces and schedules takes time too. I would be very interested to hear about agile contracts and agile multi-party coordination.

   Reply

2. Back to top

   Re: What about contracts and multi-party coordination?

   May 30, 2006 12:15 PM by Mishkin Berteig

   Multi-party coordination is fairly simple: just follow the same basic principles and discipline including self-managing teams, amplifying learning and eliminating waste. In practice this means that as much as possible, you want to: - 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.

   Reply

3. Back to top

   How does CMM fit in an agile process?

   Jun 15, 2006 5:54 AM by Donn Manlapas

   Our company is embarking to be certified for CMMi Level5. During initial briefings, we're seeing a lot of additional documentation activities for tracking, metrics, etc. I'm just curious how would an agile process and CMM fit together?

   Reply

4. Back to top

   Re: How does CMM fit in an agile process?

   Jun 19, 2006 3:30 PM by Mishkin Berteig

   CMM and agile can fit, but most approaches to CMM are very document heavy and _not_ compatible. CMM is usually used as a prescription to improve the maturity of a software development/IT organization. However, CMM is meant to be a descriptive model. The additional activities that you are seeing are only useful if they don't become barriers to your primary goal: organizational success. In software development/IT, your contribution to organizational success is primarily dependent on being able to deliver working systems in a timely manner that actually satisfy customer/stakeholder needs... as they pertain to organizatonal success. If CMM is adding a lot of documentation, it is likely going to end up hindering your ability to deliver working systems in a timely manner. Check out my article The Art of Obstacle Removal and my whitepaper (pdf) about the relationship between lean and agile methods.

   Reply

• Older >