The Secret of Agile Development

						
						
What is the secret of agile software development?

						
It is feedback.

						
Where's the Pain?

						
To begin to be more agile, ask yourself, “What is painful in my process?”

						
You spent six months creating a new product, and when potential customers finally saw it, they demanded lots of changes. They indicated that the existing features are not relevant for them. That’s painful.

						
Members of your development teams went off by themselves to write code for weeks or months, and then spent weeks in “integration hell” getting that code working together. That’s painful.

						
You spent months creating detailed requirements of a project, and then found out months later in implementation and testing that you got the details wrong. That’s painful.

						
You have the customer involved at the beginning of the project, but not during the project. At the end, they tell you that you misunderstood their requirements. That they no longer need something, or that they need something else, or you just didn’t do it right. That’s painful.

						
The revolution in manufacturing quality that permitted the Japanese to become big players in the American auto industry did not come from better planning up-front. It came from taking advantage of feedback to improve their process. Any employee on the assembly line could stop the line when he detected a problem in an intermediate stage, instead of discovering the problem after assembly was completed. More importantly, employees on the assembly line were given responsibility and tools for improving their own processes.

						
Waterfall: the Mother of Life-cycles

						
In a typical waterfall process, opportunities for feedback are limited and difficult.

						
Analysis (months)

   -> Design (months)

    -> Implementation (months)

							-> Testing (months)

						
Sometimes the standard waterfall diagram shows arrows between each “step” of waterfall going both ways, in little loops. Design shows problems in Analysis, so Analysis has to be done again. Implementation shows problems in Design, so Design has to be done again. Testing shows problems in Implementation, so Implementation has to be done again.

						
Unfortunately, just like a real waterfall, going upstream is difficult and unusual. And, in real life, the loops between steps don’t just go back one step. Testing can reveal problems in Design and Analysis; Implementation can also show problems in Analysis.

						

							
The Agile Approach

							
Extreme Programming and other Agile methods say that the solution to discovering the problems in these steps, is not to do the steps “better”, which isn’t often possible, but in getting feedback earlier and more often.

							
The steps of Analysis, Design, Implementation, and Testing, which in typical waterfall are spread out over months, are compressed into a week or a day in an agile project.

							
And since Testing is such an important feedback mechanism, Extreme Programming puts Testing before Design and Implementation, in loops that can be as short as 2 minutes. This is sometimes called Test Driven Design, where test precedes implementation, and the design step is called refactoring, which follows implementation.

							
New Test (minutes)

								-> Implementation (minutes)

								-> Refactoring / Design (minutes)

								^------------------------------------------< repeat until the feature is complete

							
This "test-first" approach is also applied at the Customer level each iteration. The Customer specifies the details of his requirements by specifying acceptance tests. The implementation of that feature is not considered complete until the acceptance tests are passing.

							
Planning

							
Planning is also an important step in a project, and one that needs to adapt to changing business conditions, as well as changing knowledge of the problem domain, so Extreme Programming does planning not only at the start (Release Planning), but also every one or two weeks (Iteration Planning).

							
Planning needs feedback too, and agile projects get feedback on the Release Plan by making releases to the customer as often as once every three months, and by acceptance testing every week. Iteration plans get feedback daily, in the form of a 15-minute meeting called a “daily stand up meeting”. The name includes “stand up” because the meeting should be too short for people to need to sit down. A daily 15 minute meeting is better than weekly hour-long meetings, because it focuses the participants on clearing up problems as soon as they are known.

							
Release Planning (every 3 months)

								<-> Frequent Releases (every 3 months)

								Iteration Planning (every 1 or 2 weeks)

								<-> Daily stand-up meeting (every day)

							

							
Applying Feedback to the Remedy the Pains

							
So, to be more agile, you asked yourself, “What is painful in my process?” How can I get feedback sooner to avoid pain? An agile process uses early and frequent feedback to avoid later and more painful (and more expensive) feedback.

							
Do you spend six months creating a new product, and when potential customers finally see it, do they demand lots of changes? Agile projects require that a customer representative be involved at the beginning of the project, with the ability to change the project's direction to keep up with their changing requirements.

							
Do members of your development teams go off by themselves to write code for a weeks or months, and then spend weeks in “integration hell” getting that code working together? Agile projects write the code in small chunks and integrate their code at least once a day, with speedy automated unit tests to support that process.

							
Do you spend months creating detailed requirements of a project, and then find out months later in implementation and testing that you got the details wrong? Agile projects do broad strokes at the beginning, and details just before implementation. Your understanding of the details will change as the project progresses -- take advantage of the feedback during the project to get the details right, just in time.

							
The heart of agile methods is feedback, and using that feedback to improve your product, and to improve your process for creating that product.

							
References

						

						

The Agile Manifesto:  <http://www.agilemanifesto.org/>

						
Agile Software Development by Alistair Cockburn, published 2001 by Addison-Wesley.

						
Agile Software Development with SCRUM by Schwaber, Beedle, Martin, published 2001 by Prentice Hall

						
Agile Software Development Principles, Patterns, and Practices by Robert C. Martin, published 2002 by Prentice Hall

						
                

        
 Email this article to a friend.

        

        
Comments to: