#47-Implications of the Agile Manifesto, Part 2

This week I will investigate part 2 of the Agile Manifesto, as part of my series of four podcasts on the subject.

Transcript

Implications of the Agile Manifesto, Part 2

To refresh your memory from the past two weeks, the Agile Manifesto states:

"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."

This week I want to investigate the second point, namely that the creation of the system in a working state is more important than documenting it in all of its aspects.  The genesis of this comes at least partly from the notion that eliminating delays is paramount, and that documentation takes time both in terms of creating it, but also in the ceremony that tends to grow around it: layers of approvals and the versioning of revisions that require multiple scheduled meetings involving many people.  

Lean business theory states that eliminating waste (delays being one form of waste) is more important to the bottom line than increasing the velocity of production.  But agile seems to be saying that eliminating waste will also increase velocity, that this is not necessarily a trade-off.

I think the answer is: it depends.  When you think about “documenting a system” you have to investigate what this means and how it is done.  If it turned out to be a heavy process that slows productivity, then I would agree this represents waste.  But what if it did not?  Could one achieve the value of documentation without sacrificing productivity?

Note that the manifesto does not say that the items on the right are valueless, and I submit that documentation has great value if you consider it to be important that systems can be maintained, tuned, and updated over a long period of time, preserving their ROI.  If they cannot, they lose value and must eventually be replaced.  That could create more waste than delays do, depending on how soon it happens.

In my consulting experience many if not most organizations have large legacy systems that are central to the operation of the business, but that nobody currently on staff understands very well.  The people that created them have long since moved on to other work, or to other organizations, or have retired or even passed away, and the knowledge that lived in their minds went with them.  This loss of institutional knowledge can be massively expensive and can impede the organization from staying competitive as market forces change, which they inevitably do.

I don't think there is a dichotomy between the value of documenting systems thoroughly and keeping productivity fast if two things are addressed:

1. Can we document in such a way that is also, in and of itself, productive toward the goal of completing the system's features?
2. Can the documentation we create retain its value over time; can it be verified at any point to be accurate to the system as it stands, and as it changes?

If there is a way to ensure both points then I would say you can essentially have your cake and eat it too, as they say.  I will address what I think you should do when I reach the conclusions part of this series of tips, but obviously I would not be mentioning this if I didn't think it was possible.

I actually think it's relatively easy.  Stay tuned.