I’m a little obsessed with Product Definition. I’ve seen it make a huge difference for teams that have experienced it. Teams experiencing frustration, constant dependencies, competing priorities, and a high number of different types of work in the Product Backlog have all found relief, clarity, and renewed purpose through product definition.
So many teams “go agile” within their current team structures. And that’s great. They are likely experiencing more collaboration, greater autonomy and a greater sense of purpose as part of their new teams. But is that really all we can expect from an Agile transformation?
Agile teams focus on value delivery. But value delivery - for whom? In order to deliver value to our customers, we should first take a step back and ask, what is the product?
In this article, we will cover seven step to a defining Product and rolling out Agile teams aligned around value delivery.
Step 1: 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 its use is growing in human resources and marketing contexts. The Scrum framework excels when there are many variables at play.
Ralph Stacey at the University of Hertfordshire designed the Stacey matrix to resolve 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.
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.
(For further discussion on when to use Scrum, sign up for the Professional Agile Leadership Essentials class or the Professional Scrum Master class.)
Step 2: 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. Contact Rebel Scrum for a facilitated workshop to define products at your organization.
Step 3: 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.
Step 4: 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 finding 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. The restrictions of these guardrails depend on 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.
Step 5: 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 class 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 allows leaders 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 who are accountable for the Scrum Master 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.
Step 6: 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
Step 7: 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) and 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 and improve 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.
Scrum Day 2024 is scheduled for October 23, 2024, in Madison, Wisconsin. This year's theme is "Deliver Products with Value". Break-out sessions will discuss how to use Evidence-based Management to focus your team on value and how to define products to ensure that teams are aligned around value. Other breakouts will focus on using AI to reduce repetitive tasks and help the Scrum team focus on complex work.