12 key challenges on an Agile transformation journey
As organisations progress along their journey to Agile maturity, they typically encounter a number of challenges. Experts at Coeus Consulting share some of the most common challenges they repeatedly see at their clients, and highlight what Agile leaders can do to address them in order to be successful.
1. 3rd party involvement influences ways of working
Many companies are locked into fixed-price or fixed-outcome contracts, or work with partners who can’t or won’t adapt to an Agile delivery model. Working with suppliers who can’t or won’t join you on your Agile journey will jeopardise its successes.
How can you address this?
There’s no easy way out of this other than to re-negotiate contracts or to seek out alternative suppliers or contracts. In software development most suppliers will recognise the benefits of Agile and be very willing to co-operate or even help drive Agile adoption. If your suppliers are the right fit they’ll be happy to work collaboratively first and tidy up contracts later.
2. Investment decisions require up-front certainty
Many businesses have well-established funding models to ensure that they do not waste investment on endeavours that do not deliver guaranteed ROI, usually with little risk. In the world of Agile software delivery this kind of certainty is just not achievable, meaning that the focus has to change to one of experimenting rapidly and at low cost.
How can you address this?
Funding models have to adapt to recognise the new world: stakeholders must be encouraged to let go of this veneer of upfront certainty and instead see investment as an iterative test-and-learn cycle whereby proof-of-concept, prototype, minimum viable product and regular iterations are the norm.
3. Stakeholders uncomfortable with loss of predictability and control
Agile projects will vex stakeholders across both business and IT for their dynamism, whether it’s the avoidance of firm commitments to defined costs / timescales or seemingly unclear outcomes or developments. Yet nothing will kill agility faster than making people give guarantees. Many stakeholders will react to this by trying to reassert controls and governance that no longer apply.
How can you address this?
Stakeholder education sessions can be held in advance to teach stakeholders what to expect and why they need to be okay with it. All stakeholders must get used to the idea that Agile trades control and predictability for big productivity gains. You can’t keep all the predictability and still expect to get the productivity gains.
4. Right Product Owner can’t be found
Underestimating the value that a good Product Owner can bring to Agile is a classic mis-step that invariably causes big problems as the process tries to mature. Product Owner is not usually a distinct pre-existing role within an organisation, so many people will compromise the position by either re-badging an existing person from a different role or making it a part-time role.
How can you address this?
If you’re genuinely committed to Agile then you need to make Product Owner a full-time role, for which you train or hire specifically. Make this a permanent job with empowerment. A good Product Owner will bridge the gap between business stakeholders and IT delivery teams and will play a crucial role facing off to both.
5. Governance processes remain slow
Agile will most likely lead you into conflict with a number of the existing checks and balances that form part of your IT delivery.
In some cases, governance processes can fall by the wayside in Agile. In other cases, the checks and balances are still required (for example, security and regulation) in which case they need to be re-worked so they can happen in time.
How can you address this?
Governance processes must be removed, relaxed or accelerated so that they keep pace with IT delivery. If you can’t remove the checks and balances, then you must either accelerate them (so that they fit with your Agile sprint cycles / development timescales) or find a way to re-factor afterwards in the event that the information can’t be ready before development.
6. Team members not fully assigned to their teams
When team members are pulled off to work on other endeavours this creates major disruption to the team dynamic and starts to damage any chance of predictable and reliable delivery.
Agile benefits greatly from established, self-contained teams who can plan and execute as a unit, safe in the knowledge that they have the skills available within a particular time-period to meet the commitments they make.
How can you address this?
You must develop your resourcing model to ensure teams are fully assigned for each sprint, and ideally that there is good continuity of team members from one sprint to the next and from one project to the next. Agile relies upon stable sprint teams and a regular velocity.
7. Projects take too long to get going
Many people starting their organisational Agile journey will be hamstrung by indecision, particularly if the organisation is not typically prone to rapid action.
Projects will often start with a ‘Sprint Zero’ to get all the groundwork in place, and the temptation is to stay at this point – turning it back into a waterfall project with all uncertainties removed before the start.
How can you address this?
There need to be limits on all up-front activity, however painful that feels. Of course, there are some things without which the project can’t start, but in almost all cases there’s enough information to do a 2-week sprint. Just start doing regular iterations; only by developing a rhythm will teams start to understand what matters and how to do proper just-in-time iterative delivery.
8. Tooling and automation landscape insufficiently mature
Many aspects of Agile transformation create challenges that can’t be solved by conventional means. There is a wealth of new tooling and automated solutions available to the organisation struggling to cope with the new pace and the dynamics of rapid iterations.
How can you address this?
Organisations could often benefit from external support to help them develop the technology they need to support their Agile transformation, be that cloud migration, infrastructure automation, automated build & deployment tools or better work organisation tooling.
9. Individuals with right breadth and depth of skills not available
With Agile you are now moving at pace and you don’t have the time to wait for a specialist skill to become available months down the line. Also, you can’t just swell Agile teams with more people without causing other problems.
How can you address this?
This often requires a cultural change whereby organisations with rigid role boundaries will struggle. If your organisation sub-divides its roles into very distinct categories and doesn’t allow them to stray beyond them then you’ll struggle to ever get an Agile team who can problem solve by themselves.
The organisation must make a decision
If the organisation has not dealt with the challenges up to this point then Agile adoption will be struggling to make the required headway. If this happens you must be able to call in senior support so that the organisation rises to meet these challenges, or you will see adoption start to back-slide and benefits not being realised. Moving towards full Agile maturity further challenges can spring up:
10. Scope is ambiguous and outcomes unclear
Scope is often a difficult concept to grasp in Agile. The scope isn’t fixed, but that’s not to say that there aren’t still non-negotiable outcomes and objectives that the endeavour needs to achieve.
Many Agile projects, if they’re not controlled, will start to meander and lose sight of their intended outcomes. This is particularly prevalent where leadership roles are weak or absent and when teams are new to Agile.
How can you address this?
This is where the Product Owner must play a strong role, being very clear on the business outcome that needs to be achieved, and working very closely with both the delivery teams and business stakeholders to manage that on-going negotiation throughout the project.
11. Activities cannot be broken down into small iterations
Some tasks and activities don’t lend themselves well to and throughout the project. If you have a major re-platforming of a business application this might require significant hardware and software changes, many of which need to be ‘big bang’ and all represent significant pieces of work. How do you iterate across sprints when some activities are huge?
How can you address this?
This largely comes down to practice. Some pieces of work are longer than a 2-week sprint, yet there is always a way to sub-divide them, even if that means that for several sprints there is no actual new functionality visible in production. Once you see the benefits of Agile and feel a rhythm developing it becomes easier to understand how to break down even the most significant tasks to the right level.
12. Risks are not actively mitigated
Agile requires far more active risk management than you’ve been used to in waterfall. In a traditional waterfall project, a risk log and monthly meetings are set up to review risks and take action to mitigate the more urgent ones.
In Agile, the risk is critical within days of it being raised, and if you don’t deal with them in days, if not hours, then they’re live in production before you’ve even thought about them.
How can you address this?
This is where ‘servant leadership’ has started to form a recognised part of Agile, particularly in the role of the Scrum Master. The Scrum Master has the duty to break down organisational barriers, resolve queries, facilitate the right technical permissions and clear any blocks.
Coeus Consulting is an independent IT consultancy providing strategic advice and programme execution to multinational clients, particularly those operating in highly-regulated industries. The London-based consultancy specialises in delivering agility and performance improvement.
