… which way I ought to go from here?

It’s been two very busy weeks (lots of big changes to be announced next week have occupied my time) since my first post in this Alice series on the shift to (or rediscovery of) agility, in part stimulated by the Agile movement, over twenty years since I started to develop the Cynefin framework and around a decade since it was picked up by the Agile community. On a wider stage it’s been 17 years since the Agile Manifesto emerged from the mountains of Utah. Since that time, despite the original intent, a lot of “stiff-necked” people have continued in the various mischiefs associated with graven images (for which read certificates), not to mention the unsafe practice of scaling by aggregation and creating highly structured engineering diagrams for what should be organic processes; “ground into powder, and strawed upon the water” to be drunk by those who “have corrupted themselves” and others being about the only valuable use both certificates and said diagrams. But, I need to move on from layering references to Exodus onto visual metaphors from Alice! if you are not familiar either skip and move on or read on from chapter 32.

In my first post I said the series would be “at times polemical and curmudgeonly” and this is likely to be one of those times. My first post established a general set of definitions that cover more or less any field. Today I want to address some of the dangers inherent in assuming short cycle production techniques will translate with ease to business strategy. Such methods are valuable, but not universally applicable, in software development and the same is true within the wider organisation. So lets look at some of those limitations and associated issues before (in a future post) moving on to wider issues. When Agile started, the manifesto was a broad set of principles and as such it might just have been a memory for those involved. But, one method, or rather set of methods namely Scrum hit the right buttons at the right time and very largely was responsible for the overall success of the movement. We can then add in prior moves around Lean the use of Kanban and many other things but Scrum remains a primary driver.

The essence of Scrum is to do things in shorter cycles or sprints, allow more self-organisation in terms of time allocation and managing backlog, the emphasis (and the language) is on product. Let me quote from the Scrum Alliance:

The Scrum framework in 30 seconds

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Just as an aside, in my language this is clearly a method not a framework. It provides for a series of defined steps to achieve an outcome; a framework would position said methods (Cynefin places Scrum in the liminal aspect of the complex domain for example). Now I think the method set is excellent, it has been transforming in many cases and produced real benefits. The problem is when a method set is elevated to an ideology, or seeks to denigrate other methods: I’ve seen a lot of posts that argue if you are doing Scrum properly then you don’t need Kanban and equally silly remarks from the other side of what is one of the all too many border skirmishes within the Agile movement as a whole. Another quote from the Scrum Alliance:

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple

Aside from the use of framework that all looks good but again look at some of the key phrases scope of work, and projects for example. The whole point about a short cycle production technique is that it implies some initial definition or scope. Even in software this can be problematic. For most of my life I have been involved in one way or another with the development of technologies to instantiate or stimulate needs which are either not articulated and in many cases are not fully understand. At least twice (in what became successful software products) I’ve only had a vague sense of the general direction of travel and any attempt to define objects or engage end users too early in the cycle would have prevented progress. They would just have asked “faster horses” to use a quote attributed to Ford, pressed they might have abstracted that to a faster mode of transportation but for much of the early period of the horseless carriage, horses and cycles were faster and, of course, they need an infrastructure before they can be used properly.

I still remember sitting in Brisbane with a bunch of software engineers who had projects which were clearly waterfall projects. They were long cycle with known requirements and little variability in resource allocation. They were not what the users wanted, but without them more popular solutions would not work, or would not work at scale. But in the organisation they worked for you only got promoted if you had all the right Scrum certificates so they declared a one year sprint; canny that. As dedicated followers of fashion they probably now have release trains suitably compromised to match reality. One size does not fit all. I’ve just reviewed an full set of methods designed to move Scrum into the Business World and for my sins being blocked for lacking a positive attitude to the evangelical zeal of the originator who basically believes that Scrum is the solution to the problem of life the universe of anything, and his solutions is not as deceptively simple as 42.

So I can see Scrum working very well for a lot of marketing and HR projects, where the need is known, the responsible executives identified and where micro-management has corrupted more traditional approaches. In innovation or conditions of high uncertainty the pre-conditions for such an approach do not apply, we need more ambiguity and sometimes the role of a leader is just too take a punt. In some cases you create an infrastructure or capability and get it out there to see how people use it before you commit. Overall we need a mixed methods approach, and we need to remember that the Scrum alliance only claim to be one aspect of Agile, not the whole of it. So you need to understand where you are in a life cycle in strategy as well as in software development. In different contexts different things will happen. In selling short cycle management works for product selling, but not for strategic selling which requires longer term relationship building. Sometimes you need to give people longer than a couple of weeks to explore possibilities. At other times you have to make commitments to architecture before you get to applications.

Context is everything – simply taking a partial method from software development and attempting to apply it as a universal panacea for the needs of government and industry will simply result in more damage. The last thing we need is something as valuable as Scrum being used inappropriately or become yet another management fad. Oh, and the same applies to Kanban where moving posts it notes around on a virtual board can often end up as the goal not the means, just as number gaming on backlogs and tokenistic standups and rituals can with Scrum.

More on context in my next post.

PS: As in all of these series you can work out the Alice references for yourselves
Attribution for images: Lewis Carroll [Public domain], via Wikimedia Commons