BMK Lakshminarayanan

Hello. Greetings. Tena koutou, tena koutou, katoa. We are Bank of New Zealand, also known as BNZ. We are delighted to be here and sharing the stage with inspiring leaders and successful transformation leaders, practitioners, and experts.

We are sharing our story, Banking on Flow Metrics: the why, how did we approach it, and what did we learn from it.

Paul Littlefair

Yes, it is great to be here and sharing our transformational journey. And it is key to share with you that we have just started. We are at the beginning, and the earlier you can establish these metrics, the better off you are going to be.

BMK Lakshminarayanan

We are here on this global stage because of our people. In New Zealand, we have a famous Maori proverb, He tangata, he tangata, he tangata. It is the people, the people, the people.

However, successful businesses are also driven by purpose, and our purpose is to help our customers to be good with money. We lead the market with innovative banking and engaging customer experiences.

We are really excited to be here. In the 2019 Summit, I remember Gene and Dr. Mik were asking people about Flow Framework and flow metrics, anybody adopting it enterprise-wide. Two years down the line, we are here to share our experience and learning.

I am also thrilled today to introduce our chief technology officer, Paul Littlefair. Paul is an award-winning CIO. He is a successful transformation leader in leading and transforming complex technology units within an enterprise to be a high-performing one. He relentlessly focuses on improving the flow and value delivery. Paul believes in leaders empowering people and giving them the capability and appetite to be curious, to take risk, experiment, and bring their best every day to work.

Paul Littlefair

Oh, thank you so much, BMK, and it gives me great pleasure to introduce BMK here. BMK is a passionate value stream architect. He is a DevOps enthusiast. He has been with Bank of New Zealand for over a decade. He is a New Zealand ambassador for CNCF, the DevOps Institute, and the Continuous Delivery Foundation, and very recently he became a Value Stream Consortium board advisor.

BMK Lakshminarayanan

Thank you, Paul.

We are Bank of New Zealand. We have served our customers for over 150 years. We provide banking to a full range of our customers, from simple transactional banking, personal and home lending to individual and small and medium enterprise customers, through to complex borrowing and forex facilities for commercial, corporate, and institutional customers. We are part of National Australia Bank Group.

And while we offer a full service, we also are so proud that we have the best online banking in the country. We have won the Canstar awards for the last three years in a row, and the research has noted that Bank of New Zealand is particularly strong in its mobile offerings.

We have served families in this country for generations, and more than banking, we focus on sustainability, protecting the environment, and also our sponsorships to support and give back to our communities.

Paul, this I have heard a number of times: digital first, human when it matters. What does it mean to you as a technology leader?

Paul Littlefair

Yeah. It is a great phrase, and one we use a lot here. And while BNZ is a mature, industry-leading, and award-winning bank, we cannot take this position for granted. We absolutely need to keep pace with the disruptors. We need to continue to innovate, stay ahead, deliver the service, and support our customers. Neobanks, fintechs, and other disruptors are coming. We are well aware.

And we also have huge burdens of compliance and regulation as well. People in the audience in financial services will totally understand that. So driving a digital and innovation agenda faster is critical for us, and we need to be digital first.

However, banking also relies on trust, and so it is really important that we continue to have those human relationships with people, and so human where it matters is also key. But of course, as a technologist, I want to support that with technology as well.

BMK Lakshminarayanan

We have a great culture, amazing people here. We are a continuously learning organization. Our conversations are healthy, our bondings are great, and connections are strong.

Paul Littlefair

Yeah. So to talk about the technology at Bank of New Zealand, we provide the technology for the whole bank: the external systems, the online channels you have heard me talk about, but the internal systems, the branch, ATMs, frontline, mobile lending managers, everything. We have a full spectrum of technology.

We have a big stack: front ends, back ends, middleware, data centers, cloud, analytics. You name it, we have it. We have a super complex portfolio. We still have people building assembler in our core banking system, which predates the moon landings. We have legacy systems, batch processing, COBOL, all those legacy systems. But we are also very committed to modern systems as well. So we have microservices, cloud native, event streaming, we do it.

And we take responsibility for that entire technology stack. And as you can imagine, there is a fair amount of tech debt in there, and it may come as a surprise, but we actually have to provide the levels of tech debt to our regulators. They are that interested in the technology stack within our industry.

BMK Lakshminarayanan

But Paul, interesting question here. But despite that, everyone just says, what are and where are my features?

Paul Littlefair

Yeah, you are absolutely right, BMK. There is always the question, where are my features? What are you delivering next? Where is the delivery? And look, we need to deliver features. It is what we are paid to do. It is what drives the organization forwards.

But people turn up and say, I want this feature or that feature. And then we turn around and say, well, what about security? And they say, well, of course it needs to be secure. Why would you even expect me to have to tell you that?

And then I say, well, what about robustness and resiliency, backup, disaster recovery? Oh yeah, of course. Of course, we need all that. Risk management. How about dealing with tech debt, addressing defects? How about spending time on continuous improvement?

And so we have that real challenge, right? And we are totally expected to do more with less. How do we do that? And how do we become more effective and efficient?

And I think most people in the audience will know that you need to remove waste, right? You need to look at those non-value-add activities. You need to address the bottlenecks and look at improving flow. So we understand this in theory, and for those of you who have ever had to lose weight, I am sure you understand that eating better and exercising more are the key solutions. It is not difficult to understand the concepts. The thing that is really tough is actually doing it and making a tangible difference.

BMK Lakshminarayanan

So Paul, it sounds like the relationship between the mind, body, and the spirit. Your mind wants to go faster, but the body is resisting us.

Paul Littlefair

Yeah. And look, I wanted to share this picture with you all. This is not a picture that we have created for this slide deck today. It is a picture that we use a lot in most of our packs, and it is one I put together shortly after arriving here.

One of the challenges that we had is that every time we needed to do something, people said to us, hey, just add some more people. Just put in another team. If you have got a challenge, you have got a bottleneck, just hire more people and push the work in. And we all know that unfortunately, that does not work. It does not matter how many teams you have, if all the work eventually ends up backed in one team, you are going to have a problem.

BMK Lakshminarayanan

But in a factory setting, Paul, we could see the end-to-end workflow. We can see how the workflows in a factory, who are the people, and what activity they are working on. And there is a queue, and there is a supervisor who is managing them. And the entire system is optimized for flow. But as a technology leader, do you see this in our organization?

Paul Littlefair

Well, it is a good question because, yes, when you go into a factory, right, you can see the work flowing, if you have ever had the opportunity to go. When you come to technology departments, what do you see? You see people sat at desks. You see people sitting in front of computers.

And I often ask my teams, why do we never get the execs? Why do the CEOs never turn up? Why do people not come and see us? And I have to keep saying, because there is nothing to see.

If you are in the factory, within a few minutes, you can see the bottlenecks. You can see the old plant equipment, right? The tech debt. You can see how long it takes things to move from one end of the factory to the other. And within technology, we are blind. That work is hidden. And one of the huge challenges is we quite often behave like order takers.

And so because people cannot see the work jammed in the factory, we just keep adding more and more work into the system, and we make promises. We say, sure, we will ship, we will deliver. And then, of course, we end up breaking those promises and having to apologize, and we struggle with trust, right? And we are just not effective.

So one of the slides I did want to put up, though, to share with you, is this concept of roading and traffic flow. And what we see quite a lot in our business is our exec teams sitting, looking at the road on the left-hand side, right? A nice empty road. But they are saying, where is the work? Where are the things that are going on? It looks like you guys are not very busy. I do not see much happening. We are spending a fortune on our technology. Why is nothing happening?

And what is normally happening is down the road we have a massive traffic jam. We have everybody blocked, and nothing moving forwards, right? And it is all congested. And quite often the solution is to go and hire a load of project managers, right, and people who jump in and start trying to move the traffic around. But the challenge is they never look at the system. They only look at their specific project and the thing that they have to drive forwards. And so we always then struggle to move forwards.

BMK Lakshminarayanan

Then it is an affirmation, Paul: the years-old, long-established plan-driven management processes, associated practices, or the metrics are definitely not helping our digital-first mission. I have a question I want you to share with our DevOps Enterprise Summit delegates. What did you do, and how did you do here?

Paul Littlefair

So yeah. We did three key things, right? The first thing we did was we actually took out our PMO. I have some great project managers who are good friends, and so I do not want to come across as anti-project managers, but our PMO, our project plans, were not helping. Basically, they were just looking to drive individual projects through the system and not looking at flow.

By removing it and actually shutting it down, the first thing it did was freed up a lot of cash, which was great, and it actually got some people out of the way, right? And yeah, we were finding that the PMO was just trying to juggle problems.

Number two, back in 2018, we regrouped ourselves into technology domains, portfolios, kind of portfolios of value streams, and then we appointed heads of tech, and we introduced product management and product owner practices to own and deliver the outcomes end-to-end.

Yeah, and then the third step is, look, we still needed effective governance. So while we removed the project management office, we still needed to align with corporate strategy to have good financial management guardrails. And so we reached down into the Agile community and picked up Lean Portfolio Management, which really helps see the system as a whole, made us look at our work and dependencies, introduced us to big-room or incremental planning, and allowed us to move forwards.

BMK Lakshminarayanan

Right. Using our DevOps Enterprise connections, Paul and I reached out to John Willis. He happily offered the help, and back in 2020 he did a six-week engagement with us, and he interacted with our technology teams. He interviewed over 100 people and provided us key focus areas. And one of them particularly stood out for me: make the right thing the easy thing. Make the right thing the easy thing. This includes putting time aside for improvements. In some organizations, I have heard jokingly people saying, even the wrong things are complex.

Paul Littlefair

Yeah. BMK, and look, great help from John. The DevOps Enterprise community is brilliant. We see passionate people. We see leaders from different industries, public government agencies, large banks, retail, e-commerce, etcetera. And everybody who is attending this conference is trying to help figure out a way to move their technology, to move their business forwards.

And so we were so privileged to reach out to the likes of John Willis, talk to Dr. Mik Kersten, Gary Gruver, Nathan Harvey, even Matthew and Manuel from Team Topologies. It was just amazing.

BMK Lakshminarayanan

I could not agree more, Paul. I owe personally so much to this DevOps Enterprise community, a dynamic learning community, that is what Ross Clanton refers to it as. I have made so many connections, learning so much from all the speakers, practitioners, experts, and every delegate. Gene wrote a love letter to conference last year. I personally wrote my tributes to DevOps Enterprise Summit.

We will remain competitive only if we can deliver business value, not just code changes. As John said clearly, we want to measure the end-to-end. So you need to get better in measuring the right thing, not just commit to deploy.

Paul Littlefair

Yeah. Coding and deploy shows speed measures, but does not measure the flow of business value, which is so critical. We also have huge amounts of measures in financial services in the bank. We have process measures, people measures, service-level measures, and really what they show us is that we have a problem, that we are not delivering the outcomes that our business wants.

So it was really important for us to go and find something industry-proven. That was really critical. We are very innovative in New Zealand, and we like to solve our own problems, but some great thinking was already there, and we thought we should capture that and try and bring it in.

And we needed data that provided insights from our tools, from our processes, our feedback loops. And the key for me was really to start. So many organizations just wait to try and get everything perfectly aligned before they start. Let us fix Jira. Let us get the restructure sorted. Let us get these teams doing. Let us get this product shipped. And so often you spend your whole time waiting. Once again, you are in a queue.

And so it is important that you get going. You take that first step. And what the huge benefit is, is when you put that in, you will initially get incorrect insights. And we saw this. We had one of our teams get a flow efficiency of 80%, and everybody knew that was wrong, including the team. They were a little embarrassed.

And so what happens is the team then start to own the problem, and the team go, actually, our data quality is not as good as it needs to be for the reporting. And so they take ownership, and they look to resolve it.

BMK Lakshminarayanan

That is right. Hence, we ended up evaluating and selecting a value stream management tool to help us to see not a static value stream, instead a live value stream. Our value streams evolve over time with learning, with feedback, with improvements, and experiments. Our PowerPoint or Visio value stream map goes stale very quickly.

Paul, I have a question. What was in your mind when you came across this, and how did you introduce this in our bank? And what did you tell our technology leaders and our business counterparts?

Paul Littlefair

Yeah. So I was really fortunate. I was handed a copy of Dr. Mik Kersten's book, Project to Product, while I was on vacation. It is a great time to sit back and reflect, and I read through the book and, yeah, it just basically blew my mind, to be honest. And I came back and said, hey, we just need to do that.

It blended business metrics really well with technology and flow metrics, and I really liked that it also looked at things like culture and team happiness. And we just wanted to move forwards because, for me, one of the most important factors is that alignment between technology and business.

When you look at the startup world and the startup community, so often the technology is the business, and they are highly, highly integrated, and that is why they tend to move at such pace, and they are so successful. Those of us who are in large enterprises, the bank with 150-year history here, we tend to end up with this concept of the business and the concept of a separate technology team. We talk about them and us, and we move into this sort of feature factory and order-taker issue.

And so we really needed to bring that together. So I handed the book to a lot of my business colleagues. I have used the language, and we have really brought the teams together. And the other key thing is we have shared with the business that we are making flow metrics core to our transformation. It is not just a project on the side. Every team in technology is going to be using flow metrics. It is the basis of the way we measure our work.

BMK Lakshminarayanan

So that is right, and brilliantly said, Paul. I think we also introduced the flow metrics in our board-level reporting. Our customers do not see us as business and technology. They see us as one BNZ. We want to go with something that is industry proven, as Paul said. We need data to provide insights, not individual intelligence.

Let us get on to see how did we approach this.

Paul Littlefair

So as we embarked on our value streams, we asked an important question. Who is going to own and drive this, right? So we have a lot of engineering teams in our bank, but to bring and introduce the change, how are we going to do this? And as Deming famously said, every system is perfectly designed to get the result it gets.

So how do we design our system? And so one of the key things, we created a new role, value stream architecture, and you are looking at one of my value stream architects. This is a critical role in our journey, right? We want our value stream architects to be influencers, consultants, optimizers. They work really closely with our product and engineering community to ensure that the integration aligns with business goals and delivers tangible value.

With flow metrics, we are in the process of designing feedback mechanisms that enable a full 360-degree view of our entire software development landscape. And we stood up an enterprise flow team and asked for expressions of interest. We went to the team and said, who would like to be a pilot team? And our flow team then engaged with the engineering teams, the product teams that showed interest. We spoke with their heads of tech, portfolio and product managers, and product owners.

BMK Lakshminarayanan

That is right. We are in the learn-to-see stage, experimenting, modeling, coaching a dozen teams in total, including teams from lending, cloud platforms, engineering, and data.

We approached a staged way. We call it learn to see, learn to improve, and learn to scale. We stood up the BNZ Flow Hub, the hub for people to connect, explore, and learn more about it, and we provided navigation guides. You can see that on the screen: learn to see, learn to improve, and learn to scale.

We held team engagement sessions. We ran campaigns to win books: Making Work Visible, Project to Product, and DevOps Transformation. And we presented to cloud, data analytics, and product management communities.

We also made self-service onboarding and engagement with the EFT team, because as an EFT team, we do not want to be a blocker or a bottleneck for someone in their flow. So my current role as a value stream architect helped me to spread the wings, and with the help of our EFT team, we presented to our business GMs, corporate strategy, and portfolio teams.

We hold every month executive sponsorship review, where we reiterate the commitment from the leadership team, we show them the progress, and we highlight the issues that we need resolution and support from. We continue to do learning and education sessions. Dr. Mik, John Willis, Nicole Bryan, Liz Fong-Jones: those were the people presented in our virtual continuous-learning brown bag sessions.

As we speak here today, we have close to 100 Jira projects' data ingested in our value stream tool. Here are a couple of screenshots from our Tasktop Viz tool: real-time visibility into the rate and quality of value delivery. That builds the trust needed for the true relationship between technology and business. As you begin to measure the flow, you need to also track the impact. When technology impacts on business results are made explicit, everyone starts paying closer attention to the value.

Paul Littlefair

Yeah, that is right. And look, if done consistently and across the board, it optimizes my ability as a leader to determine and have the right conversation with our peers, helps make the right decisions that deliver quantifiable and tangible business value, and allows us to rebalance portfolios and adjust investment levels to meet our goals.

As an executive, you have to have the power to shift the focus from short-term gains to long-term value. You need to make sure that people are working on the right things and accounting for the right things.

One of the things that we have found by putting flow metrics in is we have clearly seen a disconnect between our operational costs and our project or change costs. And what we have found in the organization is that actually, we are putting too much of our operational and run costs into our project delivery, and we have got a mismatch with our financial management of these things.

And the challenge, of course, that you have with that is that if your change costs are really high because you are funding your operational activities, then of course you are right for people to look and say, hey, as a benchmark, these are way out of whack with industry. We think we should offshore everything. And of course, if you run into those sorts of problems, you go down that strategy because the data is not showing you the correct things, and then suddenly it can lead to a whole lot of problems.

BMK Lakshminarayanan

That is right. It is not always a smooth ride. That is a great learning that we have got from this exercise. As we started and continue this journey, we have some great learnings. Now it is time to delve into some of this.

Right. What did we do? I would like to give you the eight key learnings that we have taken away from our experiment and the experience and practice.

Number one, aim high, but just get started. As Paul said, do not wait for everything to be perfect. When we engaged the teams, the first thing they asked was what they needed to change. Do they need to change the practice? Do they need to change the process? Our simple answer was, you do not need to change anything yet. Let us start collecting the data, model them, and learn from that.

Number two, ask for volunteers. Get their team commitment, because you cannot force or you do not want to force them. Let the data help them to see, believe, and then come on the journey with you.

Number three, we need to provide air cover to the experimenting teams, because you do not want priorities to keep changing or teams to be pulled in a different direction when things go in a hurry. So you want them to be really focusing.

And number four, this is actually a team approach. It is not just an individual as a value stream architect or a product manager or a product owner. You want the entire team to come into this journey.

And one more thing: please settle in, because this is what we have learned. Let the data flow. Let you learn from the data, because if you keep changing your Jira board columns and statuses and workflows and etcetera, etcetera, then probably you cannot rely on the data. Baseline and design an improvement opportunity. So once again: collect the data, model, and learn.

And number five, prepare for unlearn and relearn, because this is an interesting space and there are a lot of things that you need to unlearn and then you have to relearn. Gain insights, and do not be surprised or shocked, because it is your data. That is what you are seeing. As Paul said, one of the teams was 80% efficiency. The question was not about how to make them 100% efficient, but we all know that the data is not right.

And finally, learn to see, learn to improve, and learn to scale. The reason is because you cannot scale without seeing the improvements. You cannot improve without seeing the data.

Paul Littlefair

So I would just like to give you a summary of our presentation. We are a leading bank in New Zealand. We need to remain competitive in a rapidly evolving market. We have a full technology stack. You name it, we have it. Significant regulatory compliance demands, keeping pace with cybersecurity. We have to do more with less.

We reached out to the DevOps Enterprise community, and they helped us. They helped us understand the need for making work visible, measuring, and improving flow. We have not waited for the stars to align. We have got on with it. We have created value stream architecture, and we have introduced the Flow Framework into our system, and we have made it fundamental.

The insights the team originally saw have clearly demonstrated that we have some data problems, and they are now invested in addressing it. And we are at the beginning of our journey. We are learning to see, the team are learning to see, and we have incorporated feedback cycles.

BMK Lakshminarayanan

That is right. As an EFT team, what we do is we provide support with the teams, with the product discovery, value stream architecture sessions, flow modeling, and flow coaching sessions for them to interpret these flow insights, and we also provide the training. Let the data shape the journey.

Paul Littlefair

And we are already getting value from seeing. We are early in our journey, but we are already getting value. The teams are committed, excited, and engaged. We are seeing culture improvements because every engineer can now see how their work impacts on business delivery and helps to support an effective DevOps culture.

BMK Lakshminarayanan

Right, Paul. So what is our call to action?

Paul Littlefair

So look, I would encourage everybody to go out and read Dr. Mik's book. Embrace it. Embrace Flow Framework and flow metrics. Measure end to end. Learn to see, learn to improve, learn to scale. Reach out to the community. Talk with John Willis, talk with Mik, talk with Gary, etcetera. Read the IT Revolution Forum papers. They are a great resource for helping you on the way with your transformation journey. And share these with your colleagues and your peers. And finally, share your story with us. Share it with our community.

BMK Lakshminarayanan

That is right. As Gene says in The Unicorn Project: focus, flow, and joy.

We just started. We are in the learn-to-see stage, and this is how you can help us to learn more and share more with the wider community. If you are on this journey, we would love to hear from you, learn from you. How did you approach it? What did you see, and what did you learn from these insights?

If you are ahead of us in this journey in the learn-to-improve stage or learn-to-scale stage, please help us. Share with us what to look out for, best practices, patterns, and support. How are you approaching your value stream mapping and management? What exercise did you do to map your enterprise IT components, applications, and services to a value stream? These are really critical for us to learn as a community and learn together as an organization.

So we have benefited with people sharing with us, and we are delighted to have had the opportunity to share with you our journey and our story. I want to thank you. I hope it has been interesting, insightful, and inspires you on your DevOps transformation and improvement journey.

Thank you, programming committee. Thank you, DevOps Enterprise Summit and Gene, all the delegates, and all of our people who made this possible for us to stand in front of you and deliver this presentation. Kia mahi and kia kaha. Take care and stay well. Thank you.