The opening circle saw many more sessions proposed which filled the board nicely. Plenty of options throughout the day.
Are you Ready?
First session was with Joseph Pelrine on the Definition of Ready. The aim was to see if we could produce a generic list of criteria, for a story, that should be met before being passed into implementation. Similar to the Definition of Done.
It was interesting to hear that a number of people have introduced similar concepts into their development cycle:
- Requiring breakdown of stories so they are understood.
- Example workshops to give better guidance to the development effort.
- Generally doing some prep work before planning an iteration or committing to completing something.
One interesting aspect of this is how the idea could quite easily fit together with Feature Injection. The example workshop fits well into both ideas and would give you a common point where you can pass from analysis into development.
The second session, with Steve Freeman and Joseph Pelrine, was on organisational complexity. I like the idea of underpining the Agile ethos with a solid foundation – we know it works, but why it works is an important issue. Everything started with a quick introduction to the Cynefin model:
- Complex: molecule, can’t be reduced to constituent parts
- Complicated: mixture, can be reduced by not as effective when individual parts
- Simple: Individual parts, straight-forwards and repeatable
- Chaos: indeterminate effect, isn’t understood to start reduction
A nuclear submarine is complicated, mayonnaise is complex.
- Joseph Pelrine
Also introduced was the Butterfly Stamping exercise. This could prove an interesting experiment with a team. It should highlight the reason software development is difficult. Making them more aware of how we can tackle the complex and chaotic areas in a sensible fashion.
The approach to complex issues was one of inspect and adapt, or more properly: probe, sense and respond. Very similar to the Agile way of thinking, however XP has been more focussed on the complicated area of software.
The approach to seemingly chaotic issues can be tackled in a similar fashion: act, probe, sense and respond. Here the act is important, you aren’t sure what will happen but drive a constant into the issue to see how the other areas respond. From this you can hopefully glean more information on which you can act again.
People over Process
The last session I attended was part two of people over process.
Here Chris Matts was interested in particular in how we handle the “hero” phenomenon seen in software development. Some interesting insights came out of the session.
However, it concerned me that firing a person was seen as a success. I just can’t get behind that one. It may be a necessary evil, especially if you’ve run out of options. It would never be a success for me as a coach.
Benjamin Mitchell made the point that none of the solutions people were offering sought out the root cause. Why had a hero had been allowed to develop in the organisation? What particular practice or process was put in place to prevent it happening again?
The only exception to that point was where someone said they had moved the hero off the team, to another team close by. This corrected the issue but made it seem to be that the person was the problem rather than the system/organisation that produced them. Again, not ideal.