The ambition of the IT-management is “We want all projects using the Agile way of working, no exceptions”. In a way I’m happy with this ambition, because I understand what lies behind it, but I think that a lot of project members don’t agree with this statement and don’t want to be forced. Forcing people doing things they don’t want or from which they don’t see the benefits, leads to resistance to any other way of working. So it is important that management give the necessary differentiations like: “We can use all of Agile some of the time and some of Agile all of the time” (with thanks to Dynamic Systems Development Method).

As said before: management and coaches have to keep in mind that implementing or using Agile is not a goal on itself. The reason that we implement Agile is that it helps us in achieving our goals, like getting successful and predictable projects and a shorter time to market. This means that not everything has to change. Only the areas where we can make improvements and will lead to more success are part of our change area. This will help people in accepting a new way of working: we keep what works well and we improve what didn’t work well.

What I noticed is that there are two ways of resistance against change. One is “It is not possible, we can’t do this in our project” and the other one is “we already doing this”. Both reactions have the same effect: nothing happens, nothing will change.
As a coach (and process engineer) I prefer the first reaction, because than I can use a lot of coaching techniques to give them insight in how it can work and explain the benefits to convince them. By focusing how things can work we adapt the Agile practices to fit in their project.
In case of the second reaction “we already doing this”, it is more difficult. Because than I  have to do some research to make sure that they indeed already doing it with positive results, so than we leave it that way (don’t fix a car which is not broken). But sometimes you discover that it is not really true what they say, well in their opinion it is true, but not in mine. In that case I have to explain that we mean something different. It is clear that a careful approach is necessary. Saying that the current way of working is not effective leads to more resistant (so you say that what I’m doing for years is not good?).

Let’s give an example of the reaction “we already doing this”.
We want to implement an Agile dashboard and a daily standup in a project team that is responsible for the maintenance of an application. Their work items are RfC (Requests for change). Currently they use a tool which shows the status per RfC. Every team member has access to the tool and they can see on which tasks they are assigned to. They update the status in the tool. The project manager controls the tool and in a weekly progress meeting the status is discussed with the whole team. The project manager doesn’t think an Agile dashboard and a daily standup are needed because they already have the tool and the weekly meeting. Because everything went well, the project manager thinks there is nothing to improve, so there is no need for change.
But what I see is that the team members can work more closely together than what they do now. They are not co-located and by updating the tool they don’t interact with each other and don’t know what the others do. It is not visible for them what the status is of the work items they don’t work on, because mostly they only update their own tasks in the tool. Also some issues stays undiscussed for a week. The team members also work on other things and only the project manager has sharp what has to be delivered when.
By bringing the team together on a daily bases (minimal twice a week) and doing a stand-up with the whole team in front of a dashboard, the team members get in sync with each other and know exactly where everybody is working on. The main benefit is that issues are raised and sometimes solved immediately by supporting each other. They also see the status of all work items that has to be done and focus on the delivery of the end-result within time. The effect will be that the team act more and more as a whole team taking responsibility for the end result and become more self-organizing. After a while the project manager doesn’t have to control all RfC’s anymore, the team can do this themselves in close collaboration with the product owner. The project manager can then focus on taking away impediments for the team. And so on… all improvements will help in being more effective. As a result the lead time of RfC’s becomes shorter, the team members are happy being part of a self-steering team, and project managers can change from command & control style to a facilitating style within normal working hours.

The lesson learned is that sometimes it seems that teams are already doing Agile, but when you have a closer look, you can see more improvements than you thought at first sight.

Link to Transition to Agile, how dows it work? (part 1)