00:00:08

Uh, my name is Natasha Anderson and I am the software engineering practices. Thank you for joining me today on my talk, the art of practices. What happens when the tests, let me guess, hold up. Print team. And I are responsible for happy teams and individuals across the group. Get excited about and better at software engineering. So for some teams, we help them understand and implement modern engineering practices like DevOps or SRE. For example, for others, we help them expand on the adoption journey. Um, we work with the practice teams to, um, advanced engineering by collaboration. Um, my love for engineering staff did very early on in my life as a child. I spend most of my time breaking things apart just to understand how they work, um, what they look like on the inside. I love solving puzzles. I love building things. So the day I wrote my first lines of code, it was in basic of all the things I remember going home and, and declaring with as much certainty as any 12 year old could, this was it.

00:01:09

This is what I wanted to do. Um, and so for me, um, this was one of the defining moments in my life. And from that simple childhood declaration, um, I've since been able to come various roles in this industry. So I've coded, I've tested, um, I've trained and I've coached and the excitement and fulfillment, I suppose, that I get from, from doing the kind of job. I do always stems from being able to solve problems, being able to be creative and to, to connect with people. So as the engineering practices lead and they come every day with six seconds and mental gratitude, I suppose that I can dream up ideas and extraordinary bunch of people to bring them to life. I get to engage with and partner with like-minded people from across the group. And, you know, I think it's important for me. I see that my time here as an opportunity to contribute to the growth of my organization, to my country and my continent in whatever small way I can.

00:02:11

So what I'd like to do with you guys today is first of all, to share some of the foundations in establishing practices, the challenges we faced and the lessons we've learnt along the way. So in this section, um, what I'm going to do is just share what the, what the practice is, how we've defined it, a short history in terms of how we got here. Um, and an overview of our strategy to brief look at, um, some of the items that we've created in our Tupac, um, transformation journey has been well underway. And some key highlights include the implementation of the scaled agile framework journey to cloud, um, the huge amount of what they've done on, um, data science and machine then answer. When I joined in 2017, the bank had already been implementing, um, give ups and pockets of excellence was butting up all over the place open source was used.

00:03:07

Uh, so foxes and knowledge sharing sessions were commonplace. Um, even back then, how about practices perspective? Um, we had practices representing multiple domains of expertise and technologies that specific engineering practices, for example, development of quality engineering, by the end of 2018, the organization was ready to ship this to the next gear to the next phase. And one which led to the reshaping of an organization to allow telling me it's across the various lines of businesses. And it was at this time that we collapsed some practices into a single engineering practice. Um, and our role is to define what good engineering practices look like. So at a very high level, what the practice is responsible is for driving improvements of engineering methods and tools and techniques based on the lean and agile principles for developing metrics and measures to create visibility at an enterprise level for the state of engineering across the organization, but developing methods for chatting and growing, um, tend to individuals into the group for creating and building an engineering culture with engineers in the organization through continuous learning, through knowledge sharing and through platforms that allow them to evangelize engineering.

00:04:26

So my previous practice was the test automation and the research and development, um, practice. And that practice was collapsed as part of the changes at the end of 2018. So presenter point that I took on the new challenge of establishing the software engineering practice and with a brand new canvas to start creating this masterpiece piece, I began to ask myself, how will this practice be different? How will we make a difference? How will we make an impact helping with this organization forward? Um, and so in the first weeks being back in early 2019, but we set ourselves the exam question, how can software engineering be a competitive advantage? You know, going through the state of DevOps report at the time, looking at the metrics, it was research-based on Gardner and the accelerate DevOps for the modern into present this data. It's 55, the state of DevOps report, and then operating in the low it performance. irrelevant the distance between them and the elite in high. It quickly becoming very far apart. Yet we live in a world with the technology and the learning is available for us and already showed them what was possible. Um, and so with this, with this exam question, we then set out to, to look at what industry leaders are doing. And we asked us, how would these guys move it? How are the elite performers able to respond to being able to, um, implement changes?

00:06:02

And it was then that we looked at both it's continuous. So continuous integration, continuous deployment, continuous, nearest managing everything needed to be continuous. Whereas to be able to do that as an organization, we looked at some areas that we needed to make some shifts underway, but we needed to get away from these pockets of excellence to get into it in common. So for making shifts to continuous strive, we needed to shift the focus for our team from just delivering features to delivering real customer value, to get them to continuously ask, is this going to deliver real impact? And how would I know we all live in a sharing economy and we know that we go so much further with each other. Then if we try to go at this alone. So we needed to shift from seeing our suppliers as just vendors to partners, we can co-create and innovate with.

00:06:54

We needed to make sure that, um, the shifts in engineering improvement initiatives we're investing so heavily in, could be measured, measured, and could be visualized across the group. We needed to make engineering and aspirational singular identity. So rather than, uh, people in teams focusing on my piece for testing on my piece for giving on my database, whatever we needed, standard bank engineers to have a single identity of what it means to be a standard bank engineered, to be individuals with concrete skills. And finally the learning. Where's the fun. If you can't share and contribute that to communities that helped in giving you your itch. So we also have to do a shift. Your organization should be from being followers in the global industry to be global contributors and thought leaders. This was of course, you know, the dream of where we want to go and let us to putting together on a single piece of paper, our true north.

00:07:53

So we would realize our competitive advantage of translating business vision to value to our customer, but driving improvements in speed, quality and innovation, our adoption of DevOps and SRE cloud and agile we'll consider the three spokes in the spiel to get us there. So we worked closely with the agile coaches of programs, such as those that drive resilience, drive cloud adoption to move the entire group forward. And all of this is an engineering philosophy, engineering participation and engineering playbooks that supports this vision. The engineering practices is made up of the software engineering practice, knowledge management practice, the RTE scrotum, such liability and engineering tools practice. I says it collective is called the engineering practice. A philosophy that we put forward was make everything continuous, automate, whatever you can. We work from a premise of you build it, you run it quality is everyone's responsibility, learn, experiment, and repeat.

00:08:54

It's all about a learning organization. So participation for engineers comes from my team. For example, that coaches teams across the group, they need to be influences. So as part of a performance growth process, part of what we have is a piece that you need to be out there, cultural teams, you need to be taking playbooks according to these ones that we have over here, but also you need to be out there contributing to open source, becoming a thought leader publish. But if this participate internally in soapboxing deals influence the industry, I'll play books, policies, and standards, et cetera, cover the areas where we are building our organizational knowledge in these, what you call playbooks, which is how do we win. So how do we win an engineering through a standard, which is an outcomes based document, um, and living documents that we are continuously working at reviewing, updating and incorporating new practices.

00:09:55

What KPS can we share? So we can create consistency across the group. What guidelines can particular technical frameworks to link training engineering, maturity, playbooks for health indicators? What does, um, the recruitment onboarding process, et cetera. And then of course the engineering metrics and tools, which underpin all of this, this is how we went about establishing what the practice would be responsible for some of the philosophies and some of the things that we want to create. This was all still 2019. And by the let's say, February or so, so needed to recruit team. We still needed to put the engineering, go to scale, to get all the other practice leads in, in the team. Um, and since then a year and a half now we've been able to put together our toolbox for software engineering practices and consists of these areas. So the one that has been a lot more time talking to you about is our metrics dashboard.

00:10:57

So for the last part of the year, we went in and said, okay, if you're going to be implementing improvements, we need to be able to show that this is delivering value in your organization. And so we created what's called the DevOps dashboard and it really tells us I'll be getting better. Right. Um, then in order to be able to identify areas of improvement, um, we have a maturity assessment. Um, we have maturity assessments that didn't lend itself to improvement plans and roadmaps that teams can then leverage to be able to say, these are the capabilities I will work on to get better at engineering. And if I've configured my pipeline through the DevOps dashboard, then I will be able to visually see that my deployment lead time reduced does my recycle cycle time, um, and to help teams to be able to, um, get better, um, and to, um, you know, leverage up the lessons we've learned to other teams have learned.

00:11:59

Um, there's a series of playbooks. First of all, the overarching one is the engineering standard. Um, and then we have playbooks for, you know, um, tools that we have. We have playbooks that speak to specific, um, areas like SRE DevOps, um, and the whole lot of learning and development, which supports it. Now, when you put this toolbox together, one of the important things that we tried to do was to make it self service, um, in order not to be the bottleneck, I mean, we service the entire group. So in order not to be a bottleneck, what we did was we, we, um, looked at the toolbox and we said, okay, it can be facilitated by a coach, or you can now put it from the toolbox, which is about group sites, um, and be able to use the playbooks to be able to run a, an SRE deep dive in your area or, uh, a DevOps maturity assessment or onboard yourself to the DevOps dashboard.

00:13:02

So I want to spend some time on, on the topic of the dashboard. So when we were looking at bringing the dashboards together onto the question of, are we getting any better? Um, this book was based on the Gardner report, uh, um, measuring DevOps value as well as, um, underpinned by accelerate. Like I mentioned in Marco Herring's book, DevOps with modern engineer might enterprise. So at the beginning of 2019, what we did was we sat down and we, I sat with a few teams, um, our SAP team, our core team. And I said, guys, when you, when you look at, um, delivering features, um, how does it work? I mean, what's that line that you draw from when it's requested, um, to the time it's deployed into production. And this was the values team that we put together. A feature is requested. It's prioritized to the PI, it's put into the team debt backed up, you dev test, repeat it's marked available for release, and then it's deployed to production.

00:14:05

Um, so we, we did silicate for a DevOps score. What we will do is we'll measure two things. How quickly can we implement changes into production? And when, um, things go wrong, what is two changes or whatever? How could he, can we respond because you've been moving at an extremely fast pace in terms of where things will go wrong. So what do we do when they go wrong? So, um, the, the metric, the was, or metrics that we had here, right? Um, deployment, lead time release, cycle time, um, change frequency, throughput, um, MTD, MTTR, et cetera. Um, these were all based on the value stream that we put together. And, um, we then looked at how the organization was working and we looked at, okay. So if we took feature, request it to production, one of the things we realize is that we use it to, for planning our work in progress.

00:15:09

And we use another tool to manage changes as well as incidents. So how do we tie these two things together? And once we understood and we collected data, I think it was from around hundred and 50 or so teams in the organization, we were then able to create calculations behind that, to be able to save from the time a JIRA is created to the time it's released into production. If we could map that change request number, we could calculate that difference in time based on days. And so at the outset, um, we created an MVP, um, just putting data out of JIRA and using Excel and power BI. And we were then able to calculate quite a few of these metrics based on just Secura and an RMD system. Um, we then said, well, we need to be able to take this and ensure that it's, it's easy for us to be able to pull the data, to consolidate the data and calculate the rest of the metrics that may not be so visible here, like for example, pipeline coverage.

00:16:10

Um, and so what we did then was we, we looked at, um, tools and open source tools, and we had already been playing around with highchair, which is a capital one open source project for a while now. Um, and so what we did is we took that and we said, okay, this will be able to get us data problem-based remedy, uh, bamboo, et cetera. Um, lots of Bitbucket, um, bamboo nexus, um, exceptional. So we'd be able to pull that data and show the single pane of glass, some of these metrics, some of the metrics that we've implemented to dating to a deployment time, um, in which we both collect is predominately in Europe, where we source that information. And based on the mapping the teams do within the JIRA itself, um, we able to then calculate things like deployment, lead time release, cycle time, um, um, change frequency and throughput.

00:17:09

We do get from, you know, just the change requests that go through. Um, and in this initial view, what we then did was then we started to look at, um, the average time to pay a meantime to recover, which was, um, items already captured in our JIRA. So, I mean, you know, remedy, uh, incident management process. So we were able to bring that in when it came to the percentage, um, of, um, the degree of testing and release automation, that's where we changed it to pipeline coverage. Um, and that's where we've done, um, a lot of work to date. And in our degree of testing release automation, what we do is we look at a simple pipeline from source code management to, um, testing, to, uh, monitoring, um, security, et cetera. And we are then able to calculate how much of your pipeline is configured.

00:18:11

And so what you built or the back on top of Hydra is the ability for teams to then go in and, um, collect data or configure their data sources, um, so that they could then, um, so once they configure their sources, Hygeia is then able to translate that into data points for their team. What is interesting here as well is that we were then able to not only show these metrics at a group level, we could show it at a portfolio level we're right down to a team based on their application or a component in their application. Okay. So, you know, what we created though, is what we learned along the way. So what I'm going to go through is just some of the lessons we've learned and, um, you know, this task here, culture is your canvas for creating any engineering masterpiece. So get some of the lessons.

00:19:11

Number one, the most important thing of developing culture in your organization is leadership. So let's take a moment to just reflect on this picture here on this picture. You have author represented EDA and his image symbolized this very emotional. They put a dialysis, different emotions in us, right? Yet in this picture, that emotion that comes through is based on the work that I put in to make the experience real for us. And as leaders, we are the artists of culture in our teams. We set the piece in the course for any initiative, B transformation delivery, anything we were in a very bad space. The team, my engineering team. Last year, we faced the textbook storming challenges as a new team. We didn't know each other. We had very little trust in each other. So even though we had a group of really brilliant people as a team, and we were struggling to deliver, and at the time we engaged your coach and, and the words Mel left me with now, we, your brain tattoo leaders get what they deserve, leaders, get what they deserve.

00:20:22

Let that sink in for a moment. This was the lesson on what truly being accountable as a leader starts to me, I get what I deserve. So if I get stained, disengaged, just nonresponsive people, it's what I deserve. And what you said was it's because you're either teaching it or you're tolerating it either way, you'll get what you deserve. So in terms of getting the, getting the, the best in terms of implementing practices, yes, I have the leadership traits that I value as a leader and those that I respect, um, in, in those leaders that I respect as dead in bed. The first thing is that leaders inspire, um, during the interview process, um, when engaging with various senior leadership in, in preparation for this talk, it wasn't 1 45 minutes session that I felt challenged. I felt encouraged and I felt energized. And those three things is what makes an inspirational leader for me, that energy not only allowed me to get comfortable here today, to tell you my story, but also to be brave, to put myself out there, to contribute outside of my regular commitments, I will get me want to research and to learn.

00:21:42

It made me want to want to share that feeling with my team and those that I came in contact with, he does also connect that a bank is nothing like I've experienced is a place made up for network. And this network will help you get things done fast, and that I've learned, and you will clearly see it. If you walk past a, on any campus, is that there's an accessibility and inclusiveness of this network. And there's always someone willing to help or know someone who can help. And this extends to the seniors levels of each ship. They set the pace, they set the speed at which we go big passivity, be able to connect with people. The ability to inspire people is what gets us there, the introductions, easy and welcoming. Um, and they do this because they noticed that they serial learners and they action.

00:22:35

And therefore, because of the ability to learn and connect things, it actually offer us an opportunity to grow, which brings me nicely into my last point that you just outlined, you know, in his last days with us, my previous lead shared something with me that are offered to you today. He said, when your team succeeds, you succeed and it must all be their work, but there's so much to do. How can I not help? But more importantly, wouldn't I just be seen as a delegated rather than a contributor. Um, what I'd really be adding value. If my team did all the work, instead to me, Natasha, the best leaders I worked for spent their time investigating, reading, developing themselves. And if you went to present any piece of work, they would challenge you because based on that learning that holds strong points of view. And as a result, they modify the capability as opposed to if they just spend their time bed in delivery. So check your calendar for you, take your candidate as he does. How much time do you spend on expanding your, your thoughts? So Peter Sangha in a learning organization, uh, define the learning organization as a place with people continually expand the capacity to create the results. They truly desire. We knew an expensive patterns of thinking are nurtured. Aspiration is Steph peer with people are continually learning to see the whole reality together.

00:24:00

92% of organizations are more likely to innovate. 92% of learning organizations are more likely to innovate in the industry. 58% are more prepared to meet future demands. Yet only 1% of an employee's work week is dedicated to training and development. So the five steps of a learning organization was defined as most personal mastery, mental models, shared vision, team learning and systems thinking and how we've implemented. This is first of all, clarity, um, our team's Kia on what they need to achieve. And do they have a realistic perception of how to get there? Continuous learning for us embedded in our performance, which is our performance management process, um, in the form of something called $200 blood. So when we set out our goals for the year, my team, and I use it as an opportunity to reflect on what we are working towards in the team in terms of the organization goes to the, of course, but also what does success mean for each of us personally?

00:24:59

And this year, the Christian I posed as we were setting the scene was how will the organization know that we will? How will you feel your modesty? How will they feed your team? And for my team and our personal development is intertwined and infused into the goals that we have, um, the outcome being impact that we want to have in the organization, having a clear target of 200 hours and specific areas. We want to tell that as a team, in terms of the benefits, such as our card certification security, et cetera, provides us with a shared vision clarity, and also attracting outcomes, and also a split of the, of capabilities across the team, uh, teams, I suppose, uh, supported through platforms, um, that support either self learning, formal training, um, changing partners of classroom training, as well as informal learning, um, and experimentation through, through hackathons or through gills and masterclasses.

00:26:00

Lastly, experimentation is part of the learning process as Spotify test automation practice, for example, practice Fridays were days to show up and to showcase, um, to list out any kind of problem we're facing in individual teams. And what together, how many of your teams would, would jump at a chance of learning if you, as the leader suggested the appropriate materials and courses, the research suggests 75%, what degree of importance do you think your team places on learning and development as a factor of happiness when you have inside the team, then number sure as high as 94%.

00:26:42

And so find me a culture perspective. The last piece that I want to touch on is safety. So have you ever tried to get anything done when you felt anxious or uncertain or feed, how would you rank your productivity or ability to improve dismal? Right. So just take a moment to think about where we are as a society, the pandemics that we are facing, COVID this social injustices that we see around us. Um, you said China times, and we know that the downstream effects are going to be felt years from now. People need to feel safe now, more than ever. And it's our job as leaders to make sure they feel included. If you're safe to challenge, to learn and to collaborate. Why? Because if people feel safe, that they feel that the I included that they have considered the need to feel safe, to charge, debated, to challenge it, collaborate. And I've seen firsthand how, how engagement and outcomes achieve skyrocketed as a result for us. How did we get this? There's some lessons that we learned, for example, don't name, um, don't talk, Tom. Don't tolerate, I don't interrupt each other. If things get too, long-winded the client, your next steps time box, but commit be curious about feedback and other people's inputs.

00:28:09

These will take on different levels of complexity depending on your team. And I must admit working with a teammate of dad's a lot easier than a rock star subject metrics, but the sticks, I guess, a higher for being vulnerable, but this is our job as a leader, it's to have our thing on the pulse for teams to watch book by nudge for input, to make time, to create charity, to reassure when mistakes are made and encourage team, um, to see it as a learning experience. So the last piece that I want to share with you here is a piece on, on Mosty, right? So I first heard about, um, I came across 10,000 hours when I, when I did through Malcolm Gladwell's book outliers. Um, and you know, one of the things that I found interesting was DEC, uh, geniuses made because they genetically predisposed or they created because they put the hours in and what follows was 10,000 hours to make you an expert in anything.

00:29:08

So with these cloud, continuous integration, data science, scrum spending, the time learning spend the time experiment, there's been an attempt to understand what works for you and your team and what doesn't work for you, um, will be, you know, when you do this, you'll be able to make the headway and succeed at overcoming almost any challenge you set out to. And I hope so far that you've seen that the, the importance of making time and space for, for the team and for individual learning is again, may tear. And it can't just be about new features to production. It has to be about what are you doing with your people to help them to be future-proofed for the challenges that lay ahead, it had any of my final thoughts to you. I'm going to summarize with this, right, as a leader, it's our job to make sure that there's a spot in the eyes of our people, right?

00:30:00

Uh, it's our job to make sure that they feel safe. The next thing is that there's no better time for engineering to rise up and take your teams and organizations turn the devil. And it's a leverage tech use, open source report and metrics that matter. Lastly, keep expanding your skills. Um, and he's talking on your supplies to your network, through your learning and through your curiosity. And finally, um, I love this quote by getting Schneiderman. And he said, um, you're not even she combined art and science and the statistics and engineering and that kind of unity is needed once again. Thank you.