00:00:02

My name is Claudia and I lead a learning program in one of our it business lines. Uh, the speed bumps program was, was something that I was involved with before. Um, for this current assignment and Scott Kellerman joined the team right after to be my backfill after I rotated to a different assignment. Um, our LinkedIn information is up here. So if you'd like to connect with us during the event, we we'd love to share what we've gone through, but if you think of something after the event, happy to connect with you afterwards, virtually. So just quick. Um, Hans does the group know what a speed bump is?

00:00:49

Like five people. Great. Um, so a speed bump is a friction in your SDLC value stream, and it's a friction that is very large and it's very difficult for teams to resolve it on their own. So it could be maybe like an approval process or a process that requires more than one team to, um, get a value stream completed. And it usually crosses many different organization. So it could cross security or compliance or your operations group or your tech group, et cetera. And so for us, as we're going through our DevSecOps journey, we noticed that all of these frictions or speed bumps were starting to surface our agenda for today is fourfold. So we'll share with you contacts about our organization, about Vanguard, our it group, and our, um, transformation. We'll share with you an analogy and we'll be a little bit like high level there, and that's deliberate so that the group has a framework and an idea to take back. When you go back to work, we'll get into our experience report and we'll get a little more tactical. So specifically, what did we do with a speed bump, a federal level speed bump, um, a friction point to resolve it. And this is like a recipe that you can take away and use for your own speed bumps. And then we'll wrap up with key takeaways.

00:02:27

All right, well, thank you, Claudia. Uh, so first we wanted to take a, take a moment to orient you towards, uh, the organization we work for. So you can kind of get a feel for, uh, the size and scale and the complexity of the federal level problems that we're dealing with. So we work for Vanguard. Vanguard is a financial services, uh, uh, company. It was founded in may of 1975. So in that time period, uh, the organization has a very strong culture. One of the pretty cool aspects about the culture is we have this whole nautical theme going on. So that nautical theme can be seen in the company logo, which is a big sailing ship. It can be seen whenever we get hungry and we go down, eat in the cafeteria, which we call galleys much like you would on a ship. Uh, additionally, it can also be seen when we are referring to our fellow employees, whom we call crew members again, just like you're on a ship. Speaking of crew members, Vanguard has over 17,000 crew members worldwide. So bottom line here is, is, Hey, this is a big organization it's established and it's not, not really a startup or Greenfield.

00:03:55

So let's take a minute and dive down now into the technology division of the, of the organization, the organization, the technology division has over 10 different subdivisions. Many of these subdivisions are aligned to different, you know, business products or lines of business. Others are shared service, it groups, platform, owning things, things that, uh, things that are core enabling functions of, of the different technology teams. So because there's so many different subdivision groups and they all have a lot of autonomy and different, different needs. They sometimes I'll act like individual companies, not to themselves, thus creating a little bit more complexity to deal with at an enterprise scale, the subdivisions across the subdivisions, we have four over 4,000 it or technology crew members. We have, you know, 4,000 crew members, 10 subdivisions, and that leads to a diverse amount of, uh, technology stacks, some more legacy and monolithic in nature, others, much more modern web services, microservices, CIC, D pipelines, cloud, native, et cetera, all told there's over 3,500 applications, uh, and growing rapidly.

00:05:24

So where are we in our DevSecOps transformation? Our agile transformation we started about 10 years ago or so. Um, so at that time, I think it was around 2008. Maybe we decided that we wanted to start building scrum teams and adopting agile practices and procedures. So along our journey, our leaders actually recommended that we all read this book called the founder's mentality by Chris Zook. Has anybody out there read founder's mentality by curiosity? All right, we've got a couple of people. So for those of you who haven't, uh, highly recommend this book again, it's called the founder's mentality by Chris sock. So in Chris's book, he has one key problem that he's trying to solve. It's called, or he calls it the growth paradox, the growth paradox states that as organizations grow, they do so in complexity as well. But the problem is complexity is the silent killer of growth.

00:06:34

So in order to combat the growth paradox, Chris outlines three key themes for organizations to follow. The first theme is to bring an owner's mindset to every level of your business. It's means to take ownership, fix the problem, and don't pass the buck and think somebody else is going to solve it. The second one is to have a bias towards action. What this means is that your default state of being should be to spring into action rather than to sit around and analyze things until maybe it grows into a bigger problem. Finally, one of the most important ones is to foster a frontline obsession. So frontline obsession is like Jeff visas is customer obsession, focus. It's, it's taking that and applying it internally on your own frontline employees, as organizations scale and grow, they might add additional levels of management, thus creating somewhat of a, of a natural disconnect between leadership and frontline, uh, and crew or employees. And by fostering that frontline obsession, we're able to bridge that gap just like again, you would do in a customer obsessed, uh, uh, mindset. Finally, uh, we ended up mapping our value streams as Claudia mentioned, and applying systems thinking the first way from the Phoenix project. And when we did that, we were able to identify these different speed bumps. And that brings us, that brings us to here today. And Claudia is actually gonna talk to us now about how driving is like software delivery.

00:08:32

All right. So remember, we're a peer right now where we're in this like strategic, theoretical perspective. So I'd like for the audience to think about the last time you were in a car, whether you were the driver or maybe you were a passengers and Uber, or maybe your Tesla drove you somewhere, um, for the next few responses, shout out what you love driving Speed stick-shift control Views. Okay. So having fun destination speed drive throughs, we joked about cup holders Movement, Right? To more Celebration, freedom, freedom, adaptive cruise control. I'd love it. Love it. Self-driving okay. All right. So let's, let's talk about software delivery. Now you might be leading software delivery teams. You might be a part of one, or maybe you really love apps and use software in your day to day. Think about what you love about software delivery. Shout that out. Instant feedback, Solving a problem,

00:10:27

Creating better,

00:10:29

Creating value, learn something new new features. Innovating. Say that one more time. Automation, happy customers, creativity. What was that one? When things work one from over here, I didn't hear that one. One more time. Hugs. You like bugs

00:11:07

Oh, I'll interpret that as a lack of bugs. And if Dave Enabling your customers to succeed,

00:11:24

Self-taught in the positive, all right.

00:11:32

Opportunity to come up with all sorts of crazy solutions to problems in the middle of the night, when you're half asleep,

00:11:40

Creativity, autonomy, independence. Okay.

00:11:48

So within themes that the group called out with driving and with software delivery, I heard things that were outside of these three, but what I was hoping to hear, and what I'm going to tell you about is team autonomy and independence, safety insecurity, and deployment frequency, or acceleration or speed. So what do these things have in common with software delivery and with driving? Well, you're thinking about speed bumps and frictions, and you think about autonomy teams really love to be autonomous. They like to have the independence to be creative and to worry about solving tough problems. They could delight their customers, make them happy, be creative and focus, focus on that. They also want to be safe and organizations really want, really want their teams to be safe so that there's not lawsuits security, outages, unnecessary fines, bugs, so forth driving. We like to be safe too.

00:12:55

We take that for granted, but there's a whole ecosystem with driving there's rules and laws and software there's quality gates. He controls so forth. There's enforcement, et cetera, deployment frequency, which got, gotta be honest. When we were preparing, we were talking about deployment frequency as our favorite, because it has to do with going fast. And I think if I was counting, right, I heard speed most frequently in the room. So if, if you're a team that's delivering software, you're a dev ops team dev sec ops team, and you care about autonomy and the independence to solve problems quickly as you can, to be safe while you're doing it. And to go as fast as you can. That makes sense for your business and the problems you're solving for them. When you get frictions in that value stream, it gets really frustrating. And so this is the analogy that we really want to leave with you to think about so that when you go back to the office later this week, or next week, you think about that as leaders or participants on teams who are dealing with this and to escalate it. So now I'm going to hand this over to Scott, to drive, drive this analogy a little bit further and add another dimension to it.

00:14:15

All right. So you're probably out there thinking if you're going through a DevSecOps transformation at your organization, that if we go ahead and we focus on evolving our delivery teams into high performance, high performing DevSecOps teams, if we focus on that, like a lot of the talks of the co at the conference, right, have been that we'd be well on our way. If we succeeded, we'd be well on our way to delivering customer and business value left and right. And you also probably be thinking that, Hey, we would be able to meet our business outcomes and, and, and we'd having really great engagement scores, et cetera, et cetera. All of that is true, but you're overlooking one key ingredient. And that's, if you're DevSecOps teams that you're building or highly performed, Lamborghinis are still navigating or attempting to navigate, and an aging infrastructure that hasn't been updated along with your teams, with policies, processes, and procedures that also haven't been updated. Well, you might not end up having, you might end up driving a Lamborghini and conditions like that. And on roads like that, the key takeaway here is, is that yes, we do want to focus on evolving our delivery teams in the highly performing DevSecOps teams, but just as important, we need to focus on our core, enabling functions within your organizations and modernize them along with your delivery teams.

00:16:06

Now, we're going to take a minute and we're going to shift gears and we're going to get a little more tactical and share with you an experience that we had trying to solve. One of those, uh, enterprise level of speed bumps at Oregon at our organization.

00:16:26

So the problem that we were trying to solve is we were getting reports from our delivery teams, that it was taking them weeks to get a new app set up. And this was a very counterintuitive thing for us because we are encouraging a lot of modern practices, a lot of modern architectures, one of which is creating microservices. And if you're creating microservices, you need the ability to generate new microservices rapidly and quickly. And so we were starting to see an anti-pattern behavior emerge, where we were creating mini monoliths because of this value stream to get a new app set up. So in recognizing this problem, we knew that we had to tackle it. And this is an example of how dev sec ops and moving to dev sec ops it surfaces friction points like this for us, this particular speed bump involved, a lot of different teams.

00:17:25

There was many, many handoffs, maybe 10, seven different departments. And six weeks, if somebody's manager was out of the office, Vanguard has tried to fix this several times. And the first time that we fixed it, we learned that from a culture perspective, we, in order to get traction on it, we couldn't just share the qualitative experience that teams were having with the pain they were experiencing between ankle biting, different people, different groups, to navigating the process. Uh, we had to show data behind it and not only do we have to show the data, which teams were capturing via value streams, but we also needed to connect it to our vision and to our strategy, because as you can imagine, and as Scott had shared in an enterprise environment with many different groups and teams and a lot of complexity and a lot of initiatives underway, it's very difficult to get alignment from everyone to solve for this particular challenge.

00:18:26

So connecting it to the vision and to our technology strategy was very effective. If we're trying to get to microservices and we have a process that takes us six weeks to get through in order to get set up, we're actually going against our technology and our strategy. And that really resonated in getting support from our senior leadership to stand up a SWAT team and a SWAT team for us is something that we created. And this included team members who are empowered from each of the organizations that shepherd a piece of the process in this value stream. So in our case, it was our platform teams, our operation teams, our security teams, R I M teams. And we also included the customers, which is our delivery teams, because we wanted feedback from them and to share their voice in how they would like for the experience to work and how it actually works.

00:19:25

And the types of challenges that they face once the SWAT team was stood up, we empowered them to go after an outcome, which they all shared rather than different priorities that the groups had. And we created a culture for the team that enabled the problem solving going after that outcome. They were applying a lot of two way empathy to both understand from their own perspective as a service team or a shared service group that is facilitating a piece of this process and shepherding it. And also from the client's perspective or a team, seeing both sides was really effective. It's very easy. If you're in a group that is siloed and it has been set up this way to lose track that delivery teams, can't go read service articles for every single piece of a value stream, because your step isn't the only step in this value stream.

00:20:26

There's more than one. In fact, there's 10 20. And that would take a lot of educating to get through that. And likewise, from a delivery team perspective, the two way empathy kicked in with understanding, why does this step exist? Is it shepherding a compliance or key control step? And that education was lacking. So when our SWAT team got together and they really evaluated the value stream, they challenged it. They, they challenged it with asking a lot of questions. Why did, why do these steps exist? Is this still a requirement in 2019? Or was this just something that evolved to be this way? And so in asking those questions, they could challenge should this approval really exist. Is this team's manager really care that I'm requesting this? Is it adding value? Can this handoff be consolidated? Can I upscale my incoming team or outgoing team with what I'm actually doing so that we make it faster.

00:21:33

And through D through doing this, they were able to come up with a recommendation, both for a short term and a longterm solution. So in the short term, their suggestion was to set up a concierge service, and this would be a durable team that actually owns this value stream, instead of it being spread across many different groups. So was a concierge service. They would help teams get through this, this complex process. Now having this in the short term, knowing how complex the processes was okay, as a stop gap. But in the long term, the team had a vision of creating a push button, start experience for delivery teams. They wanted for teams to be able to press a button for everything to be automated and to be set up. And so the recommendation there was to set up a durable team that would own this value stream and work on automating it.

00:22:27

So this is the team, um, it's most of the team represented, and this is after a presentation. We went out to lunch, um, not in the galley, uh, but at a restaurant. And the outcome that they were able to achieve is they took a six week process and they were able to get it down to one business day, just by way of following those steps, challenging it investigating. Does the step reflect a requirement that's still relevant in 2019? Can it be consolidated, can be eliminated? Do we need this approval? There's a lot of wastes that they discovered that we were able to get rid of.

00:23:07

So that was, that was both our high-level kind of strategic driving and, um, software, software delivery and how it's related. And then our tactical. So are our key takeaways. We have three and the first one is solving for the entire experience. So Scott show the picture of the Lamborghinis. We talked about safety, independence, and team autonomy, along with speed, and you can't just solve for any one of those things. And going on a dev ops journey is going to surface these speed bumps for you. In our case, we learned that we can upscale our crew. We can use new tools and bring in the latest and greatest infrastructure and so forth, but eventually we need to glue it all together by way of the value stream and the process that we're looking at, and that is what teams are facing. And that creates the whole experience for your delivery team.

00:24:11

The second is applying a founder's mentality. So Scott shared about the growth paradox and Chris Stokes, three takeaways to battling the growth paradox. That is an awesome book that really compliments the whole it revolution library. And we definitely recommend reading, reading it if you haven't already. And lastly is being mindful of your culture. I know that could be like a very trite thing to share, but for us it was, it was really the night and day of what got traction on solving this, this federal level speed bump has anyone try to solve problems like this before in their organizations?

00:24:54

Okay. Saw a few hands. So for us, when we've tried it before, we've, we've gone the route of current state, future state analysis, getting approvals, toll gates, et cetera, like very thorough approach. Uh, but ultimately what really got us the win is to recognize that we need to tell the story in a certain way, which includes connecting it to our technology strategy and vision, showing data from value streams, and also sharing the qualitative experience from the teams. So with that, um, thank you everyone for your attention and for sticking around, it looks like we have four minutes left, so we can take maybe two questions. And again, our LinkedIns are here. If you wanted to connect with us after a yes. Just wait for a mic. Yes. White shirt.

00:25:50

Thank you. Okay. Maybe. Okay. Thank you. Um, my, my question is in the rhythm and reasons Riley wanted to come here was, uh, to ask how you have approached, uh, this, this, this typical problem of you hire new talent. Uh, they come in and they present you a whole bunch of good ideas and they're met immediately with, well, that's not how we do things here. Right? What is your experience been with that? And, and I think it translates into a lot of, like, we've always done it this way. What's your been experienced about, about smoothing that or trying to get others groups to work with you?

00:26:28

So that's, that's a great question. Uh, in our case, we actually seek and value experience from new, new hires and crew members as diverse experiences and perspectives that we have to incorporate because Vanguard has a really great culture and people tend to stick around for a while. Like people love working at Vanguard. So we, we value that. And when we bring in new crew, we recruit them to very strategic locations for deliberate purposes so that we can invigorate change and fresh and provide a fresh perspective. So I think it, it comes down to having an honest conversation about demonstrating that I've heard what you've shared and also explaining where it fits in with where we're going and then planning it out.

00:27:30

Yeah. I think just to build a, yeah, just to build upon that, uh, you know, so part of going through a transformation is sending that message to your organization and delivering it in a thoughtful way that, you know, we do need to change, uh, and evolve. Uh, we can, uh, have the, the who, who moved our cheese, uh, paradox. And, uh, that is that message is out there and transparent right now in our, in our organization. So I don't really think that we've come across that too much because we're actively, like Claudia said seeking because that message is out there emerged. And our leaders are so transparent about we're going through. We have a, uh, uh, technology, vision and roadmap, and we're evolving. They know where we are, but they're very clear about where we want to get to, and our new hires coming into the organization, uh, can see that and are excited by, Hey, where the organization's going because of the way that the vision has been articulated.

00:28:39

Uh, we have time for one more question.

00:28:42

Could you explain a little bit more what you mean by value stream and how your SWAT team, uh, contributed to that or made it more efficient?

00:28:52

Yeah, sure. Do you want to take that one? Sure.

00:28:55

So when we think about mapping value streams, we want to be thinking about it from a customer experience perspective. So in this case, our customers are your, your development teams, right? Your frontline, you know, engineers. So treat them, treat your customers like, like you would, excuse me, treat your, your frontline crew or employees like you would, would customers, and really build that two-way empathy that Claudia had had walked through that we did in our experience report and walk through them using personas as an technique that you can use to walk through the end to end holistic value stream. That cross cuts the organizational silos that you have set up. So we call this it's, it's essentially, it's a developer journey or an engineering journey, uh, for any of these, these things. And that's what we mean when we say value stream. It's not just the pipeline. Uh, it would be your experience from writing from, I wanna, I want to create a new application until that stuff is finally and in, in your production environment. So that includes compliance controls and includes the creation of a new application test and build, et cetera. That's, that's the experience, the holistic experience that your engineers are experiencing.

00:30:25

Okay. So we're out of time. Thank you again for joining us.