"We want to be more Agile" - a practical response

‘We want to be more agile’. This desire has been very prevalent in Change and IT functions over the past couple of years. With the advent of Digital, and ongoing comparisons to digital native companies, we often hear phrases such as ‘we want to be more like Google/Netflix/Amazon’ coming from companies across every business sector.

Let’s start with a hypothesis (and some hyperbole!)

The marketplace is changing faster than ever before. New competitors from outside the sector, new channels to engage and sell through, SaaS (Software as a Service) and other technology making it easy to go to market quicker – yet many Change and IT functions are still grappling with 1-2-year lead times for new projects to be delivered. Customers within the business are frustrated that “it’s difficult to do business with you”. So you need be more agile. It’s a worthy aspiration, but if you’re on the hook for change, just how do you go about doing it?

The killer question is: Why do you want to be more agile?

What problems are you really trying to solve? Some common ones are:

jpeg

You may be thinking – some or all of these reasons apply within my company. It’s a good exercise to rank these in order of importance, because they each need a slightly different focus.

The key point is that there are many different reasons for needing to be more agile, and they need different responses.

It is common for leaders to approach all of the problems from an organisational perspective – the hypothesis that the siloed nature of the organisation is at the root cause.

Whilst this is often partially true, there is seldom a “Scrum team” or co-location silver bullet. Most organisations are complex, multi-location entities; organisation and location changes can (and should) make the handoffs more efficient, but there will always be handoffs.

The real prize is in engendering a collaborative culture where people know and trust those they are dealing with, regardless of reporting line or relative location.

And importantly, being clear on the external outcome you’re aiming for, before focusing on the internals.

An approach to getting there

If you’re clearer on the outcome you’re trying to achieve (your vision), it’s now a case of setting out your target operating model to properly embed the changes you need to make – in simple terms “what it will feel like when you’re there”.

Designing in the shorter time to market, the multi-threaded delivery model, Agile alongside traditional delivery practices, etc, means setting out the way ideas will flow through the shaping, creation and exploitation phases.

 

approach-diagram-rgb


Trap #1—Getting the Target Operating Model for change wrong

Defining a good Target Operating Model is a topic in its own right (and will be the subject of a subsequent article), however here are some common traps to avoid.

  • The TOM needs to cater for all change concurrently, not just standalone projects. It is a common failing to design for discrete projects: Anyone can deliver one project, it’s delivering 100 in parallel that’s the challenge!
  • The TOM isn’t an OD exercise, although this is part of it. It describes how change is shaped, created and exploited, and should look through multiple lenses, including capabilities, organisation, sourcing, handoffs, governance, process.
  • In our view, the best TOMs are those which can be given to anyone from the CEO to a developer and be understandable to all.
  • It is often powerful to run some use-cases through the TOM to bring this to life.

If possible, and in parallel with defining the TOM, a current state assessment should be carried out. Whilst the pinch points may be clear to you, it’s likely that other stakeholders will have a different view.

It’s also critical (and cathartic!) to involve a wide range of stakeholders in assessing the current state, to build the guiding coalition for any subsequent change. A current state assessment gives you an objective benchmark to improve from.


Trap #2—Focusing on the delivery factory rather than upstream and downstream

Often “being more agile” is interpreted as hiring Scrum Masters and holding daily stand-ups within the delivery function.

Whilst these may be helpful, it’s usually missing the real improvement value, which is usually upstream. It is a curious phenomenon that time and effort always seems to be slightly less precious in the shaping phase than in the period just before go-live – yet a week lost in shaping is still a week lost in delivering the value.

Shaping is tough, because (in its widest sense), you are dealing with intangible concepts, working through a series of translations and interpretations between businessman and technologist, trading off strategic vs tactical, and dealing with a set of hard-to-articulate (and ever-changing) constraints.

But in our experience, there are more improvements to be made in this area than in the delivery factory. As an example, consider using Agile/Scrum principles for the shaping phase, even where a traditional overall delivery approach is necessary.

Using “Spikes” to thrash out ideas and solutions, with senior business leads, architects, developers, programme managers can often cut through months (even years!) of circling.

Having a clear vision and TOM based on the outcomes you’re trying to achieve, and a shared view of your current state, means a relatively simple exercise of defining the transformational activities to implement the changes required to get there.

Other things you might need to consider
  • The biggest opportunity for reducing time to market is usually in the up-front shaping and prioritisation – many organisations focus on marginal gains in the delivery function, but the biggest gains are before any code is cut
  • There are no methodology silver bullets, despite what we’re all told – the diversity of change types we’re asked to handle means it’s inevitable that a multi-modal delivery approach is usually needed. “Horses for courses” is a good maxim to live by
  • Handoffs and interfaces are always a weakness – our innate “tribal” nature leads to walls between teams. Process and methodology will help, but to resolve sustainably requires behavioural change and an environment which supports collaboration. This typically takes years, not months, and can’t be shortcut
  • Don’t ignore your funding model – The funding model for change delivery is often at odds with “more agile” delivery (or delivery full stop!). Engage your CFO on this topic and ensure there is an understanding of the “agile” drivers, rather than on simplistic cost measures. You will save more money through shaping solutions in 6 weeks rather than 6 months, than you will in reduction in unit cost
What does good feel like?
  • You can have a partnerial conversation with the MD of one of your business areas about tweaking the roadmap, without breaking into a sweat. He understands the constraints and is considering them when he thinks about his business plan
  • You are delivering change to the market before your competitors
  • You have a range of delivery models and can choose the right one for the specific initiative, depending on the relative priority order of cost, specificity of solution, time to market, quality
  • You’re the one speaking at the Gartner (or other!) conference on how you did it!

It doesn’t need to be a lengthy exercise to work out what “being more agile” really means to your organisation. But it’s highly worthwhile being clear what it means before setting out on your transformation.

SHARE OUR STORY

DOWNLOAD THE FULL ARTICLE NOW
SEND THE ARTICLE TO A FRIEND

POSTED BY: Steve Calder - Consultant

CONTACT: steve.calder@projectone.com

View the author's team profile page

Find out more