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).
Chief Technology Officer, Bank of New Zealand
Value Stream Architect, Bank of New Zealand
Hello, greetings cut-over. We are bank of New Zealand, also known as . We are delighted to be here and chatting stage with inspiring leaders and successful transformation leaders, practitioners, and experts. We are sharing of a story banking on flow metrics. The why, how do we approach it and what it will 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're at the beginning and the early you can establish these metrics. The better off you're going to be. We are here on this global stage because of our people in New Zealand, we have a famous Murray proverb. 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.
I'm really excited to be here in 2019 summit. I remember Jean and Dr. Mick were asking for people about phloem 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 fare. Paul is an award-winning CIBO is successful transformation leader in leading and transforming complex technology units within an enterprise to be an high-performing one. He relentlessly focused on improving the flow and value delivery. Paul believes in leaders empower people and give them the capability and appetite to be curious, to take risks, experiment, and bring their best every day to work.
Oh, thank you so much. BNK 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, that dev ops 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 Kennestone awards for the last three years in a row. And the researchers 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 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. Neo banks, fintechs, and other disruptors are coming. We are well aware and we also have a 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's 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.
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 ATM's frontline, mobile lending managers, everything. We have a full spectrum of technology. We have a big stack. Front-end back-end 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, which predates the moon landings. We have legacy systems, batch processing, Cobell all those legacy systems, but we're also very committed to modern systems as well. So we have microservices, cloud, native expense 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 as a surprise, but we actually have to provide the levels of take that 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, where are my features?
Yeah, you are absolutely right. The NK. There's always the question. Where am I 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, backup disaster recovery. Oh yeah, of course, of course we need all that low 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 added 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 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 wanted to share this picture with, uh, with, with, with you all this. Isn't a picture that we've created for this slide deck today. It's 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 we 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 got 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 back in one team, you're going to have a problem. But
In a factory setting Spall, we could say the Intuit workflow, we can see how the workflows in the factory, who are the people and what activity they are working on. And that is a cue. 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?
Uh huh. Well, so 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 am often asked by 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 ended up breaking those promises and having to 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 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 forward.
Then it is an information Paul, the ears, old, long established plan within management processes, associated practices or metrics, 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?
So, yeah, so we, we, we did three key things, right? The first thing we did was we actually took out our, our PMO. I 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 would not help him. Um, basically they, they were just looking to drive individual projects through the system 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, the, the PMO was just trying to juggle problems.
Number two, back in 2018, we regrouped ourselves into technology to minds portfolios, kind of portfolios of value streams. And then we appointed head of pic and we introduced product management and product owner practices to own deliver the outcomes intimate. 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 have good financial management guardrails. And so we reached out into the agile community and picked up a lean portfolio management, right. Which really helps see the system as a S 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, uh, 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 hand in back in 2020. He did a six weeks engagement with us. And he interacted with the technology teams. He interviewed the whole 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've heard jokingly people saying even the wrong things are complex.
Yeah. The MK and look great help from John. I mean the dev ops 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, talked to Dr. Matt Kerstin, Gary Gruver, Nathan Harvey, uh, even Matthew and Manuel from the team topologies are just amazing.
I could not agree more. Paul. I owe personally so much to this DevOps enterprise community at dynamic learning community. That's what Ross Clanton rougher says. I have made so many connections learning so much from all of the speakers, practitioners, experts, and every delegate. Jean wrote a level at a two conference last year. I personally wrote my tributes to DevOps enterprise summit. We will remind competetive one Lee, if he can deliver business value, not just code changes. As John said, clearly we want to measure the Intuit. So you need to get better in measuring the right thing, not just commit to deploy.
Yeah. I mean, coding and deploys show speed measures, right. But does not measure the flow of business value, which is so critical. We also have huge amounts of fishes in financial services in the bank, right. We have process measures, people, measure service levels, level measures, and really what they show us is that we have a problem that we're not delivering the outcomes that our business once. 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'd 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, insert alive values tree. I've got value streams evolve over the time with learning, with feedbacks, with improvements and experiments, our power point or a Vizio 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?
Yeah, so I was really fortunate. I was handed a copy of a Dr. Mick Kirsten's book, project to product while I was on vacation. Uh, it's a great time to sit back and reflect and 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 associate successful.
Those of us who are in large enterprises, you know, 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. And we talk about them and us, and we move into this sort of feature factory and all the taker, um, issue. And so we really needed to bring that together. So, uh, I've handed the F uh, 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 Jed 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 going to be using flow metric. It is the basis of the way we measure our work.
So that's that's right. And the 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 down to see how did we approach this?
So as we embarked on our value streams, we asked an important question. Yeah, who's going to own and drive this right? So we have a lot of engineering teams in our bank, but to bring an introduce the change, how are we going to do this? And as a, 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, 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 influences 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, proceed stage experimenting, modeling, coaching a dozen teams in total, including teams from lending, cloud platforms, engineering and data. We approach the stage debate. We call it, learn to see, learn to improve and learn to scale. We stood up the beans at flow up the hub for people to connect, explore, learn more about it. And we provided actually a navigation guides. You can see that on screen, learn to see, learn, to improve and learn to escape. We held team engagement sessions. Very, we, we ran actually a campaigns to win a book of making workers, but 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 here, a blocker or bottling 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 GM's corporate strategy and portfolio teams. We hold every month, executive sponsors to review where we reacted the commit from, from the leadership team. We show them the progress. And also we highlight issues that we need resolution and support from. We continue to do learning and education sessions. Dr. MC John Willis, Nicole Bryan, Liz Fong zones. Those were, the people are centered in our virtual country as learning Brownback sessions. As we speak here today, we have close to a hundred year projects, data, our industry and our value stream field here are a couple of screenshots from our Tasktop is tune 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 develop, 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 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've 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're funding your operational activities, then of course, you're right for people to look and say, Hey, as a benchmark, things are way out of whack with industry. We think we should offshore everything. Of course, if you run into those sorts of problems, you know, you, you go down that strategy because 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 an old God from the six slice as we started and continuing this journey, we have some grit 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 taken away from our experiment and the experience 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 of a simple answer was you don't need to change anything. It lets 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 Billy.
And then come on journey with you. Number three, we need to provide an, add a cover to the experimenting teams because this team you don't want the priorities keep changing. Are they pulled on a different direction when things go inhibit. 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 the view learn from the data. Because if you keep changing your JIRA board columns on statuses and workflows and et cetera, et cetera, and then probably you, you cannot rely on the data baseline and design and improvement opportunities. So once again, collect the data model and then number five, put prepared 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 really 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 theme 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 say, 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 of New Zealand. We need to remain competitive in a rapidly evolving market. We have a full technology stack. You name it, we've 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'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 tomorrow access sessions, flow modeling, and flow coating sessions for them to interpret this flow insights. And we also provide the training, let the data shape the journey and where
We're already getting value from seeing with early in our journey. But we're already getting value. The teams are committed, excited, and engaged with seeing culture improvements because every engineer can now see how their work impacts on business delivery and helps to support an effective dev ops culture.
Right? So what does have a call to
Action? So I would encourage everybody to go out and read a Dr. Mick's book, embrace it, embrace flow framework and foam 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 mic, 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, an unicorn project focus, flow, and joy. We just started. We are in the loan 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're on this journey, we would love to hear from you, learn from you. How did we approach it? What have you see? And what did we learn from this insight? If you're ahead of us in this journey in learning 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 to whether 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 our billions of people who made this possible for us to stand in front of you and deliver this presentation. take care and stable. Thank you.
Unlimited users from organization
Jason Cox's SRE Playlist
Service Level Objectivity: Improving Mutual Understanding Through the Language of SRE Accepted (MediaMath and Google)
Adam Shake, MediaMath Source; David Stanke, Google