The agile manifesto is a precisely crafted document in which every word matters. The phrase “while there is value in the items on the right” if often interpreted as “we must avoid the things on the right at all costs”. This is neither the intent of the authors of the manifesto nor is it a good way to develop software.
Processes and tools
Processes and tools can help bring about consistency which reduces churn, reduces duplication and increases predictability. One of the biggest challenges for agile software development is that traditional managers believe that they will lose control of the development effort. This will erode their ability to predict when milestones will be accomplished. A process can give newcomers that security while still fueling innovation. The process does not have to be heavyweight or dictated by management. The team can decide on and agree to follow the process. Careful selection of tools can save money and effort; not everything has to be written in house. A thoughtful balance is necessary to success.
Comprehensive documentation
If there is a single extra word in the manifesto, it might be the “comprehensive” in this line. I find it very difficult to ever value comprehensive documentation, and much less to create it. That said, some documentation has value and that is often neglected. The argument is made that tests and well written commit messages substitute for all documentation on a software project. “Getting started” documents, architectural diagrams and notes about interactions with external systems can be very valuable to a project and save the team a lot of time. Recently I had a discussion with some colleagues about Javadoc comments. They were being required to comment every method but found that most of the existing code had boilerplate comments that satisfied the static code analysis tools without providing any useful information. We agreed that adding Javadoc comments for an external facing API made sense, but internal classes should self-document with good naming conventions and tests. In short, any document that you as a developer would want to read should be written for your team. One day you might thank yourself.
Contract negotiation
My wife works in the insurance industry and frequently shares stories of lawsuits and claims. This is the world we live in, and a good contract is the difference between freedom and shackles. A well crafted contract supports changing priorities, team size and direction. A poor one limits the team to a narrow objective that might as well be solved with a waterfall process. Work to get the contract out of the way and move on to the real problem.
Following a plan
In the same way that I think the “comprehensive” in “comprehensive documentation” is superfluous, the “following” in “following a plan” may be the best placed word in the manifesto. This line is misinterpreted more than all the others and is use as justification to skip any kind of release planning, forethought, and design. Eisenhower said “Plans are nothing; planning is everything”. Waterfall teams spend up to months planning and the plan is held sacred, not to be changed until the cycle is complete. Agile software must be planned but the plan is mutable and need not be followed. Planning helps clarify requirements, reveal gaps, set priorities and makes sure the project team and the business are heading for the same goal. Skipping this crucial step can lead to muddy requirements and, at worst, development of the wrong product that adds little value.
There is no doubt in my mind that valuing the things on the left more than the things on the right leads to higher value software and more effective teams. Responding to change, preferring working software, collaboration and interactions are very powerful. The authors of the agile manifesto were right to value them more but also to give value to the things on the right. Neither group should be ignored and finding the right balance for your team is essential to successful software delivery.
=Kevin
Kevin Hickey's Blog 