Note on Current Draft

This is a nearly complete version of this book.

Version 0.97.1

We have some things to add. We have not proofread it enough yet. We are starting to add pictures.

We welcome your comments now. You might find:

• a typo
• a topic (section) you think we should add
• a question.

Please send your comments to me at jhlittle@leanagiletraining.com.

We want the book to be short. Our initial goal was twice as long as the Scrum Guide, but it is longer than that. It is readable in one day.

Primary use: If you are about to take my Certified ScrumMaster or Certified Scrum Product Owner course, you can read it usefully. Or, if you have just taken a course with us, and want to remind yourself what you learned, it’s a good summary of the basics. Of course, there are many other uses.

You can find the current version at Leanpub.com for now.

Thanks in advance for your feedback.

Introduction

Initially, I built this book as a series of blog posts to explain Scrum. It turns out that the basics of Scrum are very simple, and yet difficult to explain concisely. Maybe I knew that before, but it became evident in writing this book.

In part, you want to help explain so that people do not make all the common mistakes. Mistakes make things MUCH more complicated. So, we address common mistakes within a time/space box.

Scrum is:

• Simple to understand
• Hard to master

The last paragraph is a quote (almost) from the Scrum Guide 2017. Thus, a view shared by Ken Schwaber and Jeff Sutherland.

The primary purpose of this book is to give my course attendees a bit more of an introduction than just the Scrum Guide.

It is key that this book remains short. For those who have special cases or special needs, this book will not answer every question. I am sorry that it may not directly address your specific situation. I hope you also see the value in it being short!

Scrum is incomplete. Scrum is a bare framework. That is, it is not trying to include everything you will need to be successful as a Team. Again, it is incomplete on purpose! It is trying to contain the essential things, but not everything. One reason: Almost no one can initially implement everything that is in Scrum.

Add things that help your Team in your specific situation. You must and you will some. Whether you are conscious of those additions or not. Add more later; try to do the bare bones of Scrum, as much as you can, first.

You are expected to add to it.

Give your energy to the Team and the Game. And give your skills. Come up with a playing strategy, given your overall situation. And then try to win as a Team.

It is a kind of a Game. We think, in most reasonable situations, your odds of “winning” in real life will improve notably.

What Is Scrum?

Scrum is an Agile method co-created by Jeff Sutherland and Ken Schwaber in the early 1990s.

It is known to enable teams to achieve greater productivity, to find work more satisfying, and to produce wonderful products for customers.

Scrum is not a miracle, silver bullet, nor a panacea. It is no guarantee, but teams regularly improve to a very impressive degree by using it.

Scrum is one of many Agile methods. Agile methods are usually defined as those methods that follow the Agile Manifesto and the Agile Principles. (See AgileManifesto.org.) Jeff Sutherland and Ken Schwaber were both present when the Agile Manifesto and Agile Principles were created. They helped create those two documents.

Key: Scrum is simple.

Scrum is only providing a bare framework for a team to use to get work done. In our view, with the fewest possible constraints. We want it to enable the team to pop up to (emerge toward) a new higher level of functioning.

What is Scrum essentially? This is hard to say, to decide what to say quickly. It was created by two men in New England who like to express themselves practically, so you may have to experience Scrum for a while before you can answer that question.

From my experience, your answer will change over time. But here are some answers.

Team Sport

The Scrum Guide 2020 has a subtitle: The Rules of the Game. So, immediately we know it is looked at as a useful game.

Scrum is a team sport, modeled roughly on Rugby. Scrum tries to enable a team to be more successful. In part, to evaluate how they are doing, and then to decide what to do in their situation. (Some will recognize the “Transparency, Inspect and Adapt” ideas here.)

We mean a real Team. A Definition: A real Team pulls it (and themselves) together, so that the Team accomplishes more than anyone expected.

For example, all members of the team are expected to collaborate. Each person is expected to take fully commit, to help the Team be successful.

This does not mean that everyone is exactly equal or that they all have equal skill sets or skill in all areas. Still, together, they are taking on the goal of success (as a Team). They are taking on the vision as defined (usually and mainly) by the Product Owner.

I’m talking about a real team.

Here is a definition from Katzenbach and Smith (The Discipline of Teams - HBR):

“A team is a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable.”

Nearly everyone in any organization has been told, “You are on team X.” Mostly those are work groups or something similar — not real teams.

Among the attributes of a real team is that each member is 100 percent dedicated to only one team, the team has a common purpose and all members of the team are invested in that purpose and in accomplishing that goal.

You can do some of Scrum - maybe in a formal way do all of Scrum - without being a real Team. We are recommending using Scrum to become a real Team.

As you form Teams, you will see that many people have never been in a real team, as we defined it.

I think you will find that, if they become a good team (eg, not a dysfunctional team), then most people (90%?) will enjoy being in such a Team. But some will not. Or at least it is unclear if you can ever convince them to want to be a team member. Apparently the range is between 5%-20% of the people that managers were thinking could be team members. So, for a given team, this may not be a problem for you, could be a small problem, or could be a big problem.

Eventually, you will have to accept and deal with the fact that a small percentage of people will not want to be in a Scrum team. Or, perhaps, not want to be in this Team. Not wanting to be a team player does not mean that person is bad – but at some point, a non team player should be removed from a Scrum team. This is just common sense, right?

Team Roles

Within the team, Scrum defines three roles:

• Product Owner
• ScrumMaster
• Developer

Note that the prior Scrum Guides (before 2020) called the Developer role the “dev team” role, which I think is confusing to beginners. It gives the impression that there is a Dev Team within the Scrum Team. I find this is not helpful.

There is only one Team: the Scrum Team. The Team wins together or loses together. Everyone in the Scrum Team must contribute (to be truly successful).

We will discuss these roles in some detail later.

The Chicken and Pig Story

Short Note: Apologies if a little story like an Aesop’s Fable offends you (we are told that some people or cultures take offense). At least you must know that the purpose is, as with Aesop, to educate, and not to offend. In my culture, it is not offensive. Far from demeaning people, the purpose is to help people become better human beings.

Scrum lore has the “Chicken and the Pig” story. It is not used as often as it once was.

I will not give the story here, but the idea is that the pigs are committed, and the chickens are “only involved.”

The pigs term refers to the people in the Team. Pigs are committed. Chickens represent people outside the Team, who are not committed, but only involved.

From the point of view of the Pigs, the reality that the chickens are “only involved” is problematic. The Chickens are normally not as reliable as the Pigs want them to be. We mean reliable in helping the Pigs achieve the Mission that the Pigs have taken on. Because the Chickens have other things to do, different priority 1’s, they will be less reliable — or there is a strong chance of a problem in some way.

Some think this means we think chickens are bad. No! Just less reliable than we (the Pigs) re our Mission. Because the Chickens are not committed and focused on our one goal. From the point of view of a Chicken, he or she is doing important work, too. It’s just that when they are helping the Pigs with the Pigs’ mission, the Chickens are less reliable. To the Pigs, the work the Chickens promise to us is likely to be late or the quality lower than wanted, or it is in some other way “not quite what we wanted.”

But I find Chickens are always necessary. And important to our success! The Pigs can never, in my experience, complete their work without some help from some Chickens. To be fair, often the Pigs can find other Chickens — or do some of that work themselves in a pinch — nonetheless, normally the Scrum Team finds their own success significantly dependent on the Chickens.

Thus, we the Team must manage the Chickens well. Everyone on the Team (Developers, SM, PO), in my view, must help manage the Chickens. Because sooner or later the weak delivery by one Chicken (or a few) will become a key impediment.

Why Scrum

Why Scrum? How did it get here? How do we understand it? How do you explain it to your colleagues?

Why Was Scrum Invented?

The way I understand it, Jeff Sutherland became a software development group manager at some point in his career. The group was doing waterfall. Projects were failing. It was hard to understand what the real problems were (low transparency). People were demoralized. It was a mess, which is fairly typical for waterfall.

His reaction was “there must be a better way”. (Not sure if he used those exact words, but essentially that.)

So, Scrum is a reaction to the pain, stupidity and unhappiness of waterfall. Or, to put it a better way, Scrum is an attempt to do several things at the same time — bring some fun back to work, give us a sense of mission, enable us to see whether we have traction or not, and give us the transparency we need to make useful changes or improvements.

What Are the Ideas Behind Scrum?

These ideas are discussed in a later section in more detail. But we wanted to introduce some key ideas here, toward the beginning.

There are many ideas behind Agile and Scrum. Could Sutherland and Schwaber accurately remember in 1999 all these ideas nor where they came from? Ideas that went into Scrum. People are easily influenced and can sometimes forget where those influences came from. I think no one could remember, but some have been identified.

Scrum is a very interesting mixture of very simple ideas (e.g., KISS or Keep It Stupid Simple) and complex ideas (e.g., Complex Adaptive Systems ideas).

Agile Manifesto and Agile Principles

Scrum was invented before the Agile Manifesto and Agile Principles were articulated in 2001. Still, Schwaber and Sutherland were there at Snowbird in 2001 when the Agile Manifesto and Agile Principles were defined. They helped create them. They say that Scrum “follows” those Agile ideas. Read the Agile Manifesto (the middle 4 lines) and the Agile Principles. There are 12 Agile Principles. \

Do you agree Scrum follows those Agile ideas?

The New New Product Development Game article

Scrum was also strongly influenced by many other ideas. Early on, maybe before any experimental teams, Sutherland and Schwaber read one particular Harvard Business Review article that they found useful. So, one set of ideas comes from “The New New Product Development Game” article by Hirotaka Takeuchi and Ikujiro Nonaka.

Here are the six ideas described there:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping developmental phases
4. “Multi-learning”
5. Subtle control
6. Organizational transfer of learning

I cannot too strongly recommend that article and almost any article or book by Takeuchi and Nonaka.

Complex Adaptive Systems theory

Let me mention again the Complex Adaptive Systems ideas. See this link on Wikipedia for a start.

Ideas about People

I am convinced that Peter Drucker’s idea about knowledge workers and similar ideas had a significant impact.

Related are Takeuchi’s, Nonaka’s and others’ ideas around knowledge creation.

In my opinion, Scrum is notably about people. That is, Scrum is an attempt to help get smart people working together much more effectively. So, embedded in Scrum are many ideas about people, how they work and how they might work together better.

At the same time, Scrum takes on none of the specific theories you may have read about (Theory X, Theory Y, and others.). (If you say “more Theory Y than Theory X”, I might agree.) Scrum does not assume that a Team will self-organize well, that things will become the best that they can be “in this best of all possible worlds”. It might be an interesting exercise to puzzle out the ideas about people implied in the existing Scrum rules.

Agile is sometimes thought of as being overly optimistic about people. Not so, in my opinion. Scrum waits a day or a Sprint, and then says: “OK, let’s look at the reality of things, and decide what to do.”

Scrum is not overly optimistic. It does not assume that people are always perfect; quite the contrary. Scrum seems well aware that humans have strengths but also have weaknesses. Examples: We are easily distracted, and we tend to procrastinate. So, Scrum does a few things to address these likely issues. On the other hand, Scrum is somewhat positive, in that it assumes that usually people can learn to work together more effectively, can collaborate, can improve, and can become a better Team.

Empirical Process Control theory

Ken Schwaber visited Tunde Ogunnaike in Delaware, who was working at DuPont at the time. Ogunnaike and Ray wrote the “process bible”: Process Dynamics, Modeling, and Control. Schwaber was introduced to the ideas of Defined Processes (eg, waterfall) and Empirical Processes (eg, agile).

Hence the three key ideas.

• Obtain more transparency. Enable better inspection of the current situation (eg, how good the “completed” user story may be)
• Inspect. Observe, identify key issues, think of a reasonable action.
• Adapt. Take action and try to improve.

Within the sprint, at the end of each sprint, and across sprints.

As you recognize, these are also basic ideas around continuous improvement. Few will disagree with continuous improvement.

One can think of it this way, in part. We do not rely on what_should_ happen, but look at what has happened - the reality of the current situation (inputs (including people), outputs, everything) - and then try to make things better.

Lean

As many of you know, Lean has been called many things over the years. J-I-T, Toyota Production System, Toyota Way, Lean Thinking, etc. The ideas, especially from Taiichi Ohno, had a profound impact on Scrum.

There are many ideas embedded within Lean. Single-piece continuous flow, do not over-stress the system, minimize waste, small team, minimize work in process, focus on the essentials, using cards to manage the work (Kanban), KISS, continuous improvement, visual management, value stream mapping, the Five Whys, and on and on.

Experiments

Scrum did not arise from Sutherland and Schwaber sitting at the top of a mountain thinking big thoughts. As suggested, I think it arose from a hard, practical reality: _waterfall was not working. And then they looked, read, sought, and then experimented. It was the experiments that showed them they were on to something. They did not believe just the ideas — they believed the experimental results.

Note: These were experiments involving people working as a Team. The people inside the experiment are self-aware, have a will, have some relationship to the “experimenter”. So, this is not like a clean room experiment with non-conscious elements (even if animate).

One could say that at least some of the talk is an attempt (ex post) to explain why the experiments worked.

What we do know for sure is that many have played Scrum, and that a good percentage of them — if they do “all” of Scrum (or as close to all of it as we can reasonably expect) and do that professionally with rigor — tend to get very good to amazing results. Sometimes as much as five to ten times better than waterfall fairly quickly.

To the degree they do not do “all” of Scrum, the results come down quickly from amazing. Still, even “half-baked” Scrum tends to get them 20 percent better results.

But Wait, There’s More…

There are many more ways to explain Scrum, to help others understand why a piece of Scrum helps, or to talk about why Scrum works.

Here are a few ancient sayings (perhaps one not so ancient):

• “Two heads are better than one.”
• “The whole is greater than the sum of its parts.”
• “Many hands make light work.”
• “Live and learn.”
• “Go confidently in the direction of your dreams!” —Henry David Thoreau

Note that Sutherland and Schwaber both live outside of Boston, not far from Concord, Massachusetts where Thoreau lived. No doubt they were to some degree influenced by New England culture and Boston culture (which of course includes Emerson and Thoreau).

There still remain many more ideas that will help you explain Scrum. I enjoy using about half of the Yogi Berra quotes to explain Scrum, and it helps, I think, to use a humorous method for getting the concepts across. Two examples from Yogi Berra: “It ain’t over till it’s over” and “When you come to a fork in the road, take it.”

You will have to use all these methods and more to explain and explain. Because after a bit of time, your team will forget why they are doing this or that part of Scrum and, quite often, if they cannot explain to themselves why they are doing it, they will stop doing it. You, as the Agile advocate, must remind them again and again.

The Scrum Team Roles

We mentioned earlier that a Scrum Team is composed of people in one of three roles.

We recommend a Team should be seven people normally (or start off at seven):

• One Product Owner
• One ScrumMaster
• Five Developers

The Scrum Guide does not require you to have a fully dedicated team. I think if you read it carefully, you will see that they are urging you to have a fully dedicated team — and a stable team at that — if you are in a normal business situation.

I strongly suggest that you do that. It is just common sense, once you pick the top priority goal to accomplish. Have a dedicated Team accomplish that goal.

Can you use Scrum without a fully dedicated Team, with some success? Yes. And, more success is very likely with a fully dedicated Team (ceteris paribas)

The key reason: life is simpler for everyone. One team, one goal. There are several other reasons.

Scrum Team

The Scrum Team is key. It is not a role, but what we have if we combine about 7 people in all 3 of the Scrum roles. Or, those people in those roles could become a real Scrum Team.

We remind you that people are strange and Scrum is not a silver bullet. So, it is an opportunity, not a guarantee. Your chances improve greatly. But there are some “ifs.”

They together, helping each other, accepting help, self-organizing, self-managing and adapting to an ever-changing situation – they must make it happen. Build and deliver the product.

The whole is greater than the sum of the parts.

These are fundamental ideas in Scrum.

As one small example, it is the whole Team that makes (the Team’s) Velocity happen.

Note: The Velocity of a Sprint is the sum of the story points on each of the [8+] small user stories that the Team completed in the Sprint. Completed in accord with the Definition of Done.

The Velocity that we usually speak of is the average Velocity of that Team over the last 3 or 4 sprints. And that becomes the default expectation of what the Team will accomplish in the “average” new sprint that is just starting. And then the Team can inspect and adapt from that when there are good reasons.

Product Owner

The Product Owner (PO) ultimately owns the quality of the Product Backlog.

The PO must be decisive. So, the first key power: The PO must decide the order of each Product Backlog Item (aka user story) in the product backlog, quickly.

The PO should take input, within reason, from everyone. And then decide the order, under conditions of uncertainty. Based on “everything.” Future benefits and future costs are top of mind, but not the only considerations. Risks, dependencies, learning and other factors also get considered.

The PO is responsible for articulating the vision of what the Scrum Team is trying to accomplish. He or she must explain the vision in such a way that the team becomes inspired — not every PO can do that well.

Then, the PO enables everyone to contribute to the Product Backlog and tries to do things (e.g., talk to people in various ways) to assure it is the best possible Product Backlog and will fulfill the vision.

The PO should try to inspire each team member. I said it before, but let’s emphasize: The PO should explain the vision and everything else so well that of course the others on the team feel that this product is something that they have to do.

The PO must get all the questions that the Developers have answered quickly. As in 10 seconds, 10 minutes or, at the latest, 24 hours.

The PO must take all the questions about the user stories (in this Sprint) - and get those questions answered quickly. In 10 seconds, in 10 minutes, and at the latest, in 24 hours.

To make this more do-able, the PO must help the company gather and convey the details of all the the User Stories (for the upcoming Sprint) to the Developers, so that all their questions are answered before the Sprint starts. (This has other benefits as well.)

In this way, the questions that arise during the Sprint will be fewer and smaller.

Getting all the right people to give all the right details in a timely manner - just enough, just in time — this is almost always something that the company is not good at doing at first. To be fair, it is hard to do. Even the customers do not know what they want (the full solution) and do not even explain the problem very well.

Still, the PO is responsible that the communication about the details, the understanding, is becomes better continuously. Result: the Team is more productive.

The PO must be a change agent, and change the business side (as some of us call it) so that these questions can be answered more quickly and accurately.

The PO decides when we have a Minimum Viable Product, and when we release. Obviously, the PO must talk to others, but should be the final decision-maker.

The PO should enjoy working with the “geeks.” (I am teasing now about the divide between “the suits” and “the geeks” that many firms have now. We want them to learn to collaborate.) The PO should like learning about technology. This learning helps notably to improve the ordering of the Product Backlog.

The PO is working with others outside the team on Product Backlog Refinement. Other names of this rough type of work are backlog grooming and pre-planning.

The PO has to “herd the cats” — the Business Stakeholders. (I recommend four of them. We will discuss them later.) It is often hard to get good Business Stakeholders.

The PO is a kind of leader, but the PO is not the leader of the team. The PO leads, of course, in deciding how to prioritize the Product Backlog. The PO leads by inspiring, and by articulating the vision. The PO is the final decision-maker on when to release (deciding when we have an MVP). But the PO does not lead in any other way.

In general, we typically want the PO to come from the business side. Several good things typically result from that. It can also be OK if he or she comes from technology (or whatever your firm calls it).

In general, we need the PO to have knowledge in these areas to a high degree:

• The customers (internal or external)
• The customers’ problem(s)
• The current product (or product set)
• The competition
• The business model
• The business situation
• The people on the business side (who understand many of these things and the details well — so that the PO can, for example, help pull together the right details for the team).
• The product strategy
• The Team
• The legal, regulatory, risk, and compliance environment
• How this product fits in the organization’s strategy
• Actively learn more about Technology
• Etc.

In general, we expect the PO to have some knowledge in these areas. But not to know nearly as much as the Team needs.
For example, commonly the PO is not an expert in technology, and that level is not needed. But commonly a true willingness to learn more about Technology is needed. By working with the team, the PO starts to understand technology better and better with time; we want that.

How Much Allocation?

How much should the PO be allocated? In general, always more. This is a key problem.

Some assumptions:

• The Team has an important and difficult mission or goal
• It is urgent
• The Team is seven people in total

Then, in that case, I’d recommend that the PO be 100 percent allocated to that Team (of seven).

It makes a huge difference!

For example: One of our key problems is always unclear requirements. It is up to the PO to address this issue well. It’s a lot of work.

In general, a 1 to 5 ratio of allocated hours is a reasonable ballpark. (One PO hour for every 5 hours from the five Developers.)

Over and over and over… one of the biggest impediments is that the business side has not allocated enough time of the person who is playing the PO role. This is almost universally the biggest impediment by around Sprint 3.

You can backfill some. For example, you can add a business analyst to the team or maybe a couple of part-time business analysts outside of the team, and that can make things somewhat better for a while.

A good, highly-allocated PO can improve the productivity of the team enormously and is well worth the expense.

One can imagine circumstances where it might be better to have a PO allocated part-time. But I usually feel we was forced into that situation, rather than “this is wonderful.”

Still, it pays to have the PO allocated full-time if the team is working on an important project. (Well, they are working on one of the top projects in the company, right?)

Related: New POs are never very good. The person is often very good at the old job, but the PO role is notably different. The new person needs help in riding quickly up the learning curve; as I say it, to try to emulate the Wayne Gretzky of POs. This is hard to do if your company has no Wayne Gretzky.

In any case, get the new POs more training and coaching and other help to become better. It is trouble, but it is very much worth it.

Scrum Master

The Scrum Master role is easy to misunderstand, and in fact it is commonly misunderstood, at least to some degree.

• Servant Leader

We want the Scrum Master particularly to be a servant leader. (In a way, we want everyone to be a servant leader. For example, we want the Manager to also be a servant leader.) There are many examples of a servant leader, not just Mother Teresa. The servant leadership is a timeless concept, but was defined fairly recently by Robert Greenleaf in a famous essay: “The Servant as Leader” (available on this page).

I will over-simply servant leadership into two things:

• The Servant Leader cares about the people she is leading, as if they were real people
• The Servant Leader offers to help those people accomplish what they wish to accomplish, and takes specific actions to get something fixed or improved

In Scrum, we say that the ScrumMaster (SM) fixes impediments. More accurately, the SM gets someone to fix the most important impediment.

The SM asks the team: “What is your biggest impediment?” And then the SM asks: “May I help you with that?” Normally the Team would say: Yes.

Impediments can be anything slowing down the Team or perhaps stopping them. (So, blockers are one kind of impediment.) Really, any opportunity for improvement.

As part of this, we want the SM to look at the people and the Team in a holistic way: are they well and good, as people. Not just as workers.

This servant leader idea does not mean that the SM becomes the slave to everyone. The SM is trying to help the Team to become a high-performing Team, so the SM is always working on the top impediment (typically the impediment with the best ROI).

• Teach the Team to self-organize

The ScrumMaster (SM) should help the Scrum Team learn how to self-organize.

Self-organizing is a thing we as humans all do. And we all can do more. It is odd that some people feel that they are not supposed to self-organize at work. So, you may find that your Team or some of your people do not self-organize well. Or do not do it well in some contexts. Fairly common.

Other teams struggle with this in part because other people (eg, managers) inhibit the self-organizing.

In my experience always the Team can learn to self-organize more and better. The SM helps them learn.

• Honesty and Transparency

We want more honesty, particularly in the Daily Scrum, as one example.

We want the Team and the organization to be more transparent. Not just to tell the truth, and be more open. To share more, to allow the team members to have and use all the information available.

This can be hard.

People commonly do not want to reveal their weaknesses, shortcomings, and mistalkes. And yet people make mistakes all the time.

The SM can try to create a “safe environment”. But to do this perfectly is impossible. So, the SM must have the courage to set the example, be more honest about his own shortcomings and mistakes, and then to ask others to be more courageous by being more honest.

Not about everything, but about the work of the Team to build the product. And related matters.

• Build trust

The SM should build trust inside the Team. And also build trust between what is often called the business side and technology.

Each sprint the Team makes a promise and then either fulfills that promise, or not. By making promises and usually fulfilling them, we build the trust. Being honest also helps.

The SM cannot of course “make” the Team successful, but can certainly influence in these areas.

• Protect the Team from Distractions

Distractions are one of the key types of impediments.

The SM protects the team from distractions. Of all types or sub-types.

This, of course, is in some sense an impossible task — to eliminate all distractions. But to reduce distractions significantly is actually quite easy.

To reduce some important distractions can be challenging. Some managers in some situations want to distract the team. The manager may be senior and may feel he or she is helping the team. The SM must decide when it is not helping the team. That conversation might be challenging.

We often think of the SM as the sheepdog, protecting the Team.

• Educator

The SM teaches the team and the organization about Scrum. He or she is explaining agile-scrum all the time. They forget, they seem to actively mis-remember or they interpret it wrongly; often coming from the waterfall paradigm. So, the values, principles and practices of Lean-Agile-Scrum must be explained over and over.

• Improve the Velocity!!

By fixing impediments, we want the Velocity to increase a lot better. (For now, think of Velocity as a measure of Team productivity.)

Who is the key driver? The SM.

But the SM does not fix all the impediments by himself or herself.

The SM can fix some impediments (alone) where he or she has the right skill sets. The Team (especially the Developers) have the better skill sets to fix some impediments. And it is good that they take responsibility for their own problems some. And people outside the Scrum Team often have the best skill sets to fix many impediments. People outside the Team might be a Manager, a technology expert in a specific field, or an outside vendor. Let’s share a third, a third, a third across these 3 sets of people (the SM being a set of 1).

The SM must mainly be making sure we are making progress on the top impediment for the Team “at all times*, as the phrase goes. So, the SM is often helping or encouraging the Fixer(s). Or keeping the Fixers undistracted.

Sutherland says a typical SM should be able to increase Velocity 100% in the first 6 months. (Does typical = average? And how many of us are above-average?) Longer-term, we believe virtually every team can become hyper-productive. That means, productivity has increased 5x to 10x from the baseline.

The SM must instill the perseverance to keep going, keep on improving.

At the same time, happiness should be higher (see the Happiness Metric) [add], Business Value should of course also be significantly up, quality should improve, and the Team should be working fewer hours (eg,40/hrs/week).

• Impediment List

The SM is the person mainly responsible for the Impediment List. Making it accurate and up-to-date, and getting the Team to prioritize it well.

Simplistically, one can think of the Impediment List as an improvement list. And we can think of it has “the work the SM must do.” Too simple, because the SM, the Team, and others will work on the impediments. But, still, the SM is driving that work.

The Impediment List is discussed later, as an artifact. [add]

• Help the Product Owner

The SM must get help for the PO, so that the PO continually improves. As the person becomes a better PO, this will make that Team a lot stronger and affect the Business Value delivered and the Velocity.

We have already discussed how the SM helps the Developers, the Scrum Team generally, and the Organization.

And the SM also helps the PO. This can be hard. Most beginning SMs don’t understand the PO role well, have never played it, and don’t know where to look for help.

But the SM must start to find help. Get the PO trained. Maybe find a coach. Show your PO some really good POs (maybe find them in your organization or in your city), and suggest that your PO copy what the good POs are doing. The PO should aspire to become the Tom Brady of Product Owners (the GOAT, as the say in sports).

• Allocation

On a good professional Scrum Team of 7 people, we recommend the SM should be full-time.

There is no Scrum rule in the Scrum Guide that says that, but then, the Scrum Guide is silent on many things.

If the SM is one of seven people, then we are devoting about 1/7th of the team’s power toward continuous improvement. This is a bit over 14 percent of the team’s time. This seems reasonable and fair. Especially if, by investing in this way, we get 100 percent improvement in team productivity.

• Kaizen Mindset

If we open our eyes and see, there are a good number of notable improvements to be made — everything can be made better in some way. In Lean, the idea is expressed as the relentless pursuit of perfection[^This was the motto for the Lexus car brand.]. The team members can become more skilled in all the hard and soft skills. The team’s level of collaboration can always be improved. The impediments from outside the team always need more fixing.

[Fix footnote]

So, there is plenty of work to do to improve, if the Team and the SM knows we should be doing it.

As we hinted, there is a problem of identifying impediments at first. Often the culture is “we’ve been doing things this way for ages, everything is working fine, nothing to improve.”

In Lean, they have the saying: “No problem is the problem.”

That is, failure to recognize opportunities for improvement is often initially the biggest impediment.

The Team, the SM, and the Manager(s) must work together and commit to doing something about each top impediment. (Sometimes some mitigation of the negative effects is all we can do now.) Almost all of them. Continuously, over time. One at a time.

I hope the SM job has become a bit richer for you now.

Developers

The Scrum Guide 2020 calls this role: Developers. Formerly, it was called The Dev Team role. AKA The Implementers, the Doers, the Team role, etc.

What does Developer mean?

Developer in the Scrum Guide means or includes, all the skills needed to build and test and deliver the product. This can vary a lot per product. For software at least, it includes the coders and the testers. Which is awkward, because to some people in software, the word Developer translates to Coder. Again, for Scrum purposes, Developer includes also the testers or QA folks (if doing software).

Team Players

The Developers must be team players, as we say.

The Developers must help each other, and the strongest person must teach the others the skill set that he or she is strongest in. (Use common sense, which is very uncommon.) But the key thing is that it is about the team success and not about what an individual does. (We are not against recognition for individuals, but we want the team to be stronger. This is a team sport.)

Some people are not team players. Some do not want to be on a Team. Sometimes this is immediately evident. Sometimes unlikely people soon greatly enjoy working in a Team. Some people discover that they do not enjoy being in a Team. Soon, onlt team players should be in the Team.

Taiichi Ohno (originator of the Toyota Production System) is famous for using the rowing metaphor. They must all row together in the same direction to be successful. I am not sure the rowing metaphor, as with any metaphor, is completely apt in every circumstance, but we think in America at least it needs to be repeated and discussed more. (See “Toyota Production System” by Taiichi Ohno.)

The Dev Team - changed some

Scrum has evolved, at least a bit. So, we still have the idea of the group of Developers. And that they, as a group, have certain rights and responsibilities.

But, we no longer have the notion that there is a Team within the Scrum Team. At least, that is how some people used to think, and I think Sutherland and Schwaber have said, in effect: It is not useful to think of a team within a team.
I think we realize that the whole Scrum Team wins together or loses together.

Who Are the Developers? What Do They Do?

If the total team is seven people, that leaves five to be the Developers. The five Developers should have all the skill sets to build and verify and validate the product. (In software terms, at least coders and testers.)

This is important and often misunderstood. Some “Scrum Teams” working on a software product, do not include testers in the Team. This is a mistake.

[Move this below]

This violates that idea of done-done, or the Definition of Done. Done must mean that all the bugs (defects, etc) must be fixed by the end of the SprintFor a story to be completed and working by the end of the Sprint, it must be professionally tested (validated and verified), and the bugs (or quality problems) fixed, by professional quality people during the Sprint.

[Move this above]

Again, the Developers should have all the building, verifying and validating skill sets for whatever product the team is working on. And all related knowledge.

Does This Ever Happen?

If you mean do we ever have 100% of the needed skill sets inside the Team? In my opinion — never. The team always has a lot of the skill sets, but not all. In part, this means the Developers must rely on people outside the team to provide, one way or another, some of the skill sets. Or the knowledge.

Still, it is important to evaluate what skills we need vs what skills we have. This is important.

The Chickens

Let’s mention that most Scrum Teams cannot be nearly as successful without the help of Chickens, that is, people outside the Team who help the Team in some way. These so-called Chickens (involved, not committed) are part-timers.

The Chickens typically provide at least some of the missing skill sets.

More on the Chickens later. [Where is section on Chickens?]

How Much Are the Developers Lacking?

We should hope they have 99 percent or 98 percent or 95 percent of the skill sets. This happens. Or maybe 90 percent?

We will attempt to define 90 percent coverage, but to me, if the level is that low, the team is seriously compromised in terms of doing quality work in a tight timeline. Almost always, that is what is wanted. So, the Developers must be honest about where they are lacking skill sets. Again, getting humans to be this honest can be challenging.

Collaboration

The Developers must collaborate with each other a lot. And learn to do it much more effectively.

Usually they are initially at a loss as to what collaboration really means. One answer is: Help each other (more). Ask for help (more).

And then, teach each other your strongest skill set. And teach the other ones how to help you.

Part of the goal is to become cross-functional and multi-functional. In simple, idealistic terms, this means that everyone can do everything.

More realistically, the Team (and specifically the Developers) will develop enough skills so that (a) they have almost all the skills they need for this Product, and (b) they have the most needed skills in sufficient depth that they can complete any Sprint needed.

Knowledge Sharing

To be an effective Team, the Team must share knowledge. Virtually any and all knowledge that could help the Team be more successful.

For some people, starting to share knowledge is not a comfortable activity. But necessary.

The knowledge sharing includes learning and creating new knolwedge, and sharing that as well. “We all know what we all know” is at least the simple goal.

Dominant Person

If a team has a dominant individual who will not let the team work together, then ultimately the SM must get that person removed from the team. At least very commonly that turns out to be the correct solution. Often that person is clearly the most talented person on the team on paper, and most people think so, and yet, paradoxically to some, once that person is removed, the team’s Velocity goes up.

Should the Team Include a BA, an Architect, a DBA, an X or a Y?

It depends. It seems to work sometimes. It seems not to be necessary every time.

For DBA and Architect (often very important skills for a softaware product), Teams often find that having them outside the Team, contributing as part-timers, works quite well. Still, it depends on the situation.

Other Observations

Overall, it really helps to have a great team. In this statement, we mean not only those in the Developer roles but also the PO and SM. And important how well they all work together.

Reminder: Scrum is a team sport.

It is remarkable how many companies or people do not understand or follow-through on this “team sport” idea. This is often a big change to the culture. It is commonly a notable change for many people.

The Whole Team

The team needs to be considered as a separete thing, on its own.

The team is the whole Scrum Team. Normally we recommend about seven people — including the PO and the SM — and normally the team would be a full-time, a real team and a stable team.

Why?

First, we assume you are working on one of the top “things” for the company or at least your department. Why work on anything less important? We assume that the top priority needs to be done quickly, both for the company’s sake and for the customers.

Then, the ratios of PO to Developers and SM to Developers are better if the whole team is seven people. Also, we have enough people in the Developers to cover more of the required skill sets. Lastly, seven is about as big as you can get and still have good communication throughout the team, so that everyone knows what each team member is doing.

Next, a team has a separate identity, or, has its own identity. Hence, we must consider it as a separate thing.

Now let’s consider a few topics about the team.

Who Forms the Team?

Who selects the people who will be on the Team?

Scrum does not address this question. Just as it does not answer many important questions.

But let me suggest the following.

Start with a good Scrum advocate, well-trained, knowledgeable. Maybe you!? Maybe the best Scrum person in your company, or at least your area. You may have some power or authority or rank… or maybe not. You know agile-scrum better than most.

Next, you gather three managers. They know the project or product. They know the people. They are used to making decisions about who should be in a Team.

We recommend at least three managers because deciding who will be in the Team is a hard and important task and three heads are better than one.

We also recommend that you advise those managers — who typically are not Scrum experts — on how a Scrum Team works, how the team should be set up for success, how the team will be responsible for full and complete success, what a PO does, what a SM does, what the Developers do, etc. You must help them see the importance of team chemistry if they do not see it yet.

Hopefully they then select a good team.

Once they have selected a Team, have the three managers reflect on whether the whole team will work together and truly be successful. Sometimes they are used to looking at each person “on paper”, and not at how the Team will come together.

What kind of Team do we have?

One good thing about Scrum: You find out quickly how good the team is. Usually within three Sprints you have a fairly good idea.

Once a team is chosen, the Team should evaluate: can we win? Can we do it together? Do we have everything we need to be successful? What are possible failuremodes? What dowe need most?

They must be adult enough to insist on getting the things they will need for success. Things needed might include: the assistance of other people, books, training, knowledge, tools, etc.

The Team

It bears repeating that Scrum is a team sport. It is all about the team.

The Team should have some chemistry (amongst the team members), and the Team needs some chemistry with the involved (the chickens). Also important: the team must rise to the occasion and take on the responsibility of delivering a wonderful product. One might call this the character of the team.

Who Leads the Team?

Scrum defines this a bit, but perhaps mostly relies on emergent leadership. (This is a phrase that Jeff Sutherland uses.) Note that we call it leadership, not “boss-ship.”

The PO is the leader in the sense that he or she can decide how to order the Product Backlog. The PO gets input from everyone, but ultimately must make the lonely uncertain decisions.

The SM is a leader in terms of servant leadership. And servant leadership might be simplified into helping get one impediment fixed at a time. And the SM is the lead educator about agile-scrum. The authority. But the SM cannot make them do Scrum.

In general, we recommend a team of strong players who are all adult.

Thus, it is possible that any one person could (briefly) be a leader of the team in one area or another, from one hour to the next, or that, in the heat of battle, any person could rise up and lead the team in a moment of crisis. It is this type of team, with aggressive play and risk taking along with emergent leadership, that tends to be more successful in our kind of knowledge work in developing new products.

Again, any member of the Team can stand up, and emerge as a leader, maybe briefly or maybe in a bigger way.

Those are suggestions. Discover your own style of play, and see if that brings you success. Experiment.

Roles Outside the Scrum Team

The Chicken and Pig Story

Historically, “The Chicken and the Pig” story was part of the Scrum Guide. The main point of the story was to distinguish between the committed and those only involved. This is an important and useful distinction.

The Scrum Team includes the committed people, and they are responsible, as adults, for full and complete success in all the dimensions that real success requires. They should have all the right stuff to be successful.

The Involved or “Chickens”

Now we must talk about the “involved,” or what might be called the extended team.

Why Important?

What is key here is the notions of focus and transparency. These are key words in Scrum, and we describe them elsewhere.

If Chickens are doing work, we get much less transparency, about how it is going, commonly. But also, about why things went sideways. The answer is usally some version of “I was working on other stuff” - usually a lot less transparency, and so hard to know what to do about it.

Who are Chickens and what do they do for us?

We find that every Scrum Team always needs the assistance of others — always — and that that assistance is critical to success. The assistance could come from individuals, departments, other Scrum Teams, vendors outside the company, etc.

Perhaps some Teams can be successful with almost no assistance, but I find that is rare, assuming we also need to meet an aggressive timeline.

The Team members (and managers) must recognize the importance of the “involved.”

First, the Scrum Team must help identify the chickens and prioritize them. Then, the Scrum Team must do their best to manage each chicken. If further management is needed, the organization or organizations involved must also step in to make success more likely.

The involved are generally not very reliable vis-a-vis the mission of our Scrum Team. This unreliability is common because they are just not committed. To the involved people, the work of our Scrum Team is not their main thing. And normally, the involved have other work that is their own top priority (in some sense or another).

Typically, some of the involved will prove more reliable than others. The team must monitor them and do what they can to help assure that the involved deliver on a timely basis and with high quality.

What might the involved do for our Scrum Team? That too can vary quite a lot. Perhaps they provide knowledge or advice or coaching. Perhaps they write some code. Perhaps they do some work by pairing with us. Perhaps they build (and test) some (small?) component of the bigger product that this Scrum Team will deliver.

Some Specific Types of Chickens

Now let’s discuss quickly three roles outside the team.

• The Customer: Customers are the real people who will use our product. They may be internal or external to the organization we work in. It is in delivering something wonderful to them that we get the greatest satisfaction. Typically, customers are in “pain” (in some sense or other) and we are delivering pain relief. This is always urgent, at least to some degree.
• The Business Stakeholders: I use this term to represent the people who must work with the team part-time. First, they must come to every Sprint Review and give good feedback. See more below.
• The Minions: This is my fun phrase for that group of chickens who help the Product Owner pull together all the details. A PO may be supported by one or more “minions”. Usually part-timers. Ex: BA, SME, smart person, manager, person who does the real work, etc. Which minions are important now depends on who really knows the details of the stories we are about to work on.

Business Stakeholders

Now we talk about the Business Stakeholders (BSH) (as I call them) in more detail. When I say BSH I probably mean someone notably different than what your company culture may mean.

Among “the involved” people, the Business Stakeholders (BSHs) are very important.

Among the key tasks of the BSHs is to come to the Sprint Review and give good feedback. The bad news does not get better with age.

Why do we only say good feedback? Because no one really knows the customers that well. The customer situation is always changing. Customers change their minds. The customer base is complex. What the competition will do is hard to predict (and how that affects our customers). So, it is hard to be better than “good”. We must be realistic.

The BSHs do offer unbiased feedback. That is, because they did not create the product, they have no bias. So, we avoid the problem of confirmation bias, at least to some degree. They are willing to say “BS” to any story they don’t like. Honest feedback.

We recommend that you have about 4 BSHs. That number gives you many hands on the elephant. The PO and the BSHs together can give give fairly complete feedback and do it fairly quickly. The optimize those two goals.

The PO and BSHs represent, we hope, all the customers, and all the customer types or segments, and they represent “the business side” or, as we might put it, the interests of the shareholders for shareholder returns to the widows and orphans that eventually own the company.

These combinations of knowledge and insight and judgment are hard to find. And important to the success of the product. We do not normally recommend fewer than five (PO + BSHs) (nor more than seven in total either).

A few more qualities. The BSHs can give feedback on the Business Value of each story, now that it is real. Often this is different than the BV that was expected when it was only a story on a card. They also can give low-level feedback on any details that need to change. Or quickly find someone who can. The BSHs can also advise on, or constructively argue about, the product strategy with the PO. With the result that the PO’s qwssstrategy is more robust, and ultimately, on average, more successful.

Minions

Minions is a word we borrow for fun from Despicable Me 2. We needed a word to describe a group of people, and we wanted it to be fun.

Minions help the PO with the details.

The Minions get questions answered during the Sprint (or help the PO do that). And they identify the details needed to build the user stories. Often one story at time, but not always.

Every situation is different, so who your Minions will be can vary a lot. From one person to maybe 20 people. Lots of names people call them: Business Analyst (BA), Systems Business Analyst (SBA), Subject Matter Expert (SME), expert, smart person, Manager, Supervisor, Business Stakeholder, Process guru, “the person who understands how things work”, etc. Minions can include technical people, especially if we need technical details before we can build a story.

Because every situation is different, the PO must find the best people possible that will actually do this work and help, and be fairly reliable. Not an easy job, firstly because quite commonly, a Minion has another regular dau job. So, the Minion is often helping “off the side of their desk”, as some say.

We mentioned BSHs for each Team (we recommended four). The BSHs can often suggest people who will make good Minions. Hopefully the PO knows the business side, and will know some Minions, and other Minions will be suggested by the BSHs. Often that works pretty well, at least to identify good people.

The Events

The Scrum Guide defines the main events or meetings as:

• The Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

We start with an explanation of the first, larger time-box: the Sprint.

The Sprint

First, we look at the Sprint as one event, perhaps over 2 weeks. It is a game, and, on average, the timebox of it helps to win a lot of games (eg, >50%).

It is an important time-box (one of many time-boxes) where the team must build working product and then get feedback on what they have built at the end of the Sprint. This concentrates their minds wonderfully.

For most teams, we strongly recommend a two-week Sprint.

Some advantages of a 2-week Sprint:

• The Business Stakeholders (BSHs) and managers are more likely to come to the demo every time.
• The Team has built enough to show and we need the feedback. So that the bad news does not get better with age.
• It gives us enough time to recover from relatively small problems. And still have a successful Sprint.
• The Team can plan a 2-week Sprint better than a 4-week Sprint.

On rare occasions we might recommend a one-week Sprint or a four-week Sprint. Even more rarely, we might recommend 3 weeks or something else.

Scrum has four defined events (meetings) and all these events happen within a Sprint:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

In simple terms, you start a Sprint with the Sprint Planning Meeting and end a Sprint with the Sprint Retrospective.

Sprint Planning

Before the Sprint Planning meeting, there must exist a Product Backlog with small sprint-sized Product Backlog Items (PBIs) at the top of the list, somewhat more than enough to fill the Sprint we are starting. The PBIs must have been estimated, and the Developers should be reasonably confident in the estimates. (Or, we want to get to reasonable confidence soon.)

Specifically, we recommend User Stories and estimating using story points. AKA Planning Poker. So, for at least the stories to go into the next Sprint, they have been estimated with story points. (Story points will be explained more later.)

Also, the PO with the help of others has pulled together all the details needed to build the stories quickly. Discussed. Written down as much as needed. And key technical issues have been resolved. The stories are thus “ready” (some say “groomed”).

We recommend that the BSHs and the whole Scrum Team attend.

Time Box: For a 2-week Sprint, the maximum length is 4 hours. For a 4-week Sprint it is 8 hours. We think a Team can learn to have a good meeting for a 2-week Spring in about 3 hours.

I divide the meeting into two parts: Stories and Tasks.

1. Stories

The first part I call Stories. In this short part, everyone together reviews and agrees on the stories in the Sprint. Everyone can see all the information we have on each story, ask questions, and add or change or clarify any information.

The stories should have been discussed before Sprint Planning, but this meeting allows for “final” discussion. Some reasons: we are always learning, things change, and we often get surprises at the last minute.

More specifically, in this part of the Sprint Planning, the Developers pull one story at a time from the Product Backlog into the Sprint.

Each story is briefly discussed.

The Developers can stop at any time. They are volunteering to do this work (and we hope are also motivated).

The Developers might refuse a story for typically one of two reasons:

1. We do not have some details needed to complete the story, or
2. There is some dependency that is unresolved, so that we think we cannot complete the story in the Sprint

There can be variations, but those are the classic ones.

Typically, if a story is declined, the PO agrees to a change in priorities, so that the next story is taken in. Until the Team has, say 20 story points (assuming this is their average Velocity and is what’s expected in the coming Sprint).

While we hope this would have happened before, the Developers can reject any story they think is inadequate (we do not have sufficient information to commit to it professionally).

Early on, the PO says to the BSHs, “Speak now or forever hold your peace.” That is, any BSH is should reveal or clarify or comment – so that the BSHs are satisfied that the Developers have all the information they need, and the right understanding, to build each story successfully.

So, if a story is not perfect in the Sprint Review (demo), it is partly the BSHs fault. They should have explained more in Sprint Planning. If they are unhappy in the Sprint Review, it is partly because they did not speak up in the Sprint Planning.

Again, the Developers get to volunteer, one story at a time.

Before the 6th Sprint, we have the average Velocity for Sprints 3-4-5. Let’s say 18, 22, 20 for an average of 20 story points.

If some people will be absent some (eg, Doctors qappointment), then maybe less. Or if the SM has fixed an impediment, then maybe a bit more. Otherwise we expect to commit to the average Velocity (20, in our example).

It is important that all the top stories are small and about the same size. We recommend that a typical Sprint (for a team of seven) has about eight stories. With a Velocity of 20, that means a typical story would be two or three story points in size. No stories should be larger than 3 SPs (assuming those conditions).

These user stories have been planned for this sprint before this Sprint Planning meeting (eg, in a PB Refinement event) and this is a final review. So, typically, this part is done in 45 minutes or less. The BSHs can leave after this first part is complete.

For these reasons, we expect part one to be done in 30-45 minutes (at most, 1 hour).

2. Tasks

The second part is what we call Tasks.

Let’s pause a moment. Two key things need to happen in the Sprint Planning meeting. (a) Identify a reasonable amount of work the Team thinks it reasonably can do in the Sprint timebox. (b) Have enough conversation and discussion so that the Team is prepared to do the work, and has done some “due diligence’ about what they are committing to.

We do these things so that, when they commit as a Team, they have a fair chance of fulfilling their commitment. Of being successful! (And singing “We are the Champions!”)

So, you see the purpose(s) of this Task section differently now.

Back to the basics.

In the Tasks part of the meeting, we want the Developers (and others) to define the tasks (aka sub-tasks) through which they expect to complete all the stories (get each story to done-done, as we say).

How do stories differ from tasks?

A story has Business Value (at least in the eye of the PO) and a task by itself does not have Business Value. To put it another way, we can demo a story and get feedback, but it is not useful, normally, to demo a task.

Each person creates his or her own tasks, although people can work together.

How big should the tasks be?

To us, it is a trade-off between the work of building out the tasks versus the benefit that greater visibility would give the Team. Obviously, you get more visibility about the work and more visibility later about progress with smaller tasks. But smaller tasks are somewhat more work. What is the right balance?

We recommend that each task be typically 2 hours.

So, a Developer in the Daily Scrum would expect to say “I expect to complete Task 1 (of 2 hrs) and Task 2 (of 2 hrs) and start Task 3 (of 2 hrs).” That usually “fills” an 8-hour day, in part because these estimated hours are “ideal hours.” And the next day, after a pretty good day, say in the Daily Scrum: “I completed Tasks 1 and 2, and started on Task 3.” And it was good.

More broadly, having the smaller tasks enables the Team to see where they are making progress, who needs help, and where we are behind. Having that knowledge, we expect the Team to inspect and adapt better. Ex: By helping the people who are stuck at this moment.

The 2-hour tasks allow each person and the other members of the team to feel some completion — some traction — each day by each person.

Having 2-hour tasks is a cultural change quite often. But the visibility is worth it.

Do not forget: People should not be blamed for getting stuck. Think of this more as an opportunity for teammates to help teammates who get a bit stuck. That happens to everyone, to some degree. We help each other.

The small tasks also force people to admit their impediments in the Daily Scrum. Sometimes the only real impediment is that I am bad at estimating, but even that is a learning experience, and we all become better at estimating the tasks.

“If you want to change the world, start by making your bed.”

“One small task done leads to another small task done.”

New teams are usually bad at first at creating small tasks. The simple truth is, commonly, they are simply not used identifying small tasks. But as Goethe said, “Everything’s impossible until it becomes easy.”

So, the new Team defines the tasks at first (badly or maybe not so badly). Then does the work. Then defines tasks for the next Sprint. And does that work. With each iteration, we learn how to write better tasks. That is, when we don’t know how to do it, it is impossible for us. As we learn and practice and practice, it then becomes easy.

So, each task is described, assigned (or volunteered for) and estimated. The estimate is for a specific person, given that person’s skill-set for that specific work.

3. Improve the Sprint Backlog

After the Team has created all the tasks, we enable everyone in the team to see the whole Sprint Backlog (the stories and their tasks).

Anyone can now ask to change it, describe an item better, re-assign a task (in fact that can be done at any time during the Sprint), re-estimate a task, and even add or eliminate tasks.

With the Sprint Backlog improved, the team can now commit to the combination of the stories and the tasks. This combination is important. The Team gets two view of the work: (a) the stories and SPs versus the Velocity, and (b) the Tasks and ideal hours versus the capacity (in available hours). These two view should enable them to commit to the right amount of work (or closer, and learn to do it better and faster).

4. Commit

Before committing, they can consider any factor that might help or impede them.

It is the whole team committing.

The PO must get questions answered quickly. The SM must work on impediments. Key things that affect success.

I prefer to do this with fist-to-5 voting by each person. Showing a fist equals zero — no confidence. Showing five fingers equals maximum confidence that the team can get all 8 stories fully completed in this 2-week Sprint. We want each of the Developers to have at least three fingers showing. (How the PO and SM vote is also important, but not as important.)

If we do not get that level of confidence on the team, then either the Sprint Backlog needs to be discussed or changed, or the number of stories reduced. Or, for less likely, possibly we need to increase the number of stories in the Sprint, if they feel that is reasonable.

To commit does not mean to guarantee.

How Reliable?

With normal (good) stress, working about 40 hours per week, with the PO responding faster to questions and a SM dedicated to fixing impediments, the team should initially become 70-80% percent reliable in meeting their Sprint commitment (ie, I mean now, finishing all the Stories). That means for about seven or eight Sprints out of 10, the team should get all the stories (or perhaps all the story points) that were committed done-done.

If they were fulfilled their commitment in 100% of the Sprints, that would be too high. To get to 100%, they had notably under-promise on the stories or SPs for those sprints.

Remember that our work is hard to predict, we commonly get stuck, there are problems and delays. It short: it sucks. So, being very reliable is hard for our kind of work. Particularly high reliability.

So, 70-80% at first. The Team needs to feel like winners. We need to establish trust with the Business side.

Later, we think a bit above 50% reliability is the goal. Maybe 50-60%. That is 5 Sprints out of 10 the Team gets all the stories to done-done. This is good because the Team now has a better feel for their real productivity level (given the constraints we mentioned above: good stress, ~ 40 hrs/week, PO answering faster, SM getting impediments fixed).

On the edge of glory, as Lady Gaga might say.

A lot of good disciplines occur when the team learns to promise what they usually can complete. As one example, it forces them to minimize WIP, at least to some degree. It forces them to learn to estimate decently. (Often a key impediment at first.) Not to over-commit. (Universally a problem.) It forces them to insist on at least pretty good details before the story comes into the Sprint. (Always a problem, although the degree varies.) They become more serious about fixing impediments. (Again, always a problem.)

They learn to commit and then become fairly reliable in delivering that. The Team starts to feel like “we got this”. Team morale improves, and also trust within the Team. And the Business side trusts Technology (the Team) more.

Daily Scrum

Scrum has a daily team meeting that we call the Daily Scrum (aka Daily Stand-up).

The maximum time box is 15 minutes.

If the team is seven people, the minimum time box is 7 minutes.

The whole team attends. Others may attend, but they must be silent during the meeting. (More on this below.)

Note: The Scrum Guide 2017, particularly, implied to some that the PO should not attend the Daily Scrum. Jeff Sutherland has clarified this. You are still doing Scrum if the PO does not attend, but he recommends that the PO attend. I definitely recommend that the PO attend.

The high-level purpose of the Daily Scrum is that all team members share information and discuss, so that the Team can become more successful.

We recommend the 3 Questions. That each team member answers:

• What did I do or get done yesterday?
• What will I do or get done today?
• What is my (or our) biggest impediment?

Each person speaks for himself or herself.

The Scrum Guide mentions that the actions should be about reaching the Sprint Goal. So, for example, you do not get to talk in this meeting about your shopping yesterday.

The point is to enable better transparency for the Team. So that the Team can inspect and adapt better.

Let’s make that more specific. We can see more clearly who is stuck. And we can offer to help them. Most of it is that simple.

We also can see how much progress the Team is making, and have a view about whether we will complete the Sprint successfully. Good for Team morale.

Why the biggest impediment?

We find one of the biggest problems is no problem — usually expressed as “no impediments.”

Having no problems is the biggest problem of all. – Taiichi Ohno

This is famous quote in Lean. The key idea is: always there are imperfections that can be worked on. And having no impediments makes it harder to identify and work on the best impediments.

People want to pretend that they themselves are perfect and that the world around them is perfect. There are, also, some who wish to wallow in problems and worries all the time. But in the Daily Scrum, we want to hear the biggest impediments quickly. It is likely that one of the seven impediments will be important enough for the SM to work on immediately today.

This brings up the problem of honesty. Humans are not always as honest as we would like. Each person tends not to be completely forthcoming about his or her own weaknesses. Especially in a social group where you do not yet know the people well (low “trust” we often speak of).

So, the SM must encourage them all to be more honest about imedpiemnts or “areas for improvement” — these are important with Scrum. Note: Even “non-work” impediments (eg, lack of babysitter) can affect the Team and can be important.

Now we get to a key issue. What is the purpose of the Daily Scrum? (Yes, we gave a kind of answer to this earlier.)

One answer is to enable the team to sync up so they complete all the stories during the Sprint. This is true and good, as far as it goes.

A better way of putting it: The Daily Scrum is a meeting for all the members of the team to get the information they need to help the team self-organize, self-manage and self-direct themselves to a higher level of success.

Most people start out skeptical that a “status update” meeting is useful at all. So, three things must happen: (a) explain it and its purpose well, (b) help them get results, which are often delayed, from the meeting or series of meetings, and (c) when results happen, help the attendees connect the dots - connect the improved results to how it all started in the meetings.

Sprint Review

This meeting happens as the next-to-last thing in the Sprint.

We gather the team (the whole team, including, of course, the SM and the PO) and the BSHs.

Time-box: For a 4-week Sprint, the maximum is 4 hours per the Scrum Guide. And for 2-week Sprints: 2 hours. Commonly, the group needs about 1 hour for beginning teams, because they do not have much to show (low productivity at first compared to the future) and the attendees are not used to giving feedback. They should learn to give more and better feedback.

Again, we recommend 2-week Sprints for most Teams!

Side note on productivity: When teams get started with Scrum, often they are switching from waterfall, and the change is hard for the people and the organization. And they notice that things are not set up well for agile. So, productivity may be low in part for these reasons. Once some of these issues are mitigated, productivity increases and there is more to show in the Sprint Review.

Back to the Sprint Review itself.

In this meeting, we want to learn the truth. What progress have we made? What mistakes have we made? What do we need to do better? How do we improve the product so that it is outstanding and higher quality?

One key phrase: The bad news doesn’t get better with age. In other words, even the bad news is the good news. Because we caught it sooner, and we can fix it more cheaply (than discovering it later).

You can imagine, after the SM leads the Team in doubling the Velocity and after the PO starts providing better “details” for the stories, that the team will produce a lot more in two weeks, and so the meeting may need to go to 2 hours.

I think of the Spring Review in two parts: a short review and a demo.

1. The Review

In this short review, I recommend that the PO discuss a few basic things quickly. If someone wants to summarize the specific comments onto one slide, we would not object. (Certainly not a 50-slide presentation!)

These basics might include:

• Here are the stories we committed to in the Sprint Planning meeting
• Here are the stories that are done-done now
• This was our Velocity this past Sprint
• This is our new average Velocity over the last three Sprints
• With this average Velocity, we expect the current release to be delivered in X more Sprints (Ex: two more sprints)

The PO: “Let’s discuss this situation. Who wants to start?”

Then, there might be some discussion. As one example: the Business Stakeholders could decide to disband the Team (eg, not enough productivity). More common example: In effect they decide to continue to fund the Team. They discuss whether the Team might deliver earlier or with more Business Value.

• Next the SM might stand up: “Here are our to three impediments: A - [insert explanation of A]; B - [a short explanation of B]; C - [again, a short explanation of C]. Would you like to invest in fixing one of top impediments?”. Then silence.

First, it does not have to be the ScrumMaster. Another person could identify the impediments. Second, the silence forces the Business Stakeholders to answer the question.

In simple terms, the BSHs can answer one of 3 ways.

• “No.” Ex: We are too busy with Team B right now. So, we do not have time to consider helping your Team (Team A).
• “Maybe.” This is perhaps most likely. Ex: “We are interested. We want to discuss the dollar-value of the benefits and the costs, and see the ratio.”
• “Yes.” They know enough to decide now to help with one of the impediments. Or perhaps a different one.

Both a ‘maybe’ and a ‘yes’ are very good for Team morale.

Even if the BSHs do not answer, we all get more transparency. Almost always appreciated. And the BSHs no longer can live in the pretend world where the Team has no problems. So, they become more understanding, and less judgmental about the Team (at least on average).

Again, this is relatively quick — 10 minutes might be typical.

2. The Demo

People often call the Sprint Review “the Demo”, which is not so bad, but I think it is slightly misleading. The Sprint Review should include a bit of review also.

But on to the demo part.

• What do they demo?

What do they demo? (As in “give a demonstration of…”). Well, maybe it is obvious by now: They demo the working product built during the Sprint.

Perhaps we should add now that the demos (of each story, one story at a time, typically) are given usually in the context of the whole product. That is, all the features from any prior release as well as all the features built in any prior Sprints to build the current release.

If 2 stories are closely linked, the Team might demo them together.

• Basic considerations

Ok. After the demo, we want everyone to give us honest feedback, the best feedback that they can give us and the most complete feedback possible. The bad news does not get better with age.

• Who can give feedback.

Anyone can give feedback, but we want it mainly about two things.

1. How much Business Value does the story have now that they see it?
2. Is there anything (commonly, some detail) that needs to be changed for the customers to be happy with it?

Again, anyone in the Team can give feedback. Commonly the PO gave a lot of feedback earlier. Commonly the Developers will not give feedback on something the the coders and tester (if software) worked on. But will give feedback if other people worked on that story. And often this feedback is quite useful.

Still, most of the feedback is coming from the Business Stakeholders. And any managers who may have come to the meeting.

• Preparation and the Leader

How the Team will give the Demo needs to be prepared (before this meeting) quickly. The data needs to be prepared. Someone needs to think through how we will demo the new features. Which scenarios? Which examples will we use? Are they appropriate? Etc. This is important and sometimes hard, and it must be done in a time-box.

The demo needs to be “narrated,” particularly at first, by someone who understands the Buisiness Stakeholders personally. Also, the leader needs to ask questions, especially of the BSHs. Sometimes in the context of prior discussions of this feature, the competition, etc. Commonly, at first this means the PO leads the Demo.

It cannot be so technical that the BSHs never want to come back. The speaker must engage the BSHs and then handle their comments and feedback. If these things are not done well, then the BSHs will not come back, our feedback will not be as good and, therefore, the product will achieve much less Business Value.

Let’s say again: Getting good BSHs that come every time is hard. Good luck with that problem.

• Into the Feedback

We need to hear every imperfect detail now. So, if an imperfect BSH does not understand every detail of each story being shown, that BSH should bring a SME (Subject Matter Expert) or BA (Business Analyst) or someone who does understand all those details — and bring that person today!

What we want is perfect feedback about what the customers are going to want over the whole lifecycle of the product, so that we achieve maximum Business Value over that whole lifecycle.

The feedback we actually get is not that good. For example, we get feedback from humans who are not the real customers, or at least that’s what I usually see happening. Still, it is very useful feedback, and we should try to improve it.

• Details About the Feedback

Again, anyone can give feedback.

Complete: We want the Feedback to be complete. That is, we want all of it how for Story X, not two or six weeks later. This is hard, because it is so common that people see things later.

Positive: We want positive feedback. This improves the morale of the Team. Spend some time of this. VERY useful.

Of course, do not make a big deal out of a minor positive.

Negative: Again, we WANT negative feedback. The bad news does not get better with age.

Some people sometimes give negative feedback too brutally. This must be stopped quickly. I do tend to favor clear blunt feedback. Even that might need to be tempered a bit, until the Team gains confidence and an understanding of the usefulness of getting directly to the point.

Similarly, some of our Team members are emotional about the parts of the product they worked on, and may get unreasonably upset with calm rational negative feedback. These human issues must be addressed.

New Stories: It is common that people will see a story and think of another feature or two that could be added. This is great – in general we want to discover the missing stories. But this is not feedback on Story X that has just been demo-ed (ie, Story X does not need to be changed).

Business Value: Again, be sure to ask, now that we’ve done the demo, how do you see the Business Value of this feature over the life cycle? Often the understanding of BV changes. And it can change dramatically (down to zero or up to a much higher level). Sometimes whole new uses can be seen. Important to share this.

All Details: If a person wants to change a story, we need someone to immediately give us all the details we need for the Team to make the change(s).

As you facilitate the meeting, please be sure all these types of feedback are collected and dealt with.

• Krispy Kreme Theory or The Unbearable Lightness of Knowledge

The half-life of knowledge is often finished quite quickly.

When you go to a regular Krispy Kreme store, it is often flashing the “Hot Now” sign. That means the donuts are being made and coming, fresh and hot, off the conveyor belt.

If you like their Glazed Donut, right off the conveyor belt is…AMAZING! So fresh!

But in 30-60 minutes the donut is different. It is no longer warm. Still fresh, but not the “Hot Now” experience.

If you take a dozen home, let’s suppose a few are still left in the box the next morning. What do you do? Most Krispy Kreme lovers say: “In the mircowave for 7 seconds!” (They argue whether 5 or 7 or 9 seconds.) It comes out WARM again. But, honestly, not as good as “Hot Now” - but it reminds you of the Hot Now experience.

If you still have any donuts left the second moring, what should you do? If you care about the culinary experience of Krispy Kreme, you must throw them away.

And the same is true of the knowledge in Samuel’s mind. After 2 days, it is notable evaporated or erased. You may have to put his head back in the microwave! (Ok, that was a joke based on the metaphor. Do not do this at home kids!)

Knowledge decays quickly.

Hence, to fix the story at the least cost, we need all the details of any changes immediately. And we intend to fix this story at the very beginning of the next Sprint, which is perhaps 1-2 hours away.

• Comments on the Feedback

Often the Developers have excellent feedback. George may have excellent feedback on the story that he did not work on.

Hopefully, a majority of the time we get positive feedback. Yay! We did stuff well and the customers are really going to like it! Yes!

Double-down: It is wonderful for the team to get that kind of feedback every two weeks — wonderful. And the Team becomes more productive because of it.

The positive feedback must be sincere, meaningful and reasonable in context.

To be fair, it is hard to read the mind of the customer and what he or she or they will want in the future. We do the best we can. We live and learn.

• When there are disagreements

Not everyone agrees on the feedback. Examples: One BSH will disagree with another BSH, the PO won’t agree with an Developer, etc.

In any case, though, the PO must decide quickly one of the following:

1. “It’s done, we think the customer will like it how it is.” — A good result in many ways, as long as the person giving the feedback did not feel prematurely dismissed.
2. “It needs some changes and here is the complete list of exactly what those changes are.” — A couple of stories can be in this category. We hope not many. The list of changes might be a subset of the feedback discussed.
3. “It needs improvement, but we are uncertain about the details.” — Hmmm. This is not a good category if we want to get the release delivered quickly.
4. “Wow! This thing is mucked up. No one is ever going to want this.” — A story in this category is kind of depressing, but at least the bad news is not getting better with age. Then we have to decide: Is there anything within this user story (the three parts) that is a real need? Sometimes we realize that it was an idea, but maybe not a real need for the current release.

The PO must state their decisions clearly and also with a minimum of injury to the egos of the people whose opinions the PO is ignoring. Good luck with that.

• Politics and Courage

Let’s deal with an issue now: The PO is not always senior to everyone in the room. Sometimes some of the BSHs are more senior. Nonetheless, the PO must decide what to do with a story (or the related increment) after getting feedback. And get that decision to stick with the people in the room.

Again, sometimes two BSHs do not see things from the same point of view. Perhaps their departments or interests are opposed. Nonetheless, the PO must get them to express their differences and then must resolve them quickly — or at least decide quickly what to do with the current story.

I’m sure you can imagine how this meeting can be “interesting.”

3. Summary section

Commonly it is useful to have a “wrap-up” section.

Perhaps review the decisions that were made.

Also, let’s talk about all the stories that need to be fixed in the next Sprint.

First, it might happen that no stories need to be fixed. Rare, but possible. Also, at least technically, the feedback does not HAVE to be acted on in the next Sprint (although almost always that is the best decision).

Second, if you decide to completely reject the story, then, assuming a software product, then the code for that story must be removed from the codebase. Don’t forget to do that.

Third, we need a guess about how many story points it will take in the next sprint to fix and test (and bug fix) all the changes. Let’s imagine that guess is 2 story points.

Now we have some simple math. As an example”

Average Velocity now: 21 SPs
Fixes -2 SPs
Velocity available for new stories: 19 SPs

• Discussion of quality of Story details

It is our rough judgment that if the fixes will take 2 SPs in the next Sprint, we can assume that the total cost of the “failure to communicate” on these story, in the current Sprint and the next Sprint is roughly 4 SPs (double).

When people see that number, we hope they start to see the need to communicate better. And, given the size of it (let’s assume 20% of the expected Velocity of the current Sprint), they will want to improve and see that is possible improve notably. In conveying the details of each story better.

And everyone in the Sprint Review is involved in that communication.

• Other Questions

At the beginning of the meeting, after all the stories have been quickly mentioned, ask: “Did we work on the most important stories? Now with 20-20 hindsight, should we have worked on another story instead?”

Often this question will reveal new learning. For example, a new story for this release might be identified.

And then, after all the stories have been shown (demo-ed), ask: “Seeing all these stories, do they make you think of any stories we should add to the Product Backlog?”

Again, sometimes some very important stories will be identified at this point.

Remember what Buddha said: “Everything changes, nothing remains the same.”

More specifically, we are always discovering ourselves and others (eg, the customers, the market, etc). As things change, we then start to want different things in the product, or we (the builders) start to understand the life of the customer in a much different way. Whatever the reason, new important stories can still be identified. It’s better to identify them before the release than have the customers tell us of our glaring omission afterward.

Just because we discover a new story does not mean that the PO must put it in this release. That’s a different decision.

Retrospective

We usually think of the Retrospective as the last meeting of the Sprint.

What is the difference between the Sprint Review and the Retrospective?

The Sprint Review is about the product. The Retrospective is about the process. I prefer to put it this way: The Retrospective is about how we become better as a team — “continuous improvement.”

Who comes to the Retrospective meeting? The whole team: the Developers, the SM and the PO. They may invite others, which does happen sometimes.

Should the PO come?

Yes. Although not everyone agrees.

If the Developers are afraid of the PO and are not able to tell the truth if the PO is there, then that is an important impediment, especially for this kind of meeting. So, the SM may have to ask the PO to skip one or two meetings until the SM can get the Developers to tell each other the truth. However, the Developers must all become used to telling the truth with the PO present very soon. If they can’t tell the truth with the PO there, if could be a failing of one or more Developers, or perhaps the wrong person is the PO.

What is the time-box? According to the Scrum Guide, the Retrospective is 3 hours for a four-week Sprint. This implies 1.5 hours for a two-week Sprint. I am OK if you use 2 hours every two weeks.

This meeting is often not done well, and, less often, not done at all.

Do this meeting well! We are about to give advice that will make it a more useful meeting.

What Is the Purpose?

The purpose of the Retrospective is to become better — measurably better — in some dimension in some way.

Some people say, or act as though, the main purpose, worth 90% of the timebox, is to discover what our problems are. Some people shorten that to: The purpose is to complain.

I propose this: Spend most of the timebox on working together, where the Team helps the SM (or vice versa) solve the most important impediment the Team has.

Background

Typically, we want to improve Velocity (productivity). This is a good thing, but it presents problems. If you tell a team to improve productivity, they usually hear that as “work more hours.”

So, somewhere, the manager and the team need a few understandings, such as these:

1. We are not working more hours. We are working 40 hours per week (or some reasonable number).
2. We will be having more fun. Fun is essential to innovation work, and we will measure this with the Happiness Metric (see Jeff Sutherland’s blog).
3. We will improve Velocity a lot, 100 percent in the first six months. (I am ok with a 50% goal, but if you are clever, you likely can get 100%.)
4. We will improve quality. (Often they assume that to get higher Velocity we must decrease Quality. Nope!)

Always you have to discuss these four things together. They won’t believe it at first.

The “key” purpose could be something other than increased Velocity, although whatever it is, it usually influences Velocity eventually. Maybe higher quality, maybe faster learning, maybe better motivation, maybe higher Business Value, maybe more fun, etc.

Be aware that Velocity is a charged word for some. Some managers have used it to drive a team, with more stress. So, some people dislike the concept. Actually Velocity can protect the Team and also give them the fun of winning. But this may take some explaining.

I like to divide the meeting into two time-boxes.

The first time-box is small. It consists of the following quick discussions we suggest. (There are alternate ways of doing it, and once they master the basics, we do recommend changing things some.)

Initial Work of the Retrospective

1. What Went Well?

Take a moment to celebrate the things that went well, and ask everyone to do more of the good things — and to do those good things more often.

2. What are the Impediments?

I like to be blunt and honest. Always there are things in this sprint that sucked. Things that could have gone better. Or, opportunities for improvement. We were dumb, managers tried to kill us (it seemed), the servers decided to crash, it rained, etc. “It’s always something.”

It is important that we identify our own imperfections as a team, that we identify the supposed evil in others and that we complain about the world. All of these are true, and it is helpful, up to a point, to talk about them.

We are identifying the impediments as we did in the Daily Scrum and, unremarkably, we identify some of the same ones, along with some new ones.

Anything that slows down the team, in any way, is an impediment. A lack of a ping-pong table could be an impediment. Technical Debt could be an impediment. An interfering manager, a missing team member, corporate culture, a lack of babysitters — anything could be an impediment.

[Note: I think of Technical Debt as anything in or around the current product that, if it were fixed or addressed, would enable the Team to build new features faster. We discuss technical debt more later.]

Let me emphasize this: It is human nature to be reluctant to speak publicly about one’s own imperfections. Nonetheless, that is what we must do. Sooner or later, our personal imperfections are always some of the more important impediments. Because everyone is imperfect, and we can see this daily (eg, in the Daily Scrum), it becomes less hard to be honest.

Still, if you are the SM, good luck getting them to be completely honest, especially at first. What they are used to is this: “The beatings will continue until the morale improves.” Usually the more specific version is the blame game. You have to change this.

Before the Retrospective, the Team had have created an Impediment List, and by the end of the first Sprint it has the top 20 impediments. That remain still tobe fixed.

In the Retrospective now, each person identifies 3 possible improvements, by thinking in this way:

• I suck because…
• We suck because…
• They suck because…

It is very common in human nature to blame “them”. And, indeed, sometimes they (or it) are the source of the biggest impediment. But we must also look at our self and ourselves. (We have somewhat more control, also, over ourselves.)

Virtually always, many to most of the “things that sucked this Sprint” will not break into the top 20 list, because they are not that important, or are already on the list. But some will. One new thing might even go straight to the top of the list.

Some Benefits:

• The Team members get some things off their chest, they got to moan a bit (as all humans must do), they see that most of their impediments are not that important and they can live with most of them and move on. This is useful. More about the Impediment List later.
• This Impediment List is prioritized. Wow! Big help. Based mainly on the benefit/cost of the impediment. Or, maybe it’s better to say the ratio of the benefit achieved by mitigating or fixing the impediment over the cost of fixing it.
• We as a Team can now work on the top impediment.

The SM Report

I recommend the SM Report is the next action.

The SM has 10 minutes to “justify his love” for the team. That is, 10 minutes to explain what he or she has done in the past two weeks to help the team.

• Which impediments has he or she worked on?
• Which impediments has he or she taken to a manager?
• Which impediments have been fixed?
• How much has the Velocity improved this Sprint?

And the team (and the SM) expect the Velocity to usually improve every Sprint by a small amount. (Rome wasn’t built in a day.) The rest of the team starts to see how the SM is useful; and they are surprised. The SM is also surprised that they did not think (before) that he or she was valuable — but now they do.

The Top 4 Impediment

The SM now leads the team to quickly prioritize the top four impediments (from the top 20 list). The SM can add information (as can others) but we allow the rest of the team (not the SM) to decide the priorities. Even if they are wrong, they are right.

Main Work of the Retrospective

Now we can start the main work.

We all work together on the Top Impediment.

Now, the whole team spends the rest of the time working on the top impediment.

Here are three example of things the team can do together to work on an impediment. (These are not the only things a Team can do in the Retrospective, but common examples.)

1. Devise a Solution Together.

This is a phrase Ken Schwaber likes. They take the responsibility to define how to fix the top impediment. Again, some impediments cannot be fixed, but can only be mitigated or the impact can only be mitigated (reduced).

This might take some time. We might include root cause analysis (RCA). The Five Whys, or the Ishikawa (fishbone) diagrams might be ued. Or similar approaches.

The Team may need to consider alternate solutions. The Team might need to weigh alternate solutions and carefully decide. (I am not recommending endless deliberations, but if a solution is expensive, it deserves some thought before spending.)

2. Plan the Execution.

We figure out how to implement the solution. Which steps are needed. Who should perform the steps. Again, this done by the whole Team working together.

Note: Someone might raise their hand to opt-out, thinking “I do not have much to offer here.” This might well be a common sense request.

This might lead to the observation that the solution is costly, and maybe this isn’t the impediment with the best ROI.

3. Prepare a Business Case or A3 Report.

We work together to prepare a business case to take to a manager and ask for a “yes” — a yes to get some money or some people to work on it or a yes to allowing the change to happen.

We recommend that you use the A3 approach to Kaizen. This means many things. Specifically that the business case be prepared much like an A3 report would be done, starting with putting it on A3 size paper (close to 12” x 16.5”). The A3 Approach recommends following sections (or something similar):

• Problem
• Solution
• Benefits (from the Solution)
• Costs (of implementing the Solution)
• Action Items (e.g., steps to be taken immediately after approval)
• Measures (how we will measure after the fact that the solution actually improved things… or maybe not)

It would be fairly typical that the business case would not be perfect at the end of the Retrospective time-box. We expect the SM will move it forward and improve it. The SM might work with others on that. And then the SM (or the SM and the rest of the team) will present the business case to the right manager.

We expect the overall quality of the first A3 to be low. Discuss this beforehand with the manager. Ask the manager to give constructive feedback, on the basis that when the Team learns how to do this well, this will give a continuing stream of small improvements that the manager can use.

When an A3 is approved, it is typically for the SM to keep driving that work so the impediment is fixed quickly.

We want most fixes to be done within two weeks; and by the end of two weeks, we want to already be starting to accrue benefits (e.g., higher Velocity). This means that the Team (led by the SM) must break down the impediments into, often, smaller things, where the fix or mitigation can be implemented in 2 weeks or less.

These comments raise a couple of points.

First, the managers should be expecting these business cases. They should expect the team not to be good at presenting these business cases, and the manager should start to teach the team how to prepare a better business case.

Next, the managers should be expecting to say “yes” fairly often and expecting change. My saying: “If you don’t change things, nothing’s gonna change.” So now, the team is helping the managers become more effective.

In a typical situation, the Team should be coming to the manager with an A3 (or similar) on average maybe 1 sprint out of every 3 sprints. Maybe higher at the beginning, and then it slows down.

I hope the benefits of incremental change are clear.

The Artifacts

Now we turn to the key artifacts in Scrum.

First: There can be many artifacts for a team, depending on the work and how you define artifact. So, the main artifacts we will discuss here are what we consider the core Scrum artifacts. The Team will have others, also.

Here’s my list:

• Product Goal
• Product Backlog
• Sprint Backlog
• Scrum Board
• Sprint Burndown Chart
• Release Burndown Chart
• Working Product (or an Increment)
• DOD (the Definition of Done)
• DOR (the Definition of Ready)
• Impediment List

My list here is more than what you will find in the Scrum Guide. And also less than all the artifacts talked about in the Scrum community.

Common Sense and your situation

Do we have to use all these artifacts every time? In fact, do we have to do everything that is mentioned in this book?

First: How do I know? I cannot know, and no one can know, all the situations you all are in. So, you must decide, in the context of your overal situation. To start, perhaps Scrum is wrong for you. One good reason: You have a work group and not anything that will ever be a real team. (I might still start with Scrum if I thought that the work group, or enough people from it, could eventually make a Real Team.)

Let’s do to the next kinds of cases. These are: We think we can use some things in Scrum, but are unsure about 1 thing or several things.

First advice: Many many people have had this thought. The common situation is that that person or group is still thinking in a “waterfall” way (or at least in a non-agile way), and while it seems hard or like it won’t work, you (or you all, the Team) are actually hurting yourselves more than helping yourselves. So, you have been warned.

Still. Use common sense. If you are fairly confident that an artifact won’t help you in your specific situation, by all means do not use with it. Yet. Just be careful.

Often the problem is not so much you (you do want to use that piece). The problem is you can’t convince the right people. This is very common. Get the easy wins first. Then come back later and try to explain X (one of the things initially omitted), and get that to happen. It’s ok if change takes some time.

More advice: Consider carefully WHY we are recommending each piece and part of Scrum. Imagine how it all fits together. If you (or you all) want to reject one piece, at least think about the purpose, and try to do something that addresses that purpose. Later, evaluate how well that purpose is being served, or if it has become an issue.

“Common sense is not very common.” That’s a Ken Schwaber saying, I believe. What I think it means is that we are so easily captives of the old ideas, that we do not see the truth of the current situation well enough. Often, we do not make the right decision. Be careful!

Other Artifacts

Should you have other artifacts? Do I recommend others? I often get these questions. The answer is “yes” in both cases. I probably would recommend: Let’s do these artifacts at first, and become fairly competent and professional in using them, which will take time. Once we have some level of mastery, then let’s consider adding other artifacts.

Again, here we will discuss the basic Scrum artifacts.

Let’s mention one more artifact (or someone could call it an artifact). That is, the Scrum tool.

There are many Scrum tools out there — none are identical. They do many things and they vary a lot, but, typically, they hold the Product Backlog and the Sprint Backlog. Often, they do more, such as generate the burndown charts or show a Scrum Board, etc.

Well-known Scrum tools include using Excel, Rally (part of Broadcom), Version One (now Digital.ai Agility), Jira, Pivotal Tracker and many more. Some of the Scrum tools (other than the ones named above) used to be lame a few years ago; now most of them are pretty decent. For many of you, some of the older tools have had “feature growth” and so have become too commplex for your needs. The best tool is probably the one that someone in your Team already knows how to use.

You probably should have a Scrum tool, even if it is only an Excel sheet. Our goal in this paper does not include addressing the Scrum tool as one of the artifacts.

OK. Now let’s discuss each artifact I mentioned above.

Product Goal

Interestingly, I have always thought the Vision (or the Product Goal - essentially the same thing) was very important.

And yet, I have for years left it off the list of artifacts.

To me, the Scrum Guide 2020 puts it on the list of artifacts.

Why is it important?

First, very useful to have the whole Team committed to the singular Product Goal (or Vision).

The Team and the Business Stakeholders should find it motivating. Or want to achieve it!

Second, it is important that it is clear and they all see the same Elephant[^I allude to the Six Blind Men and the Elephant story]. But, commonly it is abstract, vague, and they forget it fairly quickly.

Is it necessary that the Product Goal is singular?

Hmm. Necessary?

It is better. The Team are all pulling in the same direction. Pretty soon, they are all motivated by it. Care about the quality the product will have. And care to deliver the product to the customer as quickly as possible.

But, would it be terrible to work on two products (two releases) at the same time? Hmm, maybe not terrible, but we don’t want to recommend that. Still, it might be the best you can do now, everything considered.

Is the Product Goal short-term, as in the Next Release of product X, or more long-term (where product X will be after the next 3 releases)?

Good question. I will be almost as equivocal as the Scrum Guide 2020.

It should be long-term, eg, as compared to one Sprint. (The Scrum Guide says long-term, but does not define that.) And I will not say how long-term. A Sprint Goal would be short-term (only for one Sprint – and I imagine 2 weeks).

I can imagine a situation where a Team might benefit by using two words. (a) A vision of where we want to be in 3 years. (b) A Product Goal for the Next Release in 3 months.

Advice to the PO

It is important that the Product Goal is clear and motivating. And everyone understands it and basically agrees.

This is not so easy to do at first. And, some Team members will not find it motivating until they have a sense that achieving the goal by the (current) Release Date seems possible. It looks like we can be successful.

Also, once they understand and become motivated, they start to forget. You might know the BB King song: “The Thrill is Gone.” A great blues song. So, the Team slowly loses the thrill.

You have to re-articulate the Product Goal. And, hopefully, get the motivation up again. The SM can help you, but the main responsibility is yours. You can get others (eg, a manager) to help you. Refreshing the motivation is not easy.

Product Backlog

The Product Backlog (PBL) is usually the first mentioned of the artifacts. In some sense, Scrum starts with the Product Backlog, or at least the first Sprint cannot start without a Product Backlog.

The Product Backlog is a list of all the proposed work for the team. We also think of the Product Backlog as the list of all the new features for the current product.

User Stories

We call the items in a Product Backlog: Product Backlog Items (PBIs).

We also speak of those items as User Stories, especially if they are in the User Story format.

The User Story format is:

As an <end user role>

I can <do something>

So that <explain purpose or next step or because>.

Who Can Contribute?

It is important that the Product Backlog include all the work of the team. (More on this later.)

Anyone can contribute to the Product Backlog. This is important and often misunderstood. Any team member can propose PBIs, any Business Stakeholder (BSH) can propose PBIs and any customer can propose PBIs.

The PO can judge an item out of scope, improve the quality of an item proposed for the Product Backlog, and even re-write PBIs.

This is often misunderstood: The PO does NOT have to write every PBI or every User Story. Although normally the PO writes many.

Ordered / Prioritized

The Product Backlog must immediately be ordered or prioritized.

The final decision maker on the priority order is the PO. By this we mean that anyone can suggest things to be considered in the ordering or prioritization, or suggest new data that would affect the ordering.

Not every one uses words the same way, so let me explain two words.

By “ordering” we mean putting the work (PBIs) in the order we will do the work, based on all consideration. Many people use the word “prioritize” to mean: we prioritize the work by business value. So, please note: When we say “order”, we mean after consideration of more factors than just Business Value.

Yes, when some people say “order” or “prioritize”, they mean exactly the same thing.

Some teams may prioritize first by Business Value or the value to the end customers. Ok, maybe useful to see some things. But rather incomplete.

Next, we recommend to prioritize by (expected) return on investment (ROI), which is the Business Value divided by the cost (mainly, of the effort). To do that and see it is educational. And may bring some insights.

The ordering must also include all other factors, such as Learning, Dependencies, Risks, MMFS / MVP, and any other factors. Let me explain them a bit.

By Learning we mean mainly: Let’s this PBI early, get the Learning (in whatever domain) and that we benefit us and the later work, so that we end up with a better result. Learning in our kind of work is VERY valuable.

Dependencies are mainly the old “technical dependencies” that we always talk about, for example, in software development.

By Risks we mean our bias to attack risk relatively early in the work. A related: “The devil you know is better than the devil you don’t know.” So, let’s do the work, see how big (or small) the risk turns our to be, and then we have more time to adapt.

MMFS stands for Minimum Marketable Feature Set[^{See **Software By Number** by Denne with Cleland-Huang]. MVP stands for Minimum Viable Product[}This acronym was popularized in Lean Start-Up by Eric Ries.]. Both acronyms include the idea, as I put it, that we always need a few extra features, because they just make the whole thing work. Usually features that are forgotten (for a while), or did not seem sexy or important. But it “won’t work without them” being in the MMFS/MVP. If you analzyed using ROI (as we suggested), these would be low ROI items.

Product Backlog Length or Duration

The Product Backlog should go out a reasonable time.

A simple way to think of this is: (a) we have a Velocity per Sprint of X, (b) we have a PBL that totals Y Story Points (over all the PBIs or stories), and (c) we are doing 2-week Sprints. So, let’s imagine that Y/X yields 26 Sprints. That’s 52 weeks, so that’s about a year.

Jeff Sutherland has said a typical length is one year for a typical product. I suppose this is based on the kinds of situations he sees. Surely this could be less for some products and more for others.

The key thing: in my experience, many Product Backlogs do not go out far enough.

They go out 2 or 3 sprints, when they should go out at least 6 months.

Two benefits with a “longer” PBL.

One, the PO can choose from more items to get an 80-20 selection. That is, the PO has a better change to find 20% of the effort the yields 80% of the Business Value.

Two, the Team can now see “where we are going.” With a shorter PBL they cannot see this. Now that they see this, the Developers especially are more motivated. They are now building one story at a time with no sense of how it fits in to the Big Picture. They know see how it does, and the work becomes more meaningful. (Well, assuming they are motivated for the Product and the Customers)

The Too-Big Product Backlog

Over time, most Teams accumuate a lot of PBIs that never move up the PBL. They “sit” at the bottom, so to speak, as other new stories come in above them.

At some point, we must be honest with the Business Stakeholders and customers and tell them something like this:

“This set of stories we think are never going to get done, in our opinion. Yes, everyone of these stories seems to have a positive ROI (more benefit than cost), but other stories are yet more important. So, we are sending these back to you. If you want to make a case that a few should be kept in out PBL and ought to be done fairly soon, you are welcome to make that case. But we will be skeptical. Still, for a few, it might be true.”

The 80-20 Rule

In general, for a given Product, the Product Backlog should help the PO do the 80-20 rule, or something close to it. This is the Pareto Principle or Pareto Rule[^https://en.wikipedia.org/wiki/Pareto_principle]. Pareto proved this with wealth in populations. The idea has since been applied to many many domains. Simplified as: The Vital Few. A relatively few things are really important, and most of the rest, not so much. Maybe 80-20, maybe 70-30, maybe 90-10.

We can “separate the wheat from the chafe.” An old old idea.

As we said, the team does 20 percent of the work (effort) and delivers 80 percent of the Business Value. This is hard to do (for many reasons) but focusing on this issue is very useful.

For example, at first, if the PO can get feedback and input and then select 20 percent of the work and gives 50 percent of the Business Value, that would be a serious and very useful improvement almost everywhere.

An added advantage is that the next release can be delivered sooner, and the product is simpler. And we learn the bad news sooner (I am thinking now: the things about the customer situation we didn’t understand).

Kinds of Work Included

The Product Backlog should include all the different kinds of work the team must do. We said this before.

The simple model is that the PBL only includes the work related to one Product.

This is a good idea, but not always viable.

The Product Backlog should include:

• new features for Product 1 and maybe Product 2 (that)
• small enhancements for P1 and P2
• legacy bugs for P1 and P2
• technical debt for P1 and P2
• other work (that the Team or Team members must do)

You recall that the PO is the final “orderer” of the PBL.

You can well imagine how the PO might order “other work” that has nothing to do with the Current Release (eg, for Product 1).

Legacy Bugs

These are bugs or defects that existed before the team started working on this product.

Technical Debt

We want PBIs also for technical debt (sometimes called technical stories). So, the PBIs include stories to fix the technical debt.

Technical Debt is not always a term used at your organization. A general definition might be: Anything that slows us down in delivering new features (enhancements).

In software, this might include:

• any code that Joe wrote (because he always writes code “Joe’s way”, ie, non-standard).
• any code that Joe wrote and then left the Team
• any code without documentation (or the right amount of documentation)
• any code without automated test coverage
• anything that should have been fixed but hasn’t been (some examples below)
• needed updates to the infrastructure
• needed updates or upgrades to the Architecture
• needed updates or upgrades to the Design
• anything that’s out-of-date and an upgrade needs to be installed (some examples below)
• upgrade the Database version
• upgrade the middleware
• upgrade the IDE (integrated developer environment)
• upgrade the language (I mean to the latest version here)
• lots of other examples

What needs to be done for Technical Debt?

Well, first, let’s assume that all or a lot of the work to fix this technical debt would be done by our Team.

Then, while we may have PBIs or stories or technical stories for some of this work, it is rare that we have all the Technical Debt identified as stories (that are at least reasonably small and thus can be estimated).

Then the Team needs to estimate the effort. (They may need some help in estimating from experts outside the Team.)

Any work to be done by people outside the Team needs to be identified, and confirmed. (Work done outside the Team does not go in the Team’s PBL – but might be tracked in the Team room or in another “instance” in the Scrum tool.)

Then we need to assign BV Points to the Technical Debt items. Usually the Business Stakeholders are not competent at this. And, to be fair, the concept of Value is quite different. Nonetheless, we need to compare on an ROI basis, so get the best people on that value you can. I recommend Priority Poker as a technique. The PO should feel that the resulting BVPs on the “technical debt” stories are roughly comparable to the BVPs are regular user stories.

This is all getting at how we order the technical debt work in the PBL.

Automated Testing

With software, organizations have two common situations often:

• this team or this product is doing manual testing currently, and we recognize that to be agile we need to move to automated testing, or
• we are doing (some) automated testing, but we need to make it better, and we need to convert the old manual tests to automated tests

In either of these cases, assuming the Team is going to do all or a bunch of this work, this work needs to be handled much like what we discussed for technical debt. (I don’t want to argue whether you should classify this work on automated testing as technical debt or something else. You decide.)

Small Enhancements

We mentioned small enhancements above.

These items (PBIs or stories) represent small changes to the an existing feature. As you probably inferred.

These become more important and more tricky in this common situation.

Situation: Image the Team has just finished a good release on Product 1. Now the next best good-sized release is in P2 (our first release in P2. The small enhancements that we have are all for P1.

So, doing any work on these P1 small enhancements will delay the P2 release. Not good, at least from a P2 viewpoint.

But, we commonly discover that some of the small enhancements have a very high ROI. Lots of BVPs for relatively few SPs. Having these small enhancement items in the PBL enables everyone to be transparent, have some tough conversations, and hopefully make the right trade-offs.

Other Comments on PBI Types

There can be other categories.

We do not have separate Product Backlogs, eg, for each category. Each team only has one Product Backlog. Hence, “everything” (all the different types of PBIs) must be prioritized together in one Product Backlog. This is not an easy job.

Product Backlog Refinement

We say the PBL is “emerging.” Some first ideas about this are: (a) is it always changing, and (b) we are always learning things that enable us to add to the PBL.

Note that I said “we”, not specifically the PO. The Team and the Business Stakeholders are involved in this identification of new information, this learning.

PB Refinement is where all the changes come together, and we start to act on them.

A few comments about PB Refinement here. More later.

The Product Backlog must be refined or groomed continuously. New PB Items will be identified. The new PBIs may be part of the current release, later release, or may never be built.

Product Backlog Refinement or Grooming includes many things. Among them are:

• identifying new stories
• breaking up larger stories (stories too big to go into a Sprint well) into Sprint-sized stories
• adding (or revising) story points on stories (Planning Poker)
• adding or revising the BV points on stories
• calculating changes to the ROI factor for any story
• re-ordering the PBL based on other factors (as discussed earlier)
• adding details to stories (as much as the team needs) - this new information BTW, often makes us see the Business Value or the Effort in a different way
• Etc

We have a whole book to describe Agile Release Planning, and Product Backlog Refinement is one key topic in that book. See Agile Release Planning.

Sprint Backlog

This artifact is different than many suppose.

Sprint Goal

The Scrum Guide 2020 describes the Sprint Goal as part of the Sprint Backlog. Ok, but not my favorite way of describing it.

We want a short singular Sprint Goal that gives the Team focus. The goal is expressed quickly. So, it is not fully defined.

Conceptually, it usually is or can be seen as a subset of doing all the stories in the Sprint. In any case, when push comes to shove, we first want to get the Sprint Goal accomplished.

While the Sprint Goal is created in the Sprint Planning meeting, a good PO will have thought out a wording for it before that meeting. The Sprint Goal must be something that the PO wants (or is the final decider about whether that’s the right thing to want now) and something the Team (mostly Developers) can do in the Sprint.

The Sprint Goal may need to be re-negotiated during the Sprint.

Stories and Tasks

The Sprint Backlog, in a concrete way, is mainly the list of stories, and the list of tasks to complete those stories. The Sprint Backlog must be stories and tasks that the team thinks they can complete in a Sprint. (In my mind, the normal Sprint should be two weeks in most cases. So, done in 2 weeks.)

The Sprint Backlog is created in the Sprint Planning Meeting. The stories in the Sprint (in the Sprint Backlog) come from the top of the Product Backlog. Again, the Developers get to decide how many stories to pull into the Sprint. The Developers volunteer. As we mentioned in describing the Sprint Planning meeting, the Developers can reject specific stories.

The Scrum Guide 2020 describes the tasks a bit differently than I will. It says: “[The Sprint Backlog] should have
enough detail that they can inspect their progress in the Daily Scrum.”

Small Tasks

To do this well, I recommend 2-hour tasks. We discussed this earlier, but here’s another discussion.

In the Daily Scrum, Joe can reasonably say: “I will work on Task 1 [2 idea hrs], and Task 2 [2 ideal hrs], and get started on Task 3 [again, get started on another task 2 ideal hrs task]. With the usual chaos that most people live in, that’s a reasonable commitment for the day.

The next morning, Joe might say: “I got Task 1 done, I got stuck on Task 2, and I never got to Task 3.” Very transparent.
The result: Carol can offer to help Joe get unstuck on Task 2.

The Team is better able to inspect and adapt with small tasks. It forces people to ask for help sooner. It enables people to offer help to a colleague sooner.

Also, the ability to see progress 2-hours at a time is reassuring. Team morale improves, and this is useful.

Purpose of Sprint Backlog

The main purpose of the Sprint Backlog is to give us the transparency (the information) we need to commit. The ability to debate the details, and come to a reasonable agreement. A commitment. Hopefully we commonly fulfill that commitment.

It should also be a bit aspirational and even inspiring.

When we complete it, we should be proud. I imagine singing (not too seriously) “We are the Champions!” if we complete it all!

That helps build the Team!

Another purpose is to become the Scrum Board!

Scrum Board

Every Team should have a Scrum Board, which is simply a kind of Kanban Board[^https://en.wikipedia.org/wiki/Kanban_board].

The Sprint Backlog (stories and tasks) becomes the Scrum Board, which is a kind of visual management tool. More specifically, the Scrum Board is a kind of Kanban board. So, Kanban, or a form of Kanban, is baked into every Scrum implementation.

Background

Taiichi Ohno was a brilliant businessman who was the main driver in what first was known as J-I-T (Just-In-Time), later called Toyota Production System, The Toyota Way, and Lean. He worked on this from the later 1940’s until he retired in the early 1980’s. His work has had a profound impact.

Ohno and his associates were visiting the US to learn, perhaps in the 1960’s. They visited a Piggly-Wiggly grocery store. It was using cards to manage the “flow” of inventory (ex: milk bottles) being presented to the customers. Ohno loved it. The Japanese word for card is kanban.

So, Kanban is closely linked to Lean.

Notes: This article is a partial but useful intro to Kanban.
See: https://en.wikipedia.org/wiki/Kanban].
Here’s an article on Lean Thinking, which is a start on Lean. See: https://en.wikipedia.org/wiki/Lean_thinking.

Kanban (or cards) are carefully used to achieve visual management and to improve (usually) “production” in some way. The main purposes of Kanban are: to identify stoppages in flow, and to then fix those stoppages.

Back to the Scrum Board

The Scrum Board is usually composed of several columns and rows. The columns are often titled Backlog, In-Process, and Done. There is one row for each story, and it is normally expected that only one story is “in process” at a time. Well, that level of minimization of WIP (work-in-process) is a bit tight for beginners doing software development work.

So, normally, a software team might have two stories in process at any time. But in any case, the situation of the whole team is usually pretty clear from the Scrum Board, or at least after a brief conversation about the Scrum Board.

Some people complain that the Sprint Backlog is micro-managing. Indeed, often the work is more broken down (for the two weeks) than you often find in a waterfall project, but the team is not being micro-managed by someone else (or at least that is not what we recommend). The Scrum Board enables the Scrum Team (and particularly the Developers) to self-organize and self-manage.

The team created the Sprint Backlog. See above. The team is not supposed to over-promise. The Team should only commit to an amount of work they have a reasonably decent chance of completing. The Scrum Board should not be used by one person to micro-manage or pressure the Team.

Purpose

The key purpose of the Scrum Board is to give the Team visibility into their progress and any stoppages in flow - so that the Team can complete the Sprint more successfully. That might mean getting all the work done that they committed to.

It might mean recovering faster and better, and getting closer to doing all the work committed.

Either way, better.

And being better in the Sprints, and learning how to react and improve faster, should enable the Team to have a more successful delivery of the Release. (This example assumes it takes several sprints to deliver a Release. Not always the case.)

[useful elsewhere??]
for work they can likely complete this Sprint. The Yesterday’s Weather pattern says only volunteer for the velocity you completed in the last sprint (or perhaps over the average of the last 3 sprints). Unless there is a very good reason to believe the team now can do more. Two examples: Now Person X is back from the vacation that happened in the prior Sprint, or the SM has fixed impediment Y and now the Velocity should be higher.
[move the above paragraph?]

Little things are big, and the bad news does not get better with age. And so, by seeing the small problems sooner, the team is able to take corrective action sooner and the positive impact is greater.

Is the Sprint Backlog perfect right after the Sprint Planning Meeting? No!

So, we expect the Sprint Backlog to be revised and improved as the team does the work and gets smarter. At least once each day, everyone in the team should revise or update the Sprint Backlog. In general, sooner or later a team member should explain why she changed the Sprint Backlog, if only briefly. (Commonly, in the Daily Scrum.)

The Sprint Backlog is pretty darn useful.

Sprint Burndown Chart

Now we come to the Burndown Charts. You could start with either one, but let’s start with the Sprint Burndown Chart.

We might first note that the Scrum Guide does not talk specifically about a (Sprint) Burndown Chart. The Scrum Guide talks about tracking progress toward goals, and mentions burndowns and burn-ups.

I still recommend specifically the Sprint Burndown Chart.

What does it measure or track? It gives our best guess, as of today, of the work remaining in the Sprint.

The way I recommend for beginning teams goes like this:

1. In the Sprint Planning Meeting, we create the tasks needed to complete the stories. I recommend putting hours to those tasks (typically 2 hours each), and that a person (or persons) be assigned to each task. (This was all discussed earlier.)
2. Each day, the Developers will get work done and learn. All of that information leads to revisions of the tasks. For example, some tasks can be replaced by other tasks. Tasks can be added. Tasks can be re-estimated. Tasks can be re-assigned to a different person who then gets to re-estimate the task.
3. Just before the Daily Scrum, the Developers make all the changes to the tasks, and put them “in the pot” (by which, I normally mean into the Scrum tool). Then someone (maybe the SM) can calculate the total hours of remaining work. And we see, in one total, how much work is remaining now.
4. That enables someone each day to set the points shown above (in the example) on the Sprint Burndown Chart.

Why?

The key thing is that the Sprint Burndown is for the whole team. The team wins together or loses together. So, the team uses the Burndown Chart to give themselves the information they need to self-organize, self-manage and self-direct themselves to greater success (or less failure).

Some of the action to be taken by the team is not discussed. Much of it happens, I think, sub-consciously.

Sometimes the Sprint Burndown Chart leads to a conversation, perhaps like the following:

Person 1: Yikes, we’re screwed.

**Person 2: Damn, well we have to do something. (And in that tone from experience they know that means fix an impediment.)

**Person 3: I think [X] is the biggest thing to fix now.

**Person 4: I think the thing to do is [Y].

**Person 5: I’ll get started on that. Who can help me?

In this little conversation, you see the team figuring out what to do. The Chart is not primarily for others, but for the team itself. They are the adults.

We look for emergent leadership, people who rise to the occasion and make it happen. We expect the team members, possibly any one of them, to take this information and do something with it.

Transparency

The Sprint Burndown relies on the team being as transparent, honest and accurate as they can be about all the work remaining — to the whole team.

The work total can change on any day for these reasons (and others):

• We completed tasks
• We partially completed tasks
• We removed tasks from the Sprint backlog
• We identified new tasks for an existing story
• We added a story to the Sprint backlog
• We re-estimated tasks (up or down)
• We removed a story (and related) tasks from the Sprint
• We reassigned a task to a different person with a different skill set (up or down)
• Etc

So the “work remaining” point for a given day is the NET of many factors.

When asked, we must be honest about each of these factors. To ourselves in the Team and to others outside the Team.

Over time, when people outside the Team look at our Sprint Burn Down, we must explain to them how to look at it, and all the factors involved.

This can be challenging to managers who too readily want to intervene if things do not go perfectly in one day. One day is not a problem. Even a “failed” (weak) Sprint is not a problem, so long as we eventually are successful.

Innovation work cannot be predicted with great accuracy and surprising things happen.

We recommend being willing to fail. We do not recommend forgoing all planning and all management. In fact, we recommend spending more time on those things (than most teams do), so that, over time, we end up being more successful. Why? In large part by putting all our heads together to solve the problem.

Release Burndown Chart

Now we come to the Release Burndown Chart.

What is the idea? The first idea is to be transparent about how it looks for us hitting the date. But let’s agree that things can be a bit more complex than just that.

A few side notes:

• There are many different kinds of situations in Scrum. We have continuous delivery (CD) now. Something like a Release Burn Down might be used, but it would be different.
• We also have people releasing every Sprint into production.
• The word “release into production” is fairly commonly used in software. It is probably less commonly used for other products, and we think Scrum is also very suitable for any new product development. So, if you use different words, please translate.
• So, if you are doing CD or are releasing every Sprint, the concept of a Release Burndown Chart is not meaningful as such. The concept of a Product Burndown might be.

So, assuming you are taking two Sprints or more to produce a product (six Sprints is a fairly common number to use as an example), then why do we want a Release Burndown Chart?

Why?

Two reasons come quickly to mind.

One is to measure progress. If we start at 120 SPs of work and get down to 60 SPs, then we are in some sense 50 percent done.

Why is that useful? Because it gives us the transparency to “take arms against a sea of troubles, and by opposing, end them.” It makes us cut through the mustard and get stuff done more quickly (at least more often)

This keeps managers from canceling projects that have made significant progress. (Such canceling has happened with waterfall projects, unfairly.)

So, I am suggesting that the common (not universal) practice in Scrum is (at some point) to set a date. We have a stable team — therefore budget is fixed — and the flexible part is scope (or how many stories will we get done in the time-box). Another flexible part is how much the SM will raise the Velocity of the team.

Above is an example picture of a Release Burn Down chart.

The vertical axis is story points, or the total of the story points for all the stories that are “remaining” — we are measuring the “work remaining.” The horizontal axis is time, divided into six Sprints. So, we measure work remaining every Sprint and get transparency from that. A trend line and where we are now.

Side note: One of the purposes of the Release Burn Down is greater transparency (this benefits many things). Obviously, humans are not always honest. So, for the Release Burndown Chart to be effective, the team must be as honest and accurate as possible.

The “Work remaining” number (in Story Points for the Release Burn Down) is the new effect of everything.

• we can also potentially redefine all of the work
• getting stories completed (done-done)
• adding stories
• removing stories
• breaking up stories
• re-pointing stories (based on new knowledge)
• redefining stories or re-writing them.

So then, the Release Burndown becomes as accurate as humanly possible as of that moment in time.

But why have a Release Burndown Chart?

A second reason is: this information enables the team to self-organize (around a common goal of hitting that date), self-manage (as if they were adults) and self-direct themselves to greater success — or at least a smaller failure.

Of course success and failure are not completely defined by hitting a date, but on this chart, the date is the key element.

The date is important because customers care so much about the date (or getting it earlier), and business (for a variety of reasons) cares about the date.

Side note: We discuss elsewhere at more length that happiness, fun and sustainable pace are also very important. While we are increasing Velocity, we must also insist that happiness and fun is going up and hours are normal (I’ll say 40 hours per week, but we could debate the exact number of hours). More on this elsewhere.

So, anyone in the team can use the Release Burndown Chart. It is mainly for the team.

Imagine a discussion after Sprint 3, heading toward a release in Sprint 6:

**Person 1: Wow! We are high by more than 20 story points.

**Person 2: Yes, we’re not going to make that date if we continue like this. We have to hit that date. [In real life, hitting the date is not always that important, but let’s imagine in this case that it really is.]

**Person 3: We still have some big stories. We need to break them down and see if we can move some of those story points to the next release. You know what Pareto says.

**Person 4: ScrumMaster, what can we do to increase Velocity?

**Person 5: If we could fix the [X impediment], I think the Velocity would go up five points.

**Person 6: We need to stop scope creep, too. If anything new comes in, we have to tell the business side that something has to come out.

**Person 7: I’ll take some time in the next two days to help with the [X impediment].

This conversation all started with an observation about the Release Burndown Chart. We are assuming that the team can act like adults and, to some degree, control their own destiny. It may not happen or may not be able to happen every time, but it can happen often enough.

Notice also that there was no discussion of working overtime or on weekends. Never say never, and we can argue about the right number of hours per week for our knowledge workers. But if you are late on a Release, working more hours is almost never the solution, especially if those hours will be significant. Because for hard knowledge work, most people have to tap out after 4-6 hours per day. They can function for longer (have boring meetings, read email, etc), but not on hard knowledge work.

Working Product, Increment and DOD

Now we come to working product. The big phrase is “potentially shippable product increment.” (Note: “potentially releasable” is the same concept.)

What it means is first this: At the end of a Sprint, we expect every story that the team committed to in the Sprint Planning Meeting to be “working” by the end of the Sprint.

Working first means built and tested — fully working (at the story level). Working does not mean that we have built a full Minimum Viable Product yet. So, while each story is “potentially shippable”, you do not have to ship it that same Sprint.

For the moment we are assuming the scenario where it takes multiple Sprints to build a Minimum Viable Product.

We define working product mainly through the Definition of Done (DOD). If the team has satisfied all the conditions (done all the activities of) the DOD, then you (should) have working product.

Note: It is possible to write a DOD that is not good enough. Following that bad DOD will not result in working product. Similarly, it is possible to have a good DOD, but the Team does not follow it.

We score points in the game (we earn story points for this Sprint’s Velocity) when we satisfy everything in the DOD for one story. It’s all or none — either the story is fully done and we get all the points, or the story is partly done (or maybe un-started) and we get zero points.

We can finish (per the DOD) any story on any day. We recommend that you do things that way.

It is not recommended, but it is not against the rules of Scrum that all stories are not done-done until the last day of the Sprint. (It is possible some Teams need to do things this way at first, as they transition toward agile.)

A bit further. For a story to be done, it must work well with all the other stories in this Sprint, and with all of the existing product we had at the beginning of the Sprint. In software, we might say its been fully intergration/regression tested.

The DOD must include two key things: The product is well built (high quality), and the product is well tested, and any defects are fixed and re-tested and all tests are running green. And we did good professional testing (usually that means better testing than ever before).

The stronger the DOD, the better. There is a strong bias toward the “quality is free” idea. That is, the sooner you build in quality, whatever that may cost you, it is much cheaper (in every way) than building in quality later.

Why?

Why do we want working product at all?

I mean, people will say that it is slowing us down and that it is lots of trouble — and it is trouble. People will say “it is more work for me” — and it certainly will at least appear to be more work for them (although if done correctly, not more work for the team).

One answer: “The bad news doesn’t get better with age.” That is, identifying and fixing the bad news now is much cheaper than fixing it later.

Another answer: We get better feedback from working product than from the documentation. Getting better feedback is very important. The more done-done the working product is, the more transparency the people at the Sprint Review have. And then they inspect and adapt better.

It is so easy to misunderstand what the customers (end-users) want. And, for example, to write down incorrect details for a story. This bad news does not get better with age. We identify the mistake CLEARLY in the Sprint Review. And we use the Sprint Review as feedback on how we can improve the communication going forward.

If we spend less time building what they don’t want and more time building what they do want, we usually get done quicker. (OK, a bit of sarcasm, but getting done quicker is very important in several ways.)

Another answer: We have a better gauge how completed (what percentage complete) we are. In waterfall, the schedule would tell us we are 90 percent complete. And then we awkwardly ask ourselves how much longer to complete the last 10 percent. (The waterfall story is that it takes as much time for the last 10% as it took for the first 90% of the work. Perhaps a slight exaggeration.)

Now, imagine we identify the story points for all the work in a release (ex: 120 story points in total) and ask how many story points are completed (ex: 60 SP). Then we would know how much of the work we have done (ie, 50%). We can then, based on the track record and the current average Velocity, make a better guess how much longer to complete the last 60 SPs. This is much more accurate.

So, what we know by this point (better, with more confidence) is also more useful for us. For example, managers are less likely to cancel a release that is truly 50% done with many great working features already built that the BSHs like. Features that they can see, taste and feel. Thus, fewer wrong decisions.

A Comparison

Let’s compare. We are 3 months in. The waterfall team is 80% done, based on people reporting they have completed tasks. People just started coding, they tell us. How accurate is the 80% usually in real life? How good is any guess about how much longer it will take?

The agile team is 50% done based on done-done stories out of a total of 120 SPs. For 5 of the 6 sprints, all the feedback from the Sprint Reviews has been fixed. We did the riskiest work. We know our Velocity (productivity rate) better (more accurately), the future work is better known and better estimated (another 60 SPs to go), and we have made improvements (aka fixed impediments).

If you could keep only one Team (waterfall or agile), which would you keep? I think the agile team. And I made it a contest by putting the agile team at only 50% done. (That low almost never happens in real life.)

What’s Included in the DOD?

Here’s an example we typically use for software stories; conceptually the basics are the same for about any product.

Using [Req’s] is meant to suggest better requirements (than we used to have). I always mention “better requirements” or better details because that is so important. Technically, better requirements are part of the ready-ready criteria (some people are calling this the Definition of Ready or DOR), but it is important to mention now. This is key input for the Devs to get a story done-done.

“It is amazing how much more work they can get done if they know what they are doing, and how much less work they get done if they have no flippin’ clue what they are doing.” So, we want clear requirements. (The saying also applies to their skill sets, but normally this is much less of a problem.)

Here’s an example of starting the DOD:

[Req’s] (better than ever before)]

• Analysis and Design: keep this short
• Coding
• Code Review: fix problems
• Testing

– Unit Testing: automated, fix all bugs
– Functional Testing: automated (80 percent), fix all bugs
– INT/REG Testing: automated, fix all bugs
– Any other testing…

• Documentation
• PO Review: fix any problems

The DOD is used to decide whether the work on that PBI or story is done; eg, did your team score the two story points on Story 38 or not. It’s part of the “rules of the game” for the referee. There are no partial scores — it’s either done-done or not done.

A Few Comments…

My example assumes we are building a software product.

We want clean, good code, well-written code; code that anyone could understand and modify.

We want to fix all the bugs. OK — we do allow people to come to the PO and make a case that “this bug does not have to be fixed ever.” That’s the only argument, that we will never have to fix this bug or defect; never, ever. (Remember: The bad news does not get better with age, and you have to slow down to go fast.) Very rarely the PO may agree not to fix the bug or defect now. The bug is then moved to an “issues” list (you might call it by another name). Usually at least half of these bugs (so moved) must be fixed later at much more cost, probably 25x more cost. You shot yourself in the foot.

Functional Testing is called lots of other things. It is the testing done by your good QA or testing people (who are as dedicated as the other Team members on your Scrum Team).

Notice, at first, we recommend 3 levels of testing: Unit Test, Functional Tests (or QA Tests), and Integration / Regression Tests. That is about all a new agile team can do. Later, you should add more testing into the Sprint. But at the beginning, that’s a good start.

We recommend that some documents are updated every time we do a story. In my example, you see the 4 dashes, meaning 4 docs are updated this way. There is a longer discussion about which documents those are and exactly what that means.

Having no documentation is unacceptable. and no documents being updated (however much or little) each time we do a normal story is something I just cannot imagine happening with any professional team.

The PO Review is important. We want a mini-demo each time a story is done, or almost done. The PO can say, “Now that I see it, it’s not quite what the customer will want,” and ask for some changes. The PO cannot add all or part of another story at this point.

The Developers will say, “But we built it according to the spec,” (and usually they will be correct about that) and then ask, “Why wasn’t this new information in the spec?” (the enabling spec or in “the details”).

There is not a happy answer to that question. The Developers should have asked the question earlier (but they didn’t) and the PO should have answered the question earlier (whether asked or not). The Business Stakeholders should also have clarified things in the Sprint Planning meeting better. Nonetheless, we have to accept that the PO (and others) will still learn things later than they should.

This practice (of the PO Review) does not allow the PO to be irresponsible and learn just anything later. But, we must accept that once he or she sees the built story, the PO may discover that it must be changed. As long as the change is within the scope of that one ticket (that one story), then the change must be made before that story is done.

Have we really made progress if the customer will not be happy? No. So, it ain’t over ‘till the customer is happy (or until the PO thinks the customer will be happy).

Is the PO always right? No, but we have to have some independent person decide quickly. The PO (or anyone he or she designates) is that person.

There should be some thoughtful discussion, such as, “Why didn’t we discover this problem earlier?” It is not a blame game, but rather a search for the root cause and an attempt to become better as a team, for next time (eg, next Sprint).

We want about one mini-demo of this sort each day. (I am assuming eight or more stories in a 2-week Sprint.) Therefore, for example, all the testing is not done at the end of the Sprint. Most of the eight or more stories should be done before the last two days in the 2-week Sprint.

Impediment List

The most important thing a ScrumMaster does is remove impediments.

Anything that slows us down, or anything that could be improved (fixed or mitigated) we define as an impediment. Further: An improvement that has not been implemented yet is an impediment.

What Is an Impediment?

Just about anything can be an impediment, but how do we define it?
One way: Anything that is slowing down the team.
Another way: Anything that can be added, fixed or mitigated, and the result is: things are better for the Team.
Yet another: Anything that is imperfect in the Team, right around the Team, or, really, anywhere that could affect the Team.

If you define impediments that way, then there are hundreds or thousands of impediments at any one time. Hence the need to have a list of only 20 items and prioritize the list.

Here are some examples of the varieties of impediments:

• Technical debt
• A bad boss
• Someone who does not understand Lean-Agile-Scrum
• A hurricane
• A power outage
• A server that falls over
• Lack of automated testing
• Continuous integration that is not good enough yet
• A culture that does not fully support Lean-Agile-Scrum
• The matrix organization
• Distractions to people on teams or to whole teams
• Having people (in a Team) work on more than one release at the same time
• The team room is too small
• Insufficient skill sets on the team
• A PO that is not good enough as a PO yet
• Confusions about what the story is
• Unresolved technical issues
• Inability to make decisions quickly (by the PO or by people in the team or by people outside the team)
• Someone on the team who is not a team player
• Lack of self-organizing or self-managing in the team
• Lack of knowledge about a method X language (eg, in C++)
• Lack of DBA skills within the team
• Need to refactor the architecture
• Lack of baby sitters for some team members
• Someone getting a divorce
• The company’s recent re-org
• One person distracting the team too much

So, to name broad categories of impediments, we might have a list like this:

• Technical impediments
• Distractions
• Blockers to specific stories
• Organizational impediments
• Culture
• Insufficient education or training on Lean-Agile-Scrum
• Insufficient knowledge or skill sets
• People issues
• Things not working that were working before
• Basic things (e.g., lack of Team room)
• Things outside the company (e.g., the weather)

But really about anything could be impediment if it slows down the team.

Issues With Impediments

Impediments are not only blockers.

We mentioned blockers, which often is not a well-defined term. Typically, “blocker” refers to an impediment that stops one story from being completed in this Sprint. Blockers can be important impediments. The key thing to remember is that blockers are not the only type of impediment. There are many other types (see the list of types above).

One of the key impediments that arises a few sprint in is: the PO sucks. OK, a little dramatic, but commonly true. That is, the PO is typically very good at his or her prior role. But that person is not used to this very different new role of PO. No training, not fully dedicated, no experience in many parts of the job, no great PO to learn from. And the relatively weak performance by the PO makes a big difference for the Team.

Impediments can (and always do) include “things around here that have been here for ages that no one has ever tried to identify, much less fix.” That is, we’re asking fish to identify water – this is part of the problem. It is almost that bad and that hard.

So, you have to ask the team (and others) to think much differently. Imagine that anything could be fixed and put those “it would never be fixed” things on the list. Then, especially if you are the SM, you must figure out how to get them fixed or mitigated. Get the solution (or partial solution) implemented.

Addressing Impediments

Some impediments are initially expressed more as symptoms than as root causes. So, very commonly, we must identify the root cause.

This means someone — probably the team — must do some form of root cause analysis (RCA). This might be done with the “Five Whys” technique or with other simple tools.

Some impediments can be fixed, and some impediments cannot. The ones that can be fixed, we recommend that you break up the work into chunks that can be completed within a Sprint (ex: 2 weeks). Then complete that work, and, start to accrue some benefits. At least we hope and expect. And, once we get used to this, I think it is generally possible.

Again, some impediments cannot be fixed, such as a hurricane. But the impact of the hurricane can be mitigated; that is, the impact on the team can be reduced to some degree almost always. So, we take mitigation steps.

Who Fixes Impediments?

Who fixes impediments?

Well, obviously a typical SM is good at fixing certain types of impediments himself or herself, but no SM is good at fixing all types of impediments.

Also, the Developers can and should invest some in fixing impediments, and similarly, the PO.

Also, people outside of the team (managers, consultants, whatever) can be excellent at fixing certain types of impediments.

The SM has to draw on all these different people and try to find the best person for this particular impediment. Once a person or small group is identified, the SM must “smooth the way” for them to fix that impediment quickly. The SM must do this with no authority, no power. The SM must convince with logic and reasonable persuasion.

Product Backlog Refinement

Introduction

We have wriiten a book on Agile Release Planning. See here.

In that book we discuss this topic (PB Refinement) at some length.

The key idea is that the Team is continuously refactoring the product backlog, in each sprint. Continually learning. And there is continuous change in many dimensions.

The two PB Refinement Meetings

First, we recommend 2-week sprints. And a Team of 7 (including the PO and SM).

So, in those conditions, we recommend a “short-term” PB Refinement meeting in the second week, before the Sprint Review and the Retrospective.

In that meeting the Team gets to vote on the quality of the details provided (or organized) by the Product Owner. The key purpose of this meeting is to enable the Developers to give their feedback on the information (details) that the PO has had prepared for the 8 stories in the next sprint (I recommend that each sprint have at least 8 stories).

Any one Developer can blackball a story.

Why? Because there is a notable dependency, and the Team cannot complete the story in the sprint. Or, because their are insufficent details to complete the story.

It is also typical for the Devlopers to have a few “last” questions to be answered for several stories. Then the PO needs to get those questions answered before the next Sprint Planning Meeting (in a few days).

The other PB Refinement (or Grooming) meeting is what I call the Long-Term meeting. We recommend in the middle of the first week of the Sprint. There, we can re-do anything that we did in the initial Agile Release Planning.

The most likely activities are:

• Write or discuss new stories
• Break up stories
• Vote or re-vote Business Value Points
• Vote or re-vote Story Points

These are done as much as needed based on what we have learned in roughly 2 weeks.

The Results

Then we re-calaculate the ROI factor for relevant stories.
Then, based on this new new ROI and the new average Velocity, we can:

• Re-organize the Product Backlog based on an improved understanding of Velocity or Risks, Dependencies, Learning, or MMFS/MVP.

All this is explained in more detail in the Agile Release Planning book.

Attendees / Time Boxes

We recommend that the whole Team attend each PB Refinement meeting. We need the feedback and learning from the whole “complex adaptive system.”

Should the four Business Stakeholders (BSHs) attend?

At first, it is very common that the BSHs do not have time to attend. No one expected them to need time to come to the Refinement meetings. In fact, typically the BSHs are not consistently attending the Sprint Planning meeting and the Sprint Review.

Later, we hope to get the manager of each BSH to agree that they will have the time for the PB Refinement meetings as well.

We recommend both these PB Refinement meetings be given a 1-hour time box.

Remember that you are asking them to take time away from “real work”, as they commonly call it - from building and testing the user stories.

So, you must run these PB Refinement meetings efficiently and effectively. That’s a skill that the SM learns, but also a skill that the whole team learns with time.

Doing the PB refinement well will help us be more successful. It is important. And take some effort to learn how to do these PB Refinement meetings better.

Special Topics re Agile-Scrum

Here are 4 special topics.

You Must Self-Organize & Self-Manage

It is fine to give you the Scrum framework, which is bare bones.

What is essential is for the Scrum team to use that framework to help themselves self-organize and self-manage successfully.

Let us say this another way. Some people treat Scrum as a silver bullet. They seem to think that Scrum by itself will make everything better, without the people lifting a finger. No doubt you guess from my tone that I do not agree.

What does this mean? What does self-organizing and self-managing mean?

It is not well-defined. “Make it happen” some people will say. “Just win baby” is a simialr famous sports quote. “Deliver a wonderful product to the customer” is another common phrase.

Another way of saying it is: Do whatever it takes. Build the release, do the work, make the improvements (in the way of working) happen, get the Product Goal or mission accomplished.

This is for most team members either a totally new experience or at least an uncommon one.

Ok, let’s not exaggerate. Growing up, getting married, having a baby, buying a house – these are key things that require you, with others, to self-organize and self-manage. And most people can do those things, at least with some level of success.

Scrum does not say what, specifically, to do. Ok, yes, we recommend the roles, the meetings, the artifacts. But, how to work together, and “what to do when” to get to product success in your case - Scrum itself does not answer that. Scrum assumes the Team, collaboratively, will do that.

In fact, probably more essential than Scrum to gaining success, is that the Team self-orgaize and self-manage.

All adults, even most children, know how to self-organize. At least some.

One key problem for work: Many adults have been taught, or feel they have been taught, NOT to self-organize. “Don’t do anything till I tell you what to do.” They have heard that. Sometimes, despite the “order from the boss”, they self-organize or self-manage nonetheless. But the bigger point is, the agile advocate (SM?) commonly must take them by babysteps toward the ocean of self-organizing.

It is not that they cannot do it at all, but just that they will stop doing it or slow down a lot in certain circumstances.

Example One: They feel they are not supposed to self-organize. They have been trained that the boss will tell us what to do.

Example Two: They have been trained that “we cannot do Y until X has been completely done” (the basic waterfall idea). The signal that X has been completed has not been given. One can of course imagine that that idea (wait for X to be complete) can make sense in some situations. (But we think generally that idea is not relevant in our work.) One can also imagine where waiting for perfection on X will never come – this is mostly our case with our kind of work.

Does a self-managing Team mean that we no longer need managers?

No! This is a mis-understanding. We will always need a manager and managers.

We want the managers to teach, situation by situation, how to self-manage. We want the manager to (help) remove some impediments. We want the manager to help optimize the Team for overall success. We want the manager to help the Team work with other people and teams and groups in the organization. And, if all hell breaks loose, then the manager must make some fast decisions, and get chaos under control.

In our view, this is better for the Team (they get to work at a higher level of responsibility than before, to the degree they are capable of it). And it’s better for the Manager. It is easier and more fun to manage the Team rather than the individuals. You don’t have to get involved in obvious decisions. But on the important and interesting decisions, you get called in.

Putting It Together

What is Scrum? Is it the practices? Is it the ideas? Is it the values?

Many say that if you do not “get agile”, then you can do a bunch of practices, but it won’t make much difference.

I am not sure that is true, as in causation.

I do think it is likely that - the more one gets agile, the more one does it with the right intention and well. And that will make a difference in terms of results.

In any case, you must assemble the pieces and parts of agile-scrum together with your people. You and the Team must figure how to make it work.

This is hard in some ways. A common way is that people will not like to tell the truth (often about themselves) or they will not see the truth (eg, in a Sprint Review). Maybe Scrum is somewhat counter to the existing company culture.

You and the Team and others must put it all together.

Another thing. If you are doing software, then you must meld Scrum and the Team with, eventually, the other good practices in XP (Extreme Programming).

So, once you have the basics of Scrum going, you all must meld it with other ideas and practices.

This is work. It can be hard. There are many people and things to guide you (and you need to ask for help). It is quite do-able.

Managers and Scrum

Managers are essential, says Jeff Sutherland.

We discussed this topic, in part, earlier under “Self-Managing.”

In what way does he mean that?

First, I think he would say that managers must help the Teams learn how to self-organize. Or self-organize better.

Then we must explain the new role of a manager in Scrum. Just reading the old reports will not cut it. It is actually a better life, where your real skills come into play. A good manager is invaluable.

But, secondly, a manager must do something if a Team is self-destructing. If the Team is about to drive off a cliff.

---

Giving support for self-organization is not the only thing a good agile manager does.

The next key thing is to support removing impediments. For a Team, the impediment-remover-in-chief is the ScrumMaster. But the Team must always get help from other people. And often help requires that the manager say yes. Yes to giving us people, or money, or just approval to change things.

Allocating the people (resources) is an important job of the managers. Often we don’t need people to “fix an impediment” (or we don’t think of it that way), but we need people to work with us or to share knowledge with us.

We need to also talk about servant leadership, and leadership in general, within the firm. But that is for another day, outside this fairly brief Scrum Introduction.

Change and Scrum

Just doing Scrum starts to change things.

And every time you fix an impediment you are changing things.

So, change is part and parcel of Scrum.

Let us state that more strongly. If you are not notably changing your situation, you are not doing Scrum right. Changing things can be many things, almost anything. Whatever needs to change the most to help the Team be happier or more effective. Or both.

But we must be a bit more honest. When you start to do Scrum, it starts to change everything. At least that is what is commonly said. Mostly true.

Neither I nor Scrum are prescriptive about how fast change must happen.

This is an important issue. Do try to make change happen, but equally, reassure people that we will try to maintain a reasonable pace of change. Discuss this, over time, to assure you’re going at the right speed.

Ideas Behind Scrum

As you recall, we mentioned many of these ideas quickly in the beginning of this book. The Scrum Values (above) are also key ideas behind Scrum. Here’s more.

Agile Manifesto and Agile Principles

First, we must mention the Agile Manifesto.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

See: agilemanifesto.org

One could spend some paragraphs trying to explain what those lines really mean.

Then we have the 12 lines of the Agile Principles.

Here is my summary of them, very quickly.

1. The Customer is important. Deliver something useful fast.
2. Welcome change, or at least accept it. And do the best you can with it.
3. Deliver working software more frequently.
4. Business people and developers must work together daily.
5. We want to set the Team up for success, with motivated individuals, and then we trust them.
6. Use face to face conversation more. Strongly preferred.
7. Working software is the primary measure of progress.
8. We all should work at a sustainable pace.
9. Technical excellence and good design are key to achieving the benefits of Agile.
10. Simplicity is essential. Less is more, almost always.
11. The best solutions arise from self-organizing teams.
12. The Team regularly reflects, learns, and takes action to become better.

Scrum Values

There are five Scrum Values: commitment, courage, focus, openness and respect.

It is through Scrum that the Team learns to live these values more fully.

It is worth thinking, from time to time, what those words mean, and specifically, what they might mean in the context of working together as a Team.

The Scrum Guide 2020 has a short paragraph that uses all five words, giving some meaning and context. Let’s add a bit more about each word:

In the Sprint Planning Meeting, the Team commits to the Sprint Goal and the Sprint Backlog. Hopefully, this reasonable commitment enables them to win the game at the end of the Sprint (that is, to deliver what they “promised”). Note: This commitment or promise is never a guarantee.

During the Sprint, the Team, as professionals, works hard on staying focused and not getting distracted.

The Team has the courage to be more honest and transparent than ever before. The Team has the courage to take on difficult missions, and see if they can master them. The Team has the courage to learn from failure (hopefully mostly small experiments, Mr. Edison). Each team member is open to developing new skills that might help the Team.

The Team members respect the people they are working with. While they may become frustrated, they express this frustration in a respectful way. They also respect that people are human, and everyone makes mistakes. While each person is respectful, this does not mean they blind themselves. As needed, they give their teammates and others respectful and honest feedback. (Easier said than done.)

Other Ideas

Then there are LOTS of other ideas behind Lean-Agile-Scrum. I plan to write another book that starts to cover them all.
But let me mention two or three now.

One is the 6 Blind Men and the Elephant story. Google that. This is an ancient story, we don’t know how old, but we do know that Buddha used it, roughly 2500 years ago.

To me, the key point is that no one person understands the whole elephant, and that each person touching the elephant (each team member) has something valuable to say, that will help us. It is the Team’s job to work and “fight” and discuss with each other, and then discover or comprehend more about the elephant as quickly as possible.

Another key idea: The bad news doesn’t get better with age. That is, it helps to be honest with ourselves about the bad news, and then deal with it sooner.

Key: Almost every time it is significantly cheaper (and faster) to fix the bad news now. If we wait 2 weeks, it is typically 20-25x more expensive to fix. Using this idea will speed things up too.

Next key idea: experimentation and learning.

Knowledge workers learn together. And mainly by doing experiments and seeing how they turn out. We are learning our way through a complex problem set that has multiple dimensions. Some examples: What are the needed features now? Who understands the details? How much time can we take? What should the product look like? What would form a minimum viable product? Will this new technology work? How do I understand these new people I am working with? How can we work together more effectively?

Experimentation reminds us of the famous story of Edison and the 10,000 light bulbs.

Experimentation means that we will have successful and unsuccessful experiments. Or, to put it Edison’s way, all experiments are useful but only some have positive results.

This brings up Yogi Berra’s saying: “I knew I was gonna take the wrong train, so I left early.” That is, we have to allow some contingency for “mistakes” (in the experiments) and also for mistakes (those things that happen with human beings). And for other things (Ex: In 2018 Hurricane Michael hit the Florida panhandle.)

There are many many other key ideas that support Lean-Agile-Scrum. More to discuss later.

You should be learning and re-learning these ideas with your Team. That learning will help them use Scrum (and Agile and Lean) more effectively.

Key Questions, Myths, Mis-Understandings

• Is the SM the boss?

No. The SM has very limited power. The SM is not like the old Project Manager (or at least what people thought the PM was – the boss).

The ideas in agile-scrum encourage knowledge sharing by the knowledge workers. Having hierarchy and higher power-distance ratios does not improve that sharing and that collaboration.

• Does each of the Developers have a personal velocity?

No. Velocity applies to the Team. Really a result of everything done by the whole Team. Obviously, the Developers (these include coders and testers in software) working collaboratively are the main drivers of the Velocity. But they do it together, not each person in isolation. Scrum is team-oriented and much more collaborative than other approaches.

In fact, the Velocity is a function of the efforts of everyone on the Team (Developers, SM, PO) and others. But the “real work” by the Developers is key.

• Does Scrum mean we stop doing estimates and planning?

To the contrary, we spend more time estimating and planning than we did in waterfall. And we do it in such a way that we get more benefit (learning mainly) at less administrative cost.

Another difference is we always expect change and learning, so we never believe in a plan. Any plan. But we understand the benefits that planning gives us.

See other comment earlier, in the Sprint Planning meeting section, about estimating and in the PB Refinement section.

Recommended Reading

A Scrum Book See also this site: ScrumPLOP.org — We cannot recommend this book and this site enough. First, it is a list of patterns.

Some people prefer the following website, here. It is essentially the same information organizes a different way.

If you do not know about Pattern Languages, read the Wikipedia article here, https://en.wikipedia.org/wiki/Pattern_language. You might want to read, or at least look at, Christopher Alexander’s book, “A Pattern Language”. The idea has, at least in some way, been around for millenia (one imagines), but Mr. Alexander (an architect) is famous now for several books, and “A Pattern Language” is maybe the one that made the concept more well-known recently (he has other books that also helped). Many people in Agile were strongly influenced by his Pattern Language idea. Jeff Sutherland speaks of Scrum being a collection of patterns.

Some key points: First, we strongly endorse the idea and use of patterns. Second, ScrumPLOP.org is available 24/7. Third, it is curated by Jim Coplien and Jeff Sutherland and the ScrumPLOP team (a lot of great people). Enjoy!

Toyota Production System by Taiichi Ohno. Strongly recommend this book. Seems to be about automobile manufacturing. In fact, the first 4 chapters are about your work.

Extreme Programming Explained by Kent Beck and Cynthia Andres. If you are doing software, once you get the basics of Scrum going, you must start adding things from XP (as Extreme Programming is called).

Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland.

Agile Project Management with Scrum by Ken Schwaber. Very useful because it has small stories that explain, in story format, lots of ideas and key issues around Scrum.

Some Relevant Sayings and Quotes

“I learned this, at least, by my experiment; that if one advances confidently in the direction of his dreams, and endeavors to live the life which he has imagined, he will meet with a success unexpected in common hours.” — H.D. Thoreau, Walden

“Whether you think you can or you can’t, you’re right.” — Henry Ford

“You miss 100 percent of the shots you never take.” — Wayne Gretzky

“If you don’t set goals, you can’t regret not reaching them.” — Yogi Berra (who earned 10 World Series rings)

“Take it with a grin of salt.” — Yogi Berra.

“Things should be as simple as possible, but not simpler.” — Albert Einstein.

K.I.S.S. (Keep It Stupid Simple)

“Do the simplest thing that could possibly work, and then test.” — Ward Cunningham.

“I’ve missed more than 9,000 shots in my career. I’ve lost almost 300 games. 26 times I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life, and that is why I succeed.” — Michael Jordan

“Everyone has a plan ‘til they get punched in the mouth.” — Mike Tyson.

“If you wait for perfection, you might wait too long.” — Joe Little.

“People are remarkably good at doing what they want to do.” — Joe Little.

“Everything is impossible until it becomes easy.” — Goethe

“The road is long
With many a winding turn
That leads us to who knows where
Who knows where
But I’m strong,
Strong enough to carry him
He ain’t heavy, he’s my brother.”
— The Hollies (Russell & Scott)
Note: This, the latter part of the song, can be read in a moralistic, very self-righeous way. For Scrum, we are not recommending that. It is, after all, work. But, we must have patience for many people, including patience with our colleagues (and of course ourselves). An impatient patience we recommend. I mean a good balance between an impatience to act quickly and deliver quickly, and a patience that everyone is imperfect.

“Most people do not really want freedom, because freedom involves responsibility, and most people are frightened of responsibility.” — Sigmund Freud

“All of me - why not take all of me.”
— Marks & Simons (from the song “All of Me”)

“Although human beings are incapable of talking about themselves with total honesty, it is much harder to avoid the truth while pretending to be other people. They often reveal much about themselves in a very straightforward way. I am certain that I did. There is nothing that says more about its creator than the work itself.” — Akira Kurosawa, a great movie director

“It is more blessed to give than to receive.” — Jesus

“Everything changes. Nothing remains the same.” — Buddha

“Bhikkhus, all is burning.” The beginning of the Fire Sermon by Buddha. Comment: The desires of our customers can never be quenched. Desire (fire) is neither good nor bad, but to avoid the pain, we must learn to step back from it.

“In theory, there’s no difference between theory and practice. In practice, there is.” — Yogi Berra

“I knew I was gonna take the wrong train, so I left early.” — Yogi Berra. The train for Yogi is a subway train in NYC.

“It ain’t over ‘til it’s over.” — Yogi Berra

“90 percent of baseball is mental, and the other half is physical.” — Yogi Berra.

“Don’t believe half the lies they tell about me.” — Yogi Berra.

“The bad news doesn’t get better with age.”
Source unclear. I say this frequently. There are other similar quotes. Colin Powell has one.
In our work, the bad news gets typically 20-25x more expensive to fix in 2 weeks.

“If you don’t change things, nothing’s gonna change.” — Joe Little (after Yogi Berra). I am being a bit sarcastic. It is similar to the old saying “You can’t make an omelet without breaking some eggs.” In the end, most change is moving from stupid to less stupid – and that’s a lot of help.

“If you wait for perfection, you might wait too long.” Joe Little

Quality Is Free. Title of a book by Philip Crosby.

“I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived.” H.D. Thoreau, Walden

“One is asked, then, to accept the human condition, its sufferings and its joys, and to work with its imperfections as the foundation upon which the individual will build wholeness through adventurous creative achievement.” Robert Greenleaf in his essay “The Servant as Leader”

Feedback

Please send feedback and suggestions to Joe Little.

This is a work-in-progress, for now, but this edition is getting close to complete. We will be adding to it, modifying it, tweaking it a bit longer. We want your suggestions.

Some kinds of things you might suggest:

• Typos
• Poor grammar
• What to say more quickly
• What to expand on
• What to add
• Which new book to write

Thanks!