Friday, June 10, 2011

Strong Versus Weak Process

I do a fair amount of agile consulting, and one of the things I see over and over again is the notion of a strong process. The "strong process" is one in which the software development process is a set of rules and requirements to be followed (or else!). The "weak process", by contrast is the one in which the process basically amounts to guidelines rather than rules.

The strength of the process is orthogonal to the process type. It's possible to have a weak waterfall process, or a strong agile process, for example. The type of process describes what the team does, checkpoints, and guidelines for how to create software. The strength of the process describes the degree of freedom the team has in deciding when to follow process and when to do something that's not according to the determined process.

Briefly, a strong process would look like this:

All backlog items for the next sprint will be provided to development for estimation three days before the end of the previous sprint. Any new items provided after that will not have estimates when the next sprint starts, and therefore will be estimated at the highest point level.

A weak process would look like this:

Backlog items for the next sprint will be provided three days before the end of the sprint. This helps make sure that items are estimated before the sprint starts, which helps make sure that velocity is more stable and therefore predictable (which makes for easier release planning!).

The strong process is procedural: it describes what to do and the consequences of failure in detail, including alternate procedures. The weak process describes the desired end benefit, and leaves the procedures and exceptions vague. The weak process tells you where you're going, and leaves it up to the team to find a good route.

So why do we care?

Because the process should be the servant of the team, not the master.

Please note that I'm talking almost entirely about smaller teams. With larger teams (over about 30 people) or many teams, then consistency of expectation and work environment gets more important, and processes have to be a bit stronger to prevent total chaos from emerging.

So, why do strong processes ever exist on smaller teams? Fear.

A strong process is usually the result of a team that has been or is afraid of being jerked around. Perhaps they have been put through a death march of ever-changing requirements. Perhaps they are reacting to a product manager they don't respect, and attempting to use the process to point out that he's really far behind and vague to the point of hindering the product. Perhaps they are not confident in their abilities and looking for a scapegoat. In any case, they are usually hiding behind the process as a shield to help with a real underlying problem.

A strong process makes a terrible shield, however. All it's really good for on a small team is providing a method for identifying blame. So get rid of the underlying problem, and then take the strong process shield away. It's time to make the process work for you, not make you work for the process.