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.
Top Ideas in This Book
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:
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:
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:
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.