Presentation
Scrum, The Art of Doing Twice the Work in Half the Time, is written by
While Scrum started as a method to solve the gaping inefficiencies in software delivery, its principles are as applicable to any other business, team structure, and even individually.
In the book, Sutherland uses examples from his rich and diverse experience across military, corporate and personal life instances to drive home fundamental points about the ability to accommodate change, and he explains how these have been applied to great success by teams, individuals and businesses.
The central theme
Change is the sole certainty, but most plans are made to resist change, not accommodate it.
You should plan to a limit, then execute the plan, analyze what could be done better, and improve.
Essentially: Plan, Do, Check, Act - and repeat this process.
Who is this book for?
Foremost, it’s for team leaders across industries who wish to revamp their organization’s working style to maximize output and reduce inefficiencies.
A majority of examples are based on teams who did just that and used Scrum to achieve incredible levels of productivity.
Most of the big ideas can also be adapted by individuals who find themselves in the vicious loop of over-planning and under-implementing.
The big idea: “overplanning”
Back in the 70s, almost the entire world’s systems were broken.
Organizations used waterfall techniques where they first planned everything to the last detail, create impressive charts and documentations, and by the time it came to delivering the end product, it was overdue, over-budget, and most of the requirements had changed, rendering the effort all but useless.
The origin of scrum
Hesitation is death and one must Observe your environment, Orient yourself, Decide on a course of action and Act.
If it doesn’t work, you’ll know better next time. Scrum finds its origins in the Japanese concept of Shu Ha Ri - to master a skill, Shu - practice without deviation, then Ha - make innovations to improve the symptom, and finally Ri, when the action happens in a flow.
Scrum teams
- Teams should be transcendent and they should have a purpose larger than the goals and aims of each individual.
- They should be autonomous - managers set the goals. How they get to the goals is the team’s decision.
- Teams should be cross functional and team members should have knowledge of everyone’s roles, so that they can all think as a team, and not be solely responsible for their own set of tasks.
- The ideal size of teams should be 7, give or take 2 members, any larger and the team’s velocity goes down.
Time limits recommended in Scrum
Scrum follows a regular occurrence called sprints ie 2 weeks of work, characterised by a goal, and ending with a piece of working output, no matter how small.
Having a Daily standup where all team members are present ensures that everyone knows what everyone else is working on, blockers are removed.
Each team member should answer three questions:
- What did you do since we last met?
- What are you going to do till we meet again?
- What's getting in your way?
A standup should be no more than 15-20 min long for a team of 7.
‘Demo or die’ should be followed where every sprint must end with some working output that contributes to the end product
Waste
Waste is a crime. The three Mu’s in Scrum are:
- Muri - waste through unreasonableness
- Mura - waste through inconsistency
- Muda - waste through outcomes
Do something entirely, or don’t do it at all - half is as good as nothing done
Planning
You must plan, but plan reality, not fantasy. Refine the plan throughout the project rather than do it all up front.
Plan in just enough detail to deliver the next increment of value, and estimate the remainder of the project in larger chunks.
Organize by value to ensure that the feature that provides the maximum value to the product is prioritized. Use relative sizing to estimate tasks and features.
