Great tips to optimize a scrum team in a multiple stakeholder environment.
The Radio team at VRT (public-service broadcaster) manages the websites for the radio brands. This article tells the story about how they transformed into a high-performing and end-user driven scrum team.
Scrum is simple but not necessarily easy. There are no silver bullets in agile, yet we will point out some principles that helped us perform better.
We hope you will be able to use some of these learnings from the trenches in your own setting.
Once upon a time at VRT
In the summer of 2016 the relationship between the Radio team and its stakeholders was strained due to a couple of incidents. All parties involved were unhappy with how things were going.
In October 2016 a new scrum master and product owner were appointed to start working with the team and its stakeholders.
A repair retrospective with the development team resulted in the following main concerns:
- We need better cooperation with the client
- We want less management
Less management
First of all, it is surprising to notice the word “client” in this context. The radio team is part of and physically works within the same company as the stakeholder brands.
The management concern mainly originated from the quite interesting structure surrounding the team. Next to a scrum master and product owner, there were several project managers. They acted as points of contact with the different brands and stakeholders.
Needless to say this resulted in a lot of waste and (mis)communication. Also two contradictory forces were at play here. The project managers tried to get as much work done for their own projects. At the same time, the previous product owner tried to adhere to the agile mindset of maximizing the work not done.
As scrum master and product owner we explicitly were given the freedom by management to make all the necessary changes to the system in this transformation.
The first change we made, was to remove all unnecessary layers of communication. We tried to move as close as possible to pure Scrum. A team, a scrum master and a product owner. Nothing less, nothing more.
Pulling in stakeholders
This approach was new to the stakeholders. So we organised a workshop with all brand managers and their heads of digital. We used the drawings from Henrik Kniberg’s amazing video about the role of a product owner.
After the introduction of the framework, we harvested feedback from the stakeholders. Three main concerns stood out:
- How should we do an intake? If we lose a dedicated project manager, and we have to share a product owner between stakeholders?
- Will you have enough capacity as a team?
- How will this scrum system be transparent to all stakeholders?
To address these concerns we added an extra ritual. A stakeholder meeting every two weeks in the middle of the 2-week sprint. A moment to talk between product owner and the different brands. About the roadmap, share learnings, address shared topics, with candor. Loosely based on the Braintrust mentioned in Ed Catmull’s Creativity, Inc.
Changes in the team’s operation system
Team culture is like an operating system. The team made small changes in their operating system to improve efficiency and effectivity.
A new definition of done
Definition of done or DoD, is an important and powerful element in scrum. It defines the criteria to move a story to the done column on the scrum board.
Or to quote the Scrum guide:
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
The initial DoD mentioned among other things that a backlog item was done as soon as it was deployed to staging.
Because of that only every 3 weeks code was deployed to production. This was not good for testing and stability, as all of the branches had to be merged and tested again in between.
Based on a retrospective, the team decided to change the definition of done to “deployed to production”. The effects were instant and spectacular. Where we first deployed every 3 weeks, now we deployed 3 times every week.
This brought new features and functionality much faster to our brands and their end users. Feedback loops became shorter. We had to pull in stakeholders on a daily basis during the sprint to validate the stories. Smaller iterations went to production immediately, with better quality control and testing.
A new way of accepting stories
A story needed to be fully documented initially. A photoshop file was almost mandatory to allow some stories in the sprint. We turned this ship around. Stories were not focused on the how anymore. We explicitly only talked about why and a bit about the what in stories.
This allowed the team to be much more creative in their problem solving. Instead of just executing what was asked, the dynamics during planning and grooming revolved more about the “why?”. We reduced documentation waste dramatically, and increased delivery speed. Let’s just build something based on what we know. Show it as fast as possible to the stakeholder and continue based on their feedback.
Pulling in the stakeholders
Start with why and co-creation
The stakeholders made a similar evolution. Instead of executing every question, we pulled them into a conversation about their why. A set of of tools was used to achieve this. The most important one was Impact Mapping.
We defined together with stakeholders what the goal was and which actors were at play. Then how they were impacted, and what we needed to achieve desired outcomes.
Another tool was Jeff Patton’s User Story Mapping. Similar to Impact Mapping it is a good tool to focus on end user value and purpose.
Always in co-creation using workshop formats. Never in classic meeting formats. Always short and timeboxed.
Starting with why and focusing on end user value. These were the principal tools to end the client-supplier relationship and grow into a mature stakeholder relationship.
Design Thinking as the golden nugget
We invited Design Thinking practices to the party, to emphasize customer value even more. Gaining empathy via double diamond approaches, data analysis, user interviews, the Jobs-to-be-done framework,… All these inspired the conversations between the team and the stakeholders.
A “Job-to-be-done” is a way to look at products or services not as mere solutions, but to investigate the higher purpose for which your customers actually use those products and services. It allows you to aim for value instead of features.
We often build things based on assumptions. But using quantitative data is not enough as a countermeasure. This kind of data gives you an idea of existing behaviour, but not about the deeper meaning. Qualitative data, especially gathered via user interviews, adds motivation to behaviour. They reinforce each other. And that is where the most compelling insights lie.
This mix of qualitative and quantitative data provides a clear why. It moves both the stakeholders and the team in the same direction. This reduces waste and improves effectivity and efficiency.
From a product owner perspective, this meant the biggest change. By using real user insights it became much easier to focus and prioritize.
Results after one year
We did a retrospective with the same stakeholders one year after the initial kick-off. The feedback was inspiring. Instead of concerns, the group of stakeholders saw two big opportunities.
“We want to become more data driven,” was the first takeaway. As we worked a lot with data reports after implementing changes, stakeholders were eager to do this even more. Let’s build, measure and learn, instead of just moving forward.
The second opportunity was all about eliminating featuritis. “Let’s stop doing things because we’ve been doing them in the past.” A clear call for more end-user value driven focus.
One more thing about efficiency and effectivity
Velocity is the heartbeat of a scrum team. It shows how the health of a team evolves through time. It indicates throughput and whether the team performs at a constant pace.
During this first year of the team, some transitions took place. 6 team members left the team. Due to circumstances and as an experiment we chose not to replace them. The team was reduced by half. However, if we look at the average amount of story points per team member, we noticed that something interesting happened.
Between sprint 12 and sprint 22 the team size was reduced, but at the same time the average amount of story points per team member increased.
We should not mix up correlation with causality. However, we strongly believe that the changes we made in the relationship between the team and the stakeholders had a positive effect. Even in such a way that reducing team size had no effect on the amount of story points.
Bottom line: focus on a solid scrum setup with good communication lines, working towards end-user value, clear priorities,… all of these can make a team almost twice as efficient for the organisation.
Key takeaways
In summary, these are the most important takeaways.
Focus on outcome (for users), not on output.
Which problems are your users trying to solve? What are their needs, concerns, pains,… Use these insights as guiding principles. Try to create customer value as fast as possible. Or to phrase one of the scrum principles, maximize the amount of work not done.
Focus on problems, not on solutions.
It is not about the needle, it is about the haystack. Don’t start with technical solutions for assumed problems. Search for brilliant problems first, and match solutions afterwards.
Reduce levels of management
Try to get as close as possible to the 3 scrum roles. A product owner to prioritize around user value, a scrum master to facilitate the process and remove impediments, and a cross-functional empowered team of experts. Any other type of project management role will add waste to the process.
Let it go
As a product owner and scrum master, let go of micromanagement, and give the ownership and responsibility to the team.
Aim for transparency, inspection and adaptation
These three pillars are the core of empirical process control. Make everything in and around your scrum team as transparent as possible.
Build everything around a stable product team
A team can only transform when there is enough safety. Stability in stakeholders and product focus is key.
“We are uncovering better ways…”
This is the first sentence of the Agile Manifesto, and perhaps the most important. This article is only a snapshot. It is very humble as well. We tried a lot of things, and some of those things worked. But there is no silver bullet. We operate in a constantly changing environments. So we must be vigilant all the time and keep on transforming.
