Kimberly Grunow

Okay, welcome, everybody. Today we're going to talk about a more effective way to execute your DevOps strategy.

This will be an experience report. We'll talk through our experience and how we've tackled this. We'll go through who we are. Kick it off with Kim.

So my name is Kim Grunow. I am with Edward Jones, and I've been with Edward Jones for 25 years. I'm going to start by explaining to you a little bit about Edward Jones. It's a 100-year-old organization that specializes in wealth management and financial services across North America.

You might not know who we are, but I can guarantee you've seen our offices. They're everywhere. We have over 16,000 branch offices all over North America, between the U.S. and Canada.

I've been with Jones for 25 years, and the question I get asked most often is, why have I worked at the same place for 25 years? The answer to that, and I'll quote Ted Lasso, who is a presentation later on today, is: I believe.

I believe in the organization. I believe in the clients that they support, and I believe in being there. I believe in the decision-making process that they go through.

As we begin to talk through a lot more, you'll learn more about Edward Jones, the organization that both Alex and I work with, along with us in particular.

Alex Basa

All right. I'm Alex Basa. I'm a Dojo coach at Edward Jones, and we run a Dojo program called DoJones. Gotta be a little clever, right? Gotta have fun.

I have a technical background. I was a software developer for 15 years, architecture, did automation, got into coaching, and I just enjoy helping teams. I've been at Edward Jones for two years. We've started up a Dojo program, and we're using that as our execution wing and helping a lot of these practices and automation.

All right, so what we'll talk about today: we'll go through what we've done, upskilling, retooling. We'll talk about the pros and cons of different approaches, and then we'll get into business examples and tech examples.

Kimberly Grunow

So, the business problem. That's part of the reason why Alex brought me along with him today.

What we realized at Edward Jones a few years ago is that what's made us successful for the past 100 years is not going to be the thing that makes us successful for the next 100 years. I like to say that there are times where change at an organization like Jones is like turning the Titanic around. It doesn't really happen all that easily.

In 2022, it was publicly announced that Edward Jones would spend a billion dollars in transformation and changing our technical... It's a billion dollars in tech spend. It was earmarked and designated for modernizing our infrastructure, upgrading various tools, various digital initiatives. It allowed us to hire new colleagues like Alex, experiencing different ways of doing business with that.

But we all know, because we live in this world, that change like this starts and begins long before that public announcement of the billion-dollar tech spend in 2022.

This is my personal experience: everything changed, everything started to shift, in 2019. Everything started to shift. We began a quiet revolution inside of Edward Jones. We started to move from project to product. We started to move from waterfall development to agile development. We started to question everything. Lots of things that were givens in the past suddenly became not so much of a given.

In January of 2023, so just this January, the area that I work in, discretionary management, was born. It was created using lots of the teams that had already existed.

What discretionary management does is it is the asset and investment portfolio management systems for our discretionary management programs. For those of you not in the industry, what that means is this is when a client has entrusted Edward Jones with our money and says, "I want you to invest this money and manage this money for me."

We are responsible for over $800 billion in clients' assets under management, and over 37 million different clients trust us with their investments. What that means is we are high risk, high regulatory, and incredibly high volumes running through these programs and doing these things.

The new durable product teams that were put together in January of 2023 were a combination. They were a combination of long-term Jones associates like myself, who had been there for a long time, who bought in, who believed, and who took great pride in what we had already done, and felt very much like they weren't being heard in many cases.

And what we do is very important, and what we do is so risky. "No one understands." This is the thing that I heard over and over again.

In my career at Edward Jones, I've been on the operation side. I had helped develop these programs. It's part of the reason why they brought me back. And they brought me back in because they couldn't say that I didn't care. They couldn't say that I didn't understand. And they couldn't say that I didn't understand that risk and the responsibility, that heavy responsibility that you carried.

That's when I started working with Alex. I actually started working with Alex in some of the previous organizations I had been in as Jones continues to go through this process.

But bringing Alex and the Dojo into discretionary management as we started this work became instrumental to helping these teams transform.

Our business problem, as we start to make this transformation: Edward Jones is going through this transformation. We are taught to question everything. We're changing the fundamentals of how we work.

Those of you that have been through a waterfall transformation before, especially our developers, we're so used to having all the answers before we started with everything, before we started with anything. You have all of your level three requirements documented before you start doing anything. We're asking them to change everything.

So what we started to look at really was some of those core problems: modernizing our infrastructure. We had to do this to be able to be successful in the future while maintaining this high-risk, high-regulatory environment. New product and future development. The world changed between this time I'm talking about, 2019, 2020. The world changed for everybody, and we're in a heavy, heavy regulatory area.

To be quite honest, and to be honest with this group, it felt like chaos. It has felt like chaos as we're going through this. So I'm very proud to work with Alex to help change some of that chaos and really understand what's going on.

Alex Basa

So typically, as you're going through a transformation, the key piece is we have to transform how we learn. And so we'll get into this next piece on the learning pyramid. Some of you have seen it before. Kim's got a great analogy on it.

Kimberly Grunow

So here's my analogy for the learning pyramid overall.

You guys can see me up here. You can see I'm from St. Louis. That's where Edward Jones is. St. Louis is a baseball town, in case you're unaware. I've read books on baseball. I've watched any number of baseball games. I've listened to lots of baseball theory.

Does that mean that I can play baseball? Does that mean you want me to be the first baseman? Absolutely not.

So when I look at the learning pyramid, I think a lot about there's lots of things that you do that I can read a book on. I was certified in agile as a PMP years before Edward Jones ever did agile. Does that mean I know how to do agile? Absolutely not.

So the learning pyramid, as we go through this understanding and seeing how you do this: I can lecture, I can read, I can watch things, I can demonstrate things, I can lead discussion groups all on baseball, a sport I cannot play to save my life.

Alex Basa

So I've put in... some of you may have seen this 70-20-10 model. Many companies have adopted that.

The interesting thing here, maybe we'll just do a quick poll. Raise your hand if you've got learning capabilities or offerings that are in the 10%. So that lecture and reading, you have that option. Okay, lots of hands.

What about in the informal learnings? So these are like CoPs and workshops. Okay, still got quite a few.

What about the on-the-job experience? Okay, we've got some.

Now, one piece I'll highlight here where it's a little different from what we're doing is when we do the on the job, in our case, we are doing Dojos. A lot of what we are doing is executing on the existing backlog. We are not doing hypotheticals. We are not taking someone or a team to an area and going through some exercises, because a lot of times what they're doing doesn't apply to their real work.

So that's a little different than the level of hands-on. Then you get into: can you get to the point where they can become multipliers, where they start teaching others?

Kimberly Grunow

In many of this, it is about understanding what the challenges your teams are really truly facing. Like I said, we created discretionary management in January of 2023 using teams. We pulled resources from existing teams. We brought in new resources. We brought in lots of things.

So what were the challenges that we were facing as we put these new teams together?

Alex Basa

Okay, we've got the modernizing. So whether it's new tech skills, you've got all the DevOps tools and all the feedback cycles.

Sometimes some of the issues teams were facing was above the teams. Maybe it was a structure of how the teams were all structured together, and are there dependencies or code contention issues with how they were connected?

And then, of course, competing priorities.

Kimberly Grunow

So as the product manager inside of this area, competing priorities is something that is near and dear to my heart.

One of the stories that Alex asked me to share with you is, we're going in again. I've said I've been with Jones for 25 years. Competing priorities are there all the time. Like I said, we're doing things with modernizing while maintaining new product feature development, all of our regulatory efforts, all of the things that are going on.

Meanwhile, my senior leadership is coming and saying, "We want you to do these five things." I go into a meeting one day. They say, "Here are the top five priorities that we want you to do over the next period of time."

And the leader of digital comes in and says, "Your word of this year is no." He tells us this: "Your word of this year is no." And he makes us all practice it. "No."

And then he leaves, and the next partner comes in and says, "Okay, I told you those are the five things you want to do, but here's the thing I want you to do."

Did you hear his presentation?

So I stand up. I figured this is part of my job, being the veteran there. And I say, "We were taught that the word right now is no, and that's not one of the priorities that we were just told. So what gives? What do we not do? Because if you want this done, what do we not do?"

So as we start to talk about competing priorities, for me, a lot of it was very much making sure that the teams were incredibly busy and the work that they were doing was incredibly important. It's not about making sure that they're busy and really saying, "This is what we're doing." It's about ensuring that we're working on the right things.

So as I started to work with Alex and we brought the Dojo in, the right thing for us was to almost stop everything and say, "We're going to reskill. We're going to teach people how to do this better, and we're going to do it in a very specific timeframe."

Alex Basa

So we'll get into a little bit on teaching and learning. Thinking back to Grease, like we all know that, right? "I got skills. They're multiplying."

Are the people that we have that are teaching other people's skills or somehow pairing with them, are they really creating multipliers? And this is a really key piece.

So the way you can always look at that is when somebody engages, maybe it's an SRE engaging a team, maybe it's a tech lead or an architect. When they leave, does the team always go back to them for questions, or is the team able to now teach others and multiply?

Kimberly Grunow

So as we go into creating the culture of learning, as we talk about approachability and having that psychological safety, when we really started to do this and we put the discretionary management area in place, and I come back in and I start looking at this and listening, one of the things that I heard over and over again was the teams felt like they weren't being heard.

They had had agile coaches come in, and their agile coaches had said, "This is how you do agile." They didn't know what the teams were actually facing, what they were responsible for, what the risks and responsibilities they were doing. They said, "No, this is how you do agile. Stop whining. Just do it this way, and it'll all be okay."

That's not going to be a change that matters.

And we had agile coaches that left.

Alex Basa

Mm-hmm.

Kimberly Grunow

And we would get a new one, and the new agile coach would be like, "No, no, no, no, no. This is what you really should do."

So the teams had a very, very negative reaction and experiences to these things. And I'm seeing some head nods, because it feels like some of you might have experienced something similar in the past.

I always call it the connection between the academic world and the practical world. Here's how it works in theory and in philosophy. Here's how it works when the chips are down and somebody's got to fix it.

So for me, a lot of it was really building the psychological safety. Like I said, I worked with Alex in a couple of different areas. But with this one, having Alex and the Dojo come in, the first thing they did was they sat and they listened to the teams, and they talked to them of what works and what doesn't work. Here are some of the things that we really need to look at, and here are some of the things that there are some easier solutions for, and we're making it harder than it needs to be.

Alex Basa

So I'll briefly touch also on approachability. You can see who's approachable on your teams. Who do all the team members go to when they have questions? Sometimes it's not the expert. It's the person that's more approachable.

So think about that and the people that are going out, whether it's SREs or anyone else.

Psychological safety: if you're doing sprint reviews, does the team ever show a failure? There are all these indicators you can look at. Are we always showing successes? Can we say no?

We actually run a lot of workshops with teams and leaders where we ask them, "What happens if you say no?" And you'll get answers like, "Well, I might hear it at my review at the end of the year," or "I might not get more opportunities." You'll get a lot of insight into those kinds of questions.

Hands-on practices: having someone that's actually a practitioner. We've found our Dojo coaches, including myself, need to be someone that can get on the ground. Whether it's coding with the team, doing whatever, you're doing it with them. I'm not showing them a tool and how to use it. I will help them integrate that tool. I will help them in whatever environment they're in. We are both going to do it together.

Now you get into leading with empathy. So many of the times, you come in. If I come into a mainframe team, I can't say, "Well, you guys just don't know." They want to do the right thing.

When you come in with the approach of they really want to do the right thing, you need to listen and understand their space before you figure out how to help them. A lot of times, they know what to do.

So there are a lot of practices you can do, whether it's pairing, mobbing. These are skills that I feel now are required for anyone who is growing a skill set with someone else on another team. Before, it used to be just on the devs, but I think it's like anyone else, because they're skills where you can start building things in partnership.

So I'll jump quickly in. I'll give you an overview of the Dojo. We hear that a lot in the conference. It's not an acronym. It comes from Japanese. It's the place of the way.

A good analogy I like for it is think about Top Gun: Maverick. All the best fighter pilots go to the Top Gun Academy to learn how to become better as a team and elevate themselves from good to great.

It is not a fixer program. It is not a, "Hey, this team's really struggling. Take them to the Dojo." You also take teams from good to great.

We work in a six-week period because we are building muscle memory. The whole point of it is long-term retention. Thinking back to that pyramid, when we've done this working with teams, we've noticed that the retention rate for skills, practices, techniques has been 80 to 85%, 30, 60, 90 days after the Dojo. And that's how we measure success.

So one piece here, going back to the adoption curve, the key piece here is in the early adopters. If you are trying to get some kind of DevOps initiative going or any kind of initiative where you're upskilling, you really need to find the teams that have the willingness, that want to join it. A lot of times we just say, "We think we should go here." But if the team's not willing, you are going to be fighting them the whole way.

So to get out of the selling business and convincing business, I like to do a survey, and I ask them. I pitch the Dojo to them and I say, "Is this something you're interested in?" If they say no and leadership says, "Go help them," we don't go there. We go where we're wanted, and it makes a huge difference.

The ability to slow down for learning. Do they have a lot of big deadlines? Can they actually throttle back to learn as a team?

Learning goals. We do skills matrix. What are the learning gaps in the team? Do we have a lot of people with very specific skill gaps, knowledge silos? We'll measure those ahead of the Dojo and at the end and try and shrink those so people can get on vacation.

And then that muscle memory. Again, we're six weeks. So if you try one of these programs, usually the pushback is, "Hey, do it for two weeks. Do it for one week." We've found that six weeks seems to build that muscle memory. So that's the one we think.

And then measure long-term skills retention. When you're done, go back and see 30, 60, 90 days, are teams actually continuing that? And that'll tell you: is your approach effective?

The other one that's been a huge one: celebrating your wins. One big thing we've had is we've had the CIO send out an email with our wins, and it's really brought a lot of visibility. If there are any ways you can do that kind of thing, that can be a really, really big win.

Kimberly Grunow

One of the things that I think has made the Dojo ultimately very successful, particularly in the discretionary management area, has been they come in and they acknowledge the Top Gun analogy. I think it's very good because it comes in and it starts from the fact of: you are already great. You're already good. No one's questioning whether you're good at what you do.

It is that kind of recognition, and then it's listening. It's a lot of listening to, "Here are the challenges." The teams know. They know what's driving them crazy from an effectiveness or an efficiency standpoint. They know, "I would really love to learn how to do this, but I honestly don't have the time."

So it's creating that environment. That's part of my job, to create that space and to create that time.

So when I work with Alex, Alex starts with, "Can you give them the time to do this?"

Absolutely.

So whenever I'm challenging that leader who's coming saying, "Here are the five things that we said we're going to do, but I really want you to do number six," it's my job to say, "I'm not doing number six. I might not be doing number four and five, because guess what? I'm going to take six weeks, and we're going to figure out how to do this better. And then maybe I can do four or five and six. I don't know yet. We're going to figure that out."

Alex Basa

Now we'll just jump into testimonials. I'll just flip through them. I'm not going to read them. These are actual testimonials, unedited. We gather them from all the different roles that participate in the Dojo.

Kimberly Grunow

So I love Easton, but I do question the, "The Dojos have proven to be a way to speed up without slowing down."

That's not true. It's what Lee might believe because that's what he sees. But what he's talking about is he gets results. He sees the results of letting these teams...

A lot of what I have seen in discretionary management as a Dojo came in is the teams didn't realize how much power they had. They didn't realize, inside of this framework, it's way less of someone telling you exactly what to do. It's way more...

When they figured out that they could go from Scrum to Kanban, I thought they were going to dance in the streets. I was like, "Who told you you had to do this? I didn't tell you you had to do it this way." But that's what they had heard.

So as they're going in and they're working with Alex and the Dojo coaches, and they're saying, "Okay, hold on. Maybe your work is not this kind of work. Maybe let's talk about this other way to approach it in Kanban and to look at things."

We're a Scrum organization. I have to do things in a Scrum way, but that doesn't mean the teams have to be Scrum.

So as we continue to go through the testimonials that are on here, one of the things that I really like to see is these are from both the product side as well as the developer side. So understanding and seeing where the different teams are, and the Dojo comes in and looks at where that team actually is.

So in this one, they talk about mob programming. Mob programming is something that my developers were not all that excited to try. These teams loved it. My teams were not as open to it. So they didn't force it on those teams.

Alex Basa

Yeah.

Kimberly Grunow

They look at it and say, "How do we listen to what the teams actually need and really help them address their actual problems?"

Alex Basa

We also get to do hands-on. One of the successes you saw there earlier with Cental, he was a mainframe developer, and we said, "You know what? We're going to be hands-on in the Dojo." And he started learning Java.

We started mobbing. And when we're mobbing, it's not just technical people. The BA's in there with us. The product owner's in there with us. And as everyone's seeing how we're problem-solving and attacking a problem, everyone now gets a better perspective.

So in that particular case, he actually got to the point where he started coding in Java. They got certified, and now he can take on stories by himself.

So briefly touch on the results. These are some results we've had on Dojos. We typically do an NPS score, like, "Would you recommend the Dojo to another team?" So we do it at the beginning and at the end. Typically at the beginning, it's a little hard because we're trying to experiment a whole lot, and then it goes up.

Team health. Time to market really improves, because now you're looking at what things can we do in parallel, what skill sets do we need, and building for the long term.

Kimberly Grunow

Some of the other things that this... Yes, the Dojo is very focused on the developers and how the developers are working, but it's also given information for me to push back on my product owners, for me to push back on my BAs, on here's the work that my product owners have to get better at: that backlog grooming, in some cases the prioritization, understanding some of those things so that the team is much clearer on not only what they're doing, but why they're doing it.

Alex Basa

Here's another. I've had other people ask me, "Well, what about stability? Do you ever do a Dojo in stability?"

Sure. If teams are struggling with stability, that's the thing that's holding them back from feature work. So we'll say, "Sure. Well, why don't we do that?"

In this particular case, they had a bunch of dirty writes that were causing them to go fix. We were able to knock out 80% of them in a six-week time period.

Does that mean we're a tiger team? No. What it meant was we brought a lot of people that could look at the problem in a unique way together and solve it together. And a lot of those techniques actually helped with this. We were not the experts, but the way we attacked problem-solving and the way we got the teams to start looking at it that way really helped them with this.

Kimberly Grunow

So in summary, one of the biggest things for me is this fourth point: make psychological safety a priority.

Part of whenever I came in, the first thing that I did was admitted places where I had failed, admitted things that I was in the practice of learning. I've been with Jones for 25 years. I didn't know some of these things. I had to learn.

I've never been to a DevOps conference before. What are the things that I'm doing to learn, to continue to expand my own skills? Because that gives them the time to be able to say, "You know what? I learned about this, and guess what I learned? I don't ever want to do it."

I took classes to be a developer, and I learned that I don't ever want to do that.

So that's part of what that psychological safety is all about. It's about saying, "We're going to let you have the opportunity to try and to do things." And if you decide, "Hold on, I've learned about baseball, and guess what? Not interested," making that space for that. Or, "I tried baseball, and I am not good at it at all. I'm going to try something else."

So that psychological safety is key to really having a Dojo be successful for you, because the team has to feel like they're being heard, someone's listening to them, and that they have the ability to try something and it not work.

Alex Basa

And I know we're just about done. If anyone would like a copy of how we survey teams and leaders on psychological safety, reach out to me. Happy to share it. It's not a super-secret thing, but it has been very impactful doing it at the leadership level, doing it at all levels, and seeing how that safety rolls up and down is really insightful.

So now our ask for you. As you can see, we're continuing to learn. We've had a lot of wins. We're trying to figure out how to scale even faster. We're on these six-week increments.

We'd really love to learn: what has worked from you, what has not worked from you. Please engage us. You've got our LinkedIn profile codes there. Happy to engage anytime. I'm also on that Slack for the conference. Reach out anytime, and thank you very much.

Kimberly Grunow

Thank you all very much for your time.