Kumar Dattatrey...: Good evening everyone, welcome to our live stream with our esteem guest, Peter Merrill, where we're going to be talking about leadership as a service, and along with me from Agile Meridian is Mike Jebber and the two of us are going to hopefully share perspectives on what leadership is a services and what DRIs are, directly responsible individuals and how you can use these patterns to really, I don't know about eliminate bureaucracy, but certainly lessen its impact. So without further ado, Peter, maybe a quick introduction, tell us who you are and a little bit about XSCALE and your journey.
Peter Merrill: Okay. Thanks for having me Kumar, it's very kind. So I've been involved with Agile since before it was called Agile. I had a credit in the first XP book and I ran the first Agile game at the very first Agile conference, XP 2000. But for me, I mean, I was never particularly interested in being an Agile anything. I was interested in using this stuff. I was a software developer architect for about three decades or more, and then about 10 years ago, people started paying me more to coach than to deliver things. So they took me away from a keyboard and wouldn't let me get back there. So I did that for about a decade, and then you get to a certain point where you've got enough gray hair that you basically have a choice to either age out altogether or start sharing what you've learned.
So XSCALE became a vehicle for sharing what I've learned and I'm delighted that we've got close to 200 senior [Agileists] worldwide involved in the XSCALE alliance now. You guys being esteemed members of same. So basically what this stuff's about is Agile above the level of a team, but not about scaling, not about frameworks. It's not about how do we sell certificates, it's around how do we generate business throughput? How do we adapt to changing market conditions? So when people talk about business agility, this has become the buzzword of a year and there's a whole bunch of theories, but when you come down to it, it's very simple. It's about adaptation, the same way that the Agile at a team level is about adaptation to change, but to do that, you need to get learning to flow through the organization.
So a lot of what we're going to talk about today is critical elements to make that happen, and they're very simple, just the same way it's just about everything in Agile is very simple, at the same time they are missing from just about every organization. So it's important stuff, even though it's simple and the figure I always bang on about to illustrate that is the number from the state of Agile survey for the last five years about they ask the question, does Agile help your organization respond to change? 95% of respondents, this is the longest running Agile survey in the world. 95% have said, no, it doesn't. So the stuff we're talking about right now is critically important if we're going to be able to get the organizations we work with, they want Agile to be able to succeed and to grow in the VUCA world that we certainly occupy in 2021.
Kumar Dattatrey...: Yeah, that's great. Thank you, Peter.
Mike Jebber: Hello
Kumar Dattatrey...: Mike, you want just a quick introduction?
Mike Jebber: Yeah. Mike Jebber, I'm a partner here at Agile Meridian. I've had the esteemed opportunity to work with Kumar now for several years now and our other partner Jolly who couldn't make it tonight. I've known him for about six or seven years now. Really happy to be here and Pete it's so refreshing, I love your perspective on all of this because that idea, and I'd love to hear more about your thoughts around how do you build that environment. Environments help promote these things. They promote what the outcomes are and they're either they're either adding to or promoting and moving things forward or they're restricting other things.
This concept I've been working in for the last several years about really helping people kind of think about environment, the talent and the environment that the talent is in and being the tenders of the soil, not the corn in the seeds themselves. I'm a Midwesterner so we talk a lot about corn here. But that and your approach and your mindset to this seems like it's so wrapped around that whole concept. It really, really interest me to know more about your thoughts on and your experiences on how you've been able to help those realize those environmental changes and create that adaptable environment so that continuous learning and those other types of talent things can really move forward.
Kumar Dattatrey...: Yeah, that's good. I'm Kumar Dattatreyan, one of the founders at Agile Meridian. I'm also an XSCALE steward on all that really means is that I had the opportunity to learn from Peter, the master here who has brought really so much clarity and I think an evolution of the application of Agile ways of working and thinking to the organization. So how do you really sort of impact business agility or organizational agility? A lot of the patterns and I guess just the patterns within XSCALE, allow you to do that and allow you to create that environment where learning can flow.
To me I think that's the most important thing is to allow learning to flow, because that's what I see and the state of the Agile service that talks about 95% of organizations that don't see the benefit of Agile it's because there's still sort of silos of walls that limits the flow of learning and knowledge between them and I think that's the biggest bottleneck to business agility. So to the topic of this conversation, it's about a couple of patterns they're sort of intertwined together. Leadership as a service and directly responsible individuals. So Peter, what is leadership as a service and why should I care?
Peter Merrill: So leadership as a service is a really simple way for teams to make decisions together without one person dominating any of the particular decisions. It basically balances, to use the Star Trek quote, it bounces the needs of the many against the needs of the few or the one. It's not okay to say that well, just because someone is bringing some expertise to a team that they get to make all of the decisions about what their area of expertise. We are all generalists, we are all team members. We have to be able to share the decision making.
At the same time, it's also not okay to say, well, then the majority rules we'll just vote on everything because then committee thinks sets, the old [Himeline] quote about a committee is a form of life with six or more legs and no brain, when all the decisions compromises and politics rules, well, that's not going to help either. So we need some way to be able to strike this balance. So the patterns that are involved DRIs, directly responsible individuals is one of the patterns in leadership as a service.
So from at least from my point of view, it's not two separate pattern languages, but the reason that we talk about patterns in general, everyone's got theories about how things should work. But what we're really interested in is what's actually worked. We want proof. We want to understand where people have demonstrated benefit in many different places and things are reliable. So that's this Chris Alexander idea of a pattern is a well proven a solution to a commonplace problem in a specific context. So there's no rocket science about it, just calling it a pattern, doesn't make it into magic.
Nevertheless, the patterns we are talking about directly responsible individuals, mission command, we'll talk about the out a little bit more later, balance of powers and decide the decider. So directly responsible individuals is very simple. As far as I know it started at Apple with Jobs. Jobs didn't want anyone in a meeting who didn't actually have a stake in the outcome of the meeting. So his rule was that every meeting had to have an agenda. Every agenda item had to have a single individual who was going to carry responsibility for executing whatever decisions were made about that item. A directly responsible individual, a DRI, and no one was allowed to be at the meeting unless they were a DRI for an agenda item. So that way you generally have smaller meetings, and we'll talk about these detailing metrics maybe a bit later.
But so far, it doesn't sound like anything that would scare anyone where it got a little bit scary at Apple was that Jobs was quite fanatical about throwing anyone out of a meeting if they weren't a DRI and it didn't matter where you were in the organization and what you thought your reason was for being there, and he put quite a lot of people's noses at a joint, and I don't think he was afraid of putting people's noses at a joint.
The next pattern. So far it's simple. I mean, nothing to it really, it just sounds like common sense. The next pattern is where leadership as a service starts to become a way of making decisions. So I think we've all had the experience when we are planning poker, if you've done any of that as part of your estimation work in an Agile team, where you get to some item where the team just can't make up its mind. Three people think it's a three and two people say it's a 13, and there are a couple of people who just sort of flip flop and it doesn't matter how many rounds you do, you're just not getting there as a scrum master, as an iteration manager, whatever you call yourself, or the coach.
So there are two stupid things you can do about that. One stupid thing you can do is to say, "Well, it's just average." Then you're going to get a bad estimate, doesn't matter what it is. I'm not knocking no estimates, but I'm just giving an example of where this protocol is used to balance the powers of protocol. So that's stupid thing. Another stupid thing you can do is you can say, well, let's just vote on majority rules. There's more people who say, it's a three than say it's a 13 so it's a three. It's not, you're not taking everybody's concerns into account.
So what typically happens is after a little bit of hair pulling the scrum master or coach, or whoever will say, "Well, tell you what, this is mainly an item that's about database." So Jill's our database architect. Jill, you tell me how much is this? Then you get an estimate that at least is reasonably well informed even if Jill hasn't necessarily taken everybody else's ideas into account. So the idea with balance of powerless is to say, "Okay, that's pretty good." But if everybody else on the team disagreed with Jill, and if they were unanimous, let's say, Jill is certain, it's a three. Everybody else says it's a 13, then everybody else wins. That's basically it.
So that means Jill has got to influence at least one person in the meeting to disagree with the others, even if they don't agree with her. So she can get one person to say, "Well, maybe it's an eight" and everybody else, it's a 13 then Jill is to make the decision. So this way, everybody has to lead by influence and this is not just a pattern that you use when you're estimating in a delivery team. This is a pattern we can use with boards, with C-suites, with PMOs, any decision. If we have DRIs and there's one person who is responsible for executing that decision, they really care about the decision that gets made. Otherwise, everyone can go, "Oh, we don't really, yeah somebody else will do that."
No. If one person knows they're on the hook, then they're going to be passionate about it. Then the fact that everybody else is going to have to live with what they're going to do in execution means that you've got a conversation that will happen. So far so good?
Kumar Dattatrey...: Yeah. Just one answer and a comment.
Peter Merrill: Yeah, please.
Kumar Dattatrey...: In our experience, Mike and I, we both are serving the same client currently and we've tried to implement DRIs and leadership as a service to varying degrees of success. I don't know, Mike, if you want to sort of talk about that in a minute, but I wanted to bring a different client. So I introduced leadership as a service, DRIs to another organization and this organization rejected it, leaders didn't want to give up control of the decision making authority to DRIs. Like, "Oh no, we can't do that. What do you mean? If this person is the DRI and there isn't unanimous dissent on the decision, then the decision is theirs. No way we can't do that." Before Mike gets into the example of where we think it's sort of working, what is your response to that, Pete?
Peter Merrill: Oh, I think that's a very valid consent. There are many cultures where the manager has to have the final say. I mean, if you think about it sounds a bit odd when you take the word manager out of it and you just say, "Well, the way we're going to make our decisions is there's one person in this room who's going to make all the decisions and the rest of us are just going to try and influence that one person." That sounds really weird. But when you say, "Well, then that's the manager." Well, of course they've got the power and we have to respect the office.
So cultures where you have to respect the office a good way to use this stuff is to say, "Okay, what we are going to do is we're going to take power out of the room while we're coming up with advice for the manager." But the manager still got the final say, they've got the ability to over rule or reject or ignore the advice. Of course they do. But the nice thing about this is that then you don't have political forces dominating getting the manager's ear. There are many cultures. Singapore's a good example where hierarchy dominates from Lee Kuan Yew and down to the boss of the local street sweepers team, and that's just the way things are, and if you try and challenge that, you're not going to get very far, but the same time when you're talking about communication between peers below the level of a particular boss, you can still do this.
Kumar Dattatrey...: Interesting.
Mike Jebber: I think it's interesting too, is finding where you can get some acceptance in your description earlier around the idea of what a pattern is, and it's proof it's evidence of something happening in a specific situation contextually. I think it was interesting Kumar and I experienced this at one of the clients we're at now together, where we had some folks that came in, they had a really daunting task in front of them, very large project. All these different elements had to come together to make this new thing happen and their industry was severely impacted. In fact, their entire delivery model was completely shut down because of COVID, because everything they did in their business was on site with people, live and they didn't have that modality more. In fact, they'd been arguing for what? Five to 10 years, different proponents inside the organization saying, "We should do this. This would be great." Others going, "No, it's not possible. We can't do it."
They overcame that hurdle in two months because they had to, and what they realized was, wow, we can look at things differently. Kumar and I came in shortly after when they had this large project going, when these folks came together, they were not used to gathering together and for a large initiative with all of these different mindsets and they were all leaders in their own right, in their own spaces, in a highly siloed and segregated kind of delivery stream that really handed things off in the old traditional ways. So when they saw with DRIs, I think they were a little bit like this, but they'd just gone through that experience of, we just did something we've been arguing that we could or couldn't, or should or shouldn't do for years and we did it. So let's kind of have an open mind.
It's interesting to me, I wonder what it would've been like and how it would've been received pre COVID, but when we got there they started using it and they just launched on time, their new product, which is a completely remote version of what they used to do online for one of their more critical products, and so far it's going well and they did play catch to do it because they were struggling to get together because of the COVID kind of knockdown that happened. While it wasn't, I don't think executed in the purest form in the beginning, you saw the spirit of it, start to build over time and I think they kind of melded their own way of doing it. They had the leader and they had the person managing the senior stakeholder and then they had the person managing the DRIs, but they really did get into the spirit of it and unfortunately I had to leave that project to move to another one, but I just got notification that they came across the line and it was like, "All right, this is really, really good."
So I'm excited to see how they take that back, because a few of them head organizations that were so big, they started taking those back to their organizations and using it within their subgroups. Two of them found it very, very lightning and enlightening. It literally took loads of time off of their shoulders and back onto their calendars to be able to do this, and they realized the time impact that they had with this as well as the positive outcomes but the time they got back was amazing. They were very, really, really shocked about that.
Peter Merrill: Mike, you've raised a couple of interesting questions in that. The first one would this have worked in a physical context pre COVID? We actually have a neat little example of that. I don't know if [Massa Meide] is on the call or not, but Massa took leadership as a service into [Prodobanko] at the end of 2019. So just before the fertilizer hit the [wellygig] and he took it in at a very senior level, he basically had a group of 13 executive vice presidents of the bank who had never agreed on anything in the previous decade and were really mired in a bureaucratic context that none of them felt they could escape. I guess that's sort of key to bureaucracy is that it locks everybody in.
So he introduced this stuff and he was amazed at the result that these guys were able to work together to get decisions made to that and to cut through the nonsense, and it basically turned what was a seven week engagement forum into a two year contract. Then the fertilizer hit the wellygig and all kinds of things changed. But that's what that is. Anyway, so it does work, and actually we've used this stuff at face to face conferences with people who they've never worked together before they owe each other nothing, and it still works.
So it's not magic, it's just that it's a really neat way to balance the forces. But the other thing that you raise, could this work with a big room full of people? If we had like a PI planning meeting with 150 people in it, and they had to use leadership as a service together, would it work? The answer is no, of course not. This is only going to work for a little team, we've got to descale that room. Of course, most PI planning meetings do have a whole bunch of little meetings, but the structure that they use then becomes the question and this raises a third pattern, and this is a pattern we call decide decider, and it's also incredibly simple.
Basically the idea is if you have a meeting and where there's particular DRI, and they've got a team that are going to help them execute the decision about the item that they're working with, that they take that decision back to their team and they get to choose who the DRIs are in their team for execution of the decision. So this becomes a little bit fractal. Basically the DRI in one meeting is going to get to decide the DRIs in at the next level down.
So there's a beautiful interview Jobs gave to Mossberg. I think the last one he gave him just before he turned up his toes. Jobs, that is not Mossberg, and where he said that, "At the top of Apple, we are just like a startup, and that at every level below, it's just like a startup." They have to own the responsibility for making the decisions about how to go about doing things, and so doing it that way gives you a formula for autonomy. That's usually lacking even in organizations that have gone full on scrum or safe, or Kanban, there's still that idea that, well, we have to get this decision vetted by people above us, and the lovely thing about this idea is that actually with decide the decider, the responsibility to carry the decision is then devolved onto the team the next level down, and no one is going to overrule them. We get into questions about reward and recognition and all of that stuff.
Mike Jebber: That did happen with this group. Two of the groups, two of the DRIs in the main group had very large organizations. One was IT and one was ops, and they took that pattern down. In fact, Kumar suggested that, and it worked very, very well. The IT group actually was kind of, they operated a little bit similarly to that. It wasn't a foreign thing to them. So they were kind of a working example inside where, when the idea was suggested that the gentleman in charge of that spoke up and said, "We do kind of this on some other things, so I can definitely see this working." It was reassuring to the rest of the DRIs that, okay, well, let's try and do this.
I think you're right, I could have seen this working before it would've been interesting to see how fast and how interested they were in jumping in with both feet prior to COVID versus when they had just gone through this big disruption and came out okay, how quickly they were to a new idea in general and how quickly they assimilated that. They really did a nice job given the fact that they all said, "Hey, we don't have a history of doing this well." Right?
Peter Merrill: Yeah.
Mike Jebber: It was interesting to see that carried down and then how that carried through for the rest of the project.
Kumar Dattatrey...: Actually it's in this client organization we're having, I think the experience with what Mike just shared is having an effect on the people that through it, they saw the value in it, and there's a group that I'm starting to work with, and they're already talking about just as a matter of, it makes total sense let's use leadership as a service and DRIs to organize how we get this work done, because it spans many teams across the organization, many people across the organization and the standard, the typical ways of doing, getting this work done in the timeframe that they're trying to get it done won't work. What's really gratifying is they're seeing that this pattern works and they're applying it now on their own. Which it's really, really gratifying.
Mike Jebber: They have that contextual proof that you mentioned, right?
Kumar Dattatrey...: Yeah.
Mike Jebber: Inside their own culture today, inside their own organization, and the level of trust for the opportunity for the outcome is definitely there, you can see it in their enthusiasm around it.
Peter Merrill: Yeah. Right. So one of the interesting things with this stuff is while some of the ideas we're talking about might seem radical in some context, none of them are unusual ideas and individually, they're all well proven. But you start looking at, oh, there must be some culture that actually worked like this for a long period of time. There must be some people who just, they got this, they were not a bureaucratic culture. What exists out there, who's done this apart from Apple, and Apple didn't do all of this. I mean, I think they did decide the decider, I think informally, they did the balance of power stuff, but when it came to how things worked there, they were very secretive. So we can't know that all of this worked exactly like that.
There's some beautiful videos you can find on YouTube of Steve Jobs when he was running next computer, and you can see the way he is running meetings there, and you can see this stuff in action at the same time. Well, yeah, they were all in their best behavior where there was a camera in the room. But where we found some really interesting historical precedence is in first nations peoples in particular, a group called the [Hotnoshoni] who they were a very successful first nations group mainly in the New York State area and parts of Canada for about 800 years. Well, they're still around today, but the stuff that they came up with was a code they called the great law of peace, or just the great peace and anyone who's heard of Hiawatha. There's a poem about Hiawatha has nothing to do with the real historical Hiawatha. But Hiawatha was one of the guys who was responsible for putting this thing together back in the 1300s.
Fundamental to this code is the idea that when you've got the civil council people making decisions, and there's councils at all levels. So this decide the decider thing is baked in. But when they're coming up with a decision for the people who are involved in the society, and we're talking about society of up to like a half a million people for eight centuries, instead of saying, "Well, we're going to get everybody in the room and have like a big parliament or a big room meeting." All of their decision making bodies were small and autonomous, which is to say that a decision made at a higher level, couldn't overrule a decision made at a lower level. They could come up with some constraints on what their responsibilities were, but the idea power would flow from the top didn't apply.
When the decision was made, if one person around the table disagreed with the rest, well, the only way that they could get the disagreement to dominate the rest would be if the rest were not unanimous with the rest of the people at the table were unanimous, well, and there was more to it than that, but that's really where a lot of these ideas have a huge body of well proven success on scales that we've never attempted.
Kumar Dattatrey...: Am I muted? No, I'm not. Peter, I was curious if you could, we don't have to talk about all of these points. You wrote an article recently on LinkedIn, Top 10 Reasons you Should Use Leadership Service Patterns. We can just go through these, the 10th reason, frontline teams are frustrated, disempowered and temporary. What did you mean by that?
Peter Merrill: Well, I think we've all had the experience of being in teams where project oriented organization, rather than product oriented teams are hired to put together to achieve particular outcomes, and then off they go. The idea is the team is there to do the work, and they're not going to make the decisions, they're not going to call it the priorities. They're not motivated to get end to end business throughput to be maximized. They're just basically plumbers, and they're either there to install the plumbing or to stop the toilet overflowing or whatever it is, and then they can go. Thank you very much. Bye-bye now.
If instead, we are using leadership as a service and we think of teens as carrying responsibility, that's well defined for functions of an organization. Well, then we start to have more of a product focus, more of a business throughput focus, and we can involve other patterns, patterns from open book of management or patterns from the Camelot Model to reinforce that. But the main thing is that this gives everybody an ability to express their agency-ness as human beings in getting the work done and it takes the political anti pattern out of the room.
Kumar Dattatrey...: Yeah. So maybe give us a tangible example of an empowered team using leadership as a service pattern so that they're not frustrated disempowered and so on and so forth. What would that look like?
Peter Merrill: So a team that is carrying a responsibility rather than a team that is responsible for executing somebody else's ideas, that team... Well, a concrete example. So I worked with an organized called the Commonwealth Bank of Australia, and we had a project there. I think it was a product called KaChing which wound up being ridiculously successful product.
Mike Jebber: I like the name.
Peter Merrill: Yeah, well, it's a good name for a product. It was the first person to person payments app in Australia, that's basically the way just about old payment happens is people bump their phones together and money will leap from one person's account to another. All of the stuff that people do in the States with checks is just completely bizarre from Australian perspective. We don't even carry cash anymore. I mean, no one I know carries a wallet around, we just use our phones for everything.
So this was the first app for doing that, and it was completely radical at the time. We're talking about a 2012 through 2014 era. So the teams I was involved with there, they were very differently enabled to teams that were working alongside them. From the point of view of the people who were doing the work, they had to be able to share for responsibility for execution, but there was a constant stream of decisions, technical decision, prioritization decisions and so on that were reviewed by these teams on a daily basis using ideas that were not formally leadership as a service, but that was the basis for the culture.
So a lot of the time when you're coming up with concrete examples about empowerment, you wind up taking lessons from the way things worked, rather than saying, "Well, they started with this particular pattern and then they executed per se."
Kumar Dattatrey...: Yeah, that makes sense. I mean, one of my current engagements, it's exactly this, frontline teams frustrated, disempowered and temporary. I don't know about the temporary bit. I think certain teams are temporary, but certainly I can sense the frustration and the disempowerment. You talked early on about the state of Agile survey. These teams are an example of that, right? So Agile not working in fact, there's resistance now. Like, we don't want all this micromanagement with a scrum and then the overhead of these ceremonies, and we just want to go back to the way we worked before, where we deliver something on a quarterly basis and in the intervening time there was really not much visibility into what we're doing. That to me is a symptom of this frustration.
Not that scrum is bad or Agile is bad or anything like that, it's just the way it's being implemented with, let's do Agile, but we're not going to not even intentionally saying, "Oh, we're not going to empower you." It's just what happens. Managers sort of keep the power of making those decisions even though they they're trying to empower their teams in reality and practice is not happening. So how would you encourage these managers, these leaders to use this pattern specifically to shift the conversational, to empower these teams?
Peter Merrill: A manager is successful based on a set of numbers. There's always numbers that they used to measure successful management. So if those numbers are really focused on things that the manager can gain, well, then they're going to gain them. If we expect that various kinds of KPIs are going to be the way we judge the success of a manager, we're always going to wind up with those games going on. Another way to do it is to look at the end to end business group as the number that we're going to use as a basis for rewarding, not just to manage it, but the team members.
So it is impossible for a team to go, "Oh, well, we're going to disempower our manager. We don't like the way they're doing things." They don't have a voice that'll let them do that. So this is something that as coaches, we can do something about it. We can work with HR to say, "Oh, well, why don't we think about rewarding people based on improvements or contributions to business throughput, rather than these artificial little KPIs?" If we reward them on the basis of KPIs, they're always going to gain those things. If everybody is motivated to try and maximize business throughput, then everybody's going to be working to the same end, and then the manager's win is going to depend on empowering their team to get the best decisions made.
What's more, the team will actually stand up and say, "Well, I don't care that you are going red in the face and wearing a big loud tie, and you've got more gray hair or less hair altogether than I do. What you're telling me to do is going to be bad for the top line of this organization or of this business stream, and that's going to be bad for my pocketbook and my kid's not going to get his bicycle this Christmas." Or we're not going to make our mortgage payment or whatever it is. So I'm willing to stand up and tell you, "No, we're not going to do it that way." Even though yes, you seem to be a very powerful and dynamic individual wearing a suit, I can't accept what you're saying.
The manager at the same time is motivated to go, "Okay. My reward depends on the same outcomes that this guy's reward or this girl's reward depends on, and they're willing to come up to my face and say what they're saying, I need to actually listen." If I'm not influenced by what's going on in the team that I'm managing, if I can't listen to them, then I'm not going to see the outcomes that I want to see to get my reward. So that idea of open book management, I would go with something like that rather than saying that leadership as a service is a magic, leadership as a service is a set of enabling patterns. But to be able to make the sorts of outcomes that we want to work, we need the role models to be right and the structure of the organization around the team.
So there's a thing called the Camelot Model that we might talk about a little bit, which is really about how learning flows between teams, and there's a set of things called the deep scaling metrics that let us measure the qualities of the structure of an organization. These are very simple things like, oh, obviously what's the maximum meeting size and the minimum frequency with which meetings occur. What's the latency for letting it flow between one part of the organization, one team and another? How many [inaudible] does it have to go through?
So all learning latency meeting, we can come up with a clever name for these things. The doer decider a distance, what's the distance between the people who are making decisions and the people who are doing the work to execute the decision? Obviously the longer that is the slower learning is going to flow. So the stuff we talked about with autonomy before there are numbers associated with all of these things, and they're typically in a D scale organization, really small numbers. Most of the organizations we work with, however, where we walk in the door, they're usually pretty big numbers.
So just by putting those numbers on the table saying, "Well, we're going to measure the quality of its organization this way, leads managers and executives to certain looking much more critically at the way the organization is structured and rewarded.
Kumar Dattatrey...: That sounds good. So I have one more question on this topic, and I'm going to turn it to Mike. That is, what I'm hearing you say is the pattern may not work just by itself, that you might need some structural changes, you might need some changes in reward models and certainly open book management is a way to provide transparency to the entire organization as to-
Peter Merrill: Let me interrupt for a minute, because I think you've raise something that's critical.
Kumar Dattatrey...: Yes.
Peter Merrill: About that. All patterns, all proven solutions to commonplace problems in particular context, every pattern generates further problems, and we'll talk about a pattern language or a pattern toolkit. It's because we have a set of patterns where we kind of have a closed group. We have a set of patterns that solve the problems generated by the other pattern. The scrum is a good example of that. But the way that patterns are applied, if we're going to avoid framework thinking and one size fits all straight jackets for organizations has to be focused on the existing problems. What problem are we experiencing today? That's where we look for the [inaudible] solve that problem.
Kumar Dattatrey...: That makes sense. The reason I asked is this question, or at least pose the challenge is that I've seen success, we've seen success with just leadership as a service, as a pattern to help start stimulating the conversations around this type of change that we're talking about.
Peter Merrill: Yes.
Kumar Dattatrey...: It doesn't require sort of this, hey, we got to change everything in order to get this pattern to work, the pattern can work on its own and be a catalyst for the types of changes. Of course, like you said, it exposes other problems, then what do you do? That's where things like the Camelot model and descaling metrics and open book management may start to come in to play, or at least the patterns that are called for implementing those words that I just said. But leadership as a service is the beauty is in its simplicity in my view that as a leader, and this is the way I try to explain it to people as a leader, your role is to provide a service to your followers, and by followers, I mean, they're leaders in their own right, but your role is to really decide the decider in that group for particular types of decisions and empower them to make those decisions.
Of course, you can easily disempower them from those decisions by overriding them or overruling them or whatever it may be. So it's a simple pattern, it's maybe hard to implement, especially for people that equate leadership with power and the power to make most decisions. But I've seen the light bulbs turn, so prior engagement with the group. The VP of this team of leaders after four or five months of using these patterns, there was a decision that needed to be made and he started to make the decision and I happened to be in the meeting and he looked at me and he says, "Oh yes, yes, yes, it's not my decision to make." He pointed to the person whose decision it was to make, the DRI and where should we go? What's the decision here? That was a beautiful thing. So I don't know if viewers maybe had that impression as well, that's why I wanted to call it out.
Peter Merrill: Well, so that's where you can then lead into getting the balance of power as pattern to become prominent, because you do want the rest of the team to start thinking, we don't just have an agency when we are a DRI, we have agency when we are working together as a team. We work together, we want the best decision to made. So if we think that Jill, the database architect is right about database most of the time, but when it comes to this particular aspect, there are a whole bunch of implications for user experience. There are a bunch of implications for the middleware or for where we source the data or for the data sites or whatever it is.
If they realize that actually we are able to help better decisions get made. The only time that we want to be overruled by Jill is when we run out of time to make this decision, which might be an hour, it might be a day, it might be a week. This is where decide the decider also will decide, well, what is the timeframe for the decision? But the other thing that you very wisely called out is that to get an organization to take this on to push patterns into an organization would be a really fraught thing to do, there will be a lot of stress that way.
Kumar Dattatrey...: I agree.
Peter Merrill: There's another set of patterns that we call a pool transformation that make it really easy to get this stuff to happen, and in a nutshell, the idea is simply that we use simple techniques like open space to identify the people on the organization that actually really want to get change to happen, and we cherry pick them and we make a little team or a little group or a little stream that is going to experiment with working this new way. Once they've got it working, then we will split of them in two and we'll hold a little open space or similar event to socialize what's happened and the benefits we've got and we'll see who's interested in joining each half.
We basically double the number of people who are working this way and the people who join are learning by immersion rather than instruction. They're learning from people they know and trust rather than coaches and doubling this way. Well, we've used this for some quite large organizations. The World Bank is probably the most successful ane of applying this approach of 50,000 people. Getting change to happen this way is far easier, far less fraught, far cheaper and far more effective because people are learning from each other rather than having someone tell you, you are going to behave in this weird way and observe this constitution and all of these rules.
Kumar Dattatrey...: Mike, you got to talk to the group and certainly to Peter about our experience with our client and what you're doing that is so similar to this approach.
Mike Jebber: Yeah. It's interesting. I even go back to 2015 and I was introduced to someone, we were working with a company who was owned by a venture capital and they had their own people that they supplied for when they acquired somebody, they would come in and have this team of people come in and help them improve processes and things like that, and we had had a contact at that company who said, "Well, we'd like to hear what your proposals are." I wish I would've known about some of this stuff because we eventually got to where you're going, but it took a lot longer to get there because we didn't have the nice, the way to describe it that you've got, and the DRI model and leadership as a service.
We had to use more divergent, convergent thinking with smaller groups of interested parties that span across the organizational chart up and down, not just across this way. It took us a good bit longer, but the one thing I was always surprised by and I still work with members of that company that are in other places now, and they said that, what we heard from you wasn't what we thought we wanted. What we thought we were going to hear from you, but we thought it was what we needed more so than someone to come in and tell us how to improve our efficiency.
It was more about capabilities and building a capability to be able to learn and do other things, and I remember we were using fist of five as a method for this group that was there, there were 11 people in the group and they were talking about one subject that we were speaking on. This was several weeks into the engagement. 10 people decided, kind of went with one thing and one person went like this, and that one person was probably the lowest person on that org chart. She didn't get three sentences into what she was going to say and the whole rest of the group with those, oh, and they all switched their votes. That was their aha moment, and they all said, "We would have totally gone in this other direction if it wasn't for the fact that we had this one person." This is not a very knowledgeable person, but not a very up outspoken person.
Just giving that idea to us, we totally went in another direction. We're like, "Okay, we're in." Then it was like, and that was it, they got it. But that was multiple weeks in and then Kumar and I had a chance with the current client were in and he introduced DRIs right away, and it was like, we got that result a whole lot faster because we were able to explain it in a way that made a lot more sense, and they could apply faster without as many iterations or repetitions that we went through of examples, and we were all co-located. So we were on site but it still took longer that way and get what they were looking for. They got the capability and they started doing what you mentioned. We would get other interested parties and break that out into the groups, they would go out and formulate and bring people in.
But yeah, it was enlightening to me to see how quickly someone could get the aha around the benefit and how much faster was that they were willing to, in some cases, give up a little bit of position power for better outcomes, and in some cases feel more comfortable in speaking up in a group where they're not with their peers, they're with people that normally would be telling them what to do. Now they're giving the group the information of what they thought they should do and having an impact, and I was really amazed how effectively that worked.
Peter Merrill: A lot of the time the trick is you've got groups that are learning things that are valuable to each other, and one person who's sort of floating above those groups might be an effective conduit for transmitting learning, might go, well, that's the manager, we really have to give them the power because they know better, they're the only person with oversight over this group of groups and if we don't give them a privilege, might not be architect or analyst or something else or a coach. But if we don't give them that much power, then we are going to wind up with misalignment between the different parties. But there is a really pattern in Camelot that we've had a lot of success with. This is an old pattern. I mean, this has been used in lean since the 1960s and it's called Quality Circles.
Where the idea is that people with similar roles in different groups, let's say the analysts or the database architects or the user experience experts, they get together on a regular basis before the decision making meetings for their respective groups. So not only are they DRI in the sense of, well, they are, they're going to carry a responsibility for execution, but they're also responsible in the sense that they are informed by the other responsibles who carry similar responsibility in different groups. So that, that way they're able to bring context to decision making that the team by itself just doesn't have. This idea of quality circles is a really good thing to do before retros. If you're doing a tight Agile cadence, if you run all the quality circles before the retros, then every team is able to adapt its decisions for the benefit, not only of its members, but of the team of teams or the group or the stream.
Kumar Dattatrey...: Yeah, that's a good point. I think we need to do another live stream on Camelot and just really deep dive into what the Camelot Model is and how Quality Circles play such a critical role in that. Our viewership is going down, so I wanted to give an opportunity for people to sort of type in their questions or comments in YouTube or Facebook, wherever you are and we will see them here. So please do type your questions in, and as we wait for those to come in, I wanted to just pick another one of these top 10 reasons and probe a little bit. I mean, we've covered a lot of these in our conversation. I don't know that we covered this in enough detail. So the number eight reason is the business left hand doesn't know what its right hand is doing. Can you sort of talk about what you mean by that?
Peter Merrill: So the more levels of hierarchy we have, typically, the easier it is for people to reproduce each other's efforts to reinvent the wheel and to become misaligned. Some of the structural patterns Camelot specifically about we go about dealing with them. I should also to mention people who are going to the XP 2021 conference in June and people who are going to the Paris Business Agility Conference in June, we are running a couple of events called the game without thrones, where you can actually see all of this stuff, not only see it in action, you can actually go and experience it in a workshop format, those are free events. Well, the workshops are free and we'll be running in exhale lines, we'll be running game without thrones. This is all online using [willow] and [millow]. We'll be running that on a regular basis going forward after June, but that's sort of the kickoff for it.
But anyway, the left hand right problem really comes down to how do we get learning to flow laterally, and how do we use hierarchy to limit the number of conversations we have to get a decision made without dominating using command or control. We really have to have, there's a principle in military hierarchies called mission command. It's very distinct from commanding control. It was invented by a Prussian field marshal named Von Mucke back in the 19th century. But mission command basically is about, well, we think of people on the military given a mission, they get to go and execute it.
That's not the way it used to work. It used to be that people would line up opposite each other on a battlefield like chess pieces and shoot each other. Von Mucke thought that was stupid. Most military minds didn't get the memo until the German Blitzkrieg stuff happened in the second World War, and suddenly that changed the way they were organizing most business organizations and business hierarchies that still use command control are still easily overrun by the competition that are using mission command. A lot of the patterns we've been talking about support that paradigm.
Kumar Dattatrey...: So there's a question from the audience. I'm just going to read it out. As a CIO consultant, I find it hard to engage both Agile IT developers and the business owners to engage both sides to build and own a minimum viable product, taking into count the steps to create it and the cost of delay.
Peter Merrill: So there's a lot to unpack there, and if we were to talk about break the first product agility, there are alternatives to the way that question's framed, but let's deal with the question full on in this context. So we've got a bunch of technical stakeholders, the Agile IT depths. We've got a bunch of business stakeholders and they each have different concerns they're carrying, and because they're carrying different concerns and different context, it becomes a power struggle. So there was a principle in the original extreme programming that technical people make technical decisions and business people make business decisions. The idea with XP was we want these people to be in the same team. There was no product owner to keep them apart, and it's actually baked into the manifesto that the technology meet on a daily basis, not once every three months.
So the idea that we would have proxies that keep these people apart, and the idea that we would meet frequently, that was never the intent of Agile. That's something Scrum introduced that the rest of us fought violently back in the day. We lost those war back then, but that's not to say that we still want to keep these people apart. So how do we deal with this? Well, the simplest way to deal with it is to say, "Okay, we're going to think in business terms about how we are going to break up the product into epics." An epic, why do we want to build something whose behavior does have to change? How does that change their behavior, and then what do we have to build to do that. We can get that stuff explicit and use some, BDD about the acceptance criteria.
Then the conversation isn't about, well, why aren't you people doing what we want? It's about, well, let's get into agreement about the acceptance criteria that we have to satisfy to get this outcome, and once we've got that agreement to happen, well, then we're going to go and execute together. Whether some of us are doing marketing and some of us are doing business communications and others are building this others, doing some of the collateral we need to be able to get that to glue together, that's all fine.
But we have a common outcome that we've agreed on. If we have to revisit it, because we've learned something, maybe it's going to blow estimates out of the water. Maybe it's going to blow priorities out of the water. At the moment we've learned something we've going to come back together and we're going to use leadership as a service in our team. Our team involves both business and technology people, whether it's a small smith team or it's a broad scope team. Whether it's an epic level or a feature level or a story level, doesn't matter. What we're going to do is apply this stuff consistently and we're going work in a way that's going to make, we get the best decisions made.
We are not going to respect office in doing that because the outcomes are what matters to us. Now, if people are already using KPIs or RKIs that are distinct and that might not work very well. This comes back to open book.
Kumar Dattatrey...: Yeah. Chris, hopefully that hopefully answered your question at least in part, if you have further questions don't hesitate to reach out and we'll try to get into more of the details behind the question. So for folks that are watching and folks that will be watching and he said, "yes," he's said, Great answer." Awesome. So for folks who are watching live and for folks who will be watching this once it is on YouTube and Facebook, what would you say to folks that want implement leadership as a service sort of stepwise? Is there a recipe for, "Hey, this sounds interesting, what do I do?"
Peter Merrill: So that's a really good question. I would suggest that you start simply as possible with this idea of directly responsible individuals just identifying them on a regular basis and saying, "Okay, well, if you are not a DRI, then why are you in this meeting? What's your purpose here?" If the answer is well, I am here to be informed so that I can make certain that some other people are because they have a stake in the decisions that are being made, then we have to fix the people in the room problem. We need those people in the room. The fact there's a proxy in between, we can start to question some of the structural issues, and we've talked about some patterns for dealing with that. If you want to see a system way of doing that, then that's where the game without thrones and the Camelot Model are relevant.
But in terms of leadership as a service, if we start with DRIs, then the next thing we can worry about is, okay, who's going to decide that DRIs how does decide the decider play in what we do? That's pretty easy to do as well, because usually there is someone who to having the power and they don't mind being the decider of deciders. If you can get them to the point where they're willing to say, "Well, I'm actually going to try this balance of power, this thing, I'm not going to go with it all the time, but I think it's a neat way to get the people in the room to provide each other with leadership. So I don't have to constantly doing that, and I can actually get the benefit of their leadership. They're providing a service to me, oh, well, I can see that much."
Even as long as I can sort of keep my prerogative, I can overrule them if I have to do for various reasons. Most of the time that's relatively easy to do. But the other way to look at it is, well, let's not go and do things for the sake of doing and let's understand what problems we're trying to solve and work backwards from those two solutions, and usually that's the best way to do it. The questions will be, okay, we've got lots of problems. Everything's a problem. How do we prioritize this? That's where we have to get into, how do we identify a landscape of the sort of the change [inaudible] that we need to have happen? How do we prioritize that stuff?
That's where we have to think in terms of theory of constraints. What is the dominant key constraint on the flow of learning through this organization? And that's going to move around. So if we can understand where it is right now, even if it's just a matter of, we're not formal about it, we're just going to go with the opinions of the change participants what change they wants that's fine [inaudible]. Later on we can be more formal about it, but that key constraint, if we go well, that's the priority. If we can fix that, then the key constraint will be something else. Then we can focus on that, and maybe leadership as a service is going to be relevant to solving that key learning constraint, or maybe it will be something else.
That's why the one pattern I always applied, no matter what is the old XP idea of the [Agni] you aren't going to need it, you need it right now don't worry about it right now. Whether we're talking about delivery constraints or business constraints or change and learning constraints, that's always the pattern, and if we apply that consistently, well, then we're not wasting our time.
Kumar Dattatrey...: That's great, Mike.
Mike Jebber: Yeah, I had one more thing and sorry for the echo. I don't know, am getting a little echo there for a little bit. You talked about it's interesting how Agile does a very nice job of it's never the magic elixir, right? That a lot of people think, but it does do a good job of exposing where we are today. It shows us what's really, it forces us to look at what's going on, and you talked about that with the DRI structure, if you're seeing those proxies show up and you're realizing, oh, we need these people that you're representing to be here. A lot of times, I don't know if you've seen this, but I know Kumar and I have seen it a lot. A lot of times that's happening because of there's so much whip in the pipe, there's so much work going on that they've over extended themselves, and they're sending proxies out to keep all the balls in the air, to keep everything going.
How have you approached that in the past where, okay, you've identified that the wrong person's in the room and now you've got to have the crucial conversation, like from XP, the CCFR, have the courage to communicate and give feedback with respect to those folks that should be there, when they're going to say, "I've got too much to do." Your response somehow has to be, well, maybe we're not doing the right things or we have things that we shouldn't be doing at that point. How have you approached that and how have you helped teams to have those conversations with folks because that was going to be very difficult conversations to have.
Peter Merrill: Oh, absolutely. You see this particularly on the business side all the time. The person who really is going to make this decision is Joe Bob the VP of sales, and he's got 1,000 people to worry about. We are just a little delivery team of eight people, Joe Bob's not going to come and visit us. He owns the decision, and the answer is well, "Okay, where's our coach. Let's talk to Jill she coach, she's no longer a DBA." So Jill, the coach you need to go and talk to Joe Bob and explain to him that these decisions have to be made now. He has to pick someone that he's going to make a DRI for these particular decisions, and it's actually going to help him because he's going to have someone who can make his echo if he need to, but more to the point he's going to have someone who's going to get the decisions made and who has actually established trust relationship with another [inaudible] is that Joe probably might not be someone who trusts anyone. As far as he's concerned, everyone's trying to stab him in the back.
That's where actually the problem isn't structural, the problem is the reward model of the organization, and we need to be thinking in terms of open book and leadership as a service, isn't going to solve that problem. Most of the time where I would go with the answer to your question is descaling. If you have a look on the xscalealliance.org site, there's a thing called the descaling manifesto. We talked about descaling metrics before, but really what we're looking for is a way to decompose responsibility across the organization so that every decision belongs to a little team. Kumar, do you have the diagram of the wheeler setup that we are using for-
Kumar Dattatrey...: I can share the screen, the image that you shared. No, it doesn't show camera on. Let me find the image. I'll find the image.
Peter Merrill: People are thinking of [Cassons] and actually that, that image it's like a picture.
Mike Jebber: We try to leave the swords out, right?
Kumar Dattatrey...: Leave the swords at the door.
Peter Merrill: We call the game without the thrones, so we don't want to worry about the Thrones. So anyway, the beautiful thing about the patterns involved there, and there's one pattern we didn't talk about, which has to do with rotating round councils, where the notion is there's quality circles. If we were to think that every quality circle is going to contribute to the level above, they're going to give a representative to level above, then the decisions that are made the level above are going to basically [inaudible] people, members of teams, but they're not representing teams they representing quality circles. That's the heart of Camelot because it gives us an ability to then say, "Oh, well, it's actually really easy to decompose these responsibility when the same people during the decomposition are also the people who are involved in the teams at the next level down."
Obviously there's a limit on how many levels a particular person can be involved with, but it doesn't need to be more than one level above to be able to make this work. Do you have the diagram Kumar, or?
Kumar Dattatrey...: I gave up trying to look for it. It's somewhere on my machine. It's just I've got so many things open I'm afraid that I'm going to lose the live stream if I go try to find it.
Peter Merrill: Okay. Maybe we can-
Mike Jebber: Do ever think Kumar's screen it's got a lot of tabs open. He usually have a lot of tabs going.
Peter Merrill: You had it in your deck, you don't have the deck up?
Kumar Dattatrey...: I don't have the deck, no, and I'm afraid to, I literally have like 20 windows open in Chrome, Chrome is the memory hog in all of that stuff.
Peter Merrill: No worries at all. Actually, can I share a screen? Because I could-
Kumar Dattatrey...: You should be able to, they should be a share button in the bottom of the livestream showing. I'm not sure.
Peter Merrill: Opening PowerPoint, hopefully that might not crash my machine. There we go. Okay. Here we go. If I go share screen.
Mike Jebber: While you're doing that, Pete, it really sounds like this is a true bottom up structure, right? You're really getting that bottom up, feed that bottom up pull from where your work's happening.
Peter Merrill: Well, I wouldn't say it's bottom up, I think it's more a matter of, we want communication to happen across the levels.
Mike Jebber: Right. Okay.
Kumar Dattatrey...: Let me add it to the stream.
Peter Merrill: There we go.
Kumar Dattatrey...: Oh, is this what you wanted me to show? I do have this picture. I didn't know what you were referring to, but yeah. Okay.
Peter Merrill: So basically the idea here is there are nine teams, there are around the outside. Each team is six people and then, so these nine teams divided into three streams and each stream has a particular epic and in the game without Thrones, it's all about building a castle to defend yourself against dragons and white walkers and invading armies. So each stream, one stream for the armies, one stream for the dragons, one stream for the white walkers. Then they have these little quality circles that are typically just groups of three, that seems to be the best number for that, and the quality circles share information across the teams.
Then inside this, we've got these little councils that are the same people as who are on the teams, and we take turns being in councils that are focused on prioritization or simplification or coordination that basically crosscutting concerns of the teams, and then we do this at the next level up. So not to go into any more detail than that, that structure is neat because it gives us kind of a fractal way. I think I've stopped doing the share, I don't know if I have or not. Anyway.
Kumar Dattatrey...: You're still sharing but I just removed it since it was that fractal.
Mike Jebber: We had the infinite mirror going there for a minute.
Peter Merrill: Yeah, that's cool. So anyway, that's a neat structure because we don't need to be doing that for the entire organization. It's simply a way for us to get three teams to coordinate in a stream, that's enough, that's all you need. Or if you've got, let's say three streams of three teams, and the reason for this number three is that's the factor in the Dunbar descaling series. Anyone who's heard of the Dunbar number. Dunbar is actually a series of number, and it's all about powers of three. I interviewed Robin Dunbar, he's professor of evolutionary psychology at Oxford. I interviewed him last year and you can find that interview on YouTube, where we explained it properly.
Most of the stuff you see in Agile frameworks done by numbers, complete rubbish, but it's really about how do we chop things up in such a way that we can decompose responsibility in the way we've been discussing with leadership as a service.
Kumar Dattatrey...: That's great. I will say just from personal experience, running a couple of game without throne sessions. Now, game without throne is that there's the picture that Pete showed. It's a simulation, the three teams in three streams. Could just be three teams in one stream. It's a simulation of how teams can share information, knowledge learning in these, not only in the quality circles, but also the representation that they provide to the prioritization council and the coordination council and so on. The representation that provide to do those various things, and it's not run by a manager or a leader, it's run by the people in rotation to provide those that leadership as a service, to provide the prioritization. It's a beautiful thing.
Peter Merrill: The game is a proof of content.
Kumar Dattatrey...: It is.
Peter Merrill: Pure autonomy and alignment, zero command and control for 60 people, and that actually works. So when it comes to, well, can we do it for 5,000 people? You don't have to, this is purely around how can we keep alignment between autonomous teams at whatever level we need to, to actually get the outcomes?
Kumar Dattatrey...: Yeah, it really is a great example of how to descale an organization and empower people to make decisions, using leadership as a service patterns. So with that, we're at what? An hour and 17 minutes, and I thought I would just share the final few slides here. Of course, this is what Peter was asking me to show and I didn't know, this is what he was asking me to show, and besides the Camelot Model that you talked about, Pete, do you want to talk about some of the other things around the square business agility conference, Agile XP 2022?
Peter Merrill: Yeah. So the Business Agility Conference in Paris in June, this has become an online conference, and so we are running, firstly, I'm talking there about this stuff. Business Agility Conference is a very tightly focused format, I get like 20 minutes to talk. So we're going to basically run an event, a three hour event for them. One week later, XP 2021, we've got a three hour game without thrones there. The descaling metrics we've talked about in other parts of the session, we talked about leadership as a service patterns. The Camelot model, basically there are three patterns there. We've talked about two of them, the quality circles and the rotating councils.
The third pattern is the thing we call BDD treaties, which is really around how do we get working agreements that people can sign up to and which can tray and can then roll back. How do we make certain the way we are working stays aligned. So you see all of those things turn up in this game without Thrones event, and what we're looking at, it's not just a pretty picture. This is a conference tool, not a conferencing tool. It's not a video conferencing tool. It's like virtual real estate. It's a thing called Willow Space, and Willow integrates really neatly with Millow, which is a virtual whiteboard/sandbox.
So the way this works then is that we attach each of these little rooms, each of these little seating positions in the willow chart attaches to a different region of a millow board, and that's where we're building castles and that's where we have Kanban and so on. Willow integrates really neatly with that. So basically think of willow is like Zoom on steroids in the same way that millow is PowerPoint on steroids and you get the right picture.
But from our point of view this is beautiful because this is like virtual office space, and you can actually see all the people who are sitting around having the conversation. We're used to having these square paints and you can sort of see us, one, all, or another. I mean, I could do brady bunch thing and I could sort of, if I'm careful about, I could point at Mike, but I can't sort of, it's a difficult time pointing at Kumar. You actually see everybody's video feed rejected into a little circle, that's a little chair and you can look at each other, you can see who's paying attention to who. It's a really simple way for us to do events like this. So this is not just a pretty picture, actually, you are looking at the play board what we're using in the game without thrones online.
Kumar Dattatrey...: Yeah. That's awesome, and I can see where this could be so useful for team teams that are working on something together. So being able to quickly see where their teammates are and be able to go quickly talk to them and see their faces and chat with them if they're not on the board and so on and so forth, that makes it very, very easy to do.
Peter Merrill: Another thing is it maintains agency. So you actually, you move yourself no one's going to move you to a different room. If you're interested in a room you knock on the door and you can hear the knock and all that sort of stuff. So the user experience is really sweet, but from our point of view [inaudible]. We used to run this with Lego in big conference rooms. We can't do that, and this solves that problem for us.
Kumar Dattatrey...: Yeah. All right. Awesome. Then I wanted to just make you all aware, whoever's still watching, four of you is still hanging in there. Thank you, and for those of you that hopefully will watch this when it's not live. We have this leading with agility course, it incorporates elements of what we just talked about leadership as a service and things like that. It is now also an on demand course. So it's a combination sort of a flipped classroom setting where you watch some lectures, do some assignments, and then you meet with us live to discuss what you learned and more importantly, how you will apply it to the workplace. So this is available on agilemeridian.com, go take a look at it. That brings us to the end of our live stream. Did you have-
Peter Merrill: One more plug.
Kumar Dattatrey...: Yeah.
Peter Merrill: So xscalealliance.org is offering business agility and product agility that are kicking off. Well, I've been running them for years, but we have amongst other people, Kumar will be offering these in August, and we also have a bunch of self surf courses. So if you go to xscalealliance.org, you can find details on all of that stuff.
Kumar Dattatrey...: Right. I'm really looking forward to facilitating that XPA, XSCALE business agility course coming up in August.
Peter Merrill: XPA XSCALE project, which is, I talked about breadth first product agility, which is very different to anything you've seen from like a safe context or lean new X context. So yeah, that all that stuff's happening in August.
Kumar Dattatrey...: All right. Awesome. Any parting thoughts, Mike, Pete, before we sign off.
Mike Jebber: I'm just thankful to have Pete here and to be able to talk to us, and this has been excellent. I hope that the viewers enjoyed it as much as I know I did and I'm looking forward to continuing to utilize DRIs and leadership as a service and find more opportunities to help others learn about this as well.
Peter Merrill: My pleasure, guys. Well, thank you so much for having me, it was really good fun.
Kumar Dattatrey...: That's great. Thank you. Thanks to those of you that stuck it out to the end, the four of you. Chris is still with us. Yay for us four. Thank you for sticking it out and hope you enjoyed this.
Peter Merrill: Everybody offline, you can stop fast forwarding now.
Kumar Dattatrey...: Yeah. There you go. All right. Thanks everyone. Bye.
