Accelerate -The Science of Lean Software and Devops – Book

Overall 8/10 – Good book that presents good ideas and clear evidence for why.
I was aware of slightly over half the best practices from this book but not all of them have been adopted by large firms. I picked up a few actions I’d take away but really the usefulness in this book may be in presenting it as evidence to try and drive change in others.

Book Notes:

Measuring Performance:

• Use capabilities to measure performance not maturity levels as maturity suggests mission complete.
• (Scrum) Velocity is only a capacity planning tool
• Utilization isn’t the correct measure, it should not be 100%
• Should measure global outcome to ensure teams are not pitted against each other
• Software Delivery Performance Depends on:
  • Lead time
  • Deployment Frequency
  • Mean Time To Restore
  • Change Fail %

Measuring and Changing Culture

• Don’t try to change how people think, first change what people do (or change the people :))
• Westnam Theory: Orgs with better information flow function more effectively

1. Level 1 – Things we just know
2. Level 2 – Culture – We can debate these within the team, e.g. importance of security
3. Level 3 – Written artifacts and established processes

Culture Types:

1. Pathological – based on power
2. Bureaucratic – based on rules
3. Generative – based on performance

Continuous Delivery

Key Principles

1. Build quality in
2. Work in small batches
3. Automate repetition
4. Relentlessly pursue continuous improvement
5. Everyone is responsible
6. Foundations:
   1. Comprehensive config management
   2. Continuous Integration – Small daily branch merges
   3. Continuous Testing

What Works:

• Version control
• Test Automation
• Test data management
• Trunk based development

Architecture

Goal is loose coupling to ensure bandwidth between teams isn’t swamped with implementation details.

Can the team by itself without speaking to outsiders:
– Change architecture significantly
– Do a deployment? now? during business hours? anytime?

Critical = Tesability and Deployability
Systems are loosely coupled and can be developed and validated independently.

Management Practices

Components of Lean Management

• Limit work in progress
• Visual Management
• Feedback from production
• Lightweight change approvals

CAB – doesn’t work to increase stability!
External approvals are negatively correlated with lead time, deploy freq. and restore time.
Lean Management <-> Software delivery performance, becomes a virtuous cycle.
Lean: Build -> Measure -> Learn

Capabilities

• Small batches
• flow of work from requirements to user known by team
• Actively seek user feedbck
• Authority to create/change specs during dev without approval

Sustainable

• Invest in employee development
• Foster supportive work environment (no blame)
• Ask employees what’s preventing them from achieving their objectives
• Give time to experiment and learn

Factors Causing Employee Burnout:

• Work overload
• Lack of control
• Insufficient rewards
• Community breakdown
• Unfairness
• Value conflicts

Transformational Leadership

• Vision – Clear understanding of where to be in 5 years
• Inspiring Communication – Says things that make employee proud to be part of org
• Intellectually Stimulates – Challenges my assumptions, makes me rethink principles
• Supportive – Considers and acts to benefit my feelings
• Personal Recognition – Commends me when I do a good job

 

Key Takeaways for Me:

1. Most the suggestions from other books I’ve read and that I had seen work myself were correct. The large survey conducted by these authors gives me the evidence to back up my opinions.
2. Action: In my current work, we need to find a way to get the 3 critical measurements improved. Increased release frequency and lower overhead change management would seem to be the highest effort/reward.
3. The importance of loosely-coupled architecture gives me a clearer way to conceptualise interactions between teams and why it’s important. (limited bandwidth)