On the 24 an 25 of May, my colleague and I organised and attended the Specification By Example course of Gojko Adzic at our company. We both very much appreciated Gojko’s book on the subject, and much of what he says fits very well with the style of dealing with requirements that I’ve used in the past. And takes it that much further.
As a trainer myself, it was very useful for me to see the excellent way Gojko has structured the training. He relies on a heavily participatory style, where the students take a very active roll. He specifically mentioned the book ‘Training from the Back of the Room’ as inspiration for this approach. In our own workshops we also try to keep audience interaction going throughout the day, and find it to be very effective in preventing sleepy students and getting stuck in theory. The reason this was doubly effective in this training is that many of the excercises Gojko gave us were techniques that are also effective for use when doing the things the training is about: facilitating communication on requirements and specifications.
I’ve listed some of the highlights for me below:
Diverge and Merge
Having recently listened to Michael Kennedy talk about Set Based Design seeing how the practice of ‘Diverge and Merge’ implements those principles within a single meeting was an eye-opener. The way this worked was that a problem or goal was posed, and the group was split into four smaller groups to work on a solution. An example of a problem was how to write good examples for a given feature.
We split-up, worked on the issue for a short period (20 minutes), and then centrally discussed the different solutions, and discussed what the best option would be. This would usually be “That one with some of the stuff from that other one included”;. Doing this for discussion on design, requirements or code can be easily done in the normal one hour timeframe for a meeting and give much better and quicker results than the usual sitting around a table. Also, through the mechanism of separate groups, it automatically alleviates the influence of one very vocal participant dominating the group.
Process
There was plenty of talk about process. About who should be involved, how much time to spend in different situations, and when all this should happen. All good stuff, but for me mostly familiar. Someone new to the material would certainly pick up all that was needed to understand how to approach the requirements process for an agile project.
One interesting observation about Gojko’s approach is that he is very careful not to use any Agile of Lean terminology. His approach is obviously related to the one used in Kanban, and he repeatedly mentioned the Theory of Constraints: he stated that he preferred to guide customers step-by-step to solve their most pressing problems, without using a specific methodology to do so. Of course, what you then end-up with is very Lean and Kanban looking and feeling…
Examples
Naturally, in a course called ‘Specification by Example’, a lot of attention was given to specifying examples! This, also, was approached in a participatory fashion. We got handed a stack of specifications, and were asked to rate for helpfulness to support (separately) Shared Understanding, Test and Documentation. Though there were some differences in how we scored the specs on those separate measures, there was mostly agreement on what are good specs, and what… less so.
Another Diverge’n’Merge was used to let us try to determine the qualities in the specs that we were given that contributed to the spec being either good or bad. This was followed by a nice overview by Gojko, which contained everything we found, and a few we didn’t.
What makes a good spec, and what will make you get shot by angry developers
We then continued by taking one of the given bad specifications, and (again) splitting into three teams to create a version that would be better.
This exercise gave us some nice insights into different ways to solve this problem, and a nice confrontation with some of our automatic responses. Usually, fewer examples was good, but the right ones. And for me specifically: splitting was good, but not too far. I tend to try and make problems smaller, but in this case splitting too far made this problem harder to solve.
Effect Mapping
The last exercise (and I haven’t discussed them all, of course) that we did was the one I thought was most impressive: Effect Mapping. Effect mapping is a process to go from a goal or vision all the way to what to do to reach that goal. Gojko has recently released a ‘beta’ version of a short book about Effect Mapping on his website.
I found enough of interest to talk about on the subject of effect mapping that I’ll be writing a separate post on it, linked with some Lean Startup principles and Hoshin Kanri. Soon:-)
Our Effect Map
For now, the short description (again, read Gojko’s booklet for the full explanation) is that effect mapping is a joined Mind Mapping exercise where different levels of the mind-map are the answers to different questions:
- Why? (The Goal)
- Who? (Who can have a role in reaching that goal; Or preventing it)
- How? (In what way can they help, business activities)
- What? (What are the concrete software features to make; Or non-software actions to take)
By making the goal specific, and measurable, it then becomes possible to not only weigh the different possible ways that contribute to that goal and prioritise them, but also to verify if the goal was actually reached. On the inevitable question about making business goals measurable, the answer given was a reference to the book ‘How to measure anything’, along with some choice examples.
All in all this was a great training, which for me resulted in some very powerful new tools to use in handling requirements at all levels.