What the Agile Manifesto Doesn’t Say

stylized image of the agile manifestoA co-worker once told me you know an agile project is done when you run out of money.  Unfortunately this joke points to the belief that agile projects are completely chaotic and unmanaged.  The Manifesto for Agile Software Development reads as follows:

We are uncovering better ways of developing software by doing it and helping other 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.

Like many documents the Agile Manifesto can be interpreted in lots of different ways.  Some teams focus on the four items on the left and take them as license to completely ignore their counterpoints on the right.  In effect, pretending the last sentence of the manifesto was never written.  In fact, the seventeen men who signed the Agile Manifesto did include the statement that there’s value in the items on the right, they simply find more value in the items on the left.

Individuals and interactions over processes and tools

Who could argue with valuing individuals and interactions over processes and tools?  Well, how about Ray Kroc, the man who established the franchise model and took McDonald’s from a single hamburger stand to a national chain of restaurants.  The secret to Kroc’s success, which has been repeated numerous time since, was to proceduralize everything.  In other words, he focused on the processes.  By establishing these processes, Kroc was able to deliver consistency in a way no other restaurant at the time could.  If you want to open a restaurant now your least risky option is to buy into a franchise because they’ve already developed processes that work.  W. Edwards Deming once said “If you can’t describe what you’re doing as a process, you don’t know what you’re doing.”  In other words, if you have no process you’re just winging it.  The Agile Manifesto doesn’t say we should eliminate processes, it merely says good software development requires individual thought, creativity and interaction.

Working software over comprehensive design

It’s fair to say a well designed product that is never built isn’t really worth much.  Leonardo Da Vinci designed many elaborate and wonderful machines that simply didn’t work, at least in his time.  He designed various flying machines, a tank, and bridges.  Many of his designs could not be built during his lifetime because the construction techniques had not yet been developed and appropriate materials were not available.  Da Vinci was undoubtedly a brilliant man but if you were paying him to build a flying machine and all you got were designs that couldn’t be constructed, you probably wouldn’t have been very pleased.  The same is true with software.  An elaborately designed system might be wonderful but a system that works is even better.  The Agile Manifesto doesn’t suggested skipping over software design, it simply points out that a working system is better than a system on paper.

Customer collaboration over contract negotiation

In my early days of project management I was trained to get everything in writing.  All system feature requirements, of course, but also things like performance requirements and acceptance criteria.  What I learned is you can meet all of the written requirements and agreements and your customer can still hate your product.  Performance requirements can be especially tricky.  If you’re building a system for a scientific applications the performance requirements will probably be very clear but for most business applications users will say things like “it has to be faster than the current system.”  What they really mean is, I don’t want to be waiting on the system.  If you try to pin them down to a timeframe, like “transactions should save to the database in less than 2 seconds” that may look great on paper but they still might not be happy with the end results.  Having the customer more involved, more frequently will help them understand when and where trade-offs are made.  As a result they are more likely to be satisfied with the final product.  You still need to negotiate some details of the contract, like what’s in scope and what’s not, and you should still document requirements but your relationship with the customer and their involvement in the project will get you over quite a few hurdles you probably wouldn’t ever specify in a contract.

Responding to change over following a plan

There are two cliches that come to mind here.  “The only thing constant is change” and “failure to plan is planning to fail.”  So how do we satisfy them both?  Old school software development techniques attempted to plan the entire project before much was known about it.  Project managers built budgets and schedules before anybody knew exactly how the business requirements would be met.  Developing the entire plan up front is building a plan that is wrong.  It may be very precise but it will be terribly inaccurate.  So does the Agile Manifesto mean we shouldn’t plan anything?  I don’t think so.  Scrum acknowledges a release planning approach that attempts to group features together to be developed and delivered within a certain timeframe.  The key is recognizing your plans will change and having a process for handling those changes.  Once you define the process for managing change your plans can change as often as necessary.

Conclusion

The Agile Manifesto doesn’t say we shouldn’t plan, negotiate contract terms, document systems or follow processes.  To me the Agile Manifesto serves as a reminder that processes, plans, contracts and documents don’t build complex systems, people do.  Specifically teams of people who need to constantly communicate and be in touch with the business they serve.  It’s also a reminder that the people who develop systems can sometimes get lost in the design and documentation.  When we get carried away attempting to develop the perfect system on paper we end up with nothing but beautiful documentation to show for it.  It’s a reminder that the documentation, planning, contracts and processes are means to the end, not the end itself.