The lack of proper communication with customer and the developers’ passive expectations of more initiative from the business to provide the team with everything they need creates costly problems for both parties. The modern Scrum framework solves this dilemma.
The Cost of Poor Communication
One of the most acute problems in the relationship between customer and developers is the lack of communication, resulting in some perils:
- Creating a product that the customer doesn’t want
- Deficiency of the critical functionality
- Time spent on secondary or even redundant features
- Constant delay of releases
- Increase in costs due to re-works
- Loss of benefits (reputational risks, weakening of market positions, etc.)
This indicates the need to find solutions to these problems and deliberate communication to achieve a product goal.
Seven Areas of the Scrum Team
The modern Scrum has taken a step forward and become even closer to business. The official Scrum Guide 2020 mentions at least seven areas of responsibility for the scrum team:
- Stakeholder collaboration
- Research (market research, product prototyping, UX/UI design)
- Verification (code review, quality assurance, live pilot testing)
- Operation (release management, DevOps)
- Maintenance (IT support)
- Experimentation (running proof of concepts)
Transparent interaction with stakeholders builds trust, which subsequently empowers Scrum Team to take responsibility for those areas. The only way for a scrum team to become naturally accountable requires the following characteristics:
- Synergistic. Developers with different skillset (e.g., programmers, testers, analysts, etc.) deeply integrated with each other, and synergy of the team integrated into its business;
- Complete. Multi-skilled teams empowered to act autonomously within high-level boundaries such as business strategy, IT strategy, company values, etc.;
- Competent. Each team member excelled in one or more areas of responsibility mentioned above, and the team as a whole can cover all seven departments.
Classic structure of the Scrum Team requires the Scrum Master to ensure proper implementation of the Scrum Framework. The Product Owner represents the interests of stakeholders, and the Developers create the product.
The Symptom of a Scapegoat
According to the official Scrum definitions, the Product Owner has a high mandate of a business representative. It is the one who often becomes a scapegoat when something goes wrong. Usually, the main reason is the lack of communication between stakeholders and developers. The modern Scrum is aware of this problem and created a solution for overloaded Product Owners. The scapegoat symptom is actually dangerous, as it indicates a low level of responsibility and maturity of the entire team. The key is to shift the focus from one role (for example, the Product Owner) to the entire team. This reduces harmful dependence on one person and helps speed up development.
It sounds surprisingly simple, but implementing the transition from “scapegoat” pattern to team responsibility is extremely difficult. To achieve this, the team must be mature, and the Scrum Master must coach collective ownership.
Who are the stakeholders? In the context of IT product development every interested party can be considered as a stakeholder. But how to identify an interested party? Here is an example:
It is known that every digital product must comply with current legislation. Therefore, it must be brought in line with the regulator requirements. This is the competence of lawyers and internal compliance controllers. Thus, lawyers may become participants in the development as stakeholders. Finance, marketing, sales managers, and other business people will act as stakeholders when their participation is needed to research, develop, verify and release the product.
Harmonious Relations with Stakeholders
Each company division has its own specifics, so there is inevitable friction at the root of their interaction. These frictions become acute when they compete to push their priorities down to the product teams. To achieve a product goal the modern Scrum calls to achieve harmony in these interactions.
The construction of harmonious relationships can depend entirely on few people (often, a product owner becomes such a figure), which leads to:
- Dependence on key figures;
- Toxicity. For the achievement of the whole team, praise one “favorite “, which causes envy, feelings of injustice and demotivates the group.
Who should solve the problem of relations with stakeholders? We’ve found that putting hope in an individual (such as product owner) is the wrong and outdated way to go. The modern Scrum insists on strengthening the role of the entire Scrum Team. Accordingly, “stakeholder collaboration” is the first item in the Scrum Team areas of responsibility. Thus, it is the self-organized Scrum Team that is responsible for building harmonious relationships with stakeholders.
How exactly to achieve this? The team decides for itself. It makes its own efforts and involves the appropriate specialist or business representative whose role is needed for development. One way or another, whoever played a significant role in building a communication bridge, the principle remains the same: the team is responsible for the relationship with stakeholders.
Black Box Strategy
How exactly does the “entire team responsible for stakeholder collaboration”? Scrum deliberately leaves this mystique to the team. Let’s illustrate this with the example of the “Black Box”.
At the entrance, we have a number of tasks that need to be performed. The output is the desired result. In the middle – a black box. When the result satisfies or exceeds stakeholders’ expectations, no one cares what is inside the “box”.
Let’s draw a parallel with football. The center forwards score the goals and, therefore the first to receive the crown of glory. Nevertheless, in interviews with journalists, they often say: “Victory is not my credit, but the achievement of the whole team.” If not for the midfielder’s pass, the striker would not have realized the goal moment. If it weren’t for the defenders and the goalkeeper, the team would have missed many goals and couldn’t have won. Something similar is happening in the work of the Scrum Team.
Examples from practice
The company had its own in-house software development. The programmers settled comfortably in a crystalline open space on the 24th floor, while the businessmen on the 25th.
Business representatives unsystematically required IT specialists to perform a task and did not always get the expected result. As a consequence, they formed a negative attitude towards colleagues. This created an unhealthy climate in the company and harmed software delivery outcomes. The twenty-fifth floor openly despised the residents of the twenty-fourth, who felt discouraged! What kind of motivation could we talk about?
The company’s management invited us to introduce Scrum in one of the IT projects. The first thing we did was ask the business to find a few people to play product owners who would represent the interests of the whole company and move it from the 25th (where there were business people) to the 24th (to the IT cohort). Based on the Scrum framework, we formed a new Scrum Team.
A business representative (Product Owner) in the heart of product creation has helped eliminate many obstacles, gather valuable information, convey important information to stakeholders. A harmonious relationship in cooperation with the product owner on the territory of the developers was formed. Everyone observed the positive results for the first month of work in such setup.
To achieve the desired result, we ensured Scrum team members understand the expectations of stakeholders. The style of communication has been changed to non-violent (stopped unacceptable toxic type of communication – superficial, arrogant, humiliating, or even intimidating). Stakeholders once understood the development team’s expectations began to interact with more trust and respect. promptly providing the necessary information.
The customer of our consulting services was an investment bank that had to develop a digital solution for one of its services. We provided the team with everything they needed for development and programmers, testers, analysts functioned like a single organism. We have formed a complete and synergistic scrum team.
It soon became clear that the product owner was too overwhelmed with operations, no matter how hard he tried to keep up. Due to lack of time, he simply did not have time to work closely with stakeholders, and we quickly felt this gap. We were just honest, frank, and open to finding the best solutions. So together with the team, we agreed that the best solution is to involve another expert who will also represent the bank (customer), work as a part-time team member, and as an insider, he will provide the team with all the necessary information to support development.
Thus, the product owner provided quality communication with end-users and the company’s management, while the expert provided in-depth information about the business problem to solve. There was a successful tandem of two business representatives.
The team also worked professionally, behaved proactively, asked all the questions necessary to better understand the customers’ expectations. Thanks to this tandem, we have successfully achieved a harmonious relationship with the customer. According to the old habit of blaming the product owner, no one would take responsibility without the “tandem”. Instead, the result pleased everyone:
- Releases came out more often than before
- Reliable delivery
- The customer received a quality product that flawlessly performed the most critical functionality.
- Scrum meets the need of modern business through shifting autonomy of the Scrum Team and empowering it to take over seven key areas.
- Managers need to be aware of their responsibility to build a harmonious relationship with developers, providing them with the necessary information and eliminate bureaucratic obstacles to product development.
- Developers need to grow into a mature team where internal work integrated into external business context.