I did a lot of thinking on the walks this weekend, especially during the painful finale to day two where I wanted to talk my mind off things and give myself some motivation to carry on. In part this was due to teaching the first agile-cynefin course in Vienna and my attempt to match SCRUM (and more specifically sprints) to the complex domain. Now it is a point of honour for many SCRUM people that their techniques are there to handle the complex, or sometimes the chaotic. I have always argued, in part contrast, that they should really focus on the transfer from complex to complicated or from exploration to exploitation.
In the course I put up a slide with the traditional sprint process and argued that this did rightly handle complexity, as it took different approaches and developed in tight timescales with a willingness to abandon or re think results. The concerns I had were the very formal roles which seemed to create some barriers to me, for example the role of Product owner who, according to the literature has to represent a broad group of users and to do so in designated slots. This seemed to me fine, but over restrictive if the levels of uncertainty. I wasn't fully happy with this to be honest and during the walk it came to me that I need to make some changes to the consensus-coherence sub-domain model of the complex.
So here it is, and its still not right so treat it as a work in process but I'm pleased with the direction. There are three major changes:
Its this latter point which is the more important. Where you have low consensus/coherence then higher volatility is inevitable. To handle this effectively; to allow safe-to-fail experiments to fail we need those experiments to be small.
As we move up the diagonal, the granularity can get more chucked and the variable reduced until as we transition into complicated we are at a substantive size.
I think this was the point I was making in Vienna. SCRUM as a method can handle all of this, but it does not consciously map to work out what level of granularity is needed; that to my mind needs to be a new first step. we have different types of proof which provide one dimension and consensus is fairly easy to measure. We have an app coming out soon which will allow mapping to Cynefin and I might modify that to handle the sub-domain models as well.
Once complete then, for the finely grained requirements something like social network stimulation (SNS) is best provides a different way (or possibly an overlapping way) of managing the feed into sprints and possibly for allocation of resources. In SNS constrained based self-organising teams work on the issues both directly and obliquity to discover what is possible. Ideally in a development SNS users with designed knowledge are a part of the criteria for team formation so we have higher levels of continuous engagement than in a normal sprint. As needs become clear the roles can fall back to those provided for in the SCRUM manuals and training.
This is a both/and not an either/or. I think the sprint concept needs little change and it handles complexity. However what is fed into a sprint, at what level of granularity and with what pre-processes is not always addressed. More to do on this, but take it as initial thinking and feel free to feed back. Ideally what I want to work is an SNS in SCRUM language – more ideas on that especially welcome for those who have been through the mainline advanced training.
Social Network Stimulation is more fully described on the method sheet which can be found here. I think that may require premium membership so I have provided a base description above.
The second day of my Exmoor weekend saw me awake to the sound of rain. ...