If you’re not familiar with SCRUM, it is a very powerful set of principles and methods that empower teams to deliver increments of a product faster and in an iterative way. This means using short cycles of development while gathering constant feedback and adapting to eventual changes in product vision or customer needs.
I have been working with SCRUM for a few years now and, for me, always was one of those things that I could clearly see the value of using it but never took the time to dive deeper into the foundation and the principles behind it. So, a few months ago, when the startup where I work (Infraspeak) had the idea of creating a “book club” for the team, with the purpose of encouraging reading and knowledge sharing, I decided to change that.
This book, from Jeff Sutherland, is not exactly a straightforward technical book. And although it goes into good detail about the technical parts of SCRUM, they are presented to you through a series of stories and past experiences from the writer with the purpose of not only give you the ins and outs of SCRUM but also the foundations behind the principles and a few Ah Ah moments during its creation.
Due to this, the idea of this article is to extract those technical parts of the book and presents them here, in a summarized form.
Before We Start… Let’s Tell a SCRUM Joke
The book is written in a light tone and starts by telling an old joke that identifies the two different actors in the SCRUM process:
A chicken and a pig are walking down the road, and the chicken says:
Hey, Pig, I was thinking we should open up a restaurant.”
“What should we call it?”
“How about ‘Ham and Eggs’?”
“No thanks,” says the Pig. “I’d be committed, but you’d only be involved!
(The “pigs” are the developers and team that are generating the outcome of the project and the “chickens” are the stakeholders that are only being informed of the progress)
Let’s now dive a little into the concepts presented in this book:
When it comes to speed, most of the time, manpower is not the answer. If you’re not moving fast enough, focus on developing your team and your system instead of adding more people to the project.
One famous term in software development is the Brooks’s Law (book “The Mythical Man-Month”):
Adding manpower to a late software project makes it late
– Small teams get work done faster than big teams (Magic number is seven people with plus or minus two)
– Teams must be cross-functional and independent (They must have all the resources needed in the team and be autonomous to make decisions and move fast)
– Focus on team performance instead of individual performance
– Blaming is stupid. Look for the bad systems instead of looking for the bad people (Sometimes bad systems reward bad behaviors)
– Every sprint should finish with something that is testable and shippable to the costumers. This means:
– Plan wisely
– Challenges are motivators, impossible goals are just depressing
– If tasks are too big t break them down
– Half-done is not done! Everything that finishes the sprint “In progress” cost money and effort and didn’t produce any value.
– Sprint duration depends on the team and project, but the sweet spot is between two to four weeks
– Transparency is key!
– At any point in the sprint, everyone should be able to see what everyone else is working on and how their progress is going
Use the PDCA Loop
– Execute the Sprint
– Conduct Daily Stand-up Meetings
– Test what has been done
– Learn from what went good or bad
– Deploy new features
– Apply improvements to the cycle from the learnings obtained
Daily Stand Up Meeting
– Should not take more than 15 minutes
– Should answer these questions from all the team members:
– What did you do yesterday to help the team finish the Sprint?
– What will you do today to help the team finish the Sprint?
– What obstacles are getting in the team’s way?
(Of course, if for some reason, you choose a different periodicity to the meeting just change the “yesterday” to “since the last meeting” in the questions)
Scrum Master is not a Manager. Is more of a servant-leader, something between a team captain and a coach.
– Facilitates all the meetings
– Ensures there is transparency during the sprint
– Helps the team discover the bottlenecks and solve them
(Basically, it’s the person who makes sure the system is running in an effective way)
– Needs to give enough information about the who, what and why of the Story
– Should be short enough to be estimated and accomplished in the Sprint (But big enough to deliver value)
– If the Story is really too big, then it’s an Epic and it should be broken down into Stories for that Epic
– Every Story should have a “Definition of Done”
Plan Reality, Not Fantasy
How do you eat an elephant? One bite at a time.
– Break down your project into manageable tasks
– Write a “Definition of Done” for each of the tasks
– Estimate the effort every task will take
Size does matter, but only relatively.
Humans are terrible at estimating size, but they are actually good at estimating relative size. It’s easy to guess that a cow is heavier than a dog, but it’s harder to guess exactly the cow’s weight.
The “standard” is to use Fibonacci Sequence as scale and the Poker Planning technique to get the team’s estimation.
Is your Story Ready?
Are the stories you’re writing ready to be done? The INVEST mnemonic developed by Bill Wake shows the criteria that any story needs to meet to be ready:
– Independent – Not dependent of other stories to be done.
– Negotiable – You need to be able to change it if necessary.
– Valuable – It actually delivers value to a customer/stakeholder.
– Estimable – You need to be able to size it.
– Small – Small enough to fit the sprint. If not, break it. – Testable – Able to test and with a “Definition of Done”.
At the end of each sprint it’s important to evaluate how each team member feels about this Sprint, about what has been accomplished and the away the work was done.
And most important, how can they move faster and be happier in the next Sprint (happiness and productivity, normally, go hand in hand).
Continuous Improvement (Kaizen)
One way to do it is by asking the following question:
– What would one thing make you happier in the next Sprint?
From the answers of everyone, the team should choose one improvement (Kaizen) and make it a priority to be accomplished in the next Sprint – with acceptance tests.
– Can contains everything that can possibly be included in the product or just the next things to do but should have enough for the next few sprints.
– It’s important not to get caught in the desire of prioritizing all the roadmap in advance because that roadmap can and will change for sure.
– You should prioritize, but only the next things to do and not all of it.
– Has knowledge about the domain and knows the product inside-out and has close contact with the customers to gather feedback.
– Responsible for building the stories for the Backlog and keep them align with the product’s vision.
– Has the power to make decisions to change those stories and their priorities.
– Works close with the team to share his knowledge and help with decision making during the Sprint.
Use the OODA Loop
Prioritize (Product Vision)
“If you consider everything as a priority, then nothing is really a priority.”
– Use the 80/20 rule and find the features that deliver the most value with the lowest risk
Finally, besides the technical principles of SCRUM, the author gives a series of advice and takeaways from his stories and past experiences. Two of those stories really got my attention:
Stop the Production Line
Before Lean Manufacturing became a standard in the industry, Japanese companies (like Toyota) were producing cars three times faster and with half of the defects compared to European companies.
One of the main reasons for this difference was that, in Toyota, if a problem came up during the production, any worker had the power to stop the production line. And the other workers would just gather around to solve it right away.
Test Fast and Fix Right Away
Test things as soon as possible after they are done and fix the bugs right away when they are identified.
Some studies found that developers can take up to twenty-four times longer to fix a bug few weeks after they developed the code that if they would fix it right away with the code still fresh in their mind.