To successfully launch Scrum, you need to focus on two fundamentally essential components: a product goal and cross-functional team(s) to achieve it. Without fundamental elements, there is a high risk of wasting the scrum approach and the impossibility of all its advantages.
Simple in Theory and Difficult in Practice
Most scrum masters who come to us for training, as well as managers of companies that turn to us for help in implementing Scrum, ask the following questions:
- Why is the Scrum approach so simple in theory and challenging to put into practice?
- Why the official Scrum Guide defines concepts so concisely but without explaining how they work in real context?
- Statements such as “The Scrum team should consist of a Scrum master, product owner, and developer” sound too prescriptive. If we have our context so, why do you say we can’t change Scrum?
Two Key Scrum Features That Can be Challenging to Introduce
Of course, there are many more questions about the use of Scrum in everyday work. Still, I want to emphasize two fundamentally essential areas that are the cause and answer to the obstacles – the goal and the people:
- A single Product Goal that mingles all participants in the development often requires decomposition of the existing enterprise solution into smaller products which individual Scrum Team can be accountable for
- Proper cross-functional structure of the Scrum Team often calls for revisiting organizational structure
1. Product Goal
Watching a football game, sometimes we see that the players forgot why they came on the field. They did not “play” but “stroll”, with many passes back to the goalkeeper, no shots on goal. All indicated that eleven professionals were moving across the field with a lack of purpose.
Something similar happens in business when managers introduce Scrum without fully understanding “why”.
Both concepts (goal and team) are closely related. After all, team members need to “stick together” into a single cross-functional team for collective ownership of the product that they create. The first of these prerequisites is a Product Goal that each developer understands.
Case 1. A Headless Chicken
Have you ever seen a brutal picture of a running headless chicken? The head is gone, and she is still running.Something similar happened with the launch of Scrum in one global bank. Their management invited me as a scrum coach to examine the current state and improve the situation. At first glance, the picture was positive, and everything had to work. It turned out that the team did not understand the purpose of the work they do. It was a picture of “headless chicken” that received many tasks to perform.
In the enterprise development a product goal should drive a sprint goal of the individual teams. Interestingly, there was a product owner who knew how the team outcomes would integrate into a bigger enterprise solution. Still, he did not want to share knowledge with others. Mid-term goal for entire solution was there but never explained to the individual teams.
Somehow, the developers slowly slipped from Scrum into a waterfall factory. First, the programmers did all their tasks, and at the last minute, thrown to the testers, who never managed to finish it in the same Sprint. Eventually, the testers worked in a separate sprint from the programmers.
Product Owner who doesn’t express a product goal resembles a butcher who chops off the head from a chicken. The headless chickens will be running chaotically and not doing Scrum together.
2. People
Many Scrum teams were launched without cross-functional structure and require re-starting. Stakeholders often do not fully understand the underlying principles of the Scrum framework or how it works in practice, but still responsible to manage P&L. There are primary reasons why Scrum teams don’t contribute to positive P&L:
- There is no scrum master, or his role is dysfunctional.
- Misunderstanding the role of the Product Owner
- Team are not fully cross-functional
- Different departments running their Scrum and handover outputs from one team to another
Fragmentation of the product development across multiple departments makes implementing a scrum approach extremely difficult. Just reading a manual or a book is not enough. A true leader will seek to achieve the main benefits of the scrum approach – faster delivery of product increment to the stakeholders, faster product launch, and other competitive advantages. He will understand the goal and takes steps to join all participants around it.
Dealing with “fragmented” Scrum happened more than once in my product development practice. The situation required me to meet with the heads of departments to coordinate a Scrum pilot around a common goal. It’s not easy to implement. Undoubtedly, implementing the scrum model within only one functional department is unlikely to produce tangible results and radical changes that top management expects.
In the absence of established interaction between departments:
- The constant tension between Scrum team members
- Excess financial resources spent
- Product release significantly delayed
The inability to solidify group of specialists around a product goal tempts managers to cancel “this experiment,” believing that the problem is “approach.” Therefore, before launching a pilot Scrum team, managers should ask a few simple questions:
- Do we have enough specialists to create a product increment? If not, how many are missing?
- Do you need the help of specialists from other departments to make a release? If so, which ones? How many?
- What should we do so that all participants in the development team understand the goal?
Case 2. Scrum Hat
Global telecommunications equipment company invited us to improve the skills of their scrum masters. Expectations of the specialists who came to the training were to find some “secrets” of making “functional” scrum teams successful. I had to upset the audience openly. From the outside, everything met the requirements of the Scrum Guide. Each team had a product owner, scrum master, product backlog, sprints, retrospectives, and others. However, there was one unexpected “nuance”: testers worked separately from developers as a separate scrum team. Accordingly, they adjusted their Scrum so that the outputs of developer’s Sprint become the inputs of tester’s Sprint. It turned out that the same goes for designers.
Scrum turned into the timeboxed waterfall, remaining only in form, not content. Managers put a scrum hat on each department, but they continued to work in silos.
The majority of those present understood: company managers should be the first to come to the training and learn the principles of product development with Scrum. Otherwise, the company will lose time, financial resources, personnel.
Case 3. Lonely department
Safe transition to Scrum requires starting one team, learn Scrum in context, and then slowly scale by launching new units. But in the case of the largest banks in Eastern Europe, it didn’t go well. Unfortunately, the bankers did not feel any noticeable benefits from the “pilot” that can be scaled as is. Stakeholders wanted a scrum “pilot” in just one department. The only thing they learned was that the “functional” Scrum team sucks.
Despite this, the bank’s leaders decided not to give up and restart the “pilot”, eliminating the identified shortcomings and bringing the model in line with the Scrum.
Two Key Components Explained
If the team’s KPI is a number of tasks completed each Sprint, it isn’t easy to talk about the purpose that makes sense of the product. Each scrum team must produce increment as a stepping stone towards a common goal. The Product Goal should concentrate efforts of all specialists and experts and saturate all processes related to it. Not having a goal means stripping the team of the core that holds it. The entire Scrum team is creating the Increment within one Sprint to achieve the Product Goal.
To successfully launch Scrum, you need to focus on two fundamentally essential components: a product goal and cross-functional team(s) to achieve it. Without fundamental elements, there is a high risk of wasting the scrum approach and the impossibility of all its advantages, mainly the rapid product delivery to the market.
JOIN AGILE.LIVE
- Check the nearest certification trainings at Agile.Live: Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO).
- Connect with Agile.Live on LinkedIn
- Subscribe to Agile.Live Telegram channel
- Subscribe to Agile.Live YouTube channel