While there is value in the items on the right…

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.


Author: Kevin Hickey

I have been a professional software engineer for over fifteen years. I currently work at Intuit as an architect. I have written bootloaders, ported the Linux kernel and Android to new platforms, written CPU diagnostics, developed control software for CPU manufacturing and worked on enterprise web sites. As both a developer and program manager I have been helping software organizations become more agile for over a decade. I am passionate about helping teams deliver world-class software solutions to interesting problems. My current focus is on pragmatic agility for the enterprise. When I’m not behind a keyboard I enjoy spending time with my wonderful wife Amanda, rock climbing and hanging out with my dog Tex. In the summer you can find me in my pool or climbing something. In the winter I count the days until summer returns to Texas (I never have to count too long).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: