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

A few months have passed since Part 5 of this series. At that time, I started with the observation that some “new work” utopias have become reality: Home office, communication via video conferencing systems, use of digital whiteboards and other tools for online collaboration. And with that came the need for managers to let go a bit and trust that employees will do their jobs even when no one is checking. At that time, I wrote about leadership and orientation as a framework for autonomy and self-organisation, among other things.

At this point I would like to refer to the “Transparency Paradox”, one of many “laws” of cooperation that I have collected over the last few months: When employees know that their superiors (that word says so much!) are watching them, it slows down their productivity and innovation. Simply put, people change their behaviour when they know (or suspect) that they are being watched. And not in the direction that the controllers actually hope to achieve through their control!

But back to the series of articles: 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 addressed some dangerous misunderstandings. Part 5 was about crises and how to deal with them, about leadership and orientation and about change. For the sixth article, I have outlined a few more phenomena and pitfalls I have observed in change processes and transformations. Spoiler: It is complex, not easy to find a suitable transition and a good mix of the tried and tested and the new!

Furthermore, I will not be able to provide universal solutions or recipes for successful agility this time either. 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 once again that this article, too, may again contain traces of irony!

You just can’t let go, Part 4: How are the new agile roles supposed to unfold while the old roles are still standing around in the way?

It sounds too good to be true: Scrum gets by with only three roles! (Yes, of course – outside the Scrum teams there are still roles, but that is not the topic here). Only three roles? And the rest is self-organisation? And that is supposed to work?

Yes, it often works very well. If you let it work. If you create the parameters for it.

And of course things go wrong during the transition phase. Things get left undone because no one had it in mind and it was therefore not clear who would take care of it.

And to avoid such “teething troubles”, some organisations come up with the supposedly great idea of making the transition as smooth as possible. So they introduce the new agile roles, but leave the old roles in place, as a safety net, so to speak, so that nothing goes wrong.

So now you have self-organising Scrum teams with Product Owner, Scrum Master and developers as well as Project Manager, Delivery Manager, System Architect, Quality Manager, UX/UI Designer, …

From my point of view, such a situation is a very typical case of “well-intentioned is the little sister of sh…”. You want to help the new teams, not just throw them in at the deep end. But hand on heart: who learned to swim properly with water wings? Personally, I only learned to ride a bike properly when my parents finally took off the training wheels. Before that, I didn’t really have to try to keep my balance – after all, I had training wheels! And my parents wondered why I just couldn’t handle the bike “despite the training wheels” …

But back to old and new wheels*: Consider the possible risks and side effects! As always, it’s complex, which means: it doesn’t have to go wrong, but there is a risk! So if you should decide for the temporary coexistence of old and new roles, consciously watch out for possible undesirable effects!

• Role conflicts can arise: The more roles there are, the more complicated it is to delineate these roles from each other and to divide tasks and responsibilities in a meaningful way.
• Watch out for the inertia of old habits: The old roles are established and well-rehearsed, especially in the rest of the organisation and beyond (with clients and partners). In case of doubt – and especially: when things have to happen quickly – I turn to a role with which I have had good experiences, which I trust.
• This can lead to a situation where people work against each other instead of with each other: The old roles (or the people who fill these roles) feel threatened and are insecure about what will happen to them if there are only the new roles in the future. In this case, they will have little motivation to support the new roles and put themselves on the sidelines. They are more likely to consolidate their own roles, e.g. by keeping their valuable experiential knowledge to themselves in order to make themselves indispensable, or by – unconsciously or even deliberately – sabotaging the new roles.

Ask yourself: Do you think agility and self-organisation is the right path for your organisation? Do you think your staff can do it? Can you afford that not everything runs smoothly at first?

If yes, then perhaps you should be brave and listen to the so-called “vernacular”: Better an end with horror than horror without an end!

However, this does not mean that you should leave the new roles to themselves from 0 to 100! There is not only black and white, not only “push them into the deep end” and “float them in the wading pool”. Offer the new roles orientation and support, go into regular exchange, into joint reflection. In Part 5 I gave some advice on this.

And also in Part 5 I warned against overshooting the mark and not valuing the old roles and their merits! That would not be a good basis for the future of the new roles either …

*) Note: In fact, this has nothing to do with agility, these phenomena can occur with any change, with any new role.

You are confusing the new roles with a savings programme: Product Owners do not become superheroes of agility by nomination!

Let’s stay with new roles. In the previous paragraph I outlined an (over-) cautious behaviour: you let the old roles run parallel to the new roles (for now), so that nothing goes wrong. Now we look at another extreme, an (over-) optimistic approach: Not only do you eliminate the old roles, you also eliminate staff directly.

Yes, the current Scrum Guide (version 2020) says “The Product Owner is one person, not a committee”! But that doesn’t mean that this person automatically gets superpowers to do all the work that was previously the responsibility of the project management and a five-person project office.

Sounds absurd, but I have experienced product owners who were completely overloaded because they were pushed into exactly this situation and simply no longer knew where their heads were.

Again, this can work!

Assuming that work always expands as much as it gets space (loosely based on Parkinson’s laws), work should also become less if it gets less space, i.e. if there are fewer people doing it, i.e. if there is only 1 product owner instead of 1+5 project offices in the future.

Anecdote: During my studies I did an internship with an independent management consultant (a “friend” of Roland Berger, as he told me) who was often called in by the Bertelsmann board at the time to make companies profitable again. One day he let me in on his secret: “Every established organisation that hasn’t been streamlined for a few years has about 30% too many staff. My job is to identify the 30% that the company can do without.” He didn’t mention Parkinson’s Law to me, perhaps he didn’t even know it, but his experience from dozens of such projects backs up this “law”. His way (making companies profitable again by cutting staff) is not mine, I prefer to help them become more innovative and successful with the personalities they have, but he has been very successful with it and saved many companies.

So everything is good after all? Well! Such an approach can also go horribly wrong and, in the worst case, people can get hurt in the process!

I already mentioned overworked Product Owners: at least one of them left this new role and the company after a short time with burnout. Maybe this quick and violent reaction was even healthier for him in the long run than a creeping overload over many years and chronic stress syndrome. I am not a psychologist, not a medical doctor, but we all bear responsibility for the consequences of our actions, and employers have a duty of care to protect the lives and health of employees.

And even if we disregard health aspects: Overworked product owners, in case of doubt, don’t do such a good job either, tend to make worse decisions under constant pressure and are hardly able to maintain good relationships with stakeholders, partners, etc.

And then they say: He (or she) just can’t do it! So you blame the failure on the individual person who did not get this role or burden done. So you look for a more competent, stress-resistant replacement.

Or they say: agility doesn’t work (for us)! So you look for the blame for the failure in the chosen approach or model. So you try a different approach or go back to the old organisational form.

Both are possible causes. But there is a third one that is often suppressed: The implementation in one’s own context/system simply did not work that way.

Perhaps things would have gone much better if you had supported or at least allowed the time to analyse the previous tasks of project management and the project office: What does the Product Owner role take on, what does the Scrum Master role take on, what is shared in the rest of the Scrum Team? What can perhaps be taken over better outside the Scrum Team? And very important: What can be dropped in the future?

If they have the time and attention for it, a Scrum Team can also deliberately conduct small experiments to empirically find out which work is really necessary and value-adding. If you don’t have the time and attention, you have no choice but to try to do everything as well as possible.

You probably know this metaphor: two lumberjacks are completely out of breath from cutting down trees. A hiker comes along and asks: “Don’t you notice that your axes are blunt? Why don’t you sharpen them?” The lumberjacks reply, “We don’t have time for that, we have trees to cut!”

A small example that I was allowed to accompany myself:

A Scrum Team in a company was annoyed by having to report the project status in three different reporting channels and IT systems. This was the topic of a Sprint Retrospective. In one of these systems, it was also not clear what was happening with the data they were entering there every week. So for the next three weeks they wrote Lorem Ipsum filler texts in the text entry fields. And lo and behold, there was no reaction at all. Obviously, no one looked at this information that each project had to enter there weekly. Based on this empirical finding, it was easy to eliminate this reporting channel in general. Had the Scrum Team not had the time and attention to axe sharpening, they (like many other teams in the company) would have grudgingly and annoyedly served this reporting channel week after week.

Bottom line: if you want to use change as an opportunity to reduce unnecessary work, make it happen! Identifying and eliminating non-value adding work is also work first! And this work needs time and attention. Think of it as an investment that will bring you a good return (freed up capacity for more value-added work) in the future. Perhaps you could also take another look at the section on transformation?

You just can’t let go, Part 5: Wash me, but don’t get me wet!

Letting go is a multifaceted topic. The first four parts were generally about the inertia of old habits, about key figures, about tools and (a little further up) about roles.

There are, of course, many more ways to make life difficult for “the new”:

Look at your established processes: They naturally demand project proposals with complicated profitability calculations from projects that want to go agile. Equal obligations for all! In general, this is a good principle! It only makes no sense at all if the project has chosen an agile approach precisely because it is an uncertain/complex project. Because it is not yet clear what the result will be in detail and what it will bring. Because it is not yet clear how long it will take to work on it and what it will take. In such cases, a project proposal with a business case is a waste of time and energy! And annoying!

And hand on heart: if you want a project to be approved, you calculate it so that it will be approved, whether agile or not. After all, how often does it happen that the initial calculations are looked at again? And even if they are: Then important parameters have changed since then, so that some assumptions are no longer correct! So why bother at all?

So what to do instead? Perhaps an open kickoff is a possibility? All those interested in the project can ask questions, point out dangers, raise objections, suggest alternatives, etc. And maybe the decision on projects can be much more decentralised than before? And much more often and in smaller steps? The danger that the wheel is then invented several times unnoticed or that enthusiast projects sprout from the ground can be countered with maximum transparency (including open Sprint Reviews).

Or look at your established committees: You may have empowered Product Owners who are allowed to make decisions and regular Sprint Reviews that are open to all stakeholders. But you would rather not give up the nice tradition of the steering committee? It can’t hurt to have another body that only has to make decisions in exceptional cases.

That can work. Maybe everything runs smoothly and every few weeks you sit together in the steering committee and celebrate the successful, because agile and self-organised project. And yourself.

But please also pay attention to risks and side effects here: Do the stakeholders regularly come to the Sprint Review or do they rely on getting a summary from the Product Owner in the steering committee (focus on a status report with numbers, data, facts instead of the usable product as a result)? Does the entire Scrum Team receive regular feedback on the Sprint result? Are problems/obstacles discussed early, openly and solution-oriented? Or does the project representative come as a supplicant or even as a defendant who has to explain herself because, for example, a budget pot has become empty earlier than planned? How much additional time does the Scrum Team invest in preparing a presentation (status report, slide presentation, …) of the project in a committee?

What would be the alternative? Maybe important stakeholders really can’t attend every Sprint Review – but then maybe this is a good opportunity to share responsibility, to delegate? Maybe other formats are needed – in a large German car company I got to know the so-called pulse meeting: every week representatives of all projects of a division meet with decision-making representatives from the line (e.g. purchasing, human resources, …). Each project has one to two minutes to show all those present what support it needs from the line. Afterwards, projects and line briefly talk to each other, make decisions or agree on the next steps. The major difference is the attitude with which all participants go into this meeting: The line comes to help the projects. The projects come because they get help so quickly and directly when they cannot solve issues themselves. (More on this in the book #PM2025.)

Traditional project status reports were mentioned in the section before. But take a look around, I’m sure you’ll find other traditions that don’t make it easy for anything new to develop itself and its own impact.

I am not advocating radically stopping everything that has been established and doing everything anew from one day to the next, that is dangerous. Imagine for a moment that you take an “agile” approach: You regularly take time to reflect and allow yourself to critically question everything at any time. And then you prioritise and take on one aspect at a time. And you do this step by step: You do small, time-limited experiments (e.g. cancel the next two steering committee meetings and invite everyone to the Sprint Review instead, after which you decide together how to proceed) and you pay close attention to any risks and side effects.

You just can’t let go, Part 6: You demand cross-functional teams to work together without silo thinking and self-organisation, but keep the functional organisational structure …

I get it. The Scrum Guide describes – in simple terms – how a cross-functional team develops products. The Scrum Guide does not describe – at least not concretely – what this means for the rest of the organisation and vice versa. So you start at the product or project team level.

And that often works amazingly well: stable teams that pursue a common vision/mission are perhaps even the(!) big lever, as the wonderful Dr. Eberhard Huber already pointed out in 2011 at the first PM Camp in Dornbirn in the session “Des Agilen Pudels Kern“: After evaluating over 300 IT projects, he came to the conclusion that the statistically most significant factor for project success is the development phase of the team. Well-rehearsed teams are significantly more successful in implementing their projects than teams that are not (yet) so attuned to each other.

So if cross-functional teams function successfully without having to change anything in the rest of the organisation, then everything is fine, right?

If that’s the case: sure! However, there are risks and side effects here too, I would even say: predetermined breaking points!

Scenario 1: You call it a “team” and it is also composed of several departments in an interdisciplinary way and you also use one or the other agile ritual. But the team members are still working in several other teams or projects at the same time. And the work only happens to a limited extent in the team itself – how could it with so many projects at the same time. The team coordinates the work, which is then taken by the team members to their line organisation and done there. I always find it fascinating that a team identity can develop at all in such a setting! However, it should not surprise anyone that in such a case, in case of doubt, all team members are much closer to their own line organisation and its interests than to the – supposed – team.

Scenario 2: From now on we assume that it is a “real team”, i.e. a group of people who (ideally) work in this team with almost 100% of their time. Now problems arise in the project (or in the course of product development), e.g. scheduling problems, budget problems, technical problems, quality problems or similar. In such a case, the functional organisation can react in an agile way, for example by having the line managers offer their support to the team, e.g. by accelerating purchasing procedures, quickly filling a position, etc. (I outlined the “pulse meeting” as a suitable approach to this above).

In reality, however, I observe too often that such a problem leads to local escalations in several involved functional areas of the company in parallel. Each line first tries to get out of the situation as unscathed as possible and influences the behaviour of its own representatives in the team. In such a situation, it is virtually only possible for divided personalities to remain loyal both to their own department and to the team.

Scenario 3: Conflicts arise in the team. A very mature team will resolve most conflicts internally, which is one of the purposes of regular retrospectives and the role of Scrum Master or similar. Sometimes, however, team members report the conflict to their superiors. Supervisors with an agile attitude take the conflict seriously and support their employees in solving the conflict themselves. Sometimes, however, supervisors play their traditional role and resolve the conflict themselves by giving instructions. This promotes self-organisation, identity as and motivation in the team immensely! Not.

I was able to observe something similar live the other day: A conflict arose in the team and after an exhausting process, a solution was found together. Now the conflict had leaked out. The supervisors wanted to help, coordinated among themselves and found a solution, which they then presented to the team without knowing the team’s solution. In fact, both solutions were more or less identical. But the motivation and commitment in the team literally collapsed.

Scenario 4: And even if everything runs smoothly in the team, there is a danger that the unrest comes from outside. It only takes minor conflicts in the goals of the team members’ departments to influence the behaviour of the team members. Or one of the line managers wants to see his or her own team more often in future and invites his or her own people to meetings that don’t always fit perfectly with the team’s working rhythm.

No, you don’t have to throw the entire organisational structure of your company overboard from one day to the next. But it certainly doesn’t hurt to talk to managers about agility and what it’s for and how they can behave to support agile teams in their self-organisation, or at least not to disrupt it. You can strengthen the position of Scrum Masters or Agile Coaches and allow them to protect their teams from the influence of the line. And you can regularly reflect with everyone involved on what are good examples and where things might not have gone so well yet, in order to learn together.

Outlook

I hope you can 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 often thought and implicitly announced that this series could soon come to an end. But as soon as I write something, I think of other aspects that I would also like to describe. So my backlog is getting bigger rather than smaller at the moment. And it probably won’t really help anyone to know now when the last part of this series will be published. So in future I won’t waste any more energy on estimates and forecasts, but will just keep writing until I can’t think of anything else (or no one wants to read it). In this sense: stay excited, stay curious, stay healthy!

Notes:

This is a Best of Blog 2021 post.

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

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