Yesterday I finished reading through Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman from Dave Hoover and Adewale Oshineye. Personally I met Ade at the Software Craftsmanship conference in London earlier this year and participated in his session on Mapping personal practices. After I came back I used the format for Personnel development. Since May I have a video from Ade open in my browser tabs on How to walk the long road, which I still haven’t seen, yet. So, just after finishing the book, I decided to describe my personal development as a reflection of the last four years of my life using the pattern language provided in the book. So, here it is.
Alistair Cockburn told us about a research in the UK on Scrum. He pointed out to the student, that Scrum is not a process, but something different. This made me thoughtful and I decided to elaborate some more on the terms and reflect on the other Agile methodologies about it.
Dale Emery influenced this blog entry with his paper on Writing maintainable automated tests. At the essence I’m going to compare several test approaches: Unit Testing (i.e. Test-Driven Development), Functional or Acceptance Testing and Exploratory Testing. I’ll look at means necessary for regression capability (checking), costs for testing and costs for adaptation to changing requirements.
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
- Customer collaboration
- contract negotiation
- Responding to change
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.
When a manager asks you to show him your test cases, ask him to show you his management cases.
When a manager asks you to show him your test scripts, ask him to show you his management scripts.
When a manager insists that every test should have an expected, predicted result, ask him if every management action should have an expected, predicted result.
When a manager insists that we lower the cost of testing by bringing in test automation, ask if we can lower the cost of management by bringing in management automation.
When a manager wants to evaluate testers based on “defect escape ratios”, ask if we can evaluate management by “bad management decision escape ratios”.
(Inspired by James Bach)
After going through this series, I was personally considering to put up some elaboration on each of the quotations on the roughly 40 slides here. Unfortunately my available time does not permit this. Maybe I will come up with a series in some weeks or months, but for the time being stick to the presentation. There is one statement on each slide, and Michael did a great job to combine them together from great thought-leaders – as I think. Read them. Now. Really.