It's often said that Agile is a bottom-up movement, meaning that it usually is started by the people doing the work in an organisation. Though at one stage or another most enterprise Agile transformations hit some form of roadblock. It's rare that other people at this level are problems when it comes to the proliferation of Agile. Similarly, senior managers can generally grasp the benefits of Agile and can often see the justification behind its principles. In my experience where the most resistance to Agile is experienced in the enterprise is in middle management.
Middle management is usually appointed to a role where they are made personally accountable for supporting a capability, for instance a core system or online channel, and have had some measure of success by being the lynchpin in the delivery of this function. As such everything now goes through them and they feel valuable, important and - most importantly - safe in this position. Their role now is to co-ordinate and control the apportionment of incoming work to their teams.
One of the first things that an Agile transformation does is expose inefficiencies and as a byproduct, flattens organisational structures so that decisions are taken on the ground between the workers and the stakeholders. A natural consequence of this is that the previous co-ordination that was needed across those parties is now no longer required. This leads to the question of "then what is my role?", which I have now heard a number of times.
I faced this dilemma myself when still in Australia. I was running a small development team but doing a lot of co-ordination to keep everything moving. I felt valuable, not just from an IT perspective, I was involved in business decisions. I felt important, I was delivering business value and had a team of people who I had the discretion to assign freely to work I thought valuable. I felt safe, I had knowledge that nobody else had and that meant that both my team and the organisation was dependent on me. Although this approach helped me to make significant improvements in the beginning there were significant downsides to my approach:
- Scalability: As the number of initiatives that the company kicked off increased I struggled to keep a handle on all of them;
- Reslilience: If I was on leave, or ill, or just maxed-out, new initiatives stalled and existing capabilities failed;
- Blame: Over time, I became the problem as the bottleneck and single point of failure... and the organisation began to see this.
Thankfully I received some great mentoring at just the right time. This was before Agile became the juggernaut it is today and most of us hadn't really heard of Scrum, stand-ups or product owners. I was fortunate enough to have to learn from first principles how to run a lean and agile development team. Those experiences help me today to help others make the same changes.
However the most important thing I learnt though was that people need to be ready to change before they will, it's not something you can force, even through logical arguments. It was serendipitous that I was ready to change at the same time as I was lucky to receive guidance. Six months or a year earlier and I would not have been so willing and chances are we wouldn't have made the changes we did and I would be doing something very different to today.