Dare to stop doing something old

Agile transformation #

How we made all the mistakes so you don’t have to #

Part 3 #

In order to change and move forward we sometimes have to let go of old beliefs or habits. But instead we usually try to squeeze even more into our already full backpack. How can we manage all the existing frameworks, methods, and ways of working while trying to learn something new?

What do you already have as baggage? Did you pack it yourself? Do you even know what’s in it? What roles, frameworks, processes, principles, policies, guidelines, and structures already exist in your organisation? And who has to carry this heavy and crammed backpack?

Imagine running a company that has been around for more than 170 years? I was part of an agile transformation in such a company. Over the years, we/they had tried every framework there is. Many of them are still active somewhere in the organisation. But to be nimble, to be agile, you can’t carry too many things. When you bring in new ideas, what do you unpack and leave behind? We spent so much time trying to get all the frameworks and roles to work together. There were advocates and strong believers for all the existing frameworks, defending their roles and methods. And now we were trying to introduce a new framework that was competing with, or in opposition to, all the existing ones. So there were meetings and meetings, trying to reconcile them all, trying to create a world in which they could all co-exist. This led to a plethora of roles, rules, and processes that confused the people who were trying to work with them all. Instead, we should have just unpacked and repacked what was really needed. If only we could agree on what that was …

It has to be done though. We can’t go on adding and never taking anything away. Which are important? Which are still relevant? Which are duplicates and which complement each other?

Then we have the common problem where the organisation thinks we have abandoned something old and embraced the new cool thing! But in reality only the names of the things have changed. We don’t have team meetings, we have daily scrums. We don’t have a ToDo list, we have a backlog. We put everything in Jira, surely we are Agile© now! There’s two sides to this. One is to try to do everything at once, and the other is to just do the new things by name and carry on as before. In some places both have been done in the same team.

Why does this happen and what can be done about it? My experience is that it comes down to two things. The first is that people in the organisation have their roles dependent on a particular framework. If that were to disappear, what would happen to them? I’m the team manager, my job is to prioritise the work for the team. Now you’re telling me there’s going to be a Product Owner who does that? What will happen to me?

I’m an ITIL Process Owner and now we’re going Agile© and teams are going to do however they want? No way! (That’s not really the case, but it’s a fear I’ve heard more than once).

The other big barrier is contracts. In some organisations we have had contracts that say we will follow a specific framework with specific roles with named individuals. We could not say that a team would work together on incidents if a contract said that the Incident Manager was Kim Smith. If we were to change that or throw out an old framework, it would be contractually complicated. I won’t go into how I feel about those contracts, but in many cases it’s still a reality that you have to navigate.

Last but not least, there has been too little buy-in to the new framework or the new way of working. People just don’t think it’s going to improve anything. In fact, it just seems to make things more complicated. No matter how many ADKAR surveys you do, people will not believe it until they see the results. Start with a small part of the organisation. Show the improvements and go from there. Sounds simple and has worked well in many situations. Then there are situations where you really need everyone on board to make it work well. Do you remember Klaus Leopold’s slide from a long time ago? Yay, we’re so agile! In this small part of the value stream we can ship really fast, but overall it’s still a long, tedious process. If “the business” is still prioritising and funding projects “the old way”, it’s going to be hard to be very agile in just one team or department.

I don’t (yet) have a good answer that applies to every situation. But I have four points that I like to ask:

• Are you trying to pack too much?
• Who is going to carry your backpack?
• Can you still be agile with all that weight?
• Which old roles/processes/policies can be removed?

^{Photo by Presley Roozenburg on Unsplash}