 Oh, I'll give everyone the last bells are ringing in the halls, we'll get started. So welcome everyone. So lovely to see you all here after another amazing lunch, too many good food for me. So my name's Kathy Burkidge, as you might tell from the accent I am from Australia, I am Melbourne based. I've been in IT since the 1980s. I started doing these crazy development stuff way back then. I used to do assembler coding and C coding and stuff like that back in the old old days. I've been working agile, whoo, there's a lot of that. Working agile since the 1990s, delivering all sorts of different roles. Sometimes as a BA, sometimes as a scrum master. Nowadays, mostly coaching and training. I'm not quite sure what's happening with that echo, you know. Little bit too much about me, you can all read all that stuff in my profile. If you go on LinkedIn, you'll see way too much about my history, et cetera, et cetera. On your tables, we have some tables with nothing and every other table with something. So if you want to move away from a table with nothing onto a table with something, probably a good idea. On the tables with something, you will find some Aussie souvenirs, you can find them amongst themselves from koalas and roos and key rings and pens. A few random things. A present from me to you, because every time I come to India, I find your present, I get too much, so I want to give some back. So a little bit of Aussie there. And throughout our session today, I'm giving away some Australian cricket caps. Well, not cricket, they're just Australian caps. I've got a couple of them to give away to those who participate and answer the question in the most correct way. I'm not quite sure that the audio says to be a bit dodge, audio person, up, down, echoing, not bad. So this is a workshop. You're working in this shop. And I'm going to stand back and watch you work, which is going to be great. Today we're going to do my passion, my number one passion when it comes to agile, working in teams, working with teams, training teams, whatever the case might be. My number one passion is to see teams thrive, see teams succeed, see teams cooperate, and of course, see teams being awesome, happy, harmonious and collaborating. Over the years, I've seen teams do some better than others. And I found the common theme with the teams that did the best was this real sense of camaraderie, real teamwork, knowing how we behave in the team, knowing what's expected in the team, knowing how we're going to work together and achieve this thing that was being given by our stakeholders, by our businesses. And it's not the processes, because we know it's individuals and interactions over processes and things. We know it's not about contracts, it's not about documentation, not about plans, it's about the team really coming together. So over the years, I've sort of talked about it, researched about it, talked to a lot of other people about it. And working with my teams back in Melbourne just before the pandemic, we were doing some teamwork and we were trying to identify why the team was not succeeding. Why this team was having so many difficulties, what were the issues, what were the common patterns, what were the common anti-patterns. And it just so happened at that time, we had a lean canvas in front of us with the summary of the work. And I said, let's use this canvas as a template to figure out our teamwork and the rest of this kind of history. And that's what I'm here to talk about today is the team canvas. There's been quite a lot of canvases here. And one thing that's been amazing in this particular conference, more so than any other that I've been to recently, is the emphasis on teamwork, the emphasis on those soft skills. Yes, there's some great stuff about the other stuff. But really, it's the soft skills, the communication, those kinds of things are what's going to get you over the line, not just the tools and techniques. Even though I sponsor, they've got some great tools out there, so I'll go with them. So I'm here to talk about teamwork, how do we create awesome teams, not just ordinary teams. For those who were in the amazing workshop yesterday with Richard, well, that was a fantastic session. And this is the next tool to take on from there, I think. I was in that session and I just went, yes, yes, all the way through because it does start with the personal reflection and then what you bring into the team. So from that canvas that he presented yesterday, this is probably our next tool to bring it together. I think some of that together for those in that session. I'm not going to go back and go through everything he went through, but those who were there, certainly that would be a springboard to where we're going today. So please, a couple of ground rules for our workshop. Ask any question any time. Don't wait for the end. I'd rather address your questions as we go. So just, you know, wave, we'll get a microphone to you at any time. I'm not going to just wait till the end. Of course, there will be time at the end for questions. But please don't wait for questions you can ask any time. And number two rule is that there is no silly question, except for one. Do you know what it is? The one you don't ask. That's the only silly question. If you leave that room and go, gee, I wish I talked to Kathy about that. You know, well, I'm in a plane and I'll be away. And then you can find me on LinkedIn. And I do, I'll have my contact details up later. Find me on LinkedIn. I mean, honestly, when I'm happy to connect and I'm happy to help you if there's any questions after this session anyhow. All right, let's get into it, shall we? So what is a team? Who can tell me what do we mean by the word team? I love this common objective. Yep, what was I going to say here? Very similar, nice, anything else? What is the most common goal? Common goal, definitely. So a couple of definitions for us. I always try to start at the very basics. A team is a group of individuals, human and non-human. Hilarious to think about it. Because you think of the old days, you work with horses. You work with computers. My PC's part of my team, yeah. So we are working together to achieve a goal. Interdependent, we are interdependent. No one of us succeeds without the other. There's that interdependency of all of us together. None of us make it alone. All of us make it together. So we're doing that with respect to information resources, knowledge and skills to combine our efforts to achieve that common goal. And a group of people does not necessarily mean a team because it's that sense of purpose, that sense of common goal, that sense that we're all here together is what is the big difference. So that's what we mean by team. Let me just grab something here which I forgot to grab before. Okay, I've got it now. So what does team work? Working together, yeah. Yep, similar to this. I love that team working together, supporting each other, exactly. A collaborative effort has achieved a common goal is for the task, cooperative and coordinated work. So it's all that common sense. But we all know team work isn't that easy. Still be able to say that cooperation, collaboration, communication, cohesion, these are all the C words you hear that you can have each of those without that true sense of collaboration. And that's what Agile asks us of this is to truly collaborate, truly share, truly support each other, truly be there for one another because it's not my goal or your goal or your goal, it's our goal together and that goal is something beyond ourselves. Number one is to satisfy the customer. Those who know your Agile manifesto, you know it's principle number one and priority number one and we're here to do that exact thing. People who report to the same manager do not necessarily constitute a team. So it's best that we just report to that guy we could be working on completely different things. So I also wanted to kind of pull that one out because there's a lot of people that say, yeah, it's my teammate and I'm like, what's your common goal? I'm trying to get the promotion, I'm like, not quite what they mean. So there's some few thoughts there about team work. Now, this is some information from Karl Weck who did a lot of, I've got the reference there probably somewhere in the back there, improvisation mindset. And he came up with this concept of talking about teamwork in comparison to people playing music. When we think about an orchestra, a symphony orchestra, with all the strings, option of the brass section, the woodwind section and the drum section and the violin and all that, we've got one person at the front conducting. That's not what we mean. He really talks about this agile collaboration more like a jazz band. A jazz band where they respond to each other, where they spontaneously act in the moment rather than this rigid kind of way. This one person conducting, everybody knows the team are always kind of looking for each other, looking at each other's energy, what's happening with each of our team members. And we're doing that in real time without waiting for someone to prompt us. And that's really what this view is all about. So if we're looking for innovation, we're looking for speed to delivery, if we're looking to satisfy our customers in a value-driven way that agile six of us, we've got to start thinking about how we are there for each other, how we feed off each other, how we will contribute to each other's success. So we're there together to help each other develop to their own best potential. That's what I loved about the session yesterday is if we call those things out, if we make it clear what our best potential inspirations are, then we can understand them together and help each other towards that goal. So yes, we've got a common goal together with the team, but we're also supporting each other to be their best selves. And that's kind of what I'm looking at. So some of the concepts that come up with this is the first one is just enough structure. Enough so we're on the same page, enough so we've got agreement, enough so we know what isn't going to happen, but not so much that it's rigid and it's law and it's all about, we must follow this process and we must stick to these rules just enough to allow flexibility as needed, but just enough so we're all on the same page. And that's really important. Matching the pace rather than working independently. Now, this is one that sounds easy and we all understand that I've been in enough dev teams and I've worked with enough dev teams to know that the devs are miles ahead, the testers are 90% of the time trying to keep up and people don't want to talk about it. I've already finished that code. No, go back and we've tested this, but no, there isn't. No, no, no, no. We want to match that. And again, before we talked about those short cycles, 15 minute cycles, TDD, pair programming and all those kinds of concepts. Yeah, they're great, but it doesn't have to be just the indeds and tests. It can be with the A's and the X's together. It can be any kind of skill group. So it's that real sense of when matching each other with the rates that we're working and we don't leave people behind. We don't move to the next story. We don't move to the next test. We don't move to the next requirement until we're finished and we're all together on this one. How many have you got that really happening in your team? I've rarely seen it. I normally see the tests running ahead. The test is running behind and the BAs somewhere in between, usually. I'm a BA by trade, just putting it out there. So I'm a tester originally though. Acting in real time over following a plan. I mean, that sounds like a manifesto thing, doesn't it? Things change. What we hoped happened, what we wanted to happen, may not happen. So we need to be able to respond in real time rather than saying, oh, well, we said today, we're doing this particular integration or we're doing this particular release. We need to act on real time. Another one is using previous experience. Because everybody in the team has experience, typically. Unless you literally just come out of school, which can happen, but chances are you're not going to have a whole team full of people who've never worked in a team before. So we need to look back and say, what's worked for us in the past? What hasn't worked for us in the past? That's what our retrospectives are all about. So we need to be able to reflect on those past experiences and use them to help us in form. But we also need to focus on what's happening here and now. Not looking so far ahead of ourselves and looking at high lofty goals. Hang on, we've got a problem right here right now. So it's remaining present at the same time, whilst not being stuck in the past or the future. Importantly, we need to understand what's around us. What resources do we have that can help us? Other people, other teams, tools, techniques, other learnings from other parts of the business. What can we use? Not just us, because we're not in an island, we're not in a vacuum. We might need to be able to consult and look what else is around us that can help us. So we need to think of that as well. Opening plans, open to deviate, which is what I sort of mentioned before, and the confidence in the team to deal with the unexpected. Now, that's an interesting one, because that's a matter of kind of trust that, look, things aren't going to go always perfectly, but we're going to trust each other, that we're going to do our best to gather, to get through it without shame in blaming and finger pointing. So there's this confidence that, yes, it doesn't matter what comes, good, bad, or ugly, we can rely on each other and know that we've got each other's back. And that's what the kind of environment I want to work in, and I'm sure you do too. So these are a couple of the success factors, I suppose, for a team, which we all aspire to. And some of this is, you know, when we think of team, it is a group of individuals that collectively they build this kind of bubble of trust, this bubble of working together, and that comes from the team members themselves. So we've got to work towards helping each other create this sense of team together, this feeding of each other to help maximize our strengths and minimize our weaknesses together, finding those synergies, finding those areas of cooperation, finding those areas of challenge, and also addressing them, because, of course, they're always going to be there. So I can learn to help each other to deal with all this. So I'm going to give you an... Whoa, I don't like that. Probably because I'm too close to a speaker. I've used to play in a band myself, and I remember that was my deliberate thing in the band, so I don't want to do it now. So I'm going to give a couple of minutes, so just with the people on your table, if you've just got one or two of you on a table, you might want to join in with the bigger table if you wish, no obligation if you don't want to, but I want you to have a talk about what are the common challenges for teamwork that you've seen or you've heard about. Maybe you've never had them yourself, but somebody else that you know has. So have a few minutes to talk about your common challenges, and I'll come back and hear what you came up with. And there is some stuff on your tables. Ignore them for now, please. We'll come to them in a little while. So what are some common challenges that you've experienced in your team? I'll give you a few minutes. Brainstorms and... Oh, brainstorm. Yeah, if you can write them down on brainstorm, because I'm going to go around and get a few ideas from everybody. Thank you, thanks for playing. All right. I might get you to finalise that last thought. I can hear that there's absolutely never any problems. It's great to see. Fuck. All right. Okay, so let's come back together now. All right. I feel like I need to go... Oh, something. Oh, that's what we do, right? You all know that one. Okay, so let's... Perhaps if you've got the mic, I might start with this table. Can you share... Someone share a couple of yours, please. Hello, everybody. Hello. If you'd like to... Thank you. I'm just getting a few shares now. We have got like 10. Oh, that's great. Is it okay to go? Of course, let's do that. Okay. So prioritising individual... Excuse me. Prioritising individual aspirations over the team's aspirations. Yeah. That is what will result in conflicts, right? Personality traits of the individuals. Yes. Clarity of vision or goals is missing. Yes. Unclear requirements. Definitely. Unwilling to share knowledge. Yes. Within or among the team members. Lack of skillset for few individuals. Psychological safety issues. Yes, definitely. Task prioritisation issues. Yes. Few people want to work on high quality tasks and the others don't. Yes. External interruptions and interventions from management also. Fantastic. Dependences across other teams. Definitely. Last one is a low team happiness index. No, not much happiness either. Fantastic. Who's got the microphone over there? Yeah, can you share a couple there too? Thank you. First one is about the consensus building that is a challenging thing within the teams. Yes. And then, as already mentioned, the personality clashes. Yes, definitely. And the lack of role definitions. That's big too, yes. You don't know who's responsible and role is for what. Yeah, there's really big challenges. Yeah. Anybody else got something in particular? Here? Yeah. Oh, sorry, I'll just look at the first one hand. A couple of others that you've had already been mentioned. Thank you. Conflict with something. Conflict, yes. And then there is a perception. It's another thing that has been added. Yes. What else is not covered is power sometimes. Power struggles, absolutely. Fantastic. And you had one here? Yeah. So I just got a paraphrase there. I know the mic didn't make it. People who don't want to ask for help, they've got this, I don't, if I ask for help, I'm going to look weak. I'm going to look silly. That's, that's, that's, and that's that psychological safety right there. If I ask, I look stupid and then my face will be shamed or whatever. And this is terrible. It's horrible, horrible. A dominant member. A dominant member, yes. Power struggles, dominance, that sort of thing. Which can be really, really tough in any team. It doesn't matter what part of the world you're from. These are all common. So let's see if we've got all my list. Personality, clashes, tick, lack of engagement. Didn't quite hear that, but that's a really huge one. If we don't feel that we're a part of this and we're disconnected and we're distant and we just don't see the point in it. Now that may be with the team problem, but it could be a broader problem in the organization. It could be cultural as well, where we just feel like, you know, what's the point the company's going under or perhaps there's lack of incentives. There could be all sorts of reasons for lack of engagement. Internal competitions, and that's where that power struggle comes from again. Communication issues. And that could be an interesting one. In many, many factors, because communication issues in itself is probably a category of all sorts of things whether it's language barriers, understanding, individual attention, listening to each other, showing respect. There can be many, many things. That's just a big one there. People working in isolation, yay COVID. How is your teamwork over COVID? Does your team work improve over COVID? Not many body are noticed that, yes, really, really, really. Most people found the distance. We started just becoming solos within ourselves. Yes, we had Slack and Teams and messengers of whatever description, and we can ping each other, but that real informal discussion about stuff, you know, stuff, stuff, the stuff that we talk about which doesn't necessarily have to mean we've got a nose to the grindstone doing work. So that informal part of just pinging ideas around and how is your kids or the cricket score? I was going to say footy, but I know where I am. Yes, we're not going to talk about testing with the shocker. I mean, it wasn't that wicked, come on. Anyway, lack of clarity, which was another one. Lack of clarity of roles, lack of clarity of what we're doing, lack of clarity of requirements, lack of clarity of the priorities, huge problem. Trust issues we talked about, and some of this is cultural, some of the company organisational culture, I mean, and some of that could be just individuals. So learning how to build trust together. And that doesn't happen by me just saying, trust each other and you will. It doesn't work that way. Trust is all sorts of different factors, showing that you're credible, showing you're reliable, showing that you know and understand someone, showing that you've got respect, but it can be undermined by your attitude and your lack of awareness too. So you can build trust with all these things, but it can be undone just as quickly. And that's an individual thing. But we've got to work on it together as a team as well. Conflict, tension, and that's not a bad thing. There's healthy conflict and there's unhealthy conflict. So I think that lack of conflict can also be a problem when we're all just going, yes, yes, yes, yes. And I don't like that sometimes with some people from this country. There's a lot of yes, yes, yes, when really, the answer should be no, no, no. Please say it. I had a terrible experience one when I did work from a team from Tune and the lead person kept on telling me, yes, I understand, yes, I understand. And then they deliver the next day and clear it. They did not understand, so I didn't pay them until they started saying no. And then that made a difference anyway. So we need to be able to trust each other to say that. We need to be able to trust each other to say that. Insecurity, insecurity about my job, my place, and it could be in lots of different areas that might not just be I'm about to lose my job, it could be insecurity about I feel maybe I'm surrounded by a group of genius people and I don't feel my brain powers up to theirs. And that could be quite insecure because you've walked in and you just go, oh, I don't, oh, gee, this is above, am I too deep, am I working above my head? And that's kind of a good thing because that's something I challenge myself to find people who are better than myself so I can learn from that. That could give you a big sense of, oh, that one looks silly. Lack of shared goals. Now we just talked about teamwork. If we don't have that shared and common goal, we're not all pointing in the same direction, then it's not gonna go well. Is this little thing called ego? Anybody who studies the Vedas or Buddhists doesn't need to have a whole philosophical discussion about that, I've been studying this stuff for 25 years and ego, well, lack of transparency, one that didn't come up. A lot of, and it kind of comes to that, I don't wanna share, and that's a real big problem because if we don't wanna share, it's because we've got something to hide or what happens a lot, if I don't share then no one else knows that I'm gonna make myself look so big and important back to ego again, shame. Okay, what else? The team is too big. How many of you work in a team of more than 10 or 12? Yeah, this can be really a big problem and that's why Agile typically advocates teams that are seven plus or minus two, 10, 12, because when it is too big, it is too hard to stay on the same page and focus as a group. Lunch is a classic example. We don't all 100, 200, 300 people stand around having one conversation because it's too hard to focus too much, so we do center off and that's what happens in a big team as well. Okay, so on your table, now I have a few spare copies. This is, it's on the screen as well, exactly what's on your tables, you'll find is a case study, the challenges of teamwork and my fictional but not so fictional team, hang on, where is it? I've got a few more if you really want the handout, so it's about DMS, a medium-sized business specializing in telco, I used to be in telco, I wonder which team this was of mine. So there's the case study, it's the same as on screen. So your task, once again, if you want some more, if you want to hand out a few, if you want to put your hand up and get an extra copy, there is, again, there's some things, I've got plenty of copies, some things I don't, but it's for you to do together as a table. So once again, working with the people on your teams, have a read through this case study, probably something you might be familiar with where there's been an emergency release that broke production and everybody finger points, have a read through it and your job is to look at the questions at the bottom, what could the team done to prevent this issue? And number two, how could have they handled the outage and stand up differently? And you'll see that in the scenario. So have a read through that scenario together and see if you can answer the last couple of questions. Once again, I'm going to give you about five minutes to come up with some ideas of how this could have gone better. All right, any questions before I start? Just five minutes. So read through it together and share together. All right, anybody needs their copies? There's a few still if they need them. Okay, just a two minute warning there. Two minutes, two minutes. See if you can make some dot points and we'll get some out. One minute, one minute warning. Okay, if you can wrap up that last thought, wrap up that last thought. So if we can come back together now and we'll start sharing some of our thoughts, there's probably lots of great ideas. So we'll get around to a few of the tables. So I might ask this table over here to start. That'd be great. So I'm really looking forward to seeing what everybody thought what some ideas are to done this issue prevented it. Fantastic, go ahead. Thank you everybody. Thank you. Okay, we both will speak together. So one point I want to start with is the CEO. He's the leader of the company, right? So leader has to be accountable here. Martin gave an approval. So I think leadership has to be accountable and they should start with sorry, right? That could have avoided conflict in the stand-ups in turn the whole stand-up into positive thing that I think leadership. The one who take leadership has to be accountable. 100%, that is a fantastic point. And that's something that's really important. Like with the team, whether we have a team leader or a manager outside the team, they've got a model of the behavior that they want. And that's somewhat in this case it's done very well. So they have to be accountable that they've created this negativity perhaps here. Wonderful point. We have two more points to see. One is about the communication. Yes. So there was no proper communication between the team members. Then we identify that in a stand-up that actually the leaders were not listening properly. So it could have been solved at that time if they're listening team members and they can motivate them also for the next time if something is coming up. So that has not been happened. That listening. And the reason I want to bring that one and talk about it is I'm not going to ask for an answer but just reflect in your own stand-ups are you really listening to each other or are you going through the motions? I see a lot of people doing a lot of this on their phones while everybody else is speaking. That's not listening. It's really a stand-up. The purpose of it is to synchronize and move as one team and when we don't listen then we have problems. Great point. And you had another one too. Respect others in a meeting. So that one thing. No respect shown. And that's something that's got to be modeled and the leader must be accountable because he didn't show respect himself. So he's modeled bad behavior and the team has followed along. There's a saying that the leader gets a cold and everybody else gets the sniffles, right? The leader sits the tone. Fantastic, great. We identified one more point that is about lack of process. It was like change management process or nothing is there in between so. Absolutely, there's definitely a lack of clarity of the process there, particularly around testing, you know, what is and what isn't. Fantastic, thanks for sharing. Where's the other mic? Yep, we'll go over here. I think it's, yep, fantastic, this team here. Fantastic, thank you very much. So answering how could they have handled the problem? We have written like around 10 points. Go ahead. So by being collaborative is the first that they could have handled the problem better? Yes. By having descriptive roles and responsibilities? Definitely. By being transparent with each other, working as a team and not taking the decisions like it should not be autonomous with the one person? Yes. Team A, if it would have been on agile, it could have handled the situation better. Okay. Right mindset, having the right mindset that testing is needed, it should have avoided the problem. By not blaming any one person, it could have handled the situation. By being process oriented, having right communication, being respectful, and being a leader, not a boss. Ah, yes. That's such a great point that last one. You think about leadership versus management. Leadership doesn't matter whether your reporting line or your pay grade's higher at all. Leadership comes from everybody. And there's a saying from those who play, I know I'm going to be controversial here. DSTM, how many people know what DSTM is? You're not scrumming. So I think you don't know what DSTM is. It's older. DSTM's one of the first. But anyway, when we talk about the SBM and the Business Consortium, they talk about leadership at all levels from all over and that's really an important point. Fantastic. And last but not the least, a bit technical. If they had applied a hot fix and if they had worked on RC root cause analysis and then worked on the, I mean post fixing, like hot fixing, that could have also prevented them. Exactly, they could have done a little bit more with that analysis, rollbacks, all the rest of it. I mean, hot fix, we know it happens, but there should be a hot rollback too. Hot fix doesn't mean we just proceed forward and try to hop this on, hop this on, hop this. Fantastic, great. A few other tables, Mike over back there, thank you. Yeah, apart from what already everybody covered, of course, the CEO should have accepted that particular blame and that way their stand up could have been turned out into be a good team discussion. Secondly, more technical on CD testing, that's continuous deployment testing. That's right. Okay, which was missing and also automation regression test pack. Anything that goes into any environment, automation regression pack should have picked up automatically and then transparency and communication, which was like purely missing and it is somebody who's taking the call, so that's why. Yeah, so there's a few technical things there that definitely that continuous regression, having that regression suite constantly being run as a minimum viable regression test for whatever the case might be, too fantastic. Over here, thank you. A couple of other structural issues are like the CEO becomes a bottleneck on making all the decisions across all the departments. Yes. That's a bottleneck that slows down the system. Yes. Yeah, and another one what we thought is maybe the teams can be having more of end-to-end responsibility because one team is doing the development and other activities, other team is trying to fix those issues. Yeah. If you have that end-to-end responsibility used more. Yeah, and that's an interesting one, because we know many organisations I've worked with, there's one team doing DevOps-y things, and the other team doing client-facing important project feature work. Now, that's not a bad thing within itself, but there needs to be cross-team support so you don't get each team kind of becoming completely disconnected from each other. That's a really good point as well. Yeah, fantastic. Anyone else care to share a last stool? The last couple there. I'll go just this gentleman and this gentleman and then we'll move on. Fantastic. Thank you. There's just one perspective possibly that is not covered. I just wanted to add is a little different spin on the leadership aspect that the leader should have agile mindset and leader should actually empower the teams. Yes. Leader should not get involved in the whole process. It's about empowerment of the team, saying that you deal with it, I'm there to support. That is one part. And from a daily standup possibly one thing I just wanted to add which was not covered is we need to start daily with the positives. Yes. As the hotfix happened, people worked overnight. I think there was a call out that people spend a good amount of time. So we should appreciate that saying that there's a good work being done and then talk about what can be done better. I love that. And when we think about feedback and that's really the point there, feedback is both redirective feedback but also reinforcing feedback which needs to be in equal amounts. Reinforcing and acknowledging and those things are just as critical than just getting to the problems. Well said. Thank you. I think there's one last point over here. Thank you. So in my opinion, there are two behavioral aspects I would like to highlight here. One is before even this event happened, the team worked on isolation. Yes. The leader, the CEO and the expert, right? They worked in isolation without discussing in the standup. Yes. That led to the issue. Yes. Right? So that's one. There is an isolation here. Yes. And number two is there is a command and control. Yes. The last paragraph. Definitely. I think she already mentioned it. Yes. The leader versus boss, right? That's right. So there is a command. So when the team questions, the leader says, go back to work. Yes. There's a clear display of command and control. So it shouldn't have happened. Many others mentioned about this fact. So this behavior issue will lead into these kind of issues. That's what I want to highlight. And these are not uncommon in the real world too. Hopefully that wasn't too traumatic for some of you who have been through very similar aspects. This was an actual scenario that I was a part of. And we did have that leader. That leader who used to go in at 3 o'clock in the morning after a few scotch and cokes and start coding. And we'd wake up in the morning and he's shoved it live and we're like, what have you done? And he was one of those people. He was the founder of the company. And he said it'd be quite inappropriate. But we also had some other, the big thing that's also missing for me was where's my facilitator? And I'm not just saying scrum master. I'm saying facilitator. And I don't mean the CEO in this case. Who was that person who has that servant leadership scrum master mindset that they are there to protect the team, to remove obstacles from the team, to enable the team to give them the right environment support that they need for those who know your agile manifesto. It's principle number seven. Build teams around motivated individuals given the environment and the support that they need and then trust them to get the job done. Someone has to facilitate that process. And it doesn't just mean the manager. So there's a few things there. I hope some of these points have run true because these are things that could happen in any team, in any workplace and often do. Variants of this scenario are probably playing out in teams right now as we speak. So we need to think about those underlying issues. There's again, it's only a short workshop here but it is an important part to think about what are we doing to address these kinds of issues because they're probably, some of these might be what's in your team as well. So just as a call out rather than a team-based discussion what have you seen? What have you used? What techniques have you employed in your team to create awesome teams? Anyone want to just call them out loud? Don't worry about the microphone we'll probably not be able to get around. Just yell them out nice and loud. Yeah. Retrospectives, doing retrospectives in a fun way. Yes. Like not the regular way. Like listing down, having a column of MVPs and rating the sprint from one to five. So making it in a fun way and using Miro boards to do some fun activities and having a fun activity R once a week to, you know, make them feel that it's not only about work, it's about building that relationship for the team. That is so important. And you said an important thing there which can be really difficult and challenging. It doesn't have to be about being staunch, serious all the time. Having some fun with it and that gamification of retro. You can definitely, there's a wonderful book for those who want to find out more about gamification of retrospectives. The book's name, you're never gonna believe it. Agile retrospectives. I know, guess what it's about. But this book is a wonderful one and there's a lot of this stuff online too. You don't have to just buy a book of gamification ways of making your retro's beyond what's worked well, what's not worked well, what are we gonna change? There's a million different ways of making it a bit more fun. And I think another important point, it doesn't have to be about work every minute because if we're gonna build trust, if we're gonna learn to, how we're gonna get along with each other, we do need to set aside some time for that getting to know you process. Exactly right. Yep. What were you thinking yet? We follow a process called team norming and storming, especially when we onboard a new team. So that through the process, we get to know each other, what are the strengths, weakness, what are they really good at doing. So that would kind of help in building the team. This is especially when you're putting up a team from scratch. Absolutely. Spending that time to kind of introduce ourselves. Fantastic. Are you gonna add? Yeah, we have been using one thing like it is something we read. We may forget what we have done, but no one will forget what we might have felt. Oh yes. So if we were connecting with empathy and not judging any individual and we clearly said that anything we are speaking, because no one is perfect, things goes wrong. So that's where we all have jobs to fix it. So when we are speaking, it is on that particular incident or the process not on any individual. So we clearly said that. So everyone stick to it. We'll not call out any of the names. What was missing? What would I mean done it? That's right. And that's a really important one for those who might know the retrospective prime directive. It's, you can look it up online. Regardless of what we find, we honestly truly believe that everyone's doing the best job that they could give the circumstances, blah, blah, blah. It's almost like we've got to make that a living breathing thing that's true, not just something that we write up. We've got to make it clear that it's about, we're all doing an amazing job here and stuff happens and it's no one fault. Let's just get on to fixing it without that. And that's a real, that's an individual choice that the team has to help reinforce. At the back there is some ideas of what makes an awesome team. So the thing is people in a team should see each other as people, get to know each other more. If they are calling each other as dev team, testing team, do away with all of that. Call each other by your names and in every ceremony try to find out what the hobbies of the other person are. That we get to know each other more. And it's a, getting to know each other, there's this weird thing in the English language. English is my second language by the way, so I just want to put it out there. There's this thing called intimacy. What is this, where is this going now? Oh my God, we're starting to change tech. No, intimacy is part of what the team needs and that is that idea that we know each other. It's not what happens behind closed bedroom doors. Intimacy is how we get to know each other and we've got to spend time to do that. That sense of I know you, I know the way you work, I know what you like, I know your communication styles, I know what's happening in your life. I know that you're, it just happened to me, my pet just died. But we, all these kinds of things, we know beyond that and we don't just say test team, dev team and that's scary in itself when you're talking agile because that means we're not working agile straight away. That's the first indication to me that there's no agile going on in that organization. It's one team and it's a squad or a guild or all those things. I think that's it. Another fifth, so the fourth there. We've got it, yeah, it's there, yep. So my warden recognition. Rewards and recognition can be frightening, fought with danger, but can be, because when we've got individual rewards and recognition, guess what happens? I wanna stump on you so I can get ahead. So be careful with that one, let's make it team-based. If it's team-based rewards and recognition, and we all share and we all get the recognition that we're doing awesome, fabulous. But be careful about incentivizing individuals in a team because that will start forcing, unfortunately, the lack of trust and the lack of transparency will unfortunately, so be careful with that one. It can be fought with danger, but I can see what could be helpful too, but team-based rewards. In a small team, of course, on a rotation base, we just try to manage. So that each individual will get in one quarter or in a month. Yeah. Some note of appreciation. Some note of appreciation, some thanksgiving. Some celebration. Celebration, yes, that's what it's all about. Celebrating success together. Fantastic, a couple of thoughts here. One thing which we have seen consistently work is praise in public and do not reprimand in public. I love this. Because typically, people who are at multi-levels when you're in a hierarchical organization or a matrixed organization, you end up, there will be, people will be making some mistakes when the similar case that happened, somebody grouped up the code or whatever it needs to be. As long as you work with levels above and tell them that just ensure that this doesn't happen again. At a project manager or anything at a level, you should stop there and take the bullets from whatever escalation's coming in and not let that impact the team. Here's how I've seen awesome teams being built and they rally behind you heavily in all situations. The moment they know that they have your back. That's right. And you're covering them, that's what they're kind of looking at from a perspective, that security aspect. And anybody who tells me that they're a team leader, they're the dev leader, they're the test leader, that means all faults are with you and all success is with everybody else in your team. And gotta be careful what you're asked for when you're a leader, because that's what leadership is. The fact is mistakes happen, it's just a matter of, they know that they'll auto-correct it generally if you behave that way. That's right. And for those in the room who say they're scrum masters, how many people think they're scrum masters? Your team is your responsibility. All their failures are your fault. True, true that. Scrum master, that is your role. Your number one priority is to make the team awesome and if they're not, it's because you haven't gone in and fixed the problem with the team. Obviously not for the team, but with the team. Last one there, and I will move on, sorry. So two experiments that we have tried. One is extension of this team building where we have taken the team outside, outbound training, so that they stay overnight. That's quite overnight. Where's this funding? Hang on, what's this team? Are you gonna jump for me? Yeah. The second one is role clarity workshops. Yes. Especially when the teams are new and they don't know what to expect from each other. So we bring the whole team, scrum masters, product owners, program managers, developers, and they call out what they expect that they should do. And we also call out what others expect from them. So it's a role clarity workshop which made them really understand each other rather than that coaches or trainers say, okay, as a scrum master, you are supposed to do this. So now they decide. My job as a scrum master is not to do the work. My job as a scrum master is to facilitate you doing the work. As a scrum master, ideally you're doing no work. True. You're enabling everybody else to do it. And that's where that facilitation is really something that's been lost in the word scrum master. Your job is to facilitate not to do. I'm gonna move on. I'm sorry, I'm just gonna put a few of these out only because we're gonna run out of time and we can definitely continue the conversation after this. So creating a shared vision, probably my number one, and that's going back to the previous problems. Social contracts, I didn't hear that too many. Anybody here heard of or use social contracts? We're gonna talk about that because that's obviously the next thing we're gonna talk about. Microsoft Teams. I have heard this and I'm just like, all right, it's a great tool that I wouldn't use it experiment. Team building activities overnight, going out bowling, whatever case might be, cooking together, try that one, hilarious. Anyway, retros, proper retros using all those tools, gamification of your retros, having rules, team rules that the team themselves bring in. I've worked in many different organizations in many different roles and I worked in a place called South Australia Water which is a government organization in South Australia Australia, if you know what I mean, Adelaide. And I walked in there and they had on the wall our team, social contract and our team rules. And I said, that's awesome, you've got that up there and everybody knows it. I said, oh, our previous scrum master put it there for us. I said, so who came up with them? Oh, she did. It's not what we mean by team rules, the rules for the team by the team. Yeah, team norms, exactly right. Team norms, team rules, facilitator, facilitation, awesome teams don't happen automatically. Someone has to facilitate and be the person who's going to be their guide and be their team slave. I often joke for those people in project management when you go from a non-agile to an agile environment as a project manager, your title changes from project manager to team slave. And that's why you've got to view this. Your job is to be a servant leader, team slave. Chartering, team charters, it's a bit like social contracts, encouragement, encouraging each other, lifting each other up, acknowledging each other, all the good stuff that has been said, coffee, drinks and all that sort of good stuff. I'm sure that you've all got that as well. Jira, yeah, I had to put up that. A shared view of work, and that's that transparency whether we're using team walls, cum bum walls, whatever it is that we're using. Sharing stories, not just user stories, but story stories. You know, last week I was doing this with that one and having that space and that time. No, not at the stand up. No, not at the sprint plan. No, but we've got to enable those structures and make it a, yes, it is safe that we can have a bit of a chat. It's okay. Yes, we've got deadlines. Yes, we want to do good work, but we've got to make some space for sharing stories. This is my favorite line, and you'll notice that it says author unknown. So I'm just going to say I made it up, but that's what the community tells you otherwise, but it does say unknown. We are most effective as a team when we can compliment each other without embarrassment and disagree without fear. Now, this is something that I live and die by when I'm working in a team or with a team as a coach, is how do we encourage these two factors? Complimenting, really complimenting in a way that isn't just ceaseless or just lip service, but truly acknowledging stuff in a meaningful way and the same thing with disagreeing. How can we disagree? Because a lack of conflict is showing a lack of trust sometimes too, and that's just a bigger problem. I think we'll talk about the dysfunctions of a team. Lack of conflict can also be a problem. So we should be able to say, no, there's a better way. Hey, I've tried this. People don't have to all 100% be on the same page, but we should be able to raise our concerns, raise our differences, voice our opinions without fearing that the team aren't going to listen or aren't going to support. So I think there's a couple of thoughts there. That's right. It can be very good. So pair programming definitely, I mean that helps that transparency too. I think there's another thought over here. It's okay. All right. So team chartering is a big one. How many of you've got team charters or social contracts, team agreements? Few of them are there. Fantastic. So it is a clear, documented definition and agreement of the team's purpose, composition, expressive ways of working to help the team remain cohesive and ensure that all team members are clear about the workout before and what success looks like. Now, if you don't have something where it's clearly documented and it's left in your head as a, yeah, we all know that. We've got this assumption. We all know that that's how we work. We all know that when we're doing a standup we only answer three questions. If we assume it without it being clearly documented, what's the problem with that? No way of testing. There's no way of saying, hang on. We agreed that in a meeting we weren't going to talk over each other. We're going to have one person speak at the time or whatever the case is. If we've got these clearly pointed out documented then there isn't a, oh, I didn't know. I didn't know that we were meant to be there. Everybody at a standup. What are those rules? You can't write them down solidly. We're going to have problems. So, hang on, I'm going to double check if I'm giving enough time because I went over in my last one and I don't want to go over without the good stuff. What is the time? 239. That means we've got, and just under an hour, is that right? Is that right? 20 minutes. No, I have gone over. All right, we're not going to do that. Team Chartering has all these things on it. I know. Ah, just because we talk too much we're having too much of a good time. I thought it was 3.30. No, it was rather 1.30, didn't we? All right, let's go into what you all came for. The team collaboration canvas. Now, you can find this online. I've left copies on the table and the copies on the table have all the information on the slides. For those tables with extra copies, great. I don't know that there was enough printed. We can get more online. And please get in touch. I can give you a copy if you don't have one. But there should be a few spares around. But it's all good. You can get this. I can send it to you. I can make this available to you. Extras, who needed one? Some spares. Who needed a spare? Yeah, over here. There's a couple there. There's one more there. It's probably just not enough to go around. I'll let you sort out who's got the spare copies. Please, we'll go through it together on the screen. And you can get a copy. Just get in touch with me. And I'll send you it. Just the printing. I don't know if there was enough printed for the number of people in the room. So my apologies there. I didn't do the printing. See, handbook, straight up. OK, so the team canvas is just like a lean canvas but with different sections. And it's all there to enable us to capture our ways of working and to help us build that awesome team. So it starts with us, funnily enough. Who is this team? For every team member, we make a few things like our names, responsibilities. Notice I said name and responsibilities, not titles. What are the things I'm going to do for the team? What are the things I'm going to do to help the team achieve work? That's what we mean by responsibilities. Nicknames and avatar. You know, an avatar is a funny little cartoon character that represents you. And a saying or a quote. I used to be called Sledgehammer. I don't know why. Maybe for I'm so subtle. I don't know. Anyhow, then this is the bit that misses and a few of the problems that you brought up before. Who are we working in and around? We don't exist as an island as a team. What are the other teams around us? What are the company stakeholders around us? What are the team and organizational rules that we must follow as a team? What are escalation points? Who are we accountable to? All of that good stuff. So it's not just about understanding who we are but understanding how we fit in to the rest of the organization and making sure that everybody knows. We work with team B and C as well and we have maybe a scrum of scrums every couple of days, whatever it might be. Importantly that shared vision. So shared vision comes in two parts. First is the purpose part. Why does our team exist? Including the value that we are delivering to our customers, the change we want to make in our organizations with our customers, et cetera. And the future we want to create. What's the impact? What do we want to see? Our team deliver happiness. Our teams deliver software people love. Our team to deliver an awesome customer experience. Our team to help people when they're dealing with insurance claims or whatever the case might be. So our purpose is more like that whole kind of high vision lofty goal. But then we break that down into measurements, objectives that we can count and we can tell how do we know that we are achieving our success. So what are those metrics and measures that we can employ that will tell us that we are achieving our mission? Oops, I'm putting it up there. So how do we track that progress? How many of your teams have something like this in your team charter? Something else I see missing. Yes, we might have a bit of a purpose, but what are those KPIs? What are those indicators that tell my team that yes, I'm on track? Maybe we need to go and run surveys with our stakeholders. Who knows what it is? So how can we gather the data to know that we're being successful? Then we've got the thing that we're working on, the product service or whatever it is that we're supporting or creating, whatever that is. What is that? What are the key capabilities? The quality and non-functional attributes. So what are the quality standards that we're maintaining with our products as well? We'll typically have them. It could be imposed externally or ones that we haven't got ourselves. And who are our customers and users? Who is our primary customer? Maybe secondary other customers who need to satisfy, but then also maybe ones around us that we might need to consider. So as a team, we've got a clear picture of who our customers are that are using, interacting and benefiting from the products and services that we're creating together. And this becomes our focal point. This becomes part of why we get up in the morning because we can service their needs. The clearer idea we have of our customer, the more likely we're gonna be able to picture what it is gonna be that we can deliver to make them happy. By definition, that should be something that you find very satisfying. I know that everybody I talk to say, half of it is when I see my product being used by my customer and seeing, yes, they love it. Yes, that makes their job better. Yes, that makes something of benefit from them. That's what's really very motivating. And our, wow, wow, way of working, wow. And I like using that term. It's come from Steve Adler, who talks a lot about agnostic agile. It's really very clearly making a list of exactly what tools and techniques, processes and procedures we use, what are those rules? What are those traditions? We had our, every Thursday we went sushi. We had a rule that if the developers, particularly developers, sometimes they don't wanna talk to people and get focused work done. So we had this tradition that if they put a baseball cap on their screen, it meant do not disturb. But they agreed that they would not be on do not disturb for more than half a day, any day. So we had this two-way rule. So how do we communicate? What are our rules around communication? There might be blackout times. I'm seeing more and more, and this is happening in Australia and I hope it's happening here. We're starting to see mail servers not send emails after 6 p.m. and they don't get delivered to the next day because the rule is an email is next day answer, not you're expected to be checking your emails every five minutes. That's very unproductive. So what are the rules around when we get messages and how we communicate, how we handle emails, what we use in JIRA, who updates JIRA? Oh my God. Don't wanna have that, I don't give it any more because it's just the biggest, it's the scrum master. I'm just gonna, for those who've ever got a coach by me, you know, it's their job. Your scrum master does all the admin. That's their job, they're enabling you because you've got better things to do. Scrum master doesn't, that's their job. Anyway, sorry, I'm just venting there. What are the meetings, what are the ceremonies, who's expected, who's facilitating, what are the roles and responsibility, decision making processes within the team? How do we decide we're gonna deploy? How do we decide that we don't need to test something? That's never gonna be the case. And what are our boundaries? What can we do and what can't we do? And that's comes to that autonomy that we talk a lot about with agile teams autonomously able to self-organize, et cetera, et cetera. And this canvas becomes that container that then allows us that if we stick to everything in this canvas, we're kind of free to do everything else. So we call out these rules and then within the rules, if everybody's abiding by them, that should put us on a good direction to having that good team set up. So rather than a team charter that you may have, and if it's anything like what I normally see, it's half a dozen dot points that are in some Confluence page somewhere, maybe. This is really calling out all the key factors that we've gotta get agreement and alignment on no matter what the answers are. Then the next two parts at the bottom are meant to be continuously looked at in the retrospective process. What are our strengths? What are the things that are helping us? What are the things internally that we're doing that is making us awesome? Whether it's skills, competencies, or practices? What are those strengths? And of course on the other side, what are our weaknesses? What do we need to improve on? What conflicts do we have? All that kind of stuff. Now, this canvas is a great tool for your retro as well. That's the intention behind it and why I came up with it is if we hold that up at the beginning of our retro, along with the premise that we know that everyone's doing an amazing job, then we can look at right, how did we go in the right in the previous sprint in the context of what we've already got there with our strengths and weaknesses and what have we agreed to do? You, after presenting this with another team, they said there should be another section on the canvas for changes that we're gonna do. Just add it in so you haven't got the chance to touch it. But you'd wanna record that as well. It's not just a retro tool. That when we're setting up a new team and just talking about inducting a new team member, we might need to alter this because a new team member means that we've got some new rules. Something else we wanna try with them. Maybe they've gone, hey, I've got this idea. And then we go, well, let's try that. So you might update this. So don't let this be a set and forget document. This is a living, breathing, capturing of how we're gonna work together to be awesome together, to hold each other's back. All the things that I talked about and we discussed in the earlier part of this workshop, this email, what was I gonna think about. So we're together talking about this stuff on a regular basis. As I said, retro is going back to what Keynote Speaker was saying, why wait for having a retro? That's awesome. That was really powerful for me. Why wait for a retro? I thought, oh, okay, so we can have this conversation at any time. That certainly is a minimum every retro. For those who've got the handout, you've got all of these points and although those points, I can definitely get it to you. So the last five minutes of this could be nearly out of time. I want you to have a look at that canvas and discuss on your teams the types of things that may go into your canvas. What might your canvas contain if you're a team working on an app? What kinds of things might you record? I know that you're working at different organizations and perhaps don't work together, but just think about a, imagine you were working together. What types of things would you add? Now don't worry about your strengths and weaknesses, but what other things might you record? Just have a quick chat through what you might put on yours. You do have a work example there, but don't worry about that. So have a quick discussion of what your canvas might contain if you're taking it back to your workplace, perhaps. Give you a quick chance to have a quick discussion of it and then we'll take questions. There's a very quick discussion. This one, oh, yeah, and also they told me it was going to be screened. I can, I can, I will. Easy to do, but we don't really need it. I'll talk about that next. All right, on the sake of I've run out of time, which never happened, unfortunately. I want to just say thank you for being here. I have definitely want to give time now to you to ask any questions or doubts that are coming up for you, anything that you want to clarify. The question that was just discussed at the back there was is this available in mural, mural, jamboard, whatever? I haven't got it and I'll tell you why because you don't kind of need it in a weird way. The document, it's really about having that discussion, how you record it, it doesn't have to be on one of those and you can set up each of these elements on the canvas. I just discussion points for you and yes, I'll put it in a canvas only because I had a lean canvas in front of me and I used that as a template, but really those nine elements are for you to think about those questions and make sure that the team has had the opportunity to discuss and confirm and capture them. Now, whether you capture them in a conference page, whether you capture them on a poster on a wall, whether you put them in a jamboard or a mural does not matter, but I'm more than happy to create some sort of template. I certainly have what I've distributed for those who've got a hard copy. I have the PDF of that, but that's easy for me to translate into, I'm a jamboarder because then you don't need to worry about licensing, but I can make a soft copy available, but it's really the same as what the, it's really that conversations there. But thank you for asking about that. And really this is, I only want this to be used as a guideline so you can facilitate that conversation and for those with that dreaded title of Scrum Master. This is a tool for you to facilitate the rest of the team talking about and ensuring that you're making sure that there is agreement and alignment there. And there's a wonderful point made, and I'm sorry, I didn't get your name, the point you just mentioned to me, that creating an alliance. That's what it's all about. And this is a document to ensure that we can, don't leave it to an assumption that we're aligned, we make it clear so we can point to it when we've deviated from it and reviewed. So questions and comments, go ahead. So this is a beautiful canvas and I look forward to customizing this canvas. For example, what I've found that goals and objectives. So it could actually be mapping it to an OKR kind of stuff. So I can actually have for this particular team, could be actually be working on one of the key areas, result areas. And then that would only be just one single metric to track for the quarter. So this canvas could also be updated along with the team for a quarter rather than just saying, like only in the retrospective or only, and this could actually serve as a beautiful tool and even in that, because your stakeholder sometimes can change. That's it. So your product definition itself could actually be changing because if you're working on a platform, you might be working on different areas. That's well said. And that's exactly my intention. It's not a static tool as team changes, as we get new goals, as we get new projects, as we get new teams, because the teams might be spanned and we get a new team. But I love that, updating it with the OKRs and the overall. Yeah. And even when you're beginning with a new team, the team itself can use this as a facilitation tool itself over there as a ice breaker. So let the teams know each other. Remember, when you're at the end of it, they can say, OK, as a team, we are already seeing that these are the strengths within us in terms of skills. And this is the area which we would want to work on. So even at the beginning, also, it makes a lot of... Yeah, and that's why I put that bit of fun of what's my nickname, what's my avatar, what's my quote. They're little things that can help break the ice and it can be used, as you said, as that tool as a new team to break the ice and do this as a set aside, not 10 minutes, set aside a couple of hours and furnish the team with lots of food and drink to do it with. So we can really talk this stuff out. Yeah, nice. Thank you. Thank you, thank you. Oh, over here, we'll get... There's another mic somewhere. Yep. So how do we validate... See, we were speaking about the current state and the target state, behavioral aspects, right? I love this question. So how do we validate how we are improving, especially quantitatively? Qualitatively, we'll discuss, but qualitatively. It takes up measurement. Yes, so how do we validate? Well, we ask our team. You know, as part of that continuous discussion, whether it's a retrospective or not, is are we acting in a way that reflects what we have agreed to? And the team should also be saying yes, unless you're qualitatively, and you're quantitatively in a way because the elements on here should be both quantitative and qualitative. That's why I deliberately set goals and objectives, one being qualitative, which is a big kind of stuff and then how the metrics are. But part of that goals and objectives is we've got to make sure that that section has... What are the measures of we knowing that we're achieving what we intend, but then we should be looking at it as a retro, perhaps every retrospective we might bring it up and saying, is there anything that anyone's noticed in this sprint that doesn't align to what we've already put up there and start there? Maybe it is a case of quickly reviewing it as the beginning of a retro, but that becomes a bit too repetitive and then it becomes too... People just ignore it. So that is definitely a tool I expect that should be looked at as that tool to focus a retro on. When we say what's working well, is it the stuff that's still on here and how can we modify it? But yeah, we do need to make sure that as a team we're reflecting back and it doesn't just become something that becomes obsolete. A few other questions over here? Yes? It's not like every retrospective we need to check, right? So any recommendation? Yeah, the team I used it for, we had it visible. It was actually on a wall and we just asked the question in the retro, is there anyone got a concern with anything that we've previously agreed that they don't think needs to change or we didn't do well on? So rather than it being we need to go through the whole thing, it was just that quick. Anybody want to raise a concern on that? They want to change something. So it was available at any time. But just like sum it up, like in every retrospective we can just bring it once and see if anyone has anything, we can have a conversation. That's it, that's it, yeah. And in retrospective, another thing I'm very passionate about, I love my retro, I used to call the retro a quaint sort of good reason, if my retro ends without a clear task list and people agreeing to do things, something's gone wrong, a retro should have result in an action plan that forms the input into your next sprint planning session because those countermeasures from your retro must be added to your sprint plan. And if it isn't, something's gone wrong and your scrum master needs to come talk to me. Ah, I try a lot of scrum masters and the ones that I try and know. Anyway, let's just make some names. Yep. So this team collaboration converse like can be applied into scenarios, one the team when it's new or one another one, an existing team where you can also ask them. Yes. So we can always expect resistance when we try to do for an existing team, why we know, we have been knowing each other, we have been working each other for almost a year, why do you want to suggest this as a change agent or as a coach when we try to implement this or suggest this basically. So in your experience, what kind of resistance like you have heard, especially from this experience team and how you have addressed that? A lot of people don't want to, what's the word? There's a bit of fear going on usually. We don't want to document it because when it's documented, then we've got something we can point to it and then there's suddenly people who perhaps were hiding or getting away with bad things now can't. I would want to lean into that and say, what is the issue here? Why is this a problem doing it? And I also might think that if I've got a team that's been working together for a lot of time and they don't have any issues and they are highly productive and highly effective and everyone's happy, maybe it's not necessary to, it's not like we should impose it, but it's certainly a tool to foster that continuous improvement mindset because no matter how awesome your team is, I guarantee you there'll be a way you can lift it. There's always something better you can do. So I would want to find out what, if there is an individual, because it's usually one or two individuals that say, this is rubbish, we all know this stuff, this is a waste of time. I'd want to find out what particular concerns you, why do you think it's a waste of time? If they say we've already been done, so there's absolutely nothing in this team that needs to be addressed to no problems to be solved, no improvements to be made. And really that will, as soon as you kind of frame it in that way, but I wouldn't make it, perhaps with existing teams, I'd sort of be cautious, but yeah, I think it's a good tool. If you haven't got this stuff called out, just ask them. Thank you, thank you. All right, I think we're being kicked out of here. I've got a couple of Aussie hats who'd like to join the Australian cricket team. I know I've got a few key contributors, I'm looking for that, I'll ask you. And please don't leave any koalas or kangaroos behind, they get lonely and they cry. So please share them out, I hope everyone's got a little Aussie souvenir, as well as that canvas. I'm just gonna put this on the back. This is me, find me on LinkedIn, I am on no other social media, I don't waste my time. But I am on LinkedIn, so find me on LinkedIn, contacting me by email. I can send you copies of the canvas, and I'm more than happy to continue the conversation. Thank you all for being here, I hope it's been insightful, useful, and you can go away and use this canvas with your teams tomorrow, all the very best. Thank you, thank you, I'll just unplug.