3 Sure Ways to Kill Agile Transformation

3 Sure ways to kill Agile Transformation

I have been helping my clients to adopt Scrum, but we always face a lot of resistance from different parties. They often say Agile does not work in our company or industry, and there usually is subtle resistance from middle management, even if top management pushes for it and the working teams love it.

My experiences with this kind of resistance prompted a little thought experiment: if we want to focus all our energy on destroying the Agile Transformation initiatives, how would we accomplish that?

1. Fixed Scope, Fixed Time Project

Even if the team is doing Scrum, insist that they must fulfil all the scope as documented and signed-off beforehand and insist they must do it within the time frame allocated. There should not be any flexibility in terms of scope, time, budget; the team just has to be “Agile” and deal with it by working overtime or sacrificing quality.

Also linked to this is the Project Approach. Agile Transformation can be hampered by thinking that the most important measurement of success is Project Scope, Time, and Budget rather than Product Success like Revenue, Customer Satisfaction, Time-to-Market, Quality, Innovation or Employee Satisfaction.

To make it even worse, let’s enforce a strict phase gate control. For example, we must have all requirements documents signoff after the first 3 months, and there can be no changes allowed afterwards. We must not deploy to the Production Server or any server before the deployment phase, which is the last 3 months of the project. Again, the project deadline and scope do not change even though the CEO insists on a complete change in direction in the middle of the project, and the team has to re-do everything.

2. Measure by Velocity

Now the team is doing Scrum, we must measure teams by Velocity. The long-term Velocity must be stable and increase as the team gets more mature. If the team velocity is not as good as expected, the team must bring the velocity up to the target and even higher to catch up.

To make sure the developers are taking that seriously, we need to put personal goals and targets of the percentage of velocity into their personal appraisal, and we need to punish them if they do not live up the expectations. This is definitely going to bring disaster to the project and is a sure way to kill your team morale.

Velocity is just a result, not a target, and it’s just an option that may not be the best way of estimation. It is also is a very commonly abused and misused measurement, and in general, we do not want to measure Agile Product Teams by output. We want to measure outcomes instead, like whether they are able to deliver a working product frequently or whether the customers are happy with the product. If velocity is abused, it will inevitably lead to the sacrifice of Quality or people as we are moving into the danger zone of fixing time (Sprints) and fixing Scope again (number of story points delivered). Consider protecting your team by using other ways of value estimation, like Scrum with Kanban.

3. Big Bang Approach to Transformation

“All the team must go agile in one year.” “ 60% of the Project must go Agile in 2 years.” I have heard statements like those a lot from CEOs and CTOs, but that is a sure way to make Agile Transformation projects a failure. Doing Agile without a clear understanding of the benefit is dangerous.

With this kind of mindset, IT feels they are under the pressure to go Agile when they’re not sure what the benefit is. Despite this, they still have to go through all the existing processes and procedures and have to deal with the extra pressure of “being Agile” with “extra requirements.”

Senior management and leaders of the transformation need to think about the benefits of Agile more carefully. With the end-goal in mind, they can proceed more easily. As I always suggest to my clients, Evidence-Based Management from Scrum.org (scrum.org/EBM), is a good way to think about Agile or Product Success Measurement. Do you want to get more value from the product in terms of Revenue and Profit, or are you doing it for marketing, branding, faster time-to-market, ability to innovate or a desire to seek some unrealized for values? These questions can help.

Conclusion

All these are the very destructive ways to make sure Agile Transformation in the workspace is a failure. Be mindful of these and avoid them to greatly improve your chances of success when transitioning to Agile.