 But what I mean by coaching is somebody who works with teams and helps them improve regularly. So, you can be a developer who's coaching, you can be a scrum master who's coaching, you can be a coach who's coaching, or you can be an engineering manager who's coaching, or you can be anybody else who's helping your teams make progress every day, right? So, how many coaches in the team? Almost everyone. That's nice. So, it's great to see people who are interested in helping teams to move forward and make progress. I'll start with customer delight. Now customer delight is something that Steve Denning is popularizing a lot nowadays. What he says is that it's the ultimate goal for any organization. Traditionally, we used to believe that in the capitalist world, the goal of an organization is to make money for its shareholders. Now, he says that no, that's not the goal. The goal really is to delight your customers and do it in a way that customers feel happy about it and they keep coming back to you over and over again. So, that's what customer delight is about. But is it easy? Is it easy to delight customers? All right. So, all the work that we do is we want to do it. So, I also think it's a matter of perspective. I've given few of my experiences here. I was quite delighted by Amazon and Zappos.com when I was in the U.S. and by HEB, it's a small, it's a grocery store chain in Houston. And every time I went there, I felt invited. I felt, you know, there was some connection there in terms of doing some shopping or they used to, you know, have wine tasting, food tasting and all that kind of stuff free of charge. And I really enjoyed it. I don't see that a lot in India though. So, coming from India, I really liked it. I'm not sure if folks from U.S. who are here in the room, they're probably used to it. But coming from India, I really liked it. So, it's a matter of perspective. It depends on the customers, the kind of customers that you target and really, you know, makes an impression. So, I want you guys to think about when you were last, when you were last delighted. Anything? Anyone wants to share something? Yeah. I was delighted when I had my car for a year in the U.S. and it started when I got home. Wow, that's nice. Which car was that? That was the Toyota. Toyota? Okay. No, I haven't. Yeah, Toyota. Oh, really? Okay, I'll go there. I'll go there. Thanks. All right, cool. Thanks. Thanks for the suggestion. Okay, one more item on my to-do list. So, now I want you guys to think about, you gave some examples of customer delight. I want you to think about was it a one-time affair or was it something that went on forever? In spikes? What happens in spikes? Yeah. Okay, think about a restaurant. You go there once with your family. You really like it, right? You enjoyed the food. You said, oh, wow, what an experience. Next time, I'm going to take my whole team there. Now, what happens when you take the whole team there? The food is bad, okay? So, the light is diluted. It evaporates. Yeah, that's... Well, don't talk about a lot of folks. Just think about yourself. Did you like the food next time when you went? Okay, that's a different thing. If you were... So, that's why I said in the previous slide, it's a matter of perspective. Okay? So, I may like something that you may not like. So, depending on the target audience, you position your efforts. Yeah? So, what I'm trying to say here is that it's very important as an organization to think about customer delight as something that needs to be sustained. If you don't sustain customer delight, your customer will go away and it will find very, very hard to get him back. So, why is it hard? Few points. There are a lot of this, but few points which I think are important. Their needs are changing. Customers used to use old phones earlier. Now, they use iPads and iPhones. They have short-term memory. Anyone remembers which phone is this? This is the Kin from Microsoft, which lasted just a few months in the market. There's competition everywhere. There are brands. There are companies. There are platforms. Multiple things to choose from. People taking over each other, gobbling up each other. That kind of phenomenon. Last, this is... I think this is from India. Our systems are complex. Well, whatever we say, we talk about simplicity. We talk about refactoring. We talk about, you know, keeping things, cyclomatic complexity, phi or below, you know, all those things. That's fine. All said and done, our systems are still complex. There are many moving parts. If you take one wire out of this, I don't know what's going to happen to the whole pole over here. So, now what do we do? Is everything lost? Can't we achieve some, you know, customer delight? Well, we can. And this is a slide I have taken from Mike Russell. He was presenting on day one. This was the first session. And he talks about organization life. And he says that, okay, as you go and you start, you're working on a product, right? Sooner or later, it's going to start declining. At the same time, you need to breed new ideas and then again, come up with new innovations that will help you out. Now, this is very important, right? But how do you do this? You do this if you work in a sustainable manner. If you encourage your teams to work at a sustainable pace. It's my definition of sustainable pace. It's about making regular progress towards meeting a goal without depleting the ability to make faster few progress in the future. I've highlighted or underlined a few keywords. Regular progress, meeting a goal, faster progress, future. Now, think about a situation. So, you're working on this product and you did not have any time to breed new ideas, right? Your team was running behind deadlines and everything. But, and it did not invest on new ideas that were coming through. It would be really painful to get the product to out. So, this is really relevant to teams in terms of, you know, they should have capacity. They should be available any time you want to start working on new ideas and to sustain the organization. And teams are really part of the organization. So, it's important. But yeah, by the way, so, just one thing here. Sustainable pace is not the only thing that you need for customer to like. A lot of other things. Like new ideas. If you don't have a new idea, well, it doesn't matter how you work. So, here I want to talk about teams and I want you to think about teams and maybe this is the time that you might want to start using your post-its. If you have some thoughts and you write down things to discuss during the workshop, which we'll have afterwards. So, what you can do is, if anything comes to your mind in terms of what you are challenged with in your current environments, just take a post-it, write it down, raise your hand, Kruthi will come and take the post-it from you and she'll stick it up on the wall. So, we can think what are the topics we need to discuss in the time that we have. So, now I want to talk about the teams that are delivering at a sustainable pace. So, teams that deliver at a sustainable pace, they understand what their customer wants. They're not in the dark. They don't have communication challenges or even if they have communication challenges, they know how to work around them and get the information they need. They know, for example, if you see this slide, these guys are working on story mapping and they have personas to work with. So, how many of us have teams that use personas for their user stories? How many? Not a great number, right? That's very sad, actually. So, well, the teams that do not deliver at a sustainable pace go on their own trip. They don't know about what the customer really wants. How is this user story? How many of us think that this is a bad user story? Why is it bad, George? Yeah. We don't know what the value is of this particular user story. We just assume, oh, he wants a coffee, so, okay, let's create a software for some vending machine which will give them coffee. Sorry? Yeah, it's in disguise. Yeah. And another thing, we don't know who the user really is. What type of user are we talking about? Are we talking about most of the times, actually, not always? Or are we talking about someone from Norway? No. Yeah. Badly worded stories really have create problems for teams in delivering sustainable pace. The teams that deliver at sustainable pace, they habitually show regular progress. If they are using Scrum, they will use burn-down charts. They track progress daily. If they are using, for example, that chart, that's a release burn-down chart at the top. They would track their progress daily and they would show to the world that this is how we're doing on this particular initiative, this effort. This is how things are progressing. They will give regular demos to each other, to all the stakeholders, get feedback, act on that. This is a team that's... What do you think of this? Sorry? Not good? Why? Yeah. So, check-ins are really happening towards the end of the release and how many sprints are there? Do you see the number of sprints before release? Right? So, it's waterfall in disguise. No offense against waterfall. It's probably good, I don't know. But it's got so many sprints then a release and a lot of check-ins happening towards the end. In this case, they minimize... Yeah. So, teams that deliver at sustainable pace, they minimize the effect of disruptions. They act as a unit. This is from the movie 300, which I really like. And this is they call it the Spartan Fallings. Each soldier protecting the soldier by his side with his shield. Protect your teammates so that they protect you as well. It's reciprocation. Right? So, think about this when you're working with your teams. More important, protect your team members. Well, the others, what do they do? Any sort of descriptions? Hey, not my problem. I couldn't do this because I didn't get this from him or her. I couldn't do this because my dependency with the other team was not well managed by the project manager. How many of us are project managers? Me too. Teams that deliver at sustainable pace, they slow down to keep things under control. This is where I want to stress on slowing down. If you want teams to deliver at sustainable pace, you have to keep your work in progress under check. You have... If you're using Kanban, you have the work in progress limit there. If you're using Scrum, you have the time box, and you have your sprint planning meetings to keep your work in progress under check so that you can sustain. This is why. This is why. So, this is my perspective. So, be gentle. But if you think about the difference between this and this, you see that you see, look at this. This is a cumulative flow chart for a team which is working on a sprint. It's very recent. You can see the dates as well. So, you see, this is a sprint. This is a sprint, and you see the team how it's doing on the done and accepted stories here. Right? They're focusing on too many things at a time, and they're not able to get it done. That's not sustainable pace. So, what I mean by slowing down is do a limited amount of work at a time, get it out of the door, and then work on something else. Exactly. Done, done. Done, done, done, done, done. Focusing on true team capacity helps you establish sustainable pace. Thanks. You maintain a sustainable pace. Sure, it's good. Well, if it is maintaining... I mean doing it for like one to three at a sustainable pace. So, I think if it's already working on sustainable pace, you won't have the station. Teams that deliver at sustainable pace keep checking under control. They know where they are at. They know what they want. They know how to improve. I'm not going into too many details of this. There have been different sessions on this, but it's important to know where you're at with respect to your technical debt. You don't have to clear up 100% technical debt, but you should suddenly try to make improvements based on how much your technical debt is there. This is about teams that are scared. They do not deliver on sustainable pace. They are scared. Oh no, I'm not even going to think about technical debt because it's huge. I know it's huge. At sustainable pace, they rely on teamwork. They collaborate with each other. They support each other. The others, they rely on heroics. You need a Superman. How many of us have Superman and Superman in their teams? Alright. Okay. So, teams that deliver at sustainable pace, they learn from experience. Their respect. Experience doesn't mean that you're going to be editor to you. Right? It's somebody who has done something. He could be or she could be somebody who's fresh out of college but has done something which you haven't done before. Learn from them. Others? Well, that's what they do. They don't really want to take what will happen. They are more concerned about their own performance reviews and appraisals than really learning. They have high morale. They communicate effectively. Thanks, Lars, for this slide. The second slide is from Lars and he talks about effective communication mechanisms. There was a session by MBS today. I really like this slide so much. This happens to people who are not delivering at sustainable pace. They keep pointing fingers at each other or at other sectors. Very important. Leaders. I cannot under stress the importance of this. If you have leadership, that sucks. No matter what the team wants to do, they always hit a wall. There may be innovative things that teams could do to bypass and do things in a different way. Sheating themselves from the managers wouldn't really be transferred into for a long run. So extremely important to think about the kind of leadership you have. Think about what they need to do to support sustainability. This happens in teams that do not deliver at sustainable pace. They control team members like puppets. Can you do this? Can you pick up this task today, please? Has anyone seen that happening? Who hasn't seen that happening? Okay, no one. Okay, alright. So what do we do? And we see this happening all around. In some way or the other we are coaching people. But we see this all around. My perspective, few points, not all again, but things that I think are important for coaches. Look for warning signs. Help each other learn what the issues are delivering at sustainable pace. Tell the team members, tell the leadership. Tell anyone else. Reach out. Don't stop. Don't hold back. As coaches, understand the context. A lot of bullets here don't have to go through all of them. But if you don't know, if you don't understand the system where you are operating and you give the same advice to different sort of people, you are probably not going to succeed. So tune your responses based on the context. See things that need to change. Solutions will be different for different situations. Get support from leadership. Coach them if you have to. Have lengthy discussions with them. Meet them over dinner, lunch, offline. Gain teams trust. You have to gain teams trust if you are a coach. If the team doesn't trust you, they won't listen to you. Even despite all the constraints or situations that they might be operating in. Navigate through all the force fields. Organizational issues. Politics. Has anyone seen politics in their organizations? Oh, I thought there was no one there. Why does politics happen, by the way? Any thoughts? Insecurity. Why insecurity? How can I sustain over others? You want to feel important. Promotion. Promotion. Why promotion? Promotion is a great point. Why promotion? Why promotions? Why promotions? What your boss wants, right? Who promotes you? It's a boss, right? The boss promotes you. He sets you a goal. And if you see, if you have stakeholders like this in your organization who have differing needs, right? They will set different goals for you compared to what the customer really wants. So understand. Understand what the force fields are. People just don't want... They want to get promoted, of course. We all want to get promoted. Anyone here who doesn't want to get promoted? Oh, yeah, you are... Of course. And you? Are you working outside an organization? Are you part of it? Oh, you run your own organization. So, yeah, there you go. Okay. People are ambitious, right? So... And they will behave depending on how their managers or bosses will want them to. Coaches can play games. This is from yesterday? Was anyone there? Okay. So coaches can play games too. In a fun way, try to teach new things to the team. Coaches can teach relevant techniques. Whatever is important, whatever works. Coaches should use drive change. Data is a mirror, is a great tool in the hand of coaches. If you can show objectively how the team is performing on any parameter, it's a great win. People will find it very, very hard to kind of say no to the data. Make sure your data is as accurate as it can be. 80% in my opinion is good enough. You should look for multiple sets of data. This is just showing velocity and average velocity, but you could probably couple it with a few other things. For example, changes in scope or, you know, the number of disruptions that you had in your team during a sprint, stuff like that. Coaches should help teams conduct a good root cause analysis. It will help them a lot for any sort of problems. Coaches must. Class like. Coaches must stay engaged and they should help teams inspect and adapt. Any disagreements to this? Okay. So this is what Dave Rooney said in his workshop. If you stop learning, you should probably not be in the job. Dave, do you agree? This is what I... what I think. Oh. But anyway, I had a crosshair. I stuck it out. I stuck out probably. You're being Canadian polite. Okay. So if you stop learning, you should not be in the job. Very important for coaches. Like I said, it's not about experience. It's not about... Sorry, it's about experience, but it's not about number of years or the number of years you've lost. All right. That brings us to the end of what I had to say. I want to move to the goal-taking exercise. Basically, I have compiled it into four categories mostly. The first one was mostly about every customer having different needs and changing requirements and how to deal with that. And also, one person asked about should we align to customer pace or make them understand our pace? So topic number one is about the customers. Aligning to customer space and making them understand our pace. Is everyone okay with that? How many of us want to discuss that? Okay. Cool. So I'm going to put this here. What's the second topic? The second topic is about actually running the meetings. One request here was the person acts as a developer and is in two scrum teams. So how does he handle it? And also how to keep the managers away who are used to pushing. Okay. And is it because of poor sprint planning that teams burn out in sprints? So basically management influence and sprint planning is these two items all together. Do you guys want to discuss this? How many of us want to discuss this? Okay. Then next one. The next one is about preventing death march and how does team move from ad hoc to actually a sustainable pace? So death march ad hoc sustainable pace and slack. Right? Okay. Let's just put this here. Next one is The next one I got three requests. How to motivate teams to deliver at sustainable pace and techniques to help people to actually see the bigger picture. And how to coach leaders to maintain this. How many of us want to discuss motivation? Motivation? Okay. Great. So this is going to be tough last. We have like four topics or we have two more. The next one is what if the team is already successful and is already working at sustainable pace? What next? So what next beyond sustainable pace? How many of us want to discuss this? Okay. So what I would like is all of us to choose certain areas that we should move around now and that person takes the notes for that whole discussion. In the end, we will have notes from everyone from all the groups and we will share those notes with everyone. Good. It's gone during this time but it's not still just showing the priority of that. So 30% backlog is still available but the rest of the things we have decided by the maximum... ... ... ... ... ... So let's start from here. ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... and plugged to the issue, right? So again, it's providing safety around to the people. Understand the minds of the individual to understand their demotivation point. So we discussed that when you try to motivate team versus one to one people, right? You meet them half step ahead rather than where you want them to be. So that helps them to connect with them what's their problem is, right? Cool. And make team members secure and safe. So provides safety. Yeah, don't overpamp your teams and don't over-criticize as well, right? Fantastic, give them a clap, everyone. Well done, yes. So we also spoke about motivation. I'm gonna try and extract themes that we talked about because there were a lot of repeated points that sort of drove at the same thing. So there was one thing was building sustainable pace is a good way to have your leaders have trust in you which can be a driver for motivation. The other one is having a good idea of the bigger picture or vision. Can motivate teams to deliver better results and have a sustainable pace and things like that. Stretch goals can be one other way of motivating people to go the extra distance. Appreciation of teams over individuals can be a good motivator. The other thing that we did discuss was if appreciation comes from external sources for individuals over teams, that might demotivate people. But one way that a lot of individuals and Oscars came up as an example of how this happens is if the recipient of the appreciation also appreciates his team for their contribution to his success, that can help the team get motivated as a whole. Transparency is a big prerequisite for motivation was one of our key discussion points towards the end. I don't know if I have anything else. I think that was what we discussed in terms of motivation. Fantastic, thank you. The topic is sprint planning and how to deal with the management interference. And a couple of points, very good points and came up and along with a bunch of questions which we are open ended right now. So we'll just propose the questions and see if we have any ideas. The first thing is don't overcome it in the sprint just to impress anybody. Do it as per what you feel is the right thing. Like 40 hours a week type scenario. And don't get into pressure from either the PM or the scrum master or anything. And if at all there is a scenario where you need to deliver the company as a whole needs to deliver more points than what the team can sustain. It's better to go back to the client and negotiate with them. Versus like you taking the extra points and trying to please the client. And this, my personal experience is this has happened. We don't think clients are also people, right? So they understand our constraints and generally tend to reciprocate accordingly. And the one other point which came up is the PM needs to adapt to the new work culture of agile and try to be more of a chicken in the meeting if he wants to attend but he's always welcome not to attend. So that's the team consensus. Right. How about that? And one big way to adapt sustainable pace is to have clear acceptance criteria upfront during the planning. And that's mainly from the product owner's perspective to give as much details as possible so that the client, the team can go along with it. And then make sure that all the stakeholders attend the sprint planning meeting which includes the product owner, the scrum master, et cetera, so we know exactly what we are doing. And one other thing again with the PM is sometimes the PM's on their own repriorities the product backlog. Maybe after the sprint has started and again then they call for an emergency meeting, et cetera, which should be avoided. And something lack of trust. PM should not be part of the sprint planning we already discussed. And one question came up is somebody developer is in a position where he has to be part of the two scrum teams, which is on the surface of it is sounds like a bad idea. But if he has to do it, what are the, are there any pointers, et cetera. And then accurately estimate and predict the team velocity. So again to maintain a sustainable pace. And one very good code which can come up is under commit, but overachieve. So if you are done on with all your commitments on day eight, you may want to raise your hand and take on your stories. Fantastic, thanks. Is there anything else? No. All right, cool. How many groups are left? Right now, how many pads are left? The last one. Motivated. Just one? Add up to sustainable. To sustainable pace. I've lost a golden old to start with some venting at situation most of us have been in. When we're scrambling to get to release and after that scrambling, the next sprint we're kind of out of steam. So how to avoid that? Think, there are a lot of things coming up. One of the things, I think a good point that came up was that we're probably not, we're expecting to go faster than we really can go. So one topic was to try to gather data to get that back to the manager on our real velocity. So that's one way of dealing with it. Another way is to try to increase our effectiveness through various means. We could try to be tough about what we really need to do. Maybe we can skip performance tests as on sprints. Maybe we could hire a clerk to do non-value added work that is required from us from organizational requirements. I think a very constructive advice that I kind of took a lot of notes on was to have testers collaborate actively with developers to make sure that you have extremely effective continuous integration tests with a high degree of automation. That way we can be more effective in the actual, well, I think my perception was that the crunching is due to not that effective tests that has to be done manually. At least I've seen that. So that's kind of my interpretation. So if we can have extremely effective or more effectiveness of the tests done on a more regular basis through continuous integration, we might achieve more sustainable pace. In terms of, well, back to the management, I think George wasn't happy with our outcome. One way was try to gather, really gather this data, give it back. And what you can do, you can hire external people to provide that message because maybe this is a stern validation trick. So it might be more effective, that's something to consider. Then we were talking about, yeah, make real hard prioritization. I'm kind of noticing maybe one reason for this crunch is that we're just taking on too much. We can be tougher on doing the read prioritization. An interesting argument that was here. I like to bring that up. I don't think we concluded on it, but there was some discussion, our ability to be able to swarm around important stuff so that we actually keep our working progress in check. I think a lot of people in the group had experience and they were doing too much and then we get into the crunch mode. And, but other people had experience that it's possible to actually have people swarm around, having four people working on the same thing to get that done as opposed to having too many people working on their own stuff and not getting anything done. So that's interesting. And then, well, I think the final stuff. I think that the most valuable outcome was, it was several people coming up with the idea of having developers working tightly with testers. So I think that's our most golden outcome. Anything else, team? Fantastic. Thank you. Our team's swarming. It's a good thing if you're stuck. If you're stuck with a very difficult problem to solve, then it's good to get everyone's head together and kind of work on it together. It's taking, I guess, it's taking the pair programming to the next level. All right. So, well, thank you very much. The workshop notes and slides will be here.