Agile and digital transformation

I first came across agile over 15 years ago. At the company I worked for at the time, we could see our customers were changing their behaviour and moving online. We needed to respond quickly if we were to remain relevant to them.

I was asked to change roles and went to work with the software development team, which was struggling to deliver our digital solutions. I asked the team how they thought we could address the problems. And they outlined some practical steps.

In a passing comment, one of the developers explained that their ideas had a sound methodological foundation – and it was called agile. The changes made a significant difference. Agile worked for us, but I couldn’t really tell you what it was.

As tempting as it is to ask simply what agile is, it’s actually more helpful to think about where agile comes from. The following is a useful statement to begin with:

It seems fairly straightforward, but is worth unpacking to see what it’s suggesting.

• ‘originated’ indicates that what people mean by it has changed over time
• ‘umbrella term for a related set of approaches’ suggests it’s never been one thing
• ‘lightweight’ recognises it was developed in contrast to a command-and-control approach to projects
• ‘software development’ acknowledges that a lot of agile is targeted at developers

Although agile came from a specific environment, it has never been a single thing, and the broadening of its usage beyond software development has resulted in a multiplicity of agiles.

So, for me, trying to agree on a definition of agile is a bit of a distraction. What works for me may make little sense to you, and vice versa.

More useful is to probe at an important tension at the heart of agile. And that’s the difference between being agile and doing agile. [This is a distinction that has been well made before. I’ve learned a lot from reading both Neil Perkin and Ahmed Sidky].

What I mean by being agile is best illustrated by a seminal document – the Manifesto for Agile Software Development.

This outlined the four values the writers – who were 17 software developers – ascribed to agile:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And they supplemented these with 12 principles.

These are ways of approaching a project rather than specific instructions on what to do.

And what I mean by doing agile is the multitude of development practices that have been grouped beneath the agile banner – some of which were developed before the manifesto was written:

• Scrum
• Kanban
• Extreme programming
• Scaled agile framework
• Disciplined agile delivery
• Large-scale Scrum
• Scrum at Scale

etc

This difference between being and doing is, for me, the trap of agile. The ease with which it’s possible to focus on doing and neglect the being.

It’s the lure of the silver bullet.

‘Follow this specific process and everything will work out’, said the consultant, the training company, or the agile evangelist.

‘Not going well? Well that’s because you’re not following the process properly:

• Send more people on longer training courses
• Be more fanatical in your application.’

But agile shouldn’t be the goal. What you want to achieve is your goal. Agile should only ever be a toolkit, and preferably a small one.

If you’re looking to deliver significant change in your organisation, and are thinking about using an agile approach, then I have seven points for you to consider.

1. Understand your own context

The context in which you’re working is very important. Actively understanding it will help you identify the best way to use agile.

Think about your organisation, and its sector, customers and business model.

You may admire another company’s approach to agile, but how similar are they to you? Their version of agile worked because it was tailored to their business. Step carefully if you’re looking to use a similar approach but in a different situation.

Think about the type of project you’re dealing with.

Ask yourself if agile is right for this part of delivery. Just because it exists, doesn’t mean you have to use it. Some projects – for example, those with tightly specified outputs and fixed timescales – will be better suited to waterfall.

Think about the wider project environment.

Is there a project management office? How do they work? At Storm, we often combine a PRINCE2 approach to project control with an agile delivery. This works well as long as it is undertaken in a collaborative manner.

How will project governance work? Is the process sympathetic to short timescales and rapid iteration? If the relevant board only meets every quarter and wants oversight of every change then agile will be a struggle.

Think about the people and personalities.

At Storm we see agile as more than simply a methodology for ensuring efficient delivery. Just as important is its focus on uncovering and refining customer requirements.

If this applies to you then are people on your team prepared to have their preconceptions challenged by user research and user testing? Does the same apply to your project sponsor or senior management? Is everyone prepared to change priorities based on evidence?

2. Focus on principles

Avoid the trap of agile I mentioned earlier, and invest time in your principles (being agile) rather than rushing into implementing Scrum, or Kanban, or whatever (doing agile).

Agree your agile principles through discussion, reflection and understanding. Look at the whole project chain and make sure everybody is involved.

It’s worth avoiding a top-down approach where senior management defines a set of principles in isolation, or a silo approach where a project team does the thinking but doesn’t include other areas of the organisation that the work will impact.

Our principles at Storm are quite simple:

• User-centric – we believe the best digital services are based on user needs rather than organisational ones
• Evidence – we think good data beats opinions
• Iterative – we take rapid progress in small steps
• Flexible – we evaluate progress with users, and are open to change

Our principles work for us because they suit our context. They are part of our DNA: they are how we approach projects.

3. Link your principles to activities

Once you are clear on your principles, it’s important to articulate the activities that will support them. Without these it can be difficult for people working on a project to know what they are expected or empowered to do.

Using Storm as an example:

• User-centric -> User engagement

User engagement is the bedrock of high-quality development. We work with users throughout the lifecycle of the project, not just at the beginning (in user research) or at the end (in user testing).

• Evidence -> Evidence-based decisions

We gather data from various sources (analytics, surveys, workshops, interviews, observation etc) and make decisions based upon it; we avoid decisions based on personal preferences or preconceived ideas.

• Iterative and Flexible -> Rapid build-test cycles

We work in relatively short development cycles, building prototypes, and iterating based on the outcomes of user testing. We like to keep learning.

4. Find a model

Feel free, now you have a clear idea of your context, your principles and the activities you value, to draw upon others’ examples. You don’t need to start from a blank piece of paper – borrow what inspires you.

At Storm we’ve learned from others – particularly the Government Digital Service (GDS) model of agile delivery. It’s something that our (potential) clients are familiar with. It’s part of the conversation around best practice and effective project delivery.

It’s also a flexible template we can customise. We see it as an embodiment of principle, rather than a delineation of process. And there is plenty of material we can access free of charge.

5. Select the agile practices that will support delivery

Finally, you are ready to do some agile! But which way to do it? Scrum is popular – maybe you should you use that. But is it right for you? And if so, do you need to follow every aspect?

At Storm we select and tailor our approach from experience, which suits us as we have done lots of agile development projects.

If you’re starting out then it’s worth experimenting. Do your reading. Start on a small project. And start with a few processes that support your principles. Evaluate how things are going and adjust accordingly.

Another option is to seek some expert input. There are lots of people to ask, but it’s worthwhile finding someone who you are aligned with. Do they focus on being agile rather than doing agile? Do they have similar agile principles? Do they think delivering projects is more important than following methodologies?

6. Be pragmatic

Once you’ve decided to use, for example, a Scrum delivery model you need to decide which elements to implement. Just because someone somewhere says you should follow every process outlined by Scrum practitioners, doesn’t mean you have to. You should decide on a case-by-case basis.

Storm tailors its agile practices to the circumstances. If we’re using Scrum on a project then we tend to have more stand-ups and show-and-tells in the beta phase than in discovery or alpha. That’s when those practices add value for us.

We choose what we want to use from experience and experimentation, not because it’s specified in the training guide. For us, doing agile is not the goal. We are agile in our approach because it helps us produce high-quality outcomes efficiently.

7. Resources

Finally, don’t forget to commit the time and people to your project to get it done. Agile is not a magic potion.

And if you do have the money available for training, invest it in the activities you value rather than the practices you use. The returns will be much greater.

Storm ID combines transformation consultancy with fast, agile delivery to create great customer experiences. We design, develop and deliver digital services that improve people’s lives, helping our clients achieve results.

https://stormid.com/