The superfluous Scrum Master

Why an investment in work equipment is desirable for (agile) software development, but is often ignored in recruited users, can be seen in the role distribution implemented. Developers, analysts and product owners are great titles – ehh… roles; or both? That’s sound and smoke anyway. After all, they all know the methodology inside out. That was at least part of the job posting. Anybody can do anything – somehow. At least the heads of companies and departments think.

The management scratches methodically, but unfortunately usually only on the surface. “Can’t be that hard. Why do you need a Scrum Master? The Product Owner can also take over the meetings.” And you have already revolutionised an overloaded methodology, saved an annual salary and let a motivated employee burn up in the mountain of fate. Sauron would be proud!

Why this thinking, which is everyday life in many companies, is a breeding ground for failing methodical company constellations, as well as for colleagues, and why one could consider Scrum Master superfluous, is the purpose of this article.

The Chosen One

In agile product development in particular, the focus is on above-average personnel. People who are unique in their field. Highly intelligent. Absolutely willing to learn. The “extra mile” literally stands on their foreheads. Experienced in what they do. Such racehorses are needed. Someone in the company finally decided that. And that only because they want to implement upcoming projects faster and to a higher standard. The status quo should simply be improved. And the variable “Personnel” should be the start. You want to improve something fundamental. So it seems.

To anticipate it in a generalistic tone: Companies all tick similarly in this respect. This thinking or aspiration is present both in corporations and in start-ups. Changes must always be made in people. Only then can one tackle the problem structurally. Somehow right. And somehow catastrophic.

Ultimately, however, it also means that trust in the already existing specialists is not given for what is to come. That can be the case for various reasons. Emotional as well as professional. Or you simply want to support this employee in his work (e.g. because of a growth of the company). Put a colleague by the side who should have at least the same know-how. Maybe even a little more, because you want to reposition yourself. With new ideas. More up-to-date methods and tools. Quasi use the chance. Fair!

Misinterpreted expertise

The problem with the “new”, however, is that the management must also be prepared for this. And also the colleagues. Put a possibly fixed opinion at the back. Be open to innovation, because: After all, only the attitude of the new colleague does not improve the situation; the mere placement of people in departments does not solve any problems and changes are not driven by it either. You should also listen to the experts. Thinking about “the new”. A recommendation without checking your gut. If the new proposal corresponds to the new personnel, but not to the management opinion (or if the implementation would hurt too much), then this is usually not well received. It is even taken personally.

But why? Well, mistakes are pointed out. So colleagues and management are wrong. Or the current procedure is at least “in need of improvement”. But the department or company management already knows that. This is probably also the reason for the expert’s new appointment. But who likes to be made aware of challenges by third parties? So you have to be instructed “by the new” right at the beginning, instead of perhaps being confirmed in your actions after all. That’s one way of interpreting it. Well, that’s great!

Methodical experts are also expensive. That’s what you hear. Although they have the experience (e.g. in integration, strategy or agility) that is often needed, they are associated with costly annual salaries. Costly means more than you actually want to pay. And then there is the above-average expectation towards the company, as well as the aforementioned teaching. On own request, but still hurtful. “And just because everyone is doing this at the moment doesn’t mean we have to integrate it. After all, the point is to become better and not to follow the trend! The management is right. Is it?

The expensive personnel seems inflexible and stubborn. They obviously don’t want to understand the internal processes – or simply don’t want to follow them. It lacks the will to adapt. The implementation of missing meetings, which should be essential for the product development methodology – and thus also for the quality of the product – is constantly preached. Reflection, research and appreciation are ongoing. In the past, people would go behind the keyboard and simply code what the management ordered. Completely without beanbags and card games. That worked, too.

So the thesis is: Experts are considered strenuous personnel with fixed ideas, which find their zenith in overengineering. At least from the management’s point of view. Example: “You don’t need burn-down charts. They are rarely correct anyway” is often recommended and tried out by new employees. Fed with unchecked or interpreted data of the company. Classic. You hear it again and again. The fact that the tool used for the first time is not responsible for the uncertainty of the output is rarely recognised or understood and the expert is quickly stamped by the management, although the data provided by the management was simply the problem and not the tool implemented by the expert. Too bad.

Business processes as opponents

Once you have realised that an expert may not be the right personnel for the company after all, the term “talent” is often used. Don’t get me wrong, companies often have no other chance. Either because the market leaves you no other choice or because the business account has applied red lipstick.

Young, dynamic, flexible and still hungry. Hungry to build something. To deliver a product immediately. Don’t snort for long. There is still directly tackling and trying out. You can feel the hunger for a career. Then the talented product owner takes over CSS changes or an adjustment of the page indexing himself. Awesome! Fresh from university – with the latest theoretical knowledge and hands-on mentality. Jackpot!

Basically all parameters that outshine an “experience” – according to the management definition. So at least often the reasoning to talk about the lack of willingness (or opportunity) of the investment beautifully. Investment in terms of salary, time and processes.

And then there is the factor “formability”. A kind of bonus. A talent can easily be tailored to the respective company – without criticism. After all, every company or start-up insists on being “different”. Something special. The target market ticks completely “abnormal” and you don’t learn that at university or in other companies. You are incomparable. A newfangled methodology doesn’t fit. For others certainly, but not for our special corporate culture.

So it’s nice when the required personnel can be branded with expertise – ehhh – I meant, with talent, immediately after hiring. Practical. And the management is not taught either. Talent will accept that you may have tried out your new-fangled idea months or years ago, but somehow it all failed. “That doesn’t work here.” Because of resistance in the workforce. Too long implementation of tools. Too inflexible processes. The expert would arrogantly reply that perhaps no experienced specialist personnel was on site to accompany the initialisation and make it successful. That the support of the management was missing if necessary. There it is again. This exhausting expert who thinks everyone in the company is stupid.

No matter which type of personnel was selected for the company, the work or vision remains the same. From here on, you only win and lose together. As a company – management – department – person.

I’m my own sparring partner

The person placed in the company is now implemented in a methodology. Or the person may even introduce the methodology into the company. Takes over the tasks of Product Owner – and Scrum Master. That’s the way it has to be! The company simply does not need the depth of detail of the methodology. Talent will rock as a product owner. It’s great that a newcomer gets so much responsibility directly from the management. Deceptive.

The fact is that you demotivate personnel (I avoid the word resource) with a double burden – both in the short and long term. Because no matter what kind of method a company chooses: Roles must be filled with real people. And I deliberately write in the plural. If you talk about roles, then you should seriously consider filling them with one person at a time – provided that the roles should actually interact with each other. Whether with talents or experts. And they will decide for themselves (or let decide) how to achieve the desired goals.

And then one arranges oneself with product development methods in the outside company culture. Otherwise the method won’t work properly. At least that’s what company and department managers increasingly believe. This may certainly be feasible in the overall methodology – but not with roles and responsibilities anchored in it.

As an example, the Product Owner and Scrum Master already mentioned. In recent years, I have increasingly noticed that these roles are being merged. For cost reasons. Misunderstood methodology. Adapted circumstances. It is precisely these two roles that are to be handled as a kind of “sparring partner” in the defined Scrum methodology framework. Simply put. From a corporate management point of view, it may be very tempting if a product owner intervenes unchecked in running sprints (i.e. development periods) and discusses changes to user stories (work orders) already in progress with the programmers. But the advantages of agile product development are gone. The whole methodology is undermined. Stakeholders, department heads, developers and management are eager for the role. Over and over again. Day after day. The person behind it, however, is grinded in a grinder. – Management – Department – People.

Waiter, I got a hair in my soup

To explain it in a simplified way: The product owner should take care of his stakeholders. About his user stories. And the prioritisations. He tips in his order and that of his “guests”. He hands it over to the waiter in the restaurant and waits for it to be prepared. Generally speaking. In a classic waterfall model, the title of the product manager would certainly be attached to it.

The Scrum Master, on the other hand, would probably be defined as a project manager in this comparison. The waiter. The guy who swings the tray and interacts with his guest. And the kitchen. He speaks both languages. The guest’s and the chef’s. He also makes it clear to the guest that you cannot prepare onion soup without onions and that (in all probability) onion soup will taste like onions. However, he will be happy to find out whether it would be possible to refine the taste a bit in order to adapt it to your needs. So for the next order. Maybe he’ll get the cook out of the kitchen and introduce him personally. In addition, the waiter will remind the kitchen again and again that the hungry guest he has to entertain is sitting in the restaurant. But at the end of the day he (or she) will have an open ear for his kitchen staff (the developers). Recapitulate how it went and work out together how to become even more efficient.

Yes, this is very simplified. But the comparison is sufficient to make my point clear: If the hungry guest himself runs into the kitchen to order his onion soup, it won’t end well. The proportion of spices is changed, the quantity, the tone and certainly the hygiene regulations are no longer as they should be. Irrespective of the fact that the booking may not be available in the cash register because the internal processes are not well enough known. Although one will (in the best case) leave the kitchen with a soup and hand it over to the person next to one’s table, it is questionable whether it tastes as good as it should. Not to mention the fact that the temporal component was left out of sight. Here in particular, one often hears: Why did it take much longer than planned? Quite simply: Because the plan, as well as the product, was changed. Shame!

Taking responsibility

In my experience, it takes a very experienced expert to get this dance across the stage. But this also requires the full trust of the management, as well as the developers. And a set time frame. Because this is not a permanent solution. It is time-consuming, very stressful and error-prone. People like to reduce the number of meetings. First and foremost: the retrospective. Mistakes are no longer learnt from. The good is not maintained or highlighted. The needs of the team are no longer understood. One forgets learning in the agile process. Critical.

If all participants take responsibility for their part, then it should quickly become clear that a product owner cannot be a Scrum Master. But who is responsible for the misery? The personnel directly affected? The developers? Maybe even the management?

It’s clear to me that all parties have to share a shoe. The developers cannot possibly be satisfied with the situation where they are constantly interrupted in their work and are generally not heard anymore (because this will happen sooner or later). The task of problem-screening must be done. But where to place if there is no retrospective and no hierarchies in a methodology like Scrum?

Then: The human being with double roles. He is obliged to cry out for help. Because of the painful time management. Concerning unsatisfactory user stories. And the resulting misjudgements of the team. Not to forget the screaming stakeholder. But who should you report to when the management had set the target and the situation was exactly what you wanted? Aren’t they more likely to call you incapable? After all, the quality of the work speaks volumes. Who wants to turn out to be a weakling? Especially as a newcomer.

Knowing what you’re getting into

Ultimately, however, management must also assume responsibility. It has the task of protecting its employees. Keeping the company on course. Implementing visions. To have the ear on the staff. And, as a result, we are already looking for optimisation opportunities in the strategic positioning. Here it may recognise that it has failed or that it sometimes does not know something. After all, that’s what you hire experts for. Or you manage to promote talents in order to allow a unique expertise to grow within the company. However, you then have to accept possible time-consuming failures or reduce expectations. But this perspective allows an almost unlimited loyalty of the employees to the company to flourish. This can be very rewarding in the long run.

If you break it down, then the management in particular simply has to learn to let go and allow opinions that counter their own. At least for an objective examination – perhaps also by a third party. One may question oneself and one’s own vision, instead of only one’s counterpart. And also, why one actually permits certain roles and which not.

It is worthwhile to create a simple Pro/Con list. Usually it is clear that you need even more input to get a well-founded answer to the topic “Do I need a Scrum Master AND a Product Owner? This will quickly show that the merging of two roles is the result of a gut feeling. For the wrong reasons. As with the fuzziness of the burn-down chart, you realise that the input data should be cleaned up before you make a decision. By the way, this applies to all decisions in life.

The team, the company and ultimately yourself grow from this.

Notes:

Do you know the term Scrumbut?

Martin Peters has published another article in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.