Book Review: Accelerate (Part 1)

G’Day Mate, how are you? I hope you’re having a beaut day today. My name’s Tammy Bryant Butow and you’ve stumbled across my Medium blog. Welcome, sit down, grab a coffee and let’s chat about a book called Accelerate. Get your copy of the Accelerate book.

The Accelerate Book

Accelerate was published in 2018 by Nicole Forsgren, Jez Humble and Gene Kim. The evidence collected prior to the release of the book refuted the bimodal notion in tech that you have to choose between speed and stability.

They discovered that speed actually depends on stability, so good tech practices give you both.

Speed actually depends on stability

The forward of this book is written by Courtney Kissler (CTO @ Zulily, Previously VP of Digital Platform Engineering @ Nike). It is a strong recommendation to adopt the practices that are outlined. You can find Courtney on Twitter here: https://twitter.com/chawklady

24 Capabilities

Accelerate identifies 24 capabilities that are classified into five categories:

1. Continuous Delivery
2. Architecture
3. Product and Process
4. Lean Management and Monitoring
5. Cultural

Focus on capabilities, not maturity

These capability categories were decided on after 4 years of research to investigate what capabilities and practices are important to accelerate the development of software, and in turn, value to companies. The 4 years of research included collecting thousands of survey responses from technology workers and publishing these in the form of State of DevOps reports.

Accelerate explains that the “key to successful change is measuring and understanding the right things with a focus on capabilities — not maturity. While maturity models are very popular in the industry, we cannot stress enough that maturity models are not the appropriate tool to use or mindset to have”.

Who is this book for?

Anyone working in a technology team, at any part of the journey to improving software delivery. This book is applicable for teams who have been on the transformation journey for years, for folks using newer methodologies like agile/lean, and for folks using waterfall.

Improvement is possible for everyone

Why is this book important?

As Accelerate explains, to remain competitive and excel in the market, organizations need to accelerate specific actions:

1. Delivery of goods and services to delight customers
2. Engagement with the market to detect and understand customer demand
3. Anticipation of compliance and regulatory changes that impact their systems
4. Respond to potential risks such as security threats or changes in the economy

A great example of this is that banks deliver value by trading faster, processing mortgages at lightning speed, keeping customer money safe but also available 24/7 via the internet (which requires excellent reliability and security). They are no longer focused on keeping gold bars in vaults and processing manual loans.

This book is also for CEOs — as explained in Accelerate, “47% of CEOs face pressure from their board to digitally transform”.

What are the success metrics?

Whenever I am reading a new book, I’m always curious to know what kind of success metrics could be gained from following the recommendations. In Accelerate they share the following metrics of success:

1. More frequent code deployment
2. Faster lead time from commit to deploy
3. Faster mean time to recover from downtime
4. Lower change failure rate

They also categorize this as tempo and stability and discovered that high-performing teams were able to achieve both.

• Tempo: deployment frequency and change lead time
• Stability: mean time to recover and change failure rate

Outcome vs Output

A successful measure of performance should focus on outcomes, not output. It shouldn’t reward people for busy work that doesn’t help achieve organizational goals.

What is lead time?

As Accelerate explains, “queue theory in math tells us that as utilization approaches 100%, lead times approach infinity — in other words, once you get to very high levels of utilization, it takes teams exponentially longer to get anything done.”

Lead time is a measure of how fast work can be done, it’s a productivity metric. “Lead time is the time it takes to go from a customer making a request to the request being satisfied”.

What are the metrics common amongst high performers?

In 2017 the surveys showed that high performers commonly achieved the following results:

• Deployment Frequency — On-Demand (multiple deploys per day)
• Lead Time for Changes — Less than one hour
• MTTR — Less than one hour
• Change failure rate — 0–15%

What about culture?

Accelerate shares the characteristics of Generative (Performance-Oriented) organisational culture:

• High cooperation
• Messengers trained
• Risks are shared
• Bridges are encouraged
• Failure leads to inquiry
• Novelty is implemented

The book discusses how important information is for culture. It shared the three characteristics of good information as determined by Westrum:

1. Information provides answers to the questions that the receiver needs answered
2. Information is timely
3. Information is presented in such a way that it can be effectively used by the receiver

How can continuous delivery (CD) improve tempo and stability?

There are a number of capabilities and cultural norms that will help accelerate software delivery and meet organizational goals:

• Version control
• Test automation
• Test data management
• Trunk-based development
• Shifting left on security
• Deployment automation
• Continuous integration
• Loosely coupled architecture
• Teams can choose their own tools
• Monitoring
• Proactive notification

What about architecture?

It’s commonly believed that certain types of architecture can limit your ability to improve and accelerate your software delivery — for example, the use of Mainframe. The Accelerate book shares that the research undertaken by the authors found that “high performance is possible with all kinds of systems, provided that systems — and the teams that build and maintain them — are loosely coupled.” This means that if it is possible to make changes to individual components or services as the operation grows, the team will be able to increase productivity as they scale.

What about testability and deployability?

Accelerate shares that there were two common statements among high-performers:

1. We can do most of our testing without requiring an integrated environment (Testability)
2. We can and do deploy or release our application independently of other applications / services it depends on (Deployability)

If your architecture does not allow testing and deploying services independently of each other, this will not enable teams to achieve higher performance.

Another interesting finding was that high performers are able to significantly increase the frequency of deploys as they add more engineers to their teams. Low performers actually decrease the frequency of deploys as they add more engineers.

What about tools? Can I pick my own?

The research done by the Accelerate authors showed that you should allow teams to choose their own tools. Tool choice is an important part of technical work — standardization can indeed be helpful but it’s better to focus on engineers adopting tools of their own free will. The focus should be on ensuring tools make life easier for the engineers that use them.

Allow teams to choose their own tools

Shifting left with security

In a past-life I worked as a Security Engineer at an Australian bank. I was in the CERT team (cyber emergency response team) which handles DDoS attacks, phishing, forensics and more. We also helped with scalable training of all engineers to make sure the code they wrote was written with security in mind. This is a common practice at banks due to the high-risk nature.

The Accelerate book shares that high-performing teams bake security into the earlier phases of the SDLC, it’s not a separate afterthought. “There should be easy-to-consume, preapproved libraries, packages, toolchains and processes available”.

Something banks do well— shifting left with security

What management technique works best to accelerate software delivery?

Lean Management and lightweight change management is the answer based on the research. The specific components of Lean Management that are important in this case are:

• Limiting WIP (work in-progress)
• Creating and maintaining visual displays showing key metrics (quality, productivity and an alignment with organisational goals)
• Using data from application performance and infrastructure monitoring tools to make business decisions on a daily basis.

In regards to lightweight change management the standard peer review process is much better than an external CAB or manager approval.

What about Lean Product Development? Should I be doing that?

Yes! The research done by the Accelerate authors showed that adopting specific Lean Product Development practices (as described in Eric Reis’ book) was “statistically significant in predicting higher software delivery performance and organizational performance, as well as improving organizational culture and decreasing burnout.”

The four specific practices are:

1. The extent teams slice up work into small batches that can be completed in less than a week and released frequently as MVPs
2. A good understanding of the flow of work from the business all the way through to customers — along with visibility into this flow (status of products and features)
3. Empowering developers to create and change specifications without requiring approval

How do we make work sustainable?

The Accelerate book shares insights into how work can be made sustainable to avoid brute force tactics or burnout. One of the most interesting findings is that reducing deployment pain (the anxiety that comes from shipping code to production) is one of the best ways to positively make work sustainable.

Certain Microsoft Teams shared that their work/life balance scores jumped from 38% to 75% after implementing continuous delivery technical practices. This makes a lot of sense, by improving the ability to deploy and reducing manual deployments they were able to get more time back for enjoying life.

Here are some specific practical recommendations based on the Accelerate findings:

• Implement comprehensive test and deployment automation
• Use continuous integration
• Use trunk-based development
• Shift left on security
• Effectively manage test data
• Use loosely-coupled architectures
• Enable developers to work independently
• Use version control for everything (code, config etc)

Thanks for reading — be sure to check out Part 2:

https://tammybutow.medium.com/book-review-accelerate-part-2-480b64edcba2