Asking about Scrum

Leaders and friends frequently ask about Scrum, and common questions include:

• What is Scrum?
• How do I get started learning Scrum?
• Why should I use Scrum?
• Are there any books about Scrum?

And my answer to these questions has changed some over the years.

By helping individuals, teams and departments implement Scrum, I’ve observed how people learn to practice Scrum.

I use the word “practice” intentionally. Scrum isn’t just a concept to grasp and file away for future use. A solid understanding of Scrum comes from the experience of applying and adapting it over time. When I was first introduced to Scrum, a mentor described it as “easy to learn, but hard master.” I don’t think you can master Scrum without practicing it.

In a complex and uncertain world, Scrum provides habits and processes that allow teams to find focus in the complexity and agility to change when they encounter the unexpected.

So when people ask me how to learn Scrum, I’ve often pointed them to the Scrum guide and encouraged them to pick an area of their life or work where they could apply it. I thought if people learned the basics in a simple context, they could use Scrum in more complex environments.

This approach worked for many people, but there were two common problems:

1. Many people prefer a more structured approach to learning and practicing.
2. Like most literature about Scrum, the Scrum Guide is written with the context of software development in the backdrop.

And this guide is an attempt to bring together both a hands-on and structured approach to learning Scrum. I also wrote it with everyday people in mind because I believe you can apply Scrum across many different contexts.

I’m excited for you to learn Scrum and discover new strategies for designing your work and your everyday life.

Why Learn to Practice Scrum?

You want to do good work that delivers value. But sometimes, it's tough to get good work done. Sure we're all swamped, but at the end of the day, were we able to deliver?

In a complex and uncertain world, Scrum provides habits and processes that allow teams to find focus in the complexity and agility to change when they encounter the unexpected.

So before we dive into the how of Scrum, let's look a little deeper at the why of Scrum.

What are the pros & cons of scrum?

Who doesn’t live a quick pro and con list?

Pros of adopting Scrum

• Early Progress. Teams can make meaningful progress even when requirements are still being discovered.
• Flexibility. Because Scrum iteratively organizes the work into sprints, the team can change as needed.
• Focus. Work only gets added at the beginning of each sprint, allowing the team to focus on what’s a priority.
• Delivery. The team quickly delivers functional features with the most value by working off a prioritized backlog.
• User-Centered. The team receives feedback from both internal and external stakeholders by reviewing regularly delivered value.
• Visibility. Transparency is built into the process allowing high visibility into the work being done.

Cons of adopting Scrum

• Scope Creep. Without a clear end to the project, sometimes more gets added than should be later in the project.
• Scaling. Adopting Scrum across multiple teams can be difficult at first.
• Fit. Some projects by nature are sequential, and Scrum isn’t best for every type of project.
• New Meetings. Some people don’t like the idea of daily meetings at first, though this usually changes with time.
• Team-Driven. This one isn’t a con (it’s actually a strength) unless the team becomes unhealthy. Team health has a high impact on the successful delivery of the product.‍
• Experience Required. For the team to produce quality work requires a team of experienced professionals.

Why is Scrum essential?

If you're leading a team where you have to overcome obstacles to reach goals, Scrum can help you get there and deliver results.

Scrum can address three common challenges to enable your team to deliver extraordinary value.

1. Prioritization: Scrum forces prioritization to happen.
2. Clarity: Scrum handles unclear or changing requirements.
3. Complexity: Scrum embraces complexity.

Scrum forces prioritization to happen.

Imagine your boss’s boss comes to you excited about a potential feature for a product assigned to you. You’re uncertain about the value of this feature for the business or client, not to mention you know it will take way more work than they think it will.

It’s easy to imagine because this situation is so common you may feel like I read through your inbox this morning. Let’s look at how Scrum addresses this challenge.

The product owner plays a crucial role in Scrum. They are responsible for defining and prioritizing the work done to deliver value to the business and client. The product owner is the intersection between the team and stakeholders. They continually work with the team to update the prioritization and estimation of work.

Scrum brings simplicity to tackle both complexity and volatility

This prioritized backlog of work to be done is transparent to anyone, creating clarity and visibility about what the team should and shouldn’t spend time on.

Scrum handles Unclear or changing requirements.

We should expect uncertainty; change is inevitable. The past few years have clearly demonstrated this reality. So what do we do? How do we lead? How does the critical work move forward?

Framing the problem creates clarity.

Requirements are critical in defining the work to be done. But many times, requirements can be ambiguous or continually changing.

Scrum uses the tools of user stories and acceptance criteria to clarify the requirements and frame them in terms of the end-user. Framing requirements for the user is a game-changer.

Frequent feedback prevents the team from working very long on “what the stakeholder said, but not what they meant.

I’ve had many well-intentioned stakeholders ask for products they would have loved 30 years ago but would be a total miss for our target audience (college students) today. I have to ask, “What do you hope is the impact of this product? What need of the student does it meet, and what action do you hope they will take?”

Scrum has just enough constraints to create clarity around the work to be done, roles and rhythm.

These kinds of questions are core to user stories. As we walk through the process, the light bulb usually comes on, and they are willing to step back from their solution and entrust our team to help creatively solve today’s problem.

Working iteratively allows for changes.

Scrum is an iterative process with most of the events commonly occurring on a two-week cycle. These short iterations (sprints) allow the team to receive regular feedback on the work they produce. This frequent feedback prevents the team from working very long on “what the stakeholder said, but not what they meant.”

Scrum brings simplicity to tackle both complexity and volatility.

If the requirements change, work is reprioritized by the next sprint, and the team focuses on what will deliver the most value. The team can adapt quickly to these changes.

Scrum embraces complexity.

I get asked about Scrum a lot. Sometimes, I explain Scrum as a simple framework for tackling complexity by applying a few constraints to empower freedom and creativity. This world is becoming increasingly complex, and so are the projects and products we work on.

It’s tempting to battle complexity with a complex solution, and this becomes more problematic when volatility accompanies the complexity. The complex solution lacks flexibility or resilience and often breaks in an ungraceful way.

Scrum brings simplicity to tackle both complexity and volatility. Scrum doesn’t have a ton of rules and structure, and it has just enough constraints to create clarity around the work to be done, roles and rhythm. These few constraints give the team freedom and flexibility to embrace the complexity and develop solutions.

How Scrum Makes Things Visible.

So much productivity and value are lost when there isn’t clarity, focus or shared understanding. Let’s learn how to increase visibility within your team and across your organization.

Why is transparency essential?

You can’t learn, lead, or change what you can’t see. This truth sounds basic, but I frequently see leaders and organizations harmed because of a lack of visibility.

Here are some symptoms of low levels of transparency

• The overall direction and goals are unclear to most of the team or organization.
• Two teams are working on the same thing without knowing it or communicating.
• Team members don’t understand how their work impacts others’ work.
• Leaders don’t understand what the doers do.
• Leaders aren’t aware of the implications of the decisions they make.
• Teams building products don’t know what the customer thinks about them.
• Teams building products don’t know what the stakeholders think about them.

As you can see from the list, transparency matters because it highly correlates with clarity and understanding.

When teams or leaders can’t see or don’t understand what others are doing, they don’t have empathy. And without empathy, things break down pretty quickly, even becoming adversarial within the team or organization.

How does Scrum make things visible?

Scrum addresses the lack of visibility through four strategies.

1. Prioritization of value.
2. Clarity about current reality.
3. Commitment regarding deliverables.
4. Cadence of visibility

Scrum helps you prioritize value.

All work in Scrum resides in one of two backlogs.

1. The product backlog contains all future work for a given product.
2. The sprint backlog contains all PBIs a team is committed to within a sprint.

The product owner is responsible for keeping the product backlog ordered by priority. This backlog is not a secret and is visible to the whole team and organization. The backlog is the one source of truth regarding what’s prioritized.

Transparency matters because it highly correlates with clarity and understanding.

Teams, stakeholders and leaders can see how future work is prioritized. They can come to the product owner if they have questions or concerns.

The sprint backlog includes everything the team selected during sprint planning to focus on during the sprint. So if it’s not in the sprint backlog, it’s not what we’re doing this week.

There is a two-sided commitment with the sprint backlog.

1. A commitment to complete what was selected by the end of the sprint.
2. A commitment not to add additional work during the sprint.

There isn’t ambiguity about what the team should focus on this week. This clear prioritization gives the team a protected space to complete the critical work.

Scrum provides clarity about the current reality.

Scrum helps you know where you are through four of its events.

• Sprint planning
• Daily Scrum.
• Sprint retrospective.
• Backlog refinement.

Sprint planning.

The sprint begins with the product owner sharing the vision for the new sprint and the development team creating an initial plan to reach that vision. The four fundamental questions of sprint planning are:

1. What is the goal for this sprint?
2. How does that goal make the product better?
3. What work are we committing to complete during this sprint?
4. How will we use this week to complete the work?

As the team works through these questions, a sprint goal is set, work is moved from the product backlog to the sprint backlog, and the team verbalizes their initial plan for the sprint.

The Scrum team is self-organizing, which means they have significant freedom to identify how they will solve the problem and deliver the solution.

All these actions create visibility and shared understanding within the team and are transparent to other stakeholders outside the group.

The daily scrum.

Sometimes called the daily standup, the daily scrum is a brief 15-minute meeting where the whole team checks in. It’s usually structured around each person answering three simple questions.

1. What did I complete yesterday?
2. What will I focus on completing today?
3. Where am I stuck?

This simple rhythm of daily check-ins makes the team aware of everyone’s current reality.

But this meeting isn’t just a status update, and it’s not for people outside the team. It is a time for the team to take that shared understanding and further clarify what they need to do next to complete the work they prioritized at the beginning of the week.

Sprint retrospective.

When the sprint ends, the team holds a retrospective to evaluate how they are doing as a team. The focus is on the health and functioning of the group.

Here are some questions I like to use:

• What did you like?
• What did you learn?
• What was lacking as a team?
• What do you long for on the team?

The retrospective provides clarity regarding how’s our team doing right now. How often have you been on a team where big or small issues went unaddressed for too long.

Imagine being part of a team that keeps short accounts and honestly works through things together to become the best team they can be.

Backlog refinement.

Backlog refinement is a little more about the future, but it provides clarity about what we currently think about the future ;)

This may sound a little silly, but consider how often two people have different ideas about what will be done next or what it will take to do it?

During backlog refinement, the team reviews product backlog items (PBIs) to ensure there is enough shared understanding that the team can take action when they select the PBI in a future sprint.

The backlog is the one source of truth regarding what’s prioritized.

The needed supporting information and resources are identified and visible within the PBI. The team also uses tools like user stories and acceptance criteria to clarify the goal for the PBI and how they will know if it was successful. They will discuss how much work it will take to complete the PBI and measure it using story points.

What’s planned for the next sprint isn’t static, it can still be changed, but the current plan is clear and visible.

Scrum requires a commitment to deliver.

Have you ever missed a deadline only to discover nobody noticed? When others don’t see a commitment, it fails to be much of a commitment.

People don't do what you expect but what you inspect.
_{Louis V. Gerstner, Jr.}

There are three factors that Scrum’s approach to commitments increases visibility.

1. Sprint review.
2. Backlog refinement.
3. Self-organizing teams.

Sprint review.

As the sprint ends, the Scrum team gathers with stakeholders to review what they produced.

The product owner will facilitate feedback and accept or reject the work done according to the user story, acceptance criteria and the definition of done. If changes are needed, the product owner can add them to the backlog for the following sprint.

The Scrum team collectively owns their commitments.

Not only are the team's commitments visible at the beginning of the sprint via the sprint backlog, but they are also evaluated with transparency at the end of the sprint.

Backlog refinement.

During backlog refinement, the team works to clarify each PBI to ensure there is clarity regarding what they are committing to if they select the work in a future sprint. When a PBI has been refined, there should be no ambiguity about what it will mean to complete and deliver it.

Self-organizing teams.

The Scrum team doesn’t have a “leader.” This reality might be one of the hardest for managers to grasp early in the process. The Scrum team is self-organizing, which means they have significant freedom to identify how they will solve the problem and deliver the solution.

When coaching new teams, we work a lot on moving from I or you to we. It’s no longer I need to get this done, or you made a mistake. It becomes we need to find a way to finish, or we need to correct this.

The Scrum team collectively owns their commitments.

Scrum creates a cadence of visibility.

Everything is in a constant state of change, which is why transparency isn’t a one-time event. You need to develop a rhythm and cadence to visibility.

The Scrum events help to create that cadence. Let’s take a closer look at the role each play in transparency.

• Sprint planning. The team visible moves work from the product backlog to the sprint backlog. The product owner communicates the sprint goal, and the development team responds by communicating their plan for reaching that goal.
• Daily scrum. Every day each team member makes their status visible to the rest of the team.
• Backlog refinement. Every week the team refines part of the backlog making the requirements and supporting information more visible.
• Sprint review. The work completed during the sprint is visible to any and all stakeholders. What is being accepted by the product owner is also being made visible.
• Retrospective. As the team focuses on how well they work together, they create transparency around how their processes and behaviors impact each other.

As you can see, the events in Scrum each play a role in creating transparency. When they occur in sync, they build a cadence of visibility where you can help but evaluate and improve. More on that in a minute.

3 strategies you can level up transparency and make things more visible.

Whether you’re already practicing Scrum or just considering it, here are three actionable steps to level up transparency.

1. Identify the people.
2. Craft the questions.
3. Place them on the calendar.

Identify the people.

As we saw earlier, each role in Scrum contributes to creating and maintaining transparency. Do you have people to play these key roles?

• Product owner.
• Scrum master.
• Development team.

Individuals can play multiple positions if needed for a season, but ideally, you work toward having individuals dedicated to a role. The one exception is being both the scrum master and product owner simultaneously. I would not recommend that.

So whether your context is wanting to deliver content consistently or getting home projects done, identify who will play these critical roles.

Craft the questions.

I’ve provided suggested questions to ask at crucial moments like sprint planning, the daily scrum and the retrospective. You can use them as-is. No need to adapt. But if you want to nuance them a little or add a question, the key is to decide, “these are the questions we’re committing to asking at these times.”

Place it on the calendar.

When will this happen? If you want to see an increase in transparency, you must make time for it.

I recommend starting with 1-week sprints because most people's lives already orient around a weekly cadence. So a weekly schedule would look something like this.

Choose your times, create a calendar event, and invite your team.

Now that you’ve taken steps to increase visibility, it’s time to evaluate what you see. From there, you’ll decide what needs to change. This process repeats as you and your team grow in focus and effectiveness.

How Scrum Helps You Evaluate Effectively

Now that things are more visible, what do you do with this new transparency?

Just because things are seen doesn’t mean they are understood. Evaluation seems straightforward, but practical evaluation is still a struggle for many teams.

Let’s walk through Scrum’s roles in helping you effectively evaluate.

The compounding impact of evaluation.

We often think of evaluation as something we do at the beginning or the end, but it’s more of a continual process.

If you drive to the store, what part of the drive are you evaluating? Is it the beginning, middle or end? It’s the whole time. You are continually observing and assessing the speed and position of other cars, what color the light is, and whether you like the current song on the radio…

All those small evaluations come together to form a responsive and nuanced understanding of your surroundings. For many of us, work is at least as dynamic and complex as driving. Scrum provides a framework that invites the same kind of continual evaluation.

Scrum disarms evaluation by making it so regular

This gives the whole team a much more real-time understanding of what’s happening. This shared and distributed understanding is one of the Scrum team’s superpowers.

The sum of the daily evaluation enables contextualized knowledge that wouldn’t be possible if batched together at a later time. Leading projects or developing products without continuous evaluation is literally like driving with your eyes closed.

Now consider the impact when evaluation cascades across an organization with multiple teams continually evaluating and adjusting. You have the makings of a learning and agile organization.

Just because things are seen doesn’t mean they are understood.

Maybe you’re thinking, “I see how important evaluation is, but it’s not that easy, in fact it can be really difficult.” Let’s take a closer look at how Scrum can help.

How Scrum enables regular evaluation.

Evaluation can be challenging, especially when a team hasn’t developed the habit together. Here are four ways Scrum can help in this area.

1. Bringing shared visibility.
2. Providing structure without over-scripting it.
3. Strengthening the team’s evaluation muscles.
4. Creating moments for evaluation

Shared visibility leads to effective evaluation.

If you and I aren’t looking at the same thing, our evaluation will likely be fraught with misunderstandings. As Scrum increases an organization’s transparency making the work more visible, team members begin to see the same things.

Leading projects or developing products without continuous evaluation is literally like driving with your eyes closed.

The increased awareness allows the conversations to move more fluidly, and the shared ownership invites everyone to engage. The subject of evaluation is known to everyone and matters to everyone.

The question shifts from “what should you do about this?” to “what should we do about this?”

Scrum provides structure without over-scripting it.

Some may disagree with whether or not Scrum over-scripts evaluation. I say it doesn't because while Scrum provides a script, you’re free to change it.

Let’s take the daily standup as an example. Evaluation has a simple script.

1. What did I complete yesterday?
2. What will I commit to completing today?
3. Where am I stuck?

Having a script is exceptionally helpful for a team learning the habit. But if, during the retrospective, the team decides to change one of the questions, they are free to do so. Most of the structure Scrum provides is flexible rather than rigid.

Scrum strengthens the team’s evaluation muscles.

What happens the next day if you go to the gym to work out for the first time in a few months or years? You feel it. Muscles you didn’t know you had are sore. Getting out of bed is up for debate, so going back to the gym is out of the question.

But what happens when you push through? How do you feel when you’ve been active and exercising daily for a few weeks? You feel strong, recover quicker, and don’t fear the pain that brings the gain.

Evaluation is never urgent, but it is always essential.

When a team is practicing Scrum, they evaluate every day, usually multiple times a day. At first, this can feel a little overwhelming and teams can resist. But if they push through they begin to strengthen their evaluation muscles.

For many people, evaluation can feel scary because it can be proximate to conflict. But Scrum disarms evaluation by making it so regular. The team's emotional strength and psychological safety increase by practicing evaluation in small and larger batches.

Engaging in evaluation for healthy Scrum teams becomes like a marathoner going out for a light jog.

Scrum creates moments for evaluation.

Allow me to continue the exercise comparison a little longer…

When is the most popular day to work out?

Tomorrow.

It’s always easier to put off running or starting a diet to our well-intentioned future selves. The same is true for evaluation. We think we’ll get to it when we have time, when we’re done.

Evaluation is never urgent, but it is always essential.

Scrum combats this resistance to evaluating by scheduling it for us. The Scrum events make space for the team to assess. It creates moments or even rituals for the team to evaluate without even realizing they're doing it anymore.

The importance of Rhythm in Evaluation.

Once evaluation becomes a habit, most friction is removed and propels the team forward.

Let’s take a deeper look at how each Scrum event helps to create a cadence of evaluation by looking at the questions they invite the team to answer.

Sprint Planning

• What is the purpose of the sprint?
• How will we get the work done?

Backlog Refinement

• What value will this feature provide?
• How much work will it take?
• What resources or information is needed?

Daily Standup

• How are we doing?
• What progress are we making?
• What issues are we facing?

Sprint Review

• Is this useful to the end-user?
• Does this meet the business needs?

Retrospective

• How are we doing as a team?
• Where are we doing well?
• What do we need to be better?

Suddenly evaluation is as habitual as getting coffee in the morning.

And that is the power of Scrum’s rhythm of evaluation. It becomes a habit. Evaluation becomes an automated part of the team’s behavior.

Three actions you can take to cultivate evaluation on your team.

The culture of evaluation on your team won’t change overnight, but taking these three steps, means you won’t wait too long.

1. Make evaluation visible.
2. Press through the soreness.
3. Stay in rhythm.

Make evaluation visible.

When people are doing something new or different, it’s natural to feel unsure if they’re doing it right. That feeling can cause them to hesitate or stop altogether.

Call it out when your team begins practicing evaluation in a new way. It can be as simple as saying something like, “this is really good we’re evaluating _______, this is going to help us continue to grow and get better?”

Naming and affirming new behaviors and gives people the confidence to continue until it becomes a habit.

Press through the soreness.

Practicing something new takes more energy than doing what you’ve always done. Forecast to the team that these new evaluation habits might initially take more time and energy, but they will make us stronger.

Providing a short-term goal or finish line often helps people push through the initial discomfort. You could propose to the team that they commit to these new behaviors for the next 40 days, and at that time, you can evaluate how it’s working.

By the time you get to 40 days, habits will be built, and the team will be able to see the fruit of greater agility.

Stay in rhythm.

When you first begin, you’ll probably need to be a little more rigid to build consistency initially. Keep your commitments to evaluation moments and keep the day, time and location the same.

This consistency will allow the team to feel the cadence of evaluation and get in sync with each other. You’ll find them more prepared to evaluate because they know what to expect.

How Scrum Helps You Adapt.

Once things are visible to the team and honestly evaluated, you almost can’t hold back making a change. But there is still both art and science involved in leading people through change.

The necessity of adaptation.

The world is not static. And change isn’t optional.

What happens when teams or organizations don’t adapt? It’s easy to point to the big ones, looking at you Blockbuster, but the same thing happens on a smaller scale each day in almost every organization.

To thrive, we need to see change as normal, not scary. Keeping things the same really is a phantom.

I stopped seeing mistakes as failures and as discoveries about the world.

A personal experience that drove this home for me was when we moved as a family ten years ago. It was a hard decision to make as we had built great relationships in the community. But we knew it was still the right change to make.

Within two years, most of our close friends also moved for various reasons, and it hit me. If we hadn’t changed, life wouldn’t have stayed the same.

As you increase the frequency of adaptation, be aware of the tendency to glorify change to the point that you end up with instability or change for change's sake.

Adaptation is a long-term game of focus.

You can’t change everything at once. It becomes too disruptive, and people begin to feel lost and untethered in the transition. It’s also difficult to measure change's impact when you simultaneously change too many things.

Let’s return to the driving metaphor we have looked at already.

Think about how steering works when you drive. You don’t only steer when making turns. You steer continually, constantly making small adjustments as you adapt to the road and the cars around you.

Continuously steering is like the sum of the daily adaptation that, if taken all at once, would be disruptive or impossible for the team. Imagine waiting and trying to make all your right turns at once.

There are moments where more dramatic change is needed, like taking a u-turn. Maybe your environment around you changes rapidly, or your user-testing tells you a significant pivot is needed.

Perfection is not the standard. If you’re not failing much, you’re probably holding yourself and the team back by playing it too safe.

But there is a compounding impact in making small changes over time. Or said another way, take the 1% improvements but be open the to possibility of 100% changes.

1% feels so small, but what if you could implement a 1% process improvement daily. You would see 100% change in just over two months.

The small changes should still connect to the big picture. You can ask the team, “how is this change taking us where we all want to go?”

You have to teach yourself to see adjustments with a long-term mindset. Run the marathon. Even though Scrum calls it a sprint. 🤷‍♂️

How does Scrum support teams to adapt?

Regular change on its own can be disruptive and confusing. Scrum’s not-so-secret ingredient is that it first normalizes transparency and inspection. Adaption is then just the natural next step.

Transparency creates shared consciousness, a great concept from the book Team of Teams, and contextual awareness that allow teams to make informed decisions.

Learning is always part of the process. And the process takes time.

Continual inspection keeps teams from making changes based too heavily on a singular data point. Instead, the adaptation is based on a nuanced understanding of many influencing factors.

But Scrum’s biggest advantage in adaptation is self-organizing teams.

It’s their decision.

The change isn’t being pressed down on them by leadership. It’s not disconnected from the reality of everyday work. Nor is it disconnected from the overarching goals and objectives of the organization.

The impact of agency and empowerment combined with clear direction is hard to overstate.

Now, with this backdrop, let’s look at each Scrum event through the lens of adaptation.

• Sprint planning. The team may have had an idea of how to do the PBIs when they last saw them during backlog refinement. But now, when they have the context of the sprint goal and other work to be done, they may decide to adapt their approach.
• Daily scrum. Every day the team is essentially adapting to replan the rest of the sprint based on what they discovered the day before.
• Backlog refinement. As the team works to clarify the items in the backlog, the product owner will likely make changes to the prioritized order of the backlog.
• Sprint review. After receiving feedback from stakeholders, the product owner will adapt what is prioritized for the new sprint.
• Retrospective. The team identifies changes they will make to work more efficiently together.

Going through that list, it’s hard to miss how closely adaptation ties to the other two pillars in Scrum of transparency and inspection.

What to do when an adaptation doesn’t work?

Learning is always part of the process.

And the process takes time.

Learn from the kids

As adults, my wife and I moved around the world to work in a new language and culture. We were adapting in every facet of life, facets I didn’t even know were a thing. An unexpected blessing was having young children during that same season.

As we were learning to live in a new way, they were just learning to live in general. Not long after taking their first step, they would fall. When learning to speak, they would use grammar in a hilariously strange way.

Take the 1% improvements but be open the to possibility of 100% changes.

When we watched this in their lives, we knew it was normal and celebrated the journey. But then in my own life, I would be frustrated by not knowing how to do or say something. One day the light bulb when off that I was on the same journey my kids were.

Mistakes were part of my learning journey. I stopped seeing them as failures and as discoveries about the world. I needed the same grace I was extending to my kids. Your team will need this also as you embark on change.

Live with a growth mindset.

As I look back on those years, I realize they were instrumental in cultivating the empathy and curiosity that later led me to the worlds of UX and agile development.

Without those “failures,” I wouldn’t have grown into who I am today.

So whether it’s your own personal project or your team has made a change that didn’t work out, seize the opportunity to learn from it.

To thrive, we need to see change as normal, not scary.

Not only does inspection inspire adaptation, but it also acts as its safety net. During the next standup or the retro, evaluate what didn’t work and adapt again.

Perfection is not the standard. If you’re not failing much, you’re probably holding yourself and the team back by playing it too safe.

3 Strategies for guiding your team through change.

We each have varied tolerances for change, and the team will likely include members who see it differently.

These differences can create some challenges to leading a team through continuous change. Let’s explore three strategies to help you lead your team amidst change.

1. Avoid the sunk cost fallacy.
2. Maintaining current clarity.
3. Engage the whole person.

Avoid the sunk cost fallacy.

Have you ever known you need to make a change, but you felt the weight of how much work you’ve already put in holding you back?

It can be challenging to navigate change when you’ve already invested much in the current plan. But if you don’t do anything and keep moving in the same direction, it will only get worse.

Let’s explore the sunk cost fallacy and see how to understand our emotions' impact in this situation.

The workday is over, and you’re swiping through Netflix to find something to watch. You pick a movie you haven’t seen and start watching. It’s terrible. The acting, the plot and the cinematography all leave much to be desired. But you keep watching because you’ve already invested over an hour, and there are only 35 minutes left. This is the sunk cost fallacy.

It's hard to let go when we’ve invested a lot of work, money, or time into something. Even when our mind knows we should cut our losses and move on, our emotions keep us from moving forward.

We like to think of ourselves as intellectual agents making rational decisions, but research has shown that we’re not that different from mice or rats regarding the sunk cost fallacy.

Scrum's short cycles are a powerful defense against the sunk cost fallacy because it limits how much time you invest before discovering a change is needed.

But if you still find yourself in the face of needed change feeling paralyzed by the time and work already invests, here’s another strategy for you.

Name the past and move to the future.

While you can and should learn from the past, you cannot change it. The effort, time, or money you’ve invested is already spent, and taking ownership of this reality is crucial to moving forward.

Sometimes it’s simply saying aloud to the team, “When we started the project, we looked at factors X and Y and decided to do Z, but now things have changed, and Z is not the right strategy for reaching our goal.”

The world is not static. And change isn’t optional.

So often, bringing the truth out into the light disarms all the lies we’re tempted to believe. All of the “you should’ve…” and “if only…” statements shame us into submission and keep us stuck on the same path.

But when you take ownership of the decisions and the outcomes and call them what they are, you can set them down and turn your attention to what’s ahead.

Maintaining current clarity.

If a larger change occurs, like a merger or reorganization, your team will need extra help navigating the added uncertainty.

You don’t know the future, but you can be clear about what you do know.

During seasons like this, you may add 5 minutes to the standup and address the following points.

• This is what we know today.
• This is how it affects our team.
• This is what we’re going to do.

This real-time clarity will provide a level of safety for the team to still do courageous and creative work.

Engage the whole person.

But what if you know the new direction but need help facilitating the change?

Change can be tricky, and it's not always clear how to implement it. The book Switch is an excellent resource for understanding how to bring about change, and it uses a metaphor of a man riding an elephant to illustrate three areas to cultivate change.

• Directing the Rider. The rider represents the rational, logical mind of people. Appealing to the rider is usually the default approach but will have a limited effect on its own.
• Motivate the Elephant. The elephant represents our emotions; if not properly engaged, it will steamroll our rational plans every time.
• Shape the Path. How can you change the environment in which the change is being made? Can you make the new behavior extraordinarily easy and the old one difficult or impossible?

I find this framework informative when the team considers changes based on our evaluation during the retrospective.

Change is inevitable, and leading through it can be hard, but you’re not alone.

Applying all three pillars of Scrum along with the Scrum values.

Even as we covered the pillars one at a time, you can see how they naturally integrate and work together.

• Transparency to make things more visible.
• Inspection to create space for evaluation.
• Adaptation to encourage growth.

They act in concert with each other, and you will often find yourself moving fluidly from one to another.

You can think of Scrum as a three-leg stool, with each pillar being a leg. If you remove any of the legs, the stool no longer functions. In fact, it’s likely to hurt someone. Scrum is similar. If you try to practice it without one of the pillars, you will do more harm than good.

The 5 Scrum values are critical to the health of Scrum.

The three pillars of Scrum are also complemented by the Scrum values, which include

• Commit to achieving the goals of the Scrum Team.
• Courage to do the right thing and work on challenging problems.
• Focus on the Sprint's work and the Scrum Team's goals.
• Open about all the work and the challenges with performing the work.
• Respect each other to be capable, independent people.

You can see these values speak to the posture of those on the Scrum team. They describe the attitudes and behaviors of the team.

I said at the beginning that Scrum is easy to learn but hard to practice. It’s easy to learn because it's not overly complicated. And it’s hard to practice because consistently living out the values and pillars requires commitment and maturity.

To experience success for yourself and your team, you must cultivate these values and pillars as you practice Scrum. They are necessary to see a truly self-organizing team grow.

The biggest challenge I see facing teams today is when the values of Scrum don’t match the organization's values. If you’ve cultivated the values in your team, but they are lacking in your organization and its leaders, it will be like planting a healthy plant on your driveway. It will struggle, then wither and die.

This is often an overlooked aspect of the Scrum Master’s role. They should always be working to explain, teach and cultivate an agile mindset and understanding of Scrum in the organization at large.

The Scrum pillars and values in practice.

Now that you understand the foundation Scrum is built upon let’s take one more trip through the roles, events and elements of Scrum, highlighting the pillars and values.

Scrum Roles

Scrum Master

The Scrum Master is a master of process and an empowerer of people as they focus on maximizing the impact of the development team. They help the team practice Scrum by cultivating openness as they reflect how the team is living out the pillars and values.  

The Scrum Master will provide coaching or facilitation when needed. They also support the team by removing obstacles and representing Scrum to the rest of the organization.

Learn about the Scrum Master role.

Product Owner

The Product Owner's primary responsibility is to maximize the value delivered to the product. They are constantly inspecting and adapting the work collected in the backlog and the work produced by the team each sprint.  

The Product Owner helps the team to commit and focus by setting the sprint goal. They serve as the inflection point between the development team and stakeholders.

Learn about the Product Owner role.

Development Team

The Development Team is a self-organizing, cross-functional group that makes up most of the Scrum team. They constantly inspect and adapt as they transform backlog items into new value each sprint.

The success of Scrum rests on the development team’s courage as they live out the Scrum values.

Learn more about the Development Team role.

Scrum events

Daily Scrum

Every day, each team member makes their status visible to the rest of the team during the Daily Scrum, also called the standup. The standup is a fifteen-minute meeting where the development team inspects the previous day's work, plans the next day’s work and identifies any barriers to getting things done. They do this by asking the questions like:

• How are we doing?
• What progress are we making?
• What issues are we facing?

Every day the team is essentially adapting to replan the rest of the sprint based on what they discovered the day before.  The daily standup requires openness and transparency but provides focus and commitment.

Learn to keep your team in sync with a daily standup.

Backlog Refinement

Every week, the team refines part of the backlog making the requirements and supporting information more visible.  During the backlog refinement session, the Scrum team reviews new product backlog items asking questions to clarify the requirements and the goals.  

• What value will this feature provide?
• How much work will it take?
• What resources or information is needed?

As the team works to clarify the items in the backlog, the product owner will likely make changes to the prioritized order of the backlog. There is flexibility about when during the sprint to have the backlog refinement.

Learn how to facilitate a backlog refinement session.

Sprint Planning

At the beginning of a new sprint, the team meets to focus on how they will commit to reaching the sprint goal. The team visible moves work from the product backlog to the sprint backlog. They then ask the questions:

• What is the purpose of the sprint?
• How will we get the work done?

They review the work selected for the sprint and make an initial plan that they can adapt via the daily scrum. The team then communicates their plan back to the product owner.

Learn how to do sprint planning in Scrum.

Sprint Review

The sprint review occurs at the end of the sprint to inspect the delivered work. Various stakeholders and subject matter experts from across the organization attend to give feedback on the work completed.

As the team’s finished work is reviewed, the following evaluative questions are asked:

• Is this useful to the end-user?
• Does this meet the business needs?

After receiving feedback from stakeholders, the product owner will adapt what is prioritized for the new sprint. Both the completed sprint work and the work the product owner accepts are made visible to the rest of the organization.

Learn to run a sprint review.

Retrospective

The retrospective occurs at the end of the sprint, focusing on the whole Scrum team. The tone is positive and productive, focused on improving the team. Evaluative questions might include:

• How are we doing as a team?
• Where are we doing well?
• What do we need to be better?

As the team focuses on how well they work together, they create transparency around how their processes and behaviors impact each other. The sprint retro creates space to inspect and adapt, inviting team members to be courageous and identify changes they will make to work more efficiently.

Learn how to facilitate a Scrum retrospective.

What are the elements (or artifacts) of Scrum?

The Backlog

Both the product backlog and the sprint backlog are transparent to the team and the organization, creating clarity and openness about both focus and priority. They each contain the definitive list of work to be done. The sprint backlog helps the team maintain focus on the work to be done in the given sprint.

The backlog is continually inspected to refine PBIs for greater clarity. The product owner keeps the backlog ordered by priority.

Learn to use the backlog in Scrum.

Product Backlog Items (PBIs)

Each item in the backlog represents precise work and value to deliver. Often these PBIs are written using both user stories and acceptance criteria. They make future priorities visible both inside and outside the team.

The PBIs are what get refined during the backlog refinement session, and if one is too large, it may be broken down into smaller PBIs.

Learn more about Product Backlog Items (PBIs)

Definition of Done

The definition of done is a list of what must be confirmed to consider a PBI done. The whole team creates and commits to what is in the definition of done. The team respects each other’s commitment to getting their work done.

The team can inspect the definition of done during a retro. It is updated as needed for the team to function effectively.

Learn to use the definition of done.

User Stories

User stories are a simple schema to organize a PBI’s requirements. They make the end user's needs, motivations, and goals visible. They use the structure.

• As a…
• I want to…
• So that…

They keep the team focused on the value they create for the end-user. PBIs are evaluated against their user story during the sprint review.

Learn to write your own user stories.

Acceptance Criteria

Acceptance Criteria defines the requirements which must be met for the sprint deliverables to be accepted by the product owner. Acceptance criteria follows a consistent structure of:

• Given that...
• When...
• Then...

Acceptance criteria makes visible what functionality team members are committing to deliver.

See examples of acceptance criteria.

Story Points

Story points measure the relative size of a PBI.  They aren’t absolute measurements like hours or days but measure the amount of work a PBI takes relative to other PBIs.

Assigning the proper size to work requires open discussion for the whole team.

Learn to use story points.

Velocity

Velocity measures how many story points a Scrum team completes on average per sprint. This average allows the product owner to forecast transparently when future features will be ready.

Learn to forecast in Scrum using velocity.

Increment

The increment is the new functionality or value the team has committed to delivering at the end of a sprint. It is inspected during the sprint review. The increment should be ready to release to the end-user even if the team chooses to wait.

What’s Next?

We’ve laid the foundation of why Scrum is necessary and what Scrum consists of. Next, we’re going to dig deeper into how to practice Scrum by looking at its application across various contexts.

Applying Scrum to Different Kinds of Work.

Now that we’ve covered the essentials that make Scrum effective let’s dig into how to really practice Scrum.

Perhaps you have heard about Scrum but still aren’t sure if it will work for you. Much has been written about practicing Scrum in a software development context, but there is so much opportunity to apply Scrum in non-software projects.

It can be challenging to translate Scrum to a new context. What stays the same? What changes? I wrote this guide to help you navigate the art of applying Scrum.

And this is why we began with a focus on the pillars and values of Scrum. Because they don’t change with the environment or context.

If you don’t understand them, you will struggle to apply Scrum in typical situations. But when you have a firm grasp of these essential principles, you can creatively adapt Scrum to an assortment of circumstances.

Why Scrum works for non-software projects.

I’ve used Scrum to lead creative media teams, branding projects, content creation, personal growth, and even homeschooling my kids. These are three reasons I believe Scrum applies broadly.

1. Scrum doesn’t prescribe much.
2. Scrum invites evaluation and adaptation.
3. Scrum creates a rhythm of work.

Scrum doesn’t prescribe much.

As we’ve seen, Scrum is a relatively simple framework. Some roles, events, and elements are critical, but there’s a lot of flexibility around implementing them.

• If your team is small or just you, you can combine roles.
• If the environment around the work is volatile, you can have short one-week sprints.
• If the environment is more stable and the work progresses slowly, you could choose a two or three-week sprint.

Either way, Scrum doesn’t prescribe you a schedule, but it forces you to create one.

Scrum invites evaluation and adaptation.

Each day, work progress is evaluated, and the next steps are clarified. This rhythm allows the team to shift and adjust as needed.

At the end of every sprint, during the retrospective, the team evaluates how they are working, where they can grow or what might need to change.

You don’t have to get it perfect in the first sprint.

Evaluation is woven into the rhythm of Scrum. This cadence allows new teams to quickly adjust as they discover how Scrum can best serve them in their context.

You should feel a huge relief knowing you don’t have to get it perfect in the first sprint. Getting started is vital. As the team works together, they can adapt as they grow.

Scrum creates a rhythm of work.

While there is flexibility in how you arrange your Scrum schedule, you want to have enough consistency to create a cadence in your practice of Scrum. There is a definite rhythm and cadence to Scrum that most teams find very helpful.

Every kind of work benefits from clarity and focus. The Scrum rhythm provides clear expectations for:

• what the team delivers.
• who does what.
• how progress is made.

The events of Scrum each have a specific and clear purpose, and there are no meetings just for meeting's sake.

Scrum may not work great on every project, but don’t be afraid to try applying to a new space just because you haven’t heard of someone doing it before.

Let’s look at some specific examples, and then we’ll cover steps and principles for applying Scrum to a new context.

‍

Establishing agile ways of working.

While you probably could try and apply Scrum to any type of work, there are some places is it will thrive and others where it will feel forced or even detrimental.

Work considerations for applying Scrum.

Scrum takes an incremental and iterative approach, and this approach shines in uncertain or changing environments.

If your work requires everything to be known before you begin, applying Scrum will likely feel forced. Constructing a bridge requires a commitment to finish according to the original plans and not change course halfway across the river, and it’s probably not going to be a good project for Scrum.

However, most projects these days are not this rigid.

If your work involves creating some kind of product or service, it will feel more natural to apply Scrum. Fields like media production or copywriting can be good examples.

But even if your work is less product or service-oriented, remember that Scrum is about maximizing the value delivered.

So if you lead a finance team, you could use Scrum to help your team continually evaluate what work needs to be done each sprint to deliver the most value to the organization and your customers.

Team considerations for applying Scrum.

Scrum assumes and really requires a collaborative team, as the whole team owns the completion of work in the backlog. There is an intentional shift from I to we as a team learns Scrum.

You will want to evaluate the current level of trust in your team. Adopting Scrum might be more than the current team dynamics could handle if it's shallow.

Even on a healthier team, the shift can be difficult at first but usually results in greater trust and collaboration than there was before.

Here are a couple of other team-related considerations:

• Distributed teams. A lot of Scrum literature will talk about teams needing to be co-located, but it doesn’t have to be. Scheduling and collaboration become more complicated if the team spans over four time zones. I’ve led Scrum across multiple distributed teams, and the level of communication and collaboration significantly strengthened the community.
• Part-time teams. Scrum teams are usually full-time teams, and that setup is ideal. I have led Scrum on teams where no one was assigned full-time to the project. The primary adjustment was to the cadence of the Scrum events. Over time, as we evaluated and adapted, we found a rhythm that fit.
• No team at all. I’ve used Scrum on a team of one for many years, and I’ve applied it to my professional development and home renovation projects. In both cases, it helped me prioritize among the possible options.

I’m continually experimenting to see how Scrum can help me and others get essential work done. Here are examples where I’ve applied Scrum to different kinds of projects.

• Scrum in blogging
• Scrum in personal development
• Scrum in education
• Scrum in everyday home projects
• Scrum in creative production
• Scrum in content creation
• Scrum in marketing

How to use Scrum in your context.

Are you ready to give it a try and apply Scrum to your work and your team? Remember, you don’t have to try to get it perfect the first time. Each sprint, you will grow and get better.

Let’s look at a few steps to get started

• Assess your context.
• Learn the essentials.
• Phone a friend.
• Start simple and lightweight.
• Leverage the retros.

Assess your context.

Look back at the previous section to assess how Scrum will fit your team and type of work.

You will also want to consider your leadership and the teams around you. When you begin to work differently, they will notice, and you’ll want them to understand and align with these changes.

Learn the essentials.

The good news is Scrum isn’t overly complicated, but the bad news is most resources were written assuming the context of software development. This is why I created this guide to teach you the transferable essentials of Scrum.

Phone a friend.

When I took on implementing Scrum across a creative department with four different creative teams, I encountered some resistance to using it for video. One leader came and told me they had googled “Does Scrum work for video production” and read an article saying it doesn’t, so we would need to do something else.

So aside from being wary of “I read this on the internet” advice, I was also pretty confident Scrum could work for video production. But the reality was that I hadn’t done it yet, and I didn’t know anyone personally who had.

So I went to LinkedIn and searched for “Scrum and Video Production” and began reviewing people’s profiles to see if anyone seemed to have the experience I was looking for. I messaged a few of the people I found using the following message.

Hi ______. I’m a Scrum Master in the creative department of a large non-profit. This year is my first time applying Scrum to the work of video production, so I began looking for examples of others who have done this before.

Looking at your profile, it seems like you have experience and expertise in this area. I’d love to connect if you’re willing to give some guidance to someone earlier in the journey of applying agile/scrum in the area of video.

Not everyone responded, but a few did, which was all I needed. It was so helpful connecting with someone who has already been down the road I was on.

Don’t be afraid to reach out. Most people are excited to help.

Start simple and lightweight.

If starting Scrum still feels like too much, try using a Kanban board to organize your team’s shared work. It will increase awareness of what the team is working on. You could then introduce retros inviting the team to explore how to grow.

Leverage the retros.

You don’t have to have it all figured out before starting. You may need some help getting your team initially oriented but start with the expectation that you’ll learn a lot in the first few sprints and make necessary adjustments.

How to teach Scrum?

So you’re interested in Scrum and may be wondering how you get the rest of your team on board.

There are several approaches to take when onboarding others to Scrum.

• Facilitation exercises
• Written materials
• Formal instruction
• Personal coaching

People learn in different ways, so using a combination of methods is recommended.

Facilitation exercises

Hands-on learning provides quick insights and memorable experiences to help your team onboard to Scrum.

Here are five facilitation exercises you can use to teach Scrum.

1. Matching Scrum roles and responsibilities.
2. Battleship: Agile vs. Waterfall
3. Relative Sizing
4. Capacity and Forecasting
5. Accelerating Delivery.

Matching Scrum roles and responsibilities.

This simple exercise tests a team's understanding of the Scrum roles. It’s best used right after teaching about the Scrum basics

Divide a whiteboard or table into three sections based on the roles of Scrum Master, Product Owner and Development Team.

Write the following responsibilities on sticky notes and have the team assign them to the proper role discussing their reasons as they go. Some responsibilities belong to multiple roles, so you will write them on different notes.

• Ensure Quality
• Attend Sprint Planning x3
• Attend Sprint Review x3
• Attend Daily Standup x2
• Attend Sprint Retrospective x2
• Attend Backlog Grooming x3
• Design
• Build
• Test
• Integrate software
• Deploy
• Improve process
• Improve technical practices
• Prioritize Product backlog
• Talk to stakeholders
• Track the progress of the sprint
• Make Product Backlog visible to all
• Create Product backlog items
• Resolve Technical impediments
• Resolve organizational impediments
• Facilitate Scrum events
• Ensure Scrum rules are followed
• Coach team
• Track progress of the release

Battleship: Agile vs. Waterfall

You’ll need three sets of battleship for this fun exercise. Divide the group into six teams and spread them across three games of battleship.

Here’s the catch. One team in each pair has to plan ten moves ahead. They can’t change the planned moves; after their 10th turn, they plan an additional 10.

The other team follows normal gameplay selecting a move during each turn.

After the games finish, have the teams debrief the experience.

• How did the two teams experience the game differently?
• Which team typically won? Why?
• Which approach more accurately represents our current approach to managing work?
• What would a more agile approach look like in our context?

The purpose of the exercise is to allow the team members to experience the benefits of a more agile approach.

Relative Sizing

Imagine you are developing a fictitious cooking app and need to size items in the backlog. On this Miro board template, you’ll be able to work through this and the following two exercises.

How to Play

Explain that your team is building a recipe app. They need to organize the tasks by how much work they will require. Keep all the tasks hidden and reveal them one at a time. Team members will take turns sizing one task at a time. Each person gets 1 minute to size a task.

• Read the task out loud and assign it a size
• Explain to the rest of the team your reasoning.

This process repeats, cycling through team members and tasks.

After about ten tasks, allow team members the option to either pick a new card or move an old card to a new column. If they use their turn to move a card, they must explain it to the group.

If all the cards have been placed, team members can either move a card or pass if they feel all the cards are in the right place. Once everyone passes in a given round, the game ends.

Ask the team for observations about the activity.

Key Learning

The beginning is difficult without a reference story. Work through these questions with the team.

• What's the size difference between an S and an M?
• Explain to a team that an XS represents the smallest type of task, and an S is about two XSs. Ask if they need to adjust any cards.
• Explain that an M is about the size of an S and an XS combined. Ask if they need to adjust any cards.
• Explain that an L is about the size of an S and an M combined. Ask if they need to adjust any cards.
• Explain that an XL is about the size of an M and an L combined. Ask if they need to adjust any cards.

Apply What They Learned.

• Add a new card and ask the team to size it.
• Discuss how this was different than before? Are there still any challenges to sizing this way?
• Explain planning poker for the final three cards.
• Discuss advantages of planning poker approach.

You'll be ready to tackle the same challenges with your real-life projects when you finish.

Capacity and Forecasting.

Just like kids in the back of the van, stakeholders have a habit of asking, “Are we there yet?”

This exercise will teach your team how to quickly and accurately answer that question.

Facilitator Notes

The group is given a list (backlog) of features for a cooking app. The list is prioritized in order, and all tasks have been sized.

In the past three 1-week sprints, assume your team has completed tasks adding up to 12 points, 14 points, and 15 points. We will estimate the team's velocity by averaging those weeks at 14 points a sprint.

Finding the finish lines.

Have the group draw lines on the list to group tasks into future sprints based on the current velocity.

The lines will divide the tasks into groups with no group containing more than 14 points.

Discussion

After completing the exercise, work through these questions:

• How many sprints until a customer can share a recipe with someone else?
• When will the app begin to generate revenue?
• How many sprints until the app works on Android?
• If you begin to get requests for launching a Spanish version of the app, what would you communicate about availability?
• You just learned that Samsung is releasing a new smart fridge and wants to feature your app. What is your current forecast for this functionality?
• If the backlog was re-ordered, how far up could you move the smart fridge integration feature?

Accelerating Delivery.

Things change. And you need to deliver something sooner than planned. How does Scrum allow for that kind of adjustment?

This next exercise allows the team to practice making the kind of adjustments real life demands.

Facilitator Notes.

You've learned that Samsung is releasing a smart fridge and wants to promote your app. This is a great marketing opportunity. However, it means the smart fridge integration needs to be available by the end of the 7th sprint rather than the 15th.

To meet this deadline, the backlog needs some pruning.

Have the team move features from the backlog over to the tree.

If the feature must be implemented before releasing the app for Samsung to promote, place it below the red pruning line.

If the feature can wait and be implemented soon after, place it above the pruning line.

Written materials.

The two significant advantages of written materials are:

1. It can be read over time, allowing people to absorb the information slowly.
2. You can refer back whenever there are questions.

Because Scrum invites teams to think and act in new ways, it often takes time for people to feel confident with the concepts. Three sources for written material I recommend include

1. This guide
2. Books
3. Scrum organization

This guide :)

I decided to write this guide after numerous leaders asked me, “Is there something I could read that would help me understand how Scrum works?”

A lot of instruction out there focuses on all the meetings, roles and elements of Scrum to get you practicing quickly.

I focused on the pillars and values of Scrum first because if those are understood and embraced, a team or organization has a good chance of success in implementing Scrum. If there is a mismatch between the values of Scrum and the values of the organization, it really won’t matter how well anyone understands Scrum.

This guide is truly designed to help people understand the core concepts of Scrum and how to apply them in the various contexts of life.

I recommend using this guide with leaders to focus your discussion on how the pillars and values compare with the organizational culture.

For now, this guide is primarily available online, but I’m hoping to publish it digitally (and maybe in print) early next year.

Books

There is something nice about turning the pages back and forth, underlining critical ideas as you learn new concepts. So if you’re looking for a hold-in-your-hand kind of resource, here are two I would recommend.

1. Scrum. The art of doing twice the work in half the time by Jeff Sutherland.
   This book focuses on the concepts of Scrum answering questions around why and what.
2. The Scrum Fieldbook by J. J. Sutherland.
   This book focuses more on the practical application of Scrum, addressing questions of how.

Scrum Organizations

Both Scrum Alliance and Scrum.org offer extensive resource sections. They can be a little intimidating to navigate through, but there is a lot of information freely available. If you wanted to build your own learning path for team members, you could probably build something using resources from these sites.

Formal instruction

Depending on the scale at which you want to role out Scrum, providing formal training and instruction for teams can also be a practical approach.

There is a multitude of organizations that offer training for becoming a Scrum Master or  Product Owner. These tend to be rather expensive and overly focused on the details of Scrum rather than the practice of it.

If you’re looking for more of an overview of Scrum, I recommend looking on LinkedIn Learning and Skillshare for options. Both have various options and are subscription based, so if you don’t like one course, you can flip to another. Skillshare will give you a free month, which is plenty of time to knock out a course or two.

I’m currently working on intro courses to both Agile and Everyday Scrum. You can signup to be notified when they launch next year.

Personal coaching

While Scrum isn’t overly complicated; it’s not something you implement overnight. It takes time for behavior to change, mental modals to adapt, and culture to shift.

There will be difficult moments along the journey. Moments of truth where the people, the team and the organization must decide if they’re really in. There will also be many decisions and questions, usually regarding if you’re doing it right.

In any new venture, we benefit by learning from those who have gone before us. Scrum is no different.

A coach can help significantly in these moments. They provide experience and perspective to navigate the process.  

Maybe you’re wondering, “where do I find a coach?” There are a few places to look when searching for a Scrum coach.

• Your organization. If you work in a large organization and some parts of the organization have already implemented Scrum successfully, check in to see if they can suggest someone as a coach.
• Scrum organizations. Scrum Alliance allows you to search from their database of Certified Team Coaches.
• LinkedIn. A quick search for “Scrum Coach” on LinkedIn returned over a million results. But you can further narrow it down by location and other criteria.

Everyday Design. Ok, a slightly shameless plug here, but I’m offering a handful of free coaching appointments each month.

Leaning Scrum for the first time can be overwhelming. There are many new concepts and terms in Scrum. And you may be thinking:

I have so many questions about Scrum I don’t know where to start.

Well, we’re here to help. Below you will find a list of frequently asked questions about Scrum. Search, browse, go on a rabbit trail…

Wherever this FAQ takes you, I’m excited for you as you begin this journey of learning about Scrum.

There’s a lot. You may even feel like you don’t know what you don’t know. That’s ok. This guide will walk you through learning scrum.