Ways of Working Agile Transformation at NatWest (The Royal Bank of Scotland)

It’s about time that someone wrote up the history of this Ways of Working Transformation since the accounts in circulation bare no resemblance to the facts. I should also say we did some fantastic work here, Agile was given a really good opportunity to have a major impact and the Board of Natwest really supported the value proposition as it aligned with their strategic objectives of being Customer Focused.

So let’s start with the essential truth the Agile Transformation at NatWest (The Royal Bank of Scotland) was not run or managed by any Management Consultancy. A few consultancies were involved in various tasks but none of them played any central part in its planning, guidance or implementation. Deloittes were involved in the early stages directly accountable to the Central Team. PA Consulting were brought in to fill some administration roles but had no involvement in the Adaptive Strategy or Delivery of the Transformation. One PA Consultant led one Domain delivery with a lot of support from the Central Transformation Team otherwise everyone else was a direct hire contractor though Lorien Contracting (thanks). When WoW was adopted by the Retail Bank, Bain & Company supplied the delivery management consultants who worked with the Central Team to ensure alignment and functionality. Later some of the Centres of Excellence hired Accenture consultants to help with Automation.

The key people on the Agile Transformation at NatWest (The Royal Bank of Scotland) were members of staff, the CIO Patrick Eltridge, Jenny Wood CCO of IT (Head of Performance and Business Management) and Anthony Christensen, Head of Agile Transformation.

• Patrick Eltridge – Primary Sponsor
• Jenny Wood – Transformation Product Owner, WoW Lead for overall Strategic Drive and Thinking
• Anthony Christensen – Head of Agile Transformation

These roles morphed over time, but they essentially describe the key activities.

The initial Strategy and Planning work was done by Jenny Wood, Anthony Christensen, Shiraz Nazeer, Aaron Hamilton which was changed due to the pilots showing that the chosen Framework did not deliver to the nuances required in a complex organisation.

PMO in Agile is the interface between the Transformation and the non transformed Group organisation, in this transformation it was run by Gary Peterson with a changing group of specialist staff including Alana Auld (business case author and onboarding guru), I can’t remember all the PA staff who did the admin work, later Erin Brolly joined also. If I missed anyone out let me know and I will add you in.

A critical component in all transformations is Human Resources and that consultancy to ensure alignment that was done by Judith Copeland. She not only created most of the strategic Agile HR documentation she also created the internal engagements to upskill all HR Business Partners with Channan Dhindsa the Domains Product Owner and Karl A L Smith the Centres of Excellence (shared services) Product Owner.

WoW Transformation Central Team 1

Each of these team members had their own staff working across the organisation and held significant budgets for the Transformation work.

• Jenny Wood – Transformation Product Owner, WoW Lead for overall Strategic Drive and Thinking
• Anthony Christensen – Head of Agile Transformation
• Gary Peterson – PMO Office Lead
• Jagbir Sandhu – Adaptive Strategy Lead, TOM and Blueprint
• Channan Dhindsa – Transformation Lead, Adaptive Strategy, TOM and PanBank Domains Product Owner
• Karl A L Smith – Transformation Lead, TOM, Adaptive Strategy, Group Risk Liaison and PanBank Centres of Excellence Product Owner
• Judith Copeland – Human Resources, People Transition TOM

WoW Transformation Strategy and Design Team

• Anthony Christensen – Head of Agile Transformation
• Jagbir Sandhu – Adaptive Strategy Lead, TOM and Blueprint
• Channan Dhindsa – Transformation Lead, Adaptive Strategy, TOM and PanBank Domains Product Owner
• Karl A L Smith – Transformation Lead TOM, Adaptive Strategy, Group Risk Liaison and PanBank Centres of Excellence (shared services) Product Owner

As we expanded into more banks it was clear that complexity and mixed messages would cause problems it was then that three new people were added to the central team.

WoW Transformation Central Team 2

• Jenny Wood – Transformation Product Owner, WoW Lead for overall Strategic Drive and Thinking
• Anthony Christensen – Head of Agile Transformation
• Gary Peterson – PMO Office Lead
• Jagbir Sandhu – Adaptive Strategy Lead, TOM and PanBank Blueprint
• Channan Dhindsa – Transformation Lead, Adaptive Strategy, TOM and PanBank Domains Product Owner
• Karl A L Smith – Transformation Lead, TOM, Adaptive Strategy, Group Risk Liaison and PanBank Centres of Excellence (shared services) Product Owner
• Judith Copeland – Human Resources, People Transition TOM
• Penny Hope – CIO Chief of Staff, Marcoms Lead
• Darren Yeats – Transformation Lead Commercial Bank
• Debbie Wren – Transformation Lead Retail Bank

WoW Flying Squad

The purpose of the WoW Flying Squad was to formulate and create answers to questions raise about the Transformation as is spread across the organisation and to respond to localised Agile Antipatterns.

• Jenny Wood – Transformation Product Owner, WoW Lead for overall Strategic Drive and Thinking
• Anthony Christensen – Head of Agile Transformation
• Gary Peterson – PMO Office Lead
• Jagbir Sandhu – Adaptive Strategy Lead, TOM and PanBank Blueprint
• Channan Dhindsa – Transformation Lead, Adaptive Strategy, TOM and PanBank Domains Product Owner
• Karl A L Smith – Transformation Lead, TOM, Adaptive Strategy, Group Risk Liaison and PanBank Centres of Excellence (shared services) Product Owner
• Judith Copeland – Human Resources, People Transition TOM
• Penny Hope – CIO Chief of Staff

What was DONE, DONE

So it is most important to understand becoming Agile was not the focus of the NatWest Ways of Working Transformation, it was focused on aligning all the work and people around delivering the best customer experience possible and becoming a flexible organisation.

The key characteristics of this Ways of Working Agile Transformation is that it did not change everything as there were already many good practices in place. What it did was try to establish a clear relationship model between what already worked and replacing the Target Operating Model previously localised in Business, Change and Technology to become Customer Experience focused and ultimately to eliminate the change function over time.

Ways of Working did this in two ways it focused on creating clarity around the structure of the work, through a transformation strand called Organise the Work. Only after the work was defined with its boundaries and shared services was the organisational structure considered in Organise the People. This was essential so that people could adapt to the flow of work. Fundamentally Matrix Management was taken to the next level by creating two essential Patterns, Domains being where the work was done and Centres of Excellence how the work was done (skills) with the intent that teams should be measured against what was delivered to the quality actually achieved against the intention. Speed was the third component, Speed up the Work was only possible after the work was structured in the right way (agile work structure, work type taxonomy, value slicing and economic ordering into Dev Ready work) and the people with the right skills were in the right teams (to deliver the right outcomes and become future proofed through upskilling and training). Technology did not own any end customer journeys but were intrinsic in most of them, and where possible Technology platforms were moved into businesses that utilised them the most. However some functions were best optimized in a Shared Service (sometimes called Enablers) function to keep risk factors low and cost at a reasonable rate. After all an absolute implementation of the Domain principals would see technology staffing increase fifty fold. More information about the structure of Agile Transformation can be found in the 7.0 Conceptual Design section of my book from 2021, A short guide to Agile Transformation.

Secondly the focus was on How Work was Funded so that the massive financial waste created by a technology ordering process and monitoring would be completely replaced with outcomes from the Business Customer Journeys. Hence there would be no projects or programmes and Domains would be funded for RTB (run the bank) and CTB (change the bank) in one lump sum granted each 2 years. It was essential that this kind of fiscal management was established to reduce the waste of burning funds in a projects or programmes where no further value was possible so that it could be reallocated at the Domain level. This also effectively eliminated most of the front door practices that were prevalent for sound reason at the time they were created but were effectual blockers to the flow of work.

Neither OKRs or Value Streams were used in this Transformation in the context now understood. The alternative for OKRs were strategic themes given to the Domains which the broke down into focused outcomes for their Quarterly planning and Domains had named Customer Journeys instead of Value Streams. The clarity of focus by using Customer Journey names like (but not these exact ones) Buying a House, Daily Banking or Business Lending made it easily relatable to everyone. Note: Feature Teams were subset of a journey not of a system or software item as they were intended to have free range across any and all technology, people and processes that impacted the journey.

Transformation Design

This transformation had some essential constructs and eliminations in order to facilitate the flow of work in an Agile way. First though it is necessary to understand how old style banks are constructed, why and how this impedes the flow of work.  Banking has traditionally been organised into RTB (run the bank) and CTB (change the bank) and these two structures are highly logical from a fiscal and risk management perspective. However in the Agile design for NatWest it was intended that both RTB and CTB would ultimately be eliminated since they both build inflexibility and financial/time waste into organisations. While this may appear to create huge levels of risk the real intention was to establish higher local risk awareness and accountability through automated controls that would run in the background establishing an active risk monitoring culture (instead of a passive and audit based one). And this is where Lean Portfolio Management comes into the Transformation Design, adopting Agile removes Programmes and Projects (with tied people, funding and timelines) in favour of long lived customer journeys like Get a Mortgage, Pay a Mortgage, Insurance for a Mortgage, Mortgage Redemption, Remortgage that roll up into a Domain (long lived team) like; Home Buying and Ownership. In a domain construct RTB and CTB are in conflict since delivering the strategic and tactical outcomes of a Domain needs to have the flexibility to refocus people, finances and outcomes as needed. It’s one of those odd corporate things that if a programme has a budget, people and outcomes it will try and keep itself going even if it is no longer relevant or able to deliver its intended outputs, when it should be shut down and everything reallocated. In many cases there is no mechanism to to do this, except if Lean Portfolio Management has been enacted.

Eliminating Impediments

The concept of a Change function does not need to be an impediment unfortunately it has become so in many organisations strangling the capacity to deliver, well almost anything. In Agile Transformation the focus is to make Change a set of principles and skills adoptable by everyone. Instead of one major organisations Change becomes a Community of Practice that supports the investigation and resolution of common problems.

The strategic transformation design was intended to consume all handoffs of work in effect eliminate a huge amount of bureaucracy that essentially has evolved in banking over many years. This key area of Change needed to be consumed by each Customer Journey so that Change became a continuous activity of delivery rather than an organisational construct that was a barrier to delivery. In this way the intent was always to eliminate the Change Function bankwide. It was decided to maintain two change areas that would ultimately be eliminated as their work became absorbed by customer journeys or automated in software systems and orchestration.  More to follow ……

Domain Construct

The Domain construct is not a permanent structure it was intended to support the strategic aims of the Group and Banks and to exist for as long as it was needed. The operation of a Domain was intended to be very Lean and totally unstratified to ensure that decision were always being made with the right people in the room. This was most visible where the strategic value slicing would ensure that Domain business, architecture, engineering leaders were all present together in the first few sessions when discussing. This was extraordinarily useful for clarity on ownership of delivery mechanisms and exposing vendor ownership of critical components and capabilities where their cadences and horizon plans were not evident to the Domain team. At this point is was clear that vendors needed to be engaged through contracts to ensure that they could service the new operating cadences and not limit the organisation to their waterfall practices or variance in priorities.

The model below like all the diagrams are archetypes to support understanding of complexity and are not in use in NatWest. The top level of the Domain is not people, it is focused on Organising the Work and refining the ideas into strategic themes. The next level down relates to the refinement of strategic themes into Work Ready or Dev Ready. The last level is focused on Delivery of Cross Journey Features as Software or Process, it misses out other Work which would include things like Marketing, Legal etc.

Big Room Planning

We did a lot of these types of events getting larger and larger until we did the Mega Room Planning event at Murrayfield Stadium in Edinburgh. I coached Marie Cooke on what was needed to organise this as she had never done one before. I left some bits out since Marie was working for Gary Peterson in the PMO Office as an Administrator and I felt that some of the technical complexity would have taken too long to learn especially around Backlog Prioritisation, Commitments, Dependency Prioritisation etc. for technical areas like Cloud Infrastructure, Resilience and Continuity and Banking Controls, Open Banking, Blockchain etc.

Before the Bank wide Big Room Planning I would run Centre of Excellence Pre Planning Events as would Channan Dhindsa run Domain ones. These pre planning events were essential to ensure that Backlogs were refined before the main Big Room Planning events so that requests for work from other teams could be effectively prioritised and WIP set with realistic work commitments for the next increment.  Centre of Excellence Pre Planning Events would include teams from all the technology CoE’s and some of the new Business CoE’s. I also attended the Retail Banking (Commercial Banking were not ready at that point for such an event) planning events to ensure alignment and brought a representative from each Technology CoE to help refine the Business backlogs and eliminate potential waste. In one such session (of over 60) I was able to eliminate £1.5m wasted budget. In all the Preplanning in one Bank saved 18 years of time and £36m of investment in technologies that were not compatible with the bank.

More to follow ……

Delivering Agile Transformation in an Agile Way

It was essential that the Agile Transformation was delivered in an Agile Way so that all could see Agile operational. After all it is very hard to tell people something is a good idea if you don’t even use it yourself. Agile Transformation should be done in an Agile Way.  The diagram below is indicative of the evolutionary process involved in delivering an Agile Transformation after all every great general knows that once the battle starts the starting strategy needs to adapt to the true situations on the ground. The mechanism below relies upon the creation of non strict guide rails as design patterns which evolve as part of the transformation. Further the features in this diagram would be the new Domains and Centres of Excellence and not software features. Relative to the NatWest Transformation the Transformation Product Pattern Owners were Channan Dhindsa for Domains and Karl A L Smith for Centres of Excellence (with teams of Consultants working with Domain’s and CoE’s to help them adopt the new working patterns and be able to articulate their changes back to the Patterns Board), the Patterns Board was run by Anthony Christensen or Jagbir Sandhu in his absence, the Scrum of Scrum of Scrums was facilitated by Gary Peterson, the Governance Board run by Jenny Wood and included the Central Team with Patrick Eltridge and representatives from each of the Banks to ensure alignment.

Transformation Governance

Stage 1 Business as Usual Agile Governance

BAU Governance evolves over time as practices and impediments to the flow of work are eliminated by becoming automated activities that self report instead of being committees and consultancies. Further the split between business and technology is also eliminated through the Domains construct that consumes less and less shared services (CoE’s being those shares services) as they become patterns CoE’s instead.

I will add to this over time, but I hope this has given a flavour for what happened.