Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

There is an innate aversion to wasted effort. Nobody really wants to do something, only to find that they have to start all over again because what they did was not what was really wanted. In response to this aversion, people are naturally inclined to do more up-front planning. “If they just would have asked for what they really wanted, we could have delivered it, and it would have saved so much time!”

It’s true. If the development team were handed a detailed plan, and the plan were perfect, they would avoid a great deal of rework that happens when plans change. We all know it is true. And so, instinctively, we resist change, instead trying to push for “getting it right the first time.”

What we don’t always realize is that you could probably build it 3 times, two a total waste of effort, in the same time that it would take to plan to get it half-right. Yes, that’s right, there is something gained in doing it even if it’s wrong.

“What is gained in doing it wrong?” you ask? The short answer is “perspective.” You want to get from A to Z. A is where you are. Z is where you want to be. You think you know how to get there. Or maybe you don’t, but you know that the first thing you need to do is go from A to B. Once you have gotten to B, your position has changed, and so has your perspective. Now you have something tangible to look at, and that may reveal to you that Z isn’t over here, it’s actually more like over THERE. And now, it is a little more clear that the next step in the progression is C. Suppose it turns out that C didn’t get you any closer to Z. It was a waste, right? No. You have something tangible that you can point to and say “From here, we need to go in THAT direction.” It is the hardest thing in the world to say “I want to go in THAT direction” when there is no frame of reference. Giving yourself a frame of reference will accelerate progress by orders of magnitude more than the time wasted doing it the ‘wrong’ way. Besides, who says you won’t use C later on for something else?

So, a truly agile team, both in form and in mindset, welcomes change. Because when the roadmap is changing, that means that forward progress is being made. It means that previous unknowns are no longer unknown. The mature team realizes that if things aren’t changing, it could well mean that somebody isn’t paying attention to what you are doing. And that doesn’t bode well for anyone.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Individuals and interactions over processes and tools

Burndown charts are tools. Obviously, they are valuable. But they are only valuable insofar as they help individuals engage one another. A burndown chart reveals where the team is compared to what they committed to. It reveals whether the team over-committed or over-estimated. But ultimately, it is a tool to encourage communication. It is a signal when things are wrong, or when there are opportunities for positive change. But the tool has no value if no one is looking at it. It has no value if no one knows how to interpret it. The tool has value only as a means to an end, that end being the constructive dialogue of the team, and the continuous improvement of the process.

Scrum is a framework, a ‘process’. It is the most popular implementation of Agile software development. Obviously, it is valuable. But what gives it that value? The dialogue between the team members that happens on a daily basis. The dialog that happens between the team and the customer on a regular basis. The way in which it reveals shortcomings in the way the team or the company works. But all of the trappings of Scrum are of none effect if they do not lead to continuous discussion and improvement. Again, the process serves to highlight the need for communication, and creates a context for it to take place. But having the trappings of Scrum without the dialogue and the evolution of the team that it facilitates, and you get very little from it.

Working software over comprehensive documentation

Documentation is valuable as a tool for communication. Its purpose is to help everyone get on the same page. Of course, having everybody together in the same room, having a lively discussion, getting all of the details out, all this yields the same results, in a fraction of the time, and with significantly higher value. The other value of documentation is to convey information to those that could not be there for that meeting. Of course, being able to point to what was built and say “That’s what we built” is just as good as pointing to a document and saying “that tells you about what we built”, in most cases. That’s not to say that documentation has no place. If it is hard to wrap your brain around it, document it, save someone else from having to spend as much time doing so. But if it is self-evident, documenting it is a case of putting the process before the results the process is intended to achieve. Like mindlessly serving a tyrant king.

Besides, at the end of the day, customers don’t use your process documentation. They use the working software. If you have to stop half way through the project, and all you have is documentation, you have nothing of value.

Customer collaboration over contract negotiation

“That’s not what you asked for!” “But that’s what I need!” Contracts are important because they set expectations, and they define roles. But they can also serve as a pair of handcuffs. The customer doesn’t win when they can’t get what they want because they didn’t ask for it up front. And the team doesn’t win when the customer is dissatisfied. In a customer service organization, which ultimately every development organization ultimately is, your success and longevity is determined by how well you can serve the needs of the customer. The contracts that you negotiate should help you do that, not hinder it.

Responding to change over following a plan

Plans are essential. Even in Agile development, you need to plan your work and work your plan. But circumstances change. The plan needs to change, too. It’s a lot of work to create a plan that lays out the next 2 years. Having to go back to the drawing board after six weeks is demoralizing, and a huge waste of effort. Refusing to go back to the drawing board, even though you should, will ruin you. The further out in time you plan, the less detailed your plans should be, so that effort is not wasted as you adapt to the inevitable changes that come your way.

1. quick and well-coordinated in movement; lithe: an agile leap.
2. active; lively: an agile person.
3. marked by an ability to think quickly; mentally acute or aware: She’s 95 and still very agile.

No plan can make it unscathed from concept to implementation.  No matter how meticulous the planning, by the time you can get it half implemented, half of what you built will be irrelevant, and there will be things you never thought of that are more important than anything you planned to build.  Reality in the software development business is the continuous attempt to hit a moving target.

The playing field is never static.  Business needs change.  Technology is continuously evolving.  “Agile” software development is a way of working that recognizes the inevitability of change, and embraces and readily adapts to it.

The difference between Agile and more traditional development methods (such as Waterfall) lies in the speed with which they facilitate adapting to change.  Through deliberately planning out only enough work to get through the next few weeks, and by revisiting the priority of upcoming work on a regular basis, changes to the playing field can be adapted to quickly, and in stride.

It’s simple, in principle.  But old habits die hard.  Truly Agile development is a paradigm shift, a complete change in thinking as well as methodology.  Attempts to adopt the methodology without understanding the reasons behind them will be frustrating at least, and may not reap all the rewards that it promises.  If you are going to adopt the methodology, invest in the people who will be exercising it.  Get them the training they need to be successful.  It will pay for itself before the end of your first Agile project.