Agility? We tried it! Does not work! – Part 7

Since the sixth part of this series, another half year has passed. And the world has not become less uncertain since then, rather even crazier.

Today I would like to give you at least a small piece of certainty: you are reading the finale of this series of articles! There are no further sequels planned!

And for me, this concluding article also marks the end of an exciting and instructive professional phase and the beginning of something new: I’m going to try something new, I call it a workatical.

But back to the actual topic: The first article in my small series was primarily about the question of whether agility is the right approach for organisations at all, and if so, which specific approach might fit which situation. The second part was mainly about typical problems in the introduction and implementation of agility. In the third part, the focus was mainly on the people themselves. In the fourth article, I tried to address some dangerous misconceptions. Part five was about crises and how to deal with them, about leadership and orientation and about change. And in the sixth article I outlined some other phenomena and pitfalls that I have observed in change processes and transformations.

Finally, a fireworks display of other aspects awaits you. I will try to be brief. Really this time! And yet it has become a loooong article.

As before, I will not be able to provide universal solutions or recipes for successful agility. One or two attentive readers will perhaps realise that some of my arguments even contradict each other. Welcome to reality: ambiguity is – depending on the expert – a manifestation or a companion of complexity, in any case: unavoidable. And yet I am convinced that the reader will be able to do something with one or the other of my impulses.

And before we get started, let me point out for the last time that this article, too, may again contain traces of irony!

You just can’t let go, Part 7: You continue to maximise the utilisation of your “human resources” and celebrate multitasking!

I would like to take up a case that I already briefly touched on in Part 6 and look at it from a different perspective. Let’s assume that you have been convinced that Scrum really does sound quite sensible. Three “roles” (more correctly: accountabilities), a few fixed “meetings” (more correctly: events, maybe even rituals) and “tools” (more correctly: artefacts and commitments) and a few rules, plus five values. Almost too simple to be true. But it seems to work, that is, in other companies.

So now you are supposed to run your projects according to Scrum.

So there is still a dedicated team for each project. Sometimes smaller, sometimes larger. And in the course of the project, the team composition changes, of course – the topics also change. And you still want to put the best people on the most important topics! And if a project is at a standstill, the expensively paid experts can work on another project in the meantime.

And then you wonder why this system collapses so quickly?

Let’s take a look at what this can mean for a person involved:

If I am involved in 15 projects with as many different project teams at the same time (no exaggeration: I know someone like that), how well will I be able to identify with and focus on each of these projects and teams? So I jump from project to project and I have no choice but to focus on my tasks in the short time span. I won’t be able to think about the big picture, the interrelationships. Self-organisation in a team? Sorry, there is no time for that! Quite apart from the fact that the calendar would already be overcrowded by the multiple dailies alone if they weren’t mostly taking place in parallel anyway. I can’t remember everything anyway, and what for?

The same goes for sprint planning, reviews and retrospectives. There is hardly any time left to really work! So I try to work on as many things as possible in parallel, so I always have something to do when I’m stuck somewhere else. Of course I make mistakes, but mistakes happen, don’t they? Quality assurance will get back to me, but in the meantime I can get on with the other project. But no matter which project I jump into, the other projects have to do without me – of course I try to plan and communicate this as well as possible, but if something takes longer than expected, then this delay affects all the other projects that have to wait for me.

Some feel good about it (“nothing works here without me”), some become jaded and simply do things by the book, others wear themselves out in this situation and suffer from the constant pressure.

If the system does not collapse in such a situation, if it somehow continues to run, even then such a work organisation is neither effective nor efficient, it is even unhealthy and dangerous. And agility hardly has a chance under such conditions, not to mention Scrum.

This topic deserves its own detailed article, because as I wrote on LinkedIn a few months ago: If there is exactly one lever that creates the greatest benefit – and the basis for all further steps – in most of the organisations I have had or currently have an insight into, then it is: Reduce overload through multitasking! Through focus! And pull! To flow!

In the comments on LinkedIn you will find some links to videos and articles where you can delve a little deeper into the topic and also find pointers to solutions.

You know better from the start and grab only the sweetest cherries. Beware of the sugar shock!

When I talk to people who tell me that they have tried agile or specifically Scrum but it didn’t work for them or didn’t do anything, the first thing I usually ask is whether they had a:n Scrum Master and whether they did Sprint Retrospectives.

“I had read somewhere that you don’t really need Scrum Masters!”

“Retrospectives? We tried that once and quickly gave it up again, it didn’t do us any good except for bad moods!”

In the last case, they at least tried it and didn’t say right at the beginning that a retrospective after every sprint costs a lot of time and that it is surely sufficient to do it every few months or after the end of the project.

The “role” of product owner is also literally “unimaginable” in many traditional organisations:

“That sounds great! But the product owner making decisions without a steering committee, that can’t work for us like that, we don’t even need to try it out like that!”

I don’t want to claim that agility is not possible without a Scrum Master or without empowered Product Owners – regular retrospectives, on the other hand, are in my opinion essential for agility! Of course you can be successful without Scrum (or other agile frameworks) and of course the Scrum Guide is not a law of nature that you have to follow slavishly (see Part 1). And quite often it actually adds value to do daily standups, even in otherwise traditional waterfall projects!

It’s just that frameworks like Scrum are coherent and have been proven to work that way in many cases. That doesn’t mean it has to work the same way for you. But my experience shows that adaptations are not trivial.

So if your company has chosen Scrum as a helpful and suitable framework, for example, then I recommend starting with it “by the book” if possible, i.e. changing as little as possible to the standards at first. On this basis, you can gather your own experiences and reflect on them in the regular retrospectives: What fits, what doesn’t and why? The team and the rest of the organisation simply have to get used to some innovations (see Part 2). Based on your own concrete experiences, you can then – completely agile: inspect & adapt – make small changes, start limited experiments and thus – sorry for the repetition, but this is important – gradually adapt your system based on empirical findings rather than mere assumptions.

Another impulse: Every change to a component of the system has risks and side effects, has interactions on the other components. And in a complex system, in a Scrum team or in a large organisation, it is not possible to predict all the effects of a change! But that doesn’t have to stop you from preparing as best you can anyway. In my experience, it is very helpful to ask ourselves about possible risks, side effects and interactions before any change. Fundamental to this is the question of “what for”! For example, “What is the Sprint Review for? What is the purpose?” if the Sprint Review is to be changed or abolished. In this way, I create a basis to avoid some risks and side effects from the outset or at least to keep an eye on whether they actually occur so that I can then react in a targeted manner.

And every day the groundhog says hello? You do regular retrospectives and the problems keep coming back? Less is sometimes more!

I touched on it briefly in the section before: I hear again and again from teams for whom the regular retrospectives were of no use, so that they were then suspended in order to spend the time more sensibly.

And I had already mentioned this, but I would like to emphasise it again here: In my view, regular retrospectives are an essential part of agility. After all, how else is the continuous improvement of working methods based on empirical findings supposed to work? And I would like to refer once again to the findings of the wonderful Dr. Eberhard Huber: Des Agilen Pudels Kern (The agile core).

Of course, retrospectives are not trivial and not a no-brainer, especially not in a team. I will briefly outline a few of the most common stumbling blocks and possible starting points:

In some teams – not only – the same people always speak in the retrospective. The perspectives (and thus also the problems and solutions) of the others do not become visible at all and thus cannot be addressed. Moderation (for example, by a Scrum Master) and moderation techniques such as brainwriting help here – in other words: first write, then speak!

In some teams everyone talks, but everyone always just “beats around the bush”. Problems are known and discussed “in private” or “behind closed doors”, but not openly addressed in retrospect. These are signs that there is a lack of trust or fear of conflict.

Or the other extreme: everyone talks, everyone goes at each other and blames each other! Steam is let off – that may well be necessary sometimes – but that’s it!

How to recognise and address such dysfunctions in teams, is something I have compiled in a detailed German article together with the great Ralf Kruse and many other agile minds.

Let’s assume that the basics fit, i.e. we have a well-rehearsed team in which everyone deals with each other openly and trustingly, takes responsibility and pursues a common mission! Such teams also sometimes skip the third step in retrospectives: they identify a concrete obstacle/problem and directly find a solution to it and also actively tackle it. And then they are surprised that the problem keeps coming up in the same way or in a slightly different way or in a different place. This is what happens when you fight symptoms without having found the causes.

Another pattern I often observe: teams take on too much, they are far too optimistic at the end of the retrospective, want to do a thousand things differently and improve in the next sprint, and are all the more frustrated in the next retrospective when they realise that they have achieved little or nothing. Here, less is more, here, “focus” is important: rather, take only one measure for the next sprint and really implement it! Make this action visible at the top of the Sprint Backlog for the next Sprint, even if the current Scrum Guide no longer lists this as a rule. Of course, this only works if the product owner is involved in the retrospective.

A retrospective without a product owner is another pitfall that often leads to retrospectives not being very effective. This is because the Product Owner is part of the Scrum Team. Many measures to improve collaboration need or involve (or both) the product owner. Retrospectives without a product owner are therefore by definition less effective or – because the measures have to be coordinated with the product owner again afterwards – inefficient.

Your organisation is simply not ready yet? How do you know that?*

Imagine that your company has decided to give agile a chance and offered all managers the opportunity to spend at least one day learning about the topic with an experienced agile coach. Imagine that after the day everyone is really taken, convinced or even enthusiastic. And then one manager says: “That sounds really great and makes perfect sense for us! But our organisation is just not ready for it!”

The attentive reader will now certainly remember “You don’t (yet) trust your employees to be agile: Look who’s talking” in Part 3. And indeed, both phenomena seem very similar to me, even if it is not identical: because here we are not talking about specific people but about “the organisation” as a whole. And here I ask myself: Who, if not the people in the current leadership positions, are in a position to initiate change in the organisation or at least create the framework conditions for change? So if all leaders say that, then that is a very particular manifestation of the vicious circle shown in the passage linked above.

This reminds me of a situation when we asked ourselves in the transformation team of a bank whether a physical signature of several decision-making roles was really necessary for a certain release, or whether this could not be regulated in a different way, perhaps digitally and, above all, in a leaner and faster way. We asked the “process owner” responsible why this was regulated in this way. He didn’t know, but referred us to another contact person who he believed was responsible for it. She wasn’t, she didn’t need the signature either. But she had a new guess as to who might be the reason for this arrangement. And so we asked ourselves through the organisation until we arrived back at the starting point, the process owner. No one needed this regulation and no one knew why it existed, but everyone thought that there must be someone who cared about it. But there wasn’t. But before us, no one had spoken to everyone involved.

You guessed it: First of all, opportunities are needed to talk about such issues with each other instead of about each other, to talk about strategy, structures and norms beyond the operational stress, to “sharpen the axe” instead of bluntly chopping down trees with an increasingly blunt axe. And if you then realise together that actually nothing and no one speaks against a change and everyone wants to join in, then there is at least a chance that something will really get moving. In agile teams these are the regular retrospectives – why not also regular retrospectives in the management circle or in the departmental management circle or …? I have had the privilege of facilitating such retrospectives several times and I can say: it can work!

If you want to go a little deeper and further, you will certainly find inspiration around the Open Space Agility approach!

*) In the meantime, the title was “Your organisation is just not ready yet? Really? Or is that just an excuse for not having to do anything yourself?” but that was a bit too provocative for me. And at the same time too important not to be mentioned at least as a comment and food for thought.

You immediately rely on complicated scaling models? Great, that’s an easy way to conceal problems!

I am surprised myself that I had not yet dealt with this and the next aspect so explicitly in my series of articles. After all, I had already addressed the fundamental problem that there cannot be one universal solution for the organisation of complex systems – or only at the abstract level of basic principles – in the first part under “Agility is more than Scrum!” And the penultimate sentence of this section even gets specific: “However, if you simply copy solutions that work well in other companies (such as the so-called Spotify model), you shouldn’t be surprised if it squeaks and creaks and worse in your own organisation”.

A word about the so-called Spotify Model: I think the article and the videos (part 1 and part 2) by the fantastic Henrik Kniberg are great! But I never understood their content as a universally applicable scaling model, a blueprint for other companies, but as a source of inspiration, a description of how Spotify organised itself at the time and why. Henrik shared a fascinating snapshot with us, which of course could only show a section and a simplified – in some aspects perhaps idealised – view, not the entire real diversity. And the content was already outdated again before the finished videos were uploaded to Youtube – at least if I take one of the agile principles seriously: reacting to change! In other words, continuous learning and optimisation based on empirical findings:

• organisational structures,
• roles,
• processes,
• rules and
• practices

change continuously in agile organisations in order to adapt to changing conditions and to constantly improve. It is precisely this adaptability that is a key success factor.

Of course, I understand that it sounds tempting and like a kind of shortcut to simply take something that works well (in terms of external presentation) elsewhere, for example at Spotify or ING (video). This can be done, it can work – sometimes better, sometimes less well – but it can also really hurt!

But now to the scaling models, which actually claim – some more, others less – to be universally applicable. So it can’t be so wrong to adopt them as a blueprint, can it?

And here, too, there are several aspects to consider and even then there is no clear-cut answer. I would just like to address one specific case here:

Some organisations don’t really want to become agile at all. The change would be far too painful (more on this in part five, among others), perhaps even threatening their existence. It is enough for them to become a little more agile, either to be able to react well enough to changes in the sales market (see part 2) or to continue to be attractive enough for applicants (see part 3). In such cases, adopting a complicated scaling model such as SAFe can be quite attractive.

Malicious tongues claim that you don’t really have to change anything, just rename it, to convert a traditional organisation to SAFe. I don’t go that far, I don’t have enough insight and experience.

But I would venture a hypothesis: the more similar the degree of complexity of two organisational models (here: the previous primarily function-oriented matrix organisation and the future agile scaling model), the less painful the changeover. Simply because previous roles and positions can be easily transferred to new dedicated roles and positions, there is less pain of change among employees, especially middle management.

And this makes it easy to continue a tried and tested tactic: to respond to problems as they arise with new rules, organisational structures and responsible roles. In other words, to manage problems and thus conceal them. Thus, to alleviate symptoms instead of addressing the causes.

A simplified example to illustrate this: A company develops a software product and is very successful with it. So successful that the product becomes bigger and bigger and gets more and more functions. So successful that it is adapted for different industries. At some point, a Scrum team can no longer handle this alone. So the work is divided among several teams, all working on the same product, on the same code base. Of course, this leads to problems because there are dependencies between the teams: If one team changes something, it affects what other teams are working on or have worked on.

So what to do? First of all: be happy instead of angry! The iterative approach in sprints has led to the first problems becoming visible and noticeable very early on, not only after several months of development work.

And then there are basically two basic strategies:

• Reduce the dependencies, e.g. through a microservices architecture, or
• manage the dependencies to mitigate the symptoms, e.g. through rules, processes, dedicated roles and committees.

The first strategy means investing in the future. It is exhausting and you will probably never manage to eliminate all dependencies, but very lean structures are usually enough for the rest.

With the second strategy, you don’t have to change anything in the status quo. You only build additional structures. You can hand over the responsibility for the problems to someone who will now take care of it so that it doesn’t hurt so much in the future – and if it does, you at least have someone you can hold responsible.

You can do this as long as you can afford it (see Part 2).

You also rely on the same consultancies for agility that have only recently trimmed your structures and processes for cost efficiency?

Since this aspect is sometimes quite closely related to the topic of the previous section, I would just like to add a sentence that is mostly attributed to Albert Einstein:

“The definition of insanity is doing the same thing over and over again and expecting different results.”

New brooms sweep better! If Scrum isn’t enough, there’s always Design Thinking! And OKR! Or?

Yes! As already shown in the first part under “Agility is more than Scrum!” Scrum is not everything and especially not the one universal solution for everything. So of course it can make sense to complement Scrum with suitable approaches.

What I observe time and again, however, is that an organisation in which Scrum is already established now also wants to use Design Thinking in order to “be closer to the customer”, i.e. to strengthen customer centricity. (Or OKR to improve the alignment of the organisation across all levels. Or …) At first glance, this makes sense. But when I take a second look at the sprint reviews of the Scrum teams – staying with the example of Design Thinking – and I don’t find a single real customer or user there, but only internal stakeholders (if any), it often leaves me shaking my head.

Again, if you recognise a problem, you could first investigate the causes and then find suitable solutions yourself, instead of pulling a ready-made solution out of the hat and then wondering after a few months that it was only a flash in the pan again and nothing has changed in essence.

Maybe design thinking can expand the repertoire of the Scrum teams in a meaningful way, maybe dedicated Design Sprints can lead to the Scrum teams being less shy about inviting real users to the Sprint Review and talking to each other there. But maybe the causes lie somewhere else entirely and need other approaches.

Methodological competence is helpful, but methods are never an end in themselves. And too many methods/frameworks in parallel can also confuse and overwhelm. I can very well understand it when some teams no longer know exactly whether they should rather enter a medium-term topic as epic in the Product Backlog or better map it in the OKR framework, or both?

Again, sometimes less is more.

But if you offer new methods to a real team that is pursuing a common mission and has taken and accepted responsibility for its own success, then such a team will make use of the wide range of methods on offer and use those parts that help it to become even more successful. Such a team does not need to be convinced or educated. It will make use of what is on offer when it needs something.

You let your teams play in the safe sandbox and wonder why they only play?

At one of those then still hip New Work Meetups a few years ago, a manager told me that he just didn’t know what to do: Self-organisation was simply not working in his team. Yet he gives them all the freedom they need, they can all make mistakes and even errors, and he always puts himself in front of the team and absorbs all the pressure from customers and stakeholders …

I wish I wasn’t lying when I write that he realised it himself when he said it …

People adapt their behaviour to the framework conditions (see the section on the human image in Part 3).

So if you give a team the task to familiarise themselves with Scrum, they will probably deal with theory and practices, according to the textbook. Of course on a real, practical example, i.e. on a real product.

But if there is no real feedback, if the manager intercepts, filters and cushions any feedback from customers and users, how is the team supposed to learn? In fact, it bears no responsibility whatsoever; in this case, it is still the boss’s responsibility alone. The team never feels any direct consequence of its own actions, whether success or failure.

And even if the boss passes on the feedback to the team, it is always filtered and modified (“whisper down the lane”) and the boss will get off his chest again, as usual.

The bad thing is: the boss does this with good intentions. He doesn’t want to throw the team straight into the cold water, into the stormy ocean with dangerous sharks (here: customers), but first let them practise in peace in the non-swimmer’s pool. And the practices can be practised that way, but that is not an end in itself.

So if you want a team to leave the sandbox or the non-swimmer’s pool and take responsibility themselves, then they need a “real” problem, a real market reference, preferably direct and unfiltered feedback from real customers and users. This may hurt at first, but it enables real development and growth.

It has worked again and again – the teams still pull it out somehow … But at what price?

Finally, a really painful and sad aspect, for which I unfortunately don’t have a simple solution:

Imagine that your company has now “successfully” converted its product development to Scrum. That was a real tour de force, but it now works really well. At least from the management’s point of view: the figures are right.

But in the teams there is more squeaking and rumbling than before. Of course, the rest of the organisation still thinks and acts as before. And because of the sprints with regular retrospectives, the problems in the teams are noticed much earlier and more often. Especially at the beginning of the transformation, there were enough problems that the teams could solve themselves. But in the meantime, the focus is increasingly on those problems that lie outside the teams’ scope for action and that require their support. So the teams make themselves heard, they go out and make the problems visible and ask for help.

Back to the management’s perspective: What do they actually want? It’s working. And that was exactly the purpose of this change; that the teams solve their problems on their own, right?

And as long as the teams absorb, compensate and cushion the problems and disturbances from outside, i.e. take the pain on themselves, as long as the results fit and the figures are right, many a manager will be inclined to ignore “the complaining”. That’s probably part of it. But as long as everything is going well, it can’t be as bad as they say.

I am always amazed at how long things can go on, how people and teams can be capable of suffering.

In the best case, the teams eventually come to terms with the situation. This is still suboptimal because a lot of potential is wasted, but – I repeat myself – as long as you can afford it (see Part 2), it’s not a bad thing.

Some teams fall apart, turnover increases and the results get worse. In case of doubt, the managers are then to blame for not being able to motivate and retain the employees.

In the worst case, employees suffer health problems as a result of the situation.

As I said, I don’t have a simple solution for this, only the hint that in such situations the teams should ask themselves how they can redirect the pain to where it actually belongs, namely to where it is caused and could be stopped. Because basically this is the same pattern as in the previous section. Only in this case it is the teams that protect the rest of the organisation from the effects of the problems by always finding ways and means to achieve good results despite the adverse circumstances. Why should the rest of the organisation change anything if they are not directly affected, if they do not feel any pain themselves?

Outlook

This series of articles is hereby concluded. Thank you for your attention!

I hope you enjoyed it and were able to take one or two impulses for your reality from the phenomena and pitfalls in the change from the tried and tested to the new described here. I have no plans for a sequel. Whether there will be a spin-off, a sequel or even a prequel to this series at some point is written in the stars. In any case, I’m going to take my “workatical” for the time being and I’m curious to see where that will take me.

Stay agile, stay curious, stay healthy!

Notes:

Here you will find further parts of the series entitled Agility? We tried it! Does not work!

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