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.
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.