In our Service Thinking Introduction we talk about how we aim to supplement rather than replace existing frameworks or libraries of practices.
This topic is part of a series that explores this - this time looking at how Scrum aligns to Service Thinking, and how as a Scrum team that you might apply the Service Thinking Guidance.
All quotes are taken from the 2020 Scrum Guide
Team Purpose & Measures of Success
According to the Scrum Guide, the purpose of a Scrum team is to deliver value to a set of well-defined users or customers via a Product:
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.
Scrum is also clear that the Team should have end to end responsibility for this product, and are empowered and have delegated responsibility for everything relating to this product:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work
This aligns to the Service Thinking idea of having a clear Purpose rooted in a customer need, however we would encourage you not to tie your Purpose to the way in which this need is fulfilled, but to give yourself remit to find the most efficient and effective way of fulfilling this need, changing this over time as the customer need and your wider context evolve.
And we’d encourage you to agree some Measures of Success that show how well you’re fulfilling this need - something the Scrum guide doesn’t cover.
See the Purpose and Measures of Success guidance for more detail.
Ways of Working
Scrum is a great tool for helping you solve complex problems:
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
But Service Thinking says this is only part of what a team that has end to end responsibility for a product needs to do - it needs to be able to innovate and experiment to understand their customer need and how best to meet it, and they need to operate, maintain and support their products.
And as much as we love Scrum, its lightweight nature means it doesn’t cover everything. So support your implementation with some Innovation practices (Lean Startup, Design Thinking, Empathy Mapping etc.) and if your product involves humans delivering a service, look at tools like Lean and Kanban for optimising your delivery or operation of that service.
See our Innovation, Change Delivery and Run Operations guidance for more detail.
Values & Principles
We love the fact that Scrum is built on a set of values (Commitment, Focus, Openness, Respect, and Courage) and principles (Transparency, Inspection and Adaptation) - having clear values and principles that drive decision making and actions is a key part of Service Thinking.
However, do the Scrum Values and Principles inform your day to day decision making? Does everyone in your team understand them? Would any of your recent decisions have been different if you’d better considered these? As a Team, are there any other Values or Principles that you think influence or should influence your decision making?
See our Values and Principles guidance for more detail.
And we love that Transparency, Inspection and Adaption are key principles within Scrum. We’ve called these out with specific guidance sections around these - Transparency and Continuous Improvement
Team Structure and Decision Making
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies
We agree with Scrum that there’s only one “doing” role. Is everyone on your team collectively responsible for delivery of your goals? Have you created sub-teams by having people that only create/build and people that only test/assure? What can you do to broaden skills so that everyone on the team can pitch into whatever the priority is?
We also agree that someone needs to coordinate decision making in what you do (Product Owner) and how you do it (Scrum Master). Do you have a shared understanding across the team of what these roles are responsible for? And do they co-ordinate and facilitate, or are they the only people that are allowed to do part of the process of delivering value to your customers (like talk to your customers to gather requirements)?
However as Scrum says:
[Teams are] self-managing, meaning they internally decide who does what, when, and how.
What would it mean for you as a team to select your own Scrum Master or Product Owner? And to rotate these roles between the people in the team on a semi regular basis? What would need to change with these roles to allow this to happen?
And finally, do you understand how you make decisions as a team? Does everyone get a say? Do you have every voice that has a role in a decision or is impacted by a decision involved in the decision making process?
See our Team Structure and Leadership guidance for more detail.
Longer Term Planning
Scrum talks about a longer term Product Goal:
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
Do you have a clear Product Goal that drives your sprint planning? Is this timebound? Is there a process for prioritising and agreeing your Product Goal?
Service Thinking suggests there’s more you can do in this space. Firstly, do you have a long term vision for your product, and a clear strategy for achieving this vision that drives your Product Goals?
Would a roadmap that shows what Product Goals the team is expecting to work on over the coming year or two be a valuable planning and communication tool?
Would there be value in a longer term planning cycle - e.g. quarterly? That agrees changes to your strategy and roadmap, your headcount and budget? That includes a strategic review of how delivery of your Product Goals is driving delivery of your longer term vision?
We think there is. See our Vision, Strategy, Objectives, Roadmap and Review & Setting Cycle guidance for more.