What’s Missing from Agile?


In this 3-part series John Seddon launches an attack on the value of Agile as practiced and charts a better way to analyse and design for improvement, making information technology the last thing to be concerned with, not the first.

Part 1: What’s missing from Agile?

Last year we completed an assignment helping a leader improve mortgage lending operations at a bank. In straitened times and within a matter of weeks, the work paid off in the shape of a massive increase in capacity and much improved customer service. As the system was scaled, sales grew with no additional resources.

Whats Missing from Agile?Very soon after, a group of Agilists arrived with a mandate to “digitise” the bank. Their first initiative aimed to reduce costs by substituting databases for surveyors. Mortgage lending requires a valuation of the property. The bright idea was that the cost of human valuation could be cut by using databases of house sale prices to calculate average local property values. In no time at all there were problems. Properties are not all equivalent. Using an average inevitably causes two errors: over- and undervaluation. Overvaluation puts the lender at risk; undervaluation leads to loss of potential customers who go elsewhere for their mortgage. Customers complained. Sales fell. The idea was speedily abandoned. The digitisers were delighted, however – for them it was a great example of “fail fast” (a mantra out of the “Agile” playbook). But why did the initiative fail? And, moreover, why fail at all? What are the knowable and unknowable costs?

At the same time, we heard from a colleague of a similar occurrence in another bank. Another band of Agilists, again on a mission to “digitise”, had set up camp in its mortgage operation, where they busily designed and implemented a “mortgage tracker”, an online tool for customers to track their application through the mortgage process. For us this was like a bad joke. By definition, tracking is most likely to be progress-chasing and therefore constitutes what I call failure demand – demand caused by a failure to do something or do something right for the customer. In a mortgage business run on conventional command-and-control lines, it’s immediately obvious to a systems thinker how the process leaves customers in the dark. With end-to-end times painfully long, and managers blissfully unaware of the fact, how could it be otherwise?

Once again – what was the point of this tracker? In my book, the first step would have been to take apart and redesign a better mortgage service. That would have resulted in shorter end-to-end times, in itself reducing uncertainty. Add a routine notification when there is a pause in the process, and customers will always know where they stand. At which point, of course, there is no longer any need for a tracker. So how much did this pointless exercise cost?

It has been the same with every case where we have witnessed Agile in action, all over the world. The focus of the Agilists is to create digital services; their measure of success is customers using the digital channels. This is not the same as knowing that customers are getting what they need. The first clue of the dysfunction is the volume of failure demand appearing in service centres. It is a wake-up call.

What’s wrong with Agile?

Dreaming things up

Agilists use “personas” to design services, imaginary customers, and create “stories” describing the nirvana these imaginary customers will experience when interacting digitally with the organisation. Why dream up personas and services when knowledge of what’s currently going on for customers at the points of transactions with any service would provide a sense of urgency for better service design?

Focused on what IT can do

Given the mandate to digitise services anything that IT can do (features) is treated as beneficial (like property valuation and progress tracking). There is no recognition of what IT should and should not be employed to do. IT works on rules. For example: Digital services work well when demand is simple, predictable and repeatable; they work less well with high-variety demand. Using computers for things people are good at and people for the simple and repetitive things computers do well is to ask for, and get, the worst of both worlds.

Disregard of current services

The reality that customers currently receive services by non-digital means is ignored. Instead current services are treated as becoming history, to be replaced by digital means. Yet, as I shall show in Part 2, the scope for improving services is always significant and generates greater economic improvement than the eventual digitising of services. In command-and-control organisations customer service is generally poor, obliging customers to use digital channels may be a step in the wrong direction, especially when the digital services don’t meet their needs. The priority (for customers) is to make services work.

Targets for “digital activation”

Top management sets targets for “increasing digital activation” – moving transactions to the new digital channels, assuming (wrongly) that this will lead to lower costs. While it is true that a digital transaction is cheaper, if that transaction creates further transactions (failure demand) the cost of service provision rises and it impacts capacity. The corollary is achievement of targets tells us nothing about how many customers like the channels, use them successfully, or find that they create value. The Agilists driving customers down digital channels to meet “activation” targets have no knowledge of the rise in failure demand in service centres, because the latter belong to an entirely different part of the organisation; on someone else’s budget. Opening top leaders’ eyes to the larger dysfunctional picture and the associated rise in overall costs is thus the first imperative.

Don’t get me wrong, I’m a fan of the Agile manifesto. It was a breath of fresh air in the IT community. It represented the authors’ frustration at the all-too-frequent failure of large-scale IT systems. Everyone likes to do a good job; software developers are as upset by failure as their customers and users. Their ambition is laudable. Getting large-scale IT projects to work, on time, matters. But Agile has become a commercial industry of training and consultancy, teaching roles and rituals. It boils down to this: Would you invite a bunch of people off the street, ask them to recreate your organisation with the only requirements being that they behave according to unfamiliar roles and employ defined rituals in how they go about it?

The Agile fad is so pervasive that the abundant evidence of failings is ignored. Take, for example, the UK government’s Universal Credit initiative, years late with costs growing to eye-watering levels – way beyond original face-to-face service costs. Consider also the evidence that as much as 80% of code written in Agile initiatives never gets used, but you pay for it. And see how easy it is to find disgruntled developers complaining about the game-playing associated with adherence to the new culture’s roles and rituals.

What’s missing is knowledge

Agile represents change without knowledge, made under a regime that tolerates, even encourages, failure. To argue that failure can lead to knowledge is wrong. If you’re doing the wrong thing without knowing it, you won’t be able to get to the right thing by studying why the wrong thing went wrong.

Successful and profound change starts with getting knowledge of the ‘what and why’ of performance as a system. I shall describe how to make that start in Part 2.

Author: John Seddon, Author of Beyond Command and Control & Professor at Buckingham University

John Seddon is a management thinker and commentator, and currently a visiting professor at Buckingham University Business School. His latest book Beyond Command and Control is a detailed account of how leaders of service organisations have changed the way they think about the design and management of their organisations and achieved profound results.

Like this article:
  70 members liked this article


Karl Wiegers posted on Friday, October 25, 2019 10:54 AM
It's not clear to me what these misguided attempts to digitize aspects of the business inappropriately have to do with agile development. An initiative to change a business approach, for better or for worse, is not necessarily tied to how any information systems associated with that change are implemented, which is what agile is about.

I've certainly seen examples where some knee-jerk management motivation to "go agile" led to failed attempts to apply agile methods to completely inappropriate project situations. But I just don't see the connection between agile and bad business IT strategies that this article suggests.
Pete posted on Wednesday, October 30, 2019 5:28 PM
These failures are symptomatic of ignoring process or trying to fix it on the run.
If you optimise your processes first and actually manage their performance in an effective way then you can make the calls at a lower level based on evidence rather than 'hunches' by well-meaning managers and Agile evangelists.
Klaus posted on Wednesday, October 30, 2019 7:55 PM
I don't understand why Agile is blamed for problems that have nothing to do at all with Agile.
The problem is when "agilists" try to use a project to sell their "product" rather than trying to help solve a problem. I've been in a situation where the consultants, the so called agilists, focused so much on selling their services to the organization that the Agile project I was on became a pony show. I am now on another organization, and Agile is anything but a pony show.
techsmith posted on Thursday, October 31, 2019 7:24 AM
None of this has anything to do with agile, other than perhaps agile was implemented badly and the people involved didn't know what they were doing. Being agile doesn't mean disregarding all analysis and flying by the seat of your pants. That still has to happen. Believe me, I have seen colossal failures of this same type in waterfall. Have some experience in an agile shop that knows what they are doing and are delivering successfully, and then come back and talk about what's missing in agile.
Phil posted on Thursday, October 31, 2019 9:14 AM
I think you are confusing the solution/improvement, with the methodology to implement the solution/improvement. Agile is the methodology to implement it. A lean sigma black belt could have also come up with the "bad" solutions you have described.
Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC