“Why doesn’t the role model work in our situation?” The old culture does not give way to the dynamic model. The conflict between the old and the new paradigms (it is not about the age of people, but the worldview) is one of the most significant risks in the Scrum approach in general and the formation of scrum teams in particular.
Problem Gravity
The main reason of success in product development is the team. It is also the common cause of failures. Hundreds of books have been written about the team, and many training courses have been created to improve team spirit, teamwork, team organization (you can continue the list of ” team xyz” on your own).
Why do some companies bring a product to market faster than others? There are many different views on the concept of “product team”. However, Scrum has a clear idea of a team that did not come from nowhere. (See our previous article, “Scrum role model: how it originated and why it is important“).
So, in this article, we will consider the minimalist and surprisingly effective model of the team in Scrum, which it is today. We call it a role model because it is about specific roles in every Scrum team. The absence of at least one indicates the lack of Scrum. It may be a “similarity” to Scrum, its imitation, a hybrid or scrum-like model, but not Scrum.
Background
So, in the 1980s, companies learned to produce user-friendly products with buttons, knobs and mini-displays. In the 1990s, various IT professions emerged, which allowed programmers to focus on coding. However, the diverse entourage that surrounded developers everywhere alongside with the complex multi-level organizational management structures became a problem in the 2000s. Business analysts, paper architects, designers, technical writers, project managers, middle managers, functional managers, and other managers were called to help with delivery of the software. But something didn’t go well …
“Who is the Culprit” Quest
The first was usually a tester, who quickly passed the baton to a programmer, who, in turn, blamed business analysts who were waving their hands because they were guided by requirements handed to them by IT product managers who could not understand what they want. When something went wrong, they started the quest “find the culprit”. But what claims may they have to the IT product manager? The executive committee of the department of digital solutions decided on a product roadmap where customer requirements were previously agreed upon with senior management following the stakeholders’ decision.
A whole cohort of experts with professional certificates “had eyes, but did not see, had ears, but did not hear.” They passed accusations to each other like football players, continuing playing on their half of the field.
Two personalities
This pointless quest bored many software professionals. Among them were Ken Schwaber and Jeff Sutherland, who:
- researched the specifics of product development
- connected their software engineers to the voice of the customer
- understood the pains of the business
- established empirical process for continuous improvement
Blaming each other within the group of people went down in a spiral to the bottom, dragging the whole company! That’s when Ken and Jeff stopped listening to the whining of the troubled specialists, bringing them into the same room, giving them Scrum, and iterating until customers will see a value!
Ken Schwaber and Jeff Sutherland were not interested in a local optimization to the technical problem of another project. They sought to invent a new systemic approach that recovered the ability to hear the voice of the end-user (preferably not after the project). The new system protected the team from external interferences and other influences that could block or slow down the work.
In addition, no one was going to remove the responsibility problem from the list. Who will be accountable for the final product?
Product Owner
It hence appeared the role now known as the Product Owner. It is about the part of the “owner”, which he performs as an authorized representative of the company, and is personally responsible for the product development decisions. Therefore, the Product Owner has a high mandate of trust, authority, and the power to make decisions. Often the Product Owner has much broader control over the product than its immediate manager. In the Scrum approach, the product owner’s decision cannot be revoked or modified, protecting the team from senior executives’ destructive whims.
In addition, the product owner is a bridge of communication between developers and customers. Uniquely, one person (product owner) replaced the futile activities of about a dozen officials of various types.
Scrum role model removed a wall between the end-users and developers. The division existed for a long time in a complex hierarchical structure with the many different roles at different levels now replaced with a short bridge of understanding – the Product Owner, single person, not a committee.
The absence of this role creates chaos, distraction, waste of time, loss of focus, confusion – after all, losses.
Structure of Accountabilities
With a brilliant decision to introduce the Product Owner role, authors of Scrum immediately felt the difference, namely:
- Simplification of processes;
- Improved performance (Jeff argues that scrum team can boost their productivity by 400%);
- The grown motivation of employees;
- Increased focus on the goal, which improved the quality of work;
- Reduced cost of development.
In addition, the Scrum role model made it possible to respond more quickly to consumer needs and create value for both businesses and customers. Together with the product owner, the required role of the Scrum Master was introduced (see below), and the concept of “development team” was specified. So, the Scrum role model finally finished.
What are the risks, and what to do with them?
“Why doesn’t the role model work in our situation?” – one of the gravest and acute issues we hear in Agile.Live, guiding companies in banking, IT, telecommunications, aviation, even in the mining industry seeking to introduce digital technologies.
The main reason is the same: the old culture does not give way to the dynamic model. The conflict between the old and the new paradigms (it is not about the age of people, but the worldview) is one of the most significant risks in the Scrum approach in general and the formation of scrum teams in particular.
There is a need to introduce the “upholder of Scrum” in addition to the product owner. There must be a person who will protect the team from old directive practices, regular interference, or external manipulation. She must be a highly competent expert who understands the nature of an agile mindset in product development development. At the same time, she must fully understand the essence of the scrum framework and ensure its effectiveness.
Scrum Master
The Scrum Master fulfills this purpose. His role also includes:
- Help the team to become more productive;
- Manage time-boxes;
- Coach a team how to be self-managed (scrum master should help the team to reach the fifth level of maturity – see the article “Five levels of transition to Agile: self-managed teams“);
- Ensure autonomy (bring the team to the level of self-sufficiency, initiative, and responsibility according to values of Scrum);
- Transform organizational culture;
- Manage Scrum framework itself;
- Remove impediments (usually the intervention of managers at different levels, lack of tools, the need for additional expertise, etc.).
Summary
First of all, it is worth mentioning that the role model in Scrum is self-sufficient. There are only three roles in the Scrum model:
- Product owner
- Scrum master
- Developers
The Developers’ configuration may vary, depending on the industry and the specifics of the project (programmers, technical specialists, engineers, technicians, designers, circuit engineers, if necessary, marketers, and specialists in non-IT areas). This model is sufficient for successful product development.
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