Key Takeaways from Scrum
I just reread Scrum: The Art of Doing Twice the Work in Half the Time by Jeff and J.J. Sutherland. It’s a great read, and I’d recommend the whole book, but here is a distillation of the most important messages in the book.
Key Takeaways
The old way of doing things doesn’t work
“The early step-by-step plans, laid out in comforting detail in Gantt charts, reassured management that we were in control of the development process — but almost without fail, we would fall quickly behind schedule and disastrously over budget.”
“Every project involves discovery of problems and bursts of inspiration. Trying to restrict a human endeavor of any scope to color-coded charts and graphs is foolish and doomed to failure. It’s not how people work, and it’s not how projects progress. It’s not how ideas reach fruition or how great things are made.”
“the best companies used an overlapping development process that was faster and more flexible. The teams were cross-functional. The teams had autonomy. They were empowered to make their own decisions. And they had a transcendent purpose. They were reaching for something bigger than themselves. Management didn’t dictate. Instead, executives were servant-leaders and facilitators focused on getting obstacles out of their teams’ way rather than telling them what and how to do product development.”
2. “Agile” dates to a meeting in 2001 where Jeff Sutherland and sixteen others drafted the “Agile Manifesto”
“It declared the following values: people over processes; products that actually work over documenting what that product is supposed to do; collaborating with customers over negotiating with them; and responding to change over following a plan. Scrum is the framework I built to put those values into practice. There is no methodology.”
3. It’s important to plan, but you should be flexible and able to adjust as circumstances and information changes
“Planning Is Useful. Blindly Following Plans Is Stupid”
“the key is to 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”
4. Get user feedback as quickly as possible and use that to iterate
“Work that does not produce real value is madness. Working product in short cycles allows early user feedback and you can immediately eliminate what is obviously wasteful effort.”
“Whenever you’re making something, you want to put it in the hands of those who are actually going to use it as fast as possible. You want to do this even before you make 20 percent of the features. You want to do this with something that delivers at least a tiny bit of value. I call this a “Minimum Viable Product,” or MVP. This should be the thing you show to the public for the first time. How effective does it have to be? Well, it should actually work, though to a person who has been working on it, it may seem kind of embarrassing”
“It’s almost laughably incomplete.
But what it gets you is feedback.”
5. Shu, Ha, Ri — learn the rules, master and innovate the forms, then discard the forms. Use Scrum as a method of understanding but once you understand the principles, do what works best
“In the Shu state you know all the rules and the forms. You repeat them, like the steps in a dance, so your body absorbs them. You don’t deviate at all.
In the Ha state, once you’ve mastered the forms, you can make innovations. Put an extra swing in your step down the dance floor.
In the Ri state you’re able to discard the forms, you’ve truly mastered the practice, and you’re able to be creative in an unhindered way, because the knowledge of the meaning of aikido or the tango is so deeply embedded in you, your every step expresses its essence.
Scrum is a lot like that”
“Any “process” that people use is wasteful, and that includes Scrum.”
6. Questions for Daily Stand-up
“What did you do since the last time we talked? What are you going to do before we talk again? And what is getting in your way”
7. The Scrum Master should impartially advocate for team improvements
“The key part of that was to realize that often the impediments aren’t simply that the machine doesn’t work or that Jim in accounting is a jerk — it’s the process itself. It was the Scrum Master’s job to guide the team toward continuous improvement — to ask with regularity, “How can we do what we do better?”
8. Done means useful to someone
“nothing gets moved to Done unless it can be used by the customer. In other words, you can drive the car. And if someone drives the car and says, “Hey, the turn signals are sticking,” that problem is dealt with in the next Sprint.”
“everyone on the team, not only the compliance people, had to work to meet that level of quality first, before moving on to the next item. The amount of rework this removes from a project is incredible. I call this standard that must be met a “Definition of Done.” Everyone knows when something is done or not; there are clear standards that any piece of work has to meet”
9. Context switching slows people down, focus intensely on one thing at a time
“They don’t change how big the project is, or what’s involved in creating it, but just by doing one thing exclusively before moving on, the work takes a little more than half as much time. Half.”
“Imagine (or, if you’re unfortunate, remember) having five tasks partially done. You’ve painted one wall of the bathroom, the dog food is still in the trunk, the mortgage check has been written but not mailed, and the leaves are piled up but not bagged. You’ve expended effort but haven’t created any value. The value arrives when the drop cloths and paint cans are out of the bathroom, the dog has been fed, the bank gets its money, and the yard is actually clear of leaves. Doing half of something is, essentially, doing nothing.”
10. Avoid decision fatigue
“there’s a limited number of sound decisions you can make in any one day, and as you make more and more, you erode your ability to regulate your own behavior”
11. Retrospective meeting is the key to the flywheel of better team performance in Scrum
“After the team has shown what they’ve accomplished during the last Sprint — that thing that is “Done” and can potentially be shipped to customers for feedback — they sit down and think about what went right, what could have gone better, and what can be made better in the next Sprint. What is the improvement in the process that they, as a team, can implement right away?
To be effective, this meeting requires a certain amount of emotional maturity and an atmosphere of trust. The key thing to remember is that you’re not seeking someone to blame; you’re looking at the process. Why did that happen that way? Why did we miss that? What could make us faster? It is crucial that people as a team take responsibility for their process and outcomes, and seek solutions as a team.”
12. The Product Owner (Product Manager) must prioritize the highest value items in each sprint
“The questions you need to ask are: what are the items that have the biggest business impact, that are most important to the customer, that can make the most money, and are the easiest to do? You have to realize that there are a whole bunch of things on that list that you will never get to, but you want to get to the things that deliver the most value with the lowest risk first”
“The Scrum Master and the team are responsible for how fast they’re going and how much faster they can get. The Product Owner is accountable for translating the team’s productivity into value.”
“Scrum aligns everyone’s interests: those of the team, the Scrum Master, the Product Owner, the customer, and the company. Everyone works toward the same goal and with the same vision: deliver real value as fast as possible. I’m a big believer in win-win situations, and making more money delivering better products at a lower price strikes me as a pretty good deal.”
Mnemonic Devices / Acronyms / Initialisms
SMART — Goals should be: Specific, Measurable, Attainable, Relevant, and Time-bound
“They’ve dubbed their new approach SMART — Specific, Measureable, Attainable, Relevant, and Time-bound. In other words, they want to use Scrum. And, in fact, they are.”
2. OODA —When confronting a problem: Observe, Orient, Decide, and Act
“I credit this to the training I got from the Air Force on how to control risk. That training taught me to do four things: Observe, Orient, Decide, and Act. Specifically, I would observe the target area, figure out the best path into the hot zone and the best path out, orient myself in the face of unexpected events, and then act decisively based on instincts and hardwiring. Hesitation could get pilots killed, but so did foolhardiness.”
3. PDCA — Plan, Do, Check, and Act
“the method to take action, and perhaps what Deming is most famous for, is the PDCA cycle (Plan, Do, Check, Act). You can apply this cycle to the production of just about anything, be it a car, a videogame, or, heck, even a paper airplane”
“He used the Japanese words: Muri, waste through unreasonableness; Mura, waste through inconsistency; and Muda, waste through outcomes. These ideas are highly aligned with Deming’s PDCA cycle, which I wrote about earlier: Plan, Do, Check, Act. Plan means avoid Muri. Do means avoid Mura. Check means avoid Muda. Act means the will, motivation, and determination to do all that”
4. INVEST — Stories must be: Independent, Negotiable, Valuable, Estimable, Small, and Testable
“Independent. The story must be actionable and “completable” on its own. It shouldn’t be inherently dependent on another story.
Negotiable. Until it’s actually being done, it needs to be able to be rewritten. Allowance for change is built in.
Valuable. It actually delivers value to a customer or user or stakeholder.
Estimable. You have to be able to size it.
Small. The story needs to be small enough to be able to estimate and plan for easily. If it is too big, rewrite it or break it down into smaller stories.
Testable. The story must have a test it is supposed to pass in order to be complete. Write the test before you do the story.”
Examples of Scrum Use
Government
FBI database — previously project has floundered for nearly a decade and hundreds of millions of dollars, complete on time and under budget
Front end and fixing healthcare.gov but not original backend which failed
Special Forces post 9/11
Jay Inslee administration in Washington
Icelandic constitution
Business
Jeff Sutherland developed it first creating the first ATM network for MidContinent
Jeff Sutherland implemented at PatientKeeper
“After I left PatientKeeper, a new management team decided Scrum wasn’t the best way to run things anymore. The result? Product releases dropped from forty-five a year to two, revenue dropped from fifty million dollars a year to twenty-five, and attrition, which had been less than 10 percent, shot up to over 30 percent. They went from a great company back to mediocre performance by returning to traditional corporate behavior.”
Deming brought the principles from the US to Japan during post WWII reconstruction, including inspiring Sony and Toyota
Toyota makes cars in 17 hrs with 34 defects per 100 while BMW/Audi take 57 hours with 79 defects
Sales Force went from 1 to 3 major releases per year after implementing scrum
Zappos — 1.6 MM rev 2000 to $1 BN+ in 2008, 124% CAGR
Valve — complete freedom but a lot of projects choose to work in scrum.
Media
J.J. Sutherland implemented for NPR coverage of Tahrir Square
Personal
Remodeling a house in 6 weeks vs 3 months down the block with same group of contractors but not leveraging Scrum
Education
Dutch Chemistry class where kids work on scrum teams to learn the material and complete projects demonstrating the knowledge every sprint