Steve Marjot, recently joined Jon Terry, Chief Evangelist for Lean-Agile Strategy at Planview, for a webinar to discuss the RBS Agile transformation journey from traditional portfolio management to Lean portfolio management over the last several years. He shared successes, learnings, the obstacles overcome throughout the journey (which is still very much a work in progress), and their ability to pivot, in an Agile way, from the enterprise-level down.
After sharing the work his team has done throughout the journey, Steve spent some time answering audience questions. The questions and answers are below.
Q: How do you maintain good governance in this process?
A: I think the assumption here is that traditional is good and Agile is bad, but it’s about appropriate governance at each level, and you don’t go from one end of the Agile journey in one go. It’s a transition, step by step.
At each level, you make a change, you review governance to make sure it still fits the purpose and is appropriate, all while applying Agile principles. At an Enterprise level, if we’re moving to delegation of funding envelopes [buckets of funding], then we have a governance process that’s appropriate for defining that envelope—the size and categorization—and how we communicate it downward.
At the Domain [value stream] level, we start to look at governance around signing off on business cases and holding people accountable for the outcomes within the business case. When we get to the Program level [Agile Release Train—ART—level], the governance at that point is about leaders embedding themselves in things like Program Increment (PI) Planning and running the equivalent at the old Program board but inside the PI Planning event—set the vision at the beginning, review the outputs during the course of planning, solve the issues as they go and then sign off the resources and funding at the back-end—ultimately committing to the next three months’ worth of work.
As you shift, focus on the change you have to make to govern and continue to support that within your organization.
Q: How much of the RBS transformation was pushed from software dev / technology, and how much from the business, or is it joint?
A: It is very much a joint effort. We’ve been running Agile projects, teams running Agile Scrum practices, for many years. For quite some time, we’ve had pockets of Agile design work in our customer franchises and Agile delivery in our technology space.
This reached a tipping point, where organizationally, we felt it was right for us to transform at an enterprise level, rather than just the local level. We decided to transform our operating models, organizational structure, roles, processes, and tools to support that transformation. It was a coming together of business and technology to make that happen.
It was a long gestation period—we started in early 2014 and went through late 2016, essentially building that single capability to look at the enterprise as a whole. From late 2016 to now, we’ve been working to transform to Agile. It’s been a two-year journey, and we’re still a long way from embedding it successfully across the entire organization. We’ve gone from 90% traditional portfolio management and 10% Agile to about 70% traditional and 30% Agile. We are slowly transitioning to get the ball over the hill and make it heavier Agile or Lean Portfolio Management than traditional portfolio management.
“I think for Agile to be truly successful at scale, you need to have both sides [IT/Software Dev and Business] involved. If your Agile adoption is principally driven by the technology organization because they just want to do it, your business customers might not be fully on board and not understand the why. To be genuinely successful, they have to understand the benefit and understand what will be different. Otherwise, all the changes you’re making are simply just going to be viewed as heavy-weight.” – Jon Terry, Chief Evangelist Lean-Agile strategy, Planview
Q: What is one major mistake made during the roll out at RBS?
A: To be totally honest, the whole process feels like you’re taking three steps forward and two steps backward every time you try to implement a change. Even with champions and supportive leaders, there’s always a group or somebody that has a reason why that change can’t be enacted. It’s a very difficult process—it’s a culture change and change management.
If I had to pick out one thing that totally floored me, it was when we deployed the organizational changes to support an Agile way of working. Some parts of the of the business employed non-change professionals in the Agile Release Train manager roles. These people came into this with no grounding in the governance, assurance, or risk-management processes that our change professionals know inside out. The thing we completely missed, was that while we’re talking about a 50% reduction in data transfer and speeding up cycle times, they had no idea what these things meant. What these non-change professions see is 50% imposed governance and data which is 50% too much, as far as they’re concerned.
What we found is there’s an education challenge and maturity challenge. When you bring run and change together and make them jointly accountable, you can’t actually just do that and expect it to work. There’s a fundamental and significant culture change and capability piece that has to be done as part of that process.
Q: How do you evangelize the transformation to the broader organization?
A: It’s all the normal processes. You have your Agile evangelist leaders who stand up and say, “I’m going to be accountable”—they live it and breathe it. Then you have your Agile coaches helping make those changes throughout the organization. You start seeding the Scrum Masters and coaches. Ultimately though, it’s all led by the top—Leadership. They must be committed to helping remove impediments to make it successful.
Q: Where does the Change Center of Excellence fit in your organization? Do you still have steering and oversight groups? How does that structure look today?
A: These groups still exist, but how we enact them has changed. At the Program [ART] level, we have program governance embedded in the program ceremonies and ask the leaders to go to the ceremonies, participate in the decision making in real-time, and document the outcomes and decisions of those conversations. This creates an audit-able record to show how leadership is managing those dependencies and making good financial decisions.
When we talk about the Domain [value stream] level, the key thing was no longer requiring typical governance, but it had to be replaced with something equally robust. For example, when we think about architecture, we used to require each Program to produce an architecture blueprint that sat alongside its Program business case. What we now ask, is for each Domain to create a business Domain blueprint that articulates how its leveraging the architecture of the bank, how its leveraging technology enablers, and what outcomes they are trying to deliver over the course of the next year through the funding of their Domain business cases.
There is an architecture authority that oversees this process and ensures it’s maintained across the entire bank. We used to do this at the Program level; we now do it at the Domain level in a slightly different way. The group still meets frequently with the same people, but those Enterprise Architects now have fewer Domains to look at and spend more time thinking about the application of that architecture. We still have steering groups; wherever possible, we try to embed them in the ceremonies of the work or make them relevant and appropriate to the level of governance we’re trying to achieve.
Q: Has your budgeting process changed?
A: We still have an annual budgeting process. At this time, we have no intention of changing that process. What we currently do is define the envelopes for funding on an annual basis and use the Domain business case mechanism as a way to delegate the funding down for continual decision making at a local level. We haven’t changed our annual funding process with our finance team, but we’ve applied Agile principles, in terms of delegation of work, prioritization, and decision making.
Q: Is there a way to quantify the value of what you’re delivering to customers through this new way of working?
A: With our new approach, we build the quantifiable results into the business case and then at each level. With these in place, we hold the Domain accountable, based on the outcomes they want to achieve with the funds allocated. When we get down to the Program level and start to talk about features that are a piece of value-driven work, each feature should have a mechanism for identifying what that value is and how it’s measured. If we slice that further, we expect every user story to have a definition that includes the value that will drive from it—like cycle time. Higher up, we’re looking at revenue driven or NPS score. Each level must be tied to applicable value at each level. Ultimately, they have to achieve the business outcomes at the enterprise level.
If you’d like to hear more of Steve’s story as he leads the Agile transformation at RBS, check out the on-demand webinar. To learn about Lean Portfolio Management and how it’s changing value delivery throughout the enterprise, download the Lean Portfolio Management for the Enterprise whitepaper now.
