Steve Fenton

Reduce roles and reduce handovers

Archived from the Cranked Alliance website

In Cranked we have just two roles, Business and Technical. Compared to some other software development methods, this is a very small number.

So why are there so few roles? There are two main reasons for this number.

Roles are Handoffs

If work is passed from role to role in sequence, then there are hand-offs to be done between each step in the sequence. If there are n roles, there are n-1 cases where the baton must be passed along to the next role. This doesn’t include any feedback between stages. Each hand-off brings its associated risks in terms of communication and understanding.

On top of this, working on a small step in a larger sequence is not a human endeavour. It is an attempt to treat humans more like machines rigged up in series. Creating a sequence of work with specialist machines, where each performs one job repeatedly as work passes down the line is a great way of taking advantage of the qualities of machines. Machines are designed to do a specific task uniformly and repetitively.

Humans are Not Machines

When humans engage with work, the qualities they bring are those unique to humans: thinking and creativity. This is why it has been repeatedly found that allowing humans to work on a task for the whole length of the line is better than having them specialise as the machines do. The concept of a humane working environment is not just a moral philosophical concept; it results in increased productivity, better distribution of work and motivated people.

Roles Narrow Options

It has also been discovered (and rediscovered many times over) that roles can become labels that restrict engagement in work outside of the narrow role. This was found in the assembly lines in the 1940s and it can be found in software development teams today. As long as you call people programmers, testers, deployment, operations… you create a start and an end to the tasks those roles will perform. (Of course, there are plenty of software development teams that manage to avoid this problem in spite of these role names, but ultimately they are successful in this respect despite the roles).

So, why have two roles?

You may be wondering why Cranked has two roles if they are so bad… why not just one role?

Actually roles aren’t all bad. If they were, there would actually be zero roles in Cranked. Where roles are useful is in shaping responsibility. This is done in a positive way in Cranked by re-stating an idea from Extreme Programming: business people make business decisions and technical people make technical decisions.

While there are some cases where the business and technical people could all come from a single all-purpose team, it is more usual to find business experts joining with technical experts (who may not know the business domain at all) to solve problems. If you are working in a product business or on software used within your own organisation it is likely you will find technical people with lots of domain knowledge, but there are many examples where a strong technical team will be working alongside domain experts to create software for an industry they have no knowledge about. In either case it is more important that the technical team are experts at software development than experts at the particular industry.

So that is why there are two roles (and only two roles) in Cranked.

Written by Steve Fenton on