 It's a magic mic that doesn't work when I speak into it. So welcome, my name is Angie Doyle. I'm an Agile coach from South Africa. I've been working in Agile teams for about 10 years. Hi, my name is Talia Lancaster. I'm also an Agile coach. I work for one of the top three banks in South Africa by day, and then by night I have a graphic recording company. So I do visualizations for companies. So how many of you have heard of high-performing teams? I want you to stand up if you've heard of high-performing teams. High-performance teams. Okay, awesome. So most people have heard of high-performance teams. It's even been mentioned today, so that's a good sign. Now, stay standing if you've ever been part of a high-performance team. So it doesn't have to be work. It could be like a social committee. It could be a religious group. It could be the military. So if you've ever been part of a high-performance team, you can stay standing. So there's quite a few of you. I want to know what are the behaviors that you saw in these high-performing teams? So just kind of throw out a couple of behaviors that you saw. Okay, so transparency. Shared goals. Shared goals and responsibilities. What else? Commitment and focus. Maybe another two more. Okay, openness, willingness to kind of embrace new stuff. What else? One more. So they're biased for execution. They're kind of focused on delivery. Okay, great. Okay, so stay standing for a second. We're going to run a different experiment, right? So stay standing if the team was a work team. Okay? If the team that you were part of was a work team. Okay? A work team. So what do you work with? Yeah. Okay, cool. So we've lost a few. And now stay standing if that team that you were part of that was high-performance was an agile team. Awesome, that's good. Okay, so it's interesting because not all agile teams are necessarily high-performance. So what we're talking about today is how to build that intentional culture of high-performance. You can grab a seat. You don't have to stay standing for the rest of it. Thank you for your participation. So like Talia said, we don't want to leave creating an environment for high-performance to chance. We want to be incredibly intentional about creating a culture where teams can accelerate to high-performance really quickly. Otherwise it actually takes them a really long time. So those teams that you were working with, chances are you probably worked with each other for more than six months to about two years. That's actually when you start building up the levels of trust to get you to high-performance. So we found that when we lift off teams, their ability to get to high-performance is significantly faster. And we initially did it with some random techniques that we used with our teams on what kind of felt right at the time. And eventually we came across something called the team canvas. So this isn't our canvas, but it's something that basically captured every bit about what we do in our team liftoffs. So we're gonna work through techniques for each of those different segments as part of today. Now you're not gonna do, we don't have enough time to do every single activity for every single section. So we're gonna talk through the first half of the canvas and just give you an idea of some of the techniques. And then we're gonna take you through another three techniques and you'll have an opportunity to practice one of them before the end of the workshop. And you'll notice that the slides, the booklets in front of you don't look like the slides up here. And that's because we've actually given you these techniques and more in your books. So you're welcome if we don't have an opportunity to practice, you can just take it back with you and practice them with your teams back home as well. Maybe an important point to mention is that this usually takes about two days. Okay, so we're gonna kind of skim through it and just maybe give you some inspiration for things that you can do. And it is also separate from your product liftoff. So this is focusing on the team, the team dynamic, roles and responsibilities, some of the words that were mentioned earlier. A product liftoff would be separate. So your product liftoff would tend to take another three days on top of a team liftoff. So in total, when we liftoff teams, we look at getting a week, which is a huge investment for companies, but we've actually started getting enough data to show them the value behind doing this. So we're gonna kick off with that little heart, like the center of the team canvas. If you ever need to refer back to it, the team canvas is in the front of your booklet. Okay, so our click is not working, so I'm just gonna have to... Okay, so the center of the canvas, the center of the canvas is the purpose for the team. So this is why are we doing what we're doing? Why does the team exist? In the background, there's a very beautiful video playing of a non-profit organization in South Africa, and we're using this more of an example of things you can do with your teams, okay? So it doesn't have to be as beautifully produced as this, but you can actually use videos to connect your teams with the purpose. So you could take video footage just on your phone of the customers or the people that you're serving, and use that in some of your events to reconnect your team with why they exist. There are also other techniques in your book. So this one is a Jeffrey Moore. It's actually based on the product kind of purpose, product vision model, and we've adapted it for teams. So Angie and I also love visuals as you could maybe tell. So this is a poster that we created for a team that we actually worked through to define the purpose. There's some other techniques as well in your booklet. So we're gonna move on to the next part of the canvas, which is people and roles, and this is essentially trying to figure out who do we have in our team, what are our names, what are our roles, and what are our responsibilities. Now I'm assuming since we had an Agile conference, everybody here is working with Agile teams. Is that an accurate assumption? Okay, so we all know that in a framework like Scrum, there's not meant to be any roles, right? You meant to have a development team. And what we've noticed, and I don't know if it's the same in India, but we'll create a team and people will still have baggage associated to the role that they came across with. So there used to be a business analyst and there's this expectation of what business analysts are meant to do. Well, there used to be a tester and there's an assumption that the rest of the team has about what they're going to only be doing in a team. Now the problem is when we make assumptions about roles, what tends to happen? If we get it wrong, there's usually conflict, right? We're like, why didn't you do this thing? You did it before when you were a BA. You should still be doing that same thing now. And you're like, but I'm not a BA anymore. I'm now part of the team and we're sharing responsibilities. So what we want to do as part of this people and roles section is we want to get rid of any hidden assumptions in a team because that is where most of your conflict is going to lie. So we came up with the technique and we've run it with numerous teams and it tends to work pretty well. How we start off with is we'll put, we'll put a whole bunch of these posters up on the walls around a room and we will put, we'll ask people to write down their role that they came across with. So we're going to use the Scrum Master as an example here. We then ask them to go stand at a different poster and they start writing down what they think the roles and responsibilities are for that role or for that title. So we'll put down a whole bunch of stuff. We'll give them about five minutes to do it on the first poster. Then they'll shift to the next role in the team. So they never go visit their own poster. They're always visiting somebody else's poster role. So we'll systematically go through. Someone else will come up, we'll do some more and eventually the whole team has made it through every single role and what we do is we just reduce the amount of time that you're spending at each poster because you're pretty much only writing stuff down that isn't there already. And at the end what we do is the person whose role it is will come and start having a look at what other people think they are going to be doing in the team. And they'll say, yeah, this one looks pretty good. I agree with that one. This one looks like my role, absolutely. I don't do this. And then how do you think we sorted out as a team? So where we have disagreements over the roles, what do you think we should do? Probably discuss it, right? Because this is our opportunity. I mean, it actually came up this morning in the keynote for Holacracy, where they were talking about making expectations absolutely explicit. This is what we're doing. We're now saying, I don't do this, but it probably needs to be done in the team so who is going to do it? Or if I'm going to do it, I'm not happy with how it's worded. So we might then just change the wording to something I'm more comfortable with. And how we ended off is we usually sign it because it's a little bit like your contract with the team. It's like the signing is like a superficial thing. It's like, I'm committing to do this stuff. And this is kind of a finished product that we had with one of our teams. The scrum master was Annalinda. And you can see there's something, there's a lot of ticks here. If you can't see it at the back, there's like four ticks against something. And she was absolutely determined that she was not a PA as a scrum master because in the team they were like, maybe she does our bookings and our minutes and stuff like that. And over here, she disagreed that she would need to make sure that the design questions get raised timeously. So once we've cycled through the team and everybody's had an opportunity to clarify their role and their responsibilities, we're one step closer to actually working as a functioning, high-performing team. I'm gonna give the mouse one more try. Let's see. Nope, okay, thanks. Okay, so now that we've defined the roles and the responsibilities, we actually wanna take it a step further. So we wanna look at the strengths and weaknesses, the strengths and assets, and weaknesses and risks for the team. Okay, so this is slightly different from roles, but a technique that we find works very well. It's actually a management 3.0 technique. It's called the competency matrix. So what you do is you make a nice grid like this. I always get confused. This is a column, right? Okay, so the first column, you're gonna actually start writing down the skills that you need in a team. Okay, so let's maybe get some examples. So let's assume that we are a software development team. What are some of the skills that we may need in that team? Functional, okay, so I'm gonna put coding because that's an easy one. What kind? Cool, okay, so JavaScript. Are there any other languages that you need in that team? Okay, so this is a mobile app team. Cool, what else? Analysis, I heard design. So design, you might also wanna say is it UX, is it UI? Okay, UI. Let's also put UX here as a separate one because some people may be strong in UI but not strong in UX. Testing, cool. What about other skills that may not be completely technical but might be softer skills? Product management. So this is an interesting one, right? Because we're looking at skills, not roles. So what does a product owner do? Value maximization, collaboration. Okay, so you may wanna... Stakeholder management. Wanna put your stake management. Okay, so remember you wanna stick to the roles. So instead of putting their scrum master, what are the, I mean stick to the skills. What are the skills that, so maybe it's coaching, maybe it's facilitation. It's these kind of skills that you actually need in the team. Why do you think we do that and we don't put roles? 100%. Yeah. Yeah, and maybe you've got a developer who's strong in facilitation. So this is an opportunity to get a really clear view of the skills that you have in the team. Okay, cool. Now what you do is on the top row, you're gonna put your team name. So we've got a very sad team because it's just Angie and I. Okay, so for now we're just gonna keep it to that. Yeah, I don't know, I don't know if we can build this app. And then another layer to add onto this is to actually distinguish between level of competence. So here we've got advanced, intermediate, and novice. So each person will then go down the list of skills and indicate what skills they have and over and above that as well, what level. Okay, so we're just doing this as an example. Our team is very sad. Can I do analysis, probably? Okay, so you're gonna go through and you're gonna indicate kind of where you're sitting in terms of that skills within your team. The value of this comes in using this for various ways, right? So firstly, you're gonna look at your strengths. So you could say, okay, green and blue are quite high. So Angie and I are actually really good at facilitation. So we're pretty strong there. However, neither of us can do stakeholder management. So that's actually a risk. If that's a skill that you require in the team, best we find someone else who can do it. Yeah. See, we didn't wanna lie. We really can't do this JavaScript. Okay, so we really can't do JavaScript. So that's also a big risk. There's gonna be no app. We'll have lots of facilitated workshops, but. Okay, and then what we do as well is we actually indicate there, we ask people to indicate things that they really don't enjoy doing. Okay, so maybe Angie's pretty good at UI, but she actually hates it. So she's gonna put on a sad face. I don't really like analysis. Okay, why do you think we do that? So cool. So maybe that person does it just because they're good at it or they know it. If that person does this every day for years, do you think they'll enjoy being part of that team? No, exactly. So that's something that you then need to look at, upskilling other people in the team or getting someone else so that that person is not doing something that they hate every day. Okay. Cool, so that's your strengths and assets, weaknesses and risks. And then there's an example of one that we actually did with the team. So you can see it's substantially larger than our sad little team. And it's a really great tool to use even for succession planning, interests, you could find a way maybe to indicate there what interests people have in terms of upskilling. So it's a very powerful tool this for your team. Getting this. Now that we know who's in the team and what skills we have, we wanna figure out how do we communicate and keep everybody in the team up to date. So this is probably what you're the most familiar with in teams. This is your typical working agreements that you'd see in agile teams. So we were in a talk earlier, he referred to it as a social contract. Usually for the teams that we see, working agreements tend to look a little bit more like this. So they've got things like your team name. And I don't know if it's the same here, but we usually, it's quite related to pop culture. So Captain Marvel's coming out, like if we started with the team, it would be like the Avengers and someone would be Captain Marvel and someone else would be Captain America and they'd actually kind of cycle through. But they're tied into the team name so that you're not landing up being the asset finance replacement system team or like something terrible like that. Cool. And then you're also gonna discuss things like your method of collaboration. So what tools are you gonna use to communicate with each other? Are you gonna use Slack? Are you gonna use Zoom? And it's important to make sure that everyone in the team has access to that tool. So the last thing you want is people battling to get in and to actually collaborate with the rest of the team. So speaking about collaboration, something that we do in South Africa a lot as well is we collaborate with a lot of teams in India. So we've got quite a hot topic that we have to have conversations about with our boards. So do we have a virtual board or do we have a physical board or do we have some kind of a hybrid between us where in India our team has a physical board in South Africa, we have a physical one and we have a high level one and some kind of a collaboration tool. And we've gotta make sure we can all access that because I don't know if you guys have experienced it but a lot of companies block access to a lot of these tools. It's like we worked with one team where all we had was Google, Google Sheets. That's all we could collaborate with and then they took it away from us. Okay, and then it's very important as well to discuss things like your core working hours. And these are often the things that we don't really think about but it's important to identify if people have possibly commitments or special kind of times that we need to consider. So in South Africa, we actually have a very multicultural and we have multiple religions within our teams. So for example, this is a point where you say, okay, but I'm Jewish, I need to leave early on a Friday for Shabbat dinner, I need to be home before sunset. So please don't schedule meetings late on a Friday afternoon. A, because it's really not a nice thing to do. Like we shouldn't be doing that anyway. And B, because there is a particular religious kind of consideration. And it's important. It may not be important to, or other people in the team may not realize it, but to that individual, it's really gonna make a difference. Okay, and there's other stuff. So Adam Wisebot's got a really cool guide that you can go through. We're not gonna touch on all of them, but definition of ready, definition of done, team calendar, all of these things that we generally do in the working agreement. Possibly the one thing that we see a lot of teams don't do is focusing on a conflict protocol. Now, especially when we first create a team, it's like you're in that honeymoon period, it's like you're never gonna have a fight, nothing's ever gonna go wrong. And we've actually gotta figure out our divorce agreement before we even go on our first date. Because at some point, there is going to be conflict in the team, and we've gotta figure out how do we handle it when it does come up? Because when is the worst part or the worst point to start handling conflict? It's when you're in the middle of the conflict. So this could be something as silly, and what we usually do with teams is we literally just come up with a safe word initially until they build up a higher level of trust. So a safe word will be a word that someone will call out, and when we hear it, we have an agreement that we break for five minutes, you are not allowed to continue with that conversation, everybody leaves the room, you come back in five minutes or 15 minutes, and you agree on how to proceed. And sometimes how you proceed is you have that conversation the next day, once everybody's had an opportunity to kind of regain all of their skills. Because when you're in conflict and it feels super hectic, you don't want to then still continue with that conversation. So something as simple as a safe word kind of gets teams set up on the right track initially, and eventually we actually build up quite a detailed conflict protocol with our teams. But this is something we see so few teams doing in the agile space, and there is conflict, like it's high pressure. So it is something we should focus on. Yeah, go for it. So that's really boards. So like, do we have physical boards? Do we, when we're collaborating on requirements, or we may be visualizing our models? And if we're doing that and we've got distributed teams, how are we gonna bring them in? So we have to do a lot of whiteboard collaboration, but we can't do it in a room because we're working with distributed teams. So like what tools are we gonna use? Do we have access to them, that kind of thing? Happy with that? Yeah, yeah, so the safe word, and then breaking for five minutes is a good one initially. One safe built up trust. We start introducing things like having a soft startup. So a soft startup is where you know it's gonna be a tricky conversation and you know it's probably could offend someone. So how you enter the conversation is really important. And we'll actually say, I'm gonna try a soft startup and it kind of gets the other person, okay I know you're trying to make something a bit softer, so I'm gonna try not to take it too personally initially. But that kind of thing you can't do with people that have only just started working with each other. It takes time to build up trust to kind of get to that point. So we usually put like a quick and dirty fix in with that safe word initially. And then after about three to five sprints, we'll start bringing in a more substantial conflict agreement where we actually talk about when we enter a conflict situation, how do we speak to each other, what are the no-go areas? So what am I, we also often will unpack what is a no-go for you, what are you not prepared to negotiate on and what are not prepared to negotiate on. But our next one actually talks about what's acceptable behavior in a team which actually leads into your conflict protocol as well. This is just again, it's visual, so it's just an example of how we build up these agreements so that it's not one person, usually the scrum master sitting and typing up the stuff in a PowerPoint when some kind of a system. Okay, so the next section, so now that we know kind of our ground rules as a team, we're gonna delve into some of the activities that are a bit deeper. So the last three that we're gonna cover now on the canvas, you will actually have an opportunity to practice one of them. So these are one of the activities, okay? So values maybe to that point, it's what do we stand for and how do we show it? So how many of you have values in your companies? Yeah, everyone, hey? They have those nice words on the wall, like integrity, trust, respect. Yeah, so one of the things with values is because those words are so big, sometimes it's difficult to actually understand the behavior that we need to live every day. So it's not enough for us to just have a value, we need to actually unpack to a lower level around the behaviors. So a good example in South Africa is the word respect. So in kind of like Western cultures, respect is things like if someone very important comes into a room, you stand up and you look at them in the eye. Whereas in Zulu culture, it's extremely disrespectful to look at someone older than you or more senior than you in the eye. So what sometimes happens is there's this miscommunication around behaviors because people are kind of sitting down as you enter the room or they're avoiding eye contact and in their culture, they're actually being extremely respectful but to the other person, they may not interpret it that way. So what we encourage with teams is actually identifying your values and then unpacking the behaviors around that value. So what we do, so we actually start off with a big values list. It's also a management 3.0 technique so there are lots of values on this. Angie and I tried to count, I think they're about 200 but it's a good place to start. So what we do is in the teams, you each have an opportunity as an individual to just skim through that list and circle your top five values. We've run this a couple of times where people take quite long to do this. The trick is here to just skim. So if you don't kind of connect with a word then it's probably not your value. So you're going to identify the words that you really connect with as an individual. What we sometimes do to kind of save time on this exercise depending on how long we've got to lift off a team is we might actually just go with a scrum value. So we'll go with respect, collaboration, commitment, focus and openness. Cool, so then once you've done that you're going to consolidate it onto one list, okay? So that foo spot is individual. Then you're going to actually take a piece of paper, so a A3 piece of paper and you're going to go around the circle and kind of start writing down your individual values so you have one list of all of your top values. You then going to use dot voting. Do you guys use dot voting? It's a very, yeah, I think, yeah, he's preaching to the converted, yeah, okay? So dot voting is like currency, three dots, use them as you like. Try not to vote for the values, try not to vote only for your values. So you're trying to pick values that are best for the team. Yeah, okay, so you're going to vote and then from there you're going to get your top three to five values for the team. And then what we do, which is really fun is we actually create this poster. So on the top there, the atmosphere section is your values. So that's three to five values for the team and atmosphere is almost like the perfume of the room. So it's something that you can kind of sense, but you may not be able to, it's not tangible, okay? That's how you want people to feel in the team. And then around the edges, these strips of colorful paper and those are actually your behaviors. So after you've done the values, you then pair up and you start to unpack how do we live those values every day? So we work best together when? And you write a whole bunch of statements. So what you're not going to write is something like we work best together when we respect each other, okay? Because that's obvious, what does respect mean? So what is the behavior that we're looking for? And that could be things like, I know in a lot of the teams that we work with, they say respect is being for meetings on time. Because that's how you demonstrate that you respect my time as much as you respect yours. So that would be a behavior that if your value was respect, that could be a behavior that would come out of the conversation. Thanks. And then, yeah, so then you end up with this beautiful poster, it's nice and visual. So you can actually put it up near your team so it reminds everyone. And it is a living artifact. So you can keep adding and assessing those behaviors as you go. Okay, so now we know what we really stand for and believe in and how we're going to show it to other people. We want to know how are we as a group going to achieve things together, certain goals together? And what do I as an individual want to achieve? So there's two different types of goals on the team canvas. There's a common goal, that's a team goal. And usually those are the things that get converted into metrics and companies. It's the kind of things that they'll put a metric in and they'll say, if you achieve these goals, we know that you are successful. But there's also the personal goals side. And so often we forget about people in a team have personal goals to you. So I'm going to use an example of a team we worked with where there was a business analyst who was trying to become a CBAP, which is a certified business analyst professional. And he was lacking on some of the knowledge areas that he needed to submit his application. So he was very eager about getting stuck in to certain types of work. Now, if he hadn't made that goal explicit with the team, they would have thought he was, I don't know, jockeying for some kind of a position. Or that there was an ulterior motive. Like, why does this guy only want to do this kind of work and he never wants to jump in and help out with other stuff? But by making that personal goal absolutely explicit that this was a career path for him and something that he had chosen, the team were a lot more flexible in saying, this is the kind of work we've got. It sounds like that work that you need to get the certification. Do you want to do it so it can go on your portfolio of evidence? So it's the two types, the team goal and then the personal goal. And how we do this in teams is we find it really hard to come up with goals. I don't know if you found that as well. They tend to be like these beauty queen statements like I want world peace or something like that. Like they're very high level. They're not tangible enough. You're like, what do you mean by this thing? And everybody has heard of smart goals, right? But we tend to do it so badly. So we'll go through smart and then we'll show you what we've actually done. It's a different technique that we've come up for that we do with our teams. So your typical smart, so specific. We want to be specific about what we want to achieve. So there we typically go into what, why, when not usually the how, that's going to be something we're going to unpack in more detail in the sprints but we try to get really clear about what it is we're trying to do. Okay, and then the M is for measurable. So this is your metrics. So it's important when setting goals to understand kind of where are you at currently? So what's that baseline metric? And then how do we know that we've achieved what we're trying to achieve? So kind of what is that metric for success? The A achievable. So can we actually visualize the path? And I think we don't want it to be super easy because I think that just encourages like teams to be really average. And we're looking for high performance. So we want these things to be challenging but they still need to be within grasp. So I always say like, I think a better word there would be feasible. Is it a feasible thing? But then it wouldn't say smart. I would say like smrift or something like that. And it wouldn't be quite as catchy. So achievable, can we actually do it as a team? Okay, and then relevant. So that's actually a time for you to assess if it's in line with the organizational strategy. So is this goal actually relevant for what we try to do as a company? And I think this is also important. We don't just set goals blindly. Let's critique it and let's be very critical of the strategic alignment. Time bound is super important in agile teams because goals that go too far into the future are immediately unachievable because they're probably too big to break down into something we could deliver in a sprint. So when we talk about time frames, what could we do in a year? What could we do in six months? What could we do in three months? What could we do in six weeks? What could we start tomorrow? So actually be quite mindful about kind of having these small iterations that we can deliver on. So that's great, but it's not enough for agile teams. There needs to be a feedback loop. Okay, so we've added, we're gonna make smart goals even smarter. So we've added in that almost that inspect and adapt element to it. So E would be evaluate and this is an opportunity for you to look at your goal and see maybe you've achieved the goal and that's great, but you need to go back and check or maybe that goal's no longer relevant. So the R would then be to rethink. So rethink or reset. If you've achieved your goal, then reset a new one or if your goal's no longer relevant then create a new one from scratch. So we played around with it and we came up with a canvas. Talia and I have this really corny joke about canvases that's so hot right now. Everybody wants a canvas for everything. So this is our canvas for smarter goals. But we've actually also in the process of creating a game for this. So there's a game that we actually have started playing with teams and we've busy ironing out like the final details to make it a little, like even more collaborative than it already is. And essentially this is one of the teams that we worked with. So I just rewrote it because the original version was super messy but it was really about how does the team increase blog traffic and after unpacking all of the different questions underneath the smart, the different specific measurable achievable relevance and time bound, we landed up with a revised goal statement. So we started there where it says initial goal statement, increase blog traffic. And the revised goal statement says, you can see it was a while ago by the 31st of March, our blog will see a 10% increase in traffic by increasing our weekly publishing frequency from three posts per week to five posts per week. Okay, so this again, it's just something to get the team, actually collaboratively do this and then you land up with something that's revised and we start converting it into metrics after this. So the activity, if you choose to do this one a bit later, you'll do a personal goal because you're probably not sitting in a team or at a table with people that you work with. So you would actually just change it into a personal goal, something that you would want to share with the team so that they can understand some of your behavior. Yeah, it's a team goal. So your team should be delivering a product. Your product metrics are going to be slightly different to your team metrics. So if you had increased sales by X percentage, you could still use the same format, but what we're looking for is how are we actually going to do it as a team as well? So you could bring in product related goals but also bring in your team goals because they are going to be slightly different to what your broader organization is going to be expecting of your team. This is almost on what do you expect of each other to get to the next step? Are you happy with that? You didn't look happy with my answer. So now that we've gone through the rest of the canvas, we're now at what is probably the hardest part for teams to deal with. And this is really what each of us need in order to be satisfied and feel whole in a team because you do have needs. You've got personal needs that have to be fulfilled in a team and very often we brush over this kind of thing. When we do our liftoffs with teams, we very often don't do this as part of the liftoff. We give the teams some time to actually get to know each other because this is quite deeply personal. It's not the kind of thing you're just going to blur it out with people and say, this is what I need to feel like a whole person. You know, you need to actually see if it's, you need to create that safe space before we even get into this conversation. Once we do, we usually do this as part of a retrospective and we play a bit of a game with the teams. So we came up, I don't know if you've ever heard of the Center for Nonviolent Communication. It's quite an interesting website. Go check it out. There's a lot of things about feelings and needs in there. And we use their list of needs and we identified a common set of 10 needs that most teams need. So you can see we just created like little playing cards and we came up with the top 10 and all you do is you just order them in importance for you. So you'll put them from left to right on a table or from top to bottom in order of priority and you'll land up with a sequence of needs that's relevant to you as an individual. The other thing I forgot to mention about this game is you do it in silence. You actually don't talk at all when you're playing this game. This is a silent game because talking kind of eliminates the opportunities for introverts to have an opportunity, like to start thinking. Okay, introverts tend to need silence to think about stuff, to have confidence to say something extroverts need to speak. Very often this gives you an idea of what you wanna say as an extrovert. So it kind of levels the playing fields for everyone. And then if we don't have your needs, there's some spare cards, it's like a gift card where you can write down your own need that isn't represented in the pack. So you order them down and you land up with a prioritized list and at the top you're gonna have your top three to five needs. And then we write something it's almost a bit like a user story. So we'll say something like as Angie, I need the space to be creative. So I request from the team the opportunity to include visual elements in our requirement discussions. Okay, so I'm telling the team that I need a creative space. Because if I don't get the opportunity to draw stuff up on walls and have those kinds of conversations, I'm not gonna be satisfied during the work that I do. Now if I don't tell the team that I need this and I keep picking up pins and drawing models on walls, it's gonna look pretty self-indulgent. You know, I'm gonna, oh, this trick all she wants to do is like draw stuff on walls. But if I told them that it's something that keeps me fulfilled as a person, teams tend to be a little more open to that. So we write these needs cards down, you can write down as many as you want for as many needs as you want. And what you do is you then pass the pack of the needs cards to the person to the left of you and they read through it. And if they've got a question, like if they're not sure what you are asking of them, they might write down a question on a post-it note and just say I'm not really sure what you're asking of me to help you satisfy this need. The idea isn't that you question that person's need, a need is a need and that's not, like it's not under debate for other people. But you're kind of saying this is what I need from you to help me achieve this need. Well, this is what I expect to kind of see in the team. And then very often what happens is this becomes one of those we work best together win statements on our atmosphere poster. So we'll actually add in some more behaviors that we wanna introduce in the team that'll start helping to create that space where people can satisfy their needs at work. Because if you're not getting this fulfillment out of your team, I mean you're spending most of your life with your team. You're not spending it with your family. So you wanna make sure that this stuff is clear because you wanna be fulfilled and a whole person when you go to work. This is quite a, it is quite a sensitive exercise, but it's incredibly valuable. So once we get to this level in a team, we sort of know we've reached that point of almost being kind of high performance. We've now really laid the groundwork well. We recommend doing the needs after the team's been running for a couple of sprints. Purely because if you haven't created a good safe space, you're gonna get very superficial needs that'll come out of the team. And we want people to be real with this. This is the stuff that's gonna make them love being in the team. So we suggest doing it after. If you've already with a team and you're just going through the team canvas because we do that when we kick off, so we do the team canvas when we kick off teams and when teams need a little bit of a kick start. So they're kind of in a bit of a, like a bit of a rut. Then we'll do a team lift off with them again and then we'll bring this in because they already know each other well enough to have confidence to do this exercise. But this tends to be a little bit edgy for a lot of people when they're first start in a team, not initially. And give them the heads up that you'll get to it in about three to five sprints. So when it comes in in the retrospective, they know it's coming. Okay. So I'll be honest, I haven't come across, so the question was, how do you handle unrealistic, unreasonable needs? You would have a conversation as a team. That's why it's so important to have the high trust level. So if someone's asking something of the team that the team can't provide, usually the team will say we can't do all of that. That's a non-negotiable, but we can do this part. And then it would be a case of like, is it good enough? And do you feel like we've heard your need? Because we, none of us don't want people to feel fulfilled at work. We all want to create that space. Well, I think we do. Most of the, I'd say every team I've worked with wants to have a great environment to walk into. So people tend to be quite flexible, but very often they don't know what you're expecting of them. Okay. Yes, absolutely. So if we don't get, so the question was, can this be part of a retrospective? If we don't get our two days to lift off a team, what we will then do is we'll ask for either half a day or a full day. And everything that we haven't got around to will bring in as a retrospective within the first couple of sprints. So we'll then kind of determine with the team, what's the next most important thing to do with them? And we'll bring that technique in. So over time we build it up. And you always revisit it as well. I think it's different to a retrospective where a retrospective would be looking back. This is almost looking forward, saying how do we want to move forward? How do we want to be an awesome team? Yeah. So you could identify something in a retrospective where maybe we're not behaving, we're not living the values that we said we were those I work best together when statements. And you could maybe bring it in and just reinforce it with the team. Yeah. You know, Scrum Masters and that you may be able to identify behaviors that would benefit from some of these techniques. You know what I mean? So even if you've done the lift off, there's no reason why you can't bring in one or two that seem relevant to the team in a retro. So there can be almost like standalone activities. Okay, we've done a lot of talking. So it's now an opportunity to practice some of the techniques. So it's important to Angie and I that we create a safe space where you guys can practice so that hopefully when you go back to your teams, you feel comfortable to run some of these with your teams. So we've got, we've prepared three activities. It was the last three sections that we covered. So the first one is the do-it-yourself values. That's the one with the cloud poster and the colorful paper. And then the needs. Yeah. Yeah. And then the next one is the needs and expectations card game, which is the one that Angie's just explained. It's a bit more challenging and deep, but it's a great place here for you to practice it and see what you think of the technique. Because here, chances are you may not have to work with that person going forward. So you can really be open and honest and see the technique itself. And then the last one is maybe it's kind of towards the end of the day. Maybe you're feeling a little bit antisocial. So the last one is the smarter goals canvas. But we want to actually run it as a personal goals exercise. The challenge is a lot of you aren't working in the same team. So it may be hard to do like a team goal. So this would be a personal goal activity that you could then do, which is also quite silent and personal. So we're gonna give you a minute or two just to decide in your teams which one tickles your fancy, which one you like. And then you can come up and just grab a pack that you can run with. Okay. And if you don't mind, we'll play some music in the background because a lot of these are quite silent. So it gets a bit awkward. Okay, so realistically, you'll probably only have time to do one. So pick one. If you finish it early, you could always try another one. So guys, we're gonna give you about another five minutes to wrap up the technique that you're on and if you're already finished, you can come grab another one and quickly try and get through as much as you can of another technique. The needs one. That's a whole pack. It's got 10 in there. Are we near them? 10. You also send out the link and you can print everything you've got. You can print the boxes. Okay. You can change the cards. You can take them. Oh, okay, sure. Yeah, absolutely, you can take them. Okay. We're gonna have a minute or so to wrap up whatever you're on and then we're gonna have a very quick debrief and we'll take you through just one or two more slides. Well, but it's a very different way of completing it. So if you have feedback for us, the website, smogcanvas.com, I think it's Oats in the booklet. And you can actually send us feedback on if you use it with your teams and it doesn't quite, like something doesn't quite work, let us know and then we just pick one. Keeping, we're building that one up because we see there's value and we're getting through. Sorry? Everything, we will send you the link. You can download everything. You can download the booklet. You can download these. Everything we give to you. So you don't have to have the physical copies here. You can print it off the net. You can just download these. How far we go towards when these don't go? I love this one. How far we go towards when these don't go? Oh, awesome. It's all available. Yeah. So I'm gonna give those to you guys and you guys. Should we give like a few more minutes? Even if we're just a little bit early, but we've still got two slides. So the team can have them and we can talk through the facilitation there. So should we ask for some feedback? Yeah. Someone's already done it. Okay, so I think wherever you got to is fine. We don't expect all the teams to complete this exercise, especially the values one. The values one takes quite a long time. Most teams tend to finish the needs one and the personal goals one. So we're looking for some feedback. So we had one team doing values and the rest of the teams did the needs game. Maybe team at the back. Do you have some feedback on the values one? What did you like? What didn't you like about the technique? Yeah, as a team, we all agree. Values are most important to work as a team, okay? So we need to have certain values from our individual perspective. How does that map to a team, okay? And then how the team looks on those values. So when we rank those values, how it comes out as a team together, okay? That's the most important aspect because when we are working as a team, we need to work by values, right? So what team believes in? Yes, yes. Yeah, exactly, it worked. And then some of the values were very common between individuals. Out of three, we add common values, okay? When you have as a big team, yeah, exactly. So we add one such value here. The collaboration and the accountability. When you collaborate, accountability comes together, right? Something like that. The most, the number one priority that comes up from most of the members. Don't tell me what to do. Yeah, it's like I've been having a diverse group like us. Yeah. Learning comes second and creative comes third. Okay, so that was for your team. That's a trend that's going on for some of you. And how did people in two, sorry, although there were similar needs with the interpretation similar, like the ask from the team. And that's the thing is it's so personal. What does independence mean to me? Top values, one was learning and the other was creativity. And then as I said, I chose learning, he chose creativity, but our illustrations were kind of same that everybody wants to learn and grow and like invest their out of the box thinking. And kind of we can club creativity and learning. We can make a new value out of it. So we had an interesting conversation around independence and choices. And we did ask like, how do you differentiate independence and choice? Because independence means autonomy. And this choice means that I get to choose what I want. And we understand that it could mean that we have a lot of options to choose from. So yeah, and then independence could mean different things to different people. What independence is to me may be different to what independence is to another team member, right? We'd like to share. What I'd like to share, everything here, either values or needs, it's a content, container, sorry. So it could mean many things to many people. Exactly, so what matters is the conversation and the exercise of doing as a user story was a very interesting clarification exercises for oneself also. Actually, this is important for me, but what do I concretely ask? So that was very, very nice, thank you. Okay, so hopefully what we've done is we've given you, I mean, this isn't our canvas, but we think it just wraps it up so beautifully what you need in a team, which is why we use it, but we definitely want to give credit to the original creators of the team canvas. We just play around with different techniques to get to the end result of what we're looking for. So hopefully today's session was a little bit of inspiration on different techniques you can use within your teams. Talia and I, we often write stuff and we'll publish it, so we've got our Twitter handles on the back of our shirts. They're there, they're on our butts, but it's, yeah. So you can follow us on Twitter. We also, in the booklet, I think our contact e-dolls are on the back. My contact e-dolls have changed, yeah, they've got Twitter handles. It is probably the idiot, but I wanted to let you know that everything that you've done in the workshop, you can download and you can use in your teams. So you can even print off a copy of the Liftoff book if you want to share it with Scrum Masters when you go back to work. The cards, we give you the format that we used for the cards. You're welcome to change those as you want. They're really, we don't want there to be any barriers to people really creating an awesome space for teams. Just maybe one point that we quickly skipped over, but I do want to go back to, and I can, yes, can I, there you go. Just remember when you go into your team Liftoff session, you do have to prepare for them. So these workshops don't just happen. There's a lot of effort that goes into it. If it's a two-day workshop, we've pretty much got our prep work down to about a day, but we used to spend, if it were a two-day workshop, we'd spend three to four days preparing for it. So it is a lot of prep, kind of come up with an idea of what you know you need to take. This at a very high level is what we originally did for this workshop quite a while ago, but it just gives you an idea of the kinds of things you can think about when you're getting ready to take your teams through this. But yeah, I think, are there any questions on anything that we did? Oh, this is actually for this workshop. So we, if you want to have a chat, I can give you an idea of what I usually play around with. I'm trying to, did we ever put it in the booklets? We never... For which section and all of that. I think the point of that facilitation guide is that actually the level of detail for the activities in the lift-off guide is the level of detail we start with. To say this is exactly how we run it. If you're doing the values, we're gonna time box it to five minutes to pick your individual values. So that facilitation preparation and that and sticking to the time boxes is so important. Because this stuff you can take, you know what I mean, you can just keep going. So it depends which techniques you use and to almost go into that detail and just really be strict with that timing. So an agile charter usually has a lot more of your product information in. So we don't have it in the team lift-off, we like to split them. Because we find teams often bulk them in and they're almost two different hats that you're wearing. One is more product focus and one is more team focused. So our product lift-off tends to take us three days. And at the end of that, we'll actually have an initial product backlog. And then the team lift-off and the product lift-off together is your agile charter and also the initial product backlog. So that's where we go into the product vision and we understand the metrics behind the products as well. So there's an overlap, this is team specific. But then... So we often use, I like to use something that Ellen Gossestena did, which is a discover to deliver. I find it's really good for teams that are new to an agile way of working. It gives them a level of insight that they don't often get with other techniques. So you still bring in things like user story mapping, that kind of thing. So we can have a chat about it afterwards. If you want to go, yeah, that's a particular passion of mine is product focus stuff. So are there any other questions about the workshop that we've run? Who talked about... Who had the mic first? You talked about personal goals and you took a very good example of somebody who was pursuing CBAP and he had his priorities, he wanted to attain certain experience. So actually there is a live scenario that happened with me way back in my previous organization. There was a tester in my team who wanted to become, do a career transition to a business analyst. And he was appearing for CCBA or CBAP, I don't remember. But then he required similar kind of experience in certain knowledge areas, like requirement elicitation and gathering, requirement design, which are not a tester which don't fall under tester care is. Now he sought for those kind of... This sounds like a conversation you and me can have. Yeah. Is that fine? Do you want to hang around? I will just summarize it. So he wanted to do something which was on a live project, which we could not afford. So we had to turn it down, turn down his aspiration there. So how can we manage that? So I don't think all environments are always going to be suitable for every person. This makes it clear if it's something that the team can help them with upfront. So it is something that you can kind of get out there and either you can come up with an agreement in the team about how you make it an environment they can still tolerate and work in. We worked in teams where it did not meet someone's career aspirations and the team actually helped them move into another team because they knew that that person was going to be unfulfilled in their role and it's important to be happy. So it's probably not a nice answer, but you don't, yeah, sometimes not all environments are perfect for everyone. So I think we're pretty much out of time. We will be around. We are very happy. We've got some extra material. If you want to come and grab some, you're welcome. We do, we've shopped a lot. So come and lighten up our suitcase for us. But yeah, just thank you very much for joining us this afternoon. Hopefully there's a little bit of inspiration to kind of make some of these techniques your own. And follow us on Twitter. Hey, thank you.