I wouldn’t recommend process

Back in February 2015 (a year ago!) I wrote that I wouldn’t recommend Scrum. Looking back I see that I was merely grasping at the end of a bigger concept.

Here I will try to clarify and generalize from the original post.

I would like to reiterate that I do not think Scrum is bad nor did I argue so in the original post. I understand that, based on the title, it is reasonable to assume that that was my point.

This post is called I wouldn’t recommend process but I do not mean to say that processes are bad and should be avoided. Processes can be valuable, as long as they are not overly bureaucratic and do not get in the way. Processes are helpful when they codify what is already being done and free up cognitive resources.

My first introduction to the world of Agile software development came through Extreme Programming Explained (XPE) Second Edition. Extreme Programming is known by many—and generally talked about—as a toolbox. But in XPE it is laid out as a three-part system: values, principles, practices.

Each of these three parts are different levels of abstraction. Values are an expression of company culture, principles are guidance for how they should manifest, and practices are concrete actions taken repeatedly.

Most importantly, these three levels of abstraction are ordered: you start with values, then find principles that support these values, then practices that live up to these principles.

The Nature of Software Development shows what some of this process could look like. It is a valuable thought experiment and brings you along for an investigation of what comes naturally to software development, naturality being the primary driving value of the book.

Thinking in values first struck a chord with me and having practiced it I see it as an immensely beneficial way of thinking.

Scrum is a process. It is a tool in the toolchain. Your values and structure might lead you to decide to take up Scrum or to take some of the best parts of it and put it together in a way that fits your organization better. If this is how you get to Scrum that’s great!

But I would never recommend Scrum (nor any other process) as the starting point. Trying to figure out how to optimize the production of a company should never start with “use this pre-packaged process”. It should start with values.

Processes, just like principles and practices, should be natural (friction-less) extensions of the culture and values of the company.

Processes that rely heavily on sharing problems do not work well in companies that punish insecurity or mistakes. Processes that rely on hierarchy do not work well in companies with a very individualistic approach. Processes with structure work badly in structureless companies and vice versa.

I wouldn’t recommend deciding on a process. I would recommend figuring out what to do based on the type of company you are in.

When I write more, filling out this form will let you know.