My opening keynote at the Scaling Agile conference in Brussels yesterday got a good response on twitter and resulted in some good conversations through the rest of the day. As a part of that I put up a slide I have used once before listing examples of sin in Agile practice. I was asked if I would elaborate it and bit so I will. In the presentation I used an picture from hell, but I have decided to be milder in this post and the illustration is of purgatory. Now I can’t give all of the build up to these so this is a summary without too much elaboration. Oh, and there are seven which appropriate although not all are deadly. I’ll leave it to readers to decide which is moral, and which venial.
Practice ill informed by theory; the it worked for me error
I’ve posted in and around this subject on many occasions. In the build up I referenced the evidence that we don’t see what we don’t expect to see along with the cobra, hawthorn and butterfly effects. So working a method from a limited number of cases is dubious if you can’t confirm the approach against sound theory. By theory I mean established evidence based approaches from the humanities and the natural sciences. Add to that good people can make even bad methods work, but that will not scale.
Aggregation, deconstruction & linear approaches to complexity
A more complex point and readers might want to switch to yesterday’s post and follow the links to my series of posts on scaling. The point is that you can’t scale be simply adding more and more of the same in ever more complicated structures. Scaling in a complex system is about decomposition and reconstruction in a different context in different combinations. So scaling up to C level means that we need different practices. As part of the presentation I went through some of our new thinking on complexity based project management to show the way that you might combine radically different practices.
Certification & accreditation pyramid
This one really speaks for itself. The idea that after you have been through a five day training course that you are qualified to run a three day training course is a classic pyramid selling scheme. To train you not only need to be trained, but you also need a broad spectrum of experience in application of the method. That does not include retrofitting. It takes two to three years for any human to truly acquire knowledge enough to teach. Without that all you do is read the slides, tell a few stories and push information. Oh and you pay your royalty of course. I am frankly amazed that people keep falling for this type of snake oil.
Use of manufacturing metaphors & techniques in a service environment
One of the things that surprised me, when I got back into software development after an invitation to present Cynefin at an XP conference several years ago, was the degree to which manufacturing metaphors and techniques dominated. Products were being defined, produced and moved around on Kansan boards. Now all of that is useful, but we need to realise that in a uncertain world with more frequent changes that we are dealing with a service not a manufacturing process. This is always difficult. IBM to my mind never managed to shift from being a manufacturing company to a service provider (although it sold a lot of services). We need to start thinking again about the way that software is architected so that applications can be ever changing emergent properties of the interactions of objects (software and people) within a ecologically orientated architecture.
Waiting for requirements rather than
articulating needs & opportunities
You will have to wait on this one – I am working on a major new participative project here and will announce it in a few weeks along with an elaboration of this point.
Focus on qualities in people rather than on linkages between them
Again a recurring theme for regular readers. People are determined by their interactions with other people, social constructs and physical objects far more than by any innate competence. I’ve hit Myers Briggs enough over the years to make the point that you can’t and should not put people into neat categories and treat them like widgets in a manufacturing process. A huge effort goes into trying to change people one at a time, when changing their environment would be more effective and also more moral. Its not for you as a coach to tell me what sort of a person I should be. There is no one model of behaviour that works in all contexts and humans, given the chance, are a damn site more resilient and adaptive than the various behavioural models peddled by trainers would allow.
Idealised models: simplistic not simple
Again, 101 complexity; in a dispositional system you can’t determine an ideal end point. Indeed doing so means that you miss opportunities in the near future which could be more beneficial. You can’t give simplistic prescriptions about how people should dress, what sort of values they should have and the like. What matters is what is done here and now; managing the evolutionary potential of the present.