Books for software engineers and managers

Accelerate

Building and Scaling High Performing Technology  Organizations

by Nicole Forsgren, Jez Humble, Gene Kim

Categories:
Favorite,
CTO,
Engineering Manager,
Tech Lead,
Startup Founder

The 4 measures of software delivery  performance

Software engineering has long struggled to identify both team and individual performance metrics. While we still don’t have quality metrics at the individual level, the authors of Accelerate do offer four team-level metrics for evaluating performance:

  1. Deployment frequency: How often does your team deploy?
  2. Lead time for changes: How much time exists between a customer submitting a request and that request being fulfilled in production?
  3. Mean time to recovery (MTTR): How much time does it take to recover from system failure?
  4. Change failure rate (CFR): How often do you need to revert your changes?

I will be writing deployment frequency this quite a bit in future articles as I’ve experienced it the most useful and practical of the four metrics to measure and implement.

Work in small  batches

If there is a secret sauce to software delivery performance, it’s working in small batches.

At TrainHeroic, we measure batch size using tickets per release. Two years ago, we averaged +10 tickets per release. Today, we average 1.25 tickets per release.

With smaller batches, we effectively deliver value to our customers earlier. But not just earlier and more frequently. We’re also delivering more total value with small batches:

  • 330% increase in deployment frequency per engineer
  • 89% increase in ticket completion per engineer

In other words, our engineering team is about 2x as effective as it previously was.

The gap between high and low performing teams remains  significant

While many software engineering teams have improved performance, many still lag behind.

Anecdotally this data also reflects my experience interviewing candidates. Many engineers work on teams with monthly or quarterly release schedules. In other words, terribly low deployment frequency and very high lead time for changes.

Focus on fixing the environment, not fixing  people

People are a product of their environment. Assuming a reasonable competency and skill level, team culture and environment matter more than individual skill.

Fixing the environment touches both technical and non-technical areas and usually they sound like principles:

  1. Releasing should be fun
  2. Deploy to production on day one
  3. Every engineer deploys to production
  4. Automated tests should be fast
  5. Culture is what you celebrate and tolerate
  6. Drive down tickets per release
  7. Find your limiting factor for deployment frequency
  8. … And many more that I will be writing about in subsequent articles

Fundamentally, these principles focus on improving the environment. They’re about making work possible.

Velocity and utilization are poor proxies for  performance

I’ve never heard a coherent and rational description for velocity yet the tech industry adopted it out of desperation, Agile religion, or both.

Utilization on the other hand inherently makes sense. Factories use production machines and we want those machines to be fully utilized. Translating the metaphor to humans is easy, particularly when we start referring to those humans as “resources.” Yes, make sure the resources are fully utilized.

Well, turns out utilization isn’t great either in software development because creativity and productivity require slack time.

Given reasonable baseline knowledge, who is on the team matters less than how the team interacts and  behaves

That is to say, you are probably better off hiring the solid engineer with great people skills than the smarter engineer with poor people skills.

10x teams are not built on 10x programmers.

To change culture, first change how people behave not how they  think

When driving change, focus on the environment and behaviors first. Hearts and minds will follow with success.

Teams that embrace continuous delivery identify more closely with the  organization

When your team is constantly shipping code to production, people feel proud of their work and impact. That pride turns into affinity for the organization.

Conversely, if you’re only delivering once per month or quarter then you’re leaving big windows for employees to disconnect from the organization.

Autonomy and minimal dependencies are the biggest contributors to continuous  delivery

The authors provide specific details, but the biggest contributors to continuous delivery can be summed up under autonomy and minimal dependencies.

Can I do my work without asking permission?

Can I do my work with minimal communication and coordination?

Employees at high-performing orgs are 220% more likely to refer  candidates

This feels obvious when stated in reverse – employees at poorly performing organizations are far less likely to refer candidates.

From a manager’s perspective, an employee referring a friend or past coworker offers confirmation that things are going well.

Accelerate

How strongly do I recommend Accelerate?
10 / 10

Every engineering leader on your team should read and discuss Accelerate.

While Accelerate does not provide how-to implementation details, it does provide the framework for understanding and measuring software delivery performance.