Five Tips 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.