SDN 2023 - Is the stakeholder allowed to do this?
SMART DEVELOPMENT NEWS 2023
Agility is finding its way into the development of mechatronic products in many forms. In the best case, the Scrum Guide can be implemented almost completely. However, there are often organisational or structural conditions that require special solutions in practice. This does not make such teams any less agile - on the contrary, as far as the special solutions are well tailored to the specific challenges, they usually provide a better basis for the development of the agile mindset, since the teams do not have to struggle with "unsolvable" problems of textbook Scrum. However, one challenge remains in any type of implementation - the interaction between agile teams and the (manager) stakeholders. This involves entering new territory, which causes uncertainty and tension. And not infrequently the question arises:
*"Is the stakeholder allowed to do that?
The review as the only interaction between the agile team and stakeholders?
The Scrum Guide describes five events or meetings. There is the sprint planning, the daily, the backlog refinement, the review and the retrospective. Only in the review are the stakeholders explicitly mentioned as participants. This means that in a two-week sprint - the most frequently used sprint duration in the environment of mechatronic projects - the stakeholders only interact with the team members for 1.5 hours within 14 days.
For some top managers, this may well be an appropriate, and often much more frequent, level of contact. But for group leaders or team leaders who worked with their team members almost daily before the agile (pilot) project, this is a radical cut. And especially since the agile project is often accompanied by a change in seating arrangements - agile teams should be co-located, i.e. sit in the same area. This means that the agile team becomes the employee's new home, while the organisational team loses importance and there are thus fewer opportunities for chatting at the coffee machine.
The stakeholder as a disruptive factor
Furthermore, in many reports from agile projects, the "intervention" of stakeholders outside of the review is described as a disruptive factor - the expression "rushing in" is used more often. This type of disruption is then mentioned as one of the reasons why a Scrum Master is absolutely needed to protect the teams from these interventions.
In this respect, it is understandable that the stakeholders, especially from the group and team leaders, are not only unsettled. One can somewhat describe the feeling with "From Hero to Zero powered by Agile" that is developing in these circles. Is that the point of agile working?
Certainly not, because one thing must not be forgotten. The vast majority of stakeholders are valuable bearers of experience who have not been entrusted with leadership tasks for nothing. They have many years of knowledge that many of the employees do not have. It would be fatal for the company not to tap this potential in an adequate form. And it is also clear that one and a half hours in a fortnight is not enough to sufficiently bring in this potential.
The self-organisation of the teams must be in the foreground
However, it is also clear that something has to change with the introduction of agile working. The transfer of knowledge and experience between manager and employee no longer takes place in the close relationship as before. In particular also as a - possibly clearly noticeable - combination of professional and disciplinary, i.e. directive, leadership. Agility aims in particular to break this link.
Technical leadership should develop into coaching or counselling. While disciplinary leadership is more about administration (leave, contracts, etc.) and personal development (training and development).
But what is the point of this approach? Why is this changed approach more successful for the company in the end? There are two aspects that make the difference.
Making better decisions as a team
Most development projects of mechatronic products are in the complex range in the Stacey matrix. There is a high degree of uncertainty as to what should be developed, i.e. what set of product features the product should have. In conjunction with this, but also often detached from it, there is uncertainty about how the product should be developed. Ultimately, it is not only a question of technical specifications. An increasingly important factor is the behaviour of the market and customers. What buying behaviour does the customer show, what features will the competitor products, about which no information is available at the time of development, have?
These questions bring a high level of complexity even to projects that have been carried out in a similar form for decades (example: automotive industry). The times when product managers specified the product precisely in specifications and then the development teams had several years to develop exactly this product in good quality are over. The market and customers change far too quickly, as do technologies.
In this environment, the best decisions have to be made - the product has to fit exactly. Not too little, but not too much, if only for cost reasons. The agile premise is that such decisions are best made in a team. There is the role of the product owner, who is responsible for this. But since in the case of mechatronic products the engineering or technology is very often the basis for deciding on the characteristics of product features, the decisions can only be made in a team. Experience shows that such decisions in a team are in most cases better than the decision of a single manager. Even if one assumes that this manager consults with colleagues and/or staff on his or her decisions in the team, the amount of time needed for the exchange and consideration of alternatives is nowhere near what an (agile) team can manage.
Complex decisions need constructive discourse and many perspectives. Trying to shorten such processes means the high risk of having a decision quickly, but the wrong one. Therefore, in these cases, one can and should rely on the "swarm intelligence" of the team with a clear conscience.
Providing good employees with an environment for motivated work.
But there is a second aspect that is becoming increasingly important. How does a company recruit good employees and how does it offer them an environment in which they can work in a motivated and committed manner? To cut a long story short, there are three factors that play an important role in this: Autonomy (self-organisation), Mastery (professional excellence) and Purpose (understanding the meaning of action).
These factors are initially completely independent of whether agile working is used or not. And there is no doubt that they can also be implemented well, at least in part, in the classic working environment. But interestingly enough, agile working promotes precisely these three factors, especially at the point around which the core of this article revolves. Because in agile working, the cooperation between the agile team and the managers is taken to a new level. Classic leadership through expertise and, if necessary, also instructions, is becoming much less important. In contrast, coaching and counselling become more important.
Whereas in the past communication often took place in the push principle, in the agile environment it happens more in the pull. The team members look for the professional leaders - who do not necessarily have to be the group or team leaders - from whom they need advice and support. It is also a clearly communicated company principle that seeking advice and giving advice are wanted and that time is available for this.
Is the stakeholder allowed to do that?
But what exactly does this mean for the stakeholder? As mentioned above, it cannot and should not be the purpose of agile working to reduce the interaction space between manager and team to 1.5 hours per sprint. Nevertheless, the action space in between is critical uncharted territory, because nowhere is it described what it should look like or how it can be designed.
The key premise that has emerged from many agile projects is that it should be robust and authentic. There are many ways to design communication between team and leader outside of reviews. As far as it is oriented towards the three motivational factors Autonomy, Mastery and Purpose, there can't be much wrong to begin with. The pull principle for seeking advice has already been mentioned and that time shares should be scheduled in the sprints for this purpose. If the supervisor manages to take on the role of trusted advisor instead of team leader, he or she will take on a leading role anyway.
Against this background, there is a clear answer to the question: "Is the stakeholder allowed to do that?" - Maybe! Insofar as his or her intention is to strengthen the classic leadership role, the approach is questionable. If, on the other hand, the intention is to strengthen the positive factors mentioned above, then the stakeholder is allowed to do so. Perhaps the form in which the behaviour is implemented still needs to be optimised at one point or another. But this can certainly be clarified in constructive discussions.
The core message for agile teams and leaders is important: there is definitely intentional interaction space between them outside of the review. However, it can be a good idea to get support from an agile coach in the first phase of an agile pilot. If you only read the Scrum Guide, you will not find a solution to this question. Therefore, it can help if the contact area between the team and the managers is clarified right from the start in a moderated discussion.