Part two: the tribulations
In this two-part series, we're going behind the curtain, taking a closer look at what it takes to make agile transformation strategies happen. Our expert guide is Tina Behers, VP Enterprise Agility.
In part one, Tina talked us through some triumphant transformations from her own experience. There were some great examples of how bringing leaders together and starting with a clearly defined strategy can make a world of difference as your agile transformation progresses.
In this blog, we're looking at the tribulations of trying to make agile happen at the enterprise level. These are some of the common missteps that can derail a transformation before it's even pulled out of the station.
Tina draws from her own experiences to demonstrate that it doesn't matter what size your organisation is or how much money you have to throw at a problem; there are some fundamental no-nos you need to avoid to set your company up for success. So let's jump in!
Common missteps to avoid with your agile transformation strategy
Not having metrics to keep you on course
Firstly, agile transformations tend to go off course when there are no metrics with which to measure if they're on track or not. 'A wet thumb in the air doesn't give anyone any indication of success or failure until it's too late to react,' says Tina.
Valid metrics–not vanity metrics (i.e. ones that make you look good but do not help you understand your performance in a way that informs your future strategies)–are key if you want to learn if the changes you're implementing in your strategy are having the desired impact.
As one example, the consulting group that had been leading the transformation effort decided a new metric for success was completing team standup meetings in five minutes. As you can imagine, the teams became very frustrated with this metric because they were not able to discuss any blockers during the standup. Instead, they were forced to give rapid-fire status updates and had to book follow-up meetings to get answers, or swarm, on a blocking issue.
Depending on an inexperienced consultant
While working with an external consultant can be a huge benefit to your transformation, the word ‘experienced’ is key here. You need to engage with someone who has done more than just read books or websites on agile frameworks, principles and methodologies. Engage someone who has tangible and repeated experience “ in the trenches”.
Some consultancies hire people straight out of college, put them through a boot camp, and then send them out into the world without any tangible experience, and only a handbook of how they have to do things. They’re not going to know much more than you can learn from a website and won’t be in a position to raise their hands, make meaningful suggestions, and prevent your transformation from derailing.
‘There are a lot of agile consultants out there trotting around with their agile certifications who have not done more than attend training workshops and take a test,’ says Tina. ‘So having someone like that come in the door is not going to drive effective and meaningful change for your organisation.’
One common example of confusion caused by inexperience is use of the word ‘portfolio’. ‘When SAFe uses the word “portfolio” in “lean portfolio management”, it’s referring to a strategic portfolio that aligns your business unit across all domains, platforms, systems, and people,’ explains Tina. ‘It is not what is referred to as a portfolio in traditional project management principles. But if you bring in a consultant who reads the word “portfolio” and assumes it’s referring to this project management model, you’ll end up with a major disconnect in how you identify value streams to efficiently and effectively deliver value quickly to market.’
"If you think it’s expensive to hire a professional to do the job, wait until you hire an amateur."
Believing tools are a silver bullet
'Tools are the backend,’ says Tina. 'They're not even the part that's wagging the tail – they're the very tip of the tail, the least important part.'
Everyone is looking for a simple fix – a tool that can solve an organisation's problems. And some consultancies will offer this. 'Some will go in there saying, "We're the tool expert. We can give you the silver bullet,"' explains Tina. 'They implement the tool and are surprised when the problems persist. Customers then think the tool is the problem, or the consultancy hasn't implemented it properly, which does happen, but it's almost never just the tool. It's often because the tool was implemented without thought for the processes it should be supporting.’
We're often brought in to fix tooling implementations, and we always start by going back to basics because it's often not the tool that's at the root of the problem. 'We will do a full assessment of people and processes, too,’ says Tina. 'We ask fundamental questions to understand the root of the problem. Have you identified your value streams? What do your team structures look like? What are the levels of dependencies you're trying to manage? How do the initiatives you're working on align with your strategy?
Choosing the wrong tool
Not all agile tools will be right for all organisations. Take Jira Align. It’s very structured around agile at scale best practices but if your entire organisation isn’t already practising agile at scale or doesn’t have a framework, Jira Align is not going to be the right tool for you. The same applies for Digital.AI, Target Process, Rally, MS Project or Clarity for that matter.
Unfortunately, not all consultancies and vendors may be this honest. ‘There are big companies we work with that are using tools they bought because they saw the marketing content and weren’t told this might not be the right tool for them,’ says Tina. ‘And the evaluation required to find out if the tool was suitable was never done. Before we consider implementing a tool for a client, we assess their situation and understand what problems they’re trying to solve to make sure that they get the right solution for their business.
Sticking to legacy tools
Sometimes it's a case of refusing to let go of legacy tools, which can be a costly mistake in a different way. One company we worked with spent $2.9 million in one quarter creating reports and data lakes to get the visibility it needed from various tools, many of which they couldn't upgrade because they had customised them. They also had agile tools that could have provided a majority of the reports needed, but they refused to integrate over concerns about data accuracy and visibility.
'It was costly and time-consuming to get any of the information and insights they needed,' says Tina. 'I explained to them the benefits and improved ROI of switching tools, but the person responsible for the customised tool was unwilling to move to a new version. It was the only thing they'd ever worked with in their 20-year career at that company. And that person's managers were worried about upsetting them by forcing the change.'
Rather than use data and native reports from the purchased tools, their concerns over data accuracy meant creating data lakes and custom reports that manipulated data to tell the story they wanted told rather than the truth.
That company just posted their first loss to stakeholders in 100 years.
Not getting buy-in from mid-level managers
The only time we’ve seen a successful agile pilot fall apart as we tried to roll the implementation out to another group was when a mid-level manager refused to change. This can have a huge impact on the whole experience, which is why it’s so important to get buy-in from all levels of management at the start.
In this example, the pilot and the second group had been a success. When we moved to the third group, the mid-level HR manager told those working under him, “If I find out you’re implementing agile, you’re going to get fired.” It took about six months to get that manager’s boss to realise that he was the problem.
This type of resistance often stems from fear of the unknown and of losing power. It’s up to you to communicate to your people that while their roles may change, they will still be an essential part of the organisation.
It starts with strategy…
Get more insights on what your agile transformation strategy needs to include and how to implement one, download our eBook The five pillars of agile transformation strategy: the starting block for achieving enterprise agility.
Leadership not setting the strategy
'A restaurant is only as good as its head chef,' says Tina. 'If the head chef decides he's going to take a six-month sabbatical, then it often ends up being whoever is the loudest who dictates the menu. Without the head chef making the plan clear, there can be confusion, conflict, and dissatisfaction, and subsequently, quality suffers.
The same can be true for an agile transformation. Your leadership needs to be stable, accountable, responsible and communicative to ensure the strategy is clearly defined and everyone knows which direction your organisation is heading in.'
Of course, this isn't always the case. Often, leadership will lean too heavily on consultants to determine and direct strategy – or leadership changes part way through a transformation, causing chaos. In the case of one organisation we know of, consultants who were brought in to help deliver the agile transformation strategy decided to go with a different approach, using an unsuitable model and preventing other parts of the organisation from using SAFe.
'Upwards of £9 million was spent on restructuring, realigning, and reorganising this particular organisation, before that consultancy was fired,' explains Tina, 'not to mention fines that resulted from not meeting regulatory requirements. Another third party was brought in, but by then, there was massive change fatigue and a general dissatisfaction with transformation.'
"All failure is leadership failure."
Set it and forget it
'A transformation strategy, just like any other, is not a set-it-and-forget-it approach,’ says Tina. And treating it as such can result in missing regulatory, legal, and market changes that will ultimately have an impact. These implications can be extremely costly if ignored.
'I was working with a government agency in another country that had a transformation strategy in place. As they were working on implementing it, the government made some changes to its main constitutional documents. Rather than see how this impacted its strategy, this agency continued working on something that was now completely illegal and unconstitutional. £11.5 million of tax-paying spending later, they finished and celebrated only to realise their work was for nothing.'
You need to review your strategy at least semi-annually in conjunction with regulatory, legal, and market changes. This review must include your current inflight development efforts. Are they still aligned after any changes to the strategy? If you don't do this step, then your transformation will fail. 'You can blame it on the framework, blame it on the tool when in reality it's the mirror's fault,' says Tina. 'You as a leader are at fault for your strategy failing if you're not evaluating it periodically, and adjusting it when necessary.'
Make it a triumph
Avoid the trials and tribulations of agile transformation by bringing in the experts like Tina from the start. We have the experience to support you as you set your strategy and put it into action. Fill in the form below, and we'll be in touch.