Agile transformation is not easy. But there are ways to make it easier.

More and more organisations are seeking to transform themselves into an “agile organisation”. But what does this actually mean?

In my experience, what this widely sought-after goal actually means and entails can generate a lot of confusion, right from the outset.

With that in mind, I’d like to share some of my first-hand experience, drawn from all kinds of organisations. I hope it’s useful to consider before your own organisation embarks on such a journey.

Firstly – is your belief system compatible with agile?

A lot of agile thinking revolves around quality – quality that yields genuine value, not gold plating. The quality of the people doing the work, the quality of the code they produce – and most importantly the quality of the products that end up in the hands of users.

I have a fundamental belief that quality is the most important thing you can possibly focus on. Letting go of this focus is the root of most evil, and putting quality back at the forefront is the solution to most problems that plague IT.

This might sound obvious, but it’s not actually a belief that’s encountered everywhere in enterprise IT. More often than not, IT is seen as a cost centre – where the focus is more on efficiency, economies of scale, consistency, and predictability than it is on quality.

So what does this mean for your organisation’s agile ambitions? Well, the further away your set of beliefs is from this quality-first mantra, the harder it will be for you to embrace an agile approach.

If your organisation does not believe that improving IT can significantly increase revenue, then the kind of investment in quality that is required is unlikely to be approved by the executive board. This brings me to my second point.

Agile on its own is not enough

Agile practices will not, and can not, turn mediocre developers into good developers – and they certainly won’t remove the legacy architecture constraints that are slowing you down.

This is true for any process or ways of working – whether it’s Scrum, SAFe or Prince2. It does sound obvious but it’s worth repeating, over and over!

So, back to my point above – if you are not ready to invest significantly into your engineering capabilities and transform your architecture across your entire enterprise, you can’t really expect to get any significant improvement from agile methodology alone.

‘Agile at depth’ before ‘agile at scale’

Agile at scale is a hot topic right now, but you shouldn’t focus on trying to scale from day one. It’s far better to concentrate on tackling the really hard constraints early on, while the scale is still manageable.

Many organisations are in a rush to implement agile across their entire organisation, and try to approach it in a top-down, prescriptive way. But agile at scale is not easily solved by an off-the-shelf framework.

One approach we have seen work well is to start with a small number of small teams, focusing on manageable scope, and running thin threads across your entire organisation. I’ve noticed that agile ‘transformations’ can sometimes just scratch the surface, focusing on somewhat superficial practices that are easy to implement (like workspaces and ceremonies). However, the key to real transformation is to go as deep as possible.

By doing this, you’re not shying away from the problems that are hard to solve – things like breaking down organisational silos, removing dependencies, evolving architectures and improving automation. Your initial aim should be to build a repeatable end-to-end delivery process in one business area, which will require you to:

• modify your legacy architecture as appropriate;
• deploy automatically in the cloud;
• use best-of-breed open source technologies;
• evolve your product based on thorough user research.

If you are stopped from doing this along the way, there will be limited benefits in trying to scale the approach to the rest of your organisation (at this stage).

However – if you can establish what good looks like early on, build the basis of a self-reinforcing culture, maybe organically grow a digital platform with services that can be shared by many teams, and keep eliminating dependencies between each team as they emerge, you will find that you can scale without losing most of your agility – and without the need to implement a pre-defined framework.

The best agile coaching comes from hands-on delivery

Those leading the charge are naturally keen to show that agile transformation is having a big impact across the entire organisation. To do that, they will sometimes unleash Agile Coaches across a large number of teams.

At a superficial level, this does give the impression that things are moving. People get enthused about the possibilities, and they start changing their processes. But too often, I have seen these initiatives lose steam after the initial few months. That’s when people start to realise that agile is not going to magically make things easier – if anything, it forces them to face their hardest problems, but with little practical help to overcome them.

To avoid agile fatigue overcoming your organisation, Equal Experts takes a different approach. We favour enlisting the help of seasoned agile practitioners that join your delivery team and provide hands-on coaching day-to-day – while actually delivering software, side-by-side with the rest of the team.

This way, we are able to share the pain and address the tough problems together. If you do this, the appropriate culture and practices are much more likely to “stick” for the longer term. This is what will enable your organisation to eventually become truly self-sufficient from an agile perspective, and not revert to old habits when things get challenging.

Agile transformation is achievable

With all the pitfalls I’ve described above, are there actually some organisations that get it right? Of course, answer is yes. Some. We have seen organisations achieving genuinely great results by doing the following:

• Building a strong engineering-centric culture – with an emphasis on code quality, automation and working “smart”.
• Establishing long-lived cross-functional teams, which own a product or service throughout the lifecycle (including operations and support)
• Setting up an organisational structure that provides autonomy and purpose – where teams have control over their destiny and are given autonomy in how to solve their problems, with a relentless focus on breaking dependencies at every level of the organisation, and every step of the software lifecycle.
• Evolving organically common platforms that encourage re-use, reinforce positive behaviour and scale multiple teams – without creating rigidity that reduces efficiency and innovation.
• Deploying new versions of the product multiple times a day, and improving the service based on genuine user feedback and research
• Evolving a bespoke build over many years, scaling it to larger and larger teams and more and more business features, while keeping the codebase easily extensible and keeping the defect count to a minimum.

So yes, it can be done. But as we’ve seen, successfully achieving agile transformation is not simply a case of choosing an agile framework and rolling it out across the organisation.

If you take just two points away from this, make it these:

1. Ascertain first what an improved capability around bespoke solutions would really mean to your organisation. If the expected benefits can justify significant investment – not only in processes and tools, but also in people, architecture evolution and into the business beyond IT – then you can begin to learn what agile at depth looks like for your organisation.
2. Avoid getting a false sense of progress by taking the easy way out. Start addressing the most severe constraints straight away – proving your success through deliveries that are meaningful (but at a manageable scale). Over time, evolve common platforms to encourage good practices, rather than dictate them.

Once you have established a strong culture in pockets, you can scale it organically to the rest of the organisation.

If your experience is similar or different from mine, I would be very interested to hear from you!