PMP Live Class: Agile for Practitioners with Roy Schilling, CSP, ACP & Phill Akinwale, PMP

PMP Exam Radioshow (Project Management)

This episode serves as a comprehensive PMP exam preparation session focused on Agile methodologies, led by hosts Phil and Roy Schilling. The discussion systematically

Key takeaways

• Roy Schilling emphasizes that story points measure relative size and complexity using a Fibonacci sequence, explicitly advising against converting them to hours to avoid schedule padding and anxiety.
• The Tuckman model (forming, storming, norming, performing, adjourning) dictates Scrum Master involvement levels, with high guidance needed in forming/storming and minimal intervention required during performing.

Main topics

• Agile fundamentals & PMP exam preparation
• Estimating techniques (story points, planning poker, affinity estimating)

Notable quotes

"Story points are not based on time. They are based on size and complexity."

Conclusion

The episode provides actionable frameworks for passing the PMP exam while shifting project management

Transcript preview

Speaker 1 (0:01) Good morning and good afternoon, everyone. Welcome. Roy, how are you doing today? Doing well, Phil. Speaker 4 (0:07) It's afternoon for me and I'm excited to be Speaker 1 (0:10) here. This is going to be fun today. Awesome. It's our final round for Agile. So this is day three of three. And last night you talked about PBIs and I just want to ask a few questions so our friends can kick those tires and make sure we can roll along today. So here is your... First question for the day, my friends, and it's about a spike. Speaker 1 (0:38) What do you think? Speaker 1 (0:58) Bye. four three Toot. and won. Speaker 1 (1:06) the pole. Speaker 1 (1:08) Share the results. And here we go. And you can see most of you have chosen B. And that is because B is indeed the correct answer. A spike refers to research, prototype, risk reduction, knowledge acquisition. And these are put into your backlog for you to execute. You may also see them called enablers. Speaker 1 (1:34) Thank you, Roy. All right. So it's a suite. Oh, I wasn't meant to. That's the problem with this Microsoft dual screen stuff. My bad. So I was going to ask you about technical debt, but you get this one for free. Things we should have done correctly the first time, but likely took a shortcut to meet a deadline. Speaker 4 (1:59) Yeah, and just a real quick one on that one. So in the Agile Practice Guide, they also make a reference to deferring cost. And I wanted to make sure that you understood what that means. So if you think about it, if we're taking a shortcut to meet a deadline or something of that nature, then we're technically, technically they're right. You're deferring the cost of doing it right, right? So the intent would be that you're going to defer that cost. That's a debt that you need to pay back. So you'll do it right in the second go round, right? That's kind of the idea. So that's where that comes from. But both descriptions are Speaker 1 (2:32) actually Speaker 4 (2:33) correct. Speaker 1 (2:35) So here's our next one. Which of these describes a defect? Speaker 1 (2:54) Five, four, three, two, and one. Perfect. You both know all about defects with the nature of what you do. Great job. The answer is B. Okay. Speaker 1 (3:11) One more for the road. Speaker 1 (3:15) Which of these describes a user story acceptance criteria? Speaker 1 (3:21) This is called the Gherkin format, Speaker 4 (3:23) as Speaker 1 (3:24) in the pickle. Speaker 1 (3:51) All right, five, four, three, two, and one. Here are the results. Majority have gone with the option A, given, when, then, which is what Roy did teach you. Now, that's not the only way people do it, but Roy, any comments? Yeah, I mean, Speaker 4 (4:12) so there is actually a reason to stick with given, when, then, in that specific format. It's not going to be so important in your industry, but this Gherkin format in the software world, there's a tool that can actually read. this format, read the text and turn it into a series of automated test cases. So it needs to be in that specific format in order for that tool to be able to read it properly. So it is preferred that you call it given when then, but if you're not using that tool, you're not necessarily held to it. It's not about dogma. So you could change it up if you want to. But if you're in the IT industry, you're going to want to keep it in this format. Awesome. Thank you, Roy. Well, that's all I've got. All right, let me share my screen and just to follow up on that one so that you understand where the word gherkin comes from. So that tool that I was just talking about is called Cucumber. Get it? Cucumber pickle. Yeah, it's a really stupid one, but I didn't come up with that joke. It's not my fault. Don't blame Speaker 1 (5:14) me. Speaker 4 (5:15) Okay, so welcome back, everybody. Let's jump right in. We left off talking about roadmaps. It's just a very quick little discussion about roadmaps. Again, they are a plan. that hopefully is owned by the business. It's basically the business saying, this is what we would like you to do. And then the teams doing the work have the opportunity to collaborate and say, okay, well, this is what's possible. And they can move things around based on the needs for sequencing, all that kind of good stuff. Something I didn't really mention yesterday was what the plan really is, what a roadmap really is. So often when we see a schedule, we think of it as a commitment. Well, this is going to sound weird, but a roadmap is actually not a commitment. We consider it only a plan. And the reason for that is that. we expect things are going to change. So if it's a commitment and we're expecting it to change, it's not much of a commitment, is it? So we back away from that word and we back away from the commitment word. And that's very intentional because we want it to be viewed by the business, by those stakeholders as a plan to what we would like to get done, what you are asking us to do and what we are saying we will do until that plan changes. And as soon as the plan changes. the commitment changes to go with it, right? So we stay away from the word commitment as much as possible. And it's not like we're trying to avoid it. It's simply that with changes happening frequently, having that kind of a commitment, it just doesn't make any sense and generally causes bad behaviors. Those behaviors could be, if I've committed to something and I'm going to be held accountable for making that commitment, then I might resist change. So we tend to stay away from the commitment just for a little while until... where we can commit at a reasonable level and change is more managed. Speaker 4 (7:00) All right, so let's now move on into and talk about storyboards. So storyboards, you can absolutely make use of these today. It's basically the same thing as what's called a Kanban board. That's K-A-N-B-A-N. Kanban is another process that we'll talk about a little bit later on today. So the idea with a storyboard is it's a visual control mechanism. This came from manufacturing. And the basic concept is that all work that is currently being worked on is on this board. So you have at a very minimum. You have a to-do state, at least one or more progress states and in-progress states, and then finally a done state. So it's kind of like a to-do list on steroids, right? So there's the stuff that's coming up next. There's a couple of, one or two states or however many states necessary to show the work in progress. And then finally the work that's completed. Now those in-progress states, the ones in the middle, like in-progress, these are just examples. So you define whatever your process flow should be. So consider what a process flow or a value, we actually prefer to call it a value stream, what a value stream would look like for a drawing, just as an example. I know I've been using that as an example a lot, but it's something that I can latch onto. So the process flow for a drawing. So you might have some initial stages of that drawing. You might have the work of the drawing. You might have some reviews of that drawing. There might be additional sign-offs. All of those would wind up being states. that represents the flow of that value stream, the value stream being then, of course, a drawing. So each of these states represent the status of the work, where it sits at any point in time. Now we use these boards as... an indicator of status, right? So that we don't have to do status reports. These boards tell you where everything is, tell you who owns it, where it is, if it's blocked, if something's going wrong, you know, you have a whole bunch of information on this. It's also known as something called an information radiator. The information radiators, the idea with that concept, you know, it's a $25 word there, right? So the idea with information radiators. is that we want information from the team to be continuously 24-7 radiated from the team, always available. It goes back to that transparency and honesty thing. All work is always visible, always open, so that anyone can look in and see what's going on at any point in time. Okay, that's our goal. Now here is see a collection of things you've got stories and spikes. It's whatever the team is working on. And the idea would be is when you start working on something, you drag it from to do drag it to in progress work on it. And when the work in progress is done you move it to the next state. And this gives you an indicator of what's happening now the tools that allow you to do this besides just, I mean, you can do post it notes I've got a right next to me on the right hand side I've got a sticky wall, where I have all of my post it notes for the work that I'm working on. So you could use something as simple as that, but you could also use a tool, right? So there are tons of tools out there like Trello and Jira and version one and Teams plan, the Microsoft planner. There's tons and tons of tools out there. We're not recommending any tools. We're just saying there's lots of stuff available for you. Now, a lot of these tools, they will allow you to configure these boards and more importantly, they collect. data. So every time you drag something from one state to another, it collects an audit trail. So you can see who's doing it, what it was, how long it's been there, when it happened, all that kind of good stuff. And it records how long work has been in a particular state. In fact, many of the tools, what they'll do is they'll give you a visual indicator that something has been sitting in a particular state for a long time. So one of the tools that is very popular in the industry will display a collection of dots. across the bottom of the card. So if every day that something's been sitting in that particular state, a new dot appears. And we use those as indicators that the more dots, the longer it's delayed, something's wrong. So it gives us an ability to talk about it. A lot of dots, something's wrong. We need to discuss, right? Maybe there's a blocker. So these tools collect all that data, and you can make use of that data to improve, help identify where there are bottlenecks, where there are challenges, where some things take longer than others, different kinds of work. All of this data is collected to help us improve. Okay? Now, the team should be managing this board themselves. The team is responsible for keeping this up to date, and that reduces the statusing. So just a minute or two a day in the tool, and... you get all of this stuff, all this really cool information. We don't want people in the tool. It's not about the tools, right? If you remember the manifesto, people over tools, right? Processes and tools. It's individuals and interactions over processes and tools, right? So the tools are important. The people, that's much more important. We want them doing the work and not spending a lot of time in the tools. But they are important because they give us great data. Speaker 4 (11:57) Now, like I said, the team is responsible for this. They are supposed to keep it up to date. You don't need a project manager following behind them, sweeping up after the elephants, right? The team is supposed to take accountability and ownership of this and manage this. Now, here's something that I would recommend to you. A little later on, we're going to talk about Kanban. You can use this approach. in a Kanban fashion in your current projects today, and you're going to get better. And it's not about software. It's not about IT. It's simply about getting work done. And this visual allows you to see where your work is. You always know what's going on because you get this visual that's being discussed. Now, this is typically also what the team has up when they're doing their daily scrum. So they can talk card by card by card, what's going on and where they are and where they're stuck, right? Great visual. to help you get a better understanding of what is currently going on. All right, now I mentioned yesterday that tons of metrics. There are tons of metrics that we can track in Agile. It doesn't mean that we should track everything. The general view with the metrics is that we only track what we need to and no more than that. And you only track it when you feel there's real value in actually tracking it. So there are a few things that we have to track, some very basic metrics that we want to track. Anything else is really just kind of a bonus. So we want to track things like velocity. We'll talk more about velocity soon. We want to track how much the team committed to versus how much the team completed. Some very, very basic metrics. Burn charts. We'll talk about that in a minute as well. These are things that are very easy for the teams to work with. There's very low overhead. And it's kind of expected that we track these things. There's lots of other things that we can track as well. How many times things are blocked. We track things like quality metrics, like escaped defects. An escaped defect is a very important metric. Basically, what it means is that it's a defect that escaped our process. And when we see an escaped defect, we're going to have a conversation about it. How did it get out of our process? How did we miss it? And we're going to talk about it and try to close that gap so that other defects don't escape. And we use this data primarily for the purpose of improving. Now, some of it is for tracking progress. Some of it is used for forecasting, but almost all of it. is used to find ways of getting better. And that's a really important concept. You don't want the team to get beat up when they have metrics that are showing some challenges, right? If they're having a challenge and the metrics are showing it, then let's talk about how to get better. Let's talk, thanks for showing us this. Let's be honest and open. Now, what can we do to help you get better, right? So a couple of suggestions for metrics. You can track a lot of stuff. You shouldn't track everything. Don't do that, or you're going to have so much overhead on the team. One of the rules that we use, or one of the techniques that we use, and this comes from Lean Manufacturing, it's called the five whys. The five whys is a process or a technique to get you to root cause. When someone is asking you for something, don't just do it, right? Never just do it. We want to get to the why. What's the root reason? What are they trying to solve? by getting this thing. So the theory is that if you ask somebody why in various ways, up to five times, you'll get to the true reason that someone is asking for something. Often when they're asking for something, they're not actually talking about why, or they maybe haven't fully thought out why they need it. They're just saying they need it and they'll give some reason for it, but it's not really the root. So getting down to that root cause, maybe you can find better ways of doing it. Maybe that doesn't involve adding a new metric. All right, some of the basic metrics that you're going to track, you're going to track burndown charts, burn up charts. We'll talk about those in a minute. Completed versus committed, which is what I just talked about. And obviously some quality metrics as well. We always want to produce high quality. All right, now this is a burndown chart or an example of a burndown chart. Now this one, this example of a burndown chart shows hours remaining. We're going to be talking about how to estimate shortly. We typically don't estimate using hours, but we'll get there in a minute. So don't worry about it. So this shows hours remaining. So the first day of the sprint, you total up the total number of hours that you expect are going to be necessary to get the work done over the course of the sprint. So basically all you do with that is the team estimates the work that they're taking on in the sprint, how many hours they need to get it done. And again, you total it up on day one of the sprint. The tool will generate that ideal burn down line. That's that red line going from the total hours down to zero by the end of the sprint. And the deal, the goal would be to burn down hours, burn down the work until you get to zero by the end, by or before the end of the sprint. Now, the purpose of this chart is to show you progress along the way. It kind of shows the cadence of the team. Is the team completing work on a regular, consistent cadence to get things to zero? before the end of the sprint. Now, this example here, you can see what happened. On day two, all of a sudden, we jumped from 80 hours to 90 hours. And some people might be concerned about that. Something went wrong, right? So we need to go jump in and investigate. Don't. Actually, let the team figure this out. Ideally, often, quite honestly, there's nothing wrong. We just maybe discovered something. Maybe we discovered there's more work than we expected. And that's normal. That happens quite often. So the important thing is that we get the reality. We get a view of what actually is happening, not just hopes and dreams. We want to see the truth, the reality. And then we can have intelligent conversations about it. If we don't have that transparency, then we can't make adjustments. So if I saw that, if I was the scrum master and I see this, first thing I would do is I would say, okay, well, I see that we've increased the number of hours here. Are we okay? Do we need to do anything? Do we need to make any adjustments? Can we absorb this time? Or do we need to have a discussion about taking something out of the sprint? So the intent of this chart is not to beat the team up. It's to find out what we can do to help them, right? What can we do to help you get down to zero? So in this case, maybe the team feels, you know what, we're okay. Let's see what happens. Let's let it go for a little bit. And then we'll make adjustments as necessary. So then we get down to maybe day, looks like like a day, day five, somewhere around there. And then we flatline for a couple of days, day four to day six, it looks like we flatline. So this is something else that we want to watch out for. Now, maybe nothing at all. It might be perfectly fine. It could be, maybe we've got a holiday. People are out on vacation or something like that. Or maybe we have some impediment that stopped the team from doing work, and we should talk about that. Or it could be that maybe somebody is out and we're not making much progress. Or another thing that could happen is maybe the team stopped updating the board. That happens a lot, a lot more often than you would like it to. So in those cases, that's a conversation. Say, okay, what can we do to get this back updated again? If you are not updating the board, this chart is useless and we can't tell where we are. So from a team's perspective, the benefit to them, keep this updated and I don't have to ask you for status. It's just that simple. It's less work to update the board than it is to bother you with questions, right? Then we get to day six and it looks like between day six and day seven. Speaker 4 (19:29) The team was able to adjust and they got a whole bunch of work done. Maybe somebody came back from vacation or the impediment was resolved, whatever it is. They were able to absorb the work and get back on track again. And they got all the work done. So the purpose of these charts is to start conversations. Maybe there's nothing wrong at all. Don't just say, oh, the chart's off, so something's wrong. It's never going to be perfect. It's never going to be exact. The intent is to start a conversation. That's really all. And see if we can do something to help the teams. Now, this is a burn-up chart. It's a similar concept, but what a burn-up, burn-down chart tracks work remaining. A burn-up chart tracks work completed. So there are two different perspectives to give you the full story, the full view of what's going on. Now, this one is a release burn-up. or it could be a feature or an epic or something like that. You can do burnups on those as well. So this shows you three basic things. It shows you the total scope, and that's that yellow line that runs across the top. Then there's the red line, which is your projected needed completion ratio in order to get everything done. And then the green line, which is the actual. So this is kind of a plan versus actual and a total, right? So it gives you the three different perspectives. So now in this case, if you look at sprint three, the yellow line went up. Now that's an indicator. That's something that we want to talk about. Someone added more scope, right? We added more scope to the sprint. Now keep in mind, remember this. The team has fixed capacity. They can't do more than what they have traditionally done in the past. Maybe they can every so often, but we want to make sure that we have a conversation and see if the team is okay with it, right? Because maybe they can't do more and we should honor that, right? So if something was added to the sprint, what we should do, or I'm sorry, to the release, if something gets added, you should look to see if you can take something else out of equivalent size. Maybe it was the right thing to do. Maybe we did need to bring that scope in. That's perfectly fine. We want to defer something of lower priority when something new comes in. Keep in mind, fixed capacity at all times. If you bring something in, something comes out. Now you can see what happened here. And this is just an example, obviously. So the red line adjusted as it would, because that's a forecast. But the green line didn't quite make it. So here, based on this chart, we have a reason why we didn't make it. You added scope. And if you take a look at the green line, when the scope was added, we were actually behind schedule, right? So they added scope and we were just behind schedule. Maybe that was not a good idea, right? So. Look at these charts, track the progress. These are very simple visual mechanisms of tracking progress. Notice something though. We don't have percent complete. Nowhere in this do we talk about percent complete. And that's because we use these charts instead. Percent complete is very misleading because often people have different views of percent complete of what it means. So this is a much more realistic view of working product as the primary measure of progress. Remember principle number seven. We keep coming back to that. So just very quickly, I have to share a funny story. This happened a long, long time ago. It was like 12 years ago I ran into this. So I was working with a project manager. At the time, I was a development manager and I had my teams. Speaker 4 (22:50) And this project manager was new to Agile. She had never done it before. And she insisted that she had to get percent to complete. And in her defense, the organization required that percent complete was always tracked. Every single week needed an updated percent complete. So I kept telling her, look, in Agile, percent complete really doesn't. mean the same thing. It doesn't mean that much. I can give you these burn charts and this will show you reality of what we're actually working on. Percentage complete is kind of a guess, right? And it may not mean the same thing that you think it means. And she said, don't care, got to get percentage complete. I said, okay, so here's what we're going to do. Speaker 4 (23:28) we're going to meet every week. I'll meet on the, we'll meet on the first day of the sprint, the middle of the sprint and the last day of the sprint. And I will give you a percentage complete of the sprint. And she goes, cool. That's all I need. Okay. All right. Fantastic. You got it. So the first day of the sprint, we were 0 % complete middle of the sprint. We were 50 % complete. And the last day of the sprint was a hundred percent complete. Never really caught on that I was just really kind of gaming those numbers. It didn't matter because she got a percentage complete. And that's a challenge with a lot of the metrics that we track. They don't always mean anything or we're just collecting them because it says to collect them. So any metrics that we do track, any progress reporting, make sure it's meaningful and valuable. Or, you know, you're just wasting your time. She was happy she got her numbers. The organization was happy they got their numbers. It took me like five minutes every time. So it didn't really cost me very much. And I kept my teams out of it. Everybody won, but it was an absolutely meaningless metric. Okay. So keep that in mind. All right, let's move on. Let's now talk. This is a fun section of our session. This is talking about building agile teams. Now, this is stuff that's definitely going to be in the PMP, in the exam. So watch this stuff and keep in mind what we want you to get. is the understanding of what we're talking about here, not just memorizing these things and these terms. We want you to understand why we follow these approaches. And the reason is, is not just that you can use this in the real world, but when you get questions on the exam that are people related, if you understand the intent, it'll make it a lot easier to answer those questions. Okay. So start out with some memorization. and then get yourself to understanding and it's going to make your exam a lot easier. Okay. All right. So building agile teams. First things to remember is we want to build small teams, 12 or less. The, the actual size, the given the size in the scrum guide says anywhere between three to nine people is the appropriate team size. You can go a little bit bigger. I honestly don't like teams of three. I think that's way too small. I prefer teams of five at a minimum. So five to nine is kind of that sweet spot. Seven is the perfect size team, but you can go a little bigger, a little less, and that's perfectly okay. The basic idea is small teams, right? The team should have complimentary skills. They're committed to a common purpose. They're committed to working together. They hold themselves mutually accountable. So I'm going to hold myself accountable. And I'm going to hold my team members accountable, right? So that means if someone's not doing their job, I am empowered to call that out and say, hey, what's going on? What can we do to help you? Things aren't getting done. You seem to be challenged. What's happening? And what can I do to help you get past that problem? So it's not like we're calling them out and being critical. We're simply saying, we've noticed there's a problem. What can we do to help you to fix this problem? We're also trying to encourage T-shaped skills. The other term for it is generalized specialists. And basically what that means is that we have specialists, the people that are really, really good at certain fields or certain skills, but we also expect each team member to be able to step outside of that skill set and help the other team members out, right? So that we're working as a team. It's not a collection of individuals. It's not a working group. It's a team that works together and helps each other out. All right. Now, one of the models that we make use of is this. Definitely memorize this one. Remember the Tuckman model. You may already be familiar with it because, you know, it's pretty normal. It's pretty standard. This is not an agile concept. This has been around for a long time. The Tuckman model. is a simple set of stages that teams go through as they're learning, as they're becoming more mature and becoming healthy teams. And we tend, I know it says maturity journey, but we're trying to back away from some words like the word maturity can sometimes have some negative connotations like, you know, that you're immature and that's not really the intent. So we tend to call it more about healthy, you know, that the team is healthy, that they're exhibiting the right behaviors and that's what we're looking for. But maturity is okay too. You know, you get the idea. Now, this is the Tuckman model. It's got the five stages, forming, storming, norming, and performing. And then the final stage, maybe an optional stage, is adjourning. And that's not a good stage. So we'll talk about that in a minute. So there are other models as well, but this one's fairly popular. So the first stage is forming. This is when you've just gotten the team together. They're just starting to get to know each other. This is a very inefficient stage. The team isn't really challenging each other. They're very politically correct. They're afraid of offending each other. They don't want to seem critical. They're not going to really challenge each other at this stage because they're really just kind of getting to know each other. Now, at this stage, the team is not highly productive. They are getting work done. And it's not a bad stage. It's just not a great stage. So in this stage, we want the facilitator, the scrum master, to be very involved. The intent here with this model is to show where the scrum master really needs to be involved to facilitate the quick progression across these stages. That's part of the job of the scrum master, is to progress the team through these stages to get them to norming and performing as quickly and efficiently as possible. So in the forming stage, high level of engagement, sometimes being prescriptive and telling the team what needs to be done. We don't want to do that too much, but sometimes a new team needs to be told what to do. And that's okay to do it. We want to very quickly, though, start backing away from that and take a different stance of serving the team and leading the team rather than managing the team. All right, next stage is storming. Now, this may be a little bit better, but it also can be somewhat negative sometimes. This is where you've got people that are getting to know each other a little better, but you might have some behaviors that aren't necessarily good for collaboration. Like you might be jockeying for power, people trying to find control, things like that. There might still be some distrust here. You might have alliances, especially if you have big teams. You start seeing alliances form. This is why we don't like, one of the reasons we don't like big teams. Small teams, you don't get those clicks forming quite as often because the team is small enough, they are a click, right? So again, the facilitator needs to be heavily involved at this stage. Might be focusing more on conflict management, making sure we're talking about agreements. And by the way, in the forming stage, that's where you start with your team agreements. Right at the beginning. Everybody needs to know how to work together. Everyone needs to agree that this is the right thing to do, the right way of working. And then we can refer to those agreements as we're progressing through the stages. Speaker 4 (30:07) This is where in the storming stage, this is where the facilitator really starts to shine because they're dealing with conflict. They're dealing with, you know, behaviors and coaching and encouraging and all that kind of stuff. Maybe a little less prescription at this point and letting the team start to form, but they need to be heavily involved and facilitate good discussions. They might be having conflict, but not healthy conflict. There is healthy conflict. Disagreements, that's a good thing, but we want to do it in a healthy way. So the next stage is then norming. Now this is healthier, and a lot of teams just stay in the norming stage, they may never get to performing. This is where the facilitator doesn't need to be quite as involved. The team is doing a lot of things on their own. They're starting to disagree with each other in a more healthy pattern. Not always right it's not perfect, but at least they're having good. diversity of ideas, intentional diversity of ideas. So the facilitator doesn't need to be as involved and maybe they can take a step back and let the team do their own facilitation. Now, eventually, hopefully we get to the performing stage. Now this place is awesome, right? Your team is just knocking it out of the park. This is where they're doing things where they have what we call full divergence and then convergence. So we will intentionally disagree with each other. We will take opposite. perspectives and opposite views in order to encourage the discussion of disagreement because it's healthy conflict. Conflict is good when managed and healthy and for a positive purpose. So we want constructive criticism. We want things to have some healthy conflict. We want disagreements, full divergence, and then convergence. This is where there's a lot of question of, do you even really need a scrum master? If your team is facilitating itself and they just... They just do the job. They're having their own meetings. They may not even need a scrum master. So there's a lot of conversation in the Agile community. Maybe you don't always need a scrum master for the team. And that's okay, right? I've worked with a lot of teams that don't have scrum masters because they're just that good. They're all adults and they just do their job. Now, the last stage is adjourning. And hopefully you don't get here very often. This is where collaboration ends. And that can happen for a lot of reasons. If you change the team up, They might go into a journey and they stop collaborating. If you take away the process, right? If you take away things they don't like or that they do like rather, then they might go into a period of mourning where they're just not performing very well. They just stop talking to each other and it's not a good place to be. We again, wanna get them out of that stage and back in through the process and back up to norming and performing again. Now keep in mind, this is not a once and done. This is not go through these stages and boom, you're good and you can walk away happy. If you make a change to the team, if someone leaves or if you add someone, you might have to go all the way back again to the forming stage or storming at least. So this is very normal for that to happen. That's another reason that we want stable teams. The longer a team is together, the less time you're spending navigating through these various stages. They can just progress and they get better. Of course. Teams are going to change every so often, and we need to take that into account, but try to keep them stable. Don't do it intentionally, right? Let the team figure that stuff out themselves. All right, high-performing team. They are self-organizing rather than role or title-based. A great team does not care about hierarchy. They are just a group of peers working together. That's a really different dynamic. If you're working with... If you view somebody as a manager because of their title or a leader because of their title, then people react very differently because with that title brings power, brings authority. And that's why we discourage calling someone team lead because that you're giving them a title and you're putting them on the team and people will react very differently to that person. They are empowered to make their own decisions. And we're talking about a lot of power, right? They can decide how they're going to do the work, best way to do the work, how they're going to organize. make sure that this team feels like they can make their own decisions and you get better engagement as a result. Just a quick story on that. I was working with a manager once at a team and I said, okay, you got to back away from your teams, let them make their own decisions. And this manager said, yeah, I have no problem with that. The team can make any decision they want as long as it's about lunch. Speaker 4 (34:30) I wasn't sure what to say to that. That was a really scary moment. It's like, wow, that's not good management. That's not what we're supposed to be doing. You hire good people. If they can't make up their own minds, maybe you either didn't hire the right people or you're a bad manager, one or the other, right? All right, so they are also committed to, oops, I skipped one. They believe they can solve any problem. Now, what I mean by this is that If you give them something to solve, here's a thing they need to do. They will go get the information they need. in order to solve that problem. And that might mean bring other experts in, go ask for training, do what they have to do to get the skills, the knowledge, the information to go off and solve that problem. So they may not always be the best people to solve that problem, but they will do it because they feel that they can do it on their own, right? They will do what they have to do in order to solve that problem. Now that doesn't mean success at any cost, which takes us to the next one. They want to be successful, but not at any cost. They're not going to kill themselves, you know, by working crazy hours. They're not going to- to beat each other up or beat themselves up. They're going to be professionals. They're going to be consistent professionals, sustainable base, and they're going to be successful without trying to hurt themselves and each other along the way. They own their decisions. They are accountable. They hold themselves accountable. They take ownership and responsibility. They are adults, right? If you want a great team, they've got to be adults and you've got to treat them that way, right? Motivated by trust, not fear and anger. They are consensus. As I mentioned, divergence and then convergence. And they are in constant constructive disagreement. That goes back to that positive conflict, the healthy conflict. We want to make sure the teams have no problem disagreeing with each other because they know they're doing it for a positive reason. Speaker 4 (36:19) All right, let's dig into servant leadership. So servant leadership is a very important concept. This is about how to be a good leader. The concept of servant leadership is not that you are just serving a team. You are leading the team first and then serving them secondarily, leading them saying, this is where we're going. This is why we're doing it. And then what do you need for me to get there? Think about it like, you know, the JFK mission to the moon statement, the speech that he gave. He didn't say how he was going to do it. He didn't say that I'm going to be there telling you what to do. Because that person, you know, JFK didn't have the knowledge to make that happen. But as a leader, he was able to provide the stuff the teams did need. Money, direction, air cover, all the things that teams needed in order to get there. A leader is able to supply that kind of stuff. So that's the serving part, leading them by saying, follow me. This is the direction we're going. Here's the clarity that we need to make sure that you understand what we're doing, why we're doing it, all that kind of good stuff. Now tell me what you need and I will get it for you. I will clear your path so that your obstacles are being removed, impediments are out of the way. I will escalate as necessary and I'll make sure you have everything you need to get that job done. Now, this can be very difficult for leaders to migrate to this technique. They may feel that there's a loss of control if they're not telling people what to do. Well, telling people what to do is management. That's not leadership. And I would suggest that leadership is not a title. It's an attribute, right? It's a behavior. There are natural leaders that don't have the title to go with it. Just calling someone leader also doesn't make them one. It just puts them in the position where they could be a leader. So we want to make sure that we are very distinct about those. They are different. Having a title as a leader does not mean they actually are leaders, right? You get the idea. Speaker 4 (38:17) All right. We mentioned this a little bit earlier, team working agreements. Big fan of doing this. These are your team policies, your agreements, your best, your practices that you want to put in place, your standards of how to behave as a team. And you're going to put basic things in here, things like your cadence calendar. Cadence calendar is simply when you're having your meetings, right? Remember all those scrum events? It's basically your recurring meeting events. And this is just an agreement. We don't want to just send out the invites and say, be there. We want to have an agreement that these are the appropriate times to do these meetings. Think about time zones and those kinds of challenges. We've got to work out what's possible and make sure the team all agrees. Yes, I can agree to this. And yes, I will be there on time every single time. Right. And make sure that you have some good, healthy discussions about what's realistic. If someone has some kind of a conflict, you don't want to be changing your meeting cadence. You know, don't be, I shouldn't look and see your daily scrum changing all the time because people have conflicts. Same time, same place. It's an important meeting and the team should be given the air cover so they can show up at this meeting. I was working with one organization. I could not get the team to show up to their daily scrums. And I found out it was because they had all these other meetings. So I said, all right, well, let me do this. If I went to management and said, look, here's the problem. The team is not able to do their daily scrum. Can I get these meetings moved? Would you be okay with that? And the team was like, no,