There we have the SCRUMtrouble

SMART DEVELOPMENT NEWS 2021

The team has all the freedom

No one can say that the managers interfered too much. Quite the opposite - the team had all the freedom. But even during the few discussions in the context of the so-called reviews, in which members of the performance circle could participate, it became clear quite quickly: the goals set were not being achieved.
Unfortunately, this was confirmed at the end of the project. The Scrum method chosen by the team only led to the team becoming preoccupied with itself. Clear leadership was clearly lacking and the processes were not always adhered to. Clear proof, then, that agility is useless.
So the experience with the agile pilot was really not the best. The most important benchmark for success, the achievement of objectives, was clearly not met. All the team's attempts to explain why it happened sounded like they had done in the projects before. All in all: more excuses than comprehensible explanations. From a management point of view, one may well believe that the team worked with commitment.
But this perception does not diminish the fact that Scrum added a lot of meetings in which the team did not work productively. In retrospect, we have to conclude that agility did not help this team at all.

But now to the real experience

The experience quoted above is not purely fictional, but a bit abstracted. In fact, this view arose with a member of the senior management circle in the context of an agile pilot. The company had come under economic pressure - due to several factors occurring at the same time. Thus, there was a high necessity to complete this project successfully. As with many projects, there were not only favourable framework conditions, but also those that could be seen as a challenge. From the neutral observer's point of view, the fact that the experience with the agile pilot was not entirely positive was due to two factors.

Factor 1:

The dilemma with targets.

Goals are important. Every team needs goals for orientation. However, goals that are not set by the team itself are dangerous, but those that are set "from above". Why is that? Managers often believe they have to motivate teams with "ambitious goals". The idea behind this: Demand the impossible and you will get the best possible. This leadership philosophy may have served its purpose in the past. But in our modern world, where the focus is on the meaning and purpose of action, such an approach tends to lead to two problem areas.
First, we know about the power of goals that people identify with. If a team has accepted that the achievement of a certain goal is absolutely necessary, then it will do everything in its power to achieve it,
to achieve it. On the other hand, given goals, especially those that are considered too ambitious, i.e. unrealistic, always lead to defensive strategies among work teams. This includes elements such as "negotiating goals", "avoiding clear statements" and "not admitting any deviation - someone else will have to say first that they are not achieving the goal". A lot of energy is lost or wasted on unproductive discussions. A high level of motivation - figuratively speaking "burning for the cause" - is not achieved in this way.

On the other hand, a clear target prevents a constructive discussion about what is realistically achievable. Agile projects should and are used for complex projects. That means there are many open questions about what exactly needs to be done and how it will be achieved. It is all the more astonishing that managers - although they admit the complexity - nevertheless already know at the start of the project exactly what the result should look like. This is a contradiction in terms and usually due to the fact that there is not enough differentiation between what is desirable and what can be a realistic goal.

Since both dimensions are important and necessary, the solution can only lie in a continuous and constructive dialogue. Ideally in the way that management provides the team with all the information they need to understand what is desirable at the beginning of a project.

Based on this, the team should set ambitious goals for themselves. It can and will happen that the goals are not yet realistic in the initial phase. Especially when teams begin to set such goals for themselves, they will make mistakes. What is important then is how the company deals with such mistakes.

Should teams be too ambitious at the beginning and then receive harsh criticism for "correcting downwards", they will never be optimistic again and always explain to management exactly why this or that is not possible. And that is exactly what should be avoided for the reasons mentioned above. So it is important to build a positive culture of error - also when setting goals.

Managers may counter that it is important for the company to be able to plan and be reliable. There is nothing wrong with that, of course. But the question is at what level one wants to achieve this. At an average level - then target-negotiation strategies are a solution. But if you want more, then the management has to give the teams the space (and the time) to learn how to set themselves entrepreneurially valuable and naturally ambitious goals.

Factor 2:

The dilemma with the non-ideal framework conditions for an agile pilot.

As mentioned above, there were some almost ideal factors for the pilot, but also some that have to be considered as real challenges. Basically, this is true for all agile pilots, because in practice there are always more or less deviations from the ideal framework conditions.
Team size, team space, full-time Scrum Master, focus on one project or the regular participation of management in the review are representative of typical challenges that a Scrum team has to deal with.
Experience shows that teams usually find pragmatic solutions to these issues within the framework of their self-organisation, but these are often more of a "workaround" than an elimination of the basic problem. Here, the team needs the support of the management - but in a form that the managers usually still have to learn.

Agility needs leaders

Catalyst leadership is the key to addressing the above challenges in a new way and leading to new innovative solutions: together with the teams, but sustainably and for the benefit of the company. Leaders should be aware that launching an agile pilot puts exactly this demand on them. The attitude that the team has been given the freedom to organise itself in an agile way is not enough. Agility needs leaders - but leaders who are willing to learn and change.

The SCRUM mess with the agile pilot

So there is a realistic risk that the agile pilot will not succeed in a precision landing at the finish line. The change from a classic project organisation to an agile one does not only affect the agile team. The managers are also involved and must supplement or complete their previous management styles. This process should be started at the same time as the agile pilot and then usually leads automatically to the emergence of a different culture on the topic of goal setting and achievement.
Perhaps, even probably, this will not immediately achieve what is desirable. But together the eye is sharpened for what is realistic. And those who can assess more realistically what "their company" can achieve will perhaps also adapt their wishes accordingly.

You are not on your own in your journey.

CO Improve's consultants have accompanied numerous companies on such a journey, from initial pilots to transformations of entire business units or entire companies.
Our experience is to offer all participants the opportunity to learn that agile working is not a purely methodological toolkit. Because it usually also entails a change in leadership style and corporate culture.
Do you want your pilot to be successful? Then we have a decisive tip for you: learn together what agile leadership means and what targets can look like in the agile world. Because: predictability and reliability only come about when you develop a realistic picture of the goal together.