Challenging the Conventional Wisdom of Agile at Scale

Why doesn’t the concept of a Minimum Viable Product (MVP) always fly with business decision makers? And why is the notion of ‘failing fast’ in serious need of an upgrade?

In this episode of the Navigate Disruption podcast, Eric Krell talks to Infosys Consulting Associate Partner Shaun Betts on why banks and other financial institutions are embracing organizational agility, the bottlenecks that can hinder progress on these initiatives, and crucial drivers of success that often get short shrift, like mindset shifts, cultural adjustments and behavioural changes. Shaun also discusses why we should move away from some conventional agile concepts like MVP and ‘failing fast’ to ensure the business is fully aligned with the agile agenda.

Transcript

Narrator
Welcome to Navigate Disruption, an Infosys Consulting podcast that shares insights on digital innovation and market disruption. In each episode we cover trending topics that help business leaders navigate their transformation journey in an age of constant change.

Eric Krell
Hello, it’s Eric Krell. On this episode of Navigate Disruption, I speak with Shaun Betts, Associate Partner, Agile Transformation with Infosys Consulting. Shaun’s doing a lot of work right now helping clients in the financial service achieve organizational agility at scale. As most listeners know, agile methodologies got their start on software development teams inside information technology functions. Today, more companies want all or most of their business groups to operate according to those same agile methodology principles and approaches.

Fulfilling that objective can deliver some wonderful benefits. more efficient operations, much faster speed to market and speed to value, and major strides in a bank’s ability to innovate. Establishing organizational agility also requires navigating around some tough obstacles. Shaun’s familiar with every aspect of the agile at scale journey, better yet he’s bilingual. Shaun’s fluent in technology and the business. That’s important because it lets Shaun challenge some of the conventional wisdom on agile that’s out there, such as why the concept of a minimum viable product, MVP, doesn’t always fly with business decision makers, or why the notion of failing fast is in serious need of an upgrade.

In our discussion, Shaun shares his take on why banks and other financial institutions are embracing organizational agility, the bottlenecks that can hinder progress on these initiatives and crucial drivers of success that often get short shrift — things like mindset shifts cultural adjustments and behavioral changes. Let’s get to it.

Let’s start by setting some context for organizational agility in the financial service’s industry. Traditional organizations typically begin their agile journeys in the IT function. A handful of developers well-versed in agile methodologies gather in a small room and then quickly progress, learn, iterate, and ultimately create a valuable new technology offering for the business. This technology-centered agile work has gone very well, Shaun. What do enterprises want to do now, though?

Shaun Betts
Whilst there’s considerable benefits for technology teams adopting an agile delivery model, companies should probably be enabled for agility throughout the organization from idea through to value. Agile technology teams lead to a more efficient, quicker, faster route to market, speed to value. But without that constant flow of value based prioritized work that will bring the real benefits to the business, they’ll never fully realize the potential of agile at scale.

Eric Krell
What do banks and other institutions hope to achieve from organizational agility? What benefits are they after?

Shaun Betts
Little has changed in the way of organizations’ goals. They still want things faster, cheaper, better. So, they’re looking for rapid speed to market to increase their time to market, time to value… to be a bit more responsive to customers’ changing needs in a very dynamic environment. They’re looking for better quality. They want things to be right the first time. And they’re looking for reusable assets that they can use over and over again, rather than something that’s bespoke for an individual build, or an individual customer.

They’re looking to retain excellent talent, particularly in the digital world, in a very competitive market, and to be an employer of choice. They’re also looking for efficiencies through the teams — to try and drive out more with less. Repeatedly, we hear things like, “I want to get the same outcomes with 50% less investment.” And of course, they’re always looking for cost efficiencies, and cost reduction. Agile will typically give them around a 20% cost reduction on a typical delivery lifecycle.

Eric Krell
There’s a lot there, a lot of benefits. Generating that type of value isn’t easy, especially within legacy financial services organizations. What commonly goes wrong when large companies attempt to do agile at scale?

Shaun Betts
I think a true problem statement for larger organizations is agile at scale. They’re all bogged down with legacy infrastructure and architecture, which makes it difficult to change, which is not necessarily lending itself to an agile manifesto. And that sort of landscape in architecture is so interwoven, that delivering any front facing product for a customer will require multiple organizations to work together, multiple product streams and value streams, looking at shared services and shared applications across a number of products to make something to happen.

So, if you pick up any textbook on agile, they will talk about autonomous teams and cross-functional self-contained teams that don’t have to go beyond their siloed boundaries. And that’s great in theory, but with large organization who have built themselves on economies of scale and platform structures and organizations, that’s simply not possible. Things such as accounts receivable platforms, core banking platforms, core payment networks, rely on some degree of shared services, supply multiple products to bring an actual end consumer product to life. Getting those guys to plan, to coordinate, to manage their supply and demand and operate at the same level of maturity in terms of agile development is tricky.

Eric Krell
There are a lot of moving pieces. Shaun, you recently published a paper that takes a look at bottlenecks on the agile journey. Tell me about at least a couple of those obstacles.

Shaun Betts
Well, the organizations are starting to think about agile and agile transformation in their agile journey, but they typically start with a technology bias. It’s the technology teams that are moving towards more agility. And the rest of the business is fairly slow to catch up. What that often leads to is tensions between technology and the business teams. If you look at the typical structure of a bank, they’re typically structured into two separate silos of business and technology. Not only do they have separate reporting lines and are structured differently, but they also often have different geographies, different locations and don’t come together.

And this is where we’ll see the technology teams trying to adopt agile, and the business teams operating largely in a more waterfall approach of handing over requirements rather than working hand in hand, in real time with the technology teams that’s working for them. Now that leads to a couple of queries. On the technology side, they’re saying, “Why aren’t I getting a prioritized flow of work? Why is it stop, start? Why is it project-based? Why are we having to stand up and stand down resources in a traditional waterfall manner?”

Now this leads to all sorts of difficulties for them in their financial management, in looking and retaining the resources that move away from the need to have continual persistent teams who can add value and can drive the efficiencies that we spoke of earlier. At the same time, they like that predictability with other teams, so that they still are operating in that handoff legacy architecture mode, which constraints speed and agility.

Eric Krell
I want to offer up some other challenges you’ve identified, so you can flesh them out a little bit. The first one I want you to address is this notion of, “Hey, we’re agile. That means we don’t need to plan.” What’s wrong with that thinking?

Shaun Betts
This is something that I often hear from technology teams and it causes some frustration from business teams: “We’re agile, we’ll think the next sprint ahead, or the next couple of sprints ahead.” And this builds tension from the business for a number of reasons. First of all, if you don’t know where you’re heading, you’re never going to get there. So, you need to have some intentional design and architecture to understand, “What does the end game look like? What am I building towards, what am I moving towards?” And that may be fluid and will change and iterate, but as things stand today, where do I see myself?

The business needs to have some degree of readiness. There’s lots of things that they may need to put into place. Whether that is looking towards reeducating service agents, or on the front line with customers. Whether it is a promotion of a new product, whether it is a launch of a new feature on a mobile app that they have. They need to have all the marketing that goes with that. They need to have the support that goes with that. They may even have to organize legal reviews and copy text with a variety of people before it even reaches the technology space. And all that requires effective planning and preparation.

From a technology perspective because of the interwoven architecture and landscape that we have, it’s impossible just to work in isolation at two weeks sprints at a time. There has to be that coordination to sure that all those dependent parties are on that same cadence.

Eric Krell
Anyone getting familiar with agile also is going to hear the term “fail fast” a lot. What’s unhelpful about that mantra?

Shaun Betts
Fail fast is not a great term to use, because none of us want to fail and the connotations that go with a not great. And it certainly gets a little bit of an allergic reaction from leadership teams when we talk about failure. Many teams spend an inordinate amount of time looking at parameter settings, getting things verified, double-checking, putting four eyes on it, because they are afraid to fail. And there’s little value in that process other than they don’t get it wrong. You’ve got to question why this is happening.

And one of the reasons that I found that one of the teams I was working with is going down this path was because of a blame culture. It’s not safe to make a mistake. The ideal in that scenario would have been, “Look, just put a parameter in, do a quick test. If it fails, fix it fast.” The culture didn’t lend itself to that in that organization. Often, I’m tempted to use the phrase of we either win, or learn fast, rather than we fail. Because the connotation’s right. We win, great, everyone’s successful. We learn fast. We don’t keep repeating that error that we’ve done.

Eric Krell
Another issue that crops up relates to the phrase “minimal viable product (MVP).” Why do product managers and a lot of other people in the business bristle at that term?

Shaun Betts
MVPs just have a lot of, again, negative connotations, particularly around the business, who quite rightly are not wanting to put anything that’s less than perfect in front of their customers. Increasingly to overcome this, I’m using the term of version 1.0, rather than MVP. So version 1.0 it indicates, this is great. This is a go-to-market approach. This can be presented to a customer. In its own right, it’s a finish product, but it also indicates that there are further versions down the line.

Eric Krell
Clearly, there’s a ton of work that goes into making legacy financial services enterprises in agile organizations. At the highest level though, what’s crucial to understand about this work and the factors that drive its success?

Shaun Betts
I really want to emphasize the need for a one team, seamless approach across business and technologies. That’s why the fintechs and disruptors thrive. They don’t have technology teams. The business teams and the teams that they’re trying to deliver products and have agility throughout the organization. Agile shouldn’t be limited to technology teams alone. Sustainable, optimal benefits are most likely to be realized if the entire organization is on that same journey. Adopting agility throughout and thinking as one. If we think about the last mile of any product is the actual technology delivery stream with this. Before that there’s a whole series of evaluation, ideation, analysis, feasibility that takes place. All of that should adopt the agile approach.

Eric Krell
Shaun, your research identifies several other key steps that help bring about the cultural change, the mindset shifts that organizational agility requires. Briefly tell me about one or two of those other enablers.

Shaun Betts
Well, any organization that’s setting out on adoption of agile, agile transformation, particularly at enterprise agile, we should understand why we want to do this in the first place. What are the drivers behind this? So often people will say, “I want to be agile”, but don’t really understand what that means. They’ve probably heard the buzz word. It’s a flavor of the month. Other organizations are doing it so they want to be on that same journey, but they’ve got to really understand why they’re doing it in the same way we spoke about planning earlier, they’ve got to know where they’re heading and to know when they’re on the path to getting there.

There are multiple models to follow in terms of agile that offer different levels of business engagement, different operating models. The organization has got to understand what’s fit for them in their context. They need to be realistic. The journey is going to be difficult. It’s not just a case of walking out on a Friday in a waterfall way and coming back in on a Monday as a truly agile organization. There is no checklist that you could say, “Do these 10 things and you will be agile as an organization.”

Eric Krell
Shaun, I really appreciate hearing your take on organizational agility, especially all the components that are focused on practical change, new ways of looking at things and new ways of interacting. It’s been very comprehensive. I thank you for your time, and I wish you well and agility on your journey ahead.

Shaun Betts
Thank you.

Narrator
Thank you for listening to the Navigate Disruption podcast. To find out more about how Infosys Consulting is helping some of the world’s most recognizable brands transform and innovate, visit us at Infosysconsultinginsight.com, or follow us on LinkedIn.