#49-Implications of the Agile Manifesto, Part 4

This week I will tackle the four point of the Agile Manifesto, with an eye toward my conclusion podcast next week.

Transcript

Implications of the Agile Manifesto, Part 4

Just in case you've joined us recently, I've been focusing on the four parts of the Agile Manifesto, which 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 address point four, which is about responding to inevitable change over the strict adherence to a previously established plan.

As the 20th century drew to its end and computer automation became more and more prevalent in business, many industries gradually realized their vulnerability to the quality, cost, and reliability of such systems.  Understandably, they sought to bring them under management.  But most of the leaders of these industries knew that they did not understand computers, nor software, nor the experts who created and operated it.  So, they turned to the universities for help, who in turn looked for an analogy to guide them.

Many things were tried, but they eventually settled on the notion that creating such automation was like building a large, complex, civil engineering product, such as a bridge across a river.  The term "computer engineering" came from this belief, as did the initial efforts to manage it.

This turned out to be a mistake, but it was a mistake that persisted.  The "make a firm plan, then stick to it" approach has never really worked, because businesses rarely have fixed requirements, and the marketplaces they operate in are in a constant state of unpredictable change.  Building a bridge is largely a matter of physics.  Running a business is not.

But this also led to technical practices that were not change-friendly.  Most if not all developers with experience would choose to create a new system rather than maintain an old one, because of these traditions that grew out of the misbegotten analogy "computer engineering."  Also, the notion of changing the design while building the system has been anathema to them, much as engineers would hesitate to change the design of a bridge when it was half-built.

Agile says we must embrace change, and in fact the manifesto stresses the value of responding to change, not resisting it as traditions would suggest.  This means that those traditions must be abandoned and replaced with new ones that allow for constant change without damage, chaos, and waste.  Anything else will make agile a failure.

A lot of what I do is all about this.  Next week I'll give my conclusions to these past four agile tips; what I think you should do about their implications, and how to do it.