The past decade of Digital change has been one of disruption. Uncertainty, VUCA, Complexity have emerged as new concepts in business. Leadership had to adapt, notably with agility. But who would have predicted what happened in 2020 and the pandemic? The world seems to have turned upside down in a matter of weeks. Change is inevitable, or businesses shut down. It is also a time to explore new possibilities. This talk will explore how good leadership through the crisis is in fact no more than great Agile leadership: Developing autonomy, promoting alignment, creating strategic clarity and keeping collaboration going by creating remote first working practices.
Best Agile Articles is a collection of the articles from a variety of authors published on topics of all things Agile in 2018.
The Best Agile Articles book series collects the best agile articles published during a calendar year into a single volume.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
About The Speaker
Philippe has been involved with Digital change from the early days of the Internet (nearly 25 years) and has led the initiation and delivery of significant change initiatives for large corporate clients & Banks. Philippe has founded Henko and is now working as an independent Coach/Consultant, or “Coachulting™”.
Other Best Agile Articles 2018 Posts
Best Agile Articles 2018 is a collection of articles from a variety of authors published on topics of all things Agile in 2018.
The Best Agile Articles book series collects the best agile articles published during a calendar year into a single volume.
On April 6 the authors of the best agile articles published in 2018 came together for a workshop, giving their talk on topics such as Agile Leadership, distributed teams, and others.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Johanna Rothman gave during the workshop providing several suggestions on how to lead distributed Agile teams.
Host All right, well, welcome back everyone, we trust that you are either back or on your way back from break. And we’re going to get started with our next session right on time so that we keep everybody on schedule, and we’re able to fit in as many conversations as possible. Everyone is on mute throughout the presentation, if you have a question, if you could put it in the chat box that will help us to be able to manage questions and be able to get get some interaction with Johanna. And I’m going to introduce her now. We have Johanna Rothman, who is going to be presenting five tips to lead distributed agile teams. And this was one of her articles in the Best Agile Articles of 2018 book. And it is very much relevant today. And this time when the whole world is now suddenly distributed. So we’re really excited to get some new information from you. And Johanna, I will hand this over to you. And welcome.
Johanna Rothman Thank you so much. And by the way, I always have my Twitter handle on my front slide, because that way, if I say anything smart, you can tweet it. If I say anything stupid, you can tweet that too, totally fine. So you folks probably know about the principles that Mark Kilby and I developed for our distributed agile teams book. I’m not going to read them to you. But I think that it’s really important to say, if we have these principles, what kind of a culture needs these principles. And what I find is that when we go from the team, to the leaders, we really need to think differently about what’s going on in the organization. So, we all know that managers create and refine the organizational culture. The reason the managers do that is because the managers hold the purse strings. What you decide to reward is a big, big part of your culture, what you are allowed to talk about another big part of your culture, and how we treat each other, the other, the kind of the three legged stool for culture.
So if I think about leaders and what is necessary for leaders, that we often when we go to an agile approach, we see long standing teams that are self directed. Now, some of you are saying, maybe my team is not yet self directed. That’s a different problem. But we also now are seeing the emergence of self managing and self designing teams. And that’s, at least for me, that’s really exciting. That means that the kind of leadership we need for those teams needs to change. And while we might be in the self directed vertical at this point, I think that more and more of us, especially as we work from home, have to be self managing and have to be self designing. There is no way managers can get their micromanagement fingers in there. So, when I think about agile leadership, especially when they’re distributed, that we have these five tips, which is focusing on the collaboration and the work from maximum throughput, and I’m going to talk about throughput versus efficiency later. How can you visualize a system? How can you encourage experiments, and how can you use resilience, not prediction, as your primary risk management. And the fifth one is collaborating with peer leaders.
So let me talk about collaboration at all levels. If you are currently working in a more traditional organization, and you have a personal plan for the year, and you have personal bonuses, and personal this and personal that, that’s all about resource efficiency. Now, the problem is resource efficiency reinforces silos of understanding. So the developers are silo, and possibly the UI developers and the middleware, and the platform layer, and those silos are separate from testing and separate from all kinds of other documentation or possibly the user experience people. The more resource efficiency we have, the less collaboration we have. That’s because all the managers are trying to focus on, and measure every person’s individual contribution. And that means we have so many delays in the work, because when the work assignment arrives, then you do your work you hand off. And who knows how much delay there is, then you hand off, who knows how much delay, than there you hand off, you might hand off and off and off. So resource efficiency looks efficient, but it’s actually the slowest way to work. So flow efficiency focuses on the team’s throughput and this is outcomes, not outputs. So if you think about resource efficiency, if the UI person has an output, right, then the next person has an output, you don’t actually get an outcome until you finish the total feature. But in flow efficiency, we work together as a team, we collaborate. I like to call this optimizing up for the team. And I needed another word. And if you anybody has a better word for optimizing up at the team level, as opposed to the individual level, I would love to hear it.
So this is where we reduce the need for experts. We increase work through the team. So the more our managers especially our distributed managers, think about collaboration, the easier it is for the team to finish their work. So this is a really interesting dichotomy. Because our managers think that resource efficiency works. They think that we can divide the, work that will help us conquer it, that if people are fully utilize, then people are efficient. They also think that we can tell how a person contributes to a team. And none of that, none of that is true. Right? All of that is fake understanding of how management and teams actually work.
So in flow efficiency, we work together, limiting our WIP, our work in progress, and we all succeed based on our team. This is where, if you read almost any of my literature, any of my writing, I have always said, the teams know who’s doing the work in the team and who’s not. You don’t need a manager to understand that. And throughput is much more important than being busy. So if you need a quick way to think about it resource efficiency is about each person’s output. And flow efficiency is about the team’s throughput of outcomes. So, especially at distance, when managers focus on flow efficiency, they realize that collaboration hours matter that you get better work at distance, and you have a lot more agility in the organization. Now, if you remember, Mark’s and my first principle is establish acceptable hours of overlap. So I’m not sure where all of you are all of you lovely people. You’re all over the world. But some of you who are much farther east than I am are already in your evenings. You would not I suspect choose to work in your evenings, all evening unless, unless you really like it. I am much more of a nine-to-five person in whatever time zone I’m in. So I happen to be in the Eastern Time Zone. I can flex a little bit to work with people on Pacific time. I can flex a little bit to work with people in Europe in Israel. And when I collaborate with people in India, we have trouble finding time to work together. We are in Australia and New Zealand. It’s always their next day and often too early in the morning for them and my later in the afternoon, so I’m not sure either of us is actually awake enough to do really good work for a long period of time. We can still collaborate for short periods of time, because we can both make it work but longer periods of time. That’s why collaboration hours really, really matter.
So let’s talk about the team’s environment. And I’m not gonna ask you, literally to tell me have you seen your team’s environment now. But I will tell you that I really like to visualize the cycle time, the lead time, and the delays. And I often do this with a couple of different charts, including value stream maps. So this is a value. This is this is a chart I made up. I’m sure it has a name. I just don’t know the name of it. This is where if you look at t-zero, times zero, the item gets selected for the organization to work on. And then this is all about management decision time. When does it go on to a team’s backlog? This particular team had a lot of independent work by the UI people in the platform people and notice this product owner decision time. This is a real team that I’m talking about. The product owner had trouble deciding when should people work on this. And then once the UI and the platform people prepared, they handed it off and resource efficiency to the middleware in the backend, and of course, things came back, right? They circled a few times once all the development was done. I put development in quotes, because if you don’t have testing, if you don’t actually know that it works, I’m not sure that you actually have finished development. When they found things, that cycled back to T-3 and oftens cycled back to T-2.
So this is supposed to be an agile team. And that looks a lot like waterfall, because of the resource efficiency. Once everyone was done with it then the product owner can offer feedback. And more often than not, the product owner said yes, this is right. But every so often, the product owner said, “Oh, it’s not quite what I want.” So, what percolated back up, back through the team. So, the cycle time is the time from t2 to t5, and the lead time is the time from T1 to T6. This is the release to consumers and ever so, often, I find that people have a lot of work in progress in the organization, that they have not yet released to the customers. And there are many possible reasons for that. But think about what does this look like for your organization. So when the new manager came in, she said, “well, what do we have for team based delays?” And if you look at this value stream map you can see that there’s a half a day of delay between the UI and the platform, half a day, between middleware and backend, half a day between test and tech pubs. And then the PO, actually took a half a day to review and accept the feature. So the work time was three and a half days, but the total cycle time was five days. So if you are using velocity in your team, to try and estimate what you can do, this is why cycle time is a much better estimate. Because you can count the days that it takes for you to actually get something done, as opposed to try and estimate something that you don’t know. So they said, “Well, let’s create a different kind of value stream.” So the entire team met to review the work and they took about an hour and then they swarmed on the work, that meant that they could keep all of these this one, just a little over two days. And they still had wait time for their product owner. But they could not figure out what was going on. Why did it take so long for the product owner? Well, it turns out that there was a whole lot of multitasking. If you don’t have really good decision making for a management decision time and product owner decision time. So the T1 to T2 time, that took a very long time for the team. So and there was still a delay, there was a different group that needed to release to the consumers. It wasn’t regulated industry and they really did need to know that they were not going to break anything else. But the days and sometimes weeks, week from T4 to T5 – that was a little crazy. So once you understand what’s going on in the team, once you visualize that, now you have a shot of understanding what are the delays outside the team. And remember that a lot of this time actually was so much larger than the team cycle time.
So they changed the team environment, which was to create full feature teams. UI, and testing, and tech pubs no longer were service, they relocated the product owners. Some of the product owners were many, many time zones and very few hours of overlap away from their teams. So they talked to a whole bunch of the product owners and said, Is there a way for us to collaborate better with people where you are? How can we do that? So they managed to have more full teams here, more full teams with a product owner closer together, so their hours of overlap are better. This is something the managers can do. Very few teams have the option to do any of this. And this is I think that this is really a problem.
Now, the next tip is to encourage experiments. I am a huge fan of experiments. And I don’t want failing fast. I don’t know how many of you like to fail fast. I don’t like to fail at all. Oh, Astrid, yes, you like to fail fast. Fine. Okay, so there’s at least one person here. Oh, you don’t like it? Oh, yeah. No, no. Failing is horrible. Learning – good, failing – bad. So I really want to learn early. I that means I need small safe to fail experiments. Yes, that’s connected language. If you don’t know about connection, I strongly suggest that you learn about it. And the way we learn is to have a hypothesis for change. So this is my experimental loop looks just like almost any other experimental loop. We have a reason for the experiment. We suspect that there’s a problem. We want to learn something. We create a hypothesis that includes the data we want to measure. Now we experiment, and we timebox this experiment. I really like small experiments of a day or two, maybe a week. I’m not too big on longer experiments, just because the feedback loops are so long. So I want to have really short feedback loops, and then I want to measure the results and learn from the data, I can go around this loop as often as I want. And even if I create a hypothesis, and I think, “Oh, that didn’t really tell me much, I maybe I need to create a different hypothesis or create different data that I want to measure.” Totally fine. So I really want to think about what the hypothesis is.
So I really want to think about the decision. Do I want to continue change or stop the experiment when I get to learning? So I really want to think about this. The reason this previous organization was ready to move to flow efficiency thinking is because I had them write down their hypothesis. We will get more work done. If everybody is busy. And I said, “What can you measure?” They decided on the number of finished features, I would have preferred the cycle time. But they decided on the number of finish features per a given time box. So they first measured what they had for the number of finished features in the previous time box. And then I said, “Okay, that was two weeks. Now, our hypothesis is you will finish fewer features if you work as a team, if you actually swarm, or mob, or at least pair. And so they had finished three features in the previous two weeks. And when they framed this change as an experiment, they got through four features in the first week. They said, “Do we need to continue this experiment?” I said, “Do you think you have enough data? I mean, what do you want to do? You’ve already learned that you finished more in one Week, do you need another week of experiment? Do you want us to frame a different experiment?” So they decided, we finished that for this one week. Now we will figure out what to do differently for the next week. So they had a different hypothesis about how to work with the product owners in the second week. So they were able to frame their changes, and then, as they had these two experiments, they could use the next two week time box and integrate the experiment.
Mark is asking, “What is my definition of a feature?” Something a customer could use. Right, so something usable, not full. I have a blog post called Minimum Outcomes. I think it’s something about minimum outcomes, where I talk about a minimum viable experiment, a minimum viable product, a minimum marketable feature, a minimum indispensable feature set, a minimum adoptable feature set. I do not use the word epic or theme. I only use the words feature set. Because if you talk about epic or theme, your managers, the people far above you in the organization think it’s one thing. And it’s not. It’s many, many things. So I happen to use the term feature set, and that helps me. So even if it’s a minimum viable experiment that will help us learn something that to me is a feature, not the entire feature set. I hope that that makes sense, Mark.
Okay, so, what I have found is that a lot of organizations really want predictability instead of risk management. When we experiment, we are able to do risk management When we demand predictability, we are saying to people, “We don’t trust you to deliver. We don’t trust you to manage your risks yourselves. We want a real, an accurate estimate,” which accurate and estimate does not actually go together. Those two words are an oxymoron. But we want an accurate estimate and we want a commitment. One of my clients talks about commitments. I don’t know if you can see my hand, right, it is kind of a hammer on the other end of my hand. That’s the way people feel when they want all of this predictability. So, if you are able to think about small safe to fail experiments instead of predictability, then you are learning early and you can still deliver. So I’ve written a lot about balancing feedback loops and innovation and commitment. And I’m happy to share those blog posts for you, you can just look for them on my site. But it’s really important to think about, how often can I get feedback from the stuff I’m doing, so I can commit. Because if you realize you have a feature set of about 30 features, you will be able to deliver several of them early, more than later, and several of them you might not need to do, this is the 80/20 rule. And I really wish most of the software I use on my computer really have to buy the 8020 rule, because most of it, most of the software we use is bloated, has way too much stuff. We don’t need most of it. So if we could do only the stuff that we need, and yes, it’s difficult to figure out what stuff that we really need. But the more we think about it, the better our products will be, and the less pressure we put on the people in the teams.
So now I’m going to talk about using resilience as your primary risk management. So, a lot of people use adaptability and resilience as the same thing. Adaptability is steering the change and responsiveness to change, that you notice that there is a change, you somehow steer the organization. Resilience is your ability to recover from problems or change. Now I made this picture so you might not agree with it, but this is how I think of adaptability and resilience. We notice a change first. And then once we recognize we need adaptability, we can generate options. Then we practice with experiments. And because we took that small step, we feel good about ourselves. And then even if we don’t succeed, even if we just learn, we’re now open to an expect more change, we use our resilience to create more adaptability and capability in the adaptability arena. So for me, adaptability and resilience are two different things. And we need both of them. So if your team is working in resource efficiency, you don’t have the resilience for other people to take over. So all of us are maybe not literally in lockdown. But all of us are working from home now. All of us are are being asked to limit our time and the stores and our flights, all of that stuff. At least I am, because I’m in the US.
So the more adaptable we are, the more able we are to generate possibilities. That’s that generate options thing here. And the more we experiment, the better off we are. So thinking about how we steer the change with adaptability? How do we enhance our ability to recover from problems, if not all of our team members can be with us all day, because they’re taking care of children, they tend to older people, they’re doing something, then what do we need to do as a team? And if you think about adaptability, and resilience, not just for feature teams or technical teams, but also for management teams, and senior management teams, now you’re a lot farther along.
So when I think about leading a distance, I know that I’m going to need adaptability. And one of the things I really like to look at is the cumulative flow. This particular chart is from a real project. I know I have many stories about real projects. This particular product owner really loved his PRD, his product requirements document. So he created a PRD and kept adding to it until the developers in the testers said, “What are you doing? Why are you adding more features as we go?” The team needed to do a little analysis on everything that was in the PRD just in time. So sometimes they would take an entire feature set at a time. Sometimes they would take a couple of small stories, but whatever it is, they often had a bunch of stuff in an analysis, because they were not sure where they were headed. This, the yellow part is not even a unit test. These people sometimes use TDD and sometimes did not, but they often had unit tests. And then this blue is where the testers actually did their testing. So you can see that the testers really kept up pretty well, with the developers. They were not behind. Now, you might be wondering, “Johanna, you’re so focused on flow efficiency. Why are you talking about testers being behind?” Well, when I create anything, I need other people to review it. I am not capable of reviewing the stuff that I create. Well, I mean, I can some amount of review. But I think that I am not that different from all of your developers and all of your testers. We need both development and testing people on a given project. We might not need anything else. And even in resource efficiency, I should say flow efficiency, I am not talking about testers are going to become developers. I’m talking about people who work together, who collaborate on the work on a limited amount of work. So, the nice thing about looking at all this green stuff, all the completed work is that you can see a leader, a manager does not have to ask too many questions. The leader, or the manager can say, “Do you have too much work in progress in this in the ready work and not yet started? What’s going on there? Is there some kind of an impediment that I can help you with?” And with analysis, there’s not that much work in analysis. So the red stuff, the the stuff that It’s supposedly ready and not yet started, that’s the only place I would actually look for areas to discuss with the team.
Now, there are other kinds of project metrics, such as the product backlog, burn up chart and feature chart, which shows you how many features you finished, and how many features you’ve added over time. Those might be useful for a manager, if the team is only self directed. This goes back to the kinds of teams. If the team is self managing, or self organizing, the manager doesn’t need to do that much. The manager kind of needs to remove the impediments in front of the team. So one of the interesting things when I think about more resilience and more adaptability is that I really liked the rule of three. So I got the rule of three from Jerry Weinberg in almost any of his books, read all of them. You should all read all of his books. Okay, fine. I said that. So the rule of three says, “one option is a trap, two options are a dilemma, and three options create the breakthrough thinking and allow you to generate options, maybe four or five and six.” My guideline for me is always to generate three options. So if you read my writing, especially my Pragmatic Manager Emails, you’ll see I often have three tips, or three options, or three of this, or three of that. That’s because my guideline is to always create at least three options. And now, that’s because I am the kind of person who until I knew about the rule of three said, “Oh, first option. Good idea. Let’s do it.” That’s one way of doing work, maybe not optimal. Because I have found that only one option really doesn’t give us enough ideas. And then there are people who are hamsters for lack of a better word, that they just create more, and more, and more, and more ideas. And if you have people like that on your team, keep them close, harness their ideas and say, “How will we start experimenting? Do we have enough ideas now?” And chances are if you’re all tired of generating ideas, yeah, you probably have enough ideas. And if you’re up to idea 25, you probably don’t need any more ideas. It’s time to start experimenting. What is your hypothesis? What data do you want to gather? How long do you want the experiment to run? Then run it and gather the data and keep going through the experimental loop. That will increase your adaptability and offer you enough resilience so you can keep going. Because you might actually have to work through all kinds of ideas.
So many of you are newly remote or new to lots of remote work. Maybe you only worked remote for a day a week before. But if you’re like most of the people I know this is very, very new. So you might need to experiment in many, many different directions. And as long as you are a leader and helping people say, “Do we have enough ideas for now? How, quickly can we go to an experiment that will offer us more data?” So one the problems with people like me, who like that very first option is we take that first option, and then we cut off all the other options. So, leadership, whether you’re in the team or serving a team, is this delicate balance for me of encouraging more options and encouraging how people can do their work, and learn from it, and not cutting off options too prematurely. And I don’t know what that Goldilocks time is, you will have to figure this out yourself.
So, the next tip is to collaborate with peer leaders. When I find is that when I go back to this image, notice that I said that management decision time T0 to T1 (and I wrote this not to scale). So I made this small but the reality is this was actually twice the duration of any of the projects. So, what is going on for miniatures? Why can they not make a decision in a reasonable amount of time? What I have often found is that managers have great intentions for making decisions. And they all meet as a team to figure out what decisions they need to make, then they need to go back and get some more data, and they get interrupted and they do something else. And it’s another week before they get together or another month before they get together. So the problem is managers by design multitask all the time, all the time. That’s a manager’s job. And that means that managers if they have to make a decision, need to focus on that decision and not allow other things to interrupt them. easy for me to say. But when we think about what the outcome of this decision is, now, we are much able to figure out, when do we need to make that decision? How quickly can we make that decision.
So, what I found with this particular client is that when managers focus on their throughput, manager flow efficiency, they reduce their selection time down to weeks, maybe a month. But they had been at six, or eight months, or even a year, portfolio decisions. Now they got that down, that T0 to T1 to two weeks. That was a huge change, and all because the managers collaborated to make certain decisions faster. They encourage the teams to leave room for options in their planning, (I’m going to talk about the roadmap in just a minute), which is a result of the managers changing the roadmap to options, not demands. When you have options, you are able to do less of it. You don’t have to do all of it. You can move to “how little” thinking not “how much” thinking. And because the managers were working in flow efficiency, and because the managers had this idea of experimentation, they have less need for predictability and more need for more measurable and visible outcomes. So if we look at what can we measure that allow people to do their work better, to feedback for the work (feedback in the small), which offers managers feedback on their jobs – now we are much, much better off.
So, let me talk a little bit about the project portfolio and more agile product roadmap. So, in the project portfolio, you collect the work in rank order, and then you have this commit, kill, and transform decision. A commit is you commit to a team or a series of teams, where you say, “you have everything you need and everybody you need to do this work. We want you to succeed in doing this work. You do not have to start with missing people. You do not have to start with missing lab time. You do not have to start with missing anything, you have all the people and resources that you need.” Now if you need to transform something, I often see that organization starts with just a project, one small team. Then they need to add another small team, and then they realize it’s a program, it is not a project. So if you realize that you need several teams, more than three, now you need to organize a program. That’s the transformation. And now you can commit to our program. A program is one business outcome with that several teams need to contribute to.
And then the kill decision. A lot of you are very nice people, you know, like killing projects. I love killing projects. I think killing projects is wonderful, because they’re, I don’t have to think about it anymore. So, but many of you are very gentle souls, and you don’t like to kill projects. That’s what the parking lot is for. If you do not have a parking lot in your organization, get one now. Put all the stuff that you’ve been meaning to do, that’s not going to get done, that’s not on anybody’s list, put on the parking lot. Every six months, you assessed the parking lot, just toss it all. If you really want an agile organization, you don’t need all this stuff on backlogs. You don’t need all this stuff in the parking lot. I am a big fan of “if it’s a good idea, it will come around again.”
So when my clients, when I say to them, “You’ve had the stuff in the portfolio for how long?” And they say, “Three years?” and I say “anything over a year, put on the parking lot.” And then the next time I work with them, which is often three months later, I say, “How’s that? How’s your project portfolio doing?” They say, “Well, we still have some stuff we’re not going to get to.” Then I said, “Put that on the parking lot!” Just keep putting stuff on the parking lot until you only have to assess what’s really important to your organization. Now I do advocate that you have stuff at various levels in the parking lot. You need to do the stuff that keeps the lights on. And you need to do the stuff that allows the current products to grow at whatever rate they are growing. And then you need at least 10 to 20% of “whoa, what would happen if we could do that.” And those moonshots, those possible transformation projects, at this point, now, where we are in the world, those are the things that will get you more customers. Those are the things that will get you more revenue. And you need to do very small experiments to figure out where those are. So those are short. Those offer you information quickly and that’s it.
So, now let me talk about this one quarter lean roadmap. Notice there are features here. And this notion of an MVP, a Minimum Viable Product, and the black line. If you have to commit to anything, I really like committing to some work that will allow you to produce a rational, reasonable product. And then you have a black line. And you if the teams are done with this, then you can pull from the black line after you’re done with what’s in front. But then you have the options of changing everything above the black line at the end of the first month. If you really want agility in your organization, got to figure out a way to move from commitments to options from demands to small bets. These are small bets. We know we need to do this. And we don’t have to do all of the stuff underneath the black line.
So when I think about distributed agile success, they’re definitely the team principles. All the eight that are on the other side. But the leadership principles are focusing on collaboration. That flow efficiency, visualizing the system, where are the delays, how do people actually work, how do we encourage experiments, how do we use resilience and definitely not prediction as a way manage risk, and how do we collaborate with peer leaders. That’s the end of my formal presentation. I am happy to take questions. And Cherie, you’re in charge of unmuting, or questions, or anything else? Let me know if you want me to stop the share.
Host All right, everybody, if you have questions, if you could post them in the group chat, we’ve got about seven minutes for questions. So if you post your questions in the chat that’ll help us get through more of this a little bit more quickly.
Johanna Rothman I envision people madly typing.
Host Let’s see if we have any.
Johanna Rothman I don’t even have private questions. Did I shock everybody?
Host Well, this was a great presentation. Lots of information very thorough. Joe Justice says loved it. It was very thorough. Lots of great visual information.
Johanna Rothman So there’s a question. There’s a question about my next book, Practical ways, the triad, Modern Management Made Easy. That triad, I’m working on it now! I will be working on… The first two were sort of okay. I have not yet integrated technical review for the second book and the third book I’m i’m actually rewriting because I’d said in the Innovative Organization I’m realizing I needed to put more in there. Joe, I have book writing tips. I’m not sure if anybody else wants them. But here’s the quick tips. Frame the book for a specific group of readers, for who your personas. I don’t do outlines, I have a user story map that guides me through the book. What three things do people need to learn, and then in any given Chapter I answered those three things. And then there’s a lot more, but keep writing right? Every single day, 15 minutes and then the six months you got a book.
Host Awesome. Yes, here has a question. Do you think all these principles will be applicable in a non IT environment?
Johanna Rothman So when I taught leadership, which is a lot of these things, to our customer success team, they found all of this really useful. So customer success, customer support. A a lot of teams that don’t actually do development they often work in resource efficiency. And while you might not real want true flow efficiency for everything, I think it’s really worthwhile. And if the managers work in flow efficiency that’s really a big deal. Because now, the entire system of work is focused on the outcomes that you want for your customers.
Host Awesome. Thank you. And do you have any recommendations on a software to use for product roadmapping?
Johanna Rothman No, I don’t actually like tools for product roadmapping, it encourages way too much. I am a huge fan of thinking ahead. I’m a huge fan of “what bets do we want” and often, especially, if you’re working in programs, you really need to figure out what kind of outcomes do you want in three months, six months, nine months, a year, 18 months? Yeah, think about outcomes. The roadmapping software I have seen is too focused on getting the details and not enough about the outcomes. So yeah, clutter free backlogs. I really like that.
Host Awesome. And will you and Gil be offering training sessions online now that were struggling to get together in person?
Johanna Rothman So Gil and I are thinking about this. We had the influential agile leader. And of course we cancelled it, it was April. So we are thinking hard about what to offer next, and when. And we are not sure, because we don’t understand when travel might happen. And we have had lots of international people at these events. And we’re not altogether sure how to translate what we do in person to a virtual event. I’m actually going to start a series of blog posts about virtual training versus in person training because what you can do in person is very, very different from what you can do online. So, and a webinar is great, but that’s not the kind of training that we used to offer. I don’t know. Thanks, Christine.
Host Very well said, I believe we’re all in that environment at this time, still just learning a new way of living. So, I am going to relaunch our poll for our audience to give some feedback into today’s session. So we will be going on break and we have a 10 minute break. We’ll be coming back at the top of the hour with the next presentation. And the next presentation is going to be Ellen Grove. And she’s going to be talking about building alignment through team working agreements. So we want to invite everyone to take a quick break and take care of yourselves. And we’ll see you back here in just a 11 minutes. And Johanna, thank you so much for participating today, great content. And if you are able to send your slides PDF to Michael and I, we will make sure that we get those out to the people who attended.
Johanna Rothman I will and I’m happy to. Thank you so much. This was great. Thanks, everybody.
Host All right. Thank you. Bye bye.
Best Agile Articles 2018 is a collection of the articles from a variety of authors published on topics of all things Agile in 2018.
The Best Agile Articles book series collects the best agile articles published during a calendar year into a single volume.
On April 6 the authors of the best agile articles published in 2018 came together for a workshop, giving their talk on topics such as Agile Leadership, distributed teams, and others.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Roman Pichler gave during the workshop on the topic of managing and dealing with the stakeholders.
Other Best Agile Articles 2018 Posts
Best Agile Articles 2018 is a collection of the articles from a variety of authors published on topics of all things Agile in 2018.
On April 6 the authors of the best agile articles published in 2018 came together for a workshop, giving their talk on topics such as Agile Leadership, distributed teams, and others.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Ajeet Singh gave during the workshop “How Scrum Master Can Enhance Daily Scrum.”
Transcript of the talk is still pending and will be posted as soon as it becomes available. Than you for your patience!
Best Agile Articles 2018 is a collection of the articles from a variety of authors published on topics of all things Agile in 2018.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Zuzana Sochova gave during the workshop “Agile Leadership: How to Change World or Work.”
Transcript of the talk is still pending and will be posted as soon as it becomes available. Than you for your patience!
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Kurt Nielsen gave during the workshop “The Fatal Attraction of Classical Hierarchies.”
Agile coaching seems to be a required staple these days to grow and nurture winning Agile teams.
Are stakeholders fair-weather fans of your Agile teams? How can you coach Agile teams to grow their skills and score more points with customers? Winning Agile teams deliver high value products in a way that leaves both team members and customers eager for the next deliverable and agile coaching is a necessary component for their success.
In this live session, Allison Pollard will examine the Agile Fluency® Model as a resource for how Agile Coaches can cultivate these winning teams for organizations. Join to find out how you can enable teams to practice and gain the proficiency they need.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Allison Pollard gave during the workshop “Coaching Winning Agile Teams.”
About The Speaker
Allison Pollard helps organizations create Agility by building trust between business & IT, leaders & teams, and within teams. As Technical Director for Improving, she is a curator of agile frameworks and change methods who coaches leaders and teams to improve work relationships and enable better delivery. Allison is also a Certified Professional Co-Active Coach, a foodie, and proud glasses wearer.
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.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Joe Justice gave during the workshop on the topic of executive led agile transformation.
Transcript of the talk is still pending and will be posted as soon as it becomes available. Than you for your patience!
About The Speaker
Joe Justice is COO of Scrum Inc. Japan and works globally as an interim executive for agile organizations, bringing multinational companies twice the work in half the time. His teams have held 4 world records. He is a TEDx speaker, guest lecturer at both MIT and Oxford University in England, featured in Forbes 7 times to date including as owner of a “Company to watch” by Forbes Billionaire Club, cited in more than 5 business paperbacks and hardcovers, the subject of a Discovery Channel mini-documentary for his work creating the discipline Scrum@Hardware while working directly with the co-creator of Scrum, Dr. Jeff Sutherland.
Joe has worked with all of the top 3 military and defense contractors, autonomous and smart road technologies, ultra-lightweight structures, guest lectured at UC Berkeley, MIT, on behalf of Carnegie Melon, CU Denver, The University of Washington, spoken at Google, Microsoft, Zynga, Lockheed Martin, HP Labs, The Royal Bank of Canada, Pictet bank, and others. Joe’s work has been featured in Forbes, Harvard Business Review, CNN Money, the Discovery Channel, and others.
Host So we’re gonna jump into our last presentation. And this is Joe Justice, who’s going to be presenting on executive-led agile and digital transformation. So thanks, Joe, for joining us. And we’ll hand this over to you. I’m looking forward to hearing your talk.
Joe Justice Thank you so much. I’m very glad to be here. I’d like to say the first talk of the day that Joanna gave, she shared eight principles for healthy functional distributed teams that can be high performing, and then expanded on it dramatically. Well, I did that on the first break, I rebuilt my day to be better overlap with the attendees of this conference for follow up. So I took a note from SpaceX and Tesla, where they work 12 hour shifts, and they do three one week and for the next week, three one week and for the next week, 12 hour shifts. That way you have maximum time zone coverage. So I set up my Calendly because of Joanna’s advice at this conference, to start at 10am, open for bookings pacific time, and close at 10pm. Open For Bookings Tuesday, Wednesday, Thursday. That should let me engage with everyone on this call no matter where you are in the world, because it’s a 12 hour day, which is the idea of why Tesla and SpaceX do it and why Joanne recommended it for distributed teams. With that. So thank you so much everyone for making this conference. Awesome. already. I, I’ve gotten a tremendous amount out of it. I’m sorry to be last everyone must be exhausted. I’ll try to get to the point. So folks can get the most out of it. And you can tweet me anytime; almost every slide has my Twitter, it’s @JoeJustice0. So if you want to know more about something, or see more pictures, or more the data, or a video, or ask a question about something, that’s a great public way to do it. If you need to be private for some reason, some companies still require that they’re not quite as open and transparent as others. You can email me old school, email does still work and that’s on every slide as well. It’s at email@example.com.
Joe Justice Okay, let’s do it. I’m lucky enough to have spent the last six years working with almost exclusively executives, and the board of directors that hires those executives and usually holds them accountable. And in some cases, some countries have something called a board above the board and I’ve been working with those people as well. And those are usually more hands-off investor types. They’re typically retired and they have a high level of stock or passive ownership. they exert an incredibly powerful but slower authority because they meet on a slower rhythm in these non-agile traditional companies that are that are that large, and that’s part of why they’re hungry for this agile transformation. There finding it almost impossible to pivot within the legal structure of being a board and having a board above the board and some of these companies’ cases. Now that said, I’m also the creator of Scrum for Hardware and Extreme Manufacturing the technical practices that go along with that. So most of my clients are manufacturers; Bosch, Toyota, I got to work a little bit with Tesla. I’d like to more; I’ve learned a ton working with them. I learned a lot more from them than they learned from me but I am happy to say I got to share some good things.
Joe Justice NEC, Hitachi, Fujitsu, 3M, all around the world and finance companies too…what I’ve learned working for executive lead agile transformations is we have to focus on investor return or they’re not going to be able to pay attention and act on it. Otherwise it doesn’t come out of the main budget of the company. The main budget of the company, for almost every company, is mapped exclusively to growing return on capital; for how much money is put into the company, how much money comes out. So if that’s not the end result, and if I don’t have evidence of what I’m saying is going to impact that, I don’t get invited back. If I actually want transformation, what I’ve learned is I’ve got to map everything I’m doing to increase return on capital. Now, here’s the good news for the agilists on this call, on this virtual conference, the ways to return return on capital with the original research I’ve done and then the research I’ve mined, is through implementing the values of the Agile Manifesto, and it’s 12 principles, and the five Scrum values. So it really does come back to openness, transparency, respect for people, if it’s important, make it visible, making a healthy loving and environment. And it comes to tools like excellent process automation and test driven development and the stuff that we as agilists care about. That is what creates increased return on capital. But if I don’t have data sets mapping to that, and if I don’t phrase everything in those terms, the transformation stops. So, so that’s… that’s it, it’s got to map there. I can’t come in as, “Here’s how to have happier staff.” Then, I’m only part of an HR initiative, which is a sub-budget. And you can do cool stuff that way and many people on this call, have and talked about it. But if I want an executive-led agile transformation, it’s got to be what the executives are held accountable to. Now you can see four Forbes articles that are written about my work at the bottom right of this slide. It’s super tiny, but if you google Joe Justice Forbes, you’ll find them and then CNN Money, Fortune, or the Forbes billionaire club said this is how every company should train their staffers and how Harvard Business Review as well; you see that link at the bottom. So we have the ammunition now to keep executives interested to make this happen. Some of you may have seen me from the TEDx video where we built where we designed, built, and tested and sold cars in one week sprints. That’s how I got the attention of executives. That’s how I became known. Then some of you may have seen me on the news, primetime news, building cars in a day we got down to a day, working with Lockheed Martin Space Systems, working with US Air Force, the Australian Department of Defense, etc on these large projects.
Joe Justice Here’s my bio my contact information. I’m lucky enough to have been on Good Morning America and USA Today and Fox News. In Japan: The Asahi Shimbun and the Nikkei. I’ve been in Forbes Harvard Business Review CNN Money. I’ve had a chance to do a TEDx talk I’m now Chair of the Agile Business Institute. The purpose of that organization is to bit by bit, evolve a master’s degree for agilus, a Masters of Business agility, I was looking to get my own master’s degree, an MBA, a Master’s of Business Administration. I don’t have one, despite the level of transformation that I’ve been doing for six years. And I couldn’t find a single program that wasn’t still majority waterfall. Now, Harvard’s includes some iterative techniques and some Agile and some Scrum, as does MIT Sloan’s. I know that because I guest lectured at MIT Sloan on this; invited in. However, the majority of the curriculum absolutely doesn’t apply in the current world to an agilist’s mind. And so, there’s no way I’m gonna waste my time on that curriculum. I haven’t been able to get a university to switch full over yet despite the guest lecturing invitations. So, what I’m doing is attempting to build up an organization as its chair to the point it’s credible enough to issue a Master’s of Business Agility. And that’s the purpose of the Agile Business Institute. I still run wikispeed as a non-for-profit to deliver hardware really fast and in – right now we’re in the days of COVID-19 – I’m working with organizations to help them deliver ventilators, new hardware, ventilator projects, masks, personal protective equipment faster. And so I like to think we’re doing work worth doing and earning ourselves non-for-profit status correctly. I landed from Tokyo 10 days ago on my six-year-old’s birthday.
Birthday Recording “Happy birthday, Senna. It’s Papa! I just arrived in Seattle, in the United States, and I would love to see you and play with you for your birthday. Papa wants to make sure he’s not sick, so he’s going to stay, I think, at Debbie and Uncle G’s house for two weeks above their garage where he’s not so close to anybody, in case he’s sick, to not share germs. I’m making the video right now because I just landed, and right now I feel great, but I’m about to put a mask on, so nobody would even see my face.”
Joe Justice So this COVID stuff is pretty real to me, right when I landed, I went to a medical clinic in a place in Monroe, Washington in the United States and they divide the clinic into two areas. There’s Red Zone (they suspect you might have COVID) and self-reporting that I just landed from an international flight, I was immediately put in the Red Zone and then there’s the rest of the clinic; the other half. And that already was pretty… pretty freaky. You see a picture of the Red Zone right there below. It was like the movie “Outbreak.” Then they say, “Go get back in your car, so you’re not going to contaminate people and we want you to drive up to the white tent in the parking lot and wait there”, and I did.
Joe Justice Then the side of the tent opens, they have a heater inside like a sidewalk cafe, and someone in full protective gear, a full face mask, and then a PPE mask underneath that, and blue gloves, blue suit, blue booty covers – I could only see the woman’s eyes – swabbed my nose. It was really deep, it was really uncomfortable, and it was terrifying. The lady that did it was shaking, scared as well because what if I had COVID? And yeah, she’s wearing all that gear, and I could only see her eyes, but she was shaking. I was terrified; she was terrified. That was March 28. So, this was…this was eight days ago. This is super real to me. Because of that. I’m going to take a very different tactic with this presentation than I typically do in the boardroom or at a public conference. I’m going to mind what I promised I do in the abstract, and then do that immediately. Then we’ll see if there’s any time for anything else.
Joe Justice So, here’s the abstract: I have worked directly with executives -I’ll move the Zoom icon so I can read it – of many of the wealthiest, fastest growing, and highest-employing companies on the planet. I have also run one of the most famous agile startups of our time. I’m going to share executive strategy for Leaning a company while being respectful to the workforce. Okay, so I’m going to do that next, fast. Outmaneuvering company competition by releasing customer-visible value faster, and with higher perceived quality, without increasing R&D or production expense. Okay, that’s next. How to retain the top and most sought after talent without redefining HR pay grades. Okay, if we get to it, that’ll be number three. And how to increase employee voted manager effectiveness and engagement across multinational offices. This and other learnings all from real companies, and many with audited results, and all resulting in a simple ‘To Do’ list for your executive lead agile and digital transformation. All right, let’s make good time because this COVID stuff’s real, and we need to be being super safe, and we need to be pivoting our companies and helping each other. First, I promised in my abstract that I’m going to share executive strategy for Leaning a company while being respectful to the workforce. I’ll do this with tweets and I’ll expan- expound on it, That way, you can mine my Twitter if you want to read this later, if you want to share it. So if any of this resonates with you, here’s a pointer to pieces of it publicly.
Joe Justice March 25, I wrote, How to Lay People Off in a Crisis. My answer? You don’t. You fund projects only to the extent responsible and ask the teams to help you distribute the funding across as many staff and suppliers are willing to fully dedicate to said project or goal. Here’s what I mean by this. A lot of times companies are making 10% or less of their revenue from last month. That’s real, and a lot of them are laying a lot of people off really fast. Well, what does that do to morale? It’s bad for everybody. Even the employees that aren’t laid off have low morale and productivity goes to almost zero. So what’s a better strategy? Here’s what I’ve learned:
Joe Justice What you want to do is keep morale high, and there’s a way to do that while implementing austerity, while cutting revenue while cutting your losses financially, dramatically, and that you say, “Look, we have 10% the money we have last month.” So with that money, with that income, we have a 10% income, which is very real story for a lot of companies right now, everyone’s salary is going to be different. Now, if you’re one of the countries that had a massive government bailout, you might not have to do this because maybe your revenue didn’t drop; maybe the bailout filled in for that. Not every country has that option and even those that do not every company qualifies or knows if they’re going to qualify yet. So if you have 10%, the run rate, you say, “Staff, here’s 10% of money; here’s our three most important projects that are going to help other companies, help our suppliers not have to lay people off, and we’re not going to lay off any of you. But it’s 10% of the total money. This project gets 5% this project gets 3%. This project gets 2%. That’s it. Tell me which one you want to work on and we’re dividing that money across however many people sign up for that; that’s your salary.” This way, no one gets laid off, no one gets fired. morale stays high. people stay engaged, and they’re even more engaged to the high priority project, which might be making ventilators now or making face masks now. This is the way to pivot your company without creating morale. Second, how to cut costs and not destroy morale? Fund projects or goals, not people. So it’s not, “Hey…so-and-so, your salary is 10% of what it was.” That’s not how this works. It’s, “This project is the one important project for our company right now. This is the only supplier that’s still able to fulfill their our orders; this is the only product we can make, whatever the decision is. So this is our one project right now. It only makes this much money. We’re going to divide that across all staff” And this is going to be a two way conversation. “Staff helped me come up with a plan of how we’re going to divide this amount of money this month, across all of you.” With that two way conversation, it’s not, “Oh, my, my salary just got cut 90%” it’s, “We’re doing this important thing so our suppliers don’t go out of business and have to lay people off; and because I’m doing this, I didn’t get laid off.” It completely changes the conversation.
Joe Justice Now only people who agree to fully dedicate themselves to the project get funding. Then, funding isn’t distributed as normal paycheck style before. If this is severe austerity, if your company needs severe austerity, and many of them do right now, several companies are going out of business right now; like, during this conference. If you’re in severe austerity, then you only release funding to be distributed across everyone who worked on it, when funding tests pass. In traditional management speak, you can call it a milestone, but like every presenter in this conference has talked about very importantly, and well said, is: it’s not a milestone that’s only the plans been made or we’ve built a module. It’s only when a test passes. Think of these each as a Lean startup. We have to have something we can test or something we can use before we can release any funds. In severe austerity, you can only fund outcomes; that’s been said more than once today. Next, if you want to go into more detail, tweet me so we can have a public conversation about it; LinkedIn is also okay. If it has to be private because of company reasons, you can email me but I far prefer to just be open that way everyone can learn together and we can all weigh in; everyone who attended this conference or spoke at it can be part of that conversation if they want to, and the whole rest of the world.
Joe Justice Next topic. I promised, we’d talk about outmaneuvering competition by releasing customer visible value faster, and with higher perceived quality, without increasing R&D or production expense. Okay, here’s what I’ve learned. First, the public info. I tweeted, “How to respond quickly as an organization in a crisis? Well, that’s the time to go from making a decision to producing a new outcome (maybe a product, say a ventilator). The speed that happens can be called a ‘sprint’. For some businesses, a sprint is ~7 years. To shorten-” Team Wikispeed tweeted, which is also my account, “Our response cannot be faster than our supply chain. If for credit critical supplier takes four months and ideal times and 18 months in emergency times, our volume response cannot be faster than 18 months during a crisis. So practice extreme manufacturing and shorten your hardware sprints.” Note, in most companies, the decision of what supplier we use is ultimately made by procurement where the top incentive is low price and speed rework, risk reduction lose, and the crisis kills the company. This is very normal. This is happening all over the world right now. To solve this, again, this is an executive mandate and continually checked and reestablished. Here’s what I mean. If we’re in a transformation that’s not executive lead, and we have suppliers that, in a crisis are taking 18 months, we can’t fix that without an executive mandate because we need an executive mandate to change the way procurement is incentive on supplier approval. So you can’t fix it without executive intervention and that is why I’ve been working with executive teams almost exclusively the last six mont- six years. Now, a note below for people that want to get a little more hardware specific, this is my specialty. This rules out stamping and molding from design in most cases. Many ways to do both with a new design in one day, like Wikispeed, is proven. Most suppliers in crisis will queue and send you a defect mold, or dye, months late requiring sending back a second or more… more multi-month wait.
Joe Justice The solution is you bring it in house like Tesla or SpaceX does where you make your own molds or stamps and dyes. Then. you can control the speed and the feedback loop or you prioritize suppliers not strictly only by cost, but by cost and response time, which gives a completely different supplier set. Now, working with suppliers that are far away from you geographically adds to this. If your parts are on a ship for the next four months, that’s part of your supply chain. And if those ships are now in quarantine, because the Conex containers need to be disinfected thoroughly before they’re allowed in by your government, well, you’ve indefinitely sabotaged your supply chain. So if you’re a Ford, and you want to pivot from making trucks to making ventilators and your supply chain is 18 months, you’re you’re going to fully lose all 18 months worth of money that’s already been spent, and you might die as a company. And this is happening right now all around the world with some of the biggest companies in the world. And it’s only massive government intervention that slowing down the death of these companies. So well, we’ll get to the next point the next. So that’s why executives need to be involved to solve this problem. Here are the executive practices; this this talk is on executive lead agile transformation for companies that are flailing. This is the best of what I’ve learned what you need to do, and I’m happy to learn better. Everyone in this conference, please teach me; here’s what I’ve got. Create a rhythm of making new priorities. Now this needs to be a rhythm so it’s not a panic each time. It needs to be collaborative so we don’t lose innovation from the bottom. So change or reconforming isn’t an unexpected stress. A good format is Meta Scrum as written by James Coplien. Then create a rhythm of measuring progress you can fund in a crisis a plan is not yet a solution. So if we give funding just when plans arrive, we can run out of money and not help anybody or ourselves. We need to split our Crisis Response into the smallest chunks we can reasonably ideally day sized deliver. Now this is where a lot of hardware companies say, “Well that’s impossible! It takes us 10 years to make something like a ventilator. Well, then you need to take my Wikispeed Extreme Manufacturer class, so you can know how to deliver hardware in a day. From design, test, to deliver in a day. I’ve done it, now Tesla’s doing it and it’s public on YouTube; I’ll show that in a minute. In fact, there’s many ventilator companies and COVID test companies that are suddenly delivering in less than a week, even though they all told all their investors, “It takes at least eight years” before as part of a ploy to get more government funding. And now when we’re all in this together, all around the world, suddenly companies can deliver in less than a week in hardware and they always could and they always can. So everyone, please don’t forget that companies are delivering less than a week in hardware. Brand new products with new design, tested, even meeting FDA regulation in less than a week.
Joe Justice Next, accelerate the solution ask, “What would speed up teams on a rhythm” so the ask is less of a disruption? See The Scrum of Scrums Pattern for this by James Coplien. Establish a leadership coalition that monotasks one of these impediments at a time until they’re fixed; Kaizen training helps here. So, executives that have been through lean training, Scrum Masters who’ve been through lean training, are incredibly valuable, even in a company in crisis under austerity situations in an executive lead agile transformation. Next, this is an impossibly high stress time, an executive activity is to reduce stress. First, that helps us the rhythm. Two: the public, clearly defined goal. These can’t be backroom conversations. These have to be billboards on a wall. These have to be everyone’s desktop backgrounds. These have to be everyone’s phone backgrounds. If they’re going to be in the company doing this in a crisis. It’s got to be complete ubiq- completely ubiquitous what the clear- clearly defined goals are. The funding paychecks need to be directly tied to results; reasonable and just even in a crisis with heavily constrained funding. Progress invisibility due to small, invaluable initiative size. So we need small goals split into small chunks, ideally day-sized, even in hardware. I know, I know, a lot of people don’t believe it but just look at what’s happening now, it happens and I did it with my company, so I’ve seen it too.
Joe Justice Then staff buying helps reduce the stress. We do this by inviting anyone to lobby for a higher priority against the Meta Scrum pattern by James Coplien. Now this pattern is evolved a lot recently, especially in my work as the rubber is meeting the road right now, so if you want updates on how to run the meta Scrum pattern effectively in a crisis, or we’ve learned what works better in any case, because of the crisis, you can tweet me or Facebook. We can have a call with your executive team or a video chat with your executive team. We do this on a cadence and the justice of staff portioning salary for the project funding budget, knowingly funding distributed only at outcomes. Here’s what I mean by this: kindergarteners have been measured, that they become most disenfranchised, or emotionally upset, when they see an injustice and it looks like it doesn’t go away after kindergarten. It looks like this is built into humans as a species. We really care about what we think is justice. So especially when we’re talking about funding, which has to do with how our kids go to school, what we get to eat, like it affects our lives in a significant way, if we believe this is being done in an unjust way, we completely lose buy in and in a crisis, we go into panic mode where we can. So to prevent against, that to keep morale high, having the financing discussion up front, which is what I talked about in the previous section, is completely important to keep engagement up.
Joe Justice Next, machines and engineering practices and test practices. This is where the real speed comes in. Everything else I talked about was simply refactoring the company according to an evolved version of Conway’s Law, that…I do now call Justice’s Law, because no one else has said it yet; and you can learn all about that in the full seminars when we have time together. But in any case, it’s the structure of the company that dictates the speed and the executive piece is creating that structure but that doesn’t suddenly make it fast. It allows the technical practices, the engineering practices, and the machines to do their work; to be fast. So the without the executive intervention, this can’t work but only the executive intervention doesn’t change the speed. So if the executive intervention happened, what changes the speed? That’s the machines and the technical engineering practices. It’s the same in software. You can have the best impediment-busting executive teams that had been poor empowered cross functional self organizing teams, but if the teams are still doing doing procedural code, with no end capitalization, no Object Oriented Architecture, no test driven development, no automated compile, and they’re compiling by hand, it’s gonna be slow…and that’s where a lot of hardware is right now. So for these practices, see Paolo Sammicheli’s book, Scrum for Hardware. The second half of the book chronicles exactly how to do this. The first half of the book is the story of my life and Paolo’s life. Yes, I think it’s interesting but it’s not going to make your company faster. We’re in a crisis; skip to the second half of the book. The book is available on Leanpub. The first few sections of the book are free. The second half, which has the most technical practices, it’s not in the free section; you will have to buy it. It’s going to be worth it.
Joe Justice Simple To-Do’s, engineering practices… note, many engineering leads and design leads/leaders, leaders of these groups, managers, directors, do not have authority or autonomy to mandate the practices I’m about to talk about. And serial, slow, multi-regression stage gate processes result as the default. So these must be executive mandates and checked, reinforced, and reinstated. This is executive agility. So with that said, with me again stressing the executive role, let’s see, ‘What are the engineering practices that work?’ First, this is the first one that people throw up their hands and say, “We couldn’t do that!” and yet it’s exactly what the fast companies are doing right now. You can see what Tesla just did building a ventilator on version two in 18 days, and this is exactly what they did; it’s on YouTube right now. It is only use materials and machines that you can receive completed parts from in less than seven days. I’ll say that again. Only use machines and materials that you can receive completed tested parts from in less than seven days. Companies have built their entire existence around global supply chains with 18 month lead times, and they say, “Well, how can we ever deliver something less than 18 months?” Well with that structure, they can’t. It’s true they cannot but if you take this step, which is a real actionable, profitable step, you can deliver in less than a one week sprint. So, now let me continue. Waterjet cutting, milling, 3D printing, Arduino boards, and similar complete commercial off the shelf boards with standard interfaces, these are going to meet the lead time of less than seven days. No special coatings or processes are allowed. If it cannot, in a crisis, reliably arrive in less than seven days. That’s it. And I get all types of designers saying, “But it’s a better part if we use this coding” and I say, “That coding is only available from one supplier, and in a crisis right now they’re not responding to anyone, you’ve just compromised your entire company and you’re going to get laid off. How do you feel about that? Now…so it’s not being an engineer, as an engineering practice, who says, “But I figured out the best coding”; it’s not that. It’s, “Of the subset that we can get in less than seven days, what’s best?” that’s the agile mindset for hardware. Then we queue suppliers up to the interface of a module; people who are familiar with contract first design, Object Oriented Architecture, test-first development to the unit to the units and its interfaces…this is your world; this is your party. At some point, I will write a book on hardware patterns. I have been saying that for years; somebody please just… write it with me. We’ll do it in a series of video chats because I’ve never prioritized it and I need to; it doesn’t exist. Hardware Patterns, Hardware Interfaces is only in a series of video chats by me around the world and conferences. But it needs to be a book so people can refer to it easily and search it. But we give the suppliers the test to pass and the interface, not a detailed design. This enables their innovation and fastest response time. Next Paolo Sammicheli and you see his Twitter at the bottom, @xdatap1, he wrote twelve executive, mandateable engineering practices designed for modularity so that the organization can execute in a massively parallel fashion; architecture examples and principles are in the book. This has been demonstrated, documented, and audited to be over 1000 times faster than sequential phase gate engineering. This is known it exists but you have to re-architect the company to do that and that requires complete executive buy-in; only a few companies have been brave enough to do that so far.
Joe Justice So here’s what it looks like. This is designing, building, and testing a car in 27 minutes. If it’s a standard operating procedure, it needs to be a robot that’s doing it. This is the what’s wrong about the E-Myth, which is taught in all businessn schools right now, so the executives that you and I are talking to, they’ve been trained in the E-Myth; all business schools do. And the idea of the E-Myth is build your company so that a 16 year old can do it. Establish standard operating procedures so someone can walk in with no training and do most of what your company does. Well, that kills innovation. It kills the agile mindset and people show up to work dead like cogs, and in a crisis, they all get laid off in the company goes under. And we’re seeing this all around the world right now. So what’s the answer? If it is a standard operating procedure that doesn’t require innovation, a robot should be doing that whether it’s a script or a physical robot depends on the thing you’re doing, but slps are not for humans. This is again, where speed comes from. Groups of humans are for all the stuff that isn’t a standard operating procedure, the design cycle. Now, they’ve got to be at the point of where the work is done and at the point of where the test is done, so they have a fast feedback loop. Virtually? Fine. Make sure they have a camera on the point of production and the point of test. Here’s Bosch; here’s the real client doing this. This is sprint one. For more detail on this take the Scrum for Hardware class so we can save time.
Joe Justice Let me check myself on time. Okay, we don’t have that much. In Sprint 1, they built this piece of equipment that goes on in front of a train. This is one week. You can see the next four sprints. On the far left is week two. They had poor sensor performance, so they established a wiper to handle inclement weather. In week three, Sprint 3, they refactored the circuit boards inside, the embedded software, and changed the wiper for better sensor performance. In Sprint 4 they tried a 3D printed enclosure and they also got it quite a bit smaller. You can see a seam of where the 3D print line was and in- by Sprint 5 the sensors were good enough – and really it was the software compensation of the sensors that they didn’t need a window and a wiper anymore – and they were ready to go to market. That’s five sprints at market Every single sprint was tested on locomotives, real locomotives asking real customers, “Is this improving your problem or not?” This was not an MBA driven exercise, “What if?” This was going out to train yards and solving a specific problem. Again, the details are in the class when we have time to do it. Which problem is being solved here?
Joe Justice How to retain the top and most sought after talent without redefining HR pay grades. I’ve been running into this with artificial intelligence labs where these people can basically ask for the salary they want and work anywhere they want in real time, and that’s been going on for six years, even before crisis. But now it’s happening at an even accelerated degree because of the COVID epidemic, pandemic rent. So here’s the simple To-Do’s that I’ve learned that help retain top talent without redefining HR pay grades. First…well, really the parent item is increasing engagement and fun. That’s the principle. How that’s done depends on the people and what they think is engaging as fun. Here are examples that often work. If you’re using Scrum, rotate the product owner Scrum Master and development team member roles each sprint. Everybody gets to play all three roles in turn. This keeps people engaged and excited, regardless of salary. And they say, “Well, we all get to be Product Owner”, which some of them still map as a senior position, these are all on the same level in reality. But it…this sense of equitability and justice keeps people excited. Then, run a happiness retrospective. Any of the many tools for happiness retrospectives. The online tool FunRetro helps us do that in these remote days and these quarantine days. Then, toss out suggestions that are outside the ability to implement next sprint. Now ability can be it was too expensive, or it’s outside what the company uses its norms, or it’s too difficult to implement in a sprint; any of those reasons are valid. Now what’s left are only suggestions that we all agree can be in the next sprint. Take one of those and do it in the next sprint. By doing that every sprint velocity stays high because part of the work that the team does with their same points measured with the same velocity, however you’re running your agility, your agile teams, will process that and keep morale engaged and high.
Joe Justice How to increase employee-voted manager effectiveness engagement across multinational offices. This came from my work with John Deere. They measured themselves at 8.2 faster, and before the work we did together. So that’s 820% and their managerial effectiveness in this group in the company had previously been 1%, the bottom 1% of the company, and it went to the top 10% of the entire company and here’s what they did.
Joe Justice Make management backlogs and KPIs and OKRs visible with names on each. So now, the employees know what the top managers are actually measured on to get promoted; if you’re even in a hierarchical company. when I work with companies that are much more flat, like parts of Bosch now or Netflix, it’s simply, “What are the KPIs and OKRs that fund the company, that keeps us getting paychecks” and it doesn’t have to be from senior leadership because they don’t have senior leadership anymore. Not the same way. In John Deere, they definitely did. So there’s a name of a manager; here’s what they’re measured against. That’s public and the KPIs and OKRs are updated as soon as there’s data; whether it’s a quarterly audit, or in some cases in real time, depending on the sensors. Ask teams to self organize around those goals. Now the managers know who their teams really are. Now, this is part of Conway’s Law. It’s not who reports to them. It’s who self organized around their objective. Now you know who your teams are. Instead of commanding they’ve pulled; you’ve created the power of pull, which was well written in the book The Power of Pull, Then run Meta Scrum patterns to refine the management backlog. Otherwise, we only have top down innovation and what we want is innovation from from every part of the company. So we invite the teams to refine the backlog, inviting new ideas from anywhere in the organization. But it’s not anarchy, it’s not everyone does only what they want. We want a very small list of prioritized missions, especially when there’s limited funding like there is now. So it’s only if the people who are making the funding decisions, and whether that’s a group vote across the entire organization, or you actually have something called a manager or whatever the structure of your group, whoever determines – whatever the mechanism for determining funding – has to determine the new idea is more important than the existing proposed ideas. So when I’m running an initiative, I bring my understanding of the highest priority items that we could do as a group, and I post them as Post-it notes on the wall, now I have to do virtually, and I say, “Everyone, if you have a better idea, give me that post it and then try to explain to me why it’s a better idea. We’re going to do the top three only,” and then we have that conversation which is part of the evolved version of the Meta Scrum pattern. I’ll add a bonus piece, how to weather a crisis. You remove all recurring expenses. If you lease buildings, those are the companies that are going out of business first. The restaurants on our lease are going out of business faster right now, all around the world, than the restaurants that owns their space and didn’t have a lease payment. I mean, that’s it. In a crisis, your run rate is how long you can make your recurring payments. So you eliminate your recurring payments. If you can buy out the things you’re renting or leasing, buy them out. If you can’t, you’ve got to get rid of them and simplify. In a crisis, that’s what you do; that’s austerity. Here’s what I did. I started living in my Tesla Model three. I put a mattress from Amazon in the back – for those of you that want to know about that, it’s an extra long twin on Amazon for $69 in the US – I put a cooler in the front seat, and a laptop and my cell phone as Wi Fi. And I drive around the world where I was. I’m in quarantine right now for another eight days; self-quarantine. My COVID test did come back negative but I’m in self-quarantine for 14 days after I got off the flight after I wasat an International Airport. So once I get out of quarantine, I’ll go back into my Tesla. And it works as a mobile office, a mobile hotel room, and before quarantine, I would go to racetracks around – in this case the US, that’s the that’s the area where my Tesla is right now – and I participate in Tesla racing series. So I’d have a crazy amount of fun and it costs nothing. The superchargers, they were free because people bought Tesla’s using my referral link. Now, I’m finally paying but it’s still like one 10th the price of gas or even less. So it’s basically free. Like driving full time…it was…$40 a month? It was…it was ridiculous. So dramatically simplify your life in a crisis.
Joe Justice I’m Joe Justice that is Executive Led Agile Transformation. To summarize, to keep executive attention, everything we do has to be to the point of increasing return on capital. Otherwise you get laughed out of the building. That’s it. Then the company structure would actually make speed as the tools you use and the engineering practices you use. That’s all written in the book Scrum for Hardware by Paolo Sammicheli. The second half is what you want to be able to do that the structure of the company has to change a lot. And that’s the executive transformation practices that I’ve just enumerated. You can mine them on Twitter, you can see them in the Forbes articles below, and tweet me anytime, folks. Stay safe, stay healthy. This is a really interesting time and I will make a personal plea that I hope we create a new normal. The world is different right now and it will never be quite the same. I’d like us to take this time to think about what’s actually essential, because almost all of us have been deemed non-essential by the world’s governments; and we weren’t. And…so what can we do that’s essential and how can we expand our definition of essential to include things like education; things like time with your family and kids? How do we, how do we refactor that? And how do we take the best parts of what we’re learning with this new online lifestyle, to make a healthy, loving, respectful culture that’s global? And I have no patience for nationalistic response; there’s many people dying in this country, this testing, this ventilator group in this country. What we need is a global mindset period and it might be a good time to rethink currency.
Joe Justice Here’s a question company that’s growing by innovation. This is pre-crisis. You can see quotes from their leadership team on the right and you can see they’re growing by prioritizing only how fast they can deliver cool stuff to the customer. Everything is about shortening the sprint length. This is Tesla. I’d like to compare that to the growth of a company that’s growing by continuous improvement. It looks like if you want growth, the one goal is shortening the length of your hardware sprint. That’s it, and that’s what Elon Musk says is the one goal of the company. Now what happens if you throw a crisis at it? These are the same two companies now.
Joe Justice It’s still better. Now, here’s the timeline I’d like to end on because I think this is the serious point that matters. So first, you’ll weather a crisis better if you have shorter hardware sprints and you’ll make more money and grow faster if you have shorter sprints and it completely blows away and makes irrelevant traditional Lean continuous improvement thinking. Now traditional Lean continuous improvement thinking as part of making short sprints, but alone, it does not give growth or survivability in a crisis.
Joe Justice So, what happens? On March 18, Elon Musk tweeted, saying “SpaceX makes life support systems, which include ventilators, and Tesla makes HVAC systems heating, ventilation and air conditioning and cooling systems that have some components that are like ventilators, maybe we can help.”
Joe Justice On March 19, they went to the customer they use the Agile practice – this is a full agile hardware company – they went to the customers and these hospitals and said, “What do you really need?” Not, “What can we sell you?”; “What do you really need?”
Joe Justice On March 21, there’s a discussion with the current believed-to-be best in industry on ventilators, called Medtronic, and the conversation was only, “What is the state-of-the-art. What is the best known about ventilators now?” So let’s not reinvent the wheel, let’s make something better.
Joe Justice March 22, while other companies were saying, “We’ve reprioritized to deliver only COVID response” but they couldn’t. They had 8-month lead times with their suppliers; they made executive announcements but no impact. Already there are 50,000 masks delivered to where I am now, Washington state in the USA, and PAPR helmets. So this is three days later and there’s already volume relief while other companies are still having board meetings about it. March 23, California governor confirms ventilators are delivered and so the Musk companies bought existing metal ventilators and shipped them already in four days.
Joe Justice March 25, ventilator in-house design begins. They say well, now we understand the state of the state-of-the-art. We’ve already bought all the existing stock and gotten it to hospitals. Now we’re going to make our own because we’re out of existing stock, we can’t buy them anymore.
Joe Justice March 26, they started delivering ventilators that they bought while they’re designing new ones. March 27, they committed that all of those are going to be free; they’re not going to charge any money for these things. March 31, New York City hospitals received the ventilators, they bought April 3. Doctors in other areas are saying their ventilators are being received on.
Joe Justice April 5, this was yesterday, there’s the sprint demo of the second version of their in-house-built functioning ventilator. So that project started March 25. April 5 was the second sprint demo. You see a screen capture of it in the bottom. That is the Tesla in house built ventilator and people saying we can’t have hardware projects that aren’t FDA approved in less than 10 years, 18 years – these are actual numbers I am being told by clients, sometimes 21 years – SpaceX did it, sorry, in this case, Tesla, had the version two in 18 days. How did they do it? It’s exactly what analysts have been saying the whole time. They refuse to work with any material or any machine that can’t give them a tested product in less than seven days. So that means 3D printing, waterjet cutting, commercial off the shelf parts parts they already use – you can see the screen is the touchscreen from a Tesla Model 3 because they’ve got warehouses full of these things and they know how to make them; they know how to get them fast. So it’s not that it’s the best product or the cheapest product. It’s the one that’s fast and it still ended up being cheaper than anyone else’s ventilator because of how fast they did it. You can watch the sprint demo at the link at the bottom right. I’m Joe justice. Thanks for learning about Executive Led Agile Transformation; which also included, in this special edition, COVID in a crisis. Thank you, everybody.
Host Right. Thank you very much. So we have just two minutes left. So if someone has a question you’d like to ask, go ahead and drop it in the chat box and we’ll take the first question that comes up that way. We can get things in before the end of the session. And thanks, Joe. This was this was a really, really great presentation. A lot of fascinating information and I love that you were able to show us new ways of thinking about hardware. And…. *laughs* How do you receive mail if you live out of your Tesla?
Joe Justice Yes, there’s a number of services. I finally found one in Japan but the US has had them for a while and I believe they exist in Europe as well. They’re mail scanning and forwarding services. So they have a P.O. Box for you, a registered post office box and – or they can even make it an office address legally or a residence, in some states, legally. So you can use it for any type of mail that you would a house or an office. What they do is they automatically scan every piece of mail you get, and you get a text message or an email, everything. If it’s a check, they automatically deposit it, you don’t have to worry about it.
Joe Justice It’s a package, they say, “Which pickup location do you want us to forward this to and on what date?” And you can use the locker services around the world. In some areas, you can have it delivered automatically to the trunk of your Tesla and they’ll put it in your trunk. They get a temporary passcode as the credential carrier. And when you’re back at your car, it’s already in the trunk for packages; I can even get freight that way. Large, you know, like 400 kilogram things. So we’re completely decoupled from traditional addresses now.
Host Awesome. That’s it. That’s fascinating. Thank you very much. Well, thanks Joe, for presenting. Really appreciate your contributions to today and this concludes our Best Agile Articles of 2018 Conference and don’t forget that we have, in the chat, the feedback for Miro for the presentations, and then I’ll open, one last time, I’ll relaunch our live poll. If you could take that and give us just a quick visual of your thoughts about today’s session. And Joe, we really appreciate you hanging in there with us to be the last presentation of the day. I’m glad that I stuck around because this is fascinating. And to everyone else, thank you very much for attending and we will send out the PDFs and links to the recordings. Once those process give us a few days just because we also have other jobs that got put on hold today that we have to go back and check in on. So we’ll get those out to you as soon as we can in the next few days. And we appreciate your attendance, we’ll be doing another one of these conferences in another quarter. And we, we intend to do one each quarter on by pulling different people who are writing for the book. And we are right now working on best at all articles of 2019 and we expect that to be released somewhere… August-y; somewhere up in there, we don’t have a drop dead date but we are at this moment making selections of the articles that are going to be in that book. So thanks for joining and you all have a great week.
Joe Justice Thanks, everybody. Take care. Stay healthy.
Host Thank you
Best Agile Articles 2018 is a collection of articles from a variety of authors published on topics of all things Agile in 2018.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Tricia Broderick gave during the workshop on the topic of challenges that leaders face personally
Other Best Agile Articles 2018 Posts
Agile teams and ways of working are proliferating in today’s work world. The Agile Manifesto touts “people over process and tools,” and the principles mention, “build projects around motivated individuals, and trust them…” and “the best architectures, requirements, and designs emerge from self-organizing teams.” But how can we hire the right people and best use the people we have? Heidi will discuss the criteria for hiring a great agile team and for growing a more high-performing team; drawing from experience from her extensive background in teamwork and collaboration, and pulling from sources such as the Google Aristotle study, Patrick Lencioni’s Five Dysfunctions of a Team, Stanley McChrystal’s Team of Teams, and others. Attendees will leave with concrete ideas on how to find the right candidates for teams (even distributed teams!) and how to work with existing team members to increase levels of self-organization, collaboration, empathy, and teamwork.
Best Agile Articles is a collection of the articles from a variety of authors published on topics of all things Agile. The Best Agile Articles book series collects the best agile articles published during a calendar year into a single volume. You can download your free copy of the ebook from our website or buy a paperback copy from Amazon. If you would like to subscribe to the soundcast of these talks, head to Soundwise.
About The Speaker
Heidi Araya (MBA, PMP, SAFe SPC, CAL, CSP-SM, CSP-PO) works with leaders, managers, and teams to improve product delivery and business operations through Lean-Agile ways of working. Heidi’s expertise includes Lean-Agile Portfolio Management, Agile Transformations, Agile HR, and Business Operations.
Heidi was the Director of Agile Transformation at Tenable, and previously led the Agile transformation at Cofense. As Product Owner for a government contractor, she led the first Scrum teams to deliver a successful product at NASA Kennedy Space Center in 2010. Leveraging over 20 years of experience in process improvement, project & program management, and organization design in a variety of industries, Heidi has led multiple organizations to improved products and better business results. Heidi has been working remotely and with distributed & global teams since 1999.
Heidi lives in Orlando, Florida and is a confirmed serial hobbyist who has dabbled in drawing, ballroom dancing, jiu-jitsu, tennis, reiki, and other hobbies she’s probably forgotten. She speaks at national/ international conferences and meetups on technology, Agile, DevOps, and business topics. Her forthcoming book is “Team Coaching with Open Patterns.” Her articles were included in a book, “Best Agile Articles of 2018.” She received her MBA from Aspen University and her BA from the University of Maryland College Park.
Heidi Araya So I’m just going to tell you a little bit about why I’m here, um…and that goes to the second slide. We’re hiring for the wrong skills, I discovered that folks are still hiring for technical skills or other skills that…that…that don’t – they’re not as relevant in agile teams, right? So what do we need to hire for? What do we need to start looking for, in-when we’re hiring for a team; and the second thing is, who makes the decision? I had people join my team, that it was like, “Oh, hey, Mary is starting on Tuesday,” like “Oh, who’s Mary? Oh, it would have been nice to meet Mary and interview her and maybe get to know her. She’s going to be working together with me and that’s just really frustrating to me.”
And so that’s why I developed this talk I’ve got over 25 years of experience in technology; been 10 years, agile starting off at product owner at NASA rescuing a failed project. That was really fascinating story but I’ve seen firsthand when hiring goes wrong and what’s really required for teamwork to happen. So I…I’ve researched deeply – like the Richard Hackman stuff, the Google Aristotle study, Patrick Lencioni’s work and other leadership development profile work, Keegan’s work – and put together this talk to try to help us hire better, and understand that. So I told you a little bit about this, like you weren’t even involved in selecting your two new teammates is so frustrating. Um, earlier this year, when I was interviewing, I had two 30-minute phone calls and they were like, “We love you. We want to hire you” and I was like, “Wait, I didn’t…I didn’t get to ask any questions; I didn’t get to meet the team.” They’re like, “No, no, we always make good decisions with two 30-minute interviews.” I was like, “Yeah, y-you do but w-what about me? *chuckles*
So I felt like there was something really, really wrong with this hiring process and why; why do we hire this way? Um, and I-I link it back to this scientific management Industrial Age, where Frederick Taylor was separating the thinkers from the doers, and he was a brilliant person, you know, to think of all this stuff, and he designed experiments to determine optimal performance levels. He experimented with shovel design until he had a design that would allow workers to shovel for several hours straight. While the other side of the coin was, well, it didn’t matter if you were five foot eight or six before you saw the same shovel, and you were still expected to do the same amount, but for first time ever, managers were monitoring workers performance and style and providing instructions and supervision to ensure that they’re doing their most efficient way of working. So the first time ever, there was a separation from the deciders and the thinkers and the doers. Now, you can read about his theories in detail, but he actually knew that what he was doing was reducing engagement. But he was accounting for that by paying more. So the legacy that we’re paying for now is these strict job descriptions that aren’t taking into account our-the whole human being.
My experience is so different than Cherie’s experience is so different than anyone else’s experience. Why are we still expecting to adhere to rigid job descriptions? Um, traditional managers are often used to just telling each individual on the team what to work on. Of course, this is creating a host of problems for Agile teams, as managers try to figure out their new role here. But even now, on LinkedIn, I see recruiters say, you know, “I’m looking for this kind of resource; like a Java programming resource.” We have individual performance that’s rewarded over team dynamics and delivery because team-teaming aspect here is so new and, honestly, no one’s thinking about that over individual performance. The reality is no one single individual can actually be successful at work anymore with the kind of work that we’re doing – especially I know that Agile coaches feel this pain keenly. Of course, then there’s a big conversation happening on LinkedIn about how Agile coaches can can show their value – um, and what does that lead to?
Lack of engagement. If management decides everything, and like you couldn’t imagine the rest of the day, the whole team when it was like, “Hey, Mary, starting on Tuesday.” We were all like, “Oh, who’s Mary? I- I didn’t get to see her resume. What’s her last name? Could we look her up on LinkedIn somehow?” That creates disengagement and disengaged workers cost 34% of their annual salary. There’s lots and lots of decisions, why we want to engage workers in the decisions, and that’s because they’ll stick around if you ask their opinion, and oftentimes make much better decisions. Right? We can’t have individual people making all the decisions anymore. It should be a team hiring decision for many, many different reasons. So we got to start hiring differently.
83% of workers say they now work in teams – for all the people that we work with, I’m sure it’s almost 100% – and that over half of their time is spent actively working together. This is in a study of over 800 companies around the world. And, as you well know, we need teams now to deliver continuously to customers, to sense and respond to market changes, to rapidly innovate, and have a learning culture; and these are such different skills than just saying, “I need a resource that’s a Java programmer.”
So what I found first off in the hiring process is, if you’re in the middle of a hiring process now, is take a-take a pause, clarify the hiring process. Oftentimes, it is not even been made clear to people who are part of the hiring process pipeline. I know for me, when I was interviewing it’d be random selection. Sometimes I’d get called in and I wasn’t…um – a few years ago, we were hiring for a Scrum Master over a few teams, and the VP just said he wanted to sign off on the final decision, just meet her and, you know, it was no big deal. There’s no way he would ever gonna say ‘No’. Well, I’m sure you can predict the end of the story. He interviewed her. He was like, “No, she didn’t answer the one question I wanted her to answer properly. She didn’t have experience and I’m going to call no on this.” After a really lengthy hiring process, where we had her do exercises and everything. We were so, it was actually my-a referral, that-that people were just so upset that happened. So who makes the final decision and who’s involved? And if you haven’t clarified that, I would encourage you to start there, and, by the way, that’s one of the Open patterns for Open Leadership is basically: clarity around these kinds of things. What kind of format is it going to be? Who is-who are all the people going to be involved in and what’s the ty-, you know, I encourage you to map it out on a Kanban board? What does that process look like? Um…I will say, by everyone, I also mean the candidate, we’re here to help the candidate be successful, too. It’s not supposed to be springing some surprise upon them. But-so I always shared the…the process with candidates as well, so they can be prepared and…and just chat with them a little bit about the expectations that we’ll have in the hiring process.
So why are we hiring? Why does this need come up? If you’re hiring for tech skills, right, they rage a-they age rapidly. Or are we hiring for right now? Or is this some need that we’re going to have in the future and how will this person fit into our plan, our strategic plan for the future? What problems is it solving for us to hire right now? But moreover, what behaviors and traits are we looking for in this person? So, resumes – you can look at a bunch of them; I’m sure you have – they don’t reveal the person’s mindset. They don’t reveal what kind of human that person is and that’s where we really have to start digging in and just understand that a resume is not going to tell you everything. So how can we get past just the resume? Here’s what I’ve done. I’ve involved the whole team in candidates. Of course, you would look at some of the candidates, the ones that were just applying to whatever thing, and you can probably eliminate a lot of them, but a lot of them, I just would send onto the team. I had a team of Agile coaches, and we would do a team review, and we would just timebox the time, and we would just chat and decide together. For lots of, of course, Agile coaches and other skills, they may have shared stuff on GitHub and Twitter and LinkedIn, so find a way to bring more of their personality and what kind of person are they? Do they-are they going to align with our thinking? What have they already shared out there? And even give them a quick call. A lot of folks are just really reluctant to…to even start a conversation with someone outside the official hiring pipeline but when I did that, I learned something. The other thing you can do, if it’s not allowed in your company, would be to have a…have the recruiter, if that’s in your pipeline, give that person a call and ask them that question and just just try to understand more about them than just the resume; maybe even before you screen them out when you have questions.
So digging right in, what skills do we need for teamwork? Things like emotional intelligence, trust, ability to learn together, etc. and you can read these things. But in-a Google study actually showed that technical knowledge was not even at the top of the list of helping teams to be great. It was psychological safety. It was emotional intelligence, reliability, navigating roadblocks; it was those kinds of things. So we should be hiring for those things. These are like, of course, you know, lots and lots of double blind studies. What personality traits are we looking for, right? Are they empath-do they have empathy for others.
So what wasn’t important in the Google study? Actually, colocation didn’t end up being important. The kind of decision making even even though we advocate for some kind of good decision making technique, consensus driven decision making, didn’t end up being important. How extroverted or introverted the team members were, that wasn’t important at all, in this study. Um, or individual performance of team members wasn’t uh,was-or even seniority, right? So thinking about these other soft skills that we often forget. So how are we going to, so to speak, test for these when we’re hiring?
So when you got the candidate, imagine that you’ve got the candidate ready and you’re, you’re preparing. So give them an assignment related to their day-to-day work. We had coaches run through a facilitation exercise; some kind of collaborative exercise. Um, and it’s interesting because at the end of one exercise, I paused, and I asked the person if he would like some feedback, and he goes, “No, thanks! I’m all good.” And I was like, “Oh, well, if he’s an Agile coach and he didn’t actually want feedback, well, that, that may tell me a little bit about his mindset. And by the way, if you’re on the interviewing side, if you suddenly ask for feedback, you’ll find out a heck of a lot about the place you’re interviewing. Um, I began to do that about a year or two ago and I just found it really invaluable to ask for feedback when you’re going through the interview process. Look for if they’re transparent with you, if they actually give good feedback, and kind of like, ‘Mmm Hhm,’ you’ll actually learn a lot about the process yourself.
So delve into their thinking process, and I put here a lot of questions, and these are obviously not meant to be prescriptive questions, but more of an idea of how you could delve into their thinking, right? So for each of the slides, don’t take these as prescription but just think about them on your team. Right? Emotionally intelligent candidates are powerful storytellers. They can describe a situation, analyze what happened, describe their mistakes, and even assess the road not traveled. So sometimes I would ask Agile coaches, “Hey, imagine you’re starting on a new team. You’ve been told the team can’t deliver anything at all? And what’s the first thing you would do?” How many questions do they ask, do they dig in and they just provide an answer right away? Or do they…do they ask you a lot more questions? Um, and then asking them to to talk about a real challenge they had. I don’t know who here has heard of the STAR interview format. It’s popular with places like Google and Amazon and such. So the STAR format is useful. It’s basically: Situation Task Action Result. “The situation was we had a production incident. I coordinated with the external supplier because it was something else. Here’s the action I took and here’s the result; the result was production incident was resolved in, you know, an hour and a half, etc, etc, impacted X number of customers.” So that’s a very popular interview format. I think in a complex world if-what if that person has never experienced that scenario? Then they might be prompted to feel that they have to come up with something. So just be aware. It’s…it’s got its uses but it’s not an answer for everything.
When Carol Dweck, if you’ve heard of Carol Dweck, writing about the fixed mindset or genius mindset, it means that someone’s ego is tied to their knowledge, since they get energy from having all the answers. But that’s not really what we need in a complex and changing world. So the leadership development profile calls these people’s having an expert mindset and that’s the research that we’re doing right now at Adaptavist in my new role. But-so talk about their challenges. How do they respond to you? What’s their ideal day? Do they mention working alone? Do they mention working with others on a team? How do they problem solve? Um, do they get input on the things they’re working on and what do they really want to be doing? Why are they entertaining your company and this job at all? So find out what their what their ideal scenario is. And how would they handle specific situations? Right? When you’re stuck on a problem, how do you handle it? Get an example. So don’t just get them to speak theoretically, but get-have them give you an example of maybe when they were stuck on a problem and how did they handle it? Um, and when they’re overloaded with work, how do they manage that? That would probably tell you a lot about whether they were trying to navigate this all on their own and have this expert mindset where, ‘I know everything, and I’m the person who does this Java programming stuff,’ or are they going to share and knowledge share and help others ramp up as well?
Okay. Um…In Agile team, we have to think of distributed leadership as a thing, right? Everyone must be a leader in a self-organizing system. So what did they accomplish? And why are they proud of their accomplishment? Did they overcome challenges somehow or did it come easily to them? If they had to overcome challenges that would tell you something. If it came easily to them, then maybe that would tell you something; that they like this because it came easily to them. Who supported them on their journey? These are all questions that you could delve in and again, it’s not just about the question, but it’s about the deep questions that I know that you know how to ask back when people give that, but what roadblocks did they have to overcome? Pay attention to their communication style? Are they diplomatic? Are they honest? Are they clear? I had someone try to tell me when he was trying to sell an idea, he just kind of, you know, “Well, I knew I-my idea was the best. So like, it was no question. I didn’t, you know – because other people were talking about technology that wasn’t nearly as good – and I just know that I was right.” And he was just so convinced that he was right about that and that told me a lot about his ability to get along with others on that team.
As an Agile coach, especially, we think about mentoring others coaching lifting others up, but we need to do that in teams, no matter their role. So are they coaching and mentoring others on a team you might have people of various experts So, depending on your need, you might want to ask this question, right? Common knowledge is so, so important to a team. Do they hoard hoard knowledge? Do they openly share? How do they share? Do they-do-are they-do they love to write? I had a guy who loved documentation in my previous company and he would take it on himself to document everything. Are they active in communities and online, right? That’s some other things about knowledge sharing.
So for interpersonal skills and emotional intelligence, I believe that culture probably plays into this as well, right? So, so be-be aware of cultural differences, because someone may not be as passionate if they come from a culture as another culture; they may be more reserved but still, they should be willing to share their point of view. What I’ve done sometimes is, say something that I believe is-might be controversial to just put it out there, like, “Hey, I believe you can’t impose upon a team any coaching” and ask them their their opinion and feedback and how you would handle a situation where you were assigned to a team and the team didn’t want to be coached, how they would handle that. Are they open to sharing their opinion? What is their opinion? So try to-try to watch these details in communication. And also, how much are they actually talking? Are you extracting it from them? Or are they actually proactively communicating with you? I had a coach and it was a really great coach but this person was not a great proactive communicator ended up not…just kind of, like, going off on their own and not being involved in any of the team stuff. So, I never knew what they were working on and it ended up not being a great fit for the team overall, because that person didn’t communicate proactively.
We talked about this growth mindset, but how do you actually ask people if they have a growth mindset, right? How do you stay on top of industry changes and tech changes? The ability to learn new things and keep on top of things is going to be more important than what they know today. So I advise to thinking about the future, especially for tech roles, right? Is the person comfortable working outside their comfort zone? When have they had to do that? And then, the best question that someone asked me, a couple years ago was, “Hey, if Agile is all about self improvement, like what are you working on yourself?” I was like, “Oh, my gosh, I got so many things,” and I just rattled off five things that I was thinking about myself and that’s what they were getting really getting at. So that’s a useful technique as well.
So in my previous companies, they actually were in a huge flux, they were growing, they were scaling, their report changes constantly. So I’m used to handling changes at work. What if you’re coming from-a person is coming to your company who hasn’t had to deal with all these changes? What if they find change scary? So, find out what the biggest change they’ve had to deal with and how did they handle it? How did they handle this change in role? I’ve just changed roles in my company suddenly…kind of fell in my lap, and I’ve had to handle lots of those.
I also-this share time, when you try something new and it didn’t go as expected? Well, we all have to try new things. If we’re just keep doing the same thing over and over again, we’re not really learning. So find out where they might have tried something new and it didn’t go as expected. I surely had a workshop where- that I gave that was a new one – and I gotten feedback on it and everybody loved this quadrant idea I had for coaching. And then I went to the workshop and it was like, this didn’t resonate with folks and so that’s a story I’ll never forget for myself, right?
In teams, there will always be conflict, even right before this…um, this talk, I was meeting with someone and he was telling me like, “Yeah, we you know, in hindsight, we-we basically should have decided that someone had this overarching, you know, like, ‘last call’ decision, and not try to get everybody aligned ahead of time.” And I was like, “Oh, well, that’s something that we would want to know.” *chuckles* But it’s not enough to stick a bunch of people together and think that they are immediately able to navigate conflict and understand how to get along with each other; it’s just not. But you also want someone who’s able to navigate this. So what if they had a different opinion about others? I had this, you know, one person thought it was this technical solution, and the other folks on the team wanted this other one. So what if they disagreed? What does it look like when they disagree? How did they end up gaining alignment and how did they solve thatt on their team? By the way, if you’re a coach, it’s a really great skill to teach people about how to help have healthy conflict.
Um…giving and receive feedback. If they haven’t answered this question now or haven’t asked you for feedback now might be the time you want to ask them in, “When, when is the last time you asked for some feedback?” I was doing the recording for the SAFe Summit and I – because the short timelines – I had just a few days to pull the talk together and I started working out in the open and I recorded myself after just a few days and it was really uncomfortable to get it out there. But I got really amazing feedback right away and so is help-it’s helpful to know those things, right? Are they open to feedback, even when they express it, was-they did it even when they were feeling uncomfortable doing it, right?
So if you’re hiring, I’m going to pause and say, well, you have a responsibility in the process too, right? So imagine you’ve got this candidate, and you’re really excited about them. What do you have to do to bring them on? You have-your organization probably has values, or mission and vision and stuff like that. What I do is I share the organizational values via storytelling. So trust from day one, what does that mean at Adaptavist? And then I tell stories, so that the candidate now-now knows the values and now knows how they should be interacting with the values. And, by the way, I’ve had some folks kind of not align-not really resonated with the values, not here, but at a previous company, and so we will go through the organizational values, but…um, also, it’s important for you, to be honest, right?
You can’t sell a position that doesn’t really exist, or a culture that doesn’t really exist, because they will feel like I did when I was sold a job, that the position was a leadership role. But I spent my day sitting in meetings, taking notes, and updating slides, and I had no autonomy at all. The culture was very hierarchical, and I ended up leaving two months later. So tell the truth, be honest about the job itself; the workplace culture, the team structure, the pending changes, the frequency of changes, and expectations, because that person will be much, much better set up for success. And yes, I was *laughs* I was, I was told I, in my, um, previous role that I would get into this job having lots and lots of autonomy but in fact, it was chaos without autonomy. Which was very strange and I ended up working my way into new-a new role that really suits me well. So candidates come to work because they want to be motivated, right? They want to they want to have a reason for getting up in the morning. People want to be self directed, have a say in what they work. This is from Dan Pink’s work drive. If you haven’t seen it, it’s, it’s worth a watch on YouTube. Why do people wake up every day? When I was working in cybersecurity, I had a Scrum Master tell me, “I wake up every day and come to work because we’re catching the bad guys,” and that was very meaningful for her and that’s helpful to know when you’re interviewing candidates and connecting them with their motivations. The urge to get better; a challenge is fun, for most people, they want to keep learning, right? So extrinsic motivators, like money, are not the same. We don’t believe that anymore about people. We-it’s about intrinsic motivations and so that’s where you can go to the next phase here, to discover their motivators. What makes you show up every day for work? Me, I want to I want to have people show up happy at work, and I’m miserable; and folks, when I see folks miserable at work, that’s my driving force. That’s why I show up every day for work.
What do you want to get better at and what’s your most and least favorite thing to do? I actually had an interview earlier this year, where they asked me, “So you told me what job you want to be doing but what job don’t you want?” and I was like, “The kind of job where you have everything figured out and all I have to do is show up and implement what you said that I should do is not the job for me” and they’re like, “Ok, we have a playbook you should follow, so, like, maybe this isn’t the right job for you,” um, but all that kind of stuff is helpful to know.
Bad hires cost a lot more than just time and money. A good hire can change the course of a business and a bad hire can do that. Hiring the wrong person in any team or organization can end up costing the business a significant amount of time, money, and resources. And I had a boss who was a bully; the kind who yelled and cursed up a storm and he was actually harassing folks. He was imposing physically and verbally. Many people complained, and because of him, they left the organization but sadly, he remained in place for years. And I’ll just let you-just with a quick story I’ll tell you the cost. He once made a comment that if the app wasn’t ready, by the end of the year, he would take away the end of the year vacations, everyone’s PTO; he would cancel everybody’s PTO, he made that threat. Although it never came true, two years later, the organization wanted to change to unlimited PTO because then they could get the PTO off the books when folks left; they didn’t have to do pay outs. Which is why most companies do that. The organization rebelled, they were so scared that they would never be able to take their PTO because now it was just, you know, your manager could say whenever you could take it or not. They’re like, “No, I want my three weeks” or “my four weeks,” whatever they had. I would rather know that I have that then take the risk of somebody saying ‘no, I can’t take it’ and take it away from me. And so that org lost millions paying out vacation to le-to those who left because of the lack of unlimited PTO policy. So bad hires cost a lot and, yes, I did have long term stress impacts on that, too.
So where can I find good candidates? Well it’s a little tougher now during COVID but build a pipeline of referrals and candidates from colleagues and friends proactively. Even if you’re not intending to hire right now, wh-why shouldn’t you have a name of top five Agile coaches that you would love to hire if you had the chance to? That way, you’ll-your like, “Oh, gosh, you know, I’ve worked with XYZ person.” So build that pipeline of referrals and candidates…um…and, of course, attend networking events, go to meetups and conferences, just like this. Find people who love learning and then you can host a meetup at your company. Of course, um, I-a lot of companies are now moving to online and I know that my company ha-holds these online events as well. So, just because it’s COVID doesn’t mean that you can’t do these things, although it’s a bit more challenging now. Try to be known as a great place to work that embraces innovation and leads in the market and makes great hires, and that’s going to attract folks to your company.
So I was getting feedback on this talk earlier this year and one of my-one of the engineering managers at my previous company said, “Heidi, why are you trying to cut me out of the process?” She’s like, “I do the screening. I… I do this. This is my job.” And I was like, “I’m not trying to leave you out but instead bring other folks in; find ways of other people contributing to the hiring process. Why shouldn’t they? They should be learning these skills, too, as they’ll be hiring folks later in their career, it’s good to have a safe place to learn and discuss these things all together.” But we bought into the hire, at that point, because it’s not just everybody pre-screened out by the manager…um, and…I-I had another question during a talk. “Well, well, what about biases and diversity?” Well, the team can learn about biases and diversity when you’re having this team chat around your-around the hi-the candidate, right? It’s valuable for people to think about biased diversity. So empower the team to choose their own teammates and, um, instead of the manager making the final hiring decision, or maybe they just want the official sign off, you could say, “Well, the team will propose the final candidate to the hiring manager, and the minal-the manager will have the final hiring decision, but find a way to the team is more involved. After all, if they’re working on a team, who should rather help them be successful as someone who has actively had a say in throughout the process of buying into this person? And it’s so key, right? If you have a person start that nobody bought in. I actually had that scenario where the team said ‘No’ to a person in the manager said ‘Yes’ to the person and they hired the person. Well, how-it ended up not working out after a few months, obviously, because the team didn’t want to hire that person. So avoid those mistakes, and try to make good decisions by involving teams ahead of time.
By the way, whole group processes, one of those Open Leadership Network patterns. If you want to go to openleadershipnetwork.com/patterns, you’ll see all the patterns there for…they’re useful for all scenarios. One thing I did say previously, and I’ll bring up again, is that the woman that we ended up not hiring because the VP didn’t want to hire her, we actually paused all hiring at that moment and we had a retrospective on those and we said, well, how do we handle the scenario? So we don’t want this to happen, again, where everybody’s gung ho on this person and then, he says ‘No.’ So we actually chatted and we changed our process around a little bit to make sure that that didn’t happen again. So improve your…um, improve your hiring process iteratively-oops, sorry, some…-If people are still reluctant, ask for an experiment, right? To say, “Well, let me get involved from the beginning.” Find ways to get the team involved. Find ways to bring more collective insights. I actually had once, we did this exercise, someone that somebody knew. Well, I would have never known that somebody knew that candidate. And they were like, “Oh, yeah, I know that person.” So bring-find ways to bring more collective insights. That was-that provided lots of value. Um, and then, like I said, the team provides the recommendation back to the hiring manager, even if the hiring manager wants to have the final say; it’s so valuable. So the hiring experience doesn’t just end with an offer. What is-what happens when the person starts? So a good onboarding experience increases engagement. If your employees are not engaged, they’re likely to go off and start working for the competition, taking all their knowledge with them and helping them, and you don’t want that to happen. So highly-engaged workers are less likely-likely to leave and how do you do that? Ask new hires, “How can we can-how we can improve?”
I don’t know how many of you do that but we sit down and we like after 30 days. “Hey, what do you wish you knew before starting? What did we not tell you? What needed to be documented? What did we forget to, uh, to share with you as you started, as you were ramping up?” And they would tell us and then we would improve our documentation or our process. And how could we have improved the hiring experience; the whole candidate experience? And of course, from the candidates perspective, it’s not just us internally talking about but now that they’re inside, they can help us improve our hiring experience for future.
So here are my takeaways. Get everyone involved in the hiring process; don’t let it just be a manager top down. Team should be able to decide their teammates and by the way, when teams decide their teammates, the understanding should be that they, they are now helping their-this particular person be successful. By proposing this hire, they’re now committing to help this person be successful in their job because they’re saying this is a great-they believe this is a great hire. Hire people for the real jobs they’re going to be doing right? We need to think about collective learning, collaborating, inspecting, and adapting. Those are the things that we need to be hiring for now. And then don’t be satisfied with your hiring process the way it is, reflect, learn and improve continually. When I brought this idea to our recruiters, in a previous company, they took the idea of the Kanban board and they ended up being a lot more efficient and effective with the hires that they did do. So, spread the wealth across the organization for these practices so that we could improve. And you can connect with me on Twitter, you can find me on LinkedIn, I mentioned a couple times the Open patterns, Open Leadership Network, so please feel free to navigate those. I’m happy to chat more about that if you want me to. And I’m going to stop sharing so I can… so I can chat with you. If you have any questions. I’d love to hear from you.
Host Awesome. Thanks, Heidi. That was so great. Um, please feel free to turn on your cameras so that we can take a look at each other face-to-face and I know that some of you will have questions or comments, you’ve learned new things, or Heidi’s made you wonder; so love to hear from you.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Kathryn Maloney gave during the workshop on the topic of managing and dealing with the stakeholders.
About The Speaker
Kathryn Maloney has coached, consulted to, and advised leaders for 20 years, positioning their organizations to compete and thrive amidst the pace, demands, and complexities confronting business, social, and political environments. Her objective has been to enhance the way organizations co-create, leverage progressive structures, embed dynamic processes and practices, update mindsets and thinking, and build systemic resilience. Structure (organizing), behavior (habits and patterns), and mindsets (narratives and cultural norms) inform potential and possibility. Equipping people and teams means braving an environment of making bets and applying continual insights in order to position the system to see ahead and along the periphery and ground modern systems with the tools needed to continually navigate and adapt.
Kathryn Maloney I work with large government agencies, large global enterprises, small boutiques…and…I, sorry, I’m trying to fix the noise in the background…and in many ways, I do the same thing across all sizes of organizations; the scale and objective sometimes is different. But I find it interesting how, at this point in my, in my work that I enjoy large systems because I enjoy the complexity of them. I also enjoy small systems because obviously, there’s things you can get done much faster. But I’m intrigued at this point in my practice and my career and the applications are the same. And that’s been something I’ve been playing with and scrutinizing for the last 15 years. Scale is really the difference but how you apply change doesn’t really change very much. And so I’m always very interested in setting the conditions up for people to lean in to doing change work in a system that says it wants to change. And I continue to sort of research and play around in that space to see what I discover about how change actually works, both from a practitioners standpoint and organizations adopting change, if you will. So I thought I’d do a check in to see who’s in the virtual room here. And I had three different prompts to give you all if you’ll type it in for me, are you a practitioner or something else? I would love to know. What’s a single word describing what you want to learn coming to my session and having maybe read my article? Um…and it’s a single word articulating where you’re at at this point in the day in these rather dynamic and challenging times. So I’m just watching you guys as you type in; see where everybody is.
Kathryn Maloney Agile coach, agile leader,learning about agile and Scrum, product owner, team coach, coach disguised as a project manager learning perspective, Boston cool. Alright, you guys can keep going, I guess. Thanks, I appreciate it. It’s cool. Keep going, then everybody else can- I don’t know if you guys have done this to see who’s in the room, but that’s awesome. Happy to have you.
Kathryn Maloney Um, so a little bit about where this article came from: It…I…when I write just a little bit about my writing, my writing tends to sort of come out of me at funny times. I don’t exactly write it myself. Something else happens and it’s written out my hand and this… this article came out. We are- We had been developing a methodology for three years and I was in a large organization and I was one year in at that point to a two year, what- what became a two year, project inside of a large consulting company in a function inside a large consulting company… and which is- was a wild environment, because we were a consultant, see consulting to a consulting company. So you have like, you know, lots of force fields with that dynamic. Although, we do a very particular type of work and we were brought in by a function-head to help disrupt his function and help it move into sort of a more progressive organization adopting ways of working that would move them into being more responsive, more agile, more nimble, more dynamic in terms of how they did their work in coordinated and there are large and I was working with a marketing function. So large function dep-
Host I think she may have gotten disconnected. Let’s see. Yes, I think we did lose her. Um Okay. She jump right back in now, now that she’s officially disconnected.
Host We’ve been doing pretty good. This is the first time today we’ve had connection issues.
Host Christine- Oh! All right, there you go. We’ll Hand it over.
Kathryn Maloney Okay, great. I’m sorry, everybody. I’m working with the finicky internet connection, apparently today. So where I left you was I was telling you the history of where the article came from, in year one of a two year project and in the course of that project, I would get asked a lot of questions about – sort of – “Is this the right change work?”, “What exactly are you all doing?”, “Is it the same as agile?”, “Is it different because we’re doing agile?”, or “I have experienced in this area versus that area.” And it was always so…um- fine questions, but also it became such a large group, a large element of the background chatter of the project that, I found it… just, interesting. And as an organization that does or transformation work, we’re always up against that question that can seem like a really smart question, but behind the smart question is always this disguised resistance or work around to actually doing change. And so after several years of, of being in the space and doing the work, this article about, “Dear Beloved Clients, please start by doing…” came about.
Kathryn Maloney So just to extract from the article three, there’s a couple different themes going through it, but three of the key ones that I was talking about- and I talk a lot about still in my work. 2018 it’s like 100 years ago, as as was February this year. So I, this is alive and well in my work now also. So, it just happened to be them that I wrote about it- but debate inhibits progress, right? Like if we’re sitting around debating, which change, what type of change, if change, should we change, should we not change, and everybody talks about change all the time. Debate gets us nowhere; debate is just about debate. Doing is progress, right? Change is all about doing; like, we cannot change and stay the same. So we have to actually do something in order to trigger/catalyze/make change actually happen. So debate is inaction; action actually looks like doing particular things and it’s in doing those things that we get into some forward motion, and then we’re in the exercise of change, and we can let it show us what it’s going to show us. And then the other thing in my article that I wrote about a lot inspired by Dave Snowden’s work, because he’s just a go to, for me, I could name a lot of people, but, you know, ideology isn’t a method. So I’m always very uncomfortable as a person who has been in the change business for a long time of anybody proselytizing, or, you know, trying to anchor to anything too tightly because it’s a warning flag, right? Because change doesn’t look like that; systems don’t take to that. And healthy change is never going to be fully realized if we’re trying to follow a step-by-step process. So those are- those are three principles that are very important to me; my practices that were threaded in, in that writing.
Kathryn Maloney Too much time and money is spent considering change versus doing change. That is a brilliant way for a lot of people to make money and organizations and particularly large ones- and people do that and it’s frustrating- and I talk about it in sales conversations all the time. Because, you know, if we’re talking about change a lot, or we’re teaching an ideology about change, we’re not doing change, but we’re spending money either way, and then it’s very hard to turn that around, because we actually get somewhat attached as adults to that… “non-doing” because that somehow seems like it’s doing something; it’s a lot easier. It’s a lot easier not to do change than it is to actually do change. In in my work right now, in the readies work we, we use a lot of tools and practices. We teach operating rhythms, we teach a lot of how to do things in small ways to instigate large change. And so leveraging tools, practices and rhythms to route things strategically, we turn around the idea of thinking strategically, because we do not.. um… we do not think about planning as a strategic tool we think about doing as a strategic tool and getting people into rhythms, operating rhythm, meeting rhythms, different ways of communicating, that helps people think strategically. So it’s the doing that then helps thinking, which is a bit counterintuitive. Leveraging tools and practices and routes working dynamically and iteratively.
Kathryn Maloney So we anchor to just doing things/starting something and allowing that work and the dynamic nature of being a team or group of people thinking and doing in real time to iteratively show us what we’re discovering. And then we use what we discover to do more and discover more. I know I’m preaching to the choir in a lot of ways here, so bear with me. And then learning constantly, right? So we’re constantly looking at what we’re doing allowing it to inform and teach and give us insights and slivers to see through to then push forward more behavior; more doing to get at more change. So the continuous change process is – and living in organizations today that will never not be and we’re living in one of the most dynamic moments in time right now that illustrates all of this quite poignantly – that change is always upon us, always happening, and it’s how we actually anchor in the work of the day to day that enables us to healthfully work in constant change, enables us to anchor in chaos when chaos erupts, enables us to be responsive and adaptive with the winds of change happening regularly. Again, commoditizing any method or practice as a whole system change ideology, versus a method of intervention will quickly create limitations on the application in complex perpetually changing ecosystems. So again, this is that-that hazard that I find myself up against in talking about frequently, which is, you know, we can-we have to apply words to an intervention method does work *Connection Difficulties*
Kathryn Maloney the relationships *Connection Difficulties* because they are binding and people want things that are much more tangible than most true change processes enable us to execute on. So it’s a bit of a…uh, an interesting paradox there. But again, the commoditization of change is and it’s quite loud nowadays it’s it’s a real hazard and being able to facilitate people in the process of change is more of where the artistry and the mastery lives. Follow our ways in McGann, we can design pretty pictures and talk about things that enable people to begin the change process and those are good and positive and gets people sort of to the door. But selling an end state is… is somewhat snake oil. There are no fixed systems to learn and apply if you’re selling an ideology and an end state. It’s a hardware practice and it’s not really good practice to do. So getting into the work quickly as a principle, rather than talking conceptually as part of the the challenge of doing this work, which I’m sure many of you can appreciate, that…it’s, again, as adults, we are in patterns. We have narratives in our head, we… we are somewhat fixed in our thinking by virtue of age, wisdom, and experience and it’s harder for us to actually step into a new experience for many reasons. The unknown, ambiguity, discomfort, wanting to actually understand what it will be at the end before going through it, which is another anomaly of change process. So it’s disorienting and can be scary and challenging, which then puts a lot of groups and organizations back into where we sit around and we discuss it more than actually doing it. So we let the doing show us what the experience might be. And let us show us-let it show us how it’s actually exciting, and interesting, and fun, and invigorating; which is what I love to put people into because the moment people experience the difference, then you have the hook – healthy hook – to keep going. So again, attributing to the doing.
Kathryn Maloney Then there’s the piece about, you know, as I said, I spend a lot of my time teaching, meeting structures, designing meeting structures, designing workshops, designing events, designing planning sessions, designing strategy sessions, teaching decision methodologies, moving people into new technologies to leverage better communication in a system, talking about different ways that groups can come together and team and the structure of that or how an organization is structured and, you know, doing change work in those spaces. And it’s always interesting there too because those things are what we ask people to get into and start doing, to be in the experience of, and so there’s that, that barrier to just getting people into those. And then there’s a secondary barrier, which is you as the recipient of that; the doers of those… people have to actually be willing to give up something and oftentimes a lot of things because we give up what we know in order to step into these new ways of being and doing… um…and that is loss and there’s grief that comes with that, and there’s emotion that comes with that. And so there’s also holding people in that space as we, as we use these processes to move people into the experience of change. I said it’s impossible to change without changing. We, as change practitioners, can show people the structures and the ways of doing new things in new ways. And the reality is, is that’s the first step of just start doing rather than talking. And then it has to be taken by the folks who were – actually it’s their change to do; that they have to take it from there, we can’t do that part for them. And that’s oftentimes something I’m articulating early on with folks to make sure that they understand that both as buyers and – then and I’m in a system, there’s people who aren’t the buyer and they just receive us – but it’s, you know, people have to be willing to take it and do it themselves because I can’t actually deliver the change. The change is owned by the group, or the team, or the organization itself. So then a couple – a couple principles out of the article: experien-experiencing is believing.
Kathryn Maloney We’ve seen time and again that the transition from debating and cognating, about change or different methodologies, or, “Is this the right one for us?”, or “Is that the right one for us?”, or “Is it-does it apply to this organization but it doesn’t apply to another organization because we’re special?” Like, we’ve seen it all… and the difference between just moving into experience and seeing what adopting simple principles and practices does is worth so much time, and money, and effort. That it’s just… show don’t tell. Don’t wait for permission. I’m in a lot of systems, whether it’s leaders in a system or teams in a system, everybody’s waiting for someone to give them permission to do change or to be different or to try new things. And the only way to activate change in a system is for someone to start. And that someone can be anywhere in the system. It doesn’t have to be a leader, it often doesn’t need to be a leader and sometimes ought not be. So permission is a big conversation we have in terms of getting the doing going as well. Prepare to lose in order to gain the reality is is doing any kind of change work, whether you’re a coach, whether you’re doing teamwork, whether you’re doing systems work, it comes with loss, and that’s really important and hugely realistic to understand what we hold in terms of bringing people into the change because we have to hold the loss in order People to create the space for people to step into and that that dialectic is always in play. And again, I tend to speak to that directly because that can help minimize whatever anxiety people tend to have around doing change and actually again, being willing to step in.
Kathryn Maloney “Mind your ego” I had written about because more… it’s the monkey mind, the ego monkey mind that, you know, a lot of the cognate eating and debating comes from the reptilian brain; the monkey mind basically feeling threatened. And the loop becomes like if I, if I just debate it, I avoid you know, I keep it away and then the risk is lower and so that often that coming from a certain part of the brain, the ego, whatever your anybody wants to call it, so mining your ego because there’s always the loop of changed, you know, it’s going to create chaos, it’s too much it’s going to disrupt, it’s going to be too crazy. And, you know, meanwhile, we’ve usually are in conversations where things are crazy. And that’s why we’re in the conversation to begin with. And so risk and the ego and not wanting to actually step in and do or are hugely a part of this scenario, doing work, as experiencial work
Kathryn Maloney “Stop planning and start doing.” Again, planning is a lot of a cover for delaying action. And we’re very conditioned, you know, change management is rooted in a planning process, it’s rooted in a linear progression, it’s rooted with the beginning and a middle and an end. And so when you come in as change practitioners in 2020, or 2018, probably even 1997. It doesn’t matter. You’re, you’re coming in to do change in this way, you’re-you’re disrupting an entire framework from which people have been deeply conditioned to think what change looks like Even…like I’m talking to a group of Agile people like if you think you know waterfall to agile and how old that conversation even is… still a very new conversation. So same difference with change management, I really come more from the-the change side of the world than I do from the Agile world. So planning is a big one. What are you guys doing? What is the plan for the change? How are you guys going to take us through the change? What is-what are the steps? What is what are, you know, what outcomes, what deliverables are you delivering? And the always the answer is what you’re going to find that out, you’re going to be the ones showing up to the change and doing the change. And how you show up and do the change is going to be what you deliver to your system about changing it. And so that’s a real that’s a real different type of conversation than what most folks are used to and what most folks are used to in terms of selling and buying change.
Kathryn Maloney So I’m, I love what I do, I love partnering with them, and have had amazing partners in my professional life for all these years. And to do this work… deeply and in its purest, most authentic form takes being in strong relationships with people and oftentimes they have a bit of depth to them, and they require a lot of courage to show up as human beings to do this work together. So gratitude and presence are just another huge, huge part of doing this work. And what makes it fun and worthwhile in my humble opinion. So, conclusion. I’d love to hear some other voices rather than my own right now. The choice is always about braving learning experiencing oneself differently both as a practitioner and as the people we bring the change work to.
Kathryn Maloney Sorry. Can you hear me? Did I get as far as the slide?
Host Yep. You were, you just popped out for just a second.
Kathryn Maloney Okay, great. It’s, it’s not up to me. It’s up to somebody else when I’m on Zoom and when I’m not here. So yeah, braving learning, experiencing oneself differently, really being in the truth and understanding of how systems work and how change works – and that study in and of itself is highly valuable, which is my, my background is natural systems and the biology of change – and then using tools and practices and methods to enable those things, not the opposite. And then no tool or method as a panacea, most are opportunities to, to with growth and change. And again, that’s a bit of a paradigm shift in terms of how people think about it. Most of the time, it’s holding all of those spaces I just talked about the tools are our helpers and our friends in the process. So that’s some backgrounds. Now that I’ve taken 40 minutes to get cut off of zoom twice and try and talk about what the article was about. I’d love to engage you guys in a conversation with me or with one another, happily with one another as well, to hear sort of what that elicits, in your minds, what kind of questions that brings up what stories you all have to share with one another about delivering change and the ideas of, of doing over… talking? We have, I think, what 10 to 20 minutes sharing to chat if people feel like it.
Host Yeah, we have about 10 minutes left to chat. So if you have questions, you can put them in the chat box. I did go ahead and give everybody the ability to unmute yourself. So if you’d like to come on and share your answer, that’s fine. I do ask that you take less than one minute to say what you are wanting to share. That way. We have time for multiple
Host Any questions or thoughts about this question?
Host Sometimes it takes a minute as people are writing/typing out their questions. So we’ll just get-
Kathryn Maloney It doesn’t have to be about that question that was just a prompt to help if there’s any questions on anything else. Are
Attendee 1 You were talking about Dave Snowden and his work? Do you use tools like sense maker to make sense of where an organization is before as part of the work that you do?
Kathryn Maloney I don’t. I don’t and I don’t – I don’t practice Dave’s methodology either but I love Dave’s talking and his-and his writing. But no, I don’t do sense maker but also I don’t do a lot of that assessment work of a system before I start work. Like I go in, I engage with a particular part of an organization, whether it’s a function or a team, or, you know, I come in in different ways. And I actually have some tools that we use to quickly get people reflecting on what’s in their way. And then get them to sort of self diagnose into trying new things immediately. So as a – my practice and the readies practice, we don’t do a set like… assessment is not a part of what we do. So there is not there’s no judgement about that tool. I just that’s not that’s not part of how we practice.
Attendee 1 Actually, I’m looking forward to reading the ready. So I’ll come back to you offline. Thank you.
Kathryn Maloney You’re welcome.
Host We have two questions. First question he is working with engineers that quickly need to turn around projects. They use hackathon as a paradigm. To do quick iterations. What is your experience in getting quick iterations for change?
Kathryn Maloney So, we again – funny enough, I’m going to tell you guys about how we practice – so we don’t go in…I mean-I-we could design a workshop, that’s not totally true. We could design a workshop that would like get people into such a thing as a hackathon. If it was a very specific workshop, so I think it’s a wonderful tool to use if you’re trying to teach people how to just think and create and design real fast and ideate to get into iterating on something. I think that’s wonderful. We also go in with large transformation projects and we teach iteration as a way of working. So which is that’s really easy to say and not as easy to do. If you work with engineers, you know that well, so like, it’s getting people to move into that, you know, more agile loop of identifying something, testing it, figuring out what the test and the data is telling you to then move to the next, you know, stage of it is something that we teach teams to do in function as a way of working. So sometimes we’re doing an event type thing, but other times we’re actually embedding to teach over the long term how to move a system to actually thinking and working in an iterative way as a way of working. So, change – quick change is also an anomaly. You know, right? Like, if we all knew how to, like teach people quick change, we would, you know, probably all be billionaires, I always say that I’m like, that’s how I’m gonna become a millionaire. Like there’s always these things. So quick changes, like, I don’t know if there’s such a thing, right. But there are there are six constructs and designs and methods and tools that certainly help people to think in tighter frameworks in tighter timelines, to design and iterate more quickly, to take that data and to put it back in to keep going right to be in that loop of change. So it’s more like where my qualitative researcher brain comes from, of, you know, trying to identify things in extract and then put it back into redesign and do it again and teaching that as a way of working is not… it’s not quick. It takes a lot of it takes a lot of discipline, and it takes a lot of attention, and it takes a lot of commitment from a team and an organization to do that.
Host Yeah, change is definitely not easy. So we have one last question; we might have time for one more after that. But this question is, “When doing this change work, what do you do when people are actually unable to execute within the framework that you’ve sent out/set up?
Kathryn Maloney Alejandra, that’s an ind-I’d almost want to know a little more behind your question. Let me try and take it but and then if you want to clarify…
Kathryn Maloney Here’s my… I might-I might be shooting incorrectly with your question here. So…just hold that lightly. I don’t know if it’s maturity because I-I work with so many different ages and cultures and, you know, genders and ethnicities, and, you know, I work across so many types of humans to include younger ones. And I often think it’s not. If you’re running into people not embracing change, oftentimes the question has to go to the practitioners it has to go to the structures, it has to go to the constructs, because that’s part of the artistry and the dance is figuring out how to find the inroads so that people can make it work for them and sometimes an Agile approach from what I hear, because I’ve never delivered one like in that way, but sometimes an Agile approach can be too rigid in what you’re asking people to do. And that’s where you – people run into because I run into this in every organization I work in, right? Because I’m very close all the time to people doing agile transformation work and systems. And so oftentimes, it’s like, I always-it’s like, “Where can you give breathing space for people to actually find their way because people need to muck about.” It’s one of my favorite expressions. That is, you know, obviously very academic. People need to muck about in change, they have to find a way whether it’s an individual working with a therapist and individual going to the gym and individual that you can think of all sorts of changes individuals, yourself of like, how do you sort of find your way to like the place where you’re in the flow and it can work? You have to do that with groups of people as well. And of course, I like small groups. So because it’s mucking about is a thing and it takes time and you have to allow people to make muck about enough to find which, which of the tools or practices actually resonate? Like is the retrospective working for a team that’s adopting an Agile approach and just focusing on that, letting people get into the rhythm of that so that they feel into that experience and have some success to then add other things.
Host Aweome. Well, okay, well, thank you very much for taking a few minutes to answer questions. Katherine, this was a great presentation.
Kathryn Maloney You’re very welcome
Host Love to hear your, your information and background that you have as a change agent, not necessarily like as just an agile coach, but how do you do change an organization, change is very complex. So definitely appreciate this perspective and appreciate your time here today.
Kathryn Maloney Thank you so much
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Gene Gendel gave during the workshop on the topic of scaling your Scrum properly and managing dynamic financial forecasting.
Brock Argue and Erkan Kadir explore the interplay between Waterfall and Agile, and how organizations can manage the resulting dynamics to their benefit. They are introducing a tool called Polarity Management, which can be used to get the most out of any change effort. And lastly, they discuss a new concept called Integrated Agile, which aims to help organizations leverage the upsides of both Waterfall and Agile.
So why is this important? As an industry, we have been transitioning organizations to Agile delivery methods, frameworks and processes for over twenty years now, and we’re not getting any better at it. Failure in Agile transformations is the norm. One of the reasons for this is that organizations operate in a mixed methods environment, where neither Agile nor Waterfall are the solution to the problems that organizations face today. It’s about time we all realize that and embrace the need for both approaches, Agile and Waterfall.
Best Agile Articles is a collection of the articles from a variety of authors published on topics of all things Agile. The Best Agile Articles book series collects the best agile articles published during a calendar year into a single volume. You can download your free copy of the ebook from our website or buy a paperback copy from Amazon. If you would like to subscribe to the soundcast of these talks, head to Soundwise.
About The Speakers
Brock Argue takes a holistic approach to agility – recognizing that all aspects of the business benefit from the application of agile values and principles. His style of facilitation creates an environment in which high-performing organizations can emerge. Brock’s work includes agile transformations at Digital Oilfield, ADP, Benevity and Suncor. As a dedicated volunteer with the Scrum Alliance, Brock seeks to support the ongoing development of coaches as they seek to transform the world of work. Brock is a Certified Enterprise Coach℠ (CEC) and Certified Team Coach℠ (CTC) through the Scrum Alliance and has received professional coach training through ICAgile and CRR Global.
Brock provides coaching, mentoring and certification programs to individuals and organizations as the co-founder and coach at Superheroes Academy
Erkan Kadir is a co-founder of the Superheroes Academy, a coaching organization that’s set out to level up the skills of agile practitioners worldwide. He is a Scrum Alliance Certified Enterprise Coach (CEC), Certified Team Coach (CTC), Certified Organization and Relationship Systems Coach (ORSCC), and an IC-Agile Certified Coach (IC-ACC).
Brock Argue Thank you Cherie. It’s good to be here. Thank you everyone for joining us for our session today on integrated Agile. We’re very excited to explore this topic with you and this concept that we have. Our focus today will be exploring the interplay between Waterfall and Agile, and how organizations can manage the resulting dynamics to their benefit. We’re going to introduce you to a tool called Polarity Management, which can be used to get the most out of any change effort. And lastly, we’ll introduce you to a new concept called Integrated Agile, which aims to help organizations leverage the upsides of both Waterfall and Agile. So why is this important? Well, as an industry, we have been transitioning organizations to Agile delivery methods, frameworks and processes for over twenty years now, and we’re not getting any better at it. Failure in Agile transformations is the norm. One of the reasons for this is that organizations operate in a mixed methods environment, where neither Agile nor Waterfall are the solution to the problems that organizations face today. It’s about time we all realize that and embrace the need for both approaches, Agile and Waterfall.
Erkan Kadir Hey, thanks, Brock and so before we go too far, we’ll just take a little bit to introduce ourselves. So as Cherie mentioned I am Erkan Kadir and with me is Brock Argue, we’re both Certified Enterprise Coaches and Certified Team Coaches through the Scrum Alliance, as well as Relationship Systems Coaches. Our company is the Superheroes Academy. We’re based out of Calgary, Canada, and we’re available globally for leadership development, workshops, Agile coaching, and we offer most Scrum Alliance certifications through online programs. Okay, so let’s dive in. We’re gonna start off by talking about an issue that we believe exists in most organizations that do product development globally. Now, we call it the Agile Warzone and we first wrote about this topic in the article that was published in the 2018 Best Agile Articles publication. Now the Agile Warzone can be demonstrated by looking at how Agile and Waterfall tend to treat the Iron Triangle of project management. In this triangle, you have time, resources, and scope and when planning delivery, you can shoot for all three, and in fact, we usually do, but when things go off track, at least one of the points must be movable. And so on the Agile side, on the left here, we have people who believe that the best products are built by teams with relatively consistent membership and who allow scope to emerge over time through the learning that comes from running experiments. And then on the right here, on the Waterfall side, there exists a completely different perspective. This is where people believe that the best way to mitigate risk is by having experts carefully plan scope in advance, and then being elastic with deadlines and resources if things don’t go as planned. And so there’s a fundamental difference in approach here that can make it very difficult for people who prefer emergence on the Agile side to interact with people who expect certainty and predictability on the Waterfall side. And when there are people on either side of the coin, who believe that their way is the right way, and the other way is the wrong way, then we have the conditions for what we call the Agile Warzone. And this is where ‘either/or’ thinking can lead to misunderstandings, passive-aggressive behavior, and, potentially, all out war. Now, unfortunately, the Agile Warzone seems to exist in most organizations, or at least all the ones that Brock and I have worked in it. And one of the reasons that we believe the Agile Warzone is so prevalent is that the war is not actually winnable by either side. And so what that means is that many of us, certainly myself, you know, as an Agile Coach, for a long time we’ve been we’ve been selling Agile as a solution to problems, oftentimes, that can’t actually be solved. And so you might have read the title of our talk, you know, mix agile and waterfall and, and immediately discounted us as heretics who are promoting Wagile or Watergile. And, you know, our intention here. And, you know, certainly if I had-would have read the talk-the title a couple years ago, that’s what I would have thought, but our intention is merely to shift the conversation to reality that Agile mixed with Waterfall is happening in most of the companies that are out there today and so what we’re going to try to do, in this talk, is we’re going to try to equip you with some knowledge and some-some practical tools that will help you to manage this reality in case this happens to be a situation that you’re in.
Brock Argue And so one of the ways that we can manage the Warzone is with a tool called Polarity Thinking and this was introduced by Barry Johnson in his book, Polarity Management, Identifying and Managing Unsolvable Problems. Polarity Thinking recognizes that all values come in pairs; that each value in the pair has both an upside and a downside and there are predictable dynamics that define the relationship between the two values. So we’re going to start off here by introducing you to a polarity – um – to Polarity Thinking. Usually one of the dilemmas that Agile companies have to manage: how to support the individual and the team. And I like to use the metaphor of a moving walkway to highlight the dynamics that exist within polarities. See, as an organization favors the individual, the upside that they will receive, for a time, is that of individual initiative, which you see here is characterized by individual creativity, and entrepreneurial spirit, fewer and shorter meetings, freedom and addressing personal needs. Given the polarity dynamics that are at work here and, like I mentioned it’s like a moving walkway, the organization will naturally start to move towards the downside of the individual pole, which is isolation. This is experienced by a lack of common direction, only being rewarded for homeruns; no synergistic effect, no team support, and selfish ‘me’ talk. Now once in the downside of the individual pole, the organization reacts to move back to the upside, this time by favoring the team pole. And this is a common shift that we see in organizations that are transitioning to Agile ways of working, moving from bring the individual pole to favoring the team pole. But in the upside of the team pole, the organization now enjoys the benefit of a cohesive unit, which includes having a common direction, recognition that each job or role is important, that synergistic effect, team support, and personal sacrifice in favor of team success. Remember, Polarity Thinking tells us that we’re still on this moving walkway. And so the organization will eventually start to experience the downside of the team pole, should they favorite long enough, which manifests itself as bland sameness, meetings having too many and for too long, least common denominator, team burden, and neglect of personal needs. In other words, too much conformity. These polarity dynamics, as we’ve just witnessed, are in evitable. So how do you know when you’re dealing with a problem to be solved? Or a polarity to manage? Well, answering ‘yes’ to these questions here tells us that you’re likely dealing with a polarity to manage. Is the difficulty ongoing? Are the alternatives interdependent? Are the upsides of both poles necessary, and will over-focus on one pole undermine the greater purpose? We believe that the challenges we try to solve when we move from Waterfall to Agile are not problems but polarities to manage. So let’s look at each one of these four criterion of problems or polarities in the context of Agile transformations.
Erkan Kadir Okay, so we’ll start off by evaluating whether Agile and Waterfall is a polarity or a problem by looking at polarity test number one: is the difficulty ongoing? Well, the Agile Manifesto was published almost 20 years ago now and a whole industry has formed around Agile transformations and so I would expect that if this problem was solvable, then we would have many shining examples of companies who have eliminated their Agile Warzones through complete and total Agile transformations. But let me share with you a few items from the 2020 State of Agile report from version one, to demonstrate that this doesn’t seem to be the case. 95% of respondents said that their organizations practice Agile, so Every company in the world almost at least outwardly reports that they’re at least trying to do Agile. But at the same time, a whopping 82% of all those companies indicated that not all of their teams have adopted Agile practices. So logically, then I would take this to mean that we can expect a mixture of Agile and Waterfall in at least 82% of the organizations globally. Now, hold on a second, that also means 18% of the software companies out there are supposedly doing Agile well. So, surely those companies have found a way to completely eradicate Waterfall with a consistent and enterprise wide approach to Agility, right? Well, it looks like even the best among us haven’t yet figured it out. Because the survey then goes on to indicate that Agility in those companies is still only largely confined to Development, IT, and Operations; meaning that the rest of the company is still also using traditional approaches and we can expect to find a warzone in those companies too. And so for all of the Agile coaches like us, transformation approaches and scaling the frameworks that exist. If I was to ask the question, ‘Is the difficulty ongoing?’ I would have to say ‘yes.’ So let’s move on to polarity test number two, are the alternatives between Agile and Waterfall interdependent? Is there a relationship there where they affect one another? Well, if you look at it, we can’t really have Agile without Waterfall. Because we work in an Agile way iteratively and incrementally, we’re really just doing a series of mini waterfalls. “But wait!”, you say, “Aren’t mini waterfalls just a an-Agile anti pattern?” And, you know, maybe and, you know, we’ve read all those blogs and stuff, too. But, but let me use Scrum to demonstrate what I mean because Scrum dominates the industry with 58% of all Agile teams globally using using it. While the next closest method, Scrumban is only being used by 10%. And so in Scrum, each iteration, when we look at it, it’s really just a phased approach where a team first has a requirements gathering phase; that’s the Backlog Refinement. Then they have a plan and design phase; that’s the Sprint Planning Meeting. Then they have an execution phase; that’s the Sprint. And finally, they have a verification phase; which is the Sprint Review. And so the cycle repeats every few weeks but the interdependence actually works the other way around as well; where we can’t have Waterfall without Agile and so every Waterfall project that we’ve seen, has some sort of change management process built into it, so that they can continuously update their plans as more is learned. And while much is made of the high cost of these processes, this is the Waterfall way of leveraging the upsides of Agility. Because without Agility or the ability to learn and adapt to our environment, the purely Waterfall company simply ceases to exist. And so at this point, we want to point out a paradox that we’re going to come back to later on. Agile and Waterfall are mutually inclusive, and interdependent op-opposites. And what we mean by that is not only can we not have Agile without Waterfall but the more we favor one, the less we’re going to have of anoth-another – and again, we’ll come back to that because it might be a lot to think about at first – and so to answer our polarity test question number two here, ‘Are the alternatives interdependent?’ We would say ‘yes.’ Okay. Let’s look at our polarity test number three. Are the upsides of both poles – Agile, Waterfall – necessary? Again, we believe the answer is yes, and one of the best ways to demonstrate that is simply by looking at the values from the Agile Manifesto, which will populate on the screen here. So on the left, we have values that generally, as Agilists, we want more of, and on the right we have values that generally, as Agilists, we want less of; which are generally more aligned with the values we would see in a traditional or a Waterfall organization. And so, the upsides of the Agile items on the left are obvious because if they weren’t necessary, we wouldn’t have 95% of the software companies globally trying to do Agile but the upsides, uh, of the Waterfall items on the right are also just as important. Because if you think about it, without processes and tools, we wouldn’t actually have Scrum or management systems. Without documentation, we’d simply incur the waste of relearning. Without contracts, we wouldn’t have customer relationships. And without planning, we wouldn’t have any Sprints. And so the Agile Manifesto even has this famous line written on the bottom that says, “While there is value to the items on the right, we value the items on the left more” and so this is one of the confirmations that we can use to show that both sides at least have some degree of necessity. Now, the often-recognized genius of the manifesto is that it acknowledges that all values come in p- *clears throat* – all values come in pairs. But as you’re going to see in the next few slides, favoring one side over the other, as we’re doing in the Agile Manifesto, actually presents a very big problem from the perspective of polarity management.
Brock Argue Okay, so the last criteria in determining if an organization is dealing with a problem or a polarity is, if overfocus on one pole undermines the greater purpose? And the answer to this in the context of our discussion here today is a resounding, “Yes,” and we’re going to look at a couple of examples here just to kind of see how this works, and what this looks like with respect to Waterfall and Agile and the challenges that organizations face. So here, we’re going to chat about the first of four case studies that we’re going to share with you to highlight the dynamics of polarities. Each case study focuses on one of the four value pairs from the Agile Manifesto and so here in case study number one, we’re going to start off with the ‘Individuals and Interactions’ and ‘Processes and Tools’ polarity, in which this organization favored the individuals and interactions. So this client company profile here, it’s a startup company that had grown to be roughly about 500 employees. They have a product that’s focused on corporate giving and volunteering solutions, and kind of the DNA of this organization: social causes, diversity, and inclusion; very important to who this company is. Now, through the growth that the organization had achieved and the culture that they had, this led to slow decision making, and very expensive meetings. There was a need in this organization to include everyone in discussions and to make decisions by consensus. Leadership of the organization started to call this out as an inefficiency that needed to be addressed. HR put in place meeting guidelines and protocols to ensure that there were clear agendas for meetings and attendance lists that made sense. Every meeting had to have a documented outcome or set of action steps. They even went so far as to provide formal training and meeting facilitation to all employees. So what happened for this organization? Well, favoring the individuals and interactions for most of the company’s history led to slow decision making inexpensive meetings as the organization grew. Leadership and HR tried to counteract this by formalizing meetings through protocols, training, and documented outcomes. This led to reduced ownership in the organization since, “Well, I wasn’t involved in that decision and no one asked me.” As soon as the organization became aware of the reduced ownership and alignment, they quickly refocused on the Individuals and Interactions pole, effectively leaving the organization in the downside of the pole, they had favored the most. So we’ll move on to our second case study and, in this one, we’re going to be referencing the ‘Working Software’ and ‘Comprehensive Documentation’ polarity from the Agile Manifesto. So, this organization is a well established Fortune 500 company in the Canadian Energy Sector. They have a very traditional culture and organizational hierarchy and the work of the organization generally occurred in the context of projects; where they had a definitive start and end date and traditional Project Management throughout. Now, this organization understood the need to take a different approach to some of their work in order to keep up with the innovations of their competitors. The desire to move some segments of their business into taking more of a product-centric approach rather than a project approach, as they had been so far. So they brought in Agile coaches to work with an internal team to design, build, and test this product-centric approach of theirs. So what happened to this organization? Well, due to the traditional history and the inertia that that history created, this organization learned to favoring upfront-lean to favoring upfront learning in an effort to reduce uncertainty. They just created a need in the organization for comprehensive documentation before changes could be made to the system. The vast amount of documentation and approvals required caused a slowdown in the results that the team was able to achieve and, ironically, led to missing out on opportunities for learning. The organization just wasn’t ready to embrace the ‘Working Software’ side of the polarity no matter how hard the Agile coaches pushed them to do so. One reason for this is that as the team started to just build stuff, and learn through experimentation, leadership became very uneasy with decisions that were being made and the lack of clear governance that they had become used to over the years. This led the organization to move back toward the ‘Comprehensive Documentation’ pole very quickly, causing them to receive the downside of that pole. These first two examples center around favoring one pole, and that by doing so, organizations receive the downside of that pole. It’s important to note that continuing to favor just one pole, and doing so to a large degree, will lead through seeing the downsides of both poles. So what you’ve observed through these first two case studies is what happens when you overfocus on one pole. This is referred to as the One Pole Myth. That myth states that if we focus solely on one pole, we are able to get the upside of that pole without any of the downsides of either poles. But the reality is that by favoring or overfocusing on one pole, we will only get the downside of that pole and as I just mentioned, if we hold on to one pole long enough, we’ll get the downsides of both poles. For example, and as we saw in case study number one, we might stick closely to individuals and interactions, because we fear reduced ownership and decisions. But we stick to that pole so tightly, that we create a culture of consensus decision making, which slows us down in getting anything done, and leads to blame and finger pointing; which is the downside of the ‘Processes and Tools’ pole. So, let’s do a quick recap based on the case studies that we’ve provided so far. Is the difficulty ongoing? So yes, our industry has yet to consistently implement successful Agile transformations in organizations. Are the alternatives interdependent? Yes, Agile frameworks include defined processes within them. Erkan, earlier, he showed us how Agile can’t exist without Waterfall and vice versa. Agile and Waterfall are mutually inclusive and interdependent opposites. Not only can we not have Agile and Waterfall, but the more we favor one, the less we’re going to have of the other are the upsides of both poles and necessary? Yes. Even as described in the Agile Manifesto, there is value in both sides of the polarities that organizations must manage in order to be successful. And lastly, will overfocus on one pole undermine the greater purpose? Yes, our experience and case studies that we have shared tell us that overfocus on one pole leads to the downside of that pole and, eventually, the downside of both poles.
Erkan Kadir So we just spent the first bit of this presentation making a case for Agile and Waterfall being a polarity to manage not a problem to solve by implementing one side or the other. But because we’re not going to spend-or we’re not going to spend too much time putting Agile and Waterfall up on a polarity map directly, because we believe that it’s actually a meta-polarity that contains many other polarities and we find it more immediately useful, and practical, for organizations that want to explore Agility to manage these polarities individually based on the specific challenges that they’re facing. And so the four values or polarities that are listed in the Agile Manifesto, plus the dozen or so that are listed on this screen are just some of the polarities that are out there and in fact, once we become aware that polarities exist, we start to notice them absolutely everywhere. And, so, we also just want to, um, give a little warning at that point when we say that; that not all polarities are going to be worth the effort to manage consciously, because they’re expensive to do so. And so our suggestion, then, is to look at the business objectives behind each Agile transformation and, first, understand what are the unique polarities that are at play here, so that we can then select the most impactful leverage points to manage consciously. Okay, so here’s a situation that might sound familiar. You’re working in a company that uses a traditional Waterfall approach to build products and the time it takes to deliver new versions of the product keeps increasing and is now measured in years. Certainly, this has happened for many organizations that I have worked with. And so you start losing market share to your competitors and somebody eventually comes up with the idea to solve the problem by doing an Agile transformation and so your company brings in new leadership, they train everybody in Scrum, and then they fire anybody who threatens the new culture. And so there’s lots of excitement around the change an-but at some point, people start to realize that, you know, Agile is actually a lot harder to implement than they thought and, you know, it’s been it’s delivered some benefit but it hasn’t solved all of the problems that we thought it would and in fact, now the company has a whole new set of problems to deal with. And so your company gets fed up waiting for the results that were promised that don’t seem to be happening. And they start to view Agile as maybe just not practical and there’s some grumblings that the transformation was a mistake, or it wasn’t done well and so what do they do? They bring in new leadership again and this time, their job is to fix the problem but they’re going to do a large transformational change effort to fix the problem but they’re going to do it by going all the way back to the first place that they came from. And so this cycle that repeats endlessly, back and forth, like this, is unfortunately very common. Because when big organizational change efforts favor one pole, they end up only in the downside of that pole, due to the One Pole Myth, or at least they spend most of their time than the downside of that pole. And so then another change effort takes place in the opposite direction, favoring the other pole and the cycle just keeps on repeating endlessly and it’s a dynamic that Barry Johnson in his book, Polarity Management, calls the polarity two-step and it’s really unfortunate, because we spend most of our time in the downsides of the poles instead of the upsides. We alienate people unnecessarily – kind of harkening back to the Agile Warzone – and we generate lots of costly resistance. And so the point we want to make here is that by seeing either the upside of either pole, Agile or Waterfall, as a solution, or as more important than the other, is a setup for it to be called a mistake later on, which is exactly what the Agile Manifesto sets us up to and this is a problem because, as Agilists, our industry has been an u-an unbalanced crusade in favor of one pole over the other, in an unwinnable war, for the last 20 years and this is why we say that Agile versus Waterfall is not a problem to solve, but a polarity to manage. Instead, we drop the word versus, and we look at this polarity as Agile and Waterfall. And so here’s the good news, dynamics in polarities are actually highly predictable and when we’re aware of these dynamics, we can manage them in such a way as to spend most of our time in the upsides of the two poles instead of the downsides and that’s what we’re gonna be showing you today.
Brock Argue Okay, okay, fine. So we can’t have the upside of just one pole, from a polarity because of the One Pole Myth. Well, then, I’ll set up my company and processes in such a way as to get the upside of both poles at the same time. Unfortunately, this too, is not possible. Since the two poles are opposites. It’s not possible to have them both at the same time. This is called the Merged Pole Myth. When we try to get both upsides at the same time, we actually end up getting both downsides instead. For example, given that our greater purpose is breathing, let’s look at the Merged Pole Myth in the context of the polarity, inhale and exhale. If we try to inhale while we’re exhaling, which is aiming for the upside of both poles, we get neither upside. Instead, we accumulate CO2 and use more oxygen than we’re breathing in giving us the downsides of both pools. We see companies doing this all the time. “We’re going to do Agile” they say, “but you have to tell us when it’s going to be done and what we’ll get on the other end.” “We’re going to do Agile” they say, and the team is empowered but managers and architects still have the final say. “We’re going to do Agile” they say, “and learn through experimentation…but you better not fail.” The Merged Pole Myth, or the worst of both worlds, is what we think of when we hear the terms Watergile or Scrumfall. The reality is that when organizations try to get the upside of both Agile and Waterfall at the same time, they end up with the downsides of both poles, missing out on the benefits of Agile, while eroding the clarity and rigor of Waterfall. Our case study on the Merged Pole Myth focuses on the ‘Customer Collaboration’ and ‘Contract Negotiation’ polarity from the Agile Manifesto. So here we have a small boutique consulting firm, it was founded about four years ago, who specializes in Agile coaching and training. Not being new to the industry, and in a quest to achieve some level of income certainty, his organization valued signed contracts with their clients but because they’re an Agile consulting firm, they wanted to walk the talk so they also valued customer collaboration. In doing so, this organization attempted to get the both get both poles at the same time, by having customers sign contracts that focused only on the collaborative relationship between the client and the consultant. So what happened? Well, as you can expect, by trying to get both poles at the same time, what they feared about each pole became true, and they received the downsides of both poles. This led to conversations with potential clients that remained contentious over contract terms and since they hadn’t discussed pricing upfront, the consulting firm didn’t feel like they were being paid fairly.
Erkan Kadir Okay, so we talked about the One Pole Myth and the Two Pole Myth. So we’re damned if we do and we’re damned if we don’t. So how do we manage polarities well? Well, it starts with being willing to take on multiple perspectives and we’re going to demonstrate that with an example. So take a look at the picture on the left. Notice that without the faces, the goblet can’t exist, and vice versa. Now, maybe we’re the kind of people who value goblets over faces, so we make the goblet bigger,and then we make the faces smaller. But when we value the goblets too much, we lose both the goblets and the faces altogether. And so here we have another paradox, a set of mutually interdependent and inclusive opposites, creating a polarity to manage. Now, you might have seen the faces first or you might have seen the goblet in the middle first but notice that both the goblet and the two faces cannot be perceived at exactly the same time. And in fact, Robert Desimone, from MIT’s McGovern Institute for brain research was able to prove that the brain is capable of only holding one of these perspectives at any one time. So either one stands out and is clear or the other does. However, if we’ve seen them both at least once, we can easily switch between the two by making a conscious intention about which perspective we’re going to take on and so both perspectives are accurate, but only partially. And we like this picture because it can help make the distinction between accuracy and completeness. When we’re able to take on the perspective from only one pole in a polarity, it’s our incompleteness combined with our conviction, that we see the whole picture that is the source of a potential problem and you can see where we’re going with this with the Agile and Waterfall. So if I tell you that you’re wrong, because there’s no goblet, and you tell me that I’m wrong, because there’s no faces, then there’s going to be no end to our argument; one of us is going to need to switch perspectives in order for us to progress in our discussion, but who’s gonna go first? Somebody has to recognize that this is a polarity to manage and say, “Hey, you know, maybe this is not a situation in which we have either a goblet or two faces. Maybe this is a situation in which we should be looking for both the goblet and the faces, maybe we could both be accurate. And so paradoxically, then, opposition is turned into collaboration when the statement, ‘I don’t see what you’re seeing,’ or ‘I can’t see what you’re seeing’ becomes, ‘help me to see what you’re seeing.’ And so the point we want to, um, make here is that ‘either/or’ thinking can be supplanted with ‘both/and’ thinking to manage polarities well. Now, take a look at the picture on the right. Now, this was the individual and the team polarity that we looked at earlier. Notice the parallel between seeing the faces, and seeing the two diagonal quadrants on the polarity map in the right. Just like the first picture, we can only take on one perspective from a polarity map at any one time. And usually, we can only see the upside of our favorite pole. And the downside of the pole we’re trying to move away from or the one that we’re afraid of, while being completely blind to the downside of our favorite pole, or acknowledging that the por-pole we fear even has an upside and that’s what’s represented in these black squares here; what we can’t see. And so the example that we have on the screen, we can see the upside of valuing the individual and the downside of valuing a team but with a little bit of courage, and maybe a lot of courage, we do have the option of intak-intentionally taking on the opposite perspective from our polarity map, as you can see here, um, so that we can see the downside of our favorite pole and the upside of the opposite pole and we can always switch back and forth. But unfortunately, as we saw in the Agile Warzone example, there’s often a very serious and cothly-costly confrontation that takes place because a ‘both/and’ polarity is treated like an ‘either/or’ a problem to solve and people only bother to take on one perspective or the other. When we can take on a polarity perspective ourselves, we also increase the possibility that others will take the time to look at the other perspective because we’re confirming their truth and we’re not contradicting the reality. So…let’s jump out of the theory for a second and get down to a little bit more practical use of: how can we use some of the lessons from the last couple slides to manage polarity as well? And the first thing I just want to say here is that polarities are unavoidable and unsolvable and so the question is not if we’re going to manage them, but how well are we going to manage them? And so here’s five skills that you can use to manage these polarities well. Number one is simply knowing that we have a polarity to manage, rather than a problem to solve and we can do that by answering the four questions that we walked through at the start of this presentation. Number two, knowing that there’s an upside and a downside to each pole. And you can do that simply by filling out a polarity map, write it down. Number three, maintaining a sensitivity to the downsides as they’re experienced and so here we have to ask ourselves, well, what quadrant of the polarity map are we in right now? Are we enjoying the upside and things are great of a certain pole? Or have we maybe held on to that pole for a little too long; we-maybe we’ve overfocused it and now we’ve started to slip into the downside. And then number four, this is where the courage is needed, this is where we have a courage and a willingness to shift perspectives and to actually drive up and across into the other pole that maybe has been marginalized. And number five, is knowing how to talk to and mediate between people who take on opposite perspectives. So we’d like to use the analogy of walking a tightrope as one that can help us understand what it’s like to manage polarities well. Now our tightrope walker, in the picture here, you can imagine that he is acutely aware that there is an upside and a downside to each pole that he’s got – both left and right – and so what he’ll do is, he will fully shift his perspective and either lean left or lean right when he’s gone too far to one side or the other. When he’s just learning to walk the tightrope, as you can imagine, his shifts will be extreme, right, as we’re just trying to figure this out from one side to the other and that’s a lot like the polarity two-step that we talked about in organizations. Maybe if they’re just trying to figure out this Agile and Waterfall, they do a big transformation and then they go too far and then they-they try to correct it by going way too far back. But if you think about an expert, tightrope walker, somebody who’s a master at this craft, as they become more skilled, their shifts between perspective becomes smaller and smaller, and eventually they’ll be barely perceptible. Okay? And that’s the analogy we want you to hold as we talk through our fourth case study. This time, it’s a company that was able to manage a polarity well and so this company was able to do that by listening to the early warning signs, that they were slipping into the downside of each pole, and then switched perspectives early enough to spend the majority of their time in the upsides of those two poles. So for this case study, we’re going to be examining the last polarity that we haven’t spoken about yet from the Agile Manifesto, which is ‘Responding to Change’ and ‘Following the Plan’. So this company, was founded about 20 years ago, in the energy sector, and they have a pretty mature Agile implementation, where they’ve been doing Agile for over 15 years. And so our case study starts in the upside of responding to change. Because this organization has Scrum teams that were fully empowered to innovate and work directly with stakeholders and clients, leadership was very comfortable with ambiguity, and they had a high degree of trust in their teams, and, you know, even though they didn’t know what would finally emerge from that customer collaboration, they were seeing value being created, and so they believed that they were doing the right thing and they were content. And so what happened with this organization is, not only was everybody happy, but they were they were doing really well. They had innovative solutions and-and general market leadership in their space. But what happens, as you can imagine, as the moving walkway goes, while their general tact of allowing solutions to emerge was working well, they also noticed that at times, they would need to plan and meet commitments And so one example was the Agile user conference or – not the Agile just a user conference – where customers wanted to know what would be demoed before they were able to confirm attendance. And so when they resisted committing to demo any particular scope by the deadline of the user conference, they received an early warning sign that they had been favoring the responding to change pole at the expense of the following a plan pole, which for them was that sign-ups for their user conference were unacceptably low. And so now this company was smart and they understood that there was a polarity to manage here, and they were hyper aware that they were shifting from the downside of ‘Responding to Change’, and they weren’t as concerned with saying, “Oh, you know, if we-if we switch, we’re not going to be Agile anymore” and-or-or these types of things. And so they were able to switch their perspectives over to the ‘Following a Plan’ pole and they did this by working out the features that were sure to make a splash at their user conference, and then working backwards from the date that they needed to hit, and they ran that particular project, a lot like a traditional Waterfall one, and you know, things were a bit hectic at times, and there was some overtime – closer to the deadline – but they did complete the projects on time, and the conference was a big success. And so here they are enjoying the upsides of ‘Following a Plan’ pole and you can guess what happened after the conference. Leaders kept asking for their team for detailed plans and they kept holding their teams accountable to delivery dates, even though there wasn’t any specific milestones that needed to be hit. The leaders generally got a taste of the certainty that following a plan and managing to it provides and they really liked it. But again, this, uh, this company was aware enough to watch for early warning signs that they were slipping into the downsides of the current pole, which included reduced flexibility, and loss of self organization in their teams, and, of course, less innovation. And so they quickly realized that it was time to switch back to the Agile pole. And so if you look at the polarity map, or I guess the moving walkway that we’ve drawn on top of this case study, you can see that while even the well managed polarity case study spends some time in the downsides of each pole. They’re astute enough, and aware enough, to know when it’s time to switch perspectives so that they spend most of their time in the upsides of these two poles.
Brock Argue Which leaves us with the challenge facing most organizations in the world today, getting the upsides of both Waterfall and Agile, and what we’re calling Integrated Agile. To get more value out of Agility, we need to be willing to move away from it once in a while. The genius of the Agile Manifesto is that its creators recognize that all values come in pairs and while the current manifesto recognizes that both are important, we’ve learned that you can’t have both at the same time. The manifesto attempts to solve this dilemma by favoring one set of values over the other. This is ‘over/more’ thinking but remember, the One Pole Myth? ‘Over/more’ thinking is simply ‘either/or’ thinking in disguise and ‘either/or’ thinking can only lead us to the downsides of the values on the left. The Agile values are a crusade from the downside of a more traditional approach into the upside of Agility, which is exactly what the software industry needed in 2001. But those values are only half of a dynamic that needs to be managed because all values come in pairs. The other half is the inverse of the Agile Manifesto, where we value processes, documentation, contracts, and plans over the items on the left. By learning to manage both poles, organizations can maximize time spent in the upsides of both poles. That’s why we’re suggesting the Agile Manifesto could use a small upgrade by replacing the word ‘over’ which promotes ‘either/or’ thinking. With the word ‘and’ we’re promoting ‘both/and’ thinking. We recognize these values as polarities to manage, not problems to solve. We call this the Integrated Agile Manifesto because it reintegrates values that have been marginalized for some time. You can find out more information about the Integrated Agile Manifesto at integratedagilemanifesto.org. “But wait, that’s blasphemy,” you say, “you can’t change the Agile Manifesto. It’s a perfect unalterable and sacred document.” Well, actually, Agile uprising recently did a podcast series with 14 of the 17 signatories of the original Manifesto. And when they’re asked, “What advice do you have for the next generation of Agilists?” the one message that they had in common was to not take the Agile Manifesto as gospel but instead continue to build upon it. We hope that the Integrated Agile Manifesto honors their work and builds upon it in a way that will help companies manage the practical realities of a mixed methods approach. And so as we wrap up there, we’ve got a few resources, where you can find out some more information here obviously integratedagilemanifesto.org. We just also like to thank Beena Sharma from the Vertical Development Academy who introduced us to Polarity Thinking.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Ellen Grove gave during the workshop on the topic of building alignment through team agreement.
About The Speaker
Ellen Grove is an Interim Managing Director at Agile Alliance. She helps organizations, leaders and teams deliver better results through coaching them to bring about the circumstances in which they can work most productively and create real organizational change. As a business agility coach, she helps teams and leaders in all parts of the enterprise to actively address the organization’s most pervasive problems. She introduces techniques from Scrum, Lean, Kanban, Extreme Programming, and Systems Coaching to promote successful collaborative environments that can adapt to changing business circumstances. She also delivers training and workshops in a variety of experiential formats to build the foundations for an agile mindset and practices, and use coaching and facilitation to solve the tough people problems and overcome obstacles to organization change at the team, managerial and corporate levels.
Ellen Grove And it’s something that has helped me considerably in my work as a team coach and as a leadership coach with organizations, this practice of making explicit, what of our ex… what are our expectations of each other as we work together? I think this is really important because one of the hallmarks of high performing teams is that everybody brings a different experience and a different perspective to the table. Um…teams that have like minded people where people come in expecting the same routines; expecting the same approach, are possibly, not always, they’re not always the most functional teams or… I don’t want to say they’re dysfunctional… but they’re not necessarily the highest performing teams, and that we tend to get the best results when we’ve got a diversity of thought and experience at the table. And with diversity in thought, Comes different expectations, comes conflict, comes the need to have hard conversations, the need to try new ideas and this is where working agreements can be really useful. Great teams exist in a state of – it’s called productive disequilibrium, right? We’re trying to be productive but we’re always a little bit out of balance because teams are a living system and living systems that are in equilibrium are dead. So, we want to be constantly seeking equilibrium but we’re never going to be fully within balance. But working agreements are a tool that can help us through that; help us manage that constant dynamic tension that high performing teams try to maintain. Um…the reason this background of this slide has a picture of broccoli is because that issue of, How do we use working agreements to manage conflict?
I worked with the team once, at a place that should probably remain nameless, helping to lift off a new team. And one of the things that became really clear in their early conversations was everybody on the team was kind of uncomfortable with the idea of being in conflict with each other. They were a new team; they were trying to put their best foot forward; they wanted to be successful together, but they’re like, “Oh, we don’t really like it when things get rough.” And in the course of the conversation, they identified that maybe this was going to be a problem to – to them being effective. And they decided as a team that what they needed was a team safe word. That when in conversations and meetings and stand-ups, if somebody thought, “ooh, things are – there’s an issue we’re avoiding here,” they needed a word that they could toss out and share to signal, “Hey, I think we need to stop and talk about this.” And the word they happen to pick was broccoli. And this stuck with me because this is the first time in my practice of lifting off teams the team had decided on a safe word that they wanted to use. But it was a practice that worked really well for them. If they all started using it right away, we’d be having a meeting suddenly, somebody would go, “uhhhhhh, broccoli!” It’s like, oh, okay, we need to stop and talk about that thing that we’re not talking about right now that we’re all dancing around and it was, it was really cool to see that in action.
So there’s a couple of approaches that you might take to building this alignment as a team to get to work together well, and a couple of places where I’ve taken inspiration from and how I use this in practice. One comes from Kent Beck in Extreme Programming Explained, where he talks about the idea of having teams identify their simple guiding principles; overarching ideas that we agree on as a team that are probably informed by our by our values that are a little bit more specific than our values. That helps us make the right choices about what we want to do if we articulate our principles when decisions come up about how do we behave together? How do we react to this situation? We can point to our principles and go, “Oh, okay, if we follow that principle, this is what we want to choose.” Um…another approach that I often use, as well, is having more behaviorally focused working agreements. Rather than just articulating a set of high level principles, we actually get very specific about the kinds of behaviors so that people are very clear and crisp about, “here are the skills and behaviors we want to develop as a team. Here are the things that we want to work on right now in order to increase our effectiveness.”
You can use either of these approaches as the means to help design our culture together. That’s really what working agreements, what simple guiding principles are for. It’s about how do we co create the culture we want to have together? How do we align on how are we going to be together in order to be a successful team? So just to give a simple example of the difference between a principle and sort of a more behaviorally driven working agreement, a principle might be something like “Be Present.” And this is often what comes out early in conversations. But what what’s important to us how do we want to be, we want people to be present. Okay, well, what does it mean? What would it look like if we have that? A more behavioral approach might be something like not having your electronics on the table during discussions, or not using headphones in the team room. Or… uh… I’m just thinking both of those behaviors aren’t really very relevant in a distributed world where we’re all connecting through electronics, most of us have our headphones on, but they give you an example of the difference between the high level principle versus the nitty gritty, “here’s a thing that we want to do differently.” So, these are also very simple, ver- very simple living documents and I Just wanted to show a couple of examples of what some of the working agreements that I’ve co-created with teams look like in practice, short lists of key ideas, whether they’re principle based ideas or specific behavior based ideas. Clear, easy to understand, co-created by the team, and visible and present as part of our visual management system, so that they’re there when we need to refer to them. Uh…Because that’s another critical element of the success of a working agreement. What gives them their power is for team members to be able to look at them and refer to them when you need to; particularly when you feel somebody isn’t or, and it might be yourself, but, when somebody on the team isn’t living up to what we’ve agreed to, it’s a lot harder. Just go to somebody and go, “You know what, we talked about doing this and I don’t think you’re doing it and it’s making me crazy” versus If you have this front and center, if you have the sort of the rules of the game posted in the team space, sometimes that makes it easier for people to call it out and go, “Hey, you know what? I think we all agreed that we were going to do this. And I don’t think that’s what’s happening here. What do we want to do about that, because I’m going to call broccoli on the team.” So having it simple, very simple, very clear, very visible, and very easy to update as the team matures, those are some of the hallmarks of a really successful working agreement.
So the kinds of things that you might put in a working agreement, often when I start working with teams, a lot of them tend to really focus on the process kind of logistics; when they say, “hey, let m-” when I say “let’s sit down and create a working agreement,” their minds jump to, “Okay, we’ll have our meetings at this time, and we’ll meet here, and we’ll do that.” and they might get into talking about let’s agree that we’re going to talk about things face to face rather than using email.Um… But when I create a working agreement with the team, I want to dive in a little deeper than that. And these are kind of at a high level, these are the sorts of questions that we explore in a conversation about working agreements. First of all, we want to get at, for each person, what’s important to them as a team member? What to them means… what does being a successful team mean to them? We want to create a collective understanding of what ar- what do we value together and how do we show it? The really important ideas are the how do we want to treat each other? How do we want to work together as a team? And what do we want to do when we don’t agree? Because, I think a lot of us go into a new team with an expectation that everybody thinks the same way we do about how a function a high functioning team should work. But when I go back to what I said at the outset about, one of the things that really makes us successful team is having bringing people together with diverse experience and diverse perspectives, it’s not really realistic to expect that we all have the same idea of what makes a great team. And if we spend a little bit of time upfront exploring that, that can really help take us a long way in terms of getting to be a functioning team sooner rather than later.
So, on that note, I want to stop talking at you for a little bit and give you a chance to explore some of these ideas in the breakout rooms. So what I’m going to share is setting up the breakout rooms. The question that I want to ask of you is I want you to think for a moment and we’ll take a couple of seconds to reflect individually on this. I want you to Think back to the teams that you’ve been a part of. And I want you to think back about what was one of your best team experiences? Or conversely, what was one of your worst team experiences? And I want you to think a lot about how did the team members behave in that setting. And that’s the subject of your conversation in breakout rooms. Whether it was the best team or the worst team, you might want to make clear which one it was, how did the team members behave that contributed to the team working that way? So we’re going to break you into groups of about four or five people. And we’ll give you four minutes to share your experiences and your ideas about that in the breakout room.
Host Okay, I just need to put one person in the room with his telephone. So let me move one person real quick. So that way… he is both in one place. Okay. I’m going to open up the breakout rooms and send you in those. And Ellen, you’re in a room by yourself so you can pop back out if it sucks you in automatically. And I said five minutes right, you’ll get a two minute warning.Ellen Grove Yeah, that will be great.
Host OkayEllen Grove Excellent. Excellent. Welcome back. Well, I hope certainly heard that there were interesting conversations going on in a couple of the breakouts. And I hope that gave everybody a chance to hear firsthand, first of all, the kinds of experiences that people have had and how there’s a real range in what we value as team experiences. Or even perhaps you might have found that some people identified, “Awww I had a team member who did this thing and it was the worst thing ever.” And somebody else is thinking, “Wait, I love it when my team members do that.” And this is the purpose of creating a team working agreement is to make some of these assumptions explicit; so that we can decide together, how can we work together to be more successful. We can be aware of what people’s preferences are, what people’s, you know, what people really like, and what are the things that are going to make them crazy as team members? Sorry, let me advance my slide here. So this is about it. Working agreements are about aligning expectations about making sure that everybody is on the same page about, for us, for this group of people, what do we think it means to be a good team? What are the things that we need to focus on as a team in order to be a more more effective team? When you create a working agreement with the team, it helps individuals become more aware of their own behavior. So simply by having the conversation about, “hey, these are the kinds of things that we want to be doing”, you don’t have to have somebody who’s being kind of, you know, the behavior monitor for the team. If the team has talked about and said, “Oh, we want to focus more on communicating this way” or “we want to make sure that we’re doing this”, every individual is more inclined to think about, “Am I doing that?”, “Am I doing enough of that?”, “Am I doing too…” you know, to evaluate their own behavior, and step up to the plate a little bit differently. Having a working agreement gives us a mechanism for establishing mutual accountability. When we have created a working agreement, and ideally, as part of creating the working agreement, we’re going to ask explicitly, “What do we think we should do if these things aren’t happening?” That gives all team members a space to hold each other accountable. Because we’ve already agreed explicitly, hey, as a team, we sat down, we had the conversation, we’re going to do all of these things, and we’ve talked about what we’re going to do if they’re not happening. Even if people aren’t feeling as confident as they might about calling each other out. It gives them a tool that they can use to say, “Hey, we agreed on this, it’s not going on, what do we want to do about it?” So it’s a means of establishing clarity, of being transparent about what our assumptions and what our desired behaviors are, and really creating respect for how other people want to be as part of the team. You know, and if you had to wrap it all up, it’s a tool that allows us to encourage – we want diversity and thinking because we want people to bring different ideas and different opinions to the table. But having said that, we do want to have some degree of harmony and behavior so that people can work together effectively; you know how the human system works.
So I talked about really focusing on behaviors rather than process and the questions that I like to use When we’re talking about things that we need to put in a working agreement, there’s these six questions are kind of my go to. Now, when I do this talk in a non-distributed setting, we explore these through Lego serious play. I couldn’t figure out how to share Lego with everybody. So unfortunately, we’re just going to talk about one of them today. But these are the questions that I use to get team members to open up. Let’s talk about our best or worst team member because that gives us a sense of the experience that people have had. And also, what do you like? Like… what… what do you like when other team about how other team members work with you? Or what are the things that people have done with you in the past that might be triggers for, “Oh, don’t talk to me like that!” I like to ask people to reveal what’s the superpower you bring to the table? What’s something about yourself that other team members might not see but it’s going to help the team be successful? What kind of help do I want from my teammates? Because I think this, again, is one of the hallmarks of really high performing team is a sign of a really functional team is when people are ready and able to ask for help as soon as they need it. And that’s something in a lot of professional environments that’s really hard. Because we’re conditioned to be the experts; we’re hired because we’re the best at our job. We have a deep knowledge of skill, you know, we have deep knowledge and skill in this area. And it’s really hard for people to come forward and go, I don’t know, I need help. Please help me. So having that conversation at the outset can be super useful. This is a question that I got from my friend Jake about talking about what happens for me when the going gets tough. If I appear to you to be stressed or overwhelmed. This is the kind of help I would like from my teammates. That’s really useful information for us to have before the going gets stressful because some people want a lot of hands-on support and encouragement. Other people are like, “No, I’ve just got to go figure this out. Leave me alone!” And wouldn’t it be awesome if we knew about that; if we knew what their preferences were before that happens? I think it’s really important as we’re talking about working agreements to talk about conflict. Um.. and I do a really simple exercise. We’re not going to do this one today; we’re going to discuss another question. But the conflict question is, I just get a bunch of different colored pieces of paper or you can use crayons, or marbles, or Skittles; doesn’t matter. Get the group around the table and ask them to pick the color that signifies conflict to them and why and just have a quick roundtable conversation about that. Because you might assume given some of the cultural associations we have with color and emotion, that everybody would pick the same color and they don’t. And you can learn some fascinating and really useful things about how all of the members of your team feel about getting into difficult situations just by doing this really simple exercise. And then the last question, which is, again, a really important one, is talking while we’re putting together our list of these are the things that we should do. What do we want to do if one of us is letting the team down? How do we, in the event that we’re not honoring our working agreement, how do we want to handle that? So everybody knows from the get go, this is how the process works. I know what’s going to happen if we noticed that this isn’t happy that what we’ve agreed to isn’t happening. And these six questions I think, are really, really useful for forming a working agreement. I’d like to send everybody back into the breakout rooms for..do we still have time a five minute break out, Cherie?Host Yep, we still have 20 minutes.
Ellen Grove Awesome. Perfect then, because what I would like to do is send you back into your breakout rooms to explore one of these six questions. I think I phrased a little differently between the slides. But the question that I’d like you to think about right now, I’ll give you a couple of seconds to think about it, and then talk about in your breakout groups, is this question, “What kind of help do you want as a team member? What kind of help do I want from other people on my team in order to be at my best?” So give you a couple of seconds to think about that and then we’ll send you into breakout rooms where you can chat, with the group that you met with before, about what kind of help would you want to be the best team member you could be?Host Okay, Welcome back, everybody, everyone is back in. So we’re good to go forward.
Ellen Grove Excellent. I hope that brief conversation about what kind of help I want to accomplish two things. One, Hopefully you learned about other people in the group, what kind of help would they want to have to be good team members? Because if we were in a situation where we were starting off a new team, this would be fabulous information to have about how can I help my teammates be awesome, understanding and upfront what kind of assistance they want from me, helps me to be more of the kind of team member they’d like to work with. It also helps me as a team member think through, “Well, what what kind of help do I want?” Those of you out there who maybe aren’t… I know, I’m not a very introspective person – and while I know what I don’t want, I don’t think I ever spend much time thinking about, “well, what kind of help really do I want? What is this thing that helps me to be more effective at my job?” So having these conversations helps us clarify expectations, both between team members, but also internally. And I find that really, really valuable. And there’s are these are while everybody was in the breakout room, I was looking at some of the conversation in the chat and there were suggestions about here’s a template you can use. Here’s a great article. Here’s some ideas for how tool that you can use to shape this conversation. And I just want to say there’s lots of ideas out there. I – those six questions that I shared with you in the previous slide, I’ll go back to them. These are generally my go-to questions, because I find, for me, they touch on the important aspects of how do we want to be a team together they start to build, how do we appreciate each other? They dig into the, “What kind of help do I want from other people?”, “What are we going to do when the going gets rough? and especially if we find ourselves in conflict, give me a clue about what other people expect, because some people are very conflict avoidant. For other people. It’s like, Ooh, you know, lots of arm waving and loud voices. That’s how we exchange ideas. It’s really good to know upfront which way the other people in your team are wired. But there are other kinds of questions you might use. You don’t necessarily need to use my six. They’re a great place to start. But there are some other kinds of questions you might talk about. You might have an explicit conversation about values. What are the values that we hold together, what’s important to us, what matters? What kind of space do we want to create together? Real- you might, depending on the team, I’m not sure I would use this with a new team but certainly if you are revisiting your working agreement with the team that had begin to… begun to work together for a while, having an explicit conversation about how do we increase trust? How do we take it to the next level? Um… but I think it’s also the last one here, I think is really important, no matter which questions you ask is, “How will we know if our team agreement is working? What will we see? What will it feel like? What will we observe?” And I think that’s a really important thing to keep in mind when you’re building a team working agreement together. Because often when you sit down and you ask the team, how do we want to be together, you get, I mean, lovely suggestions like: Be present. Let’s treat each other with respect. But it’s really helpful to dig into what does that mean, if we’re treating each other with respect? What does that actually look like in practice? What is the observable behavior that signifies respect? Or if we didn’t have it for each other, what would it look like? Because that really helps a team come together and create a shared expectation of what we’re trying to do. But any set any set of questions, like I said, mine will work for me. But they all they all center around, how do we create the environment, the atmosphere we want as a team, what kind of behaviors will help us create that atmosphere? You might talk about, “How are we going to make decisions together and put that as part of the working agreement?” And and certainly that last bit of it, “How are we going to be in conflict together when it happens?” Because I’ll say the only places I’ve seen where conflict hasn’t surfaced have been some of the most dysfunctional organizations that I’ve ever worked with. “No! No! nothing to see here, move along.” People just aren’t wired that way; my experience.Ellen Grove So a simple framework that you might use for thinking about how do I have a working agreement conversation is getting the team together. And just, first of all, setting the context: Why is it important to create an agreement? Why- Why does it make sense for us to invest a little bit of time, aligning on our expectations about how we’re going to be together. Spending a little bit of time investing in some of those exploratory conversations, like the questions that I suggested that really get at: What’s important for me? How would I like to be helped? How can I help other people in the team?” without diving right into the, “What are the behaviors we are going to agree on?” Spend a little bit of time exploring the topic. After that conversation, that’s where you might ask the team members, “Oh, okay, given all of the things that we’ve talked about, and given what we know about each other so far, what do you think if we’re going to create a team working agreement, what do you think the specific behaviors we need to include in this working agreement, at this time, are?” And that’s what those questions about, “What would it look like if we had it?” or “What would it look like if we don’t have that?” that can come in helpful, because sometimes people will still propose a higher level, “be respectful”, “let’s be nice to each other”, “make sure every voice is heard”. And those are all great things. But sometimes those aren’t enough direction to let people know really, this is what it means when we’re making sure every voice is heard. So get the teams to propose team members to propose the specific behaviors they think are important at this time. And then as a team decide on, which are the ones that we want to focus on? Because you don’t want to overwhelm people with a list of here’s the 10 things that we want to do. Here are the two or three or five that are the most important to us right now and that we’re going to pay attention to. And then like any good meeting, let’s make sure that we agree so we’ll do some sort of confirmatory thing to make sure that everybody is bought in and then a checkout of the meeting. And I just included this in the list of the framework because I really like this question and I was- while I was putting together these slides, I read a blog post from Jimmy Javelin. And the checkout question he suggested was, which one do you think will make the biggest difference? Which one is your favorite? And I love that as a way to get people to really focus on, “what have we decided to do here together? What part of this am I really excited about?” I also think that question might be a little very useful a little bit earlier when you’re trying to select the behaviors. If you can’t decide, which one do you think will make the biggest difference? Let’s focus on that right now. I added this in, this wasn’t part of my original blog posts but it’s something that came across my screen recently, and I just wanted to share to present a little bit of a different viewpoint on this topic of creating working agreements. Because it’s…could be useful to you, Roger Shwartz, wrote The Skilled Facilitator who’s really he’s an expert facilitator and expert in group process, wrote a really interesting blog post on LinkedIn recently that says, You know what, sometimes you shouldn’t leave this up to the group because the groups actually don’t know enough. If you’ve got a new team, or you’ve got a group that’s only coming together for a short period of time, they might not have enough knowledge and context to be able to propose useful behaviors that will really help the process. And his approach was to present a list to the team based on your experience as a facilitator based on your knowledge of the group process that will help this team, this group, be successful. His suggestion is you propose the working agreement and take it to the team. I’m a much bigger fan of having the team co-create their own working agreement, but I wanted to include this to provide a little bit of balance because I – as a facilitator – I can imagine some situations where I actually might want to see the working agreement of the team, I might want to propose, here’s a starting point that we can use. And I thought this article had some great ideas in it. So you might want to take a look at that and consider that as well.
So, on that note, I’m just going to go to the last slide. I just want to give you some ideas of some places that you can go for more information. Of course, there’s the blog post that I wrote, which is why I’m here today about how do we build team working agreements, what are what’s it revisits a lot of the stuff in this presentation clearly. Why is it important? Here’s some questions we might ask in terms of how to do it. Here’s how we attend to the care and feeding of our working agreement. I was inspired in a lot of this by Ashley and Diana’s book on liftoffs. Because I think working agreements are critical to getting a team off to success. And there’s some additional material in there about some examples of how they’ve done this in a variety of settings. And if you’re looking for inspiration that might be a place that you would go to. The other two places, the article by Jimmy gendlin that I mentioned, which was a great approach on bootstrapping teams with a working agreement, and then just just take a different viewpoint, the article from Roger. I’m going to stop here and just find out if there are any questions that I haven’t haven’t addressed. Any new questions that have come in.Host Yeah, we have two or one is, would you suggest having the team craft working agreements as part of a retro or in some other meeting?
Ellen Grove I try to do it, actually, at the outset. Like rather than waiting to unless you’re having a retr- You might tune your working agreement during a retro, that’s a great place to sort of think about, hey, do we need to adjust our working agreement based on what our current ambitions are based on the improvement ideas that we have in mind. But I think to actually initially create a working agreement, that needs to be part of…of… it’s got to be at the start, rather than at the after the retro is always after we’ve spent some time together. So, I usually do this as part of a team liftoff.Host Okay. Thank you. And then the next question that we have from Christine is what are some ideas that you’ve seen teams come up with to hold themselves accountable to their working agreements? Hmm.
Ellen Grove That is a great question. The safe word, the broccoli word, was an interesting… an interesting approach to that but it turned out to be really useful for that team. We had an explicit conversation about, here’s some of the things that we want to do. And they came up with a kind of a fun flag for people to use to signal, “Yeah, I don’t think this is what’s happening right now.” Um… just having those things present and visible has been really helpful to a lot of the teams that I work with. Um…sometimes they might even do – I’m hesitant to recommend this, but I’ve already started down this path, so I’ll say it- Sometimes they might sort of say, hey, Does somebody want to really focus on keeping an eye out for whether this is happening or not happening? And just kind of highlight to us if you notice it, and maybe take turns sharing that responsibility? I’m really care. I want to be really careful about suggesting that because you don’t want to appoint anybody on your team to be the “Behavior Police.” But sometimes it’s useful for, you know, to take turns going, you know, we know we have a problem with this. We need somebody to be paying attention and to at least notice when we’re doing that. But that’s really also very context and personality specific. But those are three of the things that I have seen work in practice.Host Awesome. Thank you. And then we have time for one last question. And it is what helps you create psychological safety?
Ellen Grove Oh, simple question. No problem, I’ll knock that off in 15 seconds. I mean, again, that’s that that’s a whole other thing. In terms of creating working agreements, I think one of the things that’s most important in terms of creating psychological safety is really helping the team understand that this is something that they are – this is a tool they are creating for themselves. This is not something that is for people outside the team to use, or I was going to say even necessarily be aware of although it’s going to be part of your visual management systems, hopefully. But coming into it from the approach, that, as a team, we want to work together, we want to support each other, we want to help this make our team a place where everybody can be the best that they can be. And really letting them drive the discussion of what do we need in order to do that. And that’s where, even though I shared at the end, the idea of possibly bringing a prepared working agreement to the table, I think one of the things you need for to make it as a safer conversation is to really put the control in the hands of the team. It’s not about what I expect of you. It’s about what you expect of yourselves, and do everything you can in order to reinforce that.Host Awesome, thank you. Well, everyone, we’re at the end of this session. I’m going to go ahead and relaunch our poll just to give some feedback.
Mastering anything is hard and laborious. Scrum Mastering is no different. The real mastery of Scrum results from constant learning, inspecting, and adapting.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Ewan O’Leary gave during the workshop “On Scrum Mastering.”
Ewan helps organizations face the challenge of volatile, uncertain, ambiguous and complex times, shifting from conventional thinking, amplifying learning and rehumanizing their work. As a coach, he liberates human potential by recognizing and developing the leader in everyone, at all levels and capabilities, in service of greater meaning and purpose. Using a mix of lean/agile techniques, Ewan has helped people transform their approach to work and life, learning rapidly from failures, creating value and joy through their work. As a compassionate catalyst of disruption, he challenges your organization, helping you develop novel ways of developing and understanding shared purpose, meaning and the work needed to achieve your objectives.
If you would like to subscribe to the soundcast of these talks, head to Soundwise.
Today Tandem Coaching Academy publishes the talk Elena Vassilieva gave during the workshop on the topic of managing and dealing with the stakeholders.
Other Best Agile Articles 2018 Posts
Philippe Guenet When I wrote that article, it made me think-
Host You’re on mute, somehow it clicked on-
Philippe Guenet Sorry. Yeah,thanks. Thanks. That brings me back to this article I wrote some time back and today, I’m going to try and bring a twist of COVID on it. Because you know, that’s, that’s highly disruptive and I think it reveals even more when we look at COVID.
So as… hold on let me just…adjust the slide – just a quick introduction. I’ve been a lot of my career in digital and… I don’t quite like to be introduced as an Agile Coach. I’ve been in digital change for a while, and really, Agile is a pseudo name of trying to be competent and performant with digital, it feels like, and-and working with software. And in parallel, I realized that to…you know, through a long cons-consulting career, I realized to really up til now was not so much about delivering solutions for them, but helping them to gain the competencies of being digitally competent. And, and working as teams like this. And that’s why I shifted my career about three years ago, with an effort towards coaching and being a coach and actually being a certified coach, together with Sherry on the same cohort. So that’s how we met. And and since then, I’ve focused on digital leadership as a slightly different term to achieve you know, the performance in digital and what our job is meant to be. And this article was leaders of chaos. Our traditional management perpetuates chaos in digital it. And today I’d like to also visit our is the leadership coping through COVID and the types of leadership coping to COVID. But to make it fun, because it’s quite late here. I also bring a flashback I don’t know if if you’re old enough to remember the adventures of the persuaders. Were a team it was British series, but apparently it made success more in Spain, France and other parts. And it was it had a fantastic start with comparing the two main actors which were Roger Moore and Tony Curtis as log bred sinckler. And then you wild law bread center was really the tradition very British out restro cracy, Army officer gentleman driver, old money and very much entitled. And Danny Wilde was raised in the Bronx, he served in the Navy made his money through oil in Texas. And Wall Street, it was very much a new money and go Gator, and and they were sort of partner together as chalk and cheese. And, you know, to solve crimes of some sorts and and they worked well together. But I chose those as kind of the metaphors of the traditional manager and, and the more sort of new type of manager. And actually, you know, I’m a bit of a petrol head and, and their difference was also visible in their car. For those that know on the on the left hand side here, you’ve got Dino Ferrari, which is not a Ferrari. So you know, with the V six and quite an original first central engine, rear central engine and to the right is the Aston Martin DBS, which logbooks and Claire was was driving much more traditional.
And if we look at log birth centers, the traditional manager, you know, very much suited sleek looking and so on. What does the regular manager cares about? And fundamentally, it’s about projects and big budgets, that that’s how they’ve been, you know, grown. And to a degree, I mean, although he was very slick in a series and very British, they groan about being a bit tough. In a show a leader or manager you have to make tough decisions and you have to, to commit to objective and deliver to the of victims, that’s what a manager does. And for that, when you have to apply some control, you do that by looking at the rock status very often you look at the Reds much more than the amber and greens, and you control costs and risks. And of course you have, you know, some some challenges and some worries about your careers, your perception, you need to look good. And and that’s all the motivators a lot of management out there. That’s what they grown into.
That’s what they used to. That’s what they’re good at. And and what is the unintended consequence of this is very often the watermelon projects. So don’t know, show of hands, maybe who knows the watermelons project? No. So they’re green on the outside in terms of rock stages, but red on the inside. So what happens, they’ll they’ll green, green, green, then for one week, they Ember and then they go red, generally three weeks before the release time. So that’s a very much of unintended consequences, because people are not in a safe environment to actually declare the challenges. And they try and just make the best of them. And and eventually, you know, you can’t avoid it. So that’s what happens. Now, I’d like to explain that through a framework I use quite often the sense making framework God Kennedy, do you know, Kevin? Yes. So just just to summarize it quickly, it’s, it’s, it’s composed of five domains. It’s not a five quadrant, a framework, it’s five domains. And in the middle is confused, which was before that called disorder. And it’s a state of trying to make sense of a situation. And generally, that’s where you start. And then you have the clear, to the right, bottom, right. And basically, the right is what they call the order domain, and the left is an order. And to the right, the clear domain, is relatively simple. It’s things that have been experienced before things that are generally known.
So you sense the situation, you categorize it, you respond, generally, there’s a process of protocol or policy that exists to deal with it. And it’s, it’s regimented, in a way by best practices, and generally rigid constraints, your policy to deal with those things. And then to the top right, is relatively similar, except that those situations are more complicated. In a sense, you need to make sense of them by analyzing or calling up the experts. And again, you can, you know, resolve those challenges. And you apply to good practices, and they obey the space obey by a governing constraints. And it’s the base space where you spend time analysis or a root cause analysis and calling in the experts. To the left is the less, you know, the unordered domain where it’s less clear, what is the root cause, or the causal link between things doesn’t really exist in hindsight. And in that, that complex domain, what you do is you tend to probe first. So you’re going to do experiments, and, and then you send the results of experiments, and then you adapt your response to that. And that’s the space for emergent practices. An examination examination is when you recompose things you already knew or things that you already operate, and you create something new out of that. And it’s a space as well for enabling constraints. So rather than seeing constraints as a limiting things as constraints now become enablers. So you you you put some boundaries, and people sort of recompose and do things differently, to create something new. And that’s the space of complex and display. so chaotic, is a space where there’s a degree of urgencies that is no known answers. And and when it’s like this, well, we tend to act first. You know, you have an outage, you’re going to try and resolve the outage to get yourself out of the situation. And then you will land into another domains and you adapt. So you act first you sense and you respond. But it’s also a great space because when things have broken and so on. There is no constraints anymore. Anything is possible. So it’s also a space that can be extremely creative with novel practices. What happens to those watermelons? How they materializes, there is a view of the world that everything can be analyzed, planned and committed. Anything can be controlled, in essence. And and once it is analyzed and planning committed, then we just have to execute, right? We execute through control with iraq stages to monitor it. And, and inevitably, when things go wrong, it falls into chaos. And that weekly think, at the bottom of the Navy model, this organic sort of limit, or boundary is is indicating a 3d cliff. So what happens is, when when things go wrong, you fall off a cliff, and you have overruns, you tend to try and compensate with deathmatch projects. And of course, you have a trail of tech debt. And it’s very difficult to climb back your way into clear from chaotic. And, you know, the way those those leaders actually operating this day, maybe they didn’t even have to lurking problem for so long.
But here they come along. They both have shoe people around the results on constraints that people couldn’t resolve. And suddenly they save the good, they save the game. And this is very rewarding part, to be able to save the game all the time. So what happens is, they focus on rock status, they get involved when it’s read. And effectively, they are creating chaos in your organization. Because they’re not focusing on green, they’re not focusing on Ember, and not focusing on improvement. And that is, when the CIO says we’re going to be agile on top of this, what happens is nothing changes. There’s an agile beat in the middle, but it doesn’t substantially matter. And worse, is that this is actually a characteristic that perpetuates because those people value heroes, they tap on the shoulders, the people that would work all weekend long to fix an outage. Those are the people are going to get promoted, those people are get the bonus. It’s all based on effort. When it’s an effort that fundamentally is, as its roots and foundation into dysfunction. And we’re creating, you know, a psycho minimi, psychopathic minimes that end up, you know, basically, in the leadership of organizations, were creating chaos. So, what would we like to have happen back to our heroes, and Danny Wilde, the cool new Monet character, the sort of No, that the guy that could make magic happen, we want in the digital magic to happen. We want to have the unicorn of engineering, how many times do I hear we have the wrong people. We need better people, they don’t get it. But generally as a leadership problem when it happens, because Google and so on, are in the same pool. And we need to move at speed, you know, grow and disrupt.
And sometimes, you know, wear t shirts and sandals as well, maybe some people even try to start with this because they think the rest is gonna come. And essentially, what we’re talking about is there is a dynamic in digital between opportunities and innovation and industrialization and excellence. And what we see is in what we don’t see is the relationship between those dynamics, and that’s where we talk about digital value chains. Because those are very much connected. And actually what makes it operate in the middle is the systemic leadership. It says ideas of working with a system of work, and getting the autonomy into the system of work, applying a lot of the systemic coaching techniques into leadership. So if we go back to the Canadian press, work, what essentially happens is those leaders operate into the complex, quite complex domain. And they look at options, experiments discovery, very much generated small experiments, that guide in what may actually materialize. And those small experiment travel to the complicated once we discovered, once we know better once we tried and we see what works, it becomes complicated, we’ve built the expertise to know. And that’s where we look at amplifying, we look at improving, and iterating on that. And once we are actually very useful expert, we truly try and scale things, we try and build things up. We try and get that competency as a standard in your organization. And we you know, it goes back bigger and better, as goes towards the clear. And essentially, what we’re describing is a learning journey to start with. We were simplification, modernization industrialization journey that follows that. And importantly, in digital, we need to recognize that the industrialization allows to free capacity for innovation. So it enables new value through innovation. Because it frees the capacity.
It’s not like it’s valued. It’s not like it’s a chain of production, it’s people. And if we use less people to do the existing, we get more people to do discovery innovation. And that’s what the digital companies do very well is it continuously cycles through this. Also, those those new leaders, they value the people capital, and I’ve heard this term, you know, as opposed to take that, essentially what you got is people capital, and what you’re investing in is people, technology will change solution will become obsolete, people need to grow through that journey, because they are the future. And diversity is also absolutely necessary. Because cognitive diversity, which is very often a result of diversity of people, culture, you know, skin color, religions, diversity is very diverse in itself. Diversity is about the curiosity of others, to actually explore the ideas, you may have to innovate. And diversity is essential in creating new ideas, connected with the people that are your customers, the people that buy from you. And that needs to be reflected in your teams. And, of course, collaboration is all of all of those great people working together. And in those organization, you promote the behaviors, you don’t promote the effort to promote behaviors and skills. And that creates a self sustaining evolution. So what about COVID? You know, that that that has thrown a spanner in the works, and you feel on COVID that has landed everybody right into chaotic. And some people, you know, I’ve remained into confused as a space, and they’ll paralyze, they just don’t know what to do. And what we have is the regular managers, they are trying to recenter on the call, they’re trying to safeguard the business as it is.
They’re trying to reduce the cost to achieve that. You know, they’re trying to get their hands on something concrete, are we going to return to work? Are we going to make that office with Plexiglas between people and other people are pressing live button? I don’t think so. I guess. But should I be really thinking about that? Because the other leaders think about new possibilities. What can we do the business? What made that open as options, new plans, new possibilities? You know, as we said earlier, the chaotic domain is a space of no constraints. Noble practices can emerge. I’ve got a friend of mine who works into a travel company, and he was doing total skunk work because he, he had to commit to long distances trying to figure out how can I get remote work to function. And he was a hero overnight, because he had worked out a solution using zoom before coronavirus, heat and lockdown. So he was ready to roll it out. And that’s really the kind of stuff situation where new possibilities happens. exultation can happen. And actually the people think remote first, they take cues that the working practices as changed probably forever. And rather than focusing on returning to work, especially as more and more lock downs are likely to happen, it is about making the most of the situation and exploring a new potential of the business route. So, are we going to reconfigure manager one zero with some leadership to zero, and reboot the lot. So, there is and that’s the approach I tend to take is this an element of strategy. There’s an element of leadership, an element of excellence, digital excellence, strategy very much about situational awareness and understanding the landscape we’re in to start with most of the time strategy, start with wishful ambitions. Let’s first understand the situation and visualize the digital value chains. Look at exaltation. And the adoptions work out the balance of innovation and industrialization, and very importantly, strategy to the people.
And if we want autonomous teams, it is absolutely essential that they make right decisions. Because if they don’t, the autonomy will be removed from them very, very quickly, we need to give them the element to make good decisions. And that means they need to be part of the strategy, because they will enrich the strategy with the limitations. And at the same time, part of this process strategy will become theirs as well. And they will be able to deploy and executed a lot better.
When we talk about situational awareness, I often look at, you know, enterprises in relation to a fairly linear process of having stable estate. So the stabilization of your state is often a problem when some tech debt is lurking, for some time, and optimization of a lot of the flows. And basically automation, which is the optimization of the business, it’s using technology to automate the business. And and then that enables innovation. And through that journey, if you’re in a stabilization zone, you have very, very little capacity for doing opportunities, exploration and experimentation. And you spend your time fixing problems. And you need to recover on our journey and start deriving a journey, so that you spend more time on the portunities and experimentation. But equally, it’s very important to start this journey. Because if you just say cost, at some point, you got to basically get rid of engineers, and in a digital world, that’s the last thing you want to do. So those are journeys that goes in parallel. And when I talk about value chains, understanding how your value chain of your business deploys on this, and you have tools like wardley maps, that helps a lot to do this. And once you do that, you realize that you manage actually very differently to the right of this or to the left of this and saying no agile one size fits all is completely wrong. And that’s where the leadership needs to understand and coaches as well. You know, that we need to have a situational awareness of the landscape to understand where we’re going to integrate, and we’re going to explore where and where we’re going to industrialize and normalize.
And now all those things all connected and rely on each other.
Now leadership, it is about switching really from task management. And leaders have been built, much most of the management has been built on managing tasks, and projects, managing programs, managing budgets, and portfolios. It is generally around managing tasks. And now they need to manage people in the system of work. And that is very different.
So it’s all about relationships and alignment and connectedness in the network, getting people to connect to each other, understanding their relationship to outcomes, and things I’ve done on an org design recently is asking people do not look at them racy. So the raci is responsible, accountable, consulted and informed and establishing each role, and how each role is actually involved with those things. What I’m asking people to first look at it, how will you in relationship with what are the outcomes of those relationships. And then we can work out the roles of the relationships. But fundamentally, we should design system of work to be in collaboration with each other in relationship with each other. Otherwise, you know, people do their job, but they’re not designed to collaborate. So it’s also about working with the emergence complexity is very much about what is trying to happen in the system of work. And it’s one of the recent sort of refresh Avast is about principles. And one of the principles is the system of work, the system of work is in permanent state of emergence. So how can we make take advantage of that innovation relies on getting that emergence to bubble up understanding weak signals, hearing the voices that are generally quiet, sometimes the other geniuses and getting that to bubble up experimentation, and actually finding its path through the reality or whether the customers buy or not. It’s also adopting a coaching stance in leadership. All the leaders need to really realize that their word, their attitude, their reaction, have an impact. And now Can they make it to positive impact for the people and generating autonomy and stimulation, I’m absolutely convinced that there is a role for leaders in the modern organization, I don’t believe that organizations can be just completely self autonomous.
But the role of the leader is not to get in the way, the role of the leader is to stimulate the organization to find its way and to be better. And that role of stimulation is needed. So if we think in terms of alignment, no, digital is about aligning the company, aligning Business and Technology working together, aligning executives and teams. And that alignment is basically an execution flow that is balanced with an improvement flow. It’s also having a strategy and change flow that is balanced by an emergent flow. And it’s getting those flows to be in balance permanently. Now, excellence, so this is kind of the the things that are more known. It’s about improvements. It’s about Kaizen, it’s about DevOps, you know, agile, in some cases would fit probably here. Spot value streams and flow and resilience is a very interesting thing in digital is that to manage quality, you don’t see what you’re managing, it’s virtual. In a car. If there’s a dent in the door, it doesn’t open properly, if the engine doesn’t stop, you see the lack of quality very quickly and easily. In digital is all invisible managers are blindfolded effectively. And that’s where creating a visibility of the work they know can ban gamba, collaboration, understanding the tech debt and capturing it in a way that we work with it and investing in engineering capital in the people that make the capital. And again, if we visit COVID No, I mean, I picked this up on on the internet. And I really liked it when you think our much money has been invested in transformation programs with big, big senior leaders driving those Transformation Program. And COVID-19 has probably driven more transformation in itself in a few months, and then in a lot of those programs. And when we look at what what does that mean accelerating change in COVID time, it’s almost Maslow’s pyramid.
And you need to first out the tooling and practices at this spare company completely working with Skype at the moment because you can do very little if you want to have effective meetings. You need to design those meetings, like workshops all the time, you get to get people engaged in those meetings. You need to have collaborative documents, you need to design that interaction. So people will get engaged, you need to think about a knock to the meeting, an arc where you may start with a problem, how can we refine that problem statement that it really engages the people, that it doesn’t create a bias for solution. But it actually creates something where people will collectively come to resolve that very often, what I see instead is people saying, well, I call that meeting and we’ll tell you what I think and then you have, you know, you can query it. So I’m going to put a big bias on the table, especially if there were senior, and then you know, everybody has nose Depo and is quiet as to compare contribution. Instead, we should start a meeting with the problem statement. And then allow people to diverge and ally creativity to happen. And it’s about creating that space where we we try and avoid having a reality. Or we can do that, because we can do that. Because No Why not? Let’s try what what would it take to do it without solve and and let the space open. So creativity can happen. And navigating basically, to a deeper level where where we touch the imaginary of the people. And then of course, we need to find in the like, for coaching, where we close with forward action, we need to actually lead people back into action. What are we going to try and what experiment becomes possible. And if we, we dreamed we dreamt, you know far enough in terms of ideas, obviously, those things may not be a slam dunk. So is there a thing we can try that can prove that we could go that way. And that’s why progress as well, progress gets made. But first, if you don’t have the tools, if you don’t develop the practices to do that effectively, remotely, in COVID time, you can’t do anything.
You can barely run the existing business. That’s it.
So working double out, because we’re remote, working double out on creating that engagement. And bringing people together to imagine possibilities is necessary in COVID. This is accelerating change. Looking at the team health, you know, we don’t talk very much about him health. But it’s tough for a lot of people. A lot of people that are alone at work was their social time, almost. I mean, it was part of their social time. And, and some people find it tough, and I think they are funny, tough for some time. And now we seeing more lock downs with winter coming upon us, it’s going to be very difficult for some people. And no large organization as the leaders to be in touch with everybody, and so on. And they can’t they have a business to run and they have so many hours in the day and COVID made it more difficult. So it is time to build a team and resilience, it is time to get the teams to look after each other. It is time to bring that autonomy in the team. And this is about alliances. This is about checkins. It is about the team every so often taking the time to reflect about themselves. It is about also making the effort to have some social time. But all this is also accelerating things we’ve been trying for a long time is becoming a necessity of COVID.
And we see as again, the possibility of accelerating change of teams, creating more autonomy, more independence, more thinking about themselves and being better together. So weirdly enough, you know, by being separated, we can actually be more intentional about the collaboration and and focus on on this even more. So that could be done. And that’s for leadership. Where do we start? Where do we start? There is so much and appreciate it’s extremely difficult in those times for them to also rethink how we’re going to lead. But it is about enabling the system of work organizing for flow. Why do we have to have bottlenecks between silos and every information going up the silos done another one another silo done another one. This connected teams together Start to create those organization where the work flows naturally. And it is time to share the strategy. So the teams can make autonomous decisions, it is time to accelerate those things. And and again, you know, maybe those things would not have been as pressing outside of COVID. It is also time, of course, to look after, how do we rescue the current business, but sometimes it’s about reinventing the business because it’s not really excusable. No, and I live in London, and I’m outside London, but the centre of London, I have not been in the centre of London for six months.
The sandwich shops, you know, have nobody to sell sandwiches to in the city or in Canary Wharf. And those are expensive estates. Why don’t they do a delivery service elsewhere? Why don’t they reinvent their business? They are closing shops. But there is a new demand elsewhere, I’m sure. So they could think about things like this. And I worked with enterprises in startups, as well as large, large clients, and large clients, it’s very difficult to reinvent the business. Whereas startups are naturally more inclined, and more entrepreneurial, to actually do this. And for their survival, they can pivot a lot quicker. And what we’ll see so we Stein is actually that some large businesses are probably going to suffer massively, whilst a lot of startup are going to reinvent something new. So it’s, it’s it’s a really troubled time, but it actually also can be a really novel and creative time. So in summary, we can forgive reconfiguring leadership is really about moving from Meraki to decentralized, moving from cost mindset to growth mindset. You know, moving from planning and control, to actually strategy participation and sharing and involvement of the people. It is about Kirby, many of them are technophobes, and they have to become technophiles. It was authority, it has to become an enablement. It was about control. It’s about serendipity. Now, it was about tasks and projects, it’s about people. And with COVID, it’s also about remote first, at least for the time being.
Thank you very much.
Host Awesome, thank you. All right. So we’ve got a few minutes for questions, comments, thoughts? Who has something you’d like to bring to the table? Ted?
Ted Wallace It’s wonderful presentation. I really appreciated it. I especially loved how you use the cabin model to explain the watermelon type of that was those brilliant actually. Kevin is an interesting thing, though, because this is insight my dad had when we were kind of studying it, it’s all perspective. For somebody, it could be a complex problem. For someone else, the same problem could be complicated or even clear, depending upon the viewer. So how do you take that into consideration in some of the way you explain these things, rather than this type of problem is this for this organization, a person or something?
Philippe Guenet You’re right saying is not universal. But if in your organization, it’s a complex problem, and for somebody else is genuinely a clear problem, your organization is probably a long way behind. And and in that case, rather than trying to solve it yourself, that’s where the use of consultants is actually useful. Training consultants and so on. And you need to focus on upscaling as well as bringing solutions quickly in via externals that have that knowledge. But most of the time, what we got is some people that think they have a complicated problem for analysis, when actually it’s a complex problem. Or sometimes it’s, you know, it’s a compound problem. So, for instance, you know, DevOps isn’t is a fantastic one, a DevOps pipeline. Yeah, we’ve established what Devil’s pipeline is about when we know the tools you tend to need, we know how it should work. But DevOps adoption is another matter. And it’s not because DevOps pipeline is is established, probably complicated, that the adoption is complicated as well. And the adoption and the human elements are always very, very often in the complex domain. Because there’s so many multifaceted elements of them working, or people working in a certain way that it is so contextual to your situation.
And finding solutions to that is not rational, no change is emotional. And that’s where you need to figure some enabling constraints, not just solving limiting constraints. So sometimes, you know, you’re going to say, well, we’re going to deploy every two weeks, every sprint, we deploying them. But it’s going to take too long, yes, it’s going to take long, but we’re going to get better at it. And sometimes, that’s what you do. I mean, I’ve even had the situation where nothing would change. And, and what you saying in systemic coaching is that a system is like an 800 pound gorilla doesn’t want to move, it’s not going to shift.
So in that case, the kind of thing you can do is, is create disruption in the system. And what we did is we stopped everybody to work. Overnight, we said, You know what, this release is not going to happen. We’re going to rescue the beat of it that really matters. And for the rest, you know, what? You self organize, we’re going to make the software better. We need to do things better, what do you suggest we do. And the fact that people stop their work, they actually took notice that we meant about quality. And then the engineers took a voice. And because they took a voice, they also took action. And we could have done anything, that was the best thing to do for the system to realize quality mattered, then there’s a lot of other reason why it’s difficult to make it matter. But suddenly, the system realized that and suddenly a momentum was created to achieve that. So in in here, what we did is there was no crisis, we created a crisis, we created chaos, for normal thinking to happen by removing constraints. Now, when norovirus happens, well, you need to take advantage of that you cannot create chaos on top of chaos, otherwise, it can become a bit dangerous. But you know, when something like a virus happen, you have to actually look at what can be positive out of this. And how do we leverage the situation to, to, to develop the positive out of it?
Ted Wallace Yeah, deep. I really liked that insight of in the DevOps problem. DevOps itself is complicated. It’s been done thousands of times before by many, but the getting your IT department to change their way of thinking can be incredibly complex. And that’s why coaches and some of these things are helpful because people are used to working on complicated things. Most of the time, a lot of managers not so much in that complex domain.
Philippe Guenet So the complex is very often about competencies, not necessarily about solutions. And to build the competencies, it’s a mix of training and coaching and all those things. And enabling it. So sometimes the training allows you to build a competency, but enabling it, it’s more about coaching most of the time, so you need to have the different approach deployed there.
Alex Kudinov So I was really interested to see is the the analogy with Maslow’s pyramid. Mm hmm. And, um, what I know about Maslow’s pyramid is that for a lot of people, it’s actually not a full pyramid. A lot of people just don’t get to the top right. And that’s perfectly fine. Um, but what we teach in Agile is that you can do technical stuff you can do process and tools absolutely fantastic. And without leadership, you don’t get anywhere. So um, I’m curious how you’re thinking about this analogy and whether the bottom part can actually lead without the top part.
Philippe Guenet The bottom part can live without the top. Don’t think the top can live without the bottom. And that’s the message I wanted to bring. If If you don’t find a way to connect and engage people remotely during this time, you’re not going to get any of the rest realized. And if you try, if you don’t focus on your team health, and not resilience of the teams, you’re not gonna be able to drive change and flow and all those things. So it’s really the bottom elements are needed to be able to, to execute on the IR level. Another Another thing I often say as well is that and in Agile, you know, we tend to say, Oh, we need to be agile, or do agile, be agile. And very often, you realize that you can be, you know, if you don’t do if you don’t have a decent DevOps, if you can put your software alive every so often, you’re going to batch up, if you batch, you may be working in sprint, but you’re not going to be agile.
Alex Kudinov So you’re not getting any argument from me, they’re absolutely aligned. I think what what’s coming up for me is that your bottom part requires some leadership for its existence, so it’s a little bit little bit disconnect. Because in Maslow’s, I know it goes, it builds up, right. In your example, by an actual requires a piece of off the top, and vice versa.
Philippe Guenet Yeah, I mean, you can have skunk work and stuff like that. But in large organization, it doesn’t tend to happen. And in banks, I’ve seen emails saying if you if you use zoom, it’s a soccer ball offense. So yes, indeed, it’s, it’s, you know, the skunk work could happen. You know, people could start using zoom. But if if they are prevented at that degree, it’s very difficult to to let that happen.