Remember: Agility Is Lack of Rigidity

by Preston G. Smith

As agile development becomes more popular and established, it runs the risk of maturing into a rigid, codified system that, of course, would be just the opposite of the agility we cherish. In my experience, management gravitates toward established, predictable, repeatable processes for good reason: they make management's job easier. To an extent, agilists encourage this increasing codification of agile development by writing an endless stream of books describing just how agile "should" be done.

I believe the best way to keep agile agile as it goes mainstream is constantly to keep the basics of agile in mind as we work. Here are the basics I believe are critical.

Iterate

Don't assume that you can reach the answer -- or, indeed, that you even know the answer -- the first time. Plan to revise, add, and change as you learn more about the system, your tools, and the customer. As Frederick Brooks said in The Mythical Man-Month, "Plan to throw one away; you will, anyhow" (p. 116).

Iteration may not be too difficult to maintain as your agile approach matures, as it is basic to all agile methodologies. On the other hand, iteration (repetition) has obvious "waste" inherent in it, and as managers attempt to "lean out" the business by eliminating waste, iteration is a tempting target.

Continually Go Back to the Customer

We all know that we should listen to the voice of the customer before developing a new product, but this is harder done than said. First, especially in high-tech fields, developers often are far better versed in the technology and the domain than the users, so they like to think that they know best. Unfortunately, they often are unaware of many day-to-day realities of making the product work in the real world, and this leads to frustration for more typical users.

A bigger challenge -- and one where agile software developers have not always done so well -- is in keeping the customer involved in a meaningful way during development. Customers may change their minds during development, but more likely, they will be able to focus their reaction better as they assess later, higher-fidelity prototypes. This is another area where traditional development has had great difficulty. There is a great temptation toward rigidity in trying to capture the voice of the customer initially, writing "frozen" requirements from this research, and designing only to these requirements. Agility requires the ability to change the requirements as you learn during development.

Keep the Team Fluid

Some of the great advances in agile development have been in how the development team operates: pair programmers who repartner regularly, programmers who pick their own tasks from the team's to-do list, and the extreme programming practice of allowing any team member to change any part of the code at any time. Such practices run the risk of being throttled as organizations attempt to standardize processes -- thus making the team a bit more rigid.

Both team members and management often feel more comfortable having clear roles and responsibilities for individuals and having fixed plans and product requirements, but each step in this direction is likely to be a small step back toward rigidity. Consequently, consider carefully the agility impact of any changes you make in how your teams operate.

Let the Process Emerge

I have saved perhaps the most difficult one for last. Emergent processes -- ones that emerge during the project adapting to current project needs -- have been a liberating wind in the agile movement as developers have experimented with new approaches that have moved them away from waterfall processes. As agile matures, there will be a great temptation to believe that agilists now know all there is to know about agile processes and that future projects will be like today's projects. Thus, in the name of good management practice, processes will be codified -- that is to say, rigidified.

One way to codify the process while leaving it flexible is to standardize it in its lower layers (basic activities), being careful to leave flexibility in the upper layers of process (how the basics are assembled). I explain this on pages 206-207 of Flexible Product Development (Jossey-Bass, 2007).

In summary, I have highlighted four areas where your agile development is likely to become less agile as you gain more experience with agile and your techniques "mature." This is not the time to become complacent!