Potsdam, October… it must be Agile Testing Days! Ok the observant among you will realise that last year it was in November…
Anyway, after my first conference last year I was very excited to return this year, and as a consensus speaker!
Sounds strange, but walking into the conference on the tutorial day, had a ‘coming home’ feeling, especially getting re-acquainted with Pete Walen, Matt Heusser, Lisa Crispin, Janet Gregory and Carlos Ble, not to mention new friends Dan Ashby and Paul from Net A Porter.
Accelerating Agile: From months to minutes
Dan North, of BDD fame, hosted this tutorial and one would have thought he would be plugging BDD etc. But it was far more than that. He introduced to us the concept of testing patterns.But more importantly he stressed the significance of context. Any approach to testing, any application of testing is reliant on context. Context potentially changes what the expected outcomes should be. For example, you would assume that wearing a seat belt would be a given, assumed action for any driver; but put it in the context of the ‘Ice Road Truckers’ and seat belts are a bad idea.
It makes sense when you think about it, but how many times have you tested something with the ‘obvious’ workflow in mind, yet the customer uses it differently because they are constrained by something you didn’t know about. Context!
Anyway, the tutorial was based around not creating/delivering software but delivering business capability. Software is the cost of getting business capability. This cost includes the writing cost, opportunity cost (the cost of doing one feature at the expense of others), cost of learning and the cost to change.
Dan had an interesting view that what we should be doing is not software engineering. Instead it should be delivering business capability through information technology, and that software engineering is just one tool to use in achieving this.
I really liked this view as software is often over engineered. Reaching the desired goal using the minimum of effort.
Dan introduced several patterns for effective delivery that he has identified since joining a very high performing team who were not using agile practices.
The three core patterns introduced were ‘Three Ages’, ‘Fits in my head’ and ‘Short software half-life’.
This pattern describes the three stages of the product lifecycle; Explore, Stabilise and Commoditize.
- Explore – experiment and validate ideas. “Maximise discovery”
- Stabilise – coalesce ideas to be shared “Minimise variance”
- Commoditize – make the idea into a thing that provides the business capability. “Maximise efficiency”
Fits in my head
The general message for this is that context-switching is bad and that it’s best to reason about things that fit in your head.
If you’re dealing with a complex system, you can either ignore the complexity and work around it, or simplify the system but introduce a delay while you do that.
By simplifying stuff down to head-sized chunks, it becomes easier to share, easier to learn and easier to fix/maintain.
Short Software Half-life
This pattern measures the time it takes for half of the code to be removed or completely re-written. Dan claims that teams that move quickly have a short software half-life, ~6 weeks! This makes sense when you start to break it down. Deleting or significantly refactoring half of the code every 6 weeks means you’re more likely to maintain a slim, efficient code base. It also means you’re constantly re-evaluating your software and doing what will support the required business capability.
This is, of course, is somewhat radical but I agree with Dan when he says that code has no value, it’s the ideas that have value. Therefore don’t treat the code as special. It’s easy to say that, and I suspect the reality would be rather different, but it is certainly a very interesting idea.
Dan then went on to explain the ‘aww crap’ scenario where issues are discovered accidentally at a late stage or once released, hence the ‘awww crap’ exclamation.
Through appreciation of the order of ignorance, that ‘aww crap’ moment can be brought forward in the process to ‘oh really?!’, and changed from accidental discovery to deliberate discovery.
The biggest constraint to achieving deliberate discovery is 2nd order ignorance. This is where you don’t know what you don’t know, therefore not only are you ignorance of something, but you are unaware of that ignorance.
This is mitigated by front-loading the work to uncover those ‘don’t knows’. Working the problem, talking to the product owner, learning the context and the risk areas for the contexts can all help to at least reduce the order of ignorance to the first (Knowing what you don’t know).
My Takeaway Triple from Tutorial Day
- Learn the domain! To be a great tester or developer, you need to learn the domain. Simple and obvious, but surprisingly not always the case!
- We are providing business capability. By focussing on this, rather than purely developing software, there is more chance we will actually deliver something the customer wants, faster!
- Story order should be determined by those of most uncertainty (most 2OI) first.