 So it's going to be a very interactive workshop. I hope you've had afternoon tea and everything to eat and have all the energy things. So welcome to the Distributed Agile Workshop. I want to run this in a very agile fashion. I was coming up with an agenda for what to cover in this workshop. And there's a huge variety of things that I can cover. And I've had a go at writing out some user stories, very simple ones, to get it started. But I really want you to drive what you really need. And then we'll try and fit in what you want, rather than what I think you want. So the first kind of things that I'll call out these things, and then if you agree that these are the kind of things that everyone needs, then we'll keep that on the to-do list, which has fallen off, to-do list here, and then take it as an agile project. The things towards the bottom may not get done, and we won't get upset. Is there a deal? OK, so we'll cover off. It's going to be a very interactive thing, but I want to cover off some of the basis first, as in the theory, and what I really want to quickly touch on is why distributed agile. So I don't think anyone's like, we don't have to justify why distributed agile, it's just a recap. Then the challenges with distributed agile. So it's all about what are the common challenges of distributed agile that we've seen in organizations and environments that we've worked in. The other thing is designing distributed agile teams. How do we set up teams to be at the optimal level? What do we need to consider for distributed agile teams to comprise of, and all those kind of things? How is it different from co-located teams? What are the kind of things that we need to consider? Is that something that we want to cover today? Not very promising, this. How does distributed agile align with the agile manifesto? So the agile manifesto was written in 2001. And the world's moved on quite a bit since then. This is not your word. I might put it on the flip chart here. And so the world's moved on quite a lot. Does it still matter? Does it still line up? Do we care? So I want to talk about that. And I might suggest that we talk about that first, because the foundation of all the agile values and things like that are still quite relevant. And some of the thinking that I've seen in the industry are that agile manifesto and distributed agile do not align. They're not going together. So we can talk about that. I think we should do that first. Do you agree? Because this is all where it's all underpinned by the agile values, the four values, the value statement. So I'll just transfer this here. Some tips and tricks to create high-performance distributed teams. Is that a double up? Maybe not. Distributed agile exercise. Now this one here, I've devised a game or exercise that takes about 45 minutes to an hour. We've got 90 minutes now. As part of this exercise, what we will do is we will learn by doing. And it's going to be a simulated distributed exercise or project for real. And that's why we split the room in the two. That's offshore on the other side. This is going to be onshore. And we will have all the kind of things that we normally set up in a distributed team, distributed environment, and do it for real. Are you in it? Very good. I was hoping you'd say yes to that, because that's 45 minutes. So I think we will learn more out of that than all of the other theory bits that I'm talking about. I'm really excited about that. And not overselling it or anything. The key takeaway is after that. So we just want to recap and wrap up. Got one black one, blank one. Is there anything else? Sorry? Question is the answer? Yeah? Q&O? The reason I call it Q&O is because I might not have all the answers. I've got lots of opinions. So we'll make it Q&O, right? Like third-party vendors, application, or something else. Yeah? Yes? Yeah. So I'll just look for some stickers here. So what I'll do is I'll create a parking lot as well for all those kind of things that are more involved. And we might get to cover it, but I don't promise that. So it's a bit of an involved topic. So third-party involvement. And it's not really a third-party involvement. It's all around you've got on-shore, off-shore teams, and then you've got an ERP solution that's coming from Oracle, or PeopleSoft, or something like that, right? Is that what you're talking about? Yeah. So no, that's a good one. Anything else? No one's mentioned tooling yet. Chooling is in what tools do we need? I haven't talked about tooling. And I'm from IBM. And I'm glad that you didn't. Because tooling should be an afterthought. Tooling should not be your starting point. If you need tooling, we'll talk about it. And to get distributed agile working properly, 99% of the time, you will need some sort of tooling. You will need continuous immigration, all those kind of things. Those things are given. And those things are the easier lot. It's the easiest of the best. What's more difficult is the cultural changes, the people side of things, the communication side of things. That's more difficult. And that's what I want to focus on here today. Because I think we've had many, many sessions. And you will find them everywhere about distributed agile tools and things like that. So I don't want to really cover that today, unless anyone's going to get upset. It's good. It's very unlike IBM, but it's all good. So any last request before we get started? No worries. It's important. So we've done the introductions kind of thing. So if that's the order in which we want to do that, more or less, everyone happy? There's some tears there. And some here. Do you want to sit down and be relaxed? OK. So we've talked about that. Agile principles align to the manifesto. Now, what I want to do is I'll call out there are 12 principles that are based on the value statements, the four value statements in Agile. Now, based on what you think and what your experiences have been, yell out like, yay! For everyone that I show up here, if you think distributed agile and that principle lines up. And stay quiet if you think that it doesn't line up. And then we'll recap as to what those summaries are. So continuous delivery. Three, two, one. Welcoming changing requirements in distributed agile environments. I asked you, did you have morning tea or afternoon tea? You said yes. It's not showing, right? Delivering working software in a distributed environment frequently, business people and developers working together in distributed environments. Motivated individuals in distributed environments, face-to-face conversations in distributed environments, maintaining a constant face indefinitely. Three, two, one. No? Why not? We'll talk about that. Working software in distributed agile. Technical excellence. Minimizing amount of simplicity. Is that a yes or no? Two more to go. Self-organizing teams in distributed agile. And the last one, continuously inspecting and adapting. Three, two, one. I'll take it as a yes. So the one that we highlighted here was face-to-face. And I think we were not too sure about working together a bit. Any others that we've picked up on? Most of us? Constant face. Wow, OK. Why do you say that? Why would it be a challenge in constant face? Having constant face in distributed agile. Yeah. OK. That's true. That's true. Where distributed agile doesn't just mean on-shore or off-shore, it could mean that someone's working from home, right, in the same city. And you struggle with self-organizing as a team when that's the case. Even on different floors of the same building, that's distributed. And I think lots of organizations are not acknowledging that as a distributed environment situation where teams are not co-located in one floor in one space. And even on one floor, if you're scattered all around, that's distributed. And the difficulties of communication is almost as similar as being into another city. So we need to highlight that. Now, I know these colors don't show because of the lighting or something like that. But the two red ones that we found at IBM, based on our experience, is that business and development teams, they struggle to be together and work together because of being distributed. Because most of the time, your customers in one location, they're not distributed with the development team. And the other one is obviously the face-to-face. The green ones that we've highlighted here are things that are easy to do in distributed agile as well as in co-located, things like welcoming change, things like simplicity, all the kind of things that you want to operate at a sustainable pace and doing the retrospectives and the inspection and adoption. All those bits are easy. All the other bits in blue are still a struggle, still a challenge when it comes to distributed agile. And most of the, I think it's two, no, it's like of the four values, two of them are around people and interactions. It's all around individuals and the interactions over processes and tools and customer collaboration. All of that is around communication with customers, communication with all your fellow team members and things like that. And we don't want to break those rules in distributed agile. So how do we maintain those rules? How do we make sure that we're not breaking those core values that agile has and that has been around since 2001? How do we make sure that we still keep to those values and still do distributed agile? And that's the challenge that I want to talk about today. Now, I just want to just throw this out here. There are situations where we want to go agile when we are already distributed. And there are situations where we want to go distributed while we've got a good, humming, well-oiled machine that's on one side. And then we want to distribute them. Does it make sense? Which of the two does it make sense more to do? It's more sensible. Agile first? Both equally challenging? So if you're doing agile first, and it's working, don't distribute. Is that what you're saying? So that brings the question, why go distributed agile? So I've been part of many organizations. My first distributed agile gig that I had was with Suncorp in Australia, which is the largest insurance company in Australasia. They were like a poster child for agile in banking and finance. And they had everything co-located. Everything was in Brisbane. All their kind of things were happening out of Brisbane, Sydney, Melbourne. But they all co-located in every domain. And then something happened. And this happens to all large or small organizations. There is some pressure to reduce further costs. And you've squeezed the lemon enough. You've done all the agile kind of things, all the lean kind of things, all the kind of things that you could have done to improve in the local environment. Then they look at, oh, yeah, we go off to China or India to make it cheaper for us. And we'll get the best out of both. And that happens with so many organizations. A good question that leads me to my next slide, which is both equally challenging. Like you said, both are doable. But we need to recognize the reasons why we need to do that. So first is you've got an agile team. You've aligned the IT and business. You've embracing change. There is huge transparency. You've already got fast market time and all things like that. Then you go distributed. And the reasons for that is further cost benefits, global footprint. So that's the added kind of thing that you're bringing in here. And the access to the talent pool from a global market. That's why IBM's all over the world. Because we've got reasons for getting global talent pool. And then allow scaling. So if you go distributed, then you scale up. You can't find the same kind of skill sets, especially in smaller cities and places like that, where there's only a finite number of people who can do whatever it is. So you go agile to distributed for that reason. And then the other way around is you've got distributed teams. You've got cost benefits, global footprint, everything. So you're distributed already. None of them are agile. And then you go, OK, now make them agile by making it more adaptable to change, welcoming change kind of things, IT and businesses aligning and things like that. So which of the two will be more difficult now that you see that? Second one. And why is that? Why is the second one more difficult? Yes. Because here the cultural change happens first. In the teams that you have, it happens first. Here you've got to retrospectively apply all the changes in the distributed environment. Because they've all got their ways of working, and they may not align to each other. And you've got to now align them because agile needs one single way of working for everything to be humming along. This is a more difficult scenario. It's not impossible. But that's not the preferred way to go if you're doing a new transformation to be distributed agile. So it's better to go agile team, one location, get it humming, and then distribute. Does it make sense? So moving along, I find a volunteer to move the cards for me. You close the wall. If you look behind you, the manifesto one has been done. So I'll just put this in progress thing here. And then done. Put it in done. So you'll be our scrum master. You've been. So what's the next bit? What's the next? Why distributed agile? We've done that. Yeah, we've done that. What's the other one? No, we haven't done that. Next one? Yes, that's the one in progress now. Challenge with distributed agile teams. Let's talk about what are the most common challenges. And I've looked at so many surveys and things like that. I've got some that are listed from most organizations that have done this and struggling with this and trying to overcome it. We at IBM, we do more distributed agile projects than I'd say anyone else in the world. And the common challenges that we have is around people, communication, culture, and dueling. So it's all of those things. What are some of the other things that you can think of? If you're doing distributed agile or not doing it yet, what's stopping you from doing it? Or what's slowing you down from reaping the benefits of distributed agile? If it's just one thing, what would you call out first? Time zone challenges? Yep. Accountability ownership? Yes. Yes. Dependency across all the teams? Yep. Yep. Yep. Good. Anything else? Culture? Different cultures? You're talking about organizational culture or the culture of the teams? Both. Very good. Yeah. Both of them are very important. Yeah. Any others? Different countries, different regulations? Yep. Yep. I wouldn't put that as a number one or top 10. It's going to be lower. Yeah. So those are lining up with what I've got here. The culture comes first. The other one is architecture and design for distributed development. And I'm not talking about tooling and things like that. I'm talking about solutioning architecture, as in how do you slice and dice work for it to be distributed and delivered by distributed teams? What happens? Quite a lot. The architects and everything else that needs to be done upfront in traditional projects are still done the way it was when things were not distributed and not air job. And then we say, oh, yeah, yeah, we'll dish it out to our distributed teams and expect magic to happen. So that is something that's quite difficult to get right upfront. And I'm not talking about big design documents upfront doing slicing and dicing properly. I'm just talking about just-in-time architecture, but also aligning with distributed teams' way of working. Communication needs extra focus. So how many times more? I have no idea. But it needs more focus as in what you used to have as in face-to-face communication, also with the same sort of cultural background team members. Communication is much more easier. And when you've got different cultures that you're talking to, the challenges become exponentially more difficult because the humor is different, the words mean different things, body language is different, and all those kind of things. And then added on top of that, you can't see each other. So it needs a lot more effort. And people don't cost them in when you're costing distributed agile solutions and co-located solutions. You don't normally say, oh, yeah, it's going to be taking three times as long to communicate. It has to be considered. So time zone difference. That was the first one that came up. Now, going north-south rather than east-west is the rule of thumb. So and some countries are fortunate, some are not. I come from New Zealand. We are very unfortunate when it comes to time zone because no one's in our time zone in New Zealand. It's like it's just us. And we are not in line with any other country when it comes to the same time zone. It's quite unfortunate. But we get to celebrate New Year's first. Continuous integration becomes more critical. So this is where everything has to be on the same pipeline. Otherwise, you're working in silos and it's like a black box everywhere. So you don't want that. Tooling. I don't want to talk about tooling. We all know that. So those are the kind of things that are challenges. I mean, I'm glad that we're on the same page. There are no other challenges that you've faced that I haven't got here. That's like a number one, right? But there are many more than this here. That's good. So what I want to talk about is, when it comes to culture, why I was saying humor does not always translate, it's very important to keep this in mind when you're working with different cultures. I'm not talking about organizational cultures. I'm talking about cultures of people. So I'll give you an example at SunCorp when we first started doing this and the first team that we went distributed with, I was working at SunCorp at the time, I was, I think it was 2008 or 2009. We started working with China and we, as a gesture of goodwill, what we said was, we'll send them some gifts, right? So we are based in Australia and we'll send China some gifts for the first kickoff iteration and everyone's going to get a SunCorp hat, which has got a green hat with a cap. I just want to quickly run through the guiding principles of how to have a, how to design a distributed agile team or environment based on some of the experiences that we've had at IBM dealing with other clients as well. So this is a collection of things that I've seen from multiple organizations all around the world and having worked in so many of them. These are the kind of core things that I want to highlight quickly and then we'll go into the exercise because it's going to take quite a long time to get the exercise, but I want to use this as a foundation for our exercise as well as a learning thing, right? So the kind of thing that we want to talk about is the first thing is agile governance. The funding model has to be conducive to the way of working. So there has to be a single way of working across all locations, right? Just because customers on one side and the development team, maybe some of them might be near the customer and there is another team offshore or somewhere else. The way of working should be same in both of the teams, not different because they are out of sight or out of reach or things like that. So, and this will create a us and them. This will create a culture where there's always a feeling of poor cousin, poor second cousin, when you don't have the same way of working across all locations, right? So that's one of our call out. The other one is scaling teams. When you're building teams, one of the challenges that you called out earlier was there's going to be a lot of time for handovers and it's going to be a slower process. The constant pace may not be there, right? In distributed agile. So what we're saying is you have long-lived teams and have end-to-end capability within each location, right? So avoid the situation where all your BA's, I'll show you this one. I'll skip through this. Yeah, this one. So avoid the situation where all your analysis is happening in Sydney, all your dev works in Melbourne and then QA in Pune. This is so common. And that's how IBM was structured not too long ago, up to not too long ago. And we now have started changing things to have end-to-end delivery teams at each location. All developers, BA's, architects, everything that we need to deliver any capability, those are pulled by locations and that location should be not needing to reach out to other locations for testing or architecture help or things like that. Sometimes it's not avoidable, it's not ideal. Sorry, it's not always possible, but that's what you aim for, right? So, and if that's the case, what you do is you empower these people to reach out to other people. You sort of create a distributed team, but within the teams they're all co-located. And that's the easiest way to fix the problems that we highlighted earlier with face-to-face interactions. You still are distributed in the whole program, but the work that you're doing for a unit or for a particular capability, you're still located together. You're still, yeah. Yes, yes. So you're not splitting by function, you're splitting by features, yeah, that's cool. So that's what I want to show, I'll just go back. Yeah, this one here. So now when that happens and you've got long-lived teams, you can just blow a team away and then pull them together. Sorry, that's the opposite. You don't normally do that. You sort of, as soon as they've finished a delivery or something like that, you don't just disperse them and say, okay, you're going to do other things. Keep that unit together and let them pull work because they are a well-functioning team and you don't want to throw away all of that effort that's going into making that team a well-oiled machine. And then what happens is that you've got to have a push, move from a push-to-pull culture. They're pulling work in their teams rather than being pushed to do work. So all of that will allow you to have scalability and things like that. And they will have more accountability of delivering value to the customer because they're pulling in work. They know what it's all about. Then they will have more accountability just automatically. Two-way flow with distributed teams. What I've seen in, especially with China and India is that they'll look for instructions. And wait for instructions to, oh yeah, this is how you're going to innovate. This is how you're going to make things better. This is what we found in your way of working. So you don't want that to be one-way because if most of the work is being done in China and India, then there's possibility, there's no reason why most of the innovation should not be coming out of India and China. Yet, when you read all the magazines, everything else, websites, everything, all the innovations come from the other side of the world. Yet all of the work, the 80% of the work in those situations are being done out of India and China. It's because of the culture. It's because of why it's waiting for instructions to be told what to do. And if you change that around, I think it's not going to be long before it can be two-way. And I'm making a huge generalization here. I'm not saying everyone's doing that. This is the trend that I'm seeing. Do you agree, disagree? So when I first started working with China through SunCorp, the first thing as a coach I did was challenge them to challenge others. In a meeting, first thing you do is, okay, in this meeting, if you're not challenging anybody, we're going to have a mark against you. And it was dictatorship, but that's how we train people to challenge others, even their customers. And that's the kind of thing that we want to do more, to just change the way that we behave, the mindset and the culture. It doesn't come naturally. We've got to train to become like that. Minimizing handoffs and end-to-end capabilities. Now, innovation, I've covered that, where it should be from all locations. It's not fair to just get innovation from one direction. Not only it's unfair, there's a lot of loss of ideas. We don't feel brave enough to call out all the good ideas that we have. And that's what we want to change when we partner with somebody. We also partner to innovate together. We also partner, not just to deliver code, we partner to innovate together. That's what we want to do in a distributed situation. This is the core. Passionate people who are empowered, not just taking instructions. They are willing to do everything. Leave your titles on the door. And the reason I'm focusing more on this here today is because of the environment. And in India, people are always hiding behind their title. And that's the way that we operate, right? So that's the way that everyone here and in China, and in other Asian countries operate. Not that it's not the case in the Western world, it's still the same, but not so much. So in agile teams, we wanna leave the titles on the door and that's more difficult to do here than in any other Western country. We need to learn to do that. The other one is T-shaped skills, broader and deeper. I won't go into that. So, and the crux of all this, it starts from the individuals in the teams that have got to have the courage to challenge others and to be challenged by others. And that's what would create that innovation. That will create that kind of individual that you need in distributed HR teams. Any questions around this model? All good? Everyone sleeping? Yeah? One awake? Yes, yes. I wanna give you a story and this is what happened when I first started working with my Asian counterparts. Every time we have a workshop, a kickoff meeting for a project or anything like that, especially in China, when there's a team leader in the table, there's no one gonna, there's gonna be no one else talking except for the team leader, right? Because it looks bad on the team leader if someone else is asking the intelligent question, right? So it took me a while to figure that out. And after we figured it out, what I asked the team leader to do is not turn up in the meeting, right? Because you don't know, the team leader is not a doer. All the other people are the ones that are really doing the work. So why is the team leader even turning up because he wants to keep an eye on everything, right? So then we've got a scrum master, we've got all complete transparency, everything is open. So why do we need that guy to be there to just check on people? So we got rid of the team leader from those meetings and then all of a sudden, that dynamic change. That's just one way of overcoming this problem. I don't know if that answers your question or was that the kind of challenge that you were talking about? Yeah, yeah. Yes, and there are many more, I'll take it offline, we'll talk later, yeah? Yeah, making sure that you can ask the questions and decide, is it gonna be this class here or is it gonna be something else that I need to implement to get the solution working, right? So having the courage to trial two things in parallel rather than just one and then say, oh yeah, it's working, it's good. If you're not sure, call it out saying, oh it might be, there may be two options and I wanna try a set-base option. Try both of them, if it works, we'll pick one. In a traditional environment, that will be seen as a really bad thing. But if they're empowered to do that and encouraged to do that, all good, yeah? That kind of thing. Anyway, I really wanna rush through and get to the game. This is the kind of thing that illustrates how things should be set up. This is the more traditional way, lots of hand-off and siloed teams and things like that. And then you move towards the end-to-end capable team where there will be some niche skills that will not be in that end-to-end capable team. There can be as a service teams that people use and then deliver what happens then is there's more accountability, less coordination, more transparency as to who's owning the problem and then reduce cycle time. And that can happen in distributed teams. So when you're talking about, oh, the lag time is gonna be greater, this is what you do to fix that problem. So how do we set up, I'll cover that. Now, what are we doing with time? What time does this session finish? 5.15, let's get into it. So, how are we doing with the backlog? Yeah, it's falling apart. So we go in the distributed agile. There's one that we haven't covered off. That's what we just covered. All the kind of things that you need to consider. So those are the guiding principles. As in, yes. Yeah. Yes. And that's what I'm saying is you avoid. That's what I'm saying you avoid. Yeah. Yes. Yeah. Yeah. Yeah. And that's reality, right? So most of us, even at IBM and many other organizations, that's how we still distribute. And we try and use tools to overcome some of the challenges that we have. It doesn't quite cut it as well as this model would. This model will not be possible overnight. It takes a long time to get to that model. That should be your aim over time. That's right. And that's why I highlighted the way of working should be conducive to the funding model, right? So it should be conducive to the agile way of working. If people want to do agile, all those principles, face to face, working closer to the business, all those kind of things, how do you make that happen? Go this way. Otherwise it's gonna be a challenge. Let's get to that. Yes. Yeah. I don't think this is a problem. I wanna park that one. Because that's, I've got a whole 10 or 15 minute lecture on how to overcome that problem. Because that's a very common one that I have with clients that I work with. And it's not an easy one to solve. And I can't give you a 30 second answer now. I really wanna take it offline, and we can talk about it. And people who are interested, maybe after the session, we'll have a group session outside to do that. It's a very valid question. I don't wanna compromise on the quality of the answer by compressing it, yeah? Very good question though. We'll get to the next thing. Are we ready for the game? Yeah? So, what we wanna do is work in teams. And I'd like to just for starters, we'll do a little bit of release planning using the distributed agile methods. We'll create a miniature model of a farm. Right? So, sorry? No? Is that me? Wow. Okay. So, I'm blushing. Release planning. We'll do that for 15 minutes. And then we'll do three sprints. And hopefully we'll get it done before quarter past. Is it 530 or 515? 515, yeah. And then reviews and retrospectives and those kind of normal things, but very, very speedy manner, right? And we'll try and work with teams. What I wanna do now is we will create a on-shore team and off-shore team. That's off-shore by the way. That's why we split the room. The room is in two half. This is on-shore. Off-shore is gonna be in the other half of this room. Now, what we wanna do is create red team and a black team. Now, I'll give you the reasons for creating the miniature farm. This is the farm. So the farm is needed. And this is because I wanna invest in a farm and I'll have a caretaker, farmer and his wife looking after the farm up to the point that I retire. And it's in South India. It's a rural area where I wanna just spend the rest of my life after I've retired. To purchase that block of land which has nothing now, I've seen the land. There's nothing there. I need to talk to my bank manager to get a loan to purchase that farm. At the moment, if I show him the photo of the farm, it's got coconut trees, nothing else. So what we wanna do is show him exactly what the farm's gonna look like as a miniature model. And that's gonna increase the possibility of my getting the loan. That's the vision. That's why we're doing this project. You guys, you all work for farms like us. I'm coming to you because you do agile work. I've heard that you do really good agile work and you do incremental deliveries and things like that. So you guys create miniature models for farms every day, right? So this is what you do for a living. Have I come to the right place? Very good, yeah. So the kind of things that I want on this farm are a farmer and his wife, a sheepdog, cake roll, barn, house, veggie patch, all those kind of things that you normally see in a farm. In terms of business value, I think how important they are, I've just scaled them like that. We won't do story pointing because for the exercise, for distributed agile, I don't think story pointing has a lot of value in this exercise, right? But realities don't avoid story pointing or estimation and involve everybody who are doing the work to do the estimation. Don't ignore the offshore team, right? Get them to estimate. So that's the vision. Everyone clear on the vision? How many iterations or five minutes would you need? With these many people, you deliver 16 items. 16 items, 60 people, five minutes, one iteration and you'll get it done, yeah? Yes? No? Why not? Okay, let's do some release planning. So our product, the agenda for release planning would be product owner who's me would present the vision and the goal. Product owner milestone, right? Quarter past five is my appointment. Straight after this quarter past five, I go to the bank manager. So quarter past five, I've got to have the model here. Product owner presents the first cut. You've seen that. Team asks questions to understand the stories. You're gonna ask me some questions around this kind of thing. Before you deliver by quarter past five, we won't do estimates for this one. Then we'll do a release plan and very important, we'll do a risk analysis. What's stopping you from delivering this by quarter past five? Anything? This is happening for real, guys. What material do you use? Okay, so your technology stack is gonna be this kind of thing. Play dough, clay, molding clay, and things like that. And anything else in this room, that's yours. That you don't have to ask for permission for, right? So it's like anything else, be innovative. It's gonna be a very small, it's gonna be the farms. This is the production environment. I will make it here. This is the production environment where the farm's gonna go at the end. And that's the area the farm's gonna be in. That's not a development environment. We won't do any development in production. So think about releases, migration, things like that, right? When you do this. So what are the risks? You've got the technology stack. You happy? Yes, you've got the production environment. You happy? Any other risk? No, you're oozing with confidence, right? Skills, farms are us. The reason I came to you, because you do this for a living, doesn't matter. The success criteria for this is, the bank manager should go, wow, I'm gonna give you whatever you ask for, right? So you're gonna build a product that's gonna make the bank manager go, wow, okay? So here's the success sliders. Have you seen this before? Have you seen this for any project? It's a good tool to, at the start of any project, to lay out the kind of things that are like levers, the iron triangle in the traditional method, which of those three are flexible? This is a similar thing, where these things are set by the product owner and communicated to everybody in the team before the team starts work. Because you know then, if push comes to shove later, which of these levers are flexible and which are not from a product owner's or the sponsor's point of view? And what I'm saying here is, things on this side are highly flexible, like scope, highly flexible. Mids budget, everything's free here. Materials are free, your efforts free, so I put it in the middle, right? Time fixed, quarter past five is my appointment. I don't wanna miss that. Quality, yeah, it's up to really us to convince each other of the quality. Like a sheepdog should look like a sheepdog, not like a cow or something like that. And the scarecrow should not look like the farmer's wife. Ads value, not so flexible. Everything that you do should be valuable. And then satisfies team, we wanna have fun, right? How many sessions have you been to today? Four, this is your fifth one. Have you had fun in the four sessions before this? Be honest. You wanna have more fun here now? Yes, we'll have fun, right? So that's why I've got this slide. It's not so flexible. It's not negotiable. We will have fun, okay? So you know the success criteria. Now, I would have normally done a risk chart here, but in the interest of time, I'm gonna avoid it. What the risk chart would do? This is a virtual risk chart. This way, impact. This way, likelihood, right? High, low, high, low. And then you put stickies here as to what you call out. So for example, skill set, time, technologies check, all those kind of things. You just put it up here so that everyone is on the same page in terms of risk. Before we start, get the product owner, all the stakeholders, everybody to go through this and mitigate those before you start. Don't just file it in Excel, in Wikipedia or wherever. Don't just file it. It's not for a checkbox reason. Make it visible, radically visible. If you've got distributed teams, again, get them to replicate the same thing on their wall. Not in SharePoint. The reason I'm saying not in SharePoint is because no one's gonna click and click and click three times to get to the risk. It's just for project managers that this is more for the team and the product owners. So make it radically visible everywhere. That's why you use a big visual chart. That's how you get distributed teams to operate in tandem. You replicate everything on both sides. You have a proxy scrum master everywhere. So everywhere you're gonna do this, you have that physical chart. Don't rely on tools because it's hidden. You can't rely on tools to make it radically visible. It's just a backup. Tooling is just a backup. Anyone disagree? Agree? Yes. That's right. You picked it up quite well. I shouldn't have used the word proxy. I was talking about proxy product owners, but scrum master should be the ones on the same floor with the same team. Good point. So it's normally a challenge with the product owners that you have a proxy product owner. So let's get started with the sprint planning. Now, what I wanna do is get teams organized first and we'll send some people offshore. No visa required. And then try and do this project. So I'll be wearing two hats. I'll have Evan to help me out with some of the facilitation. And I also have Rajat here who also helped us with some of the technology challenges that we have in future sprints. No. So in the first scenario, what we wanna do is you see how we've got some red and black items, right? What I wanna do is create two teams and those are like feature driven teams. One is a red feature team. The other one is, I think, if you divide like that, one, two, so black and red, right? So you guys here, three tables, you are the red team. You are the black team, right? So red things go to here, black things go there, right? Now, if you wanna just, so it's half and half, I'm guessing. Product owner, I'm wearing the hat of the product owner. I'll be onshore, I'll be in this room. In your teams, now you don't operate in silos. This is one team, that's one team, right? Now, each team, you identify four BAs, one scrum master and two QA people. Rest of you guys are developers. So four BAs in these three tables, four BAs not in each table, four amongst your red team or black team, yeah? Gotta move quickly, self-organized. And the rest are BAs. Now, oh, sorry, developers, right? So the black team, if you can write, I know I said leave your titles on the door, but I'm breaking the rule myself first. If you can write your role and just put it up here. So if you're a BA, just discuss amongst yourselves. Convince others that you are a good BA if you wanna be a BA or a tester. Normally, if you are a BA or you've done BA work in the past, don't be a BA. If you're a developer, become a BA today, right? So it's gonna be more fun. And then, same with you guys. You're at the red team, so I'll give you red stickies to somewhere to write your, some titles should take no more than one minute to decide what you wanna be. So four BAs, if you just raise your hands. One, two, three, three, one more BA, four. Yeah, yeah, just write BA and put your sticky on here. Two QA people. Yeah, two QA people. One QA here, two QA people. One more QA. Two, just write QA, right? Yeah, okay, very good. So all the other people, oh yeah, one more scrum master. This is the bravest guy here or girl here. One scrum master here, one scrum master there. Come on, be brave. One scrum master, another one there somewhere. I can't read, you need markers? Yeah, someone took it away. Have you got black markers? That's okay, that's fine. So now what we will do is can I request all the developers from both teams to say goodbye, go offshore, no visa required and work in pods like you may have one pod for one team and another pod for another team. So red and black, two dev teams in that room. That's offshore, oh really. The first one is, how guys offshore? Can't hear them, offshore guys, how are you? Good, good, here's the team. Just giving you evidence that they're all here, all right? Okay, let's get started. Farmer and the wife, the farmer and the wife are the two of the most important elements on the farm. The farmer has to be standing upright with two legs separated, two arms, two legs. My husband, this is the last time I've been standing in front of the laptop always. Can you hear me guys? The farmer and the wife have to be standing upright unsupported, holding hands, right? So they're sitting upright. Okay. The wife is the prettier of the two. Farmer is the ugly one. Farmer is taller than the wife. The wife has got red lips, long hair, glowing eyes. That's it. It's very important that the farmer's wife has to be pretty. You can see the farmer's wife in production without the farmer, but never ever farmer without the wife. The farmer's going to get really upset. Okay. So that's how this one is from after. Farmer's wife is very fat, and farmer should not lose his wife, otherwise he will get angry. That's what he said. And farmer's wife has got red lips and long hair. These are the requirements, I guess. I think we can just... The sheep dog has got two legs, one body, one tail, one head, black or brown. The scarecrow is really scary. It's got 10 pointy fingers, getting upright like that with a pointed head, fuzzy hair. Really scary-looking scarecrow, taller than the farmer. I remember this acceptance criteria. When you deliver the stuff, I want it to be like that. So please, kept everything. So, barn to store high grains. This barn has got an A-frame roof. A-frame roof with four poles. No walls, just four poles with A-frame roof. Simple structure. Now, we will get to the hay belts shortly. But what I want is, hay belts, if they are stacked on each other, five high, it should fit into the barn. So barn, any questions? You're not... Okay, A-frame roof, four poles, high enough for five square hay belts, which will come later to be inside the barn. No walls. Farmhouse for the farmer's family. This farmer is starting out new. He's not so rich. So, what I want him to do is, oh, sorry, what the house should have is just three walls, no front wall, no frontage, no windows, no doors, nothing. It's just like an open, but three walls and an A-frame roof. The house has to be big enough for the farmer and the wife to fit in. No rooms, no, it's just a hall. So it's not a fancy house. A-frame roof with three walls. Large enough for the farmer and the wife. Scrum master is the best fit. Veggie patch, these farmers are vegetarians and they need vegetation. So, what I'm looking for are three blobs of cabbages, green, three blobs of spring onions with white, spring onions with white bulbs and three green shoots from each and orange carrots with green leaves, three of them. So everything's three by three. Carrots, three of them with green shoots. Spring onions, white bulbs with green shoots, three shoots in each and then three blobs of cabbages. They don't have to be too detailed, it's just a representation. Now tractor, tractor is very primitive. No air conditioning, no wind down windows, not even a steering wheel. Just a square blob with two wheels in the front and two wheels at the back. The two rear wheels are larger than the two front wheels. Not rotating, so it's just a representation. So those are the tractor. All the wheels of the same color, the body of the tractor has to be of different color to the wheels. Guys offshore, you getting all this? I don't know, this is typical, isn't it? Windmill for milling grain. Windmill is the tallest structure on the farm. So windmill is the tallest structure on the farm where it will have three cells rotating. I will rotate them, it should rotate manually. So three cells with a taller structure on the farm. Windmill. From master, you doing BA wood. One mill windmill, it is the tallest structure on the farm. Now square hay bales, yeah? No, no, no, no, it's just a looking thing. So square hay bales, cubes of squares of hay bales, brown and it's just dry grass. So, and it's as high as the farmer's knees, okay? Hay barrack. Yes. So hay barrack, hay barrack is really complex. Flat roof, four poles, so four poles, but the roof has to be manually going up and down depending on the level of hay grain or whatever. So four poles, flat roof, roof has to be adjusted up and down manually, but it's a simple structure. You didn't get it? Your BA's are happy here. They will tell you, okay? No walls, fence, fence is for livestock, protecting livestock. Now four rails going each way, no gates, enclosed with four poles. No, no, it's not for the whole thing, it's just a pen in the middle, inside the farm. So it's only a small one, but not enclosing the whole farm. It's only like a, as big as the house, maybe. Four poles, two rails going each way, no gates, it's enclosed. No, it's on its own standalone fence for livestock, yeah? Duck pond with two ducks. Think of rubber ducks, yellow rubber ducks, with blue water, you can have anything blue and have ducks on it just swimming in. So you don't see the feet, but you see the beaks and they have to be orange. Did you get that? Two ducks. Farm pickup truck, similar to the tractor, but the trucks got a tray at the back for carrying stuff around the farm. So it's got the four wheels of the same size though. The tractor has got the wheels at the rear that are larger, but this truck has got the same wheels for size everywhere and it's got a tray at the back. So large trees for the wife to sit under and relax. So it's very important, it should be leafy, leaf don't have to be detailed, it's just a blob with a brown stem. From master, you probably want to put this in the yard. So two more to go. Which one? Number, okay, I'll find it later. No, no, no. Stool, stool is as high as the farmer's knees. Round top tripod, yeah? This is for using when he's milking the cow. Stool, round top, and the last one is a bucket, a pail. Two of them handle with a hollow thing that you could put milk in. Simple buckets, two of them. Again, as high as the farmer's knees. Those are the requirements. That's it, that's it. No color, we are very flexible with that. So if this is it, now if we go look at the backlog, what's the strum master doing? So if you look at the backlog now, for the first iteration, if there's nothing in production, I won't get upset. Second iteration onwards, I want something in production. BAs, what you need to do is now give the requirements to the development team. Our iteration starts in one minute when we get the dev environment sorted. So BAs, you can take the requirements. Now, just before we do that, one more thing, there's no travel budget, no travel budget, and no swapping of teams. So red team do the red stuff, black team does the black stuff. Do you remember what the black and red things are? Okay, I'll show you. So all the living things are black. Scarecrow is a living thing, okay? So all the living things are black. Red are all infrastructure kind of things. Okay, so guys, there's no travel budget. So you can hand over the specs to the developers from the door and then just stay here. So your development environments, so you got five minutes, your iteration starts now, five minutes, black team, red team, two teams, right? And your specs are coming. Your specs are coming, timer. The session is starting at 5.30 in the evening. Yeah, yeah, it's five minutes to iteration. Yeah, yeah, yeah, great. So your iteration has started, so your time has started, here's the timer. So we don't want the iteration's over. Round time, huh? We don't want it. So we are making it up with the grid. It's guys, iteration's over, let's come to the end. So you have anything you want to, if there is anything you want to put in production, bring it. Sing it. I don't show so. What kind of production do you want? Hello, hello, hello, hello, hello. Okay. They all come here. It's almost white. Hang on, hang on, hang on. Somebody. Okay. Everybody, come on down. It's a tree, okay. Put it in production, is it stable? Okay, this is a product review, right? Okay, so we're doing a product review. I'm the customer. I'm playing the role of the customer. Oh dear. Oh, those look good. Okay, so. Guys, I'll just go through my backlog, so that. Okay, the first one, the most valuable thing that I was after was the farmer and the wife. Thousand points, thousand business value points, right? So the farmer had to be standing upright. No, the farmer had to be standing upright, right? Farmer's drunk. So I don't think I can accept that. The wife is really pretty, right? Very good. So wife is good. I'm just concerned that the business, the bank manager is not gonna give me the loan wife with the drunk farmer. So, yeah, so there's a late, late entry. Yeah, yeah. So the other, the important thing was the house, farmer's house, no house to be seen. So, so no house yet. Fixing doing the demo. Yeah. Okay, so we've got the ducks and the veggie patch, right? So the ducks were 400 points reasonable and the veggie patch was 200 points. Now, what I'm concerned about, there's no house for the farmer, the farmer's drunk and you chose to do the low value item first because you were not communicating back to the BAs here who knew what the product owner was asking, right? So why did you not communicate? Technology, okay. So what can we improve the next time when we do a second iteration, what can we improve? Call location. Travel, okay. No, but as we always deal with this, the timeline was through the day. Oh, with 60 people, you can deliver 60 items. And what I wanna do next is I wanna change, so suggest, I'm putting in a couch head now, all right? So two teams, the two teams that you have split it into two again, right? So the red team, you become two red teams. One red team stays here. Half of the developers, two BAs, one QA stay here. And the other half go the other room. Same with the black, right? Yes, so you have two scrum masters one scrum master here, one scrum master there. So one dev becomes scrum master, right? Now, so one black team, one red team offshore, okay? Then we will have travel budget for members to go through and through, okay? But be careful, don't burn out the budget because we only have four tickets, right? So you can only have four members traveling from red team, four from black team. That means two from each room can go and come back, right? So the other thing that I would do is we will introduce a proxy product owner, Evan, in the other room offshore. So he can help you, right? Now, this is how the guiding principles we're saying end to end capable teams by location. And we'll try that. So second iteration, red team split into two, black team split into two, starting in one minute. So second iteration, let's try and get this done. Four minutes. You only have the advantage for when you've already finished the time. Oh, okay, okay, thank you. So four minutes. Five, 13, okay. Yeah, yeah, yeah. So red team split into two, black team split into two. One move first. Why have you got two fences? Who paid for that? OK, let's wrap up. We're trying innovation. Two models. Oh, no one talked to me. Where's the proxy product owner? Proxy product owner, did anyone talk to you about set-based fencing? Wow. what was the point this is the thing right so we enable you guys to talk to product owners we even put a proxy product owner on-site off-shore but no one talked to them okay so farmer and the wife looking good is the wife prettier than the farmer yeah I like that that's good ship dog no ship dog it was low value so well done what so scarecrow scarecrow is really pretty right so so some things when like people were not communicating enough use your scrum masters we had four scrum masters in the 14th what happened to them like why we're not coordinating who's doing what the team members were lost was that wrong way yeah yeah why did it get changed because it's all out in the open it was very very visible what red and black where okay so again see offshore you don't have that visibility still right so there's a challenge okay scarecrow we've done that barn no barn or barn is that the barn yeah that looks like a barn was that a house what's this so no barn right two houses though okay so this is gonna be very difficult for me to convince the product manager director director good yeah no no no that's the track yeah very good veggie patch very good veggie patch well done yeah so the farmer and the wife's gonna be well fed windmill still drunk so windmill it's rotating yeah wrong direction though yeah yeah okay so that's okay we'll do that's good so square hey bells yes we've got the five square bells I said brown but you didn't have brown okay no one asked me if you want yellow or can we make a green one again like there's no communication with the product owner so this is the the symptom of distributed agile every distributed team they don't feel inclined to talk to the product owner so get in in habit of talking to the product owner directly so the other one is barrack moving up and down no fence two fences this one is broken that one's better but one fit so scaling see so you should have talked to other people about what are you doing how big is this how big is this thing gonna be all of that you could have had so many team members you could have had a scaling manager so it's like you have to think about that when you're distributed as to how you communicate amongst the teams scrum of scrums and things like that you had two tickets to go through and for all there were reluctance of people no one really came to ask real questions around that but that should have been the reason for traveling so farmers pickup truck we've covered that duck we're really beautiful still is yes yeah and then last trees for the Y that was very important yeah what happened okay yeah so stool and the pale pale is here stools not here is that a school oh yeah very good yeah so overall I think this is good effort one waitration and we'll finish it but we won't do it today right what's much more better like workable than having developers and be a so don't split it like that so and then the last the last takeaway is scrum of scrums is really important in distributed agile without that you're gonna be all siloed so scrum of scrums is the one of the best tools to use and the scrum master's role are important more important in distributed agile than in collocated the last point I want to make before we all go is you look at all this and the coordination that's required distributed agile is not necessarily cheaper there's a lot of costs that are hidden in coordinating effort distributed environments coordination with technologies and things like that sometimes it's more expensive but the way it up any questions before we wrap up cost quality is again depending on what your practices are like test-driven development behavior-driven development all of those kind of things if you deploy that sort of story if you use that sort of practice then it should be no worse than collocated because you you sort of having the same way of working in distributed environments it's just physically away from where this the customer is but there's no refuse right so I won't say quality is gonna go down in distributed agile if you're following the right working practices so don't use distributed agile as an excuse for deep degradation in quality no one wants to leave right yes yes now thanks for your time you did well to keep us on track yeah no but well done team this is this is a great effort with a bit of fun we should take photos of this we should take photos of this and make sure that goes on the website yeah and if you have any questions I'm around tomorrow as well and and later today as well so I'll the key takeaways from all the other things are gonna be in this slide so you can read it in your leisure time yeah I will share the slides yeah so there's some key takeaways that will take about five minutes to read yeah it's good thanks guys thank you