Very useful – and surprisingly enjoyable book, filled with interesting stories with often unexpected outcomes. Highly recommend. The book is introducing “Scrum” a project management method that originated in software development and can be applied to different areas of business, and life. The method is superior comparing to the traditional “waterfall” methodology and allows to accomplish tasks faster with higher quality by empowering the team.
Notes from the book:
Government contractors sometimes have a curious business model: they under-bid on the contract, but build a clause requiring additional payment for any changes. As no plan is perfect, at the end the contractor is handsomely compensated for the effort. As a reaction to this practice, the client organization creates strict rules in attempt to limit changes. As a result, the final product may not meet the requirements as over time, the requirements has changed…
Scrum vendor might have a different approach. The vendor builds in the contract that the client can finish the project any time with payment of 20% of the remaining contract. In one case, after three development sprints, the client took the software early, as it was good enough. The result was beneficial for all: project ended up early and was cheaper for the client, and higher profit margin for the vendor.
How healthcare.gov was built:
- Design used scrum (worked)
- Back-end used waterfall (did not work)
- Fix of the back-end used scrum (worked)
Planning is useful; blindly following plans is stupid
Typically, planning does not work. And when it does, the requirements (needs) change and when the project is built, the stakeholders don’t want it anymore.
Difference in performance of teams are much more significant compared to the difference in individual performance.
Great teams are autonomous, cross-functional, and empowered with a transcendent purpose.
Characteristics of the best teams:
- Transcendent – purpose beyond the ordinary (decision to be great)
- Autonomous – self-organized and self-managing (have poser to make their decisions on how to organize their work)
- Cross-functional – have all skills needed to complete the project
Optimal size of the team is less than 9 people.
Adding manpower to the late software project makes it later
Organizational system, rather than individuals involved, is the main culprit in the outcomes (including human obedience to authority experiments).
Japanese manufacturer took over a GM plant with significant labor problems. The manufacturer re-hired all workers (but not the management) – labor problems disappeared.
Blame is stupid. Don’t look for bad people, look for bad systems that incentiveze bad behavior and reward poor performance.
Daily stand-up meeting (takes 15 minutes) – design to identify and remove obstacles. Scrum master asks three questions each team member:
- What have you done yesterday?
- What are you planning to do today?
- What obstacles do you see on the team’s way?
If you think you are good at multitasking, you are actually worse than average. Research shows that majority of participants judge themselves above average on their ability to multitask. People who multitask the most struggle with focusing.
Multitasking lowers IQ by 10 points (more for men than for women)
Key thing to remember – multitasking is stupid
Working too hard makes more work.
Estimation of difficulty of tasks – Fibonacci numbers. These numbers are distinctive enough to be able to define the “points” of task’s difficulty compared to other tasks. Humans are notoriously bad in trying to estimate time required for the task completion.
Happiness leads to success in every area of our lives (based on the research). Happiness precedes all other indicators. People are successful because they are happy rather than happy because of their success.
Performance improves even if people just a little bit happier.
After the team accomplished a sprint, the team reviews what went right, what can be done better, and what will be improved for the next sprint. The team is looking at the process, not assigning the blame.
Happiness metric: at the end of each sprint, each person answers questions on the scale 1-5
- How do you feel about your role at the company?
- How do you feel about the company as the whole?
- Why do you feel this way?
- What is one thing that can make you happier in the next sprint?
Everybody takes a turn to answer the question. Team takes one improvement and define how it can be measured.
Happiness metric is predictive. Financial metrics reflect the past.
To succeed, make everything visible and throw away the titles 🙂