The Story of Scrum
Notes taken from Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
How Startup Scrum is like Rugby
Startups face a different challenge from traditional commercial projects; the latter have established processes for bringing a set product to completion, whereas with startups it’s more open-ended.
When there’s more than one path to the end-zone, our tendency is to drift and stay in “discovery mode” too long, rather than iterating on small-scale tasks and getting things doing. Scrum is a process to hone in on the things that need to get done, while balancing the acquisition of new knowledge to make better predictions amid uncertainty about what the product is becoming.
You can’t get the plans right up front. Up-front planning encodes our ignorance.
Construction and manufacturing projects use a sequential development process to meet precise requirements and deliverable milestones. Here, up-front planning is critical.
In scrum, details of the requirements are negotiated through continuous conversations, “just in time,” and “just enough” to start building functionality to support those requirements. For innovative projects, it represents a 70x improvement over the waterfall method, since you don’t know those features that will be needed, and which were envisioned at the outset that can be dropped. It results in less wasted time; more progress for the effort; more agility.
Scrum aims to create the unique single instance of the product, not to manufacture the product.
Items move from a Project Backlog to more detailed PBIs (project backlog items), into a sprint, where content/features are designed, built and tested in small, fail-safe increments.
Dialogue as Passing the Ball
Conversations between stakeholders, product owners, and the development team are used to refine and splice broad PBIs into detailed PBIs. Timely conversations are like passes in rugby. They resolve ambiguity that arises in writing, and spark new ideas that keep the ball moving down field. Emergent opportunities need to be embraced and exploited quickly.
Conversations don’t replace the project backlog document — they help with progressive refinement.
User Roles
Here are the main roles on a team employing scrum:
PRODUCT OWNER — Manager. Synthesizes and presents a vision. Decides on features and functionality, and the order to build them. Accountability: Makes sure most valuable work is being done, whether an internal application or product. Defines satisfaction criteria for what counts as done done. Collaboration: must have people skills to collaborate with internal and external stakeholders. Envisioning: The input for envisioning is an idea that has cleared the strategic filter — i.e., is consistent with the strategic direction of the company.
SCRUMMASTER — Servant Leader. Helps team embrace scrum values and practices. Interference: Removes impediments to productivity. Asks “what can I do to make the team be more effective today?” Other qualities: Transparent, knowledgeable, patient, collaborative, protective, questioning. Not a full-time role — can also be a member of the team.
DEVELOPMENT TEAM — Executors. Self-organize to determine best way to achieve goals of product owner. Inspect and adapt each day. Groom the product backlog (see grooming below).
INVEST in User Stories
Anything that gets into the product backlog should be based on a story about a desire, for the customer or someone on the team. The big picture product/service is goal oriented, as are the building blocks: stories. If our stories are too detailed, we get lost in irrelevant details. However, they need to be broken down to be manageable.
Three Cs of Stories
1. — Card: Small enough to fit on 3 x5:
As a <user role> I want to <goal> so that <benefit>.
2.— Conversation: an ongoing dialogue. Use story is a promise to have the conversation. Might be based on a document or article.
3. — Confirmation: what are the conditions for satisfaction?
Stories should also have the following qualities:
I — independent. Write stories that minimize interdependencies.
N — negotiable. Give flexibility on how the story is solved.
V — valuable. Duh.
E — estimable. Should be able to estimate the size of the project.
S — small. Bring epics down to smaller size for sprints.
T — testable. Epics don’t need tests because we don’t build them directly. But our smaller tasks do. Most tests will fail, but the small story failures can still add up to a successful epic.
Knowledge acquisition is another kind of story. Prototype, proof, study, spike. The question is whether additional exploration is more costly than the benefit it provides.
Stories can be developed top-down — starting with “epics”, i.e., the full vision or product— or bottom up, starting with stories related to the next release of an existing system. Users/customers are better critics than they are developers of stories, but they can be developed by imagining certain user roles.
Sprint, But Not to Exhaustion
In rugby, as in scrum, there is rapid, “all-at-once” movement down the field, with lots of bi-directional communication (passing), and helping one another get the obstacles to progress out of the way.
Work Cycles & Flow:
Once the product backlog — prioritized list of desired features — has been broken into smaller tasks, the team sprints to get those features built.
SPRINT PLANNING SESSIONS allow team members to prepare their thoughts on what their priorities are, pull out the highest priority PBIs from the product backlog, and estimate the amount of time it will take (ideally).
SPRINT REVIEWS allow team to inspect and adapt the product and inform outside stakeholders (the pigs inform the chickens, and the chickens give feedback).
SPRINT RETROSPECTIVES allow team to inspect and adapt the process. You can generate insights, based on a mixture of objective data (what happened, and when?), and an emotional or subjective register of what worked and what didn’t. This is the time to reflect — to “stop bumping along and think.”
Having a steady cadence helps the communication flow smoothly.
Emphasis on completion.
Within a sprint, it’s important to stick to the same goals. Changing goals is demotivating, but abnormal termination can be employed if some unusual circumstances warrant a change in sprint goals. Remember that emergent opportunities must be acted upon immediately.
Clarification, yes. Change, no.
Small goals with specific criteria for satisfaction allow you to get things done. Done-done. These should be towards the top of the project backlog, while larger sized goals/stories are at the bottom and should not be worked on so soon.
The project backlog is a stack of items, ranked in order of size and priority, which must be periodically groomed — assessed and refined with smaller ones on top. The product owner leads this process about once per sprint, rearranging the items in the stack, deleting those that are no longer needed, and inserting smaller more detailed items closer to the top of the stack.
Marginal Economics
You are only interested in the next step. Don’t worry about sunk costs.
Ask whether the next investment in the current product is economically justified? If not, determine whether to pivot, deliver, or terminate the product. In other words, Fail fast.
Emphasis on Velocity
Hurry but don’t rush.
Sprints must be sustained over an extended period. The purpose of the sprint is to stay focused on small, frequent releases, not to work to exhaustion.
Planning poker is used to estimate the amount of time for each task, and achieve a consensus, while engaging in intense discussion. It helps you see what your priorities are and size items.
Daily scrum meetings should take no longer than 15 minutes. If a team member needs more time to discuss an item, the product owner should make time after the meeting.
Adaptation/Managing Complexity
In the realm of uncertainty, you want to make decisions at the last responsible moment, when the cost of deferring (which increases over time) is just starting to exceed the cost of deciding and committing to a particular course of action. You have to balance prediction against adaptation.
Minimizing assumptions minimizes risk. You can use validated learning to confirm or refute an assumption, turning unknowns into knowns. If you don’t discover a false assumption until too late, the cost of change grows. Scrum seeks to make change less costly each step of the way.
Sprint cycles function as learning loops.
Each sprint involves inspecting and adapting, so that whatever item people are working on, it will not cost too much if it ends up being a failure.
Variability: The Three kinds of uncertainty:
Ends — “what” uncertainty? What are you producing?
Means — “how” uncertainty? How are you going to add the feature/build the product?
Customer — “who” uncertainty? Who is the product/feature for?
These questions are best answered by the product owner, through intense discussion in scrum meetings, sprint planning sessions and retrospectives.
How Scrum is Not Like Rugby, or, There is No Endzone
There is no end-state that corresponds to agility. It is an on-going flow that must be inspected and adapted to your team’s needs.
For example, if you are not building software, you may not encounter the exact phenomenon of “technical debt,” or “the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.” However, you are likely to discover some things from past iterations of your product and/or production process that continue to haunt you down the line. This is the trade-off of agility versus up-front planning.
Values
Trust/Confidence — When failure is a feature, not a bug, people need room to experiment and make mistakes. There needs to be a safe atmosphere without tendency to cast blame.
Open collaboration — honesty and courage, transparency are required for the constant communication (i.e., the passing maneuvers), and to cut down on unnecessary ambiguous written documents.
Patience — “hurry don’t rush” may sound like a distinction without a difference, but there is a mindset that corresponds to going quickly, but checking off the important boxes, and keeping your eyes shifting ahead, beside and behind you at all times.
Joy — “Joy is just a canvas for your grace and brightness.”
