 Welcome to three to one, let's have, we have Sprintoff. We are lucky to have Angie and Talia joining us today. This session is sponsored by Agile Alliance. So thanks to them. Thank you a lot. Without further ado, let me hand it over to you. Angie and Talia, take it over. Thanks so much, Daydeep. Welcome everybody to our session this morning. We're really excited to be doing this. This is our first time doing it virtually. So we've run this particular workshop format to quite a couple of conferences in the past. But like I said, this is the first time we're doing it virtually. And you're the first group that's actually going to experience being able to do many of these techniques in a virtual way, so we're really excited. So I'm just going to kind of jump off and introduce myself. My name is Angie Doyle. I'm an Agile coach and trainer with a company called Think Agile in South Africa. Talia, I'm going to hand it over to you. Thanks, Angie. My name is Talia Lancaster. I'm an Agile coach with a large bank in South Africa called Absa. And I also have a company that I own called the Skitching Scrum Master where I do graphic recording. Okay, should I get the slides up? I think so. And in the meantime, while Talia's getting the slides up, I want to ask a question to everybody in the audience. And you can interact with us on the little discuss button on the right-hand side of the panel. And I want to know how many of you have heard of high-performance teams? If you've heard of high-performance teams, just put a yes or a why into the discuss and a chat. So I'll also go and read and why, right? There are lots of people have heard of high-performance teams. Great. Awesome. And for those of you who've heard of high-performance teams or maybe you've been lucky enough to be part of a high-performance team, we want you to just put in the chat what are the behaviors or values that you've seen in the teams? So if you could type us a little example of some of the behaviors that have been evident in a high-performance team. And you can just use one or two words. And high-performance teams could be any teams that you've worked on. They don't necessarily need to be adult teams that you've been in. They could be maybe if you were in the Army, maybe they were a high school sports team. And we're really looking for any kind of high-performance team that you've been part of, some of the characteristics. So I'm seeing things like self-organized, there's commitment, there's ownership, there's empathy for each other, self-driven, driving ownership, those are all really amazing kind of sounding words, ownership, accountability, things like collaboration, right? So high levels of trust, high levels of respect for each other as well typically tend to be some of the characteristics that we see. Now, interestingly enough, not everybody has been in high-performance teams, right? So, and we're gonna, you know, pretty much what this session is gonna take you through is how do we get to this point of being high-performance a lot quicker? Awesome. So let's look at some of the traits of high-performance teams. So there was a project done by Google called the Aristotle Project. And it comes from that quote by Aristotle which is the whole is greater than the sum of its parts. And basically Google kind of, they're very good with data so they went and they analyzed hundreds of teams to try and understand what that formula is for a high-performance team. And they were looking for things like how many people do we have in a team or what is the team kind of structured in terms of the makeup of the team or the skills. And what they found was there were actually five common traits. There was never any kind of common sizes, et cetera, but there were five common traits that were all evident in high-performance teams. And these are number one is psychological safety. So if you make a mistake in your team, it's not held against you. So you feel that you're safe to kind of give input brainstorm and give your ideas and be vulnerable without kind of someone holding it against you within the team. The second one is dependability. So if your teammates say that they're going to do something, do they actually follow through with it? The third thing is structure and clarity. So are there clear roles within the teams? Are there clear plans and goals that the team are all aligned to? The fourth one is meaning. And this is very much, do I personally find meaning in the team that I'm part of? And lastly is impact. So do I understand how my team contributes to the greater organizational goal? How do we as a team impact our organization and add value? So what we realized after working with some teams is that these are traits of these high-performance teams and we realized that high-performance spaces don't happen by accident, right? So you actually really need to have a very intentional approach to creating high-performance teams. And something that Talia and I started doing many years ago is we started running workshops with teams kind of similar to a lift-off where we would create the team charter, okay? So what we realized is it's really important for high-performance teams to kind of consciously create this space where they work together, they collaborate. This kind of thing doesn't happen by accident, right? So you have to have a very conscious approach to creating teams. And this isn't just about creating like a project charter, right? This is actually about creating a team charter. So the way that we make the distinction between an agile kind of charter in general and a team charter is that your agile charter usually includes that product side as well, right? So a little bit more of a focus on the product development side. So when we're trying to get to high-performance understanding why you're building is really important but we wanna focus on the team side first, okay? So how we actually did this is we started looking for ways to help teams kind of get an understanding of everything that they, you know, that they need to get you to create this high-performance team space. And we stumbled across something called the team canvas, okay? And I wanna share an image with you of what a team canvas looks like. And I wish we could claim ownership of the team canvas. Unfortunately, it's not something that we created. This is actually something that other people created. What you can see in front of you is the team canvas. And that is essentially this canvas that we started working with. And we realized that all of those different segments that you go through are the types of things that high-performance teams really need to work on to create these high-performance team environments. And what we did is we used this inspiration to identify a whole bunch of techniques and we're actually gonna take you through those techniques today. We do have a booklet and we will give you that link at the end of the session. We've got a booklet that you're welcome to download. It actually gives you more techniques than what we're showing today. And it really just gives you an idea of how to run these, the booklet's very focused on in-person ones. And we're gonna talk today about how we do in-person as well as virtual exercises. And you're gonna have an opportunity a little bit later to actually practice some of the virtual ones. Like I said, you're gonna be the first group that we have. Okay. Are we ready to move on to purpose, Angie? I think so, Tanya's gonna start as kick us off with the thing that we always start off with, right? So we don't have a specific order that we follow on the canvas. But the one rule that we do have is we always start at the heart of the canvas, which is the purpose, which is where Tanya's gonna take us to now. Awesome. So as Angie said, the purpose is right at the center of the canvas, and it's actually a little heart, which is quite fitting. And this purpose speaks to what do we do as a team? Okay, so why are we doing what we're doing? And what is our reason for existing? And this is quite different from a product purpose in that it's very much about the team. So for this exercise, we're not looking necessarily at product features and kind of details. We're not building a backlog. It's very much about connecting people with the purpose of that particular team. And going back to kind of high performance team, what does that meaning that people can derive from being part of the team? So Angie and I have various techniques that we like to use here. A quick and easy one is maybe taking video clips of your actual customer and playing that in things like your sprint planning or your PI planning to really kind of connect with your customer and make sure that you don't lose touch as a team with who you're actually developing for. Another technique that you actually have an opportunity to do today is called the Elevator Pitch Storyboard. And this is very much, I don't know if any of you are familiar with kind of creating videos or in the production industry where you would actually have a storyboard of what story you're going to tell. And what we do here is we actually encourage teams to use both visuals and words to connect with their purpose. And it basically falls into three steps. So step one is what is the problem statement? So really connecting with kind of what problem are we trying to solve for the customer? Step two is what are our unique skills as a team that we can actually use to address this problem? And step three is how do we ultimately make the world a better place? And that very much speaks to the value. So the best way to kind of illustrate the storyboard is to go through an example. And this example we drew by hand actually on an iPad. So you could do that virtually if you have access to that. If you are in a virtual setting, you can actually just use icons from Google or as a scrum master, you could kind of set up some icon packs for the team and you can drag and drop icons into the image space instead of drawing it. So this translates really well to virtual as well for the teams. So basically with this example, you can see for step one, you've got a very unhappy looking customer. You've got quite a horrible looking house with a big price tag on it. I suppose it depends on the currency, which is 3,000 per person. And basically the customer looks very, very unhappy in that step one, which is your problem statement. Once you've illustrated the problem, you would then write it in words. And the way that you phrase it is like a question. Do you know how? And so this example is, do you know how people travel to a foreign country or city and don't always know what kind of accommodation they are getting for the money they are spending? I think that this is a bit foreign to us at the moment because we're not really traveling. But remember when we used to travel and Angie and I are very sad that we knocked in India this year, but anyway. Okay, so that's a problem statement. And then you actually start step two with writing first. So you would say, for example, what we do is match people looking for accommodation with people who have spare accommodation that they're willing to share at a reduced cost. Okay, and then we illustrate that. So now we see a person who looks a bit happier and we're connecting them with a vacant house. And that's basically the unique skills and how the team is addressing that problem. And then lastly, this one we start again with the picture first. And that's how do we make the world a better place? So ultimately the value here, you can see a very happy customer with a heart, the house is filled because the lights are on and there's money coming out of the chimney. And the statement here for the ultimate value is so that travelers can save money when they travel. Hostors can make money by renting the space, the space space and everyone feels safe and secure during this process. Okay, so can anyone guess in the discuss section, can anyone guess what company this is? To type it into the chat. What company you think this is. Type it into the chat if you think you know. AB&B. Okay, also think along those lines. I'm not sure what else you guys have in India. We've got a couple of different types of companies that do this sort of thing in South Africa. Awesome. And basically by the end of it you have one page that the team hopefully really connects with in terms of the purpose and the meaning of that team and what value they're actually delivering for the customer. And they can pitch their purpose to other people, right? Using the storyboard as a template for them to have a conversation, okay? So now that we have a good idea of what we're doing and why we exist as a team, we want to move into understanding a little bit more about people and roles, right? So who's on the team? What are their responsibilities? And what we've realized is that people make a lot of assumptions about people in their team based on the roles that they used to have in more of a waterfall type environment, right? So what we do is we actually take them through an exercise where we unpack the roles in the team and then we say, well, what are people expecting from this role that used to exist? This business analyst, this tester, maybe a back-end developer, front-end developer, et cetera. And what we do is we have two different types of exercises that we run, one for new teams and one for existing teams. This isn't a version that we've actually currently converted into an electronic format. We're in the process of kind of converting all of our exercises that just is one that we haven't quite got to you, but we have got this as a principle version. And essentially what we call it is we call it 101 responsibilities really ideal for like a web-based team, but you can modify the content to be more suitable for an application development team as well. So what we do is we have 101 cards. It's basically a pack of cards that we cut out and each of them has a different responsibility on it. And this exercise was inspired by very often in scrum teams we'll say, what's a role in a scrum team, right? But it kind of goes into the product owner role and the scrum master role, but it doesn't talk about what are the technical requirements or the technical tasks that we actually have to do for this team? So we've got a list of everything, of everything that we believe they do. So you can see two examples there, automate deployment scripts and then create the product roadmap. And what we do is we paste upon the role kind of all the roles that we have in the team. So here we've got business analysts, front-end developer, product owner, scrum master. Really you just kind of identify what are the roles that people are associated within the organization like? Because most of us haven't moved into this concept of just being kind of like a product development team member or development team member. And we put this pack of cards, 101 responsibilities faced down on a table and we do it as a silent exercise. And people walk up to the card, they pick up a card and they then read it silently and they go and they put it on to the corresponding role that they see up on the wall. So they'll go and they'll stick it somewhere. So that's one move that they can make, another move that they can make is that there's already cards upon different roles. They might decide to move one particular responsibility maybe from a product owner to a business analyst or they can pass, right? So if they don't wanna move anything that's currently up on the posters or they're not too sure what the card in front of them says they can say, I'm gonna pass and then the next person walks up and places the card. So it's the three moves. Either they can assign that particular responsibility to one of the roles that they see or they can move a card that's already being placed under a role to a different role or they can pass. Now, the key thing with this is we ask our scrum masters or our team facilitators to just track how many cards are moving from one role to another role. So whenever they move a role we ask them to just put a little dot in it, right? And it just starts to indicate that a bit of a silent battle is happening. So remember this whole exercise we're doing silently we're not actually talking about it. So we wanna identify people are like waging a war of worlds across these different cards, right? So every time a card's moved the scrum master will put a little dot on it. And the second there's three dots on it the scrum master basically takes it out of play, okay? And that's just an indication that there's a silent argument happening we probably need to have a discussion about this it's not gonna be resolved by us just like aggressively moving cards from one role to another role. And then what we do at the end of the exercise all of the roles and responsibilities would have been allocated to a particular role and we then have a conversation, right? So if I'm a business analyst I'll go to the business analyst poster and I'll have a look at all the roles that were allocated to that particular or all the responsibilities allocated to that role. And I'll start saying, yes, I agree with this actually I've got a question about this I disagree with this one this actually goes to a different type of role and really the key behind this is we're not trying to allocate things for people to do, right? So we're not saying a business analyst only does this and a tester only does this but we know coming into teams that there's an assumption that certain people are gonna have deeper skills and some things than other people do, right? So we wanna get a sense of what's the first thing of somebody with those deep business analysis skills are gonna pick up in the team? What are the types of responsibilities or tasks that somewhere with deep test analyst skills is gonna pick up? And this is really just kicking off that conversation, right? So it's just about helping people explore who's gonna kind of not own but who's going to accept responsibility for certain things in the sprint and before they pick up something else, right? So we're really starting to get a sense of maybe where some of our skills are deeper in certain types of things than other things. We're gonna take you through another exercise and skills just now. So this is that's the one that we do for existing teams or new teams this is the one that we do for existing teams, okay? And what we do is we use that same concept of we're putting up the posters and you can see we've got the virtual version on the left-hand side in Google Docs where we just put in the title. And then what people do is they just type in what they believe that type of role, the kinds of tasks, the kinds of responsibilities that they'd have in a sprint. They type it in or if it's physical that write it up on a board. Then we go through a similar kind of format where the person who believes that they're most aligned to that role. So my title in the organization might be Business Analyst. I'll go up to that poster and what I'll do is I'll tick the ones that I agree with. If it's virtual, I'll just make it in green. If I've got a question, I might put a question mark to it next to it. If it's virtual, we'll just maybe put it in something like orange. And if I disagree with something in the virtual one, I'm gonna put like a cross next to it. On a physical post, I'll put a cross next to it in the virtual space I might have highlighted and read. And the ones that we wanna talk about are the ones where there's Christians and the ones that we disagree with. And those are gonna be the responsibilities for that role that we're gonna take a little bit deeper and have a conversation within the team. Awesome. So now that we've defined the roles within the team, we wanna take it a level deeper and speak about skills. So Angie mentioned in an ideal agile world, we wouldn't necessarily have these titles or roles. We'd have a development team. However, when that happens, we need to have a very strong grasp on the skills, the strengths and the weaknesses within the team. So the next part in the canvas, we've actually combined together. It's two sections, which speaks to strengths and assets. And then the second section, which is weaknesses and risks. And this is basically what skills do we have in the team and what are our individual and team weaknesses? Sorry, my bunny's making a bit of noise in the background. He's biting something. Okay, so with this section, basically, what you want to do is get an understanding of what the skills are within the team. And this includes soft skills and your technical skills. And essentially what you want out of this is to identify obviously where the strengths are, if you see that you have a lot of skill in a particular area, and then potentially where the weaknesses are. And the true value with an exercise like this is to actually come up with a plan to ensure that you're addressing and filling those gaps from a skill perspective. And so Angie and I have developed a technique and it's similar to management 3.0 has a really great one with a grid. We've decided to make it into a pizza because we thought it was really fun. And it depends how hungry you are. We've got eight slices here. You could have more slices if you want. But basically what we do here is we actually overlay various elements of information. So on the pizza, in the crust, you would put your skill so you can pick your top eight skills. And the trick here is to understand what skills you need for that particular team. So if you're a web-based team, you may have very different skills if you're kind of doing .NET development. Or even teams nowadays that aren't just software development teams, you may be a marketing team and then your skills pizza is gonna look very different. So you want to identify your top eight skills that are imperative to delivering the product in that team. And the way we do this is we actually brainstorm on stickies. Everyone can kind of put in the skills that they believe are core to the team. You theme it and come up with your top eight skills. Those then go into the crust of the pizza. So you can see this is the virtual version. So we've got the sticky notes where we've brainstormed, themed it and agreed on our top eight. And then just pull them across onto the crust of the pizza. The next step then is to actually identify the people within the team. So you can see on the right-hand side, we've got a team key. I'm the tomato here, Angie's the avo. And then we've got Egbert, we've got Al, we've got Shadi. So each of the individuals in the team will then pick up an avatar that correlates to their name and they'll map out on the pizza where their competency level is for that particular skill. So for example, Angie's a pro in business analysis. You can see that she's sitting in the green section for business analysis. The orange section speaks to intermediate. The red section speaks to newbie. And then one element that Angie and I've added in right in the center is I want to learn. So sometimes within a team, there is someone who doesn't necessarily have deep skill set in a particular skill, but they're really interested in learning and growing their skill set. So everyone after you've mapped your avatars onto the pizza, and essentially, we need to trust people within the team to be honest here. What does help when you're running this with a team is actually to define what you mean by these different categories. So within particular teams for a pro, you might say, well, we expect a pro to have at least five years experience, plus they need to present at conferences and be thought experts or they need to... So what are the different criteria within the team for each of these categories or each of these levels of competency? So once everyone's mapped their avatar on the pizza, the next step that we want to do is at the bottom on the right, you'll see there's a sad face, which is I can do it, but I don't like it. And this is really important with teams because often we rely on people who are experts in a skill and that's what they do day in and day out, but they actually hate it. They really don't enjoy doing that particular thing. So what we want to do is actually identify where people don't enjoy doing something because that is potentially a risk for the team. If they're the only person who can do that thing and they don't enjoy it, we could actually lose them and they could leave our team. So we overlay the sad faces where it's relevant for the different people and the different skills. And then lastly, what we do together as a team is we identify using the red exclamation points, we identify where the potential risks are. So if you see in our example for Java as a skill set, which we've identified as a core skill that's required for this team, we've only got Shadi who's a newbie in Java and we've got Egbert who wants to learn but currently doesn't really have a lot of skill set in Java. So that's a massive risk for the team. And if that's something that we need in order to deliver this product, then we need to make a plan quite quickly to address that gap. So once we have this view and we've identified any kind of risks or gaps for the team, the final step for this is actually to come up with a skills action plan. And this is really important because I think often we do this exercise where we identify skills, but we don't kind of take it a step further to say, what are we gonna do about upskilling or growing skills or filling these particular gaps? So what we recommend here is to have a plan that's very specific. So you put what do you want to do, who's owning that action and when should it be completed by? So for example, here we have go on additional Python training Egbert is gonna own that and he should have completed this by the end of next month. Okay, so that's the skills. So Talia kind of touched on that little unhappy face that we have on our skills pizza where people don't necessarily enjoy doing something. And so often we don't pay attention to people's needs in a team, right? And our needs need to be fulfilled for us to be happy at work every day. I mean, we're spending all of our time with people in our team. We want to let them into a little bit about how we check and what's really important to us. And how we do that with teams is we address their needs and expectations and we have a very open, transparent conversation about it. We don't usually do this as part of our initial kickoff with teams. I spoke briefly about that team charter. We don't do this right at the beginning when a team's forming. We tend to let the team build up a little bit of higher levels of psychological safety so that they feel comfortable about actually letting people into usually what we kind of protect other people from seeing who we are, what makes us take it. And the way that we do this is we've created a fun game that basically identifies different needs within the team, right? So, Talia, if you could go to the next slide. Okay, so those little cards on the left-hand side, we've created 10 of them. We sourced our list of needs from the Center for Nonviolent Communication from their list of needs. We just identified the top 10 that we saw kind of consistently came out of the teams that we were working with. But if we haven't covered all of the needs for people in a team, we sometimes give them the opportunity to identify, you know, using this big list. But I'll show you what our technique kind of looks like. So everybody lands up with 10 cards. So this one works well as a virtual exercise and well as a physical one. So if it's a physical exercise, we print out the need cards and we give everybody their own pack. If it's virtual, we give them all 10 cards on something like a Google slide and they can move things around. We ask them to prioritize these different needs in order of priority rights. So specifically, we're looking for those top five ones from a virtual perspective. But, you know, usually we're working with the top three to five basically. So you can see I've got an example of myself over here. I've got creativity as being my top need and that's really important for me to fulfill on a daily basis. And I find that if I'm not able to be creative and I'm not able to express myself creatively in teams, I tend to get quite frustrated, right? So it's an important thing for me to be able to do, you know, in the teams that I work with. So for that particular need of creativity, I basically complete something that we call the needs card. This was pretty much inspired by user stories. You can see the format looks like a user story, right? So, you know, as Angie, so you just put your name as a team member in there. You say I need and I kind of indicate I need the space to be creative. Okay, but what does that mean? What do I need from other people in the team to help me be creative? And here I've basically said, so a request from the team, the opportunity to include visual elements in our requirement discussions. Okay, so I'm going in with something that's quite hard to kind of put your finger on and needs quite intangible, but I'm making it a specific request from the team. That's something that they can do. If I just threw out and I said, I need to be creative. I haven't given them any kind of insight into what it means for me to be able to be creative. So we make a very explicit request from the team. And if we're in a team that really cares about each other, those high levels of collaboration and respect that we were talking about, they're going to try their best to create a space that everybody wants to work in, right? One where creativity is valued for Angie. And then you can see there's a little posted over there. So usually how we run the exercise is more as a silent exercise. So again, we'll prioritize our needs cards and all you need is what those little cards are called. So we'll prioritize those. We'll then write the needs cards and we usually do that silently because that's all the information that we have in our own heads, right? Once we've done our needs cards, we invite other people in the team to have a look at what we've written down, specifically what we're requesting from the team. We ask them if anything's maybe not very clear. So do they need clarity on anything that's written on our needs card? And then what they do is they might put some posted notes or add some notes, just where they need some idea of what you mean about something. So hopefully they're not questioning the need, right? That's the kind of behavior we wouldn't want to really see in this exercise because people are opening themselves up. They've been quite vulnerable with this. Hopefully what they're doing with those questions is saying, I just need a little bit more clarity about what you're asking of me as a team member. So you can see here, the little notes says, does this include visuals in other events like retrospectives? And that would be a trigger for a conversation with me and the rest of the team to say, yes, I'd love to be able to include some visual elements into our retrospectives. And we could talk about how we could possibly do that. So like we said, this one is quite a, it requires people to be quite vulnerable. So we don't dive into this with brand new teams. We kind of let them work together for a little bit and build up trust before we run this. Awesome. Thanks, Angie. And that needs exercise is very powerful. So whenever we run it with teams, it's really powerful. But as Angie said, you need a lot of trust within the team. So needs are quite personal. No one else can really fulfill your need for you. You can express what your need is, but it's not necessarily a shared thing. It's a very personal thing. Whereas the next section in the canvas is very much shared team values. And that speaks to, what do we really stand for and believe in and how are we going to show it? So often with companies, I don't know how many of you, you can maybe give a thumbs up if you resonate with this. But often with companies, you'll have like a really nice poster or maybe in the lobby, you'll have like your top kind of values for the company. And often it's things like respect or integrity or I don't know, ownership or, so they're always these kind of company-wide values. What Angie and I find with teams is that you need to take it a level lower in order to identify the specific behaviors that you're expecting within a team. So although values are really powerful and it's important to identify your team values, you need to agree on what those daily behaviors are. And that helps you hold each other accountable and just to agree on kind of what are those values mean for you? So quite an interesting example that I experienced with the team here in South Africa is we did the values exercise and one of the team values that they identified was respect. And in South Africa, we've got lots of different cultures and these cultures differ quite drastically in terms of things like how do you show respect for other people? How do you show respect for people older than you or people in your organization? And one of the team members had written that she shows respect by looking at people in the eye. So making eye contact with people. And another team member actually said it's an absolute opposite for him and his culture. So in his culture, to look someone in the eye is a form of disrespect. And from that, actually, that worked in a team previously together and she always thought that this team member didn't like her because he never used to look at her. And that kind of resolved this whole misunderstanding just by kind of being very explicit about the behaviors that they're wanting to see in the team. And then at least you have an opportunity to agree on, so I think the resolution with that was, if it's part of your culture to not look in the eye, then please don't now understand where that's coming from. And I understand it's a form of respect. So what we do for this activity is the two kind of options here. So if you're doing this physically in a room together, there is a big values list that's available on management 3.0. It's a lot of values. I think Angie and I tried to count it once. It's about 200. So what we would do if you physically in a room is print one of these out for each person. And then you kind of physically make five dots next to your top five values. What Angie and I have done from a virtual perspective is we've shortlisted the values onto a slide just to make it easier. And each person has five dot votes to vote on their top values. What you can do if you pressed for time with this activity is if you're a scrum team, you could actually just use the scrum values, especially if that's something that you're wanting to kind of embed and encourage within the team. You can automatically kind of identify things like focus or openness or courage, commitment, et cetera. Okay, so once you've shortlisted your values, you want to have no more than five. So usually three to five values is a kind of happy place. You don't want too many values because then it's kind of too much to focus on for the team. So again, we've included an example here of the physical poster. And it ends up being quite pretty like a flower with all the behaviors radiating out and the values in the center. And what it says there is atmosphere. And the reason for that is your team values are something that kind of hang around in the air like a perfume. So they're sometimes quite difficult to put your finger on in terms of what exactly those values are. But when you're around a team that has great team culture, you can kind of sense in the air that they've got a great atmosphere. So what we do is we put the top three to five values within that cloud and then radiating out from that are the specific behaviors. So we always start these statements with we work best together when. And we end the statement with a very specific behavior. So for example, if your value is something like honesty, a behavior may be that we work best together when we give open feedback to others. Respect, again, you would have to decide on what does respect look like for your team in terms of actual behavior. It might be something like we work best together when we greet each other by name in the morning. And do you look each other in the eye? Is that a form of respect or is it the opposite? So what are those specific behaviors? So if you're running this in a physical setting, we'd suggest that you actually split up into smaller and either pairs or threes to write these statements and then come back together and decide on kind of the final statements, get rid of any duplicates and just kind of agree that you're comfortable with those as behaviors. If you're working virtually, if you have the option to have smaller breakout rooms, then we definitely recommend that. If not, then you can have a team conversation and just start drafting these statements. Just remember the 80-20 rule because this can take quite a lot of time if you're being very pedantic about the specific kind of wording. So get to a point where you have a statement and the team is 80% happy that that kind of portrays the behaviors that you want. And then this becomes a living document. So you can use this again in retrospectives to kind of assess, are we living these behaviors? Are they still relevant? Are there gaps in behaviors that we'd like to see? Okay. Great. So we've got three sections left in the canvas and they tend to be a little bit more practical in a way than the others that are very focused on kind of collaboration within a team and being kind of really directing the behavior that we're expecting. So what we've done is we've got our common and personal goals. We do do two separate activities but we're gonna introduce the concept to you in a very similar way. So common goals are really how, what are the goals that the team is actually trying to achieve? They're really important because it's usually how people outside of the team measure the success of the team. Okay. So goals tend to convert quite well into metrics. That is at least something that other people outside of the organization can work with us or outside of the team and the broader organization can work with us on. Personal goals are individual goals, right? And again, just like needs, it's really important for us to be very clear with people about what our goals are, right? So we've got a technique for personal goals. It's available. We're gonna post the links to all of our different websites shortly. And basically, oh, before I jump in there, that's what you should have jumped in and reminded me I was going too fast. So all of our techniques are based on the concept of smart goals, right? So smart is something that has been around for years but we find people kind of disregard the great concepts that were kind of created years ago because they feel too traditional and they're not relevant anymore. But this kind of way of thinking about goals is still very, very relevant, okay? So just so we're on the same page as quickly go through this concept of smart and basically our personal and our common goals are based on this consistent definition of smart. So the S essentially stands for specific. This is actually what do we want to achieve, right? So usually what we're talking about and is specific is how, you know, those typical W questions, why, what, when, where, and then you're how, okay? So we want to be very, very specific about what is it that we're trying to do? The second that there's too much vagueness, you know, that's when we get confused and we start kind of seeing high levels of conflict within our team. M is measurable, so when will we meet the goal? But to know that, we have to have a very good sense of where we're coming from, right? So in order for us to measure any kind of goal, we have to have some kind of data at the beginning of what we're going to compare to, okay? So we've got a goal, but where did we actually start from? And A is achievable. I prefer the word feasible, but it would make this a very strange acronym if it was an F or B, like smurfed or something like that. Like it wouldn't be as cool and as easy to roll off the tongue as smart, right? So achievable or feasible? And the reason why I like to have it as being feasible is if we are converting our goals into metrics, and it's a way that the success of the team is actually going to be measured by the rest of the organization, needs to be feasible, right? Otherwise, we land up with these things that are just too big, right? Like they're too out of our reach and it's great to be motivated to achieve something, but it's really important that as a team, we have something that we can kind of drive towards, that we think that we can actually get to, right? The R is relevant. So is the goal worthwhile? Is this something that's taking us closer towards our strategy? Is it taking us away from our strategy? Because sometimes we have goals within the team or goals for a product that aren't actually taking us in line with the organization, they're taking us on a different path. So we need to always check back, is it a worthwhile goal? Is it actually taking us closer to our strategy? And then time balance, so how long is this gonna take? And we don't want other people to tell us how long it's gonna take, obviously from an agile team perspective, we wanna be very clear about when we think we're gonna be able to do something. So that time criteria, we don't want other people to determine, we wanna determine it as a team. And we might actually identify, that we wanna achieve something in the next two weeks and the next month and the next three months, we don't want it to go too far into the future, like a five-year plan that's gonna be far too long for us as a team. Okay, so that's the basics of SMART, that's what the next two techniques are pretty much based on. But we took this concept one step further, right? So we don't just want SMART goals, we want SMART goals, right? So the year on the end we've added, and essentially it's allowing us the opportunity to evaluate how we are doing. Okay, again, very often we'll set a strategy at the beginning of the year and we'll have these high level goals for the organization and the teams expected to kind of deliver towards those goals, but we need to have an opportunity to frequently inspect and adapt to kind of evaluate how are we doing against our initial goal. So we like to come back every couple of weeks, every couple of months to just really evaluate and see how we're doing. The R essentially stands for, tell you what is the screen showing, I don't know if it's just happening on my side. So it's really about rethinking or redoing, okay? So how do we redo, how do we reset our goal? And again, this is giving us the opportunity to change things if they need to change. I mean, if we think about any of the goals that we might have set at new year, when everybody sends that sets in new year's resolutions, the goals that we set at the beginning of this year would have to have changed, whereas it's been a really unusual year for most people. So we want the opportunity to rethink, maybe if our goal doesn't quite make sense anymore now that we've started working on it. And the two techniques that we've created from a personal goal perspective is something called a smarter canvas, okay? And this one is available again in the booklet. You'll have links to everything. And this is just really a way for a person to go through and articulate what their goals are. And this could be something like, I wanna be, I wanna become an agile coach. And that's a very high level, kind of like beauty queen statements. It doesn't help the team understand how are you gonna get there? So what you can do is you can actually unpack all these questions around specific, measurable, achievable, relevant, and time-bound. And you could actually articulate a much better personal goal statement that you can share with the team. And you can give them some insight into how am I actually gonna achieve this goal? Am I gonna maybe attend something like an agile coaching certification? Do I want to do some one-on-one coaching with people in the team? Is anybody willing to be one of my initial clients that I can actually start practicing coaching techniques on? So our smarter goals canvas really just gives people an opportunity to share with the team the thinking around their goal. What we do from a team perspective is we play a game. This one is lots and lots of fun. We haven't quite converted this one into a virtual format yet. Card games, there are some that translate so easily into a virtual format. This one's taken us a little bit more time to get our head around. And again, it's a game that you can play with your team. It's available to download all the cards and the questions. And essentially what we do is we take those big beauty queen statements that the organization usually gives us like we want to achieve world peace, right? We give these like super vague goals. And as a team, we actually unpack it into something that we believe we can actually deliver on. Something that's a little bit more measurable. Okay. And that brings us to the last section of the canvas. And this is called rules and activities. And it's basically how do we communicate and keep everyone up to date. So, this is actually the section that most scrum masters are quite comfortable with. And we often call it a working agreement. So this is often what teams do when they first start a new team. And it speaks very much to the ground rules, the tools for collaboration, the core working hours and those kind of things. So what Angie and I like for this section is Adam Weisbach's scrum kick off planner. So you can download it online. And essentially it's a document that you can work through and it has different sections for the team to fill out. And these cover things like obviously at a very high level kind of your team name, what you're gonna call your team and then things like methods of collaboration. Are you going to use Slack or Zoom or what are the tools that you're gonna use to collaborate? How do you visualize work? So is it physical or virtual? I think a lot of us have been forced into the virtual format now, which is not always a bad thing but essentially it's the agreement for the team with where does the work sit and how do you visualize it? And it covers things like core working hours. So I know in South Africa, we've got quite a multicultural and lots of religions within our team. So it's always something that we have to discuss upfront. So for example, don't set meetings really late on a Friday evening. A, because it's just not a nice thing to do. And B, because also with our Jewish colleagues they may have to get home for Shabbat. So things like that to just be aware of your team members and certain kind of religious considerations that may affect their working hours. Things like flexi hours, if it's something that's allowed in your organization to actually agree on what those hours are. Multiple time zones, which is becoming more and more important to kind of be aware of where people are sitting especially if you're working remotely and make sure that no one has to wake up at three in the morning. And we started the session quite early in South Africa but it was our choice. So we started at 6.30 in the morning. It was 10 o'clock your time. But it's things like that. Just to make sure that you're not inconveniencing people and that people can kind of attend your team sessions. Leave, so if someone's on sick leave what is your buddy system to make sure that they can catch up on work quickly and easily? Your team framework, so that's obviously also a fundamental that you need to decide on. What framework are you gonna use? Are you using Scrum? Are you using Kanban? And how is that gonna work for your team? Things like definition of ready, definition of done, team calendar. So if you are doing something like Scrum when are your Scrum events happening and just deciding on that calendar upfront so it suits everyone. And then lastly, things like your conflict protocols. So we know that conflict can happen within teams and it's not always a bad thing. It's actually quite good to have a healthy level of conflict but you want to kind of agree upfront how you as a team are gonna handle that. So are you gonna have something like a safe word where if someone kind of sees a safe word you have a certain protocol that you agree on. We walk away for 10 minutes, we have a breather and then we come back and discuss what we need to discuss. So this is very much kind of your foundation rules. So you'll notice that this is something that's often covered in your working agreement but why Angie and I like this team canvas is that it encompasses so much more than just your ground rules. So all the other sections that we've covered cover a lot more to do with the interpersonal interactions of teams, the values, the purpose, the skills, the needs, et cetera, et cetera. Okay. So that's a lot, right? We've just gone through a lot of different techniques, a lot of theory. The reality is we take two days to lift off a team. We don't necessarily work our way through every single kind of all of those nine different segments. We usually identify what's the most important for the team when we jump into that. But like I said, we usually spend two days working on this. So we don't have two days for you to practice everything but we do want to give you the opportunity to at least practice some of the techniques. So we identified four techniques that work quite well in a virtual environment. So that purpose, elevator, pitch, storyboard, all you need is games. So the needs one, the values, the exercise that we went through and the strengths and assets, weaknesses and skills, skills, pizza win. And what we're going to do is we're going to post a link to a Google folder into the chat. And we're going to ask you to go into the breakout rooms and I'm going to try and explain where you've got to go to find these breakout rooms because we can't just assign you to them. And what we'll do is we will jump in and help you out with the exercises. But the first thing that you have to do is you have to agree as a team which activity you're going to focus on first. And you're only going to have about 15 minutes or so to practice it. The intention isn't to actually finish the exercises just to get a little bit of practice playing it with a team. For some of the exercises, you'll need to do a super quick case study. For this one, you need to time yourself. It needs to take you under a minute, try it. And it's just to help you focus, if there's any conversations that might happen about what kind of team are we, what are we building? The case study just helps you out a bit with that. So you'll see there's a little dot voting exercise. You'll put your name against a color and then you'll have some dots corresponding to that color and you're going to vote using your dots. Like I said, it's on three of the different exercises. The only one that we don't have this case study for is the needs one because that's a personal reflection. Okay, there you go. So for those of you that are still in the main room with us, this is pretty much what that Google folder looks like and we'll give you just a quick sense of what those different exercises look like. Okay, so there's just a title slide reminding you which activity you went into. Right, let's load. Here we go. This particular one doesn't have the case study. So what we've got is we've just got a sheet on all of them with some virtual instructions and the virtual instructions really just talk you through how to do it from a virtual perspective. Like we said, the workbook that's also in that folder has more of the in-person explanation. So essentially we've also got on slide three, we've got an example of how we do this. This is where you really sort and order your cards and you put them in order of priority for you as an individual and then you complete the needs cards and then the next two slides the idea is that you just kind of copy and paste them for each person in your team and you give yourself your name. So under that name 1.1, it's just indicating that there's more than one slide. You can put my name and then what we would do is we'd actually drag and drop our top five cards on that slide. So there's my two slides for me and you can see we're just kind of drag and drop those in order of priority. So Talia can randomly click some. And our creativity probably should be number one for you, but... That's fine. Just gives you an idea. Yeah. And then what you do is you take your top, your top need and you then go to the next slide and you would kind of put the need under the need section there. So I think it was play on the other one. I might even say something like have fun or, you know... Have fun or be playful. So I request on the team and then you'd give the specific request in me. And then if any other team members have some questions, they could type a question on that posted note and they could... I'll actually go in there as well, Talia and you can collaborate on the same thing as you're going. And these you would just duplicate then for other people. So if you've got more than one person, then here this one might be Talia. And you can just duplicate. You'll need two slides per person. And depending on how many people you have in your team, you can just duplicate it. Okay. So there's an example and I added, if you go to slide five, I just added a little question there for Talia. So that's kind of what the all you need one looks like. We'll quickly take you through the others because we do want to start wrapping up in about five minutes or so. So we'll take you through a super high level rundown of how the other technique works. Just in case you haven't been able to join a breakout room. So this one is all about purpose. What we did with this one, it's a very similar exercise to what you saw. We just got that case study and the case study is only there for this type of conference setup. You don't need the case study for your teams because you'd already be working on A products. So essentially how this one works is again, we've given you just a way to do the dot voting if you're in the breakout rooms and then you'd be able to vote on your case study. Let me hop in there. You can feel free to jump into those folders anytime you want you to go play around. There's also a download folder where you can download all of the templates to your local Google Drive and the books that's also in there. This is pretty much, we don't have to go through the case study if you're not going to be doing this in breakout rooms. So we'll just take you through the actual technique itself. So these are virtual instructions just talking you through just in case you need a bit of a reminder about what the different exercises are. And then we've given you that Airbnb example on slide five. So that's there just to remind you kind of what it all needs to look like. And then the actual template itself, what we've done is we've created some icons. So we just added in five slides of icons with different images, you know, different, but you can pretty much grab whatever you want off the internet, right? You could add any kind of image in there. These were just to at least have a little bit of a starter pack of some images that you could use in your elevator pitch. And then the idea is, you know, where you need to actually type something. There's just a little kind of text field that you can go in and add some stuff in there. So this looks like a guy who's getting some lotion maybe. I don't know. So this is pretty much how this one works. There's little boxes for you to type your text and then you just drag and drop some images into the purpose statement. I think let's quickly jump into the other two and do a super quick intro into how they work. Sorry. We'll get back into 10. Okay, so we've done needs, we've done purpose. So let's do skills. And this will give you an idea. So the actual pizza is still there. And then every person within the team, this is that one where we're building up our pizza. You know, they each have their own avatar. So we've given some space on slide five for people to brainstorm their skills. You just group like skills together, identify the top one. So maybe by doing some kind of dot voting if you wanted to. And you'd bring those top skills into the blank template. So again, we've given you an example of a template and what it looks like. And then on slide seven, you'd be able to play around with the avatars, set people's names and start kind of bringing them in. So Talia's brought in one of the skills. You could then rename it and then you'd be the whatever avatar you've identified. So that looks like Talia's gonna be the tomato, there's our egg bird again with the egg. If you haven't picked up mine and Talia's humor, we're a little bit on the cheesy side. So this one would just kind of drag and drop your icons and then kind of kick off the conversation. So this one makes very similar to the impressive one. Actually, it's quite similar. And then the final template that we'll very quickly take you through is the one for values. This one's a great one from a virtual perspective as well. Also, we try to keep people can feel quite similar to the impressive one with the values kind of cloud or the team atmosphere. So we just created that little, there's your example and then there's a little grid to go and select your values. You can see there's little dots on the far left that people can drag and drop. So we try to kind of bring all of the elements that people need for the exercise. The name color coding for dots is here but I suppose it doesn't really match it too much as long as you need to pick a color. And then there's five colors. You can have five colors and you can spend your votes however you want to. And then what we'd land up with at the end is an idea of what are the top three to five values for the team would bring that into that final slide on slide seven. Okay. Okay, so we're getting the signal that we think everybody is back in the main room. So unfortunately, we know not everybody got an opportunity to go into those breakout rooms but you do still have an opportunity to go and play around with them throughout the conference so just hang on to that link and you can go and you can actually download the fresh templates. Talia will show you on that link where you can go. So if you go under download templates, you can download all four of those virtual ones and there's something else in there. There's a little PDF book. So that book is essentially you can print it out and have it next to you where you can just keep it in PDF and it basically details all of the steps for all of the exercises that we've been through today. And we will also share a link for a website where you can download all of the templates, right? So all of the templates that we've created, we've got downloadable packs that you can come onto our website and I will get that link very quickly in there. Into chat. So if you, when you've got a chance, you can visit this website, dink is actually an off the cons word, it's dunk, it means think, which is why it's, so the actual website is dink.africa and what you can do is you can go into that website, download all of the templates that we've been through today. If you want to do physical in-person ones, for the moment you've got the Google drives where we've got all of the virtual templates, they're going to be added to the website sometime this week as well. But yeah, and there's a lot more techniques in there that you're welcome to go through. So we've just got some for our Sprint off workshop there. You can see there's everything else. You just go in and you kind of download the pack. So you don't have to recreate these from scratch. You're welcome to use what we've got. And then just a reminder really about what our inspiration was. So we kicked off this initial session talking about this team canvas and how this canvas kind of articulated all of the stuff that we were doing with teams in one place, right? So there's nine different segments. We highly encourage you to go have a look at their website. We wish we had been smart enough to create that canvas ourselves. We just kind of created some techniques. We like to gamify a lot of our sessions. Like we said, our team liftoffs using that team canvas tend to take us about two days. So we do recommend spending the required time with your teams. If you don't get through all of the techniques in the liftoffs, what we often do is we'll actually bring it in as a retrospective technique. So if we haven't had an opportunity to do everything with everybody, we'll actually bring it in as part of the retrospective. So things like that, all you need is game. That's really good for a retrospective exercise, especially if the team is battling, maybe there's been a little bit of conflict because there's been different types of needs. So I do know that there were two questions in the Q&A and one of them was actually around the needs. It says what if two team members have opposite needs or expectations from the team? So if we have a look at that all you need is game, what we wanna do is we wanna just really have that transparent conversation, right? So that's an opportunity for us to uncover that there could be competing needs in a team. To be honest, I haven't actually seen competing needs. I've just usually seen where needs aren't skillfully explained to other people. That's usually what we see. Everybody wants to create a great environment to work. None of us wanna hate the environment that we go into work with every day. So most people are very open to kind of modifying their behavior if it means it's creating a great space for other people. So we don't see totally competing teams where we can't work in the same space together. Usually what we see is just people having skillfully explained what they need from a team to really feel happy and confident. So I don't know if that answers the question. Something to add maybe to that, Andrew as well is that exercise that we did with the smart goals, the personal goals. So what we see sometimes as well is almost hidden agendas. So needs are important, but also being clear and open about your goals. So if there's a personal goal that you're striving for and the team's not aware of it, often it comes across as like underhanded and like a hidden agenda. Whereas if you're able to articulate like, this is my goal, I want to become an agile coach. And in order to get there, these are the things this is a type of experience. These are the things I want to do. Often if you're able to articulate that properly, the team will actually support you. So I think that a lot of it's about just getting things out in the open and having it open and honest conversation. If the team, if there really is such a clash, often you find people almost self-adject, similar to our skills discussion. If someone's doing something that they don't enjoy all the time, they would often self-adject. They would leave the team. They would say, well, I'm not enjoying this. I'm not aligned or whatever. But often we find if you're able to express it and articulate it to the team, more often than not the team would support you. Yeah. And it's all about conversation. You'll see all the techniques that we've been through. They really do focus on that conversation side. So yeah, speak about it, get it out into the open. That's going to be your first step towards getting to that team environment that you're looking for. There was another question that was posted. So sometimes in high performance teams, people tend to become excessively competitive. This can lead to change in the atmosphere or overall health of the team. What would you suggest to tackle such situations? Interestingly enough, I would actually possibly suggest that that's not as high performance as we think it is. So if we go back to our slide and we have a look, I think Tali, if we go forward like two slides, I think, to the Google, what the Aristotle project identified, there is dependability on each other, right? There is psychological safety to be your basis, meaning there's impact. And one of the characteristics that we don't see, there is a self-preservation, right? So when we're in high performance teams, we almost talk about it being a rising platform, right? We're trying to lift everybody in the team up. We're not doing something just for our own benefit. What we tend to find is that organizational things that are impacting individual team members in the team. So maybe the way people are being remunerated, maybe the way that your bonus or performance appraisals are taking place, but they're very individual focused. When we see that, creating a high performance team is going to be significantly harder, right? Because with these high performance teams, we're looking for where we can trust people. We spoke about what are those characteristics of high performance teams at the beginning, dependability, accountability. We kind of can trust each other. So yeah, so I would kind of say, I think that high performance from the perspective that we're speaking about, we really want it to be a team effort, right? We don't want to have individual heroes within the team at the expense of other people, right? Nobody wants to work in an environment like that. And again, it's hard to create that if the organization doesn't really structure the kind of team dynamics that we've been talking about today. I think one thing you could try in that situation is to really connect people to things like the purpose and the meaning of the team. So what's the bigger picture that they're working towards and try and almost find like a common goal? So often if you're working towards a common goal, you wouldn't want to compete and kind of step on other people. So there are kind of things that you can focus on to try drive a common purpose and a common goal within a team. Are there any, I think we're pretty much out of time. So I was going to propose, are there any additional questions? We have answered the two under Q and A. If there are more questions coming by and Talira and I, I suppose we can go and hang out in the booths or something a little bit later. And like we said, go visit the website, download everything. We really do believe that these techniques have the opportunity to change the environments that we work in, which is why we make them freely available. So feel free to kind of adapt them to your context. And all that we ask for is if you do use one of our techniques, credit us a little bit, but you're welcome to kind of build on them and change them for your space as you need to. And I suppose the last thing for us to say is good luck applying all of these back in your space. Hopefully the virtual ones work well. Please send us feedback via the website if you would like to see new techniques or if something needs to be changed on the virtual templates. They haven't been used as extensively as the physical ones, but we'd love your feedback. And we just wanna say thank you very much for joining us this morning. And we hope you enjoy the rest of Agile India and we wish we were in India to actually have done this in person, but this is a close second. So thank you very much to everyone. Thank you everyone. Thanks for joining us.