]]>https://vanguard-method.net/2018/09/better-digital-from-better-method-2/feed/019132Lloyds Bank and Digital Transformationhttps://vanguard-method.net/2018/08/lloyds-bank-and-digital-transformation/
https://vanguard-method.net/2018/08/lloyds-bank-and-digital-transformation/#commentsTue, 07 Aug 2018 09:22:07 +0000https://vanguard-method.net/?p=18962Lloyds Bank embarked on a digital transformation but found the Big-Consultant-led methodology drove high levels of failure demand in to its service centres. In this video you will see how the Vanguard Method rescued Lloyds from what was becoming a disaster.

At the world’s first International Summit on Failure Demand, discover:

How to eradicate failure demand in your own organization

The benefits of eliminating failure demand, from industry insiders

How stripping away failure demand leads to radical innovation across every sector

Learn from innovative industry leaders who have eradicated failure demand with astonishing results – huge gains in capacity, massive reductions in cost and game-changing innovations in customer service and product development:

Martin Heath, manager of Repairs, Voids and Logistics for Unitas (council-owned company responsible for maintaining Stoke-on-Trent’s 18,500 council houses)

Jo Gibson, Senior Consultant, Vanguard Consulting

Book your place at the definitive summit for the service industry on failure demand, from the people who discovered it. Find out how to get rid of failure demand in your own sector to build a truly agile enterprise.

Look out for further announcements confirming the speakers.

What is failure demand?

Failure demand is a huge untapped reservoir of FREE improvement for those in the know.

Failure to do something – turn up, call back, deliver something – causes the customer to make another demand on the system. A failure to do something right – not solve a problem, send out wrong or incomprehensible forms, turn up at the wrong time – similarly generates knock-on demand and extra work.

Why does it matter?

It matters because it causes problems for customers, costs money, frustrates staff and slows down your organization, making innovation almost impossible.

Radical innovation

The good news is that being self-generated, failure demand is under the YOUR control. Failure demand represents enormous potential for improvement. Eradicating it, or at least reducing it, provides a double hit. It cuts the cost of service by reducing rework and duplication. But at the same time – the big secret – it also frees up the capacity to innovate and design game-changing products and services.

Book your place

We expect this event to be popular so we advise you to book now to avoid disappointment.

£295 + VAT per delegate. Book before 14th September 2018 for the Early Bird rate of £245 + VAT per delegate.

To book, please complete the booking form and return to office@vanguardconsult.co.uk

Do you know in your bones that Command-and-Control management has had its day? Are you actively interested in moving beyond the cost-increasing, revenue-jeopardising, morale-bashing Command-and-Control ideology? Or perhaps you are aware that pioneers have achieved levels of improvement – both in the numbers and morale – that are nothing short of jaw-dropping?

A national network

Then join with others in the Beyond Command and Control Network.

Signing up for the network is free. Connect with fellow travellers at national events. Receive a regular newsletter to find out what’s going on in the Beyond Command and Control movement.

Get first notification of the Beyond Command and Control Masterclass series and a member’s discount on the ticket price. The Masterclass series will expose you to the profound achievements of the pioneers, equip you with the practical means and help you understand the issues on the Beyond Command-and-Control journey.

Local and practice-based networks

We know people find it valuable to share their journey and learning with others. In order to help you do this, we plan to support a range of local and profession/practice-based networks across the UK in 2018 in response to demand.

If you are interested in joining or setting up a local network where you live or a practice-based network for your profession, please tell us what would best help you on the form below.

Sign up FREE

Join a network of people moving beyond command and control.

All we want from you is enthusiasm, an interest in being on the journey and a willingness to share your stories.

Whether you are interested in joining a local network or would just like an occasional email from us, sign up here:

[contact-form]

]]>https://vanguard-method.net/2017/10/join-the-beyond-command-control-network/feed/016931The greatest challenge is management resistancehttps://vanguard-method.net/2017/10/the-greatest-challenge-is-management-resistance/
https://vanguard-method.net/2017/10/the-greatest-challenge-is-management-resistance/#respondFri, 06 Oct 2017 12:10:20 +0000https://vanguard-method.net/?p=15844Déjà vu is the phenomenon of having the feeling that the situation currently being experienced has already been experienced in the past.

The report was written after surveying transformation and change leaders, in over 900 businesses, covering industries from banking and finance, manufacturing, technology, consulting, government, academia, and health.

When the question was asked ‘What is the greatest challenge facing your organisation this year and next?’ – a whopping 71% of respondents answered: ‘Management resist change’. It was followed closely by ‘New technology & business models’ which 67% of respondents also identified.

When I read this, it triggered a feeling of déjà vu. I was sure I had heard this before…

I looked around at some old articles and found one written 25 years ago titled: ‘Improving the performance of workgroups through information technology’ by Clive Holtham.

In 1992 Holtham stated:

The failure to improve the effectiveness of work groups often lies for less in any technical dimension than deep in the management style and culture of an organisation. If key strategic steps are not taken from the top of the organisations, no amount of effort at middle levels can compensate for this

Déjà vu!

Holtham is right when pointing to the top of organisations. We shouldn’t just limit management resistance to the often criticized ‘middle-management’ – or the ‘frozen middle’ as Peter Drucker termed them. A good example of this is when the CEO of one of Australia’s biggest banks announced that his organisation was embarking on a transformation that will move away from a traditional hierarchal structure, and yet, in that same announcement, the CEO also stated that the transformation would cut in two levels below him.

As with most problems that organisations are trying to solve, the problems have existed for a long time. Over the course of time, various frameworks, methodologies, and approaches have come and gone. Panaceas that promise much and purport to solve these problems, turn into fads and die, bowing out to the next wave of ‘new thinking’. As the 71% of respondents to the question: ‘What is the greatest challenge facing your organisation this year and next?’ can attest, Holtham’s issues of management resistance, highlighted in the early 1990s, gives empirical evidence to the fact that the latest panacea does no better than its predecessors

It is not uncommon for people trying to transform organisations to rationalise a failure of change away, complaining that ‘If the only managers had got it!’. What they should be reflecting on is that it was a failure of rationalistic method.

Turning our attention to ‘New technology & business models’, the paradox here is that IT & Digital teams do not have what is required within them to make it work either, or to put it another way, IT & Digital is cultural too.

Over and over again, new technology and business model improvements are thwarted by forces that are not commonly-known, and are illusive to those attempting to make changes. This social inertia is because of the lack of effectiveness in current methods available to technology professionals and managers alike.

Our findings show that the 71% quoted in Australian Transformation and Turnaround Association report is an underestimate. We have found that almost 100% of transformation activities fail, or fail to sustain, due to being fought off by the management culture, or to be more precise, fought off by the organisational system the managers have created.

Why do I want to turn the attention to technological transformation? International Data Corporation (IDC) predicts worldwide spending on digital transformation technologies will reach $1.2 trillion in 2017. That’s a lot of money being spent on change. How’s it all going?

Organizations are not confident in their visions for the future: Less than half (44 percent) of respondents are extremely confident in their organization’s ability to achieve its vision for growth, and 4 percent are not confident at all.

Why the lack of confidence? The study found that management culture was an issue. For example, when decision makers were asked ‘Does your culture support change and innovation?’ – it was found that:

‘Department leaders do not regularly collaborate with one another: Just 30 percent of respondents say departments across their organization always come together to problem solve.’

‘Respondents feel their company culture supports the ideals of innovation, but they cannot overcome a lack of internal collaboration that makes executing digital transformation difficult.’

‘(76 percent) of respondents say their department competes with other departments in their organization for resources and/or budget.’

The report goes on to give rationalistic ‘Tips for organisations’ to help them solve these issues. One ‘tip’ is: ‘Organizations must work to remove silos so that all members can collectively contribute to an improved end product that exceeds audience expectations.’

I had that feeling of Déjà vu once again…

Back in 1992, Holtham wrote:

It is necessary to be able to create new, more fluid partnerships and alliances, both within and between organisations

It is almost as though we learn nothing from our experience. The same issues are prevalent 25 years later, supporting the reality that they are designed into the organisation.

Sticking with technological transformation, you can’t move today without bumping into an article or speech that highlights the perils of ‘Being Ubered’ (a phrase coined by Publicis Groupe CEO Maurice Levy, meaning your organisation is at risk of being disrupted and dethroned, and therefore you must evolve). The facts pointed out are stark; very few of the Fortune 500 companies listed in 1955 either still exist, have not gone bankrupt, or have not been merged or acquired by another firm.

Maybe this is another contributing factor for decision makers lack of confidence in their organization’s ability to achieve its vision for growth, as reported by PointSource.

When I was a child I used to watch a futuristic world where the Daleks in Doctor Who would warn “You will be exterminated!” – now I’m an adult, I encounter the world where consultants warn “You will be disrupted!”.

Unfortunately, the prevailing answer to disruption, promulgated by the consulting firms, is to invest in technology. With a $1.2 trillion trough, you can see why. The problem is that to fend off disruption, investing purely in technology isn’t the answer, the organisational operation must also change. Both go hand in hand. Various commentators are now voicing similar opinions. However, is it again Déjà vu?

Peter Keen, in his book ‘Information Systems and Organizational Change’, published in 1980, wrote

When technology is changed, the other components often adjust to dampen out the impact of the innovation. Many writers on implementation stress the homeostatic behavior of organizations and the need to “unfreeze the status quo”

Peter wrote this 37 years ago. It’s not like anyone hasn’t heard of him. If you look at his biography it states that he has been ranked in a number of surveys as one of the world’s top 100 thought leaders in business, the most cited researcher in the academic and business literature, and among the top ten IT consultants!

The challenges of ‘Management resist change’, ‘New technology & business models’, ‘Executing Digital Transformation’ and ‘Not being Ubered’ are all a product of the same superordinate issue; the command-and-control design and management of work, which has dominated organisations for years, and, without method, is remarkably impervious to change.

Peter Keen wrote back in 1980:

We now have adequate theories of implementation. We have less understanding of counterimplementation … overt moves, often made by skilled actors, to prevent a disruption of the status quo.

Technology has been an unwitting instrument and enabler of command-and-control. This is because IT & Digital professionals are being asked to solve problems from a command-and-control point of view, and it is that very point of view that needs to change if we want to enable the technology to work and work well, from the users’ perspective.

Applying a design thinking, human centered, lean-agile approach, by using service design and experience design experts in a command-and-control organisation, will result in little to no discernible change.

The PointSource study shows a deep lack of confidence in executing digital transformation. If organisations are to spend $1.2 trillion, there will be a lot of money poured down the drain. As a consequence, many of the people involved in such programs of work will see their hard efforts wasted. Who wants to put their heart and soul into creating something that is either cancelled or is not valued by the recipients?

This isn’t to say that people at all levels are stupid, or guilty of malintent. This is not about stupidity or intention. Everyone would say they are trying to do things better. What is more appropriate is to state the people are guilty but not to blame, in other words, the crux is that they have been let down by bad perspective and methods.

To solve the challenges of ‘Management resist change’, ‘New technology & business models’, ‘Executing Digital Transformation’ and ‘Not being Ubered’, technology professionals and managers ultimately require a different structure, different measures and, most importantly of all, a different philosophy; one where they move beyond command-and-control, where the prevailing thinking is aligned to customers, and where they see their job as adding value to the work. This will then solve these challenges for good.

————————————

To obtain differentiated results, progressive leaders are turning to the Vanguard Method which has received numerous academic awards for contribution to management science and were the first winner of the Harvard Business Review / McKinsey Management Innovation Prize for ‘Reinventing Leadership’.

If you would like to learn more, join us at the Progressive Leaders Summit 2017, Melbourne Arts Centre, on the 2nd November.

The annual awards aim to recognise the people making a difference in housing and communities across Northern Ireland and the Republic of Ireland. Many congratulations to the team at Cluid.

]]>14719High tech, the low tech wayhttps://vanguard-method.net/2017/02/high-tech-the-low-tech-way/
https://vanguard-method.net/2017/02/high-tech-the-low-tech-way/#respondMon, 20 Feb 2017 11:03:58 +0000https://vanguard-method.net/?p=16873How a housing allocations team went digital on a whiteboard – and developed a simple tailored solution without involving IT at all

It started on a whiteboard …

I was working with a team in local authority housing that was redesigning the way properties about to become empty are allocated to families in need of social housing. We’d reached a point where several properties were being dealt with in the new emerging flow and it was becoming increasingly difficult to keep track of the status of individual properties.

Not unexpectedly, the team’s starting point was: ‘Let’s get IT to develop a system to keep track of them.’ After some discussion members decided that what mattered was to start by creating a tool that was low tech, simple and visible. So we started on a whiteboard. Where did we end up? … well, more on that later.

The point here is that when organisations encounter a business problem, more often than not they respond by reflexively turning to information technology. The result is that the original problem gets papered over – not solved but embedded in a technology solution. The result is overly complex, costly and unnecessary IT solutions. It’s not that the use of IT is bad – if well conceived and designed, it can greatly improve effectiveness and efficiency – it’s the unquestioning way we turn to IT as the solution.

An example of where the unquestioning approach leads. In many service organisations the work required to solve a customer’s problem is fragmented. That is, rather than being completed by one person it is split across many people, the thinking being that specialisation of tasks will be more efficient. In fact, to do the work, information about it needs to be shared by several people, so fragmenting it creates problems of communication and coordination. So we stitch it all back together with an IT workflow solution, when a better remedy would be to get rid of the fragmentation that caused the problem in the first place.

Returning to the housing team let me provide some context for the evolution of the IT solution.

The existing workflow is typical of what happens in local authority housing departments and housing associations.

How it used to be…

A tenant tells the housing officer that he or she is moving out, signalling that a property is about to come vacant. On confirmation of the departure, the housing officer requests a nomination from an allocations officer. The allocations officer advertises the property, allowing registered users (i.e. people on the housing waiting list) to bid for it. On average 100 people do so. When people are added to the waiting list they are put in bands of need – high, medium or low. When the bidding window has closed, the allocations officer selects the bidder with the longest wait in the highest band of need. The selection or nomination is passed to the housing officer. The advertising, bidding and selection process takes an average of 23 days. At no point does the housing officer – who knows the property, neighbours and neighbourhood – have any involvement in the selection of the successful bidder.

When the current tenant hands back the keys, they are passed to building services for inspection and refurbishment, after which the housing officer arranges a viewing with the successful tenant and signs them up to move in.

How it is now…

In the redesigned process the team arrived at a better flow that:

Eliminates the advertising and bidding process which causes delay and prevents effective consideration of right person/right property

Builds in a site visit with housing officer and surveyor before the existing tenant leaves to gather information that would help identify a new one

Reshapes the allocation role so that it can be done collaboratively between the allocation officer, housing officer and surveyor

Designs in opportunity for the incoming tenant to view the property and agree with the housing officer and surveyor what work is neededbefore moving in and what work the tenant chooses to have done after they move in.

Agreeing what work is needed before moving in eliminates the waste of removing non-standard items that might be useful for the new tenant.

Ensures that the incoming tenant has enough time to make moving arrangements

Designs in appropriate collaboration with housing benefits so the new tenant is set up ‘clean’ – that is, they know exactly what their net rent will be and they are set up to pay.

How we got to a better IT solution…

Now let’s return to the problem foreshadowed at the start – how to manage the movement of properties and people through the redesigned flow.

As noted, the team began by using a whiteboard. There was a column for each housing officer and a row for each stage in the process. Property addresses in the appropriate cell indicated the owning housing officer and the stage the property had reached. Information moved vertically down the board as the property progressed through the flow.

This worked well while the number of properties and staff involved were low but became messy as they increased. However, it did allow the team to get clear on the information that was needed at each stage.

Having arrived at an effective flow and information needs empirically, the team was now in a position to decide on a better way of making the progress of properties visible and manageable.

The initial candidate was a manual, wall-based T-card system – which was quickly discarded since it needed to be visible both to all housing officers and surveyors, and each had different information needs.

So the team experimented with a web-based T-card system that could be readily tailored to different user needs. In just hours they built a simple and powerful visual management system that continues to provide effective support to the end-to-end void and allocation flow.

The following screen-shots show the two primary views of the T-card information – one used primarily by housing officers ensuring the right people are allocated to the right properties, the other by surveyors managing agreed work to properties.

This example from local authority housing is a simple illustration of the Vanguard principle that deferring decisions about a potential IT solution until after the flow has been redesigned results in better supporting solutions, cheaper and much more quickly.

It’s worth reiterating that having started with a low-tech manual solution (the whiteboard) the team progressed to a commercial web-based solution that was readily configured by housing officers (i.e. non-IT people) to suit their specific needs – in hours. In this example, there was no need for specialist IT involvement at all.

The moral is, don’t default to IT as the solution to business problems. Apply the principle: understand the problem; improve the underlying flow; and ‘pull’ IT as necessary. Start on a whiteboard!

]]>https://vanguard-method.net/2017/02/high-tech-the-low-tech-way/feed/016873Better outcomes in software developmenthttps://vanguard-method.net/2017/01/better-outcomes-in-software-development/
https://vanguard-method.net/2017/01/better-outcomes-in-software-development/#respondFri, 20 Jan 2017 10:51:43 +0000https://vanguard-method.net/?p=15519The Age of Enlightenment was a wave of humanist and scientific thought that spread across Europe during the 18th century, producing great advancements in many fields, particularly in science.

In recent years software development appears to have experienced its own age of enlightenment with the spread of ‘Agile’ methods taking more adaptive and iterative approaches, requiring continuous learning among its practitioners. But if that’s true, why does so much of the software and technology that touches our lives still seem to be problematic?

A brief background to Agile

My earliest experience of software development was during my electronic engineering degree in the early 1990s. We were introduced to the programming language Modula-2 to teach us problem-solving through the use of computers. The first chapter of the textbook laid out a method based on six steps:

Define the problem

Design a solution

Refine the solution

Develop a testing strategy

Code and test the program

Complete the documentation

This linear approach is also present in many of the formal or plan-driven approaches to software development that were in common use at that time (e.g. Waterfall or V-model). These methods are sequential: each stage must be completed before progressing to the next.

At that time computers were spreading fast through business, and the increasing pace and need for change triggered a crisis in the software industry. An ‘application delivery lag’ of up to three years between business requirement and working software was not unusual. Increasingly frustrated with the long development times, a group of like-minded software professionals came together in 2000 ‘looking for something more timely and responsive’.

Several emerging concepts and methodologies – iterative development (drawing on Deming and Boehm), the alignment of concurrent activity (influenced by Takeuchi and Nonaka’s 1986 Harvard Business Review article, ‘The New New Product Development Game’) and self-organising teams (as in Sutherland and Schwaber’s ‘scrum’ software development process) – now started to be drawn together. The result was a manifesto drawn up by the group which set out new principles of effective software development in contrast to the sequential and plan-driven approaches.

The document was named ‘The Agile Manifesto’. Agile was not intended to be a methodology but rather a mindset, within which a variety of methods and practices co-exist (SCRUM, Kanban, Scrumban, DSDM, BDD/TDD and XP among others).

A number of organisations ascribe their success to Agile. One of the best-known and most influential is Spotify, which so far has managed to keep ahead of much bigger competitors such as Google and Apple. Agile also has critics, however, who point to high-profile failures such as the Department of Work and Pensions’ Universal Credit and less than overwhelming results from the UK Government Digital Service. So what is causing some organisations to succeed and others to fail?

Common traps associated with Agile

The tools trap

When Japanese car manufacturers such as Toyota began to gain global market share at the expense of western competitors, industry experts queued up to visit Japanese production plants to learn the secrets of their success. What they observed was widespread use of technology (robotics, Andon cords), techniques (Kaizen, Kanban, just-in-time) and training (skills such as problem-solving and Six-Sigma analysis). Much of this learning crystallised into practices that fall under the ’Total Quality Management’ and ‘lean’ banners, which have been deployed not only by vehicle manufacturers but also in a wide variety of sectors and organisations. Yet outcomes have often been disappointing or even detrimental. The problem is that it was not the tools but rather the principles and thinking that were key to Toyota’s success, and these are completely missed when the improvement techniques are used ‘out of the box’.

The thinking trap

In the same way, with no understanding of the thinking behind Agile practices, the focus of teams remains fixed in conventional thinking, so Agile becomes reduced to cards and sticky notes on walls with teams having meetings standing up. In one large financial organisation I worked with, over 400 personnel had been through Agile training, yet a year later not one piece of work had been delivered in an Agile manner.

Even when teams learn to apply Agile principles in practice, they often run up against traditional management philosophies and structures based on the idea of the organisation as a machine to be controlled in all its components (including those completing the work), which is entirely at odds with Agile thinking.

The structure trap

At heart team software development is a series of interactions and learning processes between knowledge workers that sits uncomfortably with the way projects and changes are handled in organisations. Traditional managers are unsettled by the lack of fixed plan or demands for cross-functional personnel for unpredictable periods, interfering with corporate resource planning and productivity reporting. They struggle with perceived lack of structure that leaves them feeling delivery is not in their control. In some organisations this results in an ‘Agile sandwich’, with delivery teams using Agile methods to deliver changes that are then subject to weeks or months of delay to fit in with traditional planning and release schedules. No matter how Agile the code developers, they are always at the mercy of those working to outdated industrial-age management dogma.

The ‘wrong problems’ trap

The final and most destructive trap is to have teams working Agilely on the wrong problems. In their article on improving software project management, Brendan O’Donovan and Peter Middleton show how software projects are often subject to highly unsystematic and partial selection criteria, carrying the danger that the organisation is merely getting faster at delivering the wrong thing, expensively replicating poor existing processes in ‘IT concrete’. The key to effective change lies in understanding service capability as a system and from the users’ perspective.

In a large financial organisation I worked with, an application development team was working to address a backlog of errors and bugs that were affecting an automated financial platform. Although the organisation was in the process of implementing Agile, the leader decided he first needed to better understand what was really happening in his organisation, using the Vanguard Method to do so (although to be clear the Vanguard Method is not one of Agile’s many flavours).

The team quickly learnt that it was much slower at resolving coding issues that it had imagined. The average end-to-end time from starting work to implementation of the solution was four months, but predictably could be up to 11 months. That was bad enough. Four further findings added to the shock:

The fixes were small and relatively simple (typically no more than 10 lines of code, limited to one module and had no impact on external system interfaces)…

… yet each issue had a massive effect on operational teams, which had to take manual action, often complicated and time-consuming, to correct the impact on a supposedly automated system. In one case, operations calculated that correcting errors in customer accounts was costing it the equivalent of the work of five fulltime employees.

Issues had often been identified long before the development team got to them, typically sitting in a backlog for two years. The problem therefore affected the operational team for far longer than the developers were working on it.

Perhaps most worrying of all, the controls and governance structure were showing the team’s performance as ‘green’ – ie it was meeting performance requirements with no outstanding issues.

Rather than simply using the Agile techniques they had been trained in, the leader and team decided to work to principles drawn from systems theory, in effect to determine whether the resulting outcomes were beneficial or not in a wider context. In essence they were putting scientific method to use by testing their hypothesis that ‘the new principles will improve the team’s effectiveness and therefore performance’.

Within months they had learnt how to put the new principles into practice, with effective solutions taking an average of four weeks, and predictably up to eight weeks, to implement. The change of focus and decision-making resulted in a new approach to governance and collective learning, leading to further improvements. A year on, effective solutions were predictably being implemented in less than a week, with simple scenarios being resolved in two days, as the application team and its leaders progressively identified constraints obstructing the work and took action to remove the ‘waste’. Having eliminated the backlog, the team progressed to close working with the operational team proactively to prevent backlogs from occurring.

All the improvement occurred without the use of Agile or related operating models. At the same time, some of the practices emerging from the systems principles had parallels with Agile.

We were left with a working hypothesis that better outcomes in software development are dependent not so much on using Agile practices as on the effective application of systems principles. A critical consequence of using a systems approach, as opposed to a software perspective, is that business change and IT efforts are focused on issues that demonstrably affect outcomes for customers.

Releasing the new principles into production

Unlike new software code into a computer, principles cannot simply be ‘installed’ in groups of human beings. The Italian astronomer and physicist Galileo is one of a number of historical figures who have suffered persecution for espousing new thinking that challenges the common dogma held by the hierarchy. Galileo was ordered to turn himself in to the Holy Office for trial for maintaining the belief that the earth revolves around the sun, then deemed heretical by the Catholic Church. Standard practice demanded that the accused be imprisoned and secluded during the trial.

The development of new principles, or a new manifesto, requires a change of thinking and behaving. In conceiving the Vanguard Method, one of John Seddon’s founding tenets was that effective change cannot be imposed on people but has to be enabled through study of what is happening in the work and why. Helping people to experience for themselves why change is required may take more effort than other approaches, but it is the only one that works sustainably. If training programmes for techniques such as Agile do not challenge managers’ traditional frame of reference, they will continue to manage rather than lead teams, nullifying Agile’s potential benefits. (Which is why new employees often find it easier to tune in to the Agile mindset and practices than do staff with long experience of older methods.)

Even if people do get to understand for themselves how and why Agile principles should be applied, this still leaves them short of method to identify the constraints affecting the performance of Agile teams. This is why in the earlier example the Vanguard Method was key to the remarkable improvements in cycle times that were eventually achieved.

So what?

Any organisation adopting Agile thus faces a choice: either treat it as the latest fad or accept that it needs to be set in a systems perspective. Do managers stay in the comfortable framework of current dogma? Or do they move into the enlightenment that comes from understanding the organisation as a system and dealing with change accordingly? The latter demands a change of thinking not only in those developing code, but in managers throughout the organisation, regardless of functional speciality or seniority. From my observation, successfully applying Agile requires a solid investment of leadership in:

propagating a manifesto of principles grounded in systems theory

enabling a learning organisation that is able to put the principles into practice

using intervention theory to enable change in the organisation.

Naturally if you have any data or observations that enable me to improve on my hypothesis I would be very grateful to hear about them.

Designed right, digital technology can enhance the quality, efficiency and accessibility of service and build the human capacity of customers and staff alike. Designed wrong, it makes us less efficient and dumber, while costing a huge amount of time and money. The key difference is not in the tech itself, but in thinking. This is not a 21st century Luddite rant, a call to break the digital frames. Rather the message is a hopeful one: if we understand why attempts to exploit digital technology are often a let-down, we will build better principles that keep us and our organisations smart.

How can we discriminate between smart tech and stupid tech?

At the Santa Fe Institute, Professor of Complex Systems David Krakauer describes technology in terms of its ability to help us think, reason and problem-solve more effectively. The abacus is a ‘complementary cognitive artefact’, because using one regularly alters a user’s neural pathways to create a ‘virtual abacus’ in the frontal cortex, so that experts can perform calculations without needing the physical object to hand. The abacus makes people smarter.

Some technology has the opposite effect, reducing cognitive capacity to become a ‘competitive cognitive artefact’. Calculators erode the ability to do mental arithmetic and long division. Maps and sat-navs are respectively complementary and competitive navigational technologies – one builds intelligence, the other reduces it.

Stupid tech

The insight that technology can directly affect intelligence exposes some common problems in technology use in services and gives a clear direction for better design. As an example of dumb-down tech, consider a physiotherapist friend’s unhelpful and fractious visit to A&E with a suspected broken ankle:

Nurse practitioner, studying script on computer screen: ‘I need to manipulate your ankle because I have to work out what pathway to put you in.’

Patient: ‘That will damage my ankle! I’m a physio, I know that I need an X-ray first to figure out whether my ankle is broken or not…’

Nurse practitioner, still driven by IT pathway scripts: ‘So it’s not broken, now I need to manipulate your ankle to its full range so I know what pathway to put you on.’

‘Don’t touch my ankle, you will damage it even more if you do that! I could end up with a permanent problem. Now that we know it’s not broken, I know what to do to rehab myself – I told you I’m a physio.’

‘But I need to manipulate your ankle so I can put you in the right pathway – are you refusing treatment?’

IT-driven assessment and pathway tools are common in UK health and social care. They have become a disabling technology because they cause professionals to act in ways that stop them understanding and absorbing the variety of presenting demand. The IT-driven scripts, standardised assessment tools and workflow timescales and rules make them more stupid, and has the perverse effect of increasing demand into services and damaging outcomes.

Smart tech

Here are two examples of complementary cognitive technology – tech that makes us smarter:

In financial services a multimillion-pound automated workflow management system was decommissioned and staff focused on improving the flow of mortgage applications through a physical process. Technology was then realigned to support information capture and processing needs of the staff, so that they could understand what mattered to each customer and manage cases accordingly. Failure demand and time from application to final offer halved, productivity went up by 50%, Net Promoter Score doubled, revenue increased and staff morale improved.

In one housing repairs organisation, focusing the physical flow of work on enabling a ‘one call, one visit, one fix’ response to incidents led to a 50% reduction in costs fell by 50% and dramatically better service. The technology was redesigned to display workers’ current location and estimated availability for the next job, enabling call takers to match workers to jobs and arrange mutually agreeable appointment times. The new IT system was orders of magnitude cheaper than the old one, and was deliberately designed to help tradespeople take responsibility for doing good work.

To a mindset that assumes that all tech is beneficial, these designs are counterintuitive. Yet in a complementary versus competitive perspective, the logic is clear. It is to design technology with the aim of enabling staff to do good work: to think, reason and problem-solve effectively.

A new digital philosophy

It is very easy to create tech solutions that make performance worse and us dumber. We need a digital philosophy that keeps us smart and enhances not only the effectiveness of our service organisations, but also the human capacity of customers and staff.

Dumb tech assumptions

Principles for smart tech

Technology will improve our current situation

Design for value first, pull technology second

Develop the discipline of designing tech that helps us better create value by anchoring all design decisions not in annual plans but in a deep understanding of and redesign of processes according to what matters

Digital by Default – all tech is useful

Smart tech to help us think, reason and problem-solve more effectively

Only use tech that complements human activity, that enhances our cognitive and social capacity, and that eliminates tedious, tiring or dangerous tasks

Projects destined for success

Decision-making integrated with work

Leaders facilitating emergent change

All design and deployment in the discipline of experiment, test and learn… all change designed as experiment, allowing agents to cope with emergence and continually challenge assumptions

The answer is simple and hard at the same time. Simple because all we need are new principles. Hard because these principles challenge received wisdom, disrupt long-established custom and practice, and require us to re-wire and de-commission organisational structures and systems. The good news is that when people start the journey, improvement begins to flow, staff, managers and customers alike love the results, and momentum builds.