Elisabeth Hendrickson put up a response on Why I defined Agile in terms of results on her blog, which made me thoughtful about the dialogue I had last weekend with Alistair Cockburn on the XP Days Germany. Though a more thorough write-up of the conference from me is still missing, I decided to respond on Elisabeth Hendrickson’s blog entry.

During the Open Space session on Saturday Cockburn introduced to us the use of the value statements in the Agile Manifesto as dials. Overall there are eight dials on the meter to consider:

• Individuals and interactions
• processes and tools
• Working software
• documentation
• Customer collaboration
• contract negotiation
• Responding to change
• plan

Based on the particular context we tune the amount of individuals and interactions and the amount of processes and tools. Likewise the remaining six values can be adapted to our particular situation. Indeed, we value all eight mentioned terms. That means that we may sometimes need to create documentation. As Hendrickson pointed out to me at the Agile Testing Days earlier this year, being Agile does not equals being stupid. If there is need to create that thorough documentation so that you can be set-up for the next round in the Cooperative Game, then you better create it – now! On the other hand if you find out that you’re documentation is mostly waste, then you should reflect on how to recude it or get rid of it completely. But you need to consider your particular situation, the project, the customer, the people involved at hand. That is what good coaches do.

The second thing Cockburn pointed out was the fluent up and down among practices, principles and values. During our work we keep on continuously switching from one level of abstraction to another, up and down. Some time ago I thought that this fluent switch among the levels is comparable to skill-set development with Shu-Ha-Ri. The main difference is, that you go through the Shu-Ha-Ri stages when learning a new techique, like TDD or Refactoring or facilitating Retrospectives. When working in an Agile team, you switch quickly between the values like simplicity or responsibility and the practices and principles, like TDD, Refactoring or Emergent Design. From time to time you may adapt and adopt some of your principles, practices or even values. Indeed, the Software Craftsmanship Manifesto is just a result of such a value shift. Giving the Agile values, we have put our new values beneath them. This does not mean that we don’t value the statements from the Agile manifesto, but we found new value statements that we think are worth to consider for the next ten years or so.

Getting back to Elisabeth Hendrickson’s write-up, focussing on the results is essential in all the above. When we loose our focus on resulst, we start to day-dream and seldomly get something productive finished. You can use the dials from the Agile or Software Craftsmanship manifesto to finetune your situation, but do this based on the results you already got. The essential thing here is still reflection. Without reflection I constrain myself to self-blindness and No-Problem-Syndrome thinking. This hinders innovation and improvement in your actual work.