Skip to content

What is the hardest part of managing an Agile transformation?

What is the hardest part of managing an Agile transformation?

Welcome to part 4 of our agile coach interview questions series, where John McFadyen answers common questions asked of agile coaches in interviews and client engagements.

I would say it’s getting rid of the consultant that sold you on the idea of an Agile transformation.

An agile transformation is a myth, and it’s led to heaps of failures in our industry because there is a significant difference between adopting Agile within a product development environment and trying to transform an entire organization into something that fits into a box labelled Agile.

What makes adopting Agile so difficult?

Business Agility and the behaviours, processes, practices, and systems that support that are often counter to how traditional organizations work.

In traditional project management environments, people ‘estimate’ an outcome upfront and attempt to assign costs, resources, tasks and deadlines to something before they start.

That works fine in a complicated environment such as civil engineering, where we have built thousands of bridges and have a very clear idea of how to do that, how much it costs, and roughly how long it should take to do that.

In complex environments, engineers are telling you that they don’t know the answer upfront, nor do they know how to build the product because it has never been built before. They don’t know all of the variables that will impact the success of the venture, and they won’t know until they have built the product or solved the problem.

The team could tell you exactly how long it will take, what needs doing, and how much it will cost immediately after they have finished because only then will they know for sure.

This isn’t the kind of thing that fuels confidence in executive and leadership teams.

Even if they know that a project scope and time estimate, in a complex environment, is inaccurate (at best) or an illusion (at worst), it is something they are comfortable with and allows them to get a feel for what the road ahead looks like.

Those executive and leadership teams want certainty upfront, and yet an Agile product development team and agile coach turn up and tell them that we don’t know what we don’t know and there is no way for us to know until we build the product or solve the problem.

That is the hardest part of adopting Agile within an organization and getting leadership and executive teams to support and champion this style of product development and problem-solving.

The illusion of certainty

Time and again, waterfall-style project management has failed within complex environments.

People attempt to define a scope upfront, assign tasks and work to specific people or companies, and estimate a cost and time frame within which the project will be delivered.

In so many instances, these time, cost, and quality estimates prove to be inaccurate, and projects are delayed for months, if not years. In addition, the project costs spiral out into the millions and billions over budget.

Project management teams are so far in that they can’t turn back, and so much money and effort has been invested that companies need to keep investing in the project rather than abandon the project and lose billions.

This is well documented, and there is a great deal of evidence to support this, yet executives and leadership teams continue to buy into the idea of placing massive bets using a style of building and problem-solving that fails them a great deal more than it serves them.

They assess the degree of confidence with which the project overview is being presented and make a decision based on how confident the team appear to be in their estimation and projections.

So, in the early days of being an Agile coach, the hardest part is helping executives and leadership teams understand that ‘we don’t know’ was the only ethical answer. Helping them to understand that Agile is about making small bets based on solid hypotheses and proving or disproving each of those hypotheses before committing to bigger bets and more ambitious ventures.

It’s helping them understand the value of rapid prototyping and submitting that concept or idea to customers and product stakeholders to verify that we are building something of value before committing vast amounts of money, time, and effort to building it.

Projection and estimation in complex environments.

Once we get going and build momentum as a team, it becomes easier to project and estimate based on evidence and data.

Sprint burn-up charts and sprint burndown charts allow us to document how much work is being delivered over specific periods of time. Whilst it can be hard to know how long something can take, we can compare like with like and make a reasonable estimate based on past performance.

So, it does get easier as the team become more agile and effective.

You can demonstrate what the team have achieved in the past and how the team is likely to deliver in the short and medium term, but you can’t offer certainty.

The flip side of this is that you do earn confidence with each sprint because the executive and leadership team see a tangible, working product or service at the end of each cycle.

They witness continuous delivery, continuous improvement, and increased customer satisfaction through this style of working while witnessing greater creativity, collaboration, and employee satisfaction.

As you document this progress and present the data, your leadership and executive teams will be able to see the value and improving trends in the areas that truly matter to the organization, so it will get easier with each adoption within the organization.

So, in closing, it’s the presence of uncertainty and the inability to accurately forecast the future for executive and leadership teams that present themselves as the most challenging part of agile adoptions in traditional organizations.

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster