Organizing Principles

I made a recent comment on David Anderson’s blog regarding the underlying assumptions of two software development practices. The point of my reply is useful outside of the domain of software development and I’d like to include some of it here.

In his blog David made the claim that one development process, named Scrum, has an underlying assumption: ”that trying to map the creative process that produces software is futile and there is no point in trying.”

I would say that differently. From my experience, the underlying assumption in Scrum is that the environment surrounding the team(s) is so chaotic that mapping the internal process of the team would not be useful, as it is unlikely that it would usefully describe the activities of the team when they bite off the next chunk of work.

This articulation of the assumption provides a useful dimension for decision-making between various processes. We can ask of our context - how chaotic is the environment? If we make a map of our current activities, how likely will the map be useful in 2-4 weeks?  

The fact however is that many of our working environments are /not/ chaotic. They are simply complicated and maybe a little complex. Perhaps this is the range where different practices, like Kanban, apply more directly.

A question I would pose is whether the use one methodology over the other has more to do with the characterization of a company’s environment, than it does with the usefulness of the process.

What I mean is, if you look broadly at the media, everyday we are told that the world is a chaotic place, just on the edge of chaos, about to fall apart. There is some good evidence for this. We have the financial crisis, the environmental crises, the political characterizations of a “democractic crisis”. Recent change management methods reinforce these beliefs with metaphors like the “burning platform” or the “melting iceberg”.

All of this  attention to crises has created a lens on reality where we are prone to look for more crises. From this perspective a process for making progress in a crisis or in chaos is valuable. 

But if we honestly ask, if our daily work-life is really in crisis, our answer is more likely to be “no”.   There is a fair chance that the work we will be doing next month is a lot like the work we are doing this month. If this is true, then Scrum may not be the process for you. Whether Scrum forces a revolution or not is not important, what is important is if your *context* is in revolution. If it truly is, then Kanban may not be the process for you.

The point is that our context sets the parameters for what a useful work process looks like, and that one significant criteria for deciding what process to use is how fast our context is changing.

If the context is relatively stable, we want to be able to carefully refine our process over time to optimize for the environment. If the context is unstable and rapidly changing, we want to be able to make progress toward an aim despite the surrounding chaos.

Best,

Evan Leonard