Accelerate

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.

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.

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.

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.

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.

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.

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

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.

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?

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.