Agility welcomes change – that sounds very good as a catchphrase, but leads to a lot of confusion in real and (often enough) ugly life outside of seminars and books and so on, because we often find that too much change is not good either. But what is the right measure, or where do we want change and where not?
Of course, it is very difficult to give a generalized answer to these questions. As with many other things in our work, it is also true that this is not a precise science. However, we can certainly agree on a few principles that should help you to better assess and classify the things around you.
Perhaps we should even begin with what the term »welcoming change« actually means to us. We could take that as accepting changes and working with them or driving changes.
You see – there is a big difference.
On the other hand, the statement has several aspects. Firstly, changes to the organization, changes to processes or changes to the scope. We can think of more if we try.
But let us limit ourselves to these three for the sake of simplicity. We have to start somewhere (and above all: end somewhere).
Changes in the organization can be summarized by everything that relates to the team structure, what concerns management levels, or in other words: everything that we could somehow see in an organization chart.
This stuff always hurts, always involves a lot of effort, and therefore always hinders us – even if there are positive effects in the medium or long term.
Sometimes we have no choice but to change the team (e.g. when two colleagues just cannot stand each other). Maybe we need additional skills. At scaled levels, I have already seen entire management levels being cut because the company expected a leaner organization with shorter paths. Depending on the role we play, we can be the initiator of such changes or part of it or sometimes even some sort of victim.
We should aim for this kind of change if we feel it is necessary. Our goal is and will remain the optimization of our processes – within a team or at other levels. If, on closer inspection, it turns out that changes to the organization will help us in the medium and long term, then we will initiate them. We will do anything necessary to drive them forward.
Here we get to a very important point and a fundamental misunderstanding of the agile world: Agility does not mean that there is no long-term planning. Of course there is. Even in the most modern start-up-like company ever. We cannot renegotiate budgets on a weekly basis. We cannot hire and fire new colleagues every two weeks. In this context, agility simply means that agreements and plans can be changed because we learn from our experiences.
Therefore changes in the organization need a long-term view. We should be aware that they are always disruptive (in other words: expensive), and we still strive for them if we consider them appropriate, but no means carry them out lightly. These things really need to be considered carefully, after all, it is very difficult to undo them.
We encounter processes at all levels. We find them within individual teams, where they may not always be written down, but have simply established themselves. We find them at all levels when we ask ourselves how requirements from management actually end up in the backlogs of the teams. And that is only one of countless facets.
At team level, we have our retrospectives that explicitly aim to change those small processes defining our collaboration. That is good and right and nobody questions it. Here we examine our working methods, which we do not always call »processes« (but they are), find gaps and weak points and strive for continuous further development.
What we find and do here is rarely disruptive. These are small steps that only affect a small number of people (our own team and maybe a neighboring team if we talk about working together). The consequences are manageable and it is easy to do.
Everything looks different when we talk about our »big« processes, how requirements are added to the portfolio, enriched and elaborated there and then run through the entire cascade down to the team’s backlogs.
Changes here are extremely expensive because they involve many people and roles who have to learn and adapt to new things. Maybe we have to create suitable tools first. These processes can be highly complex, so changes can be compared to playing a mikado. When I move something, I have to be careful that something does not suddenly fall over in another place. Many companies have process managers for this. And if they do their job right, they can tell us which changes will have which consequences.
Analogous to the changes in the organization, it also means that we still rethink and revise our major processes if we think it makes sense. We are only aware of the difficulty in doing so. The more people and roles involved, the more complex it will be, the more resistance we will face, and the better we should think through our change, which does not mean, however, that we should shrink from it.
We do not change the big processes every week, but we change them when it makes sense. For this we need a review process – a way to question the existing things. If it is like slaughtering a holy cow every time, even questioning the meaningfulness of individual things, we will not develop any further.
So, who is responsible for these big processes? Who do you turn to when you find a vulnerability or have a suggestion (a real suggestion rather than just criticism)? What is the path from the first conversation to the actual change in a process?
These are things that we should know and if they are not clarified we should urgently seek clarification. If we do not do that, we are hindering ourselves.
Finally, a look at changes in the scope or in the project itself.
Does anyone think that we plan iteratively in Scrum? That we only think from sprint to sprint?
Of course we do not. We have defined project scope. There are also written agreements with customers. Behind the sprints and sprint goals, there are still milestones and larger feature sets.
In the sprints we plan the details, but at what intervals – or better: in what form – do we plan on a larger level? Changes to our plans at the sprint level do not hurt. If we move a backlog item from one sprint to the other and rephrase it because details change, it is no big deal. With changes at the larger levels, however, things look very different.
We have filled our backlogs with many items that, if we are honest, already reach quite a long way into the future, because we know (or think we know) what is to come. We have already talked about more scopes than those that are only shown in our next two sprints.
We know that several teams coordinate. In addition, they may have looked to the coming three months (a friendly hello to SAFe).
Do we welcome change in this context as well?
Let us stay with SAFe. If the scope of the next PI changes, i.e. the scope of the iteration superordinate to the sprint, then not only one team may reschedule a sprint, then x teams may reschedule four or five sprints.
This is not fun, and nobody wants that. We do not do things like that lightly. We only make changes of this magnitude if we have no other choice.
But we do not shy away from it either, if necessary. Sticking to a plan just because it becomes expensive to change would end up being even more expensive.
Core: The question of change is always the question of the scope and type of change. Our approach is based on the risk (impact) of the change. We strive for change where we expect a healthy relationship between benefit and risk. However, change itself is never what drives us. Stability is very important, even if we do not talk about it, because change always has disruptive properties.
If you need any assistance or want to know more, just speak to me.
