Skip to main content

The three ways (2013)

The basics​

The three ways are a set of principles designed to improve the efficiency of software development projects. These principles are highly influenced by The Agile Manifesto, Lean UX and Kanban and are grouped into three main categories.

The First Way: Systems thinking and the principles of flow​

Move work from Business, through Development, to Operations, and ultimately to the Customer (where the value is created) as quickly as possible.

  • Use a board to make work visible.
  • Limit work in progress.
  • Reduce batch sizes.
  • Reduce the number of handoffs.
  • Identify and resolve constraints.
  • Eliminate things that do not add value

The Second Way: Feedback loops and the need for amplification​

Increase the feedback loops from right to left. Focus on increasing the number of feedback loops and their speed. Treat problems as opportunities to learn how to prevent them and create an ever safer and more resilient system instead of a cause for punishment and blame.

  • Increase causality.
  • Learn from your mistakes.
  • Swarm and fix.
  • Push quality closer to the source.
  • Prioritised non-functional requirements as highly as user features.

The Third Way: Creating a culture of continual experimentation and learning​

Developing and fostering a culture where constant experimentation and learning are encouraged and where people acknowledge that the way to mastery is through repetition and practice:

  • Enable organisational learning and safety culture.
  • Institutionalise the improvement of daily work.
  • Transform local discoveries into global improvements.
  • Make anti-fragility a habit.

Pros and cons​

The best thing about the three ways is that these principles leverage ownership within the development team to eliminate hostilities between technology disciplines such as frontend or backend development, testing, infrastructure, and site reliability engineering. The three ways also encourage implementing a high level of automation to prevent human errors, speed up the development feedback loops, increase anti-fragility and avoid repetitive tasks. The three ways can mitigate some inherent risks associated with developing technology products, particularly those associated with handovers and operations.

The bad thing about the three ways is that these principles are not a methodology. These principles are not prescript enough and are open to interpretation. As I have mentioned several times, not being prescript makes mainstream adoption much more complicated. However, the three ways and DevOps seem to have escaped this "curse", and today, they are mainstream in businesses of all sizes across the world. How did the three ways gain popularity despite being hard to implement? Two factors can explain the adoption of the three ways:

  • It is possible to get started as an individual developer. You will need company-wide buy-in to create a highly mature implementation of the three ways. However, you can begin by implementing automated tests or a deployment script without the management team's support. Your colleagues will experience some of the initial improvements and join the cause. Eventually, you and the rest of your team can attempt to convince your management team to support your initiative.

  • These principles are not prescript, but there is a lot of documentation about specific technologies that are closely related to these principles. The documentation about technologies such as Docker is highly prescript and facilitates the adoption of the three ways.