7 steps to make sure your agile transformation fails 

Estimated reading time: 5 minutes

Transforming your entire organization to become agile is one of the most ambitious change projects one can undertake. Even for experienced change professionals the road is fraught with pitfalls. Think you have it figured out? Think again, and consider these 7 mistakes, that will undoubtedly make your change effort fail. 

In an effort to adapt to the high pace of digital transformation and global economic change, many organizations are looking for ways to overcome bureaucracy and organizational inertia. As traditional hierarchic business models weigh businesses down, many look to agile models to become faster and more flexible1.  

But transforming an entire organization is a huge undertaking for any (change) manager. The basics are obvious: You set up a change project and a change team. You pick an agile framework and adapt it to your organizational needs. You hire Agile-Coaches and Scrum-Masters. Good to go? Not so much. There’s still plenty of opportunities that will ruin your effort. 

From our experience, here are 7 surefire ways to ruin any agile transformation.  


We get it. Once the agile spirit has caught you, it is hard imagining working any other way. However, any tendency to talk dismissively about old ways of working among enthusiastic agile proponents is counteractive. Using words like “old-fashioned”, “outdated”, “rigid” or “controlling” dismisses an entire world that has worked well for years. You want people to listen to you? Maybe don’t tell them their whole life until now was a failure and you have all the answers figured out. 


While you’re thinking about self-managing teams and short decision cycles, everyone else is thinking about one thing: Am I going to lose power, attention, money, or cumulating all of the above: my job?!  

By emphasizing the improvement of KPIs like net promoter score, employee referral rate and cost/in-come ratio as reasons for the transformation, you are feeding into the fear that the agile endeavor is just a cost-cutting program and jobs are at stake. There needs to be room to address questions about personal consequences2: Who will be my disciplinary leader? Who will decide on my performance and salary? Once you get these basics clarified, people can concentrate on what’s really important: getting things done.  


Middle management has a particularly hard time during an agile transformation, since their role in the new organizational set-up often remains unclear3. Of course, once they hear that they will no longer be line or project managers, they panic! “Decentralized decision-making” certainly sounds threatening to employees who have invested all their efforts in a system with a rigid career ladder and strict hierarchy & decision-making levels. The previous company culture has promised them that they will succeed if they conform and perform. And suddenly they are supposed tell everyone openly about their daily tasks, “potentials” and “failures”? Of course this feels overwhelming!  

The resistance that can build up is not to be underestimated, and you have to invest considerable resources into redefining roles to be in line with agile management styles and involving middle management in cultural training early on.  


“Be agile rather than do agile.” This frequently used mantra refers to the experience that going agile is more about a mindset and a cultural reset than a particular process an organization can implement. But what does this mean for leadership? It means the leaders need to be able to share responsibility. To give up power. To trust to have hired the right people, who know what they’re doing3. It also means a manager can’t reprioritize action items in the middle of a sprint, just because he or she feels pressured from the board. If you’re not up for that, going agile might not be the right path for you and your organization. 



It turns out, people really don’t want to be mandated to work in a self-reliant and self-responsible environment. You can’t wait for change to happen bottom-up, but since going agile is inherently about employee’s ownership and motivation, you need to find middle ground by creating room for participation. Research has shown multiple times4,5 that involving employees reduces change resistance6. People want to participate in deciding how their work will be done in the future, and rightly so. There is no place for an ivory tower of organizational developers spending months at the drawing board, before ever talking to the people affected.  


If you take your transformation seriously, you have probably set up an official project for the organizational change. You have nominated a change team, which has developed a roadmap and change plan. Not diverting from this plan is the worst thing you can do. Just as you’re setting your organization up to be agile, the transformation itself should also be organized in an agile way7. This means to constantly learn, iterate, and implement insights from previous experiences during the transformation process. You should even organize the transformation program in sprints.   


Just don’t do it. Apart from disrespecting agile principles, this can really break people’s spirit as it undermines the whole “working self-responsibly”-thing. The Product Owners probably committed to some sort of quarterly goal, but other than that, it is on them to prioritize work and decide what needs to be done8. As the role usually doesn’t have disciplinary responsibility, it only takes a line manager’s decision or a spontaneous idea from the last Steering Committee meeting for them to be overruled. If you are tempted to disregard the agile framework and mindset so fundamentally, you might consider stopping the whole change process altogether. 

So yes – if your organization wants to go agile, a lot can go right, but a lot more can go wrong. This list is in no way exhaustive. We can’t wait get into the weeds with you or help you with your agile transformation.

Christian Schneider

Partner, Capability Lead Agile Organization

1 Overby E., Bharadwaj A. & Sambamurthy V. (2006). Enterprise Agility and the Enabling Role of Information Technology. European Journal of Information Sys-tems. 
2 Fry, C., & Greene, S. (2007). Large scale agile transformation in an on-de-mand world. Agile 2007 (AGILE 2007), 136–142. 
3 Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108. 
4 Coch, L., & French, J. R. P. (1948). Overcoming resistance to change. Human Relations, 1(4), 512–532. 
5 Armenakis, A. A., Harris, S. G., & Mossholder, K. W. (1993). Creating read-iness for organizational change. Human Relations, 46, 681-703. 
6 Wanberg, C.R., & Banas, J.T. (2000). Predictors and outcomes of openness to changes in a reorganizing workplace. The Journal of Applied Psychology, 85(1), 132-42. 
7 Hui, A. (2013). Lean change: Enabling agile transformation through lean startup, kotter and kanban: an experience report. 2013 Agile Conference, 169–174. 
8 Ashmore, S., & Runyan, K. (2014). Introduction to agile methods. Addison-Wesley Professional.