When people ask me the best way for their team to transition to Scrum, I tell them that there isn’t an easy answer, because every organization is unique. Keeping that in mind, here are some general steps to consider if implementing Scrum is on your horizon.
Is Scrum the right fit for your business problem?
First, you should honestly evaluate whether Scrum is the right fit for your business problem. Scrum is the most popular agile framework today, but agile isn’t the right fit for every business problem – it’s simply one of many tools in the toolkit.
Agile frameworks (including Scrum) perform best in complex environments where more is unknown than known, and creativity rules the day to determine the best path forward. That’s why Scrum is so popular for software applications and why its use is growing in contexts such as human resources and marketing. The Scrum framework excels when there are many variables at play.
Ralph Stacey at the University of Hertfordshire designed the Stacey matrix to describe when agile is a good fit. The matrix uses four categories to define business problems: simple, complicated, complex, and chaotic.
Agile frameworks - including Scrum - work best in business situations that are complex, where more is unknown than known.
When should you use Scrum? Agile frameworks, including Scrum, will not add value in simple environments where you can write work instructions for exactly how to deliver your product. Use your judgment and the advice of an experienced practitioner to evaluate the right approach for your context.
Define your Product(s)
Before establishing a Scrum Team (or teams) to deliver value, you must understand your product. Once you’ve determined that Scrum is a good fit for your business problem, the next step is defining your product. Many teams transition without defining the product boundaries that the Scrum Team will create, resulting in a team not being optimized to deliver value.
Defining your product starts with describing your customer. Who are they, and what do they want/need? What value are you delivering to them, and how is your organization rewarded? Once you answer these questions, you are on your way to better understanding the definition of your organization’s product.
Identify Resources
Once you understand what product you are striving to deliver, it’s time to determine the skillsets you need on your team to deliver that product. For example, if your product is a website, you might need team members with experience building functionality, designing user experiences, building database tables, content writing and more. These team members might operate as silos right now, but product teams should contain all the skills needed to deliver a valuable Done product increment.
How big should you draw the product box? Should it include the server team, given that your product runs on servers? Should it include the networking team? How far do we take this? The answer is it depends! Generally, if the team's day-to-day work encounters frequent dependencies or requires problem-solving, those skills should be represented on the product team. Once you’ve identified the initial product team members, the Scrum Team should determine what additional skills it needs.
Each team will need a Product Owner. It can be helpful to identify the Product Owner before a team self-organizes. In this case, the Product Owner can establish the product vision and Product Goal, allowing the team to use this information to guide their self-organization.
Prepare to allow the Product team to self-organize
Scrum Teams that own the problem of delivering their work realize better results than those not empowered to determine the best way to deliver value to the organization. The team members closest to work are better at figuring out the best way to deliver that work. This logic extends to the Scrum Teams determining how to structure themselves to deliver value for the product. I have seen Scrum Teams increase their throughput by over 160% simply by being allowed to self-organize.
Organizations can provide guardrails for team self-organization. How restrictive these guardrails are depends upon the parent organization, the team’s experience, and the product delivery environment. Sample guardrails are:
All Scrum Teams supporting this product must work from the same Product Backlog.
Each team must be cross-functional and have all the skills needed to deliver a done increment of valuable product at least once per Sprint.
Each team should have no more than ten members.
The Product Owner will have a budget of $xx.xx for the product.
You will notice that most of these guardrails simply restate the Scrum framework. Setting these guardrails upfront is one way to reinforce the expectation that all Scrum Teams supporting the product will adhere to the Scrum framework and thus optimize their ability to deliver value to the organization. Guardrails could exceed the Scrum framework requirements depending on your organization’s needs.
Scrum training for everyone
Before teams self-organize, those supporting them, including organizational leaders, should take Scrum training. Applying Professional Scrum (APS) is the best classes for those who are either new to Scrum or on a Scrum Team but need to learn more about Scrum roles, artifacts and events. If you’re not sure the APS class is right for you, ask yourself the following questions:
Did you know that the Scrum Team should create a Sprint Goal at every Sprint Planning meeting?
Did you know that Developers should deliver a Done, usable Increment at least once per Sprint?
Did you know that the Product Owner’s accountability is to maximize the product's value, but they can delegate the documentation of individual Product Backlog items to the Developers?
If you answered “no” to any of these questions, you would benefit from the Applying Professional Scrum (APS) course.
The Professional Agile Leadership Essentials (PAL-E) course is excellent for organizational leaders supporting Scrum Teams. PAL-E provides leaders with the opportunity to learn why Scrum Team members work on objectives rather than tasks and how to hold members accountable for delivery.
Individuals fulfilling the Product Owner accountability should take the Professional Scrum Product Owner course. The class delves into the critical aspects of Product Ownership and their relationship to the Scrum Team.
Finally, individuals fulfilling the Scrum Master accountability would benefit from the Professional Scrum Master (PSM) course. PSM covers the principles and empirical process theory underpinning the mechanics, rules, and accountabilities within the Scrum framework.
Self-organize
At this point, you’re ready to facilitate an activity allowing people to sort themselves into teams. It might be easier to assign members to their teams, but self-organization starts with this activity.
Engaging an experienced Scrum practitioner to facilitate self-organization will help ensure that your team feels prepared and empowered to make the critical decision of how to perform and manage their work. Following is how a sample agenda for a self-organization session might unfold:
Review product vision, Product Goal and initial Product Backlog (if available)
Ask team members to introduce themselves and their skills (if they don't know each other)
Review management’s guardrails
Have teams determine their structure (e.g. how many teams, how many per team, whether they will be feature teams)
Have teams identify and remediate weaknesses with their planned structure
Engage teams in choosing team names
Teams identify their Scrum Masters
Present proposed organization to managers
Managers ask questions
Start Sprinting!
You’re now ready to establish the Sprint duration and the timing of Scrum events (which you might choose to document using the complementary practice of team agreements) as well as a Definition of Done. It’s time to get Sprinting! The first Sprint might be challenging. But if you use the Scrum events as designed — especially the Sprint Retrospective — each one will get easier. Don’t expect perfection out of the gate. Living the Scrum values of courage, respect, openness, commitment and focus will help establish trust, improving the productivity and professionalism of your team. And a little dose of optimism never hurts.
Conclusion
Adopting the Scrum framework is the first step towards a better way of delivering complex products. Once you’ve determined that Scrum is the right fit for your environment, define what products you will deliver. Identify your resources, set guardrails and provide the right level of training to ensure success. Then, allow people to self-organize into teams that will support your product, empowering them to own “how” they deliver their work, including ownership over how they work together. Before you know it, your Scrum Team(s) will be delivering value in the complex product space.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Introductory class for those new to Scrum
Geared towards Scrum Masters coaching teams
Advanced class for Scrum Masters
For leaders and managers of Agile teams
Professional Scrum Product Owner
For Product Owners
Professional Scrum with Kanban
For anyone interested in learning about implementing Kanban principles within a Scrum Team
Scaled Professional Scrum with Nexus
For three or more teams working together on a single product
Both public and private classes are available. To learn more, contact Mary Iqbal.
