#50-Implications of the Agile Manifesto, Conclusions

This week I will answer the questions raised over the last four Agile Tips, each a different aspect of the Agile Manifesto.  I'll also set the stage for what to expect next from this series.

Transcript

Implications of the Agile Manifesto, Conclusions

This week I want to wrap up this series and provide some recommendations.  But first, to reiterate the Agile Manifesto itself:

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

Over the past four tips I have examined each point, leaving a question or questions to be addressed.  This week I want to address those questions. 

Warning: this is going to be a longer-than-usual Agile Tip.

In part 1 (Agile Tip #46) I ended by writing "Agile requires collaboration.  Collaboration requires an effective framework that everyone can participate in.  There may be many ways to accomplish this, but for myself this means that everyone must have a basic, shared set of analysis skills so that they can work together."

How can we best collaborate?  What is the most effective framework for his, if we keep in mind that it cannot require specific skills or experiences?  This is important because we must not exclude anyone from the process.  If we do, we will miss important insights and proceed with incomplete information.  In my experience, this is a major, perhaps the major, cause of failure in product development.

There may be other ways to make this happen, but in my experience nothing tops acceptance testing.  When people learn to write acceptance tests together, they learn a shared language for collaboration around requirements, and this yields a complete, shared understanding of the business value proposition that drives all requirements and should drive all activities by the team.  If you include commonality-variability analysis in your process, this will make it work all the better.  Acceptance testing is not really about testing, but it uses tests as collaborative tools.  Of course, they also persist as tests for the future, which is extremely useful.

In part 2 (Agile Tip #47) I asked two questions:

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?

The tests we write in TDD (whether they be unit tests by developers, or acceptance tests by all stakeholders) both move the development process forward (hence "driven") and they document the intentions of those that write them.  This is only true, however, if they are written with this purpose in mind, which is different from testing traditions.  They can be verified because they are executable, and so they never lose value.

In part 3 (Agile Tip #48) I posed another two questions:

1. How can we engender the most effective degree of collaboration, given that the stakeholders for a given product may have very different skillsets, experiences, priorities, and may use language in a way that is different from others?
2. If we have no firm contract (and the manifesto does not stipulate this, only that we value such a thing less) then how will we be able to show progress and track completion estimates with little or nothing to measure against?

The language of behavior-driven development (BDD) is Given, When, Then or the expression of cause and effect.  This is understandable by everyone and can be used to describe all systemic behavior.  Remember that all business automation is behavioral, we take a general-purpose machine and make it do something specific, something of value.

If we do this in terms of, once again, executable tests, then the conversion of failing tests to passing test allows us to track progress in a measurable and predictable way.

In part 4 (Agile Tips #49) I pointed out that agile says we must embrace change, and in fact the manifesto stresses the value of responding to change, not resisting it as technical traditions would suggest.

This question has dominated the last 20 years of my life.  How can developers learn to embrace change realistically, to be able to analyze and design systems that have "changeability" built into them without over complicating and thus over-designing those systems?  All the technical training I do, whether it be about design patterns, test-driven development, or emergent design, has at its goal the aim of enabling my students in this way. 

But even non-technical people need to understand this, in order to be able to support it, and to take in into account in their planning.  They need to see what it means to, essentially, enable efficient and safe changes by changing change itself.  That's my next topic to tackle.  See you next week!