Agile Coaching for Winning Teams

Transcript

Host  We have Allison Pollard, who is going to be doing a presentation for us today on coaching, winning agile teams. Alison and I have known each other a while. I’m really excited to have her with us today. And you’re gonna love this presentation. So Allison, I’ll let you do further introductions of yourself. And I’ll hand it over to you.

Allison Pollard  All right, thank you. Yeah, I think you and I, like got started in the Agile community and like, you know, really contributing back many years ago. And so it’s like, Wow, look at us now.

And I’m excited because obviously, you know, Sheree and I both have, you know, work together, we presented together, but now I get to talk to you all a bit about what I’ve been doing, and thinking about recently and this topic is coaching. Winning agile teams, partly inspired by a blog post I had written previously, comparing agile coaching and sports coaching. So for today’s session, I really want us to kind of talk through what is a coach role with agile teams. Because a lot of times there is the comparison to a sports coach. And there are some things about that metaphor that I think work really well. And there are some other parts of it that might be kind of confusing for folks. And also, if I’ve described, you know, hey, we want to have agile teams that win. What do we mean by that? And so I want for us to be able to explain what winning is for an agile team by the end of the session. And I want to share and an outline of a particular model that I have found really helpful in coaching agile teams. And so by the end of this you’ll have a couple new models to work with and be able to describe things you know, bit more Clearly for the teams that you’re working with.

So a little bit about myself, I am an agile coach, I actually worked for improving a large consulting and training company, and I’m one of the technical directors. So I lead our agile practice across all of our offices. That means I’m working with our internal, you know, practitioners on how they’re better developing themselves and delivering for our clients. But then certainly working at some of our large client organizations and helping their leaders and their teams gain agility. And so I’ve, you know, gone through quite a bit and my own self learning and my self journey around you know, becoming a better agilus becoming a better coach. I’ve gone so far as as you know, going through professional coaching certification. I’m a certified professional co active coach. So I bring a lot of that background into what I do. do when I’m working with people. Now I wanted to find out you know who was in the session with me. And so either unmute yourself or type something into the chat. I’d love to know what is your role in your organization today?

Participant  Mostly Scrum Master

Allison Pollard  Scrum Master. Yeah, I see a couple other Scrum masters in the chat here. We have a coach trainer, another coach, product owner. We got some release train engineers. Couple more senior Scrum Master awesome senior ba so got some business analysis going on. Scrum Master Operations Manager Wow, I am really digging the diversity of this group. We got program management. So a pretty big variety of roles. that are working with teams.

And what I love is that it’s not, It’s not just like one person or one particular title that is responsible for coaching a team. We have someone that’s a Delivery Manager and Scrum Master, we have Scrum Master and POs who wears multiple hats. Regardless of what the title is, I love this. I don’t love calling myself a master. Because if I don’t have the 10,000 hours experience, right, the mastery that comes with that any single one of us are working with teams and we are trying to help them deliver better for their organizations and for their customers. And so it doesn’t matter exactly what your your job title is. It’s how you interact with the team and the things that you can help them to see and what you can help them to do that really make you an influential leader.

So when we think about the sports coach, you know, most The time that sports coaches off on the sidelines, and in a lot of ways that that applies to agile coaching, in the sense that most of us are not hands on embedded within the team, and also delivering the product with them. So we’re not writing the code, most of us are not testing it. You know, we’re not in the really deep architectural, you know, conversations and decisions that are happening.

Now, some of us, you know, are further away from the team than others, you know, people that are more like the scrum master or business analysts, product owner, you’re probably there on a day to day basis, listening and facilitating maybe even guiding the conversations that the team has. And so here, you know, we have the sports coach that is helping the player to like see some things and maybe even like thinking out the next play, and working with the person, you know, in a much more tactical manner and others have us you know if you’re like the release train engineer, Delivery Manager, agile coach, you might be interacting with the team less frequently and possibly looking at some things are more strategic in nature.

Now, when I first wrote the blog post around this it was because I found an old video that inspired me. So John Whitmore, professional coach, he’s written quite a bit in the area of professional coaching on you know, how do I coach someone like through their life? Or how do I coach executives for their presence and how they’re making business decisions? Or how might I coach a leadership team, for example, all these different areas. He had done a demonstration of how a coaching approach could work with someone trying to learn tennis, and they had a comparison of his interaction with a new tennis student, and then showed alongside what a traditional tennis coach was doing.

So the traditional tennis coach and for most of us that have played sports, this might sound familiar. That person is telling us like, how do you hold the racket? And and like, like, what is your swing? Like, and like, how do you need to hold that? And like, follow through on it and like, where do you, you know, feel it in your body and kind of, you know, like, connect with where the ball is. And as you’re like listening to that instructor, you’re thinking, gosh, this is this is so convoluted and like, so hard to follow. You know, it’s like, I have to think about like, where my fingers are on the grip, and like, like, what’s my wrist? Like, you know, like, how far back does my arm go? Like, what’s the angle that I have it at? And now like, I keep all of that in mind as I like, make a motion. Like oh my god, I’m so in my brain. And John Whitmore, instead, ask this student, you know, pick up the racket, and swing. And what did you notice? As you know, swung that racket that tennis racket, and like, Where did you feel it in your body like, like what connected like what felt kind of awkward. And he’s bringing your attention to the experience of doing something. And as they continued on with the sessions, and you know, this demonstration, you realize that the tennis player that John Whitmore is working with like, she’s kind of excited and she feels more ownership, you know, like she’s more actively involved in the process of learning tennis. And she’s like, making sense of it like from from her brain down into her body of what is this like, and and feeling more confident as a tennis player.

Whereas the person working with the traditional tennis coach, still kind of stuck in his head trying like really hard to connect it down to like, how does this play out in real life and probably moving at a bit of a slower pace in comparison And I thought this was really powerful as a metaphor, because how are we as agile coaches, helping teams to connect to the experience of doing software development of actually delivering? You know, more often than not, we don’t have the luxury, nor do I think we have the desire to say, you know what, we’re going to go learn over here, we’re going to run like practice drills. And we’re going to do that for like, a really long period of time. And then you’re going to move into your actual project and try to apply all those skills in the moment.

Instead, I think most of us recognize, like, not only would it be hugely expensive to pull a team aside, and instruct them and like do all this like practice. You know, like there’s an opportunity cost to the actual product that they’re supposed to be working on. There. There’s the idea that you know, is that stuff from like a classroom or like practice setting going to translate into real life and like, how would we know or not That I think we know like we come along the sides, the team where they are in the actual product or in their project that they’re trying to work on. And that’s why we’re asking questions and retrospectives or making sure that there is a retrospective, you know, maybe we’re trying to facilitate planning a little bit differently. We want to draw the team’s attention to certain areas, and have them better connect, what is it that they’re doing and why are they doing it? Because we might get stuck in. This is just the routine. And this is just what we normally do. Now, if we as coaches act as though we’re on site trainers, and we’re telling people what to do at any minute of the day, we’re going to get stuck, that team’s going to get stuck. And I’ve seen this a few times in my career. How many of you have had the experience where you come to a team and they say, well, we do this because that’s the way that the Agile coach told us how to But that agile coach has actually been gone for a while, or the team no longer remembers why they do things, the way that they do things.

I’ve had the experience of, you know, starting to work with a team, and they couldn’t describe to me like, why they followed the process the way that they did. Some of it came from a previous agile coach who had been gone for some time. And they they stopped thinking, and I find this kind of scary, you know, if I, as a coach, I’m too focused on framework execution on how do we have a daily standup or, you know, like, what are all the checkboxes of how to do an iteration planning or sprint planning, the team might disconnect from the experience and they just start going through the motions.

And to me, it’s like taking real human players and turning them into foosball. You know, like little models of you know, players but Someone else’s like cranking those wheels and like turning it and getting them to play. But they’re just following our direction and not really connecting and they don’t have the autonomy of how would I do this on my own? or What does it mean for us to follow this direction? And like, how did they know this was the thing to do? So, in order to keep us in the land of having real players that make decisions, I think we have to remember like there is an element of us always being on the sideline, that I could yell at you from the side and say, Ryan, Ryan, and I kick that ball. But if you see a different opportunity, and you’re the one that has the ball, you have the ultimate say you have the ultimate determination in what the best path is.

And perhaps there’s something about their position on the field that enables them to like recognize an opportunity and go for it that I am not privy to from My position on the side.

And so when I think about what does the team, you know, like, what’s this game that they’re playing? And certainly like, how do they know if they’re winning or not? I found this great quote from Diana Larson, one of the co-creators of the Agile fluency model, and she describes how a high performing team creates high performing products. And this idea that this is a team that is delivering what the customer wants, what they’re willing to accept, and what they’re willing to exchange value for. So that customer is willing to either provide some information or provide you money. And that exchange from the customer is what creates value now for the business.

We’re able to, you know, say that we’re earning more dollars or we’re saving money, maybe there’s more loyalty, more engagement from our customers. That helps us, you know, in our in our business in a meaningful way. And these customers are willing to do this in it like we’re willing to create a product for them that suits the customer’s needs. And so we’ve created a product that’s easily maintainable. It’s supportable after deployment, and we do it in a way that leaves the team members ready and eager to work on the next deliverable. And I’m going to pause right there because I want to hear reactions to that definition of winning.

Host  So everyone, you do have the ability to take yourself off from you. Um, if you want to contribute

Allison Pollard  Any thoughts? There’s a lot in there.

I’ve stunned y’all into silence. Yes.

Participant  My hand into but I’m not sure. Yeah,

Allison Pollard  yeah, Lucy.

Participant  I like that line high performing teams deliver high performing products and have to also include the after sale element of it that it comes back and that is part of the loop. There’s sometimes we’re in a cycle of just delivery, delivery delivery, but this glue back and continue. Mm hmm. I find that I guess one of the struggles I’m having as a scrum master with my team is the number of steps between us and the customer. Mm hmm. clear vision of Are you happy with what we’re, we’re doing right now. So I look forward to hearing more about that.

Allison Pollard  Yeah. Ah, yeah, that’s a very real challenge. I sometimes think in large organizations, especially, you know, I think about, you know, it’s like six degrees to Kevin Bacon, like, how many degrees until I can get to a customer? You know, like, how many layers removed? Are we? Is it six? might we get to Kevin Bacon? Before we get to a real customer? I don’t know. That would be concerning to. And you’re right, like, we want to check for that feedback loop. You know, I, I’m a consultant. So I’m usually brought in when things are not going well. And sometimes the not going well is we’ve been deploying pretty regularly, but our customers are now telling us like, please don’t give us more stuff, you know, or like, hold off on deployment, like we don’t, we don’t want it.

And that often speaks to quality issues that have been, you know, festering for a while that maybe we’re delivering the features but there’s a number of bugs or the the actual deployment process itself. requires like so much downtime and, and causes like new learning, you know, new work processes from the customers themselves, that they say like, I’m not ready for that I don’t have the appetite for the downtime, or I don’t have the appetite to like, retrain all of my people, or for us to have to configure, say, like other reports or other processes that might exist, you know, based on what we’re putting in the hands of them at that point in time.

And so this idea that, you know, I not only want like the development team to be like, eager and ready for the next deliverable. I want the customers to be as well. John has put in the chat, you know, I’m a big fan of identifying a difference between success and performance. And you think this idea connects a bit to this here. And I think you’re right, there’s performance in terms of like, how are we you know, interacting on a day to day basis and and what are we doing and then there Like real big gains and wins, I see another hand in the chat.

Participant  So during my teenage years, I was into swimming and competing. And from that experience, I learned that the definition of when it was to do better than before. Keep on that journey, on and on, always in net never moving backwards.

Allison Pollard  I love that that is definitely going to connect with some things we talked about a little bit here, for sure.

Yeah, so I find, you know, like we said a moment ago, as the team is disconnected from actual users, and being able to interact with them or being able to, like close that feedback loop. In other cases, I feel like teams don’t even have an awareness of like, there are actual people that use the product. I actually have been talking to a group recently. They are, you know, an enterprise data set of teams. And when they talk about their vision or their purpose, they describe and building this amazing data platform like this is going to be the end all be all data catalog that any analyst you know, in the organization can come to this catalog and search through it to find it the exact information that they’re looking for. And it’s been like really fresh, and you know, like really clean data. It’s gonna have all this like historical information as well, that you can pull the reports that you’re looking for, do your analysis and make a decision has a positive impact towards the operations of the organization. So like really big dream, like kind of vision.

But where I find them getting stuck is that they’re so focused on the platform, that there’s a lot lot that goes into the architecture and thinking about the scale of the architecture. And there’s so many different kinds of users and so many different use cases that we already get kind of like weighted down by just like how massive this effort is that when we instead shift to Who are the people, like who are the actual users of this system? And can we have them walk us through what they’re doing today? Because obviously, the organization is making decisions right now. They’re making the best that they can with the information available, you know, we’re wanting to enable them to make better decisions or more timely decisions, perhaps, like more accurate decisions because of the information we’ll have. But how do we connect to like, how do I make your job better by Friday? Not how do I build this amazing platform? Maybe in six months from now? And that’s a really different paradigm for people to connect with on doing something that’s very technology and like product, not for the sake of product oriented, the way that we describe it versus who are the real people and their jobs or their goals. And what does it mean for us to focus on improving that, you know, as quickly as we possibly can?

So one of the models I wanted to share with you in trying to figure out like, Where’s your team today? And like, what might winning mean for them? I like the Agile fluency model, because it acknowledges there’s not one right way to do agile, there’s a variety of ways. And I like that this is in here because as I thought to the sports metaphor, there’s not one way to win at soccer, or baseball or hockey other than you probably need to score more points. But even they’re like they’re scoring more points or being really good at defense. If you can, like do just enough on the offense that you I guess, score like two points, but I’m really strong at defense, I could still win. Or I could be so amazing at scoring, that I just like rack up the scoreboard like this for a really large number, that my defense doesn’t even matter.

You know, in some cases, most teams are going to find there’s a balance, you know, on how they play the game, and that it’s the individuals like connecting as a group and figuring out like, what is our focus, like, what is our purpose collectively? And how do we use one another skills so that we can be effective in the game? That’s that like team shift, right? Like we are now a group then we’re going to work together. And this and the fluency model is like the team culture shift. That takes us into focusing on value.

So now we’re thinking about, like, what is value to our organization or what is value to our customers and we have so level of transparency that we’ve created in our environment most often than not, this means we’re working from some kind of a product backlog. It’s using something like user stories. So it’s in the language of business and not in technical tasks, you know, or like architectural pieces. It’s something that our stakeholders can understand and help prioritize for us. And we’re going to have some regular demonstrations of the fruit like the work that we’ve produced.

So focusing as the first you know, zone where we see some benefits from agile. It’s not the end all be all of what organizations need in most cases. So there are multiple types of success all are valuable. Well, the next state or like the next zone that we think about is where the team skills have developed. So instead of like this is a pickup game of soccer and we just started playing in the street. Like we have been practicing. And we have been working on like, how does how does each person like play a certain position, and maybe like run through some plays together? in software, this might be like we’re learning some of the technical practices and like, how do we test our code together? How would we deploy it into production, that now we’re able to deliver regularly, so delivering? You know, I’d like the release, it will have software. And this provides great benefits.

This is what’s going to get us to sustainability as a software development team that we’ve deployed to production. And we’re still excited and have the energy to talk about the next release after that. This is not the old days that I know I encountered as a project manager. We’ve worked all night we worked all week and we finally did it, it went live. And now we all need a vacation to recover. And there’s some decompression that has to happen. And maybe we’re in like a warranty period. We’ve like staggered, you know, our time off and all that stuff. point, then we kind of get back into, all right, like how like, what’s the next thing? And how do we start working towards it again. So there’s more sustainability that comes in from the delivering value for the team and for the customers.

And this is the zone that a lot of organizations need. There are some that want to go even further. You know, we talked about the promise of agile and it was like, Oh, we could just be agile, then we’re going to be able to like pay attention to the market and our product is going to be like right there alongside if not leap-frogging our competitors, we’re going to be able to make better product decisions. We’re going to reduce the handoffs between like our business and our IT. We’re going to have everyone that’s needed, like really collaborating and working towards the product.

At that point, we’re optimizing. So we’re able to make the best decisions because we have all the people that are needed, whether they’re from sales or marketing or legal You know, any of those areas that tended to be like, you know, three, three degrees away, like we bring them as close as possible. Same with like our operations, you know, folks like they’ve probably started to come alongside us in delivering and they might be even closer to us and optimizing here. But this is going to help us, you know, develop the best product possible for our customers.

And this last stone in the Agile fluency model on strengthening, it’s a little bit it’s a little more radical, and it’s a little bit hypothetical. We’ve seen this like organizational culture shift in some companies that you know, more often than not, they like they were natively created that way. Where you’re, you’re a team member, but you understand like the whole value stream and and like what it is as a company that we’re trying to accomplish that say if your product is no longer the most important thing, you would even like move for yourself to another effort or to a note another product, and being able to have that like radical self organization. Now, I think a number of you might sense that’s probably not the goal of most organizations, because that takes a really big investment, a lot of learning a lot of training, and some really big changes.

But when I think about where most teams are, and what they need, I personally encounter a lot of teams that are focusing and like working towards delivering, maybe they’ve gotten that one figured out, but they’re really trying to, like get really strong at delivering and maybe even move to optimizing. So winning means we can deploy at will, you know, as soon as our product person says, I love what I see, put it in front of customers we go, yep, it’s there. Just like that. You know, there aren’t that many steps involved. I can practically push a button and it just triggers everything automatically. It’s there in the hands of customers, and we can see how it goes.

And in other cases, I have clients that are saying, I’m getting pretty good at deploy and like our quality is there, you know, we’ve brought in a number of these technical practices, but we’re still kind of behind our competitors. Or it feels like we’re not, we’re not seeing like the real revenue growth or the real cost savings. Like there’s a disconnect between, you know, the output from the team and like the outcomes that that we’re seeing as a result of it. And so we’re trying to bring those groups together and help the team have better clarity on what is the real business goal, and how would you measure it, how would you know if you’re achieving that or not? And so those are starting to describe some of the purposes or some of the objectives that that development teams might need.

So when it comes to helping the agile team play to win, right, because we’re not just going to practice, you know, like off on our on our own on the field, and they’re gonna be playing, you know, and trying to deliver a real product. And we want to support them through that effort. You know, we need to talk about like the different skills and capabilities that they need. Well, it seems as though that’s more training and something that could happen outside of their project. And instead, we shift as coaches we say we want to learn on the real thing. And I will introduce some theory or a model or something new as a practice, just in time, and then we’re going to start doing it right away, we’re going to try and like lock that in to our muscles, and and get familiar with it and have the team again, experience it and reflect on that experience. So, you know, if I, as a coach think that test driven development is a practice that we should try, I can introduce it to you and like walk through the steps. I could have someone sit down with you and and mentor alongside you on how we implement it for a couple of our user stories, let’s say, we need to have that reflection afterwards of like, so did that. Did that get us what we thought it was going to? And? And how might we need to improve that practice or change that practice for our teams needs.

So I’m going to put up another model here, and this is the improvement kata. And one of the things that I considered when I was thinking about a sports team, you know, we can we can generally turn on a TV and we can look through old clips or you know, current games and see what does a really good soccer team look like? or What does a really good basketball team look like? And I can make some pattern recognition of what they do. Now in software development, I find or and certainly if you’re using agile outside of software development, like we don’t have as many Visible examples of what really good looks like. And it’s much harder for us to then identify from those examples, like, what are the patterns or like, what are the key practices that we might try.

And this reminded me of the Toyota manufacturing, where, you know, decades ago, Toyota had been really, really strong and how they were manufacturing cars. And they had this amazingly lean process. And they started out producing other car manufacturers. And so folks in the United States, they go and they visit Toyota, and they notice, you know, some different things happening. And they they start trying to bring back you know, some of those tangible or some of those like visible efforts, so, now, I might have a Kaizen event, like we’re gonna have a short workshop and look at how we improve things or we might have a Kanban board and have cards that are like telling us about the inventory. And try to like manage the overall throughput. But as we mimicked some of these practices, we missed the underlying mindset. And the underlying mindset is what is described in the improvement kata. And this was created by Mike Rother who’s written a fantastic book on it and provided some additional resources around it. So at this point, I’ve got this model up here and has a couple words to describe it and some numbers. What do you all think this is is saying?

Host  I want to chime in here one of the things that is really interesting is the the patent the experiment before establishing the next target, which is different, right. Usually people say Here’s the target. Now let’s go experiment. So I realize that different paths.

Allison Pollard  Hmm, yeah, yeah, they’re the numbers here, you know, aren’t going to be helpful. So it actually is that three is the next target condition. So we are going to set that before we start conducting the experiments at step four. But when it comes to that journey, right, like the experiments are extremely focused towards that next target condition. So I’m not just running any old experiments or doing things that I think are kind of helpful. I’m looking at what is going to take me from where I am to that next target condition. And and I’m going to encounter some particular obstacles on that path. And those are the things I’m going to be most concerned about.

Host  Other thoughts?

Allison Pollard  Yeah, what other observations do you have?

Participant  This reminds me when I’m going to drive to place it, it’s like far, but I can. By just knowing the directions, I know where I’m going, I can pack on my mind. But I know how to get from here to the main junction to the road. And then once I’m at the road, I know I need to get to that next city. And once I’m getting to the next city know how to get to the other exit and through steps by knowing what’s my end, destination. I know how to steps get to each one up to this intermediate destinations.

Allison Pollard  Yeah, nice. I like that. Because, you know, from your metaphor there like that, that final destination is what we would call number one on here. So it’s that direction or that challenge, like that’s the that’s the real place I’m trying to get to and obviously at current State, you know, like, my current position is two. So there’s a quite a distance between them. And as you said, like we’re setting some intermediate targets. We’re setting like the next place that I want to be. And I can go a number of paths to get there. And, and it’s funny because as I think about nowadays, like many of us driving like we turn on the GPS, and it just reroutes, you know, we just we just blindly follow it. It’s telling us, you know, how to run the experiment in some ways. And when we’re developing products, there is no GPS that tells us how to run the experiment. It doesn’t do the rerouting for us. We are the ones that have to figure out like, what is the pathway? What is the plan to get there?

So this is a model that I’ve been using with some of my colleagues, a couple of technical coaches, when we’re working with teams, and what’s been really interesting about this is trying to shift away from having the really large roadmap, you know, of feature feature feature feature feature feature feature, right until the end of time. And and you know, then it’s a question of, are we ahead? Or are we behind, and more often that we’re gonna be behind? Because it’s a really big roadmap, and there’s a lot of stuff in it. Instead, we think about not not so much like, what’s the feature that we’re trying to deliver? But like, what’s the goal? You know, like, Who are the people and like, what do they need to be able to do? Or like, what’s the business like revenue that we’re trying to impact your like the cost savings, impact we’re trying to have or, or maybe it’s like a certain number of users that we’re trying to enable with something. So when we can have that kind of perspective on it, it gives the team a lot more autonomy in the experiments that they can run.

And there are some experiments that we’ll do that is all about how the Developers can improve just their working conditions. And some of the like, I’ll say like platform needs, you know, maybe it’s, you know, how do I improve my continuous integration and continuous delivery practices, knowing like I mentioned with the fluency model, that if I can release at will, I’m able to deliver value regularly. That’s gonna be a next step towards being able to focus towards like the business market and business needs. I probably have to have built up that trust in order to like, get my business folks and even some of my my it leadership on board with the team having more visibility and more ownership of the overall product. Because if I have a track record of every deployment comes with issues, and there’s certain fixes that have to happen and like a certain amount of cleanup. You’re not going to want me to do a whole lot of experimentation. You with, you know, how are we going to increase revenue? You’re gonna say, Well, well, well Well, how about you just figure out how to deploy like safely and cleanly. And when you can do that consistently, then we can talk about, you know, having a bigger impact on the work that you do.

So with this, I’m finding that a number of the teams, you know, they don’t have a really clear direction, they don’t have that big challenge that they’re working towards. They got stuck in next target can like current condition and like run an experiment of like, here’s the feature, here’s where I am deliver towards the feature. And then there’s just like, next feature, here’s where I am deliver towards the feature. And we don’t get that big feedback loop of the feature like produce the results it was meant to. Did people adopt it? Are they using it? You know, is it is it helping our business. I think sometimes that information is lagging, you know, not only for the team, but even for other stakeholders. And other times it’s so siloed across the organization, that we tend to think that the most important thing that the development team can do is keep on developing, instead of that pause and working with our users to find out like, Where are the pain points or what wasn’t so intuitive? You know, how can I make this better for you and your goals and what you’re trying to accomplish?

So my colleagues and I get to be kind of creative. You know, we’re out on the sidelines, but we’re getting to paint a different picture of that challenge and of the success and it’s like, you know, getting the team to envision like that trophy, or that like feeling of like you’ve just won the Olympics. Imagine if you could create this kind of win. That is compelling. And that is something that makes it worthwhile for us to go through all those impediments and all those experiments that we’re going to have to do. Because what I find is when we say, Hey, we just need to deliver another feature. And the team goes, Yeah, and we have some technical debt and our deployment process, still got some manual pieces about it. It’s not really clear to anyone, like why would we prioritize addressing that and and like, adding more automation or you know, fixing or updating some of the architecture or you know, working on some of the defects that might be happening today. But when you give them this end state, and get that like emotional impact around it, then it becomes much clearer like what can wait and what cannot wait as a development team.

So one of the things that we do is we create that like Northstar are we like to call it the definition of awesome. We know that we’ve hit on a meaningful definition of awesome when we can put it on the screen in front of a group. And they start to laugh. So this is an example of one of the challenges that we put in front of our release management groups. So release management actually helps with deployments for multiple products. And they were doing it rather well. They were able to deploy effectively, twice a month, pretty stable. And then we said, you know, what, what if? What if we could do a deployment so that when a developer submits a pull request, their code is in production within one hour, and every step of the deployment process is automated.

Can you hear that group laughing at us? Like, do you know how crazy that is like we don’t we don’t have Have the test automation in place, we have all these like approvals. We have all these like dates that we have to go through, you know, like there’s different environments, you know, and stuff that like the code is going to get progressed through and like you. You’ve lost it right? Like you really think that from the time a developer puts in the pull request, and the product owner says I love it, push it, like an hour later. It’s in production and in the hands of real users.

And this is something that we put in front of them. And sure enough, as we as we said, you know, what’s the next target condition. And we’re going to be working on this every week, and we’re going to make small steps towards it. This team made amazing progress, where they could go from deploying once a month to twice a month. They could go from deploying in the evenings to deploying during the business day. They actually deployed during the business day, like while we were in a meeting about this stuff, and I was like Hold on, time out like deploying this becomes such a non event that we can be in a meeting, talking about how we improve. And y’all already have code that’s moving, like right now into a production environment. And like, no one’s worried about that. Like, that’s a cause for celebration.

These were folks that had dedicated themselves to like, you know, one night, a month. And then like one night a week, eventually, like, every evening, they knew they were going to be online deploying code and testing it to they can now do it within the business day, they got their evenings back, like that was massive. And what was really interesting is some of the initial changes and some of the initial improvements had nothing to do with the code. There was no configuration that changed. It was all process. It was all a matter of who did what, at what time, and who needed to be involved or did not need to be involved on that we could change in order to see a really big impact in the deployments.

So that’s one example. Now a second example. Again, if you think about a large organization, they have a really big value stream. And when it comes to putting a new retail product in front of customers, we have to run a program, you know, or we need a whole release train involved. This is a very time consuming effort. Because there are people that are involved in how is it going to be marketed? Like, how is it going to display on say, our .com website or our mobile applications? You know, how do we accept payment for this? Like, what is the back end fulfillment process? And who does that need interact with? Like what systems there might be some changes in, you know, what needs to be displayed on receipts? And like, what kind of information needs to be provided to customers about this new product? And so you’re talking about a very large group of people and a lot of moving pieces, and we said, What if we can deliver a new version retail product in one month.

And once again, they laughed at us, like, What are you talking about? Like there’s no no like that. That’s how really, and this is where like the business folks start to go, oh man, and if you can do that in a month, like here’s what becomes capable, you know, for us as an organization, like we have this massive backlog of products we’ve been wanting to put out there anyway, you know, it takes so long we have to prioritize, like really, really scrutinize like, what is the next most important thing that y’all work on, because we can’t get everything that we want. But if this group if this like release trainer, if this large program could make the changes needed, that they could over time, you get closer to being able to put product products in production in a month.

Their business is so excited, their customers are going to gain a lot more capabilities or a lot more functionality and a lot more benefit as a result of it. And again, this is not that we say like let’s do like one massive improvement project. And we map out all the steps and all the things that need to happen with it. Instead, we had to go back and recognize where are we today, and what’s like the next target like in six weeks from now, what might be achievable, and like let’s work towards that, and and make the small improvements and run the experiments and only worry about the obstacles immediately in our way to get there.

And this last example that I wanted to share with you all, like I mentioned a moment ago working with a large enterprise data group, if they can enable product teams to have end to end visibility into the market and operational performance of their products within minutes of making changes. This would help them leapfrog their competitors because right now, you know, folks are worried about a giant data platform. And how can it serve all of the world’s needs when it comes to data? But we’re missing that step of like, how do we enable actual people right now? Like, what is it we’re doing by Friday, that gets us to better decisions. And there’s a number of groups that do not have the visibility that they lack the access, or they’re having to, like piece together information across multiple systems, that there’s a really long delay in when they’re able to do that analysis and when they’re able to figure out what they need to do next.

So if you can imagine your own product team, putting something into production, and not knowing, you know, for a while, like how many people are using it, you know, like, what, how many people are having problems with it? How many people you know, if you think about like a sales funnel, how many of you, like just bailed out, you know, like partway through, they said, I’m no longer interested in this. How would the team know you know if this is our product, how do we know that that’s happening? That we are able to make changes to our product and try to better address those customer needs. If we don’t have the data right away, we’re going to continue like piling on to like our guesses, and we’re going to think we’re doing the right stuff. And it’s not until much later that we realize, Oh, we’ve kind of missed something here, we might have to go back and do some rework.

So if our goal as the Coach is to help the team explore their experience, and really help them play to win, I’m finding that step one is the step we need to worry about. That steps two, three, and four, often enough, like our teams have gotten that through some kind of Agile practice, whether they’re following Scrum, or SAFe, or even using Kanban. They have the beginnings of a way to recognize like, what is the current state, like where’s the product right now, or where are we right now? With our capabilities, we figured out the next condition, you know, we might think of that as like a release plan, or it’s a particular feature or epics that we’re working towards. And we’re probably running something like an experiment, or at least some kind of a plan on how we’re going to get there.

But this idea of like a bigger direction that we’re working towards something that really takes us beyond in our thinking, and, and also like what we’re willing to live with, I think is the piece that our teams need most from us to inspire them to greater than what they’ve been doing. So to help us with that, I do want to make sure that you know, there are resources, you know, beyond what I’ve described today. So Toyota Kata by Mike Rother and his website also has presentations and videos, a lot of additional information that you can use there on how to run a question. With your teams, and then the Agile fluency model, they have an ebook. It can describe for you what are the particular benefits that your organization might be needing from its team and give you a sense of like, what capabilities that teams should be investing in. And some of the like, go to topics to research further that you as a coach might introduce to them in terms of practices. And if you want to talk about this further, or certainly, like, hear more about how we’ve used it and share ideas, you can contact me, I have my email address up here. I’m available on Twitter, and certainly you can find me at my blog. After all, this is kind of what sparked this whole presentation today. Was this blog post a couple years ago on looking at agile coaching and sports coaching.

Host  Awesome, thank you very much, Alison. This was very interesting and very enlightening. We appreciate your participation today.