By Dr Amanda Salter

Back in 1991, the ideas of the Agile founders were seen as extreme, even radical, compared to the then-popular ‘waterfall’ project management method. “What? Start the project without having captured every requirement? That’s crazy!”

Two decades on, the world has executed a rapid 180° turn, committed to Agile’s focus on delivering projects quickly, especially during times of uncertainty or incomplete information. All looks well at a 30,000-foot glance, but to seasoned practitioners, the gaps in Agile are more evident than ever.

Trouble in Paradise

The reality is, Agile projects still fail, albeit less frequently than traditional ‘waterfall’ projects. One recent failure even appeared before the High Court in London. In one of the biggest cases of 2020 a high-value digital transformation project for a financial institution saw the appointment of a global technology company to design and implement a new IT platform for their general insurance business. From the outset, both parties agreed to use Agile, in the form of Scrum, to deliver the project.

(For the uninitiated, Scrum breaks down the work to be done into a set of user stories, which are then allocated to short timeboxes or sprints. Teamwork and assertive prioritisation are prerequisites for its success.)

In court, the evidence painted an all-too-familiar picture. The institution was late in producing the user stories and allowed the sprints to be derailed by stakeholders, demanding additional change to the out-of-the-box system to suit their preferences. The vendor failed to manage the sprints to keep the project on track. The subcontractor company that owned the system didn’t provide enough people to make the changes within the timeframe.

These multiple points of failure contributed to the collapse of the sprints, deterioration of trust and relationships, eventually leading to the trial. Agile could not save this GBP50m project, which was subsequently canned in its entirety.

Many advocates are disillusioned by the plethora of canny companies that have turned Agile into a money-spinning industry, complete with consultants, tools, conferences, certifications, and training. Practitioners are weary from battling within organisations that claim to be Agile, when their culture and people are entrenched in an opposing mindset. The passion and enthusiasm of many Agile practitioners have also blinded them to its failings.

Due to some of these challenges, in 2014, Agile was famously declared dead by Dave Thomas, one of the original pioneers of the Agile Manifesto. Yet, Agile and its broader counterpart ‘agility’ is still very much alive and kicking.

The question is, what have we learnt in the last 20 years of applying Agile? What do we want to take forward and what should we leave behind? What’s missing from the most common Agile framework, Scrum?

This article highlights some common pitfalls and makes six key recommendations to ensure we plug the gaps and get maximum value out of Scrum and Agile.

#1 Don’t Treat Scrum like a Religion

If you’re offended at the thought that Scrum is not perfect, you might be subconsciously treating Scrum like a religion. Once you’ve paid for the training and accreditation courses, learned the lingo, and participated in the ritual ‘pass the tennis ball/hockey stick/stuffed toy’ stand-ups, you can become attached to doing things simply because ‘Scrum says I should do it this way’.

Be careful – this is a dangerous place to be. Scrum is a man-made framework, and however great, it has its failings. Recognising this helps you to augment and tweak Scrum to work efficiently for your organisation and context.

For example, in highly collaborative teams, it’s a waste of time during a stand-up for each person to report on the work they did the day before. Instead, change the question to “What do you want to update the rest of the team on?”. This allows people to raise thoughts, questions, or discussion points, and recognise that these are equally valuable.

If you are reporting on work done, don’t say, “I had a meeting with so-and-so yesterday”. This doesn’t convey value. Instead, highlight a nugget of useful information or the outcome of the meeting. Don’t go through the motions of reporting just to prove you’ve been busy.

#2 Keep the Bigger Picture in Mind

Scrum requires a project to be divided up into manageable tasks that can be accomplished within a short time period (a sprint). This drives motivation because the work feels achievable. However, it becomes dangerously easy to get lost in the weeds, enjoying the satisfaction of moving tasks from ‘Doing’ to ‘Done’ and losing sight of the bigger goal.

Reductionist thinking results in sprints that seem successful on the surface but miss the wider project objectives entirely. Teams need to periodically check if they are still aligned to the strategic business objectives of the overall product. Put regular checkpoints in after every few sprints to do this. This gives everyone a chance to pause and consider whether the project is going in the right direction.

#3 MMP not MVP

Many Scrum practitioners work towards the concept of initially delivering a ‘minimum viable product’ or MVP. This is great because it forces teams to prioritise features and get the product out of the door quickly. However, the concept of MVP can often lead teams to deprioritise things of true value to the customer and only focus on what’s doable or achievable within the shortest possible timeframe (hint: the most valuable aspect of your product is often NOT the easiest thing that you can deliver).

Imagine that a bank wants to launch a new mobile banking app for their business customers. It’s tempting to launch an MVP with simple functionality, allowing users to login and view their account balance. However, today’s business owner will not be impressed by this limited functionality and you risk bad press and complaints.

To address this, replace MVP with MMP – the ‘minimum marketable product’. Your product needs to provide enough value that it is marketable to the end customer, i.e. can be shouted about with credibility. For our hypothetical banking app, choose a common transaction that customers currently find it difficult to do. How about enabling small traders to charge and receive instant card payments via their mobile?

#4 Involve Your Customers

Scrum started off purely as a coding framework. There was no mention of talking to customers or finding out about the problems they are facing. The result is that you can deliver software to the market super quick, but you can also discover that it doesn’t address a want or need. Thus, your baby is a flop.

Learn from the example of Bó, the digital bank set up by the Royal Bank of Scotland at a cost of GBP100 million, which provided less powerful features than other neobanks, and only survived for six months due to low customer uptake.

When creating something new, it’s even more critical to thoroughly understand the problem space you’re tackling through the eyes of your potential customers quickly and early. This prevents you from wasting time and money developing something that no one needs.

Agile doesn’t teach you how to do this, so you need to augment your toolbox. Look to user-centred design for techniques and methods. Incorporate customer research into every project and pivot your response where needed.

#5 Identify the Right Progress Metrics

Some ‘out of the box’ metrics that Scrum gives you are not always going to work for the type of project that you’re running. For instance, measuring velocity (the amount of work completed in a sprint) to estimate a team’s velocity for the next sprint makes sense only if they’re working on similar tasks across sprints. But what if you’re working on tasks that are different in every sprint? Velocity as a metric loses relevance at this point.

Find a more appropriate measuring stick. Here is where Kanban metrics can become useful (see Kanban 101 on page 18). Kanban measures progress as the number of tasks that are completed and the time taken for a task to get from ‘To Do’ to ‘Done’. This helps prevent tasks from languishing for weeks in the ‘Doing’ state. For many projects, these are more useful metrics than Scrum’s velocity. Teams should cherry-pick the best of Kanban and Scrum, combining these in whatever way that best suits the project at hand.

#6 Lay the Groundwork Before Sprinting Towards the Goal

As Agile started off as a coding methodology, it says nothing about business strategy, product vision, or business KPIs. Agile just assumes that these things are already in place and clearly understood. Often, however, they are not.

To proceed on assumption here is hazardous and can result in rework and wasted time. You need to rein in anyone who is raring to start producing outputs straight away. Make time in your project for a discovery phase before starting your development sprints.

In the discovery phase, set out and agree on a clear product vision, identify success metrics, and define how the product fits into the wider business strategy. Business KPIs must be made clear from the outset. At the end of discovery, there should be a clear vision for your product or project that is based on business drivers AND customer research. You should have an idea of the problems you’re trying to solve and the value you want to drive from the future product. This sets the direction needed by the team as they begin their main project sprints.

Plug The Gaps

Agile itself must continue to evolve, or die. Many things can be done to plug the gaps and this article suggests just a few, but let’s also keep a weather eye on the horizon.

As banking evolves, the time is always ripe for a whole new methodology to emerge, so don’t get too wedded to your favourite Agile practices just yet.

Kanban 101

Like Scrum, Kanban is an Agile framework. In Kanban however, there is no concept of ‘sprints’. There is only a running list of tasks to be done. A team member who is available will pick up a new task from the pile and move it from ‘To Do’ to ‘Doing’, and then to ‘Done’.

The key differentiator in Kanban is that there is a limit to the number of tasks allowed to be in a specific state. For example, a team could agree that there are only a maximum of five tasks allowed in ‘Doing’. This means, when five tasks are already in progress, no one is allowed to start a fresh task. One of the ‘Doing’ tasks MUST be completed in order to free up a space. This motivates the team to focus on completing tasks before they start new ones.

Dr Amanda Salter is Associate Director at Akasaa, a boutique content development firm. Based in Newbury, UK, she has delivered award-winning global customer experience (CX) strategies and been a practitioner of Agile for over a decade. Her recent guest lecture at the University of Cambridge shared insights on architecting impactful CX. Dr Salter holds a PhD in Human Centred Web Design; BSc (Hons) Computing Science, First Class; and is a certified member of the UK Market Research Society and Association for Qualitative Research.