SCRUM by Jeff Sutherland

• The only problem with them is that they are always, always wrong.
• We gave up on trench warfare, but somehow the ideas that organized it are still popular.
• For reasons I’ll get into further in future chapters, I called this framework for team performance “Scrum.” The term comes from the game of rugby, and it refers to the way a team works together to move the ball down the field. Careful alignment, unity of purpose, and clarity of goal come together. It’s the perfect metaphor for what I want teams to do.
• Traditionally, management wants two things on any project: control and predictability. This leads to vast numbers of documents and graphs and charts, just like at Lockheed. Months of effort go into planning every detail, so there will be no mistakes, no cost overruns, and things will be delivered on schedule.
• 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.
• Scrum embraces uncertainty and creativity.
• At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.
• No one should spend their lives on meaningless work. Not only is it not good business, it kills the soul.
• Often people simply say that everything is important.
• In software development there is a rule, borne out by decades of research, that 80 percent of the value in any piece of software is in 20 percent of the features.
• Making people prioritize by value forces them to produce that 20 percent first. Often by the time they’re done, they realize they don’t really need the other 80 percent, or that what seemed important at the outset actually isn’t.
• Eliminating waste must be a business’s first objective.
• For Scrum to really take off, someone in senior management needs to understand in his bones that impediments are nearly criminal.
• Suffice it to say here that the effect of eliminating waste is dramatic, but people often don’t do it, because it requires being honest with themselves and with others.
• The world is constantly getting more complicated, and the work we do is gaining in complexity at an ever-increasing rate.
• Whenever people are involved in a complex, creative effort, whether they’re trying to send a rocket to space, build a better light switch, or capture a criminal, traditional management methods simply break apart.
• What Scrum does is bring teams together to create great things, and that requires everyone not only to see the end goal, but to deliver incrementally toward that goal.
• Just because everyone has always told you that’s the way the world works doesn’t mean they’re right.
• Planning Is Useful. Blindly Following Plans Is Stupid. It’s just so tempting to draw up endless charts. All the work needed to be done on a massive project laid out for everyone to see—but when detailed plans meet reality, they fall apart. Build into your working method the assumption of change, discovery, and new ideas.
• Inspect and Adapt. Every little while, stop doing what you’re doing, review what you’ve done, and see if it’s still what you should be doing and if you can do it better.
• Change or Die. Clinging to the old way of doing things, of command and control and rigid predictability, will bring only failure. In the meantime, the competition that is willing to change will leave you in the dust.
• Fail Fast So You Can Fix Early. Corporate culture often puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users. 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.
• Years later it occurred to me that organizations, teams, and people are all complex adaptive systems.
• “The first thing we need to do is to stop doing stuff that is killing us.”
• After my first career in the military and my second in academia, I found myself something of an outsider in business. But that outsider’s perspective was one of my most valuable assets.
• From day one, it was a mystery to me why people insist on working in ways they know are inefficient and wasteful and that are dehumanizing and depressing. I guess they figure that’s the way everyone does it, so it must be the best way.
• Scrum teams that work well are able to achieve what we call “hyperproductivity.”
• The basic idea is to measure exactly what is being done, and how well, and to strive for “continuous improvement.” Don’t just get better once; get better constantly.
• Always be looking for something to improve.
• Scrum, like aikido, or, heck, like the tango, is something that you can only really learn by doing.
• Hesitation Is Death. Observe, Orient, Decide, Act. Know where you are, assess your options, make a decision, and act!
• Look Outward for Answers. Complex adaptive systems follow a few simple rules, which they learn from their environment.
• Great Teams Are. They are cross-functional, autonomous, and empowered, with a transcendent purpose.
• Don’t Guess. Plan, Do, Check, Act. Plan what you’re going to do. Do it. Check whether it did what you wanted. Act on that and change how you’re doing things. Repeat in regular cycles, and, by doing so, achieve continuous improvement.
• Shu Ha Ri. First, learn the rules and the forms, and once you’ve mastered them, make innovations. Finally, in a heightened state of mastery, discard the forms and just be—with all the learning internalized and decisions made almost unconsciously.
• Teams are what get things done in the world of work.
• On all great teams, it’s left to the members to decide how to carry out the goals set by those leading the organization.
• One of the key concepts in Scrum is that the team members decide themselves how they’re going to do the work.
• The third leg of the stool for great teams is that they have all the skills necessary to get things done.
• The team dynamic only works well in small teams.
• The classic formulation is seven people, plus or minus two, though I’ve seen teams as small as three function at a high level.
• That very large groups do less seems to be an ironclad rule of human nature.
• the research is fairly clear that we can only remember four “chunks” of data.
• The number of communication channels increases dramatically with the number of people, and our brains just can’t handle it.
• Keep your teams small.
• we’re all creatures of the system we find ourselves embedded in.
• Greatness can’t be imposed; it has to come from within. But it does live within all of us.
• Pull the Right Lever. Change Team performance. That has much more impact—by several orders of magnitude—than individual performance.
• Transcendence. Great teams have a purpose that is greater than the individual; e.g., burying General MacArthur, winning the NBA championship.
• Autonomy. Give teams the freedom to make decisions on how to take action—to be respected as masters of their craft. The ability to improvise will make all the difference, whether the unit is reporting on a revolution in the Middle East or making a sale.
• Cross-functional. The team must have every skill needed to complete a project, whether the mission is to deliver Salesforce.com software or capture terrorists in Iraq.
• Small Wins. Small teams get work done faster than big teams. The rule of thumb is seven team members—plus or minus two. Err on the small side.
• Blame Is Stupid. Don’t look for bad people; look for bad systems—ones that incentivize bad behavior and reward poor performance.
• Time is the ultimate limiter of human endeavor, affecting everything from how much we work, to how long things take, to how successful we are.
• We’re lousy focusers, we spend far more hours in the office than needed, and we’re horrible estimators of how long things will take.
• The sooner you give things to your customers, the quicker they can tell you if you’re making something they need.
• An important point: nothing gets moved to Done unless it can be used by the customer.
• The Scrum Master, the person in charge of running the process, asks each team member three questions:
• 1. What did you do yesterday to help the team finish the Sprint?
• 2. What will you do today to help the team finish the Sprint?
• 3. What obstacles are getting in the team’s way? That’s it. That’s the whole meeting. If it takes more than fifteen minutes, you’re doing it wrong.
• It has to be at the same time every day, with the same three questions, with everyone standing up, and last no more than fifteen minutes.
• My standard speech to teams large and small is: “Do you really want to suck forever? Is that what your motivation is in life? Because it’s a choice, you know—you don’t have to be that way.” A team has to demand greatness from itself.
• What Scrum does is alter the very way you think about time.
• Time Is Finite. Treat It That Way. Break down your work into what can be accomplished in a regular, set, short period—optimally one to four weeks. And if you’ve caught the Scrum fever, call it a Sprint.
• Demo or Die. At the end of each Sprint, have something that’s done—something that can be used (to fly, drive, whatever).
• Throw Away Your Business Cards. Titles are specialized status markers. Be known for what you do, not how you’re referred to.
• Everyone Knows Everything. Communication saturation accelerates work.
• One Meeting a Day. When it comes to team check-ins, once a day is enough. Get together for fifteen minutes at the Daily Stand-up, see what can be done to increase speed, and do it.
• Rhythm is deeply important to human beings.
• We’re human; we make mistakes. How you deal with those mistakes can have an extraordinary impact on how fast you can get things done, and at what level of quality.
• The human mind has limits. We can only remember so many things; we can really only concentrate on one thing at a time.
• The peak of productivity actually falls at a little bit less than forty hours a week.
• Overworked employees get more distracted and begin distracting others. Soon they’re making bad decisions.
• Who cares how many hours someone worked on something? All that matters is how fast it’s delivered and how good it is.
• Don’t be an asshole—and don’t allow, abet, or accept that behavior in others.
• What Scrum does is focus us on trying to eliminate the pointless waste that seems part and parcel of work.
• Multitasking Makes You Stupid. Doing more than one thing at a time makes you slower and worse at both tasks. Don’t do it. If you think this doesn’t apply to you, you’re wrong—it does.
• Half-Done Is Not Done. A half-built car simply ties up resources that could be used to create value or save money. Anything that’s “in process” costs money and energy without delivering anything.
• Do It Right the First Time. When you make a mistake, fix it right away. Stop everything else and address it. Fixing it later can take you more than twenty times longer than if you fix it now.
• Working Too Hard Only Makes More Work. Working long hours doesn’t get more done; it gets less done. Working too much results in fatigue, which leads to errors, which leads to having to fix the thing you just finished. Rather than work late or on the weekends, work weekdays only at a sustainable pace. And take a vacation.
• Don’t Be Unreasonable. Goals that are challenging are motivators; goals that are impossible are just depressing.
• No Heroics. If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.
• Enough with the Stupid Policies. Any policy that seems ridiculous likely is. Stupid forms, stupid meetings, stupid approvals, stupid standards are just that—stupid. If your office seems like a Dilbert cartoon, fix it.
• No Assholes. Don’t be one, and don’t allow the behavior. Anyone who causes emotional chaos, inspires fear or dread, or demeans or diminishes people needs to be stopped cold.
• Strive for Flow. Choose the smoothest, most trouble-free way to get things done. Scrum is about enabling the most flow possible.
• As I’ve said previously, the very act of planning is so seductive, so alluring, that planning itself becomes more important than the actual plan. And the plan becomes more important than reality. Never forget: the map is not the terrain.
• Plan in just enough detail to deliver the next increment of value, and estimate the remainder of the project in larger chunks.
• The numbers in the Fibonacci sequence are far enough apart that we can easily tell the difference. It’s easy for people to come down on one side or the other. If one person estimates something as a five, and another as an eight, we can intuitively see the difference. But the difference between a five and a six? That’s pretty subtle, more than our brains can really register.
• Our minds don’t work in smooth increments. We’re better at perceiving jumps from one state to another—and not smooth jumps but jagged ones.
• People think in narratives, in stories. That’s how we understand the world. We have an intimate grasp of characters, desires, and motivations.
• When you’re writing stories or making a list of work to be done, it’s important to ask two questions: Is the story ready? And how will you know when it’s done?
• There is a mnemonic I always use to tell whether a story is ready. It was created by Bill Wake, who’s a deep thinker on software design. Bill says that for any story to be ready it needs to meet the INVEST criteria:
• 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.
• Also once you have your velocity, you can figure out the most important thing in Scrum: what is keeping you from going faster? What is keeping you from accelerating?
• Changing that culture, though, is what allows true excellence to emerge.
• The Map Is Not the Terrain. Don’t fall in love with your plan. It’s almost certainly wrong.
• Only Plan What You Need To. Don’t try to project everything out years in advance. Just plan enough to keep your teams busy.
• What Kind of Dog Is It? Don’t estimate in absolute terms like hours—it’s been proven that humans are terrible at that. Size things relatively, by what breed of dog the problem is, or T-shirt size (S, M, L, XL, XXL), or, more commonly, the Fibonacci sequence.
• Ask the Oracle. Use a blind technique, like the Delphi method, to avoid anchoring biases such as the halo effect or bandwagon effect or just plain stupid groupthink.
• Plan with Poker. Use Planning Poker to quickly estimate work that needs to be done.
• Work Is a Story. Think first about who’ll be getting value from something, then about what it is, and then why they need it. Humans think in narratives, so give them one. As an X, I want Y, so that Z.
• Know Your Velocity. Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down.
• Velocity × Time = Delivery. Once you know how fast you’re going, you’ll know how soon you’ll get there.
• Set Audacious Goals. With Scrum it is not that hard to double production or cut delivery time in half. If you do it in the right way, your revenue and stock price should double as well.
• People want to be happy. Not happy in a complacent, sheeplike way, but in a way that is more active.
• Scrum done in the right way will make workers, customers, managers, and stockholders happy (usually in that order).
• “We are not rewarded for enjoying the journey itself but for the successful completion of a journey. Society rewards results, not processes; arrivals, not journeys.”
• Most of our days are taken up with striving toward our goals, whatever they may be.
• The research is startlingly clear. Happy people simply do better—at home, at work, in life. They make more money, they have better jobs, they graduate from college, and they live longer. It’s quite remarkable. Almost universally they’re just better at what they do.
• Happiness leads to success in nearly every domain of our lives, including marriage, health, friendship, community involvement, creativity, and, in particular, our jobs, careers, and businesses.
• “Study after study shows that happiness precedes important outcomes and indicators of thriving.”
• People aren’t happy because they’re successful; they’re successful because they’re happy. Happiness is a predictive measure. And performance improves even if people are only a little bit happier.
• Perfection can never be reached, of course, but every increment in that direction counts.
• What are the things that actually make people happy? They’re the same things that make great teams: autonomy, mastery, and purpose. Or to say it more expansively, it’s the ability to control your own destiny, it’s the feeling that you’re getting better at something, and it’s knowing that you’re serving something bigger than yourself.
• Managers should also have zero tolerance for incivility and never allow an employee to poison corporate culture through abuse or disrespect.
• The “Wise Fool” is the person who asks uncomfortable questions or raises uncomfortable truths. These workers aren’t always easy to have around, since they can be seen as troublemakers or not part of the team, but they need to be cultivated and used.
• The Wise Fool is that child—the person who can see that the accepted truth is simply a consensual illusion, and that really the emperor has no clothes. So if you have a Wise Fool or two, cherish them.
• One of Scrum’s virtues is that it makes the uncomfortable visible, quickly.
• It’s not enough just to be happy. Happiness needs to be harnessed to produce results.
• It’s the Journey, Not the Destination. True happiness is found in the process, not the result. Often we only reward results, but what we really want to reward is people striving toward greatness.
• Happy Is the New Black. It helps you make smarter decisions. Plus, when you’re happy, you’re more creative, less likely to leave your job, and more likely to accomplish far more than you ever anticipated.
• Quantify Happiness. It’s not enough just to feel good; you need to measure that feeling and compare it to actual performance. Other metrics look backward. Happiness is a future-looking metric.
• Get Better Every Day—and Measure It. At the end of each Sprint, the team should pick one small improvement, or kaizen, that will make them happier. And that should become the most important thing they’ll accomplish in the next Sprint.
• Secrecy Is Poison. Nothing should be secret. Everyone should know everything, and that includes salaries and financials. Obfuscation only serves people who serve themselves.
• Make Work Visible. Have a board that shows all the work that needs to be done, what is being worked on, and what is actually done. Everyone should see it, and everyone should update it every day.
• Happiness Is Autonomy, Mastery, and Purpose. Everyone wants to control their own destiny, get better at what they do, and serve a purpose greater than themselves.
• Pop the Happy Bubble. Don’t get so happy that you start believing your own bullshit. Make sure happiness is measured against performance, and if there is a disconnect, be prepared to act. Complacency is the enemy of success.
• The first thing you need to do when you’re implementing Scrum is to create a Backlog.
• 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?
• With Scrum’s incremental development and delivery, you want to begin with the things that will immediately create revenue, effectively “de-risking” the project.
• You want to start delivering value to your customers as soon as you possibly can.
• In product development there’s a hard-and-fast rule that has been proven over and over again. I talked about this earlier: 80 percent of the value is in 20 percent of the features.
• The trick of Scrum is figuring out how you build that 20 percent first.
• There are only three roles in Scrum. Either you’re part of the team, and you’re doing the work, or you’re a Scrum Master, helping the team figure out how to do the work better, or you’re a Product Owner.
• The Product Owner decides what the work should be. He or she owns the Backlog, what’s on it, and, most important, what order it’s in.
• 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.
• The Product Owner needs to be knowledgeable about the domain.
• The Product Owner has to be empowered to make decisions.
• The Product Owner has to be available to the team, to explain what needs to be done and why.
• The Product Owner needs to be accountable for value.
• The key is not to have a fully established design at the beginning but, rather, to make a functional prototype, then see what you can improve.
• What is the absolute least I can build and still deliver some value to a customer?
• A company or organization that can’t react to changing conditions, competitors, or tastes is in trouble.
• Every hour spent polishing the apple is lost opportunity for value.
• Don’t focus on delivering a whole list of things—everything and the kitchen sink—focus on delivering what’s valuable, what people actually want or need.
• Management of risk is at the heart of any successful venture.
• The three most common types are market risk, technical risk, and financial risk. Or, to put it another way: Do people want what we’re building? Can we actually build it? Can we really sell what we’ve built?
• By putting incremental releases in front of customers quickly, you’ll find out what your customers value and what they’re willing to pay for. And if your first guesses were wrong, you can make changes.
• The important thing, though, is just to begin.
• Scrum is designed so that you can boot up a team in a couple of days. Get your Backlog, plan your first Sprint, and away you go.
• Make a List. Check It Twice. Create a list of everything that could possibly be done on a project. Then prioritize it. Put the items with the highest value and lowest risk at the top of that Backlog, then the next, and then the next.
• The Product Owner. She translates vision into Backlog. She needs to understand the business case, the market, and the customer.
• A Leader Isn’t a Boss. A Product Owner sets out what needs to be done and why. How the team accomplishes it and who accomplishes it is up to the team.
• The Product Owner: Has knowledge of the domain and the power to make final decisions. He or she is available to answer questions and is accountable for delivering value.
• Observe, Orient, Decide, Act (OODA). See the whole strategic picture, but act tactically and quickly.
• Fear, Uncertainty, and Doubt. It’s better to give than to receive. Get inside your competition’s OODA loop and wrap them up in their own confusion.
• Get Your Money for Nothing, and Your Change for Free. Create new things only as long as those new things deliver value. Be willing to swap them out for things that require equal effort. What in the beginning you thought you needed is never what is actually needed.
• As they say on Wall Street, if you don’t know who the sucker in the room is, you’re the sucker.
• Cynicism is perhaps a rational response to despair, but it is one of the most corrosive of human states.
• Over the past two decades I’ve delved deeply into the literature of what makes greatness. The surprising answer is that, fundamentally, humans want to be great. People want to do something purposeful—to make the world, even if just in a small way, a better place. The key is getting rid of what stands in their way, removing the impediments to their becoming who they’re capable of becoming.
• Scrum Accelerates All Human Endeavors. The type of project or problem doesn’t matter—Scrum can be used in any endeavor to improve performance and results.
• Scrum for Schools. In the Netherlands, a growing number of teachers are using Scrum to teach high school. They see an almost immediate improvement in test scores of more than 10 percent. And they’re engaging all sorts of students, from vocational to gifted.
• Scrum for Poverty. In Uganda, the Grameen Foundation is using Scrum to deliver agricultural and market data to poor rural farmers. The result: double the yield and double the revenue for some of the poorest people on the planet.
• Rip Up Your Business Cards. Get rid of all titles, all managers, all structures. Give people the freedom to do what they think best and the responsibility to be accountable for it. You’ll be surprised at the results.
• How to Scrum
• 1. Pick a Product Owner. This person is the one with the vision of what you are going to do, make, or accomplish. They take into account risks and rewards, what is possible, what can be done, and what they are passionate about.
• 2. Pick a Team. Who will be the people actually doing the work? This team needs to have all the skills needed to take the Product Owners’ vision and make it a reality. Teams should be small, 3 to 9 people is the rule of thumb.
• 3. Pick a Scrum Master. This is the person who will coach the rest of the team through the Scrum framework, and help the team eliminate anything that is slowing them down.
• 4. Create and prioritize a Product Backlog. This is a list at a high level of everything that needs to be built or done to make that vision a reality. This backlog exists and evolves over the lifetime of the product; it is the product road map. At any point, the Product Backlog is the single, definitive view of “everything that could be done by the team ever, in order of priority.” Only a single Product Backlog exists; this means the Product Owner is required to make prioritization decisions across the entire spectrum. The Product Owner should consult with all stakeholders and the team to make sure they are representing both what people want and what can be built.
• 5. Refine and Estimate the Product Backlog. It is crucial that the people who are actually going to complete the items in the Product Backlog estimate how much effort they will take. The team should look at each Backlog item, and see if it is actually doable. Is there enough information to complete the item? Is it small enough to estimate? Is there a Definition of Done, that is, everyone agrees on what standards must be met to call something “done”? Does it create visible value? Each item must be able to be shown, to be demonstrated, hopefully to be potentially shippable. Do not estimate the Backlog in hours, because people are absolutely terrible at that. Estimate by relative size: Small, Medium, or Large. Or even better use the Fibonacci sequence and estimate the point value for each item: 1, 2, 3, 5, 8, 13, 21, etc.
• 6. Sprint Planning. This is the first of the Scrum meetings. The team, the Scrum Master, and the Product Owner sit down to plan the Sprint. Sprints are always a fixed length of time that is less than a month. Most people now run one- or two-week Sprints. The team looks at the top of the Backlog and forecasts how much of it they can complete in this Sprint. If the team has been going for a few Sprints, they should take in the number of points they did in the last Sprint. That number is known as the team’s Velocity. The Scrum Master and the team should be trying to increase that number every Sprint. This is another chance for the team and the Product Owner to make sure that everyone understands exactly how these items are going to fulfill the vision. Also during this meeting everyone should agree on a Sprint Goal, what everyone wants to accomplish with this Sprint. One of the pillars of Scrum is that once the team has committed to what they think they can finish in one Sprint, that’s it. It cannot be changed, it cannot be added to. The team must be able to work autonomously throughout the Sprint to complete what they forecast they could.
• 7. Make Work Visible. The most common way to do this in Scrum is to create a Scrum Board with three columns: To Do, Doing, Done. Sticky notes represent the items to be completed and the team moves them across the Scrum board as they are completed, one by one. Another way to make work visible is to create a Burndown Chart. On one axis is the number of points the team has taken into the Sprint, on the other is the number of days. Every day the Scrum Master tallies up the number of points completed and graphs them on the Burndown chart. Ideally there will be a steep downward slope leading to zero points left on the last day of the Sprint.
• 8. Daily Stand-up or Daily Scrum. This is the heartbeat of Scrum. Each day, at the same time, for no more than fifteen minutes, the team and the Scrum Master meet and answer three questions: • What did you do yesterday to help the team finish the Sprint? • What will you do today to help the team finish the Sprint? • Is there any obstacle blocking you or the team from achieving the Sprint Goal? That’s it. That’s the whole meeting. If it takes more than fifteen minutes, you’re doing it wrong. What this does is help the whole team know exactly where everything is in the Sprint. Are all the tasks going to be completed on time? Are there opportunities to help other team members overcome obstacles? There’s no assigning of tasks from above—the team is autonomous; they do that. There’s no detailed reporting to management. The Scrum Master is responsible for making the obstacles to the team’s progress, or impediments, go away.
• 9. Sprint Review or Sprint Demo. This is the meeting where the team shows what they have accomplished during the Sprint. Anyone can come, not only the Product Owner, the Scrum Master, and the team, but stakeholders, management, customers, whoever. This is an open meeting where the team demonstrates what they were able to move to Done during the Sprint. The team should only demo what meets the Definition of Done. What is totally and completely finished and can be delivered without any more work. It may not be a completed product, but it should be a completed feature of one.
• 10. Sprint Retrospective. 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. At the same time, people have to have the fortitude to bring up the issues that are really bothering them in a way that is solution oriented rather than accusatory. And the rest of the team has to have the maturity to hear the feedback, take it in, and look for a solution rather than getting defensive. By the end of the meeting the team and the Scrum Master should agree on one process improvement that they will implement in the next Sprint. That process improvement, sometimes called the kaizen, should be put into the next Sprint’s backlog, with acceptance tests. That way the team can easily see if they actually implemented the improvement, and what effect it had on velocity.
• 11. Immediately start the next Sprint cycle, taking the Team’s experience with impediments and process improvements into account.