The Phoenix Project

The Five Dysfunctions of a Team

1. An absence of trust, then, is the first dysfunction of a team. Leaders can get mired in conflict and chronic underperformance simply because there’s no trust. And there’s a trickle down effect: when leaders don’t trust each other, neither do teams. So how do you cultivate trust? Well, it starts with vulnerability, which is why Steve is leading a personal history exercise. Share where you come from and what drives you in order to model vulnerability. And then ask each person in the group to do the same.
2. Fear of conflict is the second dysfunction. Choosing artificial harmony over constructive, heated debate is an open road to nowhere. Candid discussions about contentious issues can be hard. They require leaders and teams to overcome ingrained behaviors – but embracing conflict can drive progress.
3. The third dysfunction is a lack of commitment. Especially when it comes to group decisions, fake buy-in introduces ambiguity and apathy into the company environment.
4. Avoiding accountability is the fourth dysfunction. Not taking responsibility and, conversely, not calling peers out for counteractive behavior both set low standards.
5. Finally, there’s inattention to results. When you put your own personal gains, status, or ego before the success of the team, it’s never a win-win situation.

The DevOps Principles - The Three Ways

Way 1 - Fast flow of work

A critical part of the First Way is creating a fast flow of work through Development and IT Operations. Instead of wasting time trimming to-do lists and reprioritizing commitments at weekly executive reviews, set up a kanban board.

To make a kanban board, create three columns on a wall: Ready, Doing, and Done. Label index cards with all the ongoing work activities, and place them in their respective columns. Now, here’s the kicker: limit the amount of Work In Progress, or WIP, to just four or five cards at a time. A key element of the First Way is reducing the number of moving parts. This allows the team to focus on and complete a small number of tasks quickly before moving on to the next. When a task is completed, move the card to its new placement. For example, when you start a task, move its card from Ready to Doing.

💡 Erik’s First Way focuses on the success of the entire system, as opposed to a specific department or silo of work

The bottom line is that until code is in production, no value is actually being generated – so removing needless work from the system is often more important than adding more in.

The less WIP, the more effective you’ll be.

Way 2 - Fix quality at the source to avoid rework

The Second Way entails fixing quality at the source to avoid rework.

💡 Shorter feedback loops to help identify and fix quality issues earlier in the process.

The goal is single-piece flow, or one unit of product flowing between the different processes. In other words, work on one piece at a time. By cutting out wait time between steps, you maximize throughput, limit WIP, and minimize errors.

In IT, single-piece flow can be achieved through the continuous delivery approach, which emphasizes three things:

1. Small batch sizes. Working in smaller batches allows you to quickly apply feedback loops and course-correct if needed.
2. Stopping the production line when problems crop up. That means not taking on any new work when builds, tests, or deployments fail.
3. Create fast, automated test suites to ensure that code is always ready to be deployed.

💡 Remember, code isn’t “done” when Development is done coding; it’s when code has been tested and is operating as designed.

❓ Aim for multiple deploys per day.

Way 3 - Create a culture of continuous experimentation, failure, and improvement

According to the Third Way, if you’re not getting better, you’re getting worse. There are three parts to this. The first is about experimentation. In order to beat competitors, you need to out-experiment them – so it’s important to encourage innovation and risk-taking.

❓ Create an environment in which it is safe to experiment - separate, but identical environments that can be developed on, safe knowing you won’t impact real customers.

The second part is about failure.

❓ Build for failure, and have process inciting failure in systems on purpose, purely for the purpose of testing how the system and the people *handle* the failure.

The third aspect involves putting the improvement of daily work over daily work. At Parts, all managers must improve something – anything – every two weeks. These so-called improvement kata cycles keep the system under constant pressure and force it to advance.