Overall 9/10 - Highly engaging easily-read book for software developers.
Interesting book that uses a story about an IT manager getting promoted and being responsible for a team as a way to explain lean/agile concepts. Working in IT a relatively long period now I guess most the scenes are basically from somewhere I’ve worked which is nice that it’s realistic but perhaps shows the book would be more useful for those newer to software development.
The book covers a wide range of topics in varying levels of detail. While quite succcessfully tying them together into one story.
- Incompetent management - Few bad employees making trouble. USeful to hear of scenarios but characters were shallow though served their purpose.
- Issue prioritization - kanban and prioritize issues that fix the bottleneck only. Bill re-discovers kanban from manual post-it note creation. How to decide whether a project is worthwhile, the company projects should return >10% rate of return in time period.
- Releases - Bad change release procedures, continuous deployment
- Change Management - Allow all minor/low risk automatically, only monitor medium and require manual intervention of high risk items. Else you’ll never survive.
- SDLC/Kanban - Things are only done when deployed, anything else is WIP that should be avoided. Smaller iterations = lower risk
- One Genius - How to reduce reliance on 1/2 great developers and spread work over a team
- Types of Work - Business projects, Internal Projects, Changes and Unplanned Work! Last one is very dangerous as it throws off planning.
- Dev vs Ops - Shouldn’t be separate but working together.
- Teams - Need trust and mutual respect.
- Minimizing WIP is essential - Nice analogy of a factory with parts and Work In Progress building up showing how taht actually can slow progress.
Key Takeaways for Me
The Three Ways
- left to right flow of work - small batch sizes, never pass defects downstream and constantly optimize for global goals. Limit work in progress.
- right-to-left - have constant fast feedback to ensure to prevent problems. Stop the production line if going wrong.
- Foster a good culture - Encourage constant experimentation and risk taking. But understand that practice and repetition pre-requisite to mastery. High trust is essential.
Percent Busy and Waiting Times
We’ve all relied on a chain of people/teams or systems and wondered why simple changes take so long. This graph goes some way to explaining it:
Imagine a chain of 6 resources. If each resource is 95% occupied the waiting times between each one is significant. Only by having some less than 80% could you really ensure quick response times.
Forward Looking KPIs
Not sure the equivalent in IT but they have an interesting idea. If on-time delivery is a business KPI. Try to get a forward looking KPI that ensures the business deliverable. e.g. Median Time since Vehicle Maintenance - by ensuring regular maintenance, avoid breakdowns and help deliver business KPI. Are there similar forward looking KPIs on the IT side to ensure business value delivery?