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.
- 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
- Level 1 – Things we just know
- Level 2 – Culture – We can debate these within the team, e.g. importance of security
- Level 3 – Written artifacts and established processes
- Pathological – based on power
- Bureaucratic – based on rules
- Generative – based on performance
- Build quality in
- Work in small batches
- Automate repetition
- Relentlessly pursue continuous improvement
- Everyone is responsible
- Comprehensive config management
- Continuous Integration – Small daily branch merges
- Continuous Testing
- Version control
- Test Automation
- Test data management
- Trunk based development
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.
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
- 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
- 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
- Value conflicts
- Vision – Clear understanding of where to be in 5 years
- Inspiring Communication – Says things that make employee proud to be aprt 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:
- 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.
- 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.
- The importance of loosely-coupled architecture gives me a clearer way to conceptualise interactions between teams and why it’s important. (limited bandwidth)