What is Cranked?

Welcome to Cranked – a framework with an example implementation; a sequence of stages, activities and practices that draws inspiration from many lean and agile sources.

  • Craftsmanship
  • Reduce Waste
  • Agile
  • No Estimates
  • Kanban
  • Extreme Programming
  • Drip Funding / Deploy Continuously

The Cranked framework seeks to dramatically reduce the feedback loop by helping teams to quickly create product increments that test business assumptions. The framework includes many activities that are designed to ensure that the fast cycle times can be maintained or even improved over time.

The term cranked evolved from a metaphor that had fallen into use within our team that described the process of creating a product increment as “turning the crank handle one whole time to produce a new version of the product”. Crank mechanisms are used to convert circular motion to reciprocating motion or vice versa.

Crank Mechanism
Example Crank Mechanism

As we turn the handle on our process, it converts the circular motion of an increment into the reciprocating motion of a release (A) and the feedback and validated learning (B) that the release brings.

Reduce Roles and Reduce Handovers

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.

Reason One

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.

Reason Two

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.

Evolution of Roles

rolesWhen we documented Cranked, we included just two roles:

  1. Business
  2. Technical

That’s it. Just the two.

This isn’t actually very controversial; it is simply the next step in an evolution of roles – as shown in the diagram in this article (you can click through to a larger version). The essence of the diagram is that in traditional software development there were a lot of roles. In Scrum, there were three and now we have two.

This is inspired by Extreme Programming and in particular, Kent Beck’s statement:

“Business people make business decisions and technical people make technical decisions.”

The obvious omission in Cranked when compared to Scrum is that there is no Scrum Master role. There are some good reasons for this. Firstly, the technical team must solve problems for themselves – they are all responsible for removing blockages and sometimes, mobbing the problem is the best way to get a result. The temptation to shovel problems to a Scrum Master to unblock is replaced with the self-empowerment of knowing that you are in charge of your own destiny. No room for learned-helplessness here. Secondly, a good Scrum Master actually eliminates their role over time – so having a permanent role titled “Scrum Master” creates a natural conflict of interest as to be great you must make yourself unemployed.

There are other important differences other than the lack of a Scrum Master. The technical team is cross-functional (very much as a Scrum team should be), but the job role and ideally the job title is “Technical Team Member”. Each individual may bring discreet skills to the team, but the endgame is to share those skills with other members of the technical team. The team must build, verify and release their software – no hand-offs, no “chucking it over the wall”.

And lastly… there is one more logical step that could be taken to reduce the roles even more. We will enjoy hearing about anyone who has done this. For now though, we have found two clearly defined roles to be just right.

Cranked Reading List

If you have read our book on Cranked and want to read further on the specific topics, the following map shows a recommend set of books that offer great insight into the fundamental aspects of Cranked.

The reading list works from the centre outwards, and you can work out along each node to find out more about the particular subject you are most interest in. The first-tier of books can form a recommended reading list for your team.

Reading List