I get asked fairly often to describe what agile development is. My consulting company's most popular
seminar series is about agile/lean processes. The folks that usually attend invariably have little or no understanding of agile when they first come in.
This always comes as a surprise to me since it's been 10 years since XP began its ascent into the mainstream. And it's clear that the agile approach still isn't understood by many folks in IT, despite the fact that they are almost always quite curious about it! I view this primarily as an indirect failure of the agilists; no one has yet hit on the right set of memes to distribute this much needed evangelism.
So it's great when I come across artifacts that accurately capture the spirit of agile concepts in a single snapshot. And today, while surfing the blogosphere, I came across Sam Newman's excellent Agile Release Process post that includes a diagram that is sure to ultimately cause a bit of heated discussion. But it also does a very commendable job of conveying the essence of most agile processes. I especially like that it specifically emphasizes the delivery of value to the customer. I've included a slightly modified version below with notes that I hope will address misperceptions that the diagram can convey to the uninitiated.
Figure 1: The Agile Release Process - High Level Flow
A lot of folks have already chimed in on other blogs and said this should actually be called the Agile Development Process, but that's not entirely accurate. The development process cuts across this for sure, but there are important elements of agile development mechanics that aren't conveyed here. Instead, this diagram clearly shows how end-user value is taken in the form of stories (requirements) and transformed step-by-step into a release that delivers the functionality to the stakeholders, all in the framework of (hopefully) rapid iterations.
My two quibbles with the original release diagram was that:
1) It didn't make clear that end-user functionality is made available for early examination by users, either in the development shop, or my personal favorite, deployed to a group of early-adopters. These are trusted users that don't mind working with beta releases and are representative of the user community. This should happen during the deploy step (in the above diagram), where newly implemented stories are forked off to the early-adopters and the QA process at the same time.
And 2) it didn't describe the time-boxed gating process at the end of the iteration. This ensures stories that don't cut the mustard, are too buggy, or determined not to be needed due to low return for the investment, are cut or moved to the next iteration. Each iteration should start at a predetermined point in time. And since the product should always build and run, time-boxing is not only possible to do rigorously with agile methods, it's essential to keep things moving along.
Finally, since I do worry that workable agile development memes are in short supply, here's a brief recap of the values that drive it, in what I hope is catchy sound-bite form:
Agile Development Values:
- Satisfy the customer, through early and continuous delivery of valuable software.
- Welcome changes, especially in requirements, up to the last responsible moment.
- Deliver working software frequently and maintain a working build at all times.
- Stakeholders and developers must work side-by-side to achieve a common end.
- Construct the project around motivated people and give them what they need to succeed.
- Face-to-face communication within the project is to be preferred above all other forms.
- Working software is the measure of progress. Working stories that are in production is the only success criteria.
- Sustainable but continuous pace. Schedules and staffing must allow a constant pace indefinitely.
- Architecture, requirements, and design should come from self-organizing groups on the team.
- At intervals, the team must rigously reassess itself to tune and improve its behavior.
Note: Freely adapted, with thanks, from the Agile Manifesto principles.
Lean development, which has the elimination of waste as its key driving factor, is also trying to make inroads in almost the same space as agile methods. Lean development also seems to be suffering from a similar lack of effective viral marketing. Although I have seen numerous projects, especially large formal ones, frequently try to introduce elements of agile processes into their hide-bound playbooks, I still think we're an epiphany or two away from the aha! required to get agile/lean methods truly established in the traditional IT world.
Technorati: Agile Methods, Computers and Internet, Programming