Why Scrum fails in your company

Anyone who thinks highly of their self wants to prove something with the help of agile software development. For example, how quickly you can react to strategic changes, impulsive ideas and the modular structure of entire project mountains. Developers are finally free in their work. Project managers, as leaders of the Scrum teams, are not forced to interact with project participants. Managers dream of development on schedule. Finally, an infinite expansion of quality and feature sets is possible. Bravo.

The investors and the holding company are informed that from now on time will be saved. And time is money. Marketing is already dancing the tango because the brand can unfold better. In the kicker room, companies spray their start-up flair with the scent of rose water. And new start-ups grow into unicorns on pizza bases.

Why real mythical creatures have nothing to do with just one method, why Scrum is not even related to these wishes and why agile software development is only as good as the canoe that remains attached to the jetty of the waterfall is the subject of this article. Because: Agile development is expensive. It does not aim at faster programming. Oh yes,… and it has no place for delegates or superiors. In short: I am enthusiastic about agile software development. Honestly.

A new hope

Of course I have decided to cause a stir with a series of provocative word sequences. Even with a plot twist. A struggle for attention, if you will. And yet smaller and larger truths are hidden in my previous sentences. In my experience, the Scrum method is misunderstood. Deeply. And accordingly unpredictable ideas grow up in many companies. Then there are those who see no benefit in the change of development methodology. After all, corporations have grown even without agile software development. And if you are honest: there is some truth to it.

But it is also a fact that there has been a radical change in software development. For reasons. So not everyone involved in the project was quite satisfied. You know the history of Sutherland and Schwaber. And anyone who has ever felt the need for project budget planning knows that the result seldom has anything in common with the figures on paper. Where the reason lies depends on the perspective taken. And everyone is wrong. Or right. Agile software development should then fix it. And it is so obvious that a method for implementing software products can only support this. No more. No less.

Do it or leave it alone – there’s no trying

Pragmatically speaking, a project can be compared to a supermarket purchase. I check my finances and decide what I really need from the discounter. I also plan two hours of my day with traffic and waiting time at the checkout. Now the decisive question for you: How often have you been successful in shopping?

The masses will certainly agree that people are inclined to say that this process is usually very successful. Congratulations. It was a great project.

But if I now work on the specifications or the events within the “Purchasing” project, everything changes. You have less budget. Or just half an hour for purchasing. Maybe not all goods are in stock. Maybe the supermarket has moved the shelves completely. Or you are planning the purchase for the very first time because you have just moved out with your parents. And let’s just imagine a car driving into your trunk at a traffic light. So your car stops on the shopping street for the time being. Not only is the time planning over, the ice in the trunk is melting, the eggs are broken and the shopping was partially useless. Everything is changing, isn’t it? But the shopping has somehow been finished. A success?

The development of software looks pretty much the same. Countless companies were tired of “burning money”. And since knowledge is the first step towards improvement, we act now. Somehow. But that doesn’t make it any better.

In order to make everything a little more efficient, companies are at some point launching something like Scrum. You’ve heard it before. Everyone does that in the Valley. So you feel your way in. For 2 weeks. During this time, the members of the agile team have sat in many meetings, used up countless sticky notes or implemented elaborate Jira boards. Isolated from the impulses of the head of department. Exactly these impulses, which in the old world could have been done quickly. And that now stands in the way of the company’s success. Nothing was achieved. The management is annoyed about the newfangled method and the team no longer understands the world. The fairy dusty agile software development from the Valley apparently had no effect. Or at least the wrong one. So could experience and discipline be the key to success?

When the customer has to give way to the path

To put it very clearly: Agile product development stands and falls with the support of the entire company and above all with the correct focus. Particularly in everyday hierarchical thinking, it is often difficult to keep an eye on the actual goal. Often it is more a matter of finishing a project. And that’s quite fast and absolutely with low costs. However, you don’t want to lose the freedom to intervene again in the current development cycle, because you notice that a pink button brings much more conversion than a grey one. Of course, good quality is required, but without creating the framework conditions. How often has the testing time for your last project been reduced to keep a timeline?

If you talk to a project or product manager, he will certainly tell you that he is required to lead projects to success. How wrong this statement is (and I can’t even blame the people behind it) is shown by the simplicity of the following answer: The customer is not the focus, but the departmental goal. The way, not the result. Or to answer it physically: The path-time ratio (= speed) is the focus of the development. Both variables are given hierarchically: “Build a product (what) by day X (when) in this way (waterfall)”.

It goes without saying that this procedure completely fails to meet the requirements of utility and quality. And, of course, it is true that one should not get lost in the details of product development in order not to stand in the way of a company’s growth. Nevertheless, it would be good for the mass of projects out there if one took the time for extraordinary planning. Take the time again to completely understand a user, as well as his communication culture. In recent years, I have increasingly come across the latter in particular. If you make compromises in usability for customers due to a lack of time or even the skill set, then often only transparency and good explanatory texts help the user. Headlines, tool tips, or simply the unmistakable naming of a call to action. That’s totally ok. But you have to do it, too. And if you want a smooth introduction to an agile methodology, then everyone is free to do so. So why not place the testing on an office wall using Kanban sticky notes and let off steam there with acceptance criteria? In this respect, I have had very good experiences with the development team of my employer.

The famous sticky notes in use

More space for the customer

So where does this trained approach come from? And why is there a lack of acceptance in project and product management to know something exactly and therefore not be able to make any statements? Just admit again that you are unable to do something – or know something. In the past you were successful with it. After all, the project was finished. With bugs. But finished. Everyone was absolutely annoyed by the implementation. But the goal was achieved.

Due to the digital change, which is picking up speed more and more, the competitive pressure is also increasing. Especially the generation of “I’m smart and want a start-up” makes it very difficult for corporations to maintain speed. Ultimately, one has the feeling that start-ups announce fresh features daily in press releases. With inexperienced personnel. Small budget. Lower salaries and experience. A contrast that usually cannot be explained with the mindsets of experienced managers.

And everything in the list is the reason for the success. Working with less means concentrating on more. It’s a creative relay race that presents many small milestones and not just the finish run, of which you don’t even know if any spectators are still cheering at the presumed final time.

Start-ups have no choice but to bring quick results to the market with little resources. These are then more of a feature than a finished product. Knowledge is acquired during the sprint. Experienced knowledge carriers integrated as analysts for the development period. All of this could be taken into account in the planning because a team coordinated itself. Courage to fill the gap proved. And actually listened to the experts. How often is the competence of one’s own personnel denied? Only to ask an overpaid consultant to confirm one’ s own employees’ theses. Active. Or passive. Somehow typical for a corporate group. Ultimately, methods like Scrum are about building the feature for the customer. No matter what the cost. As already said: Agility has its price. A Kobe steak, by the way, also has that. And the meat is of the highest quality.

Success through relevance, calmness and trust

But let’s be honest: Scrum, Kanban and all the smart and agile Wunderkinder are no saviours. How could they? Methodology alone is not the key to success. Waterfalls also have their justification. After all, there are projects which, for example with Scrum, would be over engineered. In my opinion it is a fallacy that a company is only allowed to choose one method. Often it is the combination that brings the right spice into play. Or would you write a user story to correct a spelling mistake? Including a prioritisation and estimation of the team. Just to make sure the mistake is cleared up within a two-week sprint. Certainly not. That would be crazy. Moreover, it has no cost-benefit ratio.

Believe me when I say that agile software development does not replace good project research. Too often this is thrown overboard: “Scrum doesn’t need it at all.” I’ve heard it all before. And read. By the way, not only for corporations. I recommend Ralph Stacey’s Complexity Diagram, which sums it up exactly and helps you to orientate yourself in this methodological universe.

The Stacey Diagram as Help in the Methodology Universe

But it is even more important to stay calm. To have patience with your colleagues and the management. Especially if you want to place new methods in the company. This should also be well researched. Because it takes time, strength and empathy. There are no hierarchies in the Scrum team. Only roles. Nobody is the boss. If he does, it may be in the company – but not in his role in the agile team. The team is self-sufficient and does not slow itself down with painful personnel management. And if there are frictions, then you solve them among colleagues, or with the actual boss outside the Scrum team. But there has to be a lot of trouble. Pure escalation prevail. It is then worthwhile to fill the role again in order not to interrupt the flow.

Convince the management and other departments of agility by talking about added value for the customer. Not for the company. Be aware of the differences between efficiency and effectiveness. Agile software development is expensive and transfers responsibility from management to the agile team. If it is not possible for the management to keep their fingers on details for technical or emotional reasons, then Scrum, for example, will not bring the desired success. Promised. The team is even demotivated. Who likes to sit next to a prompter when writing user stories?

Long live the vision

Micro management cannot work with agility. If you interrupt running sprints or add more water to the already full bucket, your feet quickly get wet. This means that a procedure was planned based on requirements. If you change the requirements (complexity, quantity…), then the plan is gone. Actually simple. One also calls causality.

The promised flexibility through agile software development suddenly turns out to be a set of rules made of titanium. Nothing works anymore. Impulses are not possible. And the costs seem to explode. The added value is gone. That is then quickly the thinking of the management. It is painfully realised that impulsive decisions have no place in Scrum. This is then dismissed as a lack of flexibility. This is not the case. The problem is not the method. The missing or not understood vision is it.

One is only impulsive if one reacts emotionally to something surprising. There is no planning. You don’t weigh pros and cons. But shouldn’t exactly that already be part of a good vision? The vision of the management at least. Would you like to give the customer features that nothing can be built on without thinking about it? Shouldn’t one rather pour a well thought-out foundation of features in order to create a holistic product? One that the user really needs?

Agile means learning together from each other

In entrepreneurship, this impulsive vein is often found due to newly gained knowledge or well-intentioned external advice. These can come from consultants, investors or clients. That doesn’t matter. By the way, in corporations as well as start-ups. In these cases, management must be made aware, often only in visual language, that its vision is in jeopardy. A rat’s tail is drawn when an ongoing development is interrupted. And it is precisely this impulsive requirement that has no place in his master plan in the long term. From this grow the conversations that open eyes. A follow-up discussion is basically based on the fact that the impulsive requirement is nothing but a thesis that has not yet been based on facts. There is no research. Especially not a business case. And if it nevertheless exists, the information is not (completely) available yet.

So how is complexity to be determined by an agile team? In the end, the ball is in the management’s court again. Data must be submitted for review. Every good manager sees that. After all, his team of specialists was not inaugurated. And so you usually gain time until the next planning of the next sprint. Tempting, isn’t it?

Especially the implementation of agile development methods is subject to enormous friction. Throughout the entire company. That’s a good thing. A company gets to know itself anew and communication is the key to clean development. The Scrum Teams have to learn this as well. Especially the Product Owner and Scrum Master – if available. Nevertheless, the developers in the team must also engage in transparent and heated discussions. Be honest with each other and with yourself. Speak clearly when there are obstacles. And finally, take responsibility yourself. Software developers have been trained to do this for years. A return to the company hurts. That is part of it.

What else is important to me

Agile teams must grow together. Not necessarily the number of members. Rather in interaction. And in the mindset. One’s own abilities may be questioned. This is absolutely essential in order to make realistic estimates. There is no place for egos. Moreover, synergy effects can be found in this way.

As soon as everything has worked out, wonderful things happen. Knowledge grows. Development times are reduced. Product quality increases. Project results are no longer evaluated on the basis of a timeline, but rather on the basis of positive customer feedback. A wonderful feeling. Because nothing is more motivating than building products of which you yourself are convinced. Not only the customer. Or the management.

And ultimately only because you think of the customer. Not deviating from the vision. The relevant methods and tools are used. Emphatically dealing with colleagues, working as a company on the right goals and not just finishing something for the department.

Goal achieved.

Notes:

Martin Peters has published another article in the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.