Every once in a while I start thinking too hard and I ask myself: “What is Scrum, anyway?” Sometimes the answer is complicated, and sometimes it’s simple… depends on my mood, I guess…
The basic idea is pretty simple. Have some work to do, and a (small) Team to do it. Make sure the Team Members have all the skills and knowledge they need to be able to do the work. Have one person on the Team determine what to do next, let the Team figure out how to do it and get it done before moving on. The Team has frequent meetings to discuss their work, and periodic meetings to figure out how to improve what they’re doing, and how they do it. And that’s it… there is not really any more than that.
We see teams like this all over the place: on basketball courts, in restaurant kitchens and food trucks, in repair shops, in the military, on construction sites, and so on… But we’re geeks; we like to model things, we like to describe things, we like to make rules about things. So, we see this stuff going on, and we say to ourselves: “This is good stuff! What is going on here? How do I make that happen? What do we call it?” And we invent things like “Scrum” and “kanban” and “Small Unit Leadership” to describe what we see.
We can’t help ourselves…
So, since I’m a Scrum guy, let me describe, in a very simple, idealized, way, the basic Rules of Scrum as I understand them. Since every Scrum Team Produces Results, whether it be Developing Products, Providing Services, Cooking Meals, Building Houses, whatever… I’m going to stick to the “Produces Results” language. Different environments use different terms to represent who they’re Producing Results for — like Clients, Users, Customers, and Stakeholders — and it’s often very complicated. I usually think of this as the “Stakeholder Swamp,” and will simply refer to the members as “Stakeholders.” My goal is to describe something I can instantiate (in some cases, at least) and be able to explain to anybody.
Scrum, as it’s usually defined, is about a single Team, managing its Flow of work one Sprint at at time, that is co-located with the Stakeholders it is Producing Results for. This is what the basic Rules of Scrum describe, and I will call this “Atomic Scrum.” I like to think of this as the “Five People in a Garage” kind of Scrum. The Developers and the ScrumMaster are inside the Garage, working away, while the Product Owner is standing in the side door of the Garage talking to the Stakeholders.
The Rules of Scrum
- Backlog: The Scrum Team works from a Backlog, which is a ‘pile’ of Items that represents the work the Team will have to do in order to produce the Results the Stakeholders are asking for. The Backlog is a “living” thing; it is constantly changing and being refined in order to represent the most current information available to the Scrum Team and the Stakeholders. The Backlog may have Items of different types on it…
- Low-fidelity items (Epics) often represent the Results the Team will produce.
- High-fidelity items (Stories) represent work the Team will do in order to produce those Results. These Items may include Chores — work that is necessary but doesn’t actually produce the Results being asked for (example: in a restaurant the Results may be meals for Customers, and ‘do the dishes’, ‘shop for ingredients’, ‘mop the floor’, and ‘prepare the spaghetti sauce’ are Chores that must be done as well). In addition, each of these Stories will have a definition of “Done” associated with it, either explicitly or implicitly. This definition of “Done” includes a description of what work will be done, as well as the appropriate Standard of Care to use while doing it.
- Scrum Team: the Scrum Team is a self-organized, cross-functional, value-driven group who, amongst themselves, have all the skills and knowledge necessary to get the Items on the Backlog “Done.”
- The basic Responsibility of the Scrum Team is to move down the Backlog, working on one (or a few) Items at a time. They do their due diligence and use the appropriate Standard of Care to get each Item “Done” as quickly as possible without wasting time or doing unnecessary work. Each Team Member is accountable to do his or her best to help the Team with this basic responsibility.
- One of the Team Members is called the Product Owner, who spends about half of his/her time in the Stakeholder Swamp in order to help define what the appropriate Results should be, and spends about half of his/her time with the Scrum Team in order to help the Team understand how to produce them. The Product Owner manages the Backlog so that it represents the current understanding of the work necessary to produce the appropriate Results; and it is likely that the Product Owner will have to get help from Stakeholders and other Scrum Team Members to do this. The Product Owner is accountable for knowing what work the Team should do next, and why.
- Another of the Team Members is called the ScrumMaster, a servant-leader who improves the Team by helping the team remove impediments to its teamwork and production activities; helping the Scrum Team become more self-organized, more cross-functional, and more value-driven; and, in particular, helping the Product Owner work better with the Stakeholders and the rest of the Scrum Team. The ScrumMaster is accountable for knowing what improvements the Team needs, and what is being done about them.
- Feedback and Adaptation: The Scrum Team is working Sprint-to-Sprint, which is a fixed time-box of one month or less. Within this Sprint-to-Sprint cadence, there are the following meetings:
- Daily Scrum: The Scrum Team meets daily in order to discuss the current work situation and get ‘on the same page’ about what is expected to happen today.
- Refinement Meetings: As I said above, the Scrum Team and (some of the) Stakeholders may have to help the Product Owner manage the Backlog. This is often done in special meetings called Refinement Meetings, which have the goal of modifying the Backlog to represent current realities. This is done by confirming/changing the order of the Items in the Backlog, adding or removing Items to/from the Backlog, splitting larger Items into smaller Items, merging smaller Items into larger Items, defining what “Done” means for Items, and so on…
- Sprint Review: At the end of each Sprint, the Scrum Team and appropriate Stakeholders (they must be capable of giving meaningful feedback) review the Results of the Sprint, determining what they liked, what they didn’t like, and what would they like to see next. In other words, this is a review of what was done in order to help decide what to do next.
- Sprint Retrospective: At the end of each Sprint, the Scrum Team has a meeting to discuss its Teamwork and Practices; this is a discussion of how they do their work, so that they can decide how to improve.
- Sprint Planning: At the beginning of each Sprint, the Scrum Team commits to a Goal for the next Sprint, and produces a Forecast of what Items might get done; this discussion is led by the Product Owner and is largely based on the results of Refinement, the PO’s conversations with Stakeholders, and the results from the previous Sprint’s Review and Retrospective.
The Real World
Now, here’s the rub. Almost nobody has this simple situation in the Real World. Atomic Scrum is an Ideal that is seldom realized. Atomic Scrum is our North Star — it indicates where we think we want to go, but we almost never get there. However, you must understand that Atomic Scrum is the basic tool in our toolbox. There are additional extensions, decorators, and practices we need to add in order to make our toolbox more useful to us in our actual situations. The trick is to add/modify what we need to without losing our “Scrummish” personality… and no one really knows what that means. Here are some of the problems we may have to deal with in the Real World (reverting to software-specific language):
- The Team is not co-located with the Stakeholders, not even virtually;
- The Team needs to have a focus on Releases and Projects, and not just Flow;
- We may need to create or modify the Scrum Team itself;
- The Team may not have all the skills and knowledge needed to get Items “Done”;
- The PO can’t spend half of his/her time with the Team;
- The PO doesn’t have the skills or knowledge to help the Team understand its work;
- The PO can’t spend half of his/her time in the Stakeholder Swamp;
- The PO doesn’t have the skills or knowledge to work with the Stakeholders to determine what to build;
- There is more than one Product, each with its own Stakeholders;
- There is more than one Team working on the same Product;
- We need to plan from Release-to-Release, not just Sprint-to-Sprint;
- The definition of “Done” is not ‘good enough’, whatever that means;
- and so on…
This is what makes Scrum fun. Atomic Scrum is easy to describe and understand, but getting Scrum to work in most situations is tricky. Welcome to Scrum!