Considering Scrum: Implementing Scrum In Your Organization
Are Considering Scrum In Your Organization?
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Source: Scrum Guide - Definition of Scrum
Let’s Take A Fictional Walk Through the Scrum Guide When Considering Scrum. But First…
This definition of Scrum is pulled directly from the 2020 version of the Scrum Guide (the latest version by Ken Schwaber and Jeff Sutherland as of this blog posting).
It’s a common place to start when you are considering scrum.
As my colleague Stephen wrote in a comment about this “Definition of Scrum” in the Scrum Fundamentals document I’ve shared…
“This is an awesome definition that actually explains nothing at all about what scrum is or how it works. If I don't know ahead of time about Scrum, this definition does not help me understand.”
I agree (smile).
So.
I decided to write a fictional story of a person Implementing Scrum using the Scrum Guide as the backbone for the story.
You will enter the fictional world of someone Considering Scrum in the real world.
Want the TL/DR; version of this — check out kiss.mvizdos.com now :-).
Please play along with me!
Let’s get started….
Jump into a Fictional Story of Considering Scrum
I [some fictional character, not really me] was recently told our organization was using Scrum as an Agile methodology of choice to work on product development.
“Great, how am I going to learn what that even means?” I thought to myself.
I hopped online and found this “Interactive Scrum Guide” from Michael Vizdos, and learned I could listen to or view or even watch the latest version of the “Official” Scrum Guide (2020) by Ken Schwaber and Jeff Sutherland. I also noticed that I can learn about the revisions in the 2020 Scrum Guide since its last updater in 2017.
Note to self:
I put the free audiobook version on the back burner to listen to as I am driving around town sometime later (because it is about 30 minutes to listen to – or 15 minutes at double speed!).
Reading The Interactive Scrum Guide When Considering Scrum
I learned there is a Purpose of the Scrum Guide, which let me know the two authors have published the Scrum Guide since 2010 in order to help people worldwide understand Scrum.
This Scrum Guide is important for people to read (especially while you are considering scrum).
In this, I found the Definition of Scrum and was reminded that if I change or leave out any of the elements of Scrum it would basically render whatever they write about possibly useless.
So.
I tried to imagine what it would look like for my team to Implement Scrum in our organization.
Starting with the Scrum Definition, I learned that Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
It requires this person – a Scrum Master – to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat.
“Sounds easy enough,” I thought. So I kept reading…
I learned that Scrum Theory is based on empiricism and lean thinking. It requires the Scrum Team to reduce risks by using an iterative and incremental approach to also help predictability.
“Cool. We need that.”
In reading a bit more, I realized it would require our team and organization to embrace three pillars of Scrum, which include, Transparency, Inspection, and Adaptation.
Scrum also depends of people “living” the five Scrum Values, which include:
Focus
Openness
Respect
Commitment
Extreme Courage.
Actually, the final Scrum value is only “Courage;” however, I thought it would be easier to remember the Scrum Values as “FORCE” and really, this courage thing would require some possibly extreme – and maybe scary – changes in the way we are working together today.
These five scrum values are required so that we can build trust.
“Hmm…
THAT might be missing in our organization today because we are not delivering results as promised.”
Sigh.
Implementing Scrum requires a Scrum Team, which is a small team of people consisting of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies.
It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
It’s a small team (usually less than 10 people) who is entirely self-managing and cross-functional.
The first accountability on a Scrum Team includes the people who are committed to creating any aspect of a usable increment each Sprint. These people are called Developers and they are always accountable for:
Creating a plan for the Sprint, the Sprint Backlog;
Instilling quality by adhering to a Definition of Done;
Adapting their plan each day toward the Sprint Goal; and,
Holding each other accountable as professionals.
“Wow. Gulp.”
Oh, and then we’d need someone called a Product Owner who is responsible for maximizing the value of the product resulting from the work of the Scrum Team. They are accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood.
“Wow. Double Gulp.”
And then it turns out there is this person, a Scrum Master who is accountable for establishing Scrum as defined in the Scrum Guide (I was reminded that I could listen to a free audio book – that is about 30 minutes long – from someone in the Scrum Community (Michael Vizdos) reading this to me!).
The Scrum Master is a true leader who is responsible for creating an environment where a high performing team can exist (thinking back to the tuckman model of Forming, Storming, Norming, Performing, and Adjourning).
This is going to require a team reset and possibly getting everyone involved up to speed by onboarding our team members at the beginning.
That section of the Scrum Guide really helped me in setting up the expectation that the Scrum Master serves the Scrum Team, Product Owner, and the organization in several different – and very important – ways.
“Triple Gulp. Wow.”
I am still considering scrum and thought, “What does this Scrum thing look like in reality.”
There is this thing called a Sprint which is a container for all of the other four Scrum Events.
We’d need to figure out how to do Sprint Planning, talk to each other daily at our Daily Scrum, and then have a Sprint Review to get feedback from our stakeholders and end users. We’d finish each Sprint with a Sprint Retrospective and then rinse and repeat.
“Sounds simple so far.”
I dug a bit more into the four Scrum events (that we’d need to do each and every Sprint). The Sprints allow for a regular heartbeat where ideas are turned into value.
“Sounds like a good idea.”
I thought that having a fixed length of one month or less would help create some consistency and predictability for our team to [ Focus. #deliver ].
“Cool.”
Within the Sprint, we can use Sprint Planning to lay out the work to be performed and create a plan for our collaborative team to finish. The Product Owner helps make sure the attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. We can even invite people outside of our Scrum Team if needed. Phew.
As a team, we’ll address WHY this Sprint is valuable, figure out WHAT can be done, and allow the developers to figure out HOW the chosen work will get done.
Once we get started in the Sprint, we’ll get together for a Daily Scrum to inspect progress towards the Sprint Goal (and adjust the upcoming planned work). It was good to be reminded that the Daily Scrum is a timeboxed 15 minute – or less – event for the Developers on the Scrum Team. This really helps us improve communication, identify impediments, promote quick decision making, and eliminates the need for more meetings.
“Less time in meetings.
Sounds good to me.”
At the end of the Sprint, we’ll inspect the outcomes and determine future adaptations during the Sprint Review. This is not just a demonstration; it’s a working session where we have conversations with our stakeholders that will allow us to make adjustments to meet new opportunities.
After that, we’ll get together as a Scrum Team – no stakeholders – for a Sprint Retrospective to plan ways that we can increase the quality and effectiveness of our team working together. By the end of that event, we should identify the most helpful changes to improve our effectiveness (and even possibly add an idea to our Sprint Backlog for the next Sprint).
At the end of the Sprint Retrospective, it’s time to rinse and repeat.
“Eesh.”
I’ve learned about the Scrum Team and Scrum Events, but am really left hanging wanting to learn more about the Scrum Artifacts and each of their new commitments.
I am seriously considering scrum in my world but want to dig in a bit more before getting started.
Each artifact contains a new commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
For the Product Backlog it is the Product Goal.
For the Sprint Backlog it is the Sprint Goal.
For the Increment it is the Definition of Done.
The Product Backlog is the single source of work undertaken by the Scrum Team. This is where we get items ready for the next Sprint Planning event (through Product Backlog Refinement).
The commitment to the Product Backlog – the Product Goal, is the long term objective for the Scrum Team.
“I’ve heard people refer to this as “The North Star” or something like that.”
It’s also important to remember that a product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
“Phew.”
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). This can be updated throughout the Sprint and should have enough detail for our team to inspect their progress during the Daily Scrum.
We should use the Sprint Goal as the single objective for the Sprint. It’s important to remember we need to leave the Sprint Planning event with this Sprint Goal added to the Sprint Backlog (so the Developers can keep this in mind as they work through the Sprint).
I am also reminded that this Sprint Goal is a commitment by the Developer and it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
“What do we need to Implement Scrum effectively and deliver something real?”
Scrum now calls these real artifacts an Increment. An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
In order to provide value, the Increment must be usable.
Oh, and I am reminded that multiple increments can be created within a Sprint, and the sum of all increments is presented at the Sprint Review (thus supporting empiricism) AND remembering that we don’t need to wait until the end of the Sprint to release value to our customers vs. end users.
We DO need to make sure that the Definition of Done is met so it can be considered part of the Increment. And remember that the moment a Product Backlog Item meets the Definition of Done, an Increment is born.
This commitment is something that the Developers must conform to (especially if there are multiple teams working together on a product; alas that scaling stuff is for “future me” to worry about [smile]).
It was great to wrap up reading the Scrum Guide End Note, where I am reminded Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
It was also a great place to read Acknowledgements of the People who helped create this framework along with a bit of the Scrum Guide History.
CONSIDERING SCRUM — THE END
Considering Scrum: What Next?
OK. Welcome back from the world of a fictional character walking through the Scrum Guide when considering scrum in their world.
I know. It was not a riveting story and I don’t think I can license the story as a Netflix series just yet [hey, if any peeps at Netflix want to buy an option for this just let me know lol].
I do hope it helps put a bit more context to the original comment from Stephen.
I do hope it helps
Remember that you, your team members, and your organization are all in different places of your journey in Implementing Scrum int he real world.
You can learn more (from four different vantage points) by selecting one of the following links:
START | PRACTICE | COACH | LEAD
Consider Implementing Scrum.
Talk to your team about it. Figure out where Scrum could fit within your organization.
And.
I can help with the conversation.
Really.
Contact me (with feedback) or connect with me on LinkedIn to discuss this more together.
Also, check out possible ways to bring me in for a consulting engagement to help get you started today!
One final thing…
Subscribe to my weekly Saturday morning emails about Implementing Scrum in the real world. And get an “every two week” check in from me too.
What could be better?
About the Author: Michael Vizdos
Hi. I sincerely appreciate you reading this article. My name is Michael Vizdos and I’ve had the privilege of working with thousands of people on teams all around the world for the past 30+ years of my professional career.
You can read more about my background or contact me or connect with me / send me a direct message on LinkedIn .
Can you do me a quick favor?
If you found this article helpful, please "right click and share" the following link with your internal team (think slack channels) or out on your favorite social media platform:
Considering Scrum: Implementing Scrum In Your Organization by Michael Vizdos.
Do you have some feedback to share with me?
Contact me and let's start a conversation. Really.Otherwise... Keep learning more by clicking through the links to my other articles below. Thank you!