Banking on Flow Metrics – Bank of New Zealand Transformation Journey

Paul Littlefair is an award-winning CIO, a highly successful transformational leader in leading and transforming complex Technology units within an Enterprise to be a high performing unit focusing on improving flow, value delivery; He is a servant leader who believes in leaders to “empower people and give them the capability and appetite to be curious, to take risks, to experiment and bring their best every day”. As CTO, he is redefining the way Technology functions and bringing the Tech & Business together to achieve BNZ's goals - digital-first and human when it matters & enable technology to deliver customer outcomes.

BMK Lakshminarayanan is an inspiring and passionate DevOps Advocate and Value Stream Architect promoting DevOps, Lean and Value Stream Management practices. He also serves as New Zealand ambassador for the Cloud-Native Computing Foundation(CNCF), DevOps Institute and Continuous Delivery Foundation(CDF), and a Board Advisor for the Value Stream Management consortium(VSMC).


Paul Littlefair

Chief Technology Officer, Bank of New Zealand


BMK Lakshminarayanan

Value Stream Architect, Bank of New Zealand





Hello. Greetings, Koto Koto Kava. We are Bank of New Zealand, also known as BNZ. We are delighted to be here and sharing 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?


Yes, it's great to be here and sharing our transformational journey. And it's 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. We are here on this global stage because of our people in New Zealand. We have a famous Maori proverb, tangata, tangata, 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 2019 Summit. I remember Jean and Dr. Mick were asking for people about flow framework and flow metrics anybody adopting in the enterprise wide. Two years down the line. We are here to share our experience and learning. I'm also thrilled today to introduce our chief technology officer, Paul, little Fair. Paul is an award-winning CIO, a successful transformational leader in leading and transforming complex technology units within an enterprise to be in high performing one, he relentlessly focused on improving the flow and value delivery. Paul believes in leaders yam, empower people, and give them the capability and appetite to be curious, to take risk, experiment and bring their best everyday to work.


Oh, thank you so much. BMK, and it gives me great pleasure to introduce BMK here. BMK is a passionate value stream architect. He's a DevOps enthusiast. He's 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.


Thank you Paul. We are Bank of New Zealand. We are serving our customers over 150 years. We provide banking to full range of our customers from simple transactional banking, personal and home lending to individual and small medium enterprise customers through to complex borrowing and Forex facilities for commercial corporate institutional customers. We are part of National Australian 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've won the Stan 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 number of times, digital first human, when it matters, what does it mean to you as a technology leader?


Yeah, it's a, it's a great phrase and, and one we use a lot, um, 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 a huge burden of compliance and regulation as well. People in the audience in financial services will, 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's really important that we continue to have those human relationships with people. And so human where it matters, it's also key. But of course, as a technologist, I wanna support that with technology as well.


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


Yeah. So to talk about the technology at Bank of New Zealand, we, we provide the technology for the whole bank, the external systems, the online channels you've 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 date, which predates the moon landings. We have legacy systems, batch processing, cobalt, all those legacy systems. But we're 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's a fair amount of tech debt in there. And it may come to us a surprise, but we actually have to provide the, uh, levels of tech debt to our regulators. They are that interested in the technology stack within our industry.


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


Yeah, you are. You're absolutely right. BMK, that's always the question, where are my features? What are you delivering next? Where, where, where's the delivery? And, 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? Why would you even expect me to have to tell you that? And then I say, well, what about robustness and resiliency? You know, back up disaster recovery. Oh yeah, of course, of course. We need all that. Oh, risk management. You know, we, how about dealing with tech debt addressing defects? How about spending time on continuous improvement? And so, you know, we have that real challenge, right?


And we are totally expected to do more with less, 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 and activities. You need to address the bottlenecks and look at improving flow. So we understand this in theory. Um, and for those of you who've, who've ever had to lose weight, I'm sure you understand that, you know, eating better and exercising more are the key solutions. It's not difficult to understand the concepts. The thing that is really tough is actually doing it and making a tangible difference.


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


Yeah, and look, I, I wanted to share this picture with, uh, with, with, with, with you all. This isn't a picture that we've created for this slide deck today. It's, uh, a picture that, uh, we use a loss in most of our packs. And, uh, it's one I put together shortly after arriving here. Um, and yeah, one of the challenges that we had is that every time you needed to do something, people said to us, Hey, just add some more people. Just put in another team. If you've got a challenge, you've gotta a bottleneck. Just hire more people and push the work in. And we all know that. Unfortunately, that doesn't work. It doesn't matter how many teams you have. If all the work eventually ends up backed in one team, you are gonna have a problem.


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


Well, it's a good question because yes, when you go into a factory, right, you can see the work flowing. If you've 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 you know, I often ask for my teams, why, why do we never get the execs? Why don't the CEOs ever turn up? Why don't people come and see us? And I have to keep saying, because there is nothing to see. You know, if you're 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, we are blind. That work is, is is hidden. And one of the huge challenges is we, we quite often behave like order takers. And so because people can't 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'll ship, we'll deliver. And then of course we end up breaking those promises and having to, you know, apologize and, and, and we struggle with trust, right? Um, and we, we, yeah, we are just not effective.


So one of the slides I did want to put up though, to share with you is this, this concept of, uh, of, of roading and, and traffic flow. Um, and what we see quite a lot in our business is, uh, our exec teams sitting, looking at the road, uh, on the left hand side, right? A nice empty road. Uh, but they're saying where, where are, where's the work? Where are the things that are going on? It looks like you guys aren't very busy. I don't see much happening. We're spending a fortune on our technology. Why is nothing happening? And what's normally happening is, is, is down the road, we have a massive traffic jam. We have everybody blocked, um, and nothing moving forwards, right? And, and, and it's all, it's 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 struggled to move forwards


Then it is number information, Paul, the years old, long established plan driven management processes, associated practices, or the metrics, definitely not helping our digital first mission. I, 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?


<laugh>? So yeah, so we, we, we did three key things, right? The first thing we did, um, was we actually took out our, our PMOI have some great project managers who are, who are good friends. And so, uh, I don't want to come across as, as anti project managers, but our PMO, our project plans were not helping. Um, basically they, they were just looking to drive individual projects through the system and, and not looking at flow. Um, 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, uh, yeah, we, we were finding that, you know, 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 head of tech and we introduced product management and product owner practices to own, deliver the outcomes end to end.


Yeah. And then the third step is, look, we still needed effective governance, right? So while we removed the project management office, we still needed to align with corporate strategy to, um, have good financial management guardrails. And so we reached down into the agile community and picked up that lean portfolio management, right? Which really helps, um, see the system as a, as a whole made us look at our work and dependencies, um, introduced us to, um, you know, big room or incremental planning. Um, and, um, yeah, allowed us to move forwards,


Right? Using our DevOps enterprise connections. Paul and I reached out to John Willis, he happily offered the help. And in back in 2020, he did a six weeks engagement with us, and he interact with our technology teams. He interviewed over a hundred peoples 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 things. This includes putting time aside for improvements. In some organizations, I have heard jokingly people saying even the wrong things are complex.


Yeah, bmk and, and look, great help from John. I mean, the DevOps enterprise community is brilliant. We see passionate people, we see leaders from different industries, public government agencies, large banks, retail, e-commerce, et cetera. And everybody who's attending this conference, right, 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 Doc Dr. Mick Kerin, Gary Groover, Nathan Harvey, uh, even Matthew and Manuel from the, the team topologies, uh, just amazing.


I could not agree more. Paul, I owe personally so much to this DevOps enterprise community, a dynamic learning community. That's what Ross Clanton references has. I have made so many connections, learning so much from all the speakers, practitioners, experts, and every delegate. Gene wrote a level letter to conference last year. I personally wrote my tributes to DevOps Enterprise Summit. We will remain competitive one lead 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.


Yeah, I mean, coding and deploy shows speed measures, right? 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, right? We have process measures, people, measures, service levels, level measures. And, and really what they show us is that we have a problem that we are not delivering, um, the outcomes that our business, um, wants. So it was really important for us to go and find something industry proven that was really critical. We're very innovative in New Zealand and we like to solve our own problems, but some great thinking. Um, and, 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.


You know, let's fix Jira, let's get the restructure sorted. Let's get these teams doing, let's get this product shipped, right? And so often you spend your whole time waiting, right? Once again, you're 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, right? 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. That is right. Hence, we ended up in 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 the time with learning, with feedbacks, with improvements and experiments. Our PowerPoint, our Visio value stream map that 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?


Yeah, yeah. So I was really fortunate. I was, uh, handed a copy of, uh, of Dr. mc Kirsten's book, uh, project to product while I was on vacation. Uh, it's a great time to sit back and, and and reflect. And, uh, I, I read through the book and, um, yeah, it just basically blew my mind to be honest. And, uh, I came back and said, Hey, we, we just need to do that, right? It, 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, we just wanted to, to, to move forwards because for me, one of the most important factors is, is that alignment between technology and business. And you know, when you look at the startup world and the startup community, so often the technology is the business and they're highly, highly integrated.


And that's why they tend to move at such pace. And they're so successful. Those of us who are in large enterprises, you know, the bank with 150 year history here, we, we tend to end up with this concept of the business and the concept of a separate technology team. And we talk about them and us, and we move into this sort of feature factory and order taker, um, issue. And, and so we really needed to bring that together. So, uh, I handed the, the, the book to, uh, to a lot of my business colleagues. Um, I've used the language, um, and we've really brought the teams together. And the other key thing is we've shared with the business that we're making flow metrics core to our transformation. It's not just a project on the side, right? Every team in technology is gonna be using flow metric. It is the basis of the way we measure our work.


So that's, that's 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 VNZ. 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?


So as we embarked on our value streams, we asked an important question, you know, who's gonna own and drive this, right? So we have a lot of engineering teams, um, in our bank, but to bring and introduce the change, how, how are we gonna do this? And as, uh, as Deming famously said, every system is perfectly designed to get the result it gets. So how do we design our system? Uh, and so one of the key things, we created a new role value stream architecture. And, uh, 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're 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.


That's 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 stage way, we call it learn to see, learn to improve and learn to scale. We stood up the beans at flow hub, the hub for people to connect, explore, learn more about it. And we provided actually a 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, we, we ran actually a campaigns to win a book of making work, visible project to product and DevOps transformation. And we presented to cloud data analytics and product management community. We also made self-service onboarding and engaging with EFT team because as an EFT team, we don't want to be actually a blocker or a bottleneck for someone in their flow.


So my current role as a value stream architect, it helped me to spread the wings. And with our help of EFT team, we presented to our business GMs corporate strategy and portfolio teams. We hold every month e executive sponsors review, where we reiterate the commit from, from the leadership team. We show them the progress, and also we highlight the issues that we need resolution and support from. We continue to do learning and education sessions, Dr. Mick, John Willis, Nicole Bryan, Liz Fong zones. Those were the people presented, uh, in our virtual continuous learning brown back sessions. As we speak here today, we have close to a hundred Jira projects. Data are in, just in our value stream tool. Here are a couple of screenshots from our task of une 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.


Yeah, that's 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 a 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 found by putting flow metrics in is we've clearly seen a disconnect between our operational costs and our project or change costs. And what we found in the organization is that actually we're putting too much of our operational and run costs into actually our project delivery. And we've got a mismatch, um, with our, uh, 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 outta whack with industry. We think we should offshore everything, <laugh>. And of course, if you run into those sorts of problems, you know, you, you go down that strategy because the, the, the data is not showing you the correct things. Uh, and then suddenly it can lead to, um, a whole lot of problems.


That's right. It is not always a smooth ride. That's a great learning that we have, you know, got from the six slides as we started and continuing this journey. We have some great learnings. Now it's time to dwell into some of this, right? What did we do? I would like to give you the eight key learnings that we have. I know, uh, taken away from our experiment and our, the, the experience and practice. Number one, aim high. But just get started. As Paul said, don't wait for everything to be perfect. When we engage the teams, the first thing they asked, what they need to change, do they need to change the practice? Do they need to change the process? Our simple answer was, you don't need to change anything. It 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 don't want to force them. Let the data, help them to see, believe, and then come on, journey with you. Number three, we need to provide an air cover to the experimenting teams because this team, you don't want the priorities keep changing or they pulled on a different direction when things go in a heavy. So you want them to be really focusing. And number four, this is actually a team approach. It is not a just an individual as an 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 the you learn from the data because if you keep changing your Bo Jira board columns and statuses and workflows and et cetera, et cetera, and then probably you, you cannot rely on that data baseline and desire an improvement opportunity.


So once again, collect the data model unlearn. And number five, pre prepare for unlearn Unreal in 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's what you're seeing. As Paul said, one of the team was 80% efficiency. The question was not about how to make them a hundred percent efficient, but we all know that the data's not right. And finally, learn to see, learn to improve and learn to scale. The reason because you cannot scale without seeing the improvements. You cannot improve without seeing the data.


So 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've had 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've got on with it. We've created value stream architecture and we've introduced the flow framework into our system and we've 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.


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


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


Right Paul? So what is our call to action


<laugh>? So look, I would encourage everybody to go out and read, uh, Dr. Mick'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 Mick, talk with Gary, et cetera. Um, 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.


That's right. As Jean says, in unicorn project, focus, flow and joy, we just started, we are in the learn to see stage. And this is what, this is how you can help us to learn more and share more with 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 this insights. If you are ahead of us in this journey in learn to improve stage or learn to scale, please help us share with us what to look out for best practices, patterns and support, how you are approaching your value stream. Mapping and management. What exercise did you do to map your enterprise? IT components, applications, services, to a value stream. And these are really critical for us to learn as a community and learn as together as an organization.


So we have benefited with people from sharing 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 thanking DevOps, enterprise Summit, and Jean, all the delegates and all of our billions of people who made this possible for us. Stand in front of you and deliver this presentation. Kia Mehi and KIA Kaha, take care and stable. Thank you.