Of course, who hasn't been through it: The (product) management sets budgetary and/or time targets for product development and “once again the development team has missed the targets". Frustrating! But even more annoying is that the developers also conclude that they have built up technical debts due to the tight schedule, or that they were not even able to set up the testing properly. What’s the reason? Although there was an extra buffer in the planning!
Challenges as a Scrum Master
Regardless of possible methods and ways to avoid such problems in the first place (have a quick look into: Estimates in everyday project life), one of the most important tasks of a Scrum Master is to ensure that a team can achieve its goals.
The Scrum Guide does not necessarily describe practically which challenges a Scrum Master has to face in his daily work - and they are quite difficult. Below are the top three problems that I have encountered frequently in companies or projects:
- Waterfall-like approach vs. agility
- Disconnection between "Product Management" and "Delivery Unit”
- (Too) many people in the company influence the product development
I am often asked how to deal with these problems as a Scrum Master and the answers are difficult to put in practice:
Remember the values of the agile manifesto
Smart and experienced people started thinking about what agility means more than 20 years ago:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Source: agilemanifesto.org
From these values, many possible solutions to the issues named above can be developed.
Example: A product management specifies that a feature or an entire product must be implemented by a certain date. In the process, no consideration is given to the fact that estimates have to be made by the development team. Instead, the product owner is supposed to provide rough estimates. The implementation does not match the specification, the project fails.
Solution: Product management needs estimates. Since rough estimates were enough in the past, the Scrum team was bypassed in the process. A different process needs to be established. The Scrum Master should already intervene when estimations are required from the PO and reflect together with the team on how the process can be modified. Product management must be briefed on the estimation methods and possibilities. Instead of an entrenched process and statements like "I just need a rough, approximate figure", a new process needs to be worked out together. The Scrum Master should also demand that the PO prioritises the important features in coordination with the product management. Accordingly, the PO and the development team can inform about the progress of the features at regular intervals, e.g. in the sprint review. Product management can then adjust the prioritisation at any time in coordination with the PO or actively contribute to the product that is to be developed through feedback.
This example shows how critical the basics of the agile manifesto are and what relevance they actually have for everyday life in a company. In addition, it clearly shows that a neutral person recognises the problems and deduces either to introduce new processes or to remind and demand existing processes.
Transparently show the advantages & disadvantages of agile working methods
People are quick to downplay complex problems with an apparently simple solution. For many, agility is therefore the long-awaited answer to rigid structures and the "modern" working environment that many people desire. It is rarely critically enough questioned whether both the philosophy and the concrete processes in the company are in line with agility. Just as quickly as the announcement "We're doing Scrum!" is proclaimed loudly in the company and the long-awaited "fresh spirit" in the company is longed for, first problems arise. Scrum is not the answer to all problems, but in the best case it delivers more advantages than disadvantages in the methodology for a company. When evaluating the introduction of Scrum, the risks must not be underestimated. On the contrary: the more all individuals in the company are involved in the process - and thus the company - the closer one comes to a common understanding of what agility means in the corporate context.
A Scrum Master should continuously guide this process and insist that the organisational structures outside the "development department" (e.g. sales, management) are regularly trained in the Scrum process and thus help to promote understanding. At this moment, it contributes significantly to the development team being able to focus on what it is there for: developing software.
Following the Scrum process
The Scrum development process is explained in detail on the internet and in various literature. Nevertheless, the Scrum Master has to point it out again and again and also actively engage in conversations to defend the process. A common example is that people with authority in the company (e.g. managing directors, product managers) undermine the sprint cycle and would like to modify the sprint scope. The Scrum Master must support the Product Owner in an advising role and, if necessary, try to talk to the corresponding people. Often it is enough to show that necessary adjustments can be made, but there several dependencies are fundamental to the implementation. Changes to the implementation must be considered in the context of the overall architecture. This results in a significantly higher effort than originally roughly estimated. Especially here, the Scrum Master can clearly point out the dependencies in the development process in a clarifying conversation and therefore turn away from an emotional argumentation towards a logical one that builds on each other. The Scrum process is not an immutable procedure, but is developed and lived by the individual employees. In detail, there are different preferences and needs how the process can be included in the overall company processes. The Scrum Master acts here as a mediator and advisor who adapts the process individually with the people in the organisation to them and their working reality.
Influence on corporate processes
A Scrum Master also has the responsibility to work on organisational changes to help the team. This means that an experienced Scrum Master recognises problems in processes which, for example, have arisen historically or are new due to restructuring in the company. The Scrum Guide does not explain how collaboration with dedicated product management works. Many companies implementing Scrum for the first time have historically separated product management from the rest of the Scrum context. This results in a variety of problems: Misunderstandings in the implementation, different ideas about budget, time and quality or too large a scope of product features then become common. Pressure is then often put on the Scrum team. Frequently it results in an attitude of defiance or actively working against each other against the „bad management". If you find yourself in this situation, you need to take action, because the problems can be solved. The Scrum Master should intervene here in a mediating and moderating way. Possible approaches range from clarifying discussions to training on how to proceed. In the end, each company has to find its own way. It is important that a role that is not actively involved (Scrum Master) accompanies this path and starts the communication.
What possibilities do you have as a Scrum Master to demand processes?
Documentation of the retro results and decisions on a clear board
A good way to create an overview (both for the existing Scrum team and for new team members) is to collect the decisions and commitments from the retrospectives on a separate board. Results of retrospectives are often documented in separate pages in documentation tools (e.g. Confluence). The decisions then get lost with time. A good basis for cooperation is a board, cumulative with all decisions, which is also regularly reviewed by the team in retrospectives. Are the rules still up to date? Are the rules still appropriate and consistent with the team's process? Do the rules need to be modified or discarded? The Scrum Master should regularly check with the team whether the defined processes fit the company in this form.
This board also can be used as a template that a Scrum Master might use to explain to people in the organisation outside the team how the team works and what it values.
Describe your impressions in retrospective
A Scrum Master should only act as a moderator in retrospectives and not be seen as a participant. However, depending on how the team members talk to each other, it is sometimes necessary for a Scrum Master to raise issues. Of course, a neutral position must be adopted in order to describe observations and present the resulting problems analytically and clearly. This helps to find solutions together in the team. Why retrospectives are needed, what needs to be considered in retrospectives and how they can become a successful and motivating factor for the team, we will describe in a following blog article.
Addressing team members in a conversation of trust
Often people have different ideas or even problems with a process that has been defined together - but do not have the confidence to bring their concerns into the discussion. This can result in individual team members not behaving according to the common process or even actively opposing it. A trust conversation helps here, in which the Scrum Master has to find out what fears are behind the behaviour. The Scrum Master has to be very sensitive to the person's fears and concerns. It may also be useful to try to talk to the team if the concerns relate to the team.
Conclusion
Referring to the title of this article, I draw the following conclusion: based on the experiences shown in everyday project work, the importance of the role of an active Scrum Master becomes clear. This person has to demand compliance with defined processes and procedures in software development from people outside the Scrum team, no matter in which position they act. In other words, if this role is not staffed or if the Scrum Master is only seen as an administrator of the team who creates appointments and moderates meetings, it is missing the neutral role in the company that ensures that different people can work successfully together. Misunderstandings, faulty communication and working against each other instead of together is then often the result. It is also important that Scrum Masters intervene in this process in an objective, calm and argumentative manner, as emotional attitudes are usually already adopted by team members. The Scrum Master should be the voice of the rational here, analytically grounded. Most importantly, however, such a role constantly refers to the Scrum framework and never get tired of consistently reminding people in the company of the rules of the game. Only then is it possible that Scrum is really lived in the company and does not just remain a vision of agile idealists. A company can only be as good as its employees, who work together instead of against each other in efficient processes - and at least one person must demand this: the Scrum Master.
Did you or your company recognise parts of it? Feel free to contact us if you need support. We can help you get the processes up and running again.
Jakob Hofmann is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/warum-ein-scrum-master-prozesse-einfordern-muss/
Feature image: Photo by Denys Nevozhai on Unsplash
Top comments (0)