The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

Here are some of my favourite lines in the book.

"Who is on a team matters less than how the team members interact, sturcture their work, and view their contributions."

• Google did a research to find out if there were traits that made their teams high performers. But this was what they found instead.

"Continuous delivery predicts lower change fail rates, unplanned work and rework."

• High performers spend 49% of their time focusing on new work, vs 38% for low performers.

• High performers spend 21% of their time on unplanned work and reworks, vs 27%.

The authors do explain how they quantify high and low performers and the data collection methodology in the book.

"Developing off the master (vs long-lived branches) correlated with higher delivery performance".

"Teams that have fewer than three branches (less than a day each) had better delivery"

This reinforces that pushing small changes frequently does improve productivity. Focusing on one small thing at a time gives developers more attention to the task at hand before moving on to the next.

"High performers were more likely to incorporate infosec into the delivery".

"Shift left" on security - build it in rather than build it later.

That being said, you pay taxes on having the infosec team review the build during development.

"Low performers were more likely to say that a software was custom by a third-party (vendor, outsourcing)."

"Low performers were more likely to be working on mainframes."

"Mainframe integration and system type (packaged software - aka SaaS, new software - aka Greenfield) was not correlated with delivery performance."

I suppose that's one reason CIOs are shifting toward building in-house. You ship the code, you support it.

"As number of developers increased, high performers deployed exponentially frequently, but low performers' deployment frequency dropped."

Perhaps a reflection of how organizations grow their teams and what to expect.

"Allowing teams to choose their own tools contributes to delivery performance."

The only downside to be aware of is non-standardization.

"Debugging problems with someone else's code get harder unless there's a universal sandbox for every service."

"Architects should collaborate closely with engineers who build the system."

Gather feedback on what matters to them. At the end of the day, engineers supports the system, not the architects. People first, tools and tech stacks become secondary.

The next one's my favourite. Effect of change approval was assessed across 4 conditions:

1. All production changes require approval.
2. Only high-risk changes require approval.
3. Only peer review required for changes.
4. No change approval process.

These were the findings.

"Approval for high-risk changes was not correlated to delivery performance."

"Peer reviews or no change approvals achieved higher delivery performance!"

"External approvers (someone not related to the dev process) achieved lower performance."

Couple these findings with high velocity frequent releases and you get a pretty good idea of a high performing team.

That being said the authors' recommendations are:

"Lightweight change approval or peer reviews with the capability to reject bad changes."

Moving on to experimentation.

"Teams that experiment without requiring approval predicted profitability, productivity, and market share."

But it's not a blank cheque to work on other projects. Experimentation should be coupled with visibility, customer feedback, and done in small batches.

"People who feel supported by their superiors, have the right tools, and feel their judgement is valued perform better at their jobs."

Reinforcing almost every organizational psych literature out there. Desirable but surprizingly challenging to execute.

"Investment in DevOps highly correlated with delivery performance."

"High performers performed 26% of deployments manually compared to 43% for low performers."

"High performers perform 48% of change approvals manually compared to 59% for low performers."

The cost of automation will be high in the beginning, but eventually pays off over time.

This is what it means to have continuous delivery:

1. Build quality in, not after.
2. Work in small batches.
3. Computers for routine tasks, people for problem solving.
4. Shared responsibility.

Lean management practices:

1. Limit WIP (reduces tech debt).
2. Create visual displays for productivity feedback.
3. Use data from app monitoring for decisions.

The book title is Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, Gene Kim.