Advanced Agile Project Management Masterclass: Leadership, Scaling & Team Performance

1. Welcome to the Project Management Advanced Course!: Welcome to Agile Project Management, leading and improving Teams master class. My name is Luke Phillips and I'm a project manager and Agile practitioner with over seven years of experience running cross functional teams, coaching Agile practices, and delivering projects across a variety of industries. We will begin by exploring what it means to lead an Agile team. You will learn the principles of servant leadership, understand when to coach, manage, or direct a team, and develop facilitation techniques that make Agile ceremonies more productive. We'll also discuss how to handle difficult conversations in a way that builds trust rather conflict. Next, we will take retrospectives to the next level. Instead of running the same meeting every single sprint, you'll discover new retrospective formats and learn how to turn discussions into meaningful improvements that stick. We'll then move into scaling Agile, exploring when larger frameworks like safe, less and scrumm scale make sense and just as importantly when they don't. You will learn practical approaches for coordinating multiple teams without adding unnecessary complexity. Cover quality and risk management, learning how Agile teams build quality into their work, manage uncertainty and reduced risk through experimentation. Finally, we'll focus on continuous improvement, team health, and sustainable productivity. You'll learn how to create a culture where teams keep learning, improving, and delivering value all without burning out. By the end of this course, you will have the mindset, the tools, and leadership techniques to guide Agile teams more effectively and support long term success. Let's get started. 2. From Doer to Leader: Welcome. This course is about a single career defining shift, the move from doing the work to leading the people who do it. You can already run a solid, Agile process. Now we're going to build the skills that turn a capable practitioner into a leader that others want to follow. In this first short lesson, let's frame that shift and look at what's ahead in the course to come. So here is the first thing to understand. Leadership is not just doing the work scaled up, doing the work well and helping a whole team do it well are genuinely different skills. One that you've probably spent years building, the other starts now. And the clearest sign of the shift is how success is measured. It used to be simple what you personally delivered on any particular week. From here on, your success is the team's success, what they delivered, and how much they grew while doing. It's a very different scoreboard, and getting comfortable with it is the whole journey. So what changes a team when you lead it? It's the same goal, but a completely different job. So let's make this a little more concrete. As a doer, you deliver the work, you decide, you build, and you're judged on your own output. As a leader, you enable the work. Team delivers, you clear the path in front of them, and you are judged on their success, not on your own success. It's worth sitting with that for a little while because it can feel strange at first. Your instinct, which may have been honed over years, is to jump in and solve the problem yourself. Leadership often means resisting that instinct and building the person who'll solve it instead. This is a promotion in responsibility, not just a change of title. So let's look at what's ahead in this course and what we'll build together throughout the course. First, leading people, serving your team, coaching them, facilitating their meetings, and handling the hard conversations. Then better retrospectives, running the kind that actually change how a team works rather than the kind that everybody quietly dreads. Then scaling, coordinating more than one team without drowning everyone in processes. Finally, continuous improvement, building a team that keeps getting better on its own without you having to drive every single step. So, that's the road ahead from doer to leader. It's a bigger shift than it sounds, and it is a deeply rewarding one. Thank you for joining me. In the next lesson, we'll start with the foundation of it all, what it really means to lead a team by serving it. I will see you there. 3. Servant Leadership in Practice: Welcome back. In this lesson, we're going to look at something called servant leadership, which is the foundation that everything else in this course rests on. The name can put some people off as it sounds a little soft, but in practice, it's one of the most demanding and one of the most effective ways to lead that exists. So by the end of this lesson, you'll know what it actually means, what it looks like day to day, and just as importantly, what it is not. Let's start with the core idea, and it's a genuine inversion of the usual picture. In servant leadership, the manager is there to serve the team, not the other way around. The traditional image has the team working to make the leader look good. Now, flip this. The manager's job is to build the conditions in which good people can do their best work. So the leader sits underneath the team holding it up rather than on top of it pressing down. So everything practical we'll cover in this course flows from that one reversal. So that whole mindset lives in one changed question. So most leadership quietly asks, How do I get more out of the team? It treats the team as a resource to be squeezed for output. Now, servant leadership asks something different. What do they need to succeed? It treats the team as people to be supported and trusts that the output flows from that. So it's the same team and the same goals and the same deadlines, but it's a completely different relationship, and the people can feel which question you're really asking within about a week of working for you. So this isn't just a vague attitude. This is a set of concrete daily jobs. And here we have four of them. So first is remove blockers. Spend your day clearing obstacles that are sitting in front of the team, like the approvals, the dependencies, and the broken tools. Next one is to shield from noise, so absorb all the politics, the last minute interruptions, the anxious pins from above, so that your team can actually focus. The next is to grow people, so handout work that stretches them a little, but also provide the support to allow the team to rise to. And finally, is make it safe. So build an environment where someone can admit a mistake without fear because that's the only way that problems surface while they are still small. Now, probably one of the most common misunderstandings and it's worth correcting head on is that serving the team is not the same as pleasing the team. Servant leadership is not about being nice, avoiding conflict, or saying yes to everything. Still hold standards. You still say no. You still have the hard conversation when it's needed. In fact, holding that high standard itself is an active service because it's how people grow. So picture two dials both turned up high, support and standards. You genuinely have your teams back every single day. And you expect their very best. Caring about people includes expecting a lot of them. So drop either dial and you're not serving anyone. So here's a simple way to keep yourself honest. Here are four questions to end the day on, then you can run through them at the end of any day. First is, did I unblock someone? Name one specific obstacle that you actually removed for the team today. Next is, did I protect their focus? Did you absorb noise coming down from above, or did you just pass it on to the team straightaway? Next, is did I develop some anyone grow a little because of a choice that you made, a task that you handed over or a question that you asked instead of answering? And finally, is, did I give the credit away? When something went well, whose name did you put in the spotlight? If you ask those four questions, honestly, each evening, you will become a servant leader far faster than any book will take you. So servant leadership, then, is demanding. It's not soft, it's high support and high standards in service of the team's success. So if you get this foundation right, everything else becomes easier. For joining me. In the next lesson, we'll look at three distinct modes of leading, coaching, managing, and directing and when to reach for each one. I will see you in the next one. 4. Coaching vs Managing vs Directing: Welcome back. In this lesson, we're going to sort out three terms that get muddled up all the time in relation to leadership, coaching, managing, and directing. They are not personality types, and none of them is the only right way to lead. They are different tools, and a good leader picks the right one for the right moment. So by the end of this lesson, you'll know what each one is. When to use it and the mistakes to avoid. So first, the key idea, leadership isn't just a single style that you settle into and you defend for the rest of your career. It's three modes, and the real skill is choosing the right one for the person in front of you and for the situation you find yourselves in. So instead of asking, am I a hands on leader or a hands off leader, which is the wrong question in the first place, learn to move fluidly between all three modes and on purpose. So let's have a look at them all. So picture a spectrum running from taking control on the left to handing over control on the right. On the left is directing. You direct, they follow. You give clear instructions, and you expect them to be carried out. In the middle is managing. You coordinate and you track and they execute. You organize the who and the when and you keep the work on the rails. And on the right is coaching. You ask, they decide, you help someone find their own answer. Rather than giving it to them. So the single most useful rule here is, the more capable the person, the further to the right you can safely move them, and the skill and the trust that they have loosen your grip. So how do you actually choose? You should match the mode to the person and the moment. So in a crisis or anything involving safety, you should direct. Be clear and fast. This is not the time for open questions. With a brand new team member, for example, you could start by directing, then moving to managing as they find their feet. And when you've got known work and several people who need coordinating, managing would also be your home base. You need to organize it and track it. With a capable person who's ready to grow, you should coach them. You should resist the urge to tell them and ask, instead, the situation chooses the mode, not your mood that particular morning. Of the three modes, coaching deserves special attention because it's the one that grows people, and it tends to be the one that leaders skip when they are busy. So here's the trade off in one line. Directing fixes today's problem. Coaching builds someone who will need you for that problem the next time. Directing is faster right now. Whereas coaching compounds. The team that gets coached, however, gets steadily more capable until one day it barely needs you, which is exactly the goal. So in practice, coaching means asking open questions rather than giving answers, letting people struggle productively with a problem, and resisting the powerful urge to rescue them the moment that they hesitate. The struggle is where the learning actually happens. Finally the mistakes which are almost always related to the right tool, but at the wrong time. So first, is directing capable people. Standing over an expert and dictating steps insults them and also throws away the judgment that you hired them for. Next is coaching in a crisis, asking, What do you think we should do while the building is on fire? It's not the right moment to ask just direct. Next, never leaving directing. If you always make the call, your team never listen, sorry, your team never learns, and it quietly becomes dependent on you, which is a trap that you built for yourself. And finally, coaching without safety. If people don't trust you yet, your open questions may come across as traps, not invitations. So trust should always come first. So we have three modes directing, managing and coaching chosen deliberately with a long term lean towards coaching as your people grow. Thank you for joining me. In the next lesson, we'll get practical about the meetings themselves with the facilitation skills that make agile ceremonies actually work. I'll see you for the next one. 5. Facilitation Skills for Agile Ceremonies: Welcome back. In this lesson, we're going to focus on a skill that may quietly decide whether your meetings are useful or painful. And that skill is facilitation. So every Agile ceremony, the stand up, the planning, the review, the retrospective is only as good as the person leading it. So by the end of this lesson, you will know how to prepare a session, how to keep it moving, how to handle the tricky characters, and above all, how to stay out of the way at the right moment. Let's start with what the job actually is because it can sometimes be a little easy to get wrong. Your job as a facilitator is not to have all the answers. It's to help the group find themselves. So it's a clean division of labor hiding in that sentence. You own the process, and the team owns the content. You are responsible for how the conversation runs, whether it's focused, fair and productive, and the team is responsible for what it decides and the content it's going to produce. The moment you blur that line and you start pushing your own answer, you stop facilitating and you've started arguing. If you hold that division, everything else good will fall into place. So most bad meetings are actually lost before they even begin, and this is in the lack of preparation. So here are three things that you can sort out beforehand. First is have a clear purpose. So one clear sentence on why you're meeting in the first place and what done looks like by the end. If you can't write that, then cancel the meeting. Second, is having the right people. So having everyone who's genuinely needed and nobody who isn't because inviting people just out of habit wastes their time, and it also dilutes the room. And third, a plan and a time box, a rough agenda and a firm time limit so that the session has a shape and an end. This 10 minutes of preparation can routinely save you around half an hour worth of drift. Once you are in the room, here you have four habits that can keep the energy and the focus high. So first is time box ruthlessly. Protect the clock because a meeting that regularly overruns teaches the people involved to dread it. Next is to draw out the quiet. So actively invite the people who haven't spoken by name to speak because the best insight is oftenly sitting silent in the corner. Third is to park the tangents. When a good but off topic point comes up, capture it on a visible list and move on so that it's honored without derailing the meeting. And finally, make all of this visible. So write things where everyone can see them board or a shared screen because shared memory then becomes shared focus. Now, every facilitator will meet the same handful of characters and here's how to handle each one of those kindly. First is the dominator who fills every silence. So you should thank them genuinely and then say, Let's hear from someone we haven't heard from yet. The next is the silent one. So invite them in gently by name on something you know that they know, so it's an easy first step. Is the skeptic. Don't fight the doubt, but welcome it, make it specific and turn it into a question that the group can actually chew on. And finally, you have the rabbit holder, the one who dives deep into every single detail. For that, you should say, great topic. Let's park it and come back to it if we have time. Notice that none of these are about control. They're about making the room for everyone. One habit that separates a good facilitator from a great one, it's neutrality, and it's genuinely quite a hard skill to have. The moment you push your own answer, you stop facilitating because the room can feel the leader's thumb on the scale and the team will quietly stop thinking for itself. So you guide how the group decides and let go of what it decides. If you honestly do have a strong view on the content, the cleanest move is to step out of the facilitator role for a moment and say so openly. Offer your opinion as one voice, and then step back into neutrality. You can't do is stay in a chair and steer. People stop contributing the instant that they sense the outcome is already decided. And finally, a quick facilitation note for each one of the ceremonies. For the daily stand up, keep it short and steer it towards blockers rather than a round of status reports. For planning, make sure you scope honestly and don't let the team's optimism overload the sprint. Your job is often to gently apply the brakes. Review, get them to demo real working products rather than present slides and draw feedback out of the quieter stakeholders. And for the retrospective, safety comes first because without it, people won't say really what's wrong. And it'll be a retro with no honesty in it, which will change nothing at all. Facilitation in short, is owning the process, handing the team the content, and staying neutral even when it's difficult. If you can master this, then your meetings will stop being something that people endure and it'll be something that people enjoy. So thank you for joining me in this lesson. In the next one, we'll tackle the difficult conversations that most leaders avoid and how to handle them well. I will see you in the next video. 6. Difficult Conversations on Agile Teams: Welcome back. In this lesson, we're going to face part of leading that almost everybody would rather avoid the difficult conversation. The underperformer, the simmering conflict, the missed commitment, avoiding these may feel kinder in the moment, but it's the single most expensive habit a leader can have. So by the end of this lesson, you'll have a simple and humane structure for handling these difficult conversations well. So let's start with the honest truth that makes these conversations worth having. An unsaid problem does not go away. It compounds quietly in missed work, in resentment in a team that watches you tolerate something and then quietly lowers its own standard to match. So the real choice is never conversation or no conversation. It's a small kind and timely conversation now or a large and painful one later after the problem has grown teeth. The leader who has the small one early is being kinder, not harsher than the one who lets it fester. So preparation is most of the battle here, and the heart of it is separating what's actually happened from the story you've built around it. So here are three steps. Number one, observation, not story. So bring the fact, not the interpretation. So you missed three stand ups this week. Is an observation. You don't care about the team is a story that you may have invented to explain that, and it will start a fight. Second, is to know your goal, to decide before you walk in what a good outcome actually looks like so that the conversation has somewhere to go. And third, pick your time and place in private, calmly and soon, never in the heat of the moment and never in front of the rest of the team. In the conversation itself, a simple four step structure keeps things fair and useful. So one observation, state the specific behavior you saw plainly and without blame. Two is impact. Explain the effect it had on the work or on the team so that it's clear why this matters and why it isn't just nitpicking. Three question to ask for their perspective genuinely because there is very often a reason that you don't yet know about. And four is listen. So actually listen this is a conversation. So listen to the answers they give. And the third and the fourth steps here make a conversation rather than a sentencing. So you might walk in certain and walk out having learned the real story. So let's put that to work on four situations that you'll almost certainly encounter the underperformer. So with this, be specific and be early. Vague hints and a hopeful wait help nobody. Name the gap clearly and offer support to close it. Conflict between two people, bring it out into the open rather than letting it fester and coach them towards resolving it themselves because refereeing every clash forever isn't leadership. Next is the missed commitment. So focus on the pattern and its cause, not on extracting a one off apology. And finally, we have the dominating personality to name the effect on the rest of the team kindly and in private so they can see what they can't feel in the moment. So underneath all of this, three rules that keep a hard conversation constructive rather than combative. So first, assume good intent to start from, there's probably a reason from this rather than they're just a problem. You can always harden your view later, but you can't always undo an accusation. Behavior not character, so talk about what someone did, never about who they are. You missed the deadline, for example, is workable. Your unreliable is an attack. And finally be specific, not general. The words always and never start fights and are almost never true, while one clear, concrete example gives the person something they can actually act on. So being safe and specific every time is highly important. Now, difficult conversations never become fun, but they do become a skill, prepared, structured, and kind. So having them well is one of the most respected things a leader can do. Thank you for joining me. In the next lesson, we'll put your leadership into practice by writing your team's working agreement together. I will see you there. 7. Practice Exercise: Write Your Team's Working Agreement: Welcome back. This is a practice lesson, so it's your turn to make something real. We're going to create a working agreement for your team, which will be a short set of norms that the team writes for itself. So I'm going to show you the one I've created already in Notion, and then you'll run the exercise with your own team. So Notion is free, runs in the browser, and everything today works on the free plan with no add ons or subscriptions. So let's have a look. First, what a working agreement actually is, it's a short and plain statement of how this team agrees to work together. So how you communicate, what quality means to you, how you handle disagreement, and so on. The crucial word here is agreement. These are not rules imposed from above by you. They are norms that the team sets for itself together, which is exactly why they work. People tend to follow the agreements that they helped write, and they ignore the ones handed down to them. Your role here is, again, to facilitate, not to dictate. Is the exercise in four steps. Number one is to gather the team because this is written together, not drafted by you in advance. Two is to brainstorm norms openly, asking what helps us work well and what gets in the way. Collect everything first and judge later. Three is agree a short list. So five to eight agreements that you'll genuinely keep because a giant list is one that nobody ever remembers, and four make it visible. So somewhere that the team sees it often and can point to it when needed. If the team is a little bit stuck for ideas, there are four areas tend to cover most of what matters. First is availability, so your core hours, your expected response times, and how someone signals they need more focus time. Next is quality, so your shared definition of done and the things that you agree never to skip under pressure. Next is disagreement, how you raise concerns and how you make a decision when you all genuinely agree. And then finally, we have meetings, which ones you hold, how long they run, and how everyone agrees to show up to them. So things like cameras, punctuality, and so on. So we have four prompt here, and the agreement would almost write itself. So, writing it in notion, yeah, a free page that the whole team can edit. On this, we're just going to use a simple list with one page. Yeah, a list with short bullet points with plain language that everyone understands. The pronouns are W, not I or you. It should always be we create a shared voice with shared ownership. Then finally, you should also have a review date, which would be the date that you review your agreement plan. So let's go to Notion and have a look what that might look like. So here we have my EdTech project Hub, at the bottom, I've added a page called working agreement just to remind you how to do this. If you press forward slash and then type in page and then press Enter, it'll take you to a new page. And when you type in the title on that new page, it will appear here like. So, in this page, I have added four of the agreements that the team has agreed on. The first is we start the daily stand up at 9:30 A.M. And it lasts 15 minutes. Next is that we turn cameras on for retrospectives, so we can all see everyone's faces and also understand their emotions. Third is that we do not merge code without a review first. So then this is related to quality and how the team works in relation to that. And then finally, we have something that touches upon disagreements and how to handle them. So when we disagree and can't resolve it, we decide with a quick thumbs up or thumbs down vote and then move on. And that's it. It's as simple as that. Doesn't have to be long, a long page full of agreements. Four short and concise agreements are fine. I mean, up to six is probably a good number, anything more, and it becomes a little convoluted and more difficult to remember. And as you can see here, I've added a review date, which is a few months down the line. From now where we will review this working agreement and see if there are any changes that need to be made or if anything needs to be added. This type of document would be very, very important if you join a company as a project manager and your first few weeks of learning the ropes should also be learning how your team works. So having them create a working agreement or having them show you previous working agreements if they have them is a great way of learning the ropes and learning how projects progress in your new company. So let's have a look at what good looks like. So now, go and run this practice with your own team, and when you have a draft, you can check it against these four things. First, the team wrote it. If you wrote it alone, it's your policy, not their agreement. Next, it's specific. So be respectful. So cameras on for retro is a real agreement. Third, it's short, so few enough agreements that the team can actually remember them. And finally, it's revisited now and then, and it changed when it stops fitting. So if you hit those four, you'll have something that the team can genuinely own and it will genuinely give you a very good understanding of how they work. Working agreement is a small artifact with a big effect, and it turns your team into one that has chosen how it wants to work rather than being imposed. So thank you for joining me in this lesson. In the next one, we will look at how to run retrospectives that genuinely change behavior so that those agreements keep getting better and the work keeps improving. I will see you there. 8. Why Most Retros Fail, and How to Fix Yours: Welcome back. In this lesson, we're going to be very honest about retrospectives. Now, the retro on paper is the most powerful meeting in Agile. It's the one where a team improves itself, but in practice, it's very often the one that people actually dread. So by the end of this lesson, you'll know the four reasons that retro go stale and the specific changes that can bring one back to life. So you've probably sat in a meeting like this before with some complaints with same nodding of heads, the same, nothing happening afterwards. And after a few rounds of this, people stop bothering to be honest because honesty costs quite a lot of energy, especially when nothing appears to be changing. So this usually shows up in one of two ways, the polite and the empty retro, which everyone says it went fine, but nobody names what actually went wrong, and you're all out in 50 minutes feeling vaguely relieved. And the second one is an honest but futile meeting where real problems are named very clearly and bravely, but then nothing changes. Now, this second meeting, this second type is the more damaging of the two because you've spent people's trust and you've given them nothing back for it. So real problems named, then nothing changes. This is worse than silence. Now, almost every dead retro has one or four causes. First is no safety. So people won't name the real problem if there's any chance that that will be held against them. So you get a safe answer rather than the real one. Next is no structure. So an open how did it go? Will produce a vague and shapeless conversation that will drift to wherever the loudest person wants to take. Next is no follow through, where actions are agreed, nobody owns them, and then nothing changes by the next time. And then finally, the same format forever, the 15th identical retro reliably produces the 15th identical answer because you keep asking the same question. The good news is that each of these problems has a straightforward fix. And we'll look at them one by one. So first, safety comes first. Without safety, everything else is just decoration. So that chain is very simple. No safety, no honesty, no honesty, no improvement. People have to genuinely believe that naming a problem will not be held against them, and belief comes from what they've seen happen, not from you just saying the words. So these two things build the safety faster than anything else. First is to focus on the system, not on the person at fault. Ask what made this hard rather than whose fault was it. The first question gets you a cause that you can fix, whereas the second one gets you a defensive answer and a quieter room next time. Then the next is to go first yourself. So name your own mistake early and plainly, like I set the sprint goal too late and that cost us two days. Now, when the leader is visibly fallible, everyone else feels like they have the permission to be fallible as well. Everyone's human. These things will move changes in retros faster than any form at will. Next is a structure that works. A retro that wanders produces strange feelings, whereas a retro with shape produces change. So there are five stages that'll do the job here. One is to set the stage, remind everyone while they're in the room and get people talking early. Make sure that every single person says something because whoever stays silent in the first 5 minutes tends to stay silent throughout. Two is to gather the data, what actually happened, get facts and feelings before anyone jumps to conclusions. Three is generate insights. Why did it happen? This is where you look for patterns and root causes rather than the symptoms. Four is decide what to do, to choose a small number of concrete actions with owners, and five is clothes. So confirm the actions out loud and check how the retro itself felt. These five stages are your reliable spine, whatever format you decide to dress them in. So what can you change at your very next retro? There are four small things with some very outsized effects. Number one is to start with the actions from last time. Nothing signals that this meeting matters more. And opening with D we do what we said last time? Number two, is to limit yourself to one or two actions because a short list that happens beats a long list that nobody remembers. Three is to give every action a named owner, saying that the team will look into it reliably means that nobody will. And then four has changed the format now and then because a new question shakes loose answer that the old one was never going to reach. So if you do these four things, and you'll feel the difference in one single sprint. Retros fail for four predictable reasons, but all four of those things are fixable. If you build safety, if you give it structure, if you follow through, and if you vary the question, you will improve your retrospectives. Thank you for joining me. In the next lesson, we'll look at five retrospective formats that will get you well beyond the same three columns. I will see you in the next one. 9. Five Retrospective Formats Beyond Start-Stop-Continue: Welcome back. In this lesson, I'm going to give you five retrospective formats that you can use straightaway and more usefully tell you when each one is the right choice. Most teams know one format, and they run it forever. If you have five in your pocket, and if you know which one fits the moment perfectly, this is a genuine leadership skill. So let's go through them all. So first of all, why vary the format at all? Why bother changing anything? Because the format is the question that you are asking. If you ask the same question every time, unsurprisingly, you'll get the same answer every time. Different frame surfaces things the familiar one keeps sliding past. So there are two cautions here, though. So this isn't novelty for its own sake. Each of these formats is built to draw out a particular kind of insight so that you can then choose deliberately and also rotate rather than to churn. So change every few sprints, not every single time, because people need enough familiarity to relax into the meeting. First is mad, sad, and glad, and it starts with feelings rather than facts. So three columns mad, what frustrated you in the sprint. Sad is what disappointed you or fell short of what you hoped, and glad is what genuinely pleased you. It feels a little exposing the first time, and that's rather the point of this. Emotions are excellent problem detectors, and people often feel that something is wrong well before they can actually articulate why. So this format is at its best when there's tension in the team because feelings name the problems that are purely factual discussion politely might tiptoe around. Number two is the sailboat. This is a picture. Your team is aat trying to reach an island. The wind is what's pushing you forward, everything that's helping you move. The anchors are what's holding you back. So something that's dragging in the water. The rocks are the risks ahead that you can still steer around if you spot them now, and the island is where you're actually trying to get to. So the last one is the quiet gift of this format. It is remarkably common for a team to discover mid discussion that people have different ideas about where the island even is. So if you use a sailboat and the team feels busy but also drifting. Third is the four s, liked, learned, lacked and longed for. So like what did we enjoy about how this sprint went? Learned is, what do we do now? What do we know now that we didn't before? Led is what was missing that we actually really needed, and longed for is what did we wish that we had and we still don't have. The clever part is separating liked from learned because a sprint can be thoroughly unpleasant and hugely educational at the same time. And the usual format might blur these things together. But this one shines after a very hard sprint or after anything that was experimental. Fourth is the starfish, which is a sharper version of the familiar start stop continue. So five categories here instead of three, more of. This is working. We want a bigger dose of it. Keep doing fine as it is. Don't break it. Less off. It's not worthless, but it's taking more than it gives. Stop doing. This actively costs us, so drop it and start doing things we're not doing yet, but we think we should. Two middle categories, more of and less of are what make it worth the extra columns. So real life is rarely this binary between keep and kill. Most things just need turning up or turning down. So use the starfish when the team has habits that nobody has questioned in a while. Fifth, lean coffee, which is different in kind. Instead of you providing the questions, the team sets its own agenda. And there are three steps for this one. Number one is that everyone writes topics. So a few minutes in silence, one topic per note with no discussion yet. Two, the team votes usually with two votes and the topics with the most votes rise to the top. And three time box each one, about 5 minutes, and then take a quick vote on either continue or to move on. So this is actually the format to reach for when you suspect that there's a real issue, but you don't know exactly what it is, because you're not steering the agenda. The thing that's actually bothering people has more room to surface. Now, it takes some nerve as a facilitator to let the team steer like this, but since you generally don't know where it'll go, then that's why it works and why it helps. So how to choose match the format to what you're seeing. If the team is tense or frustrated, use Mad Sar and glad. If they're losing sight of the goal, the sailboat is a good option. If they're coming off a big learning sprint, the four s, if the team is stuck in habits that nobody questions, use the starfish. And if there's clearly something unsaid or you're sitting on an unnamed problem, use lean coffee. So read the room first and then pick the format second. So there you have it. You have five formats, each asking a different question and chosen for the moment rather than for variety for the sake. You for joining me in this lesson. In the next one, we will tackle the hardest part of all of this, which is turning what comes out of a retro into change that actually sticks. I will see you there. 10. Turning Retro Outcomes Into Real Change: Welcome back. In this lesson, we're going to close the gap that ruins more retrospectives than anything else, which is the gap between talking about a problem and actually fixing it. Now, good insights are common, but change is rare. So by the end of this lesson, you'll have a concrete method for making sure what your team decides in the room genuinely happens outside that room. So here's the diagnosis. Most retros don't fail at finding problems. They fail at fixing them. Teams are usually rather good at spotting what's wrong. The insight was right there in the room, correctly identified, and then it never became anything. So the work of this lesson isn't about better discussion. It's about what happens in the last 15 minutes of the meeting. And then in the two weeks that follow. So start with the discipline that matters most, and it's a counter intuitive one. Pick one thing. So what teams typically do is agree on eight improvements. Everything Rays feels important and nobody wants to dismiss a colleague's point, so everything goes on the list. And then none of it happens because eight simultaneous changes on top of a normal delivery is not a real plan. What works instead is agreeing one change and then actually finishing it. So one completed change beats eight that were only ever discussed every single time. If you do the arithmetic on that because it's genuinely motivating, a team that successfully changes one thing every sprint becomes a transformed team within a year. Slow is completely fine, but stalled is not. Once you've picked the one thing, it needs three attributes to survive contact with a very busy fortnight. A named owner, one person by name, not the team, which translates to nobody, by the way. The owner doesn't have to do all the work, but they are the person who makes sure that it happens. Two is a deadline. So by the end of next sprint at the latest, because anything vaguer than that quietly becomes never. And a visible finish line. So agree now in the room how you'll know it's done. And if you can't describe what done looks like, then you haven't got an action yet. You've got a wish. So let's make this a little bit more concrete because honestly, this is where most action items fall apart. So improved communication is very vague. Pre or post to written update each Friday is actionable. Do better testing is vague. No merge without One review from starting Monday is actionable. Fewer interruptions is vague. Support requests go to a queue rather than to people's direct messages is something that's actionable. So notice the pattern there. The actionable version names who what and when, and you could tell from the outside whether it happened or not. If you can't, then it will quietly not happen. So now, this is a practical step that some teams skip. An action item that lives only on a retro page is an action that nobody sees ever again. So make sure you put it where the work lives on the board. You can add it as a card in the next sprint. Sitting alongside the normal work, which should be visible in every single stand up. You could also put it in the plan and give real capacity actual time in the sprint. Now, this is the honest bit. If an improvement never competes for time against delivery work, it will lose to delivery work every single time because at the end of the day, delivery is what's urgent. So making space for an improvement is a leadership decision, and it's yours alone to make. Finally, close the loop by starting where your next retro where the last one ended. So review last time's actions first before anything new. Did we do it and what happened? Celebrate the completed ones and do it out loud because proof that this meeting changes things is what keeps people honest and what keeps people attending the meetings. And finally, be honest when something didn't happen without blaming anybody. So just ask why nine times out of ten, the answer is capacity rather than willingness, which tells you to pick smaller actions or to protect the time properly. Now, this is all actual very useful information and not a failure. One action, one owner, one deadline, put the work where it actually lives, and make sure it's reviewed at the start of the next retro. That's how talk becomes change. So thank you for joining me. In the next lesson, we'll zoom out and we'll look at how to track whether your team is genuinely improving over time. I'll see you in the next one. 11. Tracking Improvements Over Time: Welcome back. In this lesson, we're going to zoom out from the single retrospective and look at the longer view. Is your team actually getting better? It's a surprisingly hard question to answer from memory alone and a very easy one to answer with a simple record. So let me show you the latest possible system that does the job. Now, here's the problem with improvement. Week to week, a team genuinely cannot feel its own progress. That's probably because the work is always busy and there's always something going wrong. And last month's fixed problem becomes invisible precisely because it's already fixed, but a simple record shows the change that the daily work may hide. And it earns its keep in two ways. Number one, it sustains momentum. So seeing concrete progress is what convinces a team to keep investing in improving rather than treating retros as like a tax. And finally, it exposes what is stuck so a problem that's been raised at five retros in a row is telling you something important that no single retro would reveal all on its own. Now, this system is deliberately unglamorous. It's one row per retro, and that's it. So four columns are plenty. The sprint number, the action you agreed, the owner, and whether it got done. So sprint 12 written update each Friday. Prior done. Sprint 13, no merger without a review. Sam, done. Sprint 14, support requests to a. Alex, done partly. Sprint 15, trim stand up to 10 minutes. Prior done, not yet. It takes about 30 seconds to fill in at the end of each retro, but after a few months, it'll become probably one of the most honest documents that your team has. So notice how much that little table already tells you just sitting there with one row per retro. Now, once you've got a few months of that table, there are three signals that are worth watching out for. First is completion rate. What share of the actions you agreed actually got done? That single number is the health check on your whole retro habit. Two is recurring themes, which problem keeps coming back retro after retro in slightly different clothes. The final one is team mood. So ask for one word check in at each retro and note it because the trend across months tells you far more than any individual word did on an individual day. So three signals is plenty. Resist the urge to build something elaborate here. This is a habit, not a reporting exercise, and the moment it starts to feel like admin is the moment that you will stop doing. So what do you do with what you see? There are three common patterns, and here is the response to each. So a low completion rate means that you are agreeing to too much. The fix isn't to nag the team. It's to cut back to a single action per retro until you're reliably finishing it. Next is the same theme returning means that you've been treating a symptom rather than treating the cause. If a slow code review keeps appearing, then the real issue might be workload or unclear ownership or maybe something that nobody has said out loud yet. So dig properly. And then finally, steady completion with mood rising means that it's working. So in this case, you should keep going and importantly, say so out loud to the team. People rarely notice their own progress unless someone else names it and points it out to them. So one little log, three simple signals, and a habit of reading them every couple of months. That is really all it takes to see whether your team is genuinely improving over time or not. Thank you for joining me in this lesson. In the next one, it's your turn to do some work, and you'll design a complete retrospective for your own project. I'll see you in the next video. 12. Practice Exercise: Design a Retro for Your Project: Welcome back. This is a practice lesson, so it's now your turn to build something that you will actually use as a project manager. We're going to design a complete retrospective for your project, the format, the timings, the questions, and the follow through. So I'm going to show you mine on screen in Notion, and then you can pause and you can plan your own. So just a reminder that Notion is free runs in the browser and everything today works on the free plan with no add ons required. So let's begin. Four steps. Number one is read the room because what your team needs right now decides everything else later. Number two is to choose a format that asks the question that your team really needs to answer. Number three is to plan the five stages with real timings so that the meeting has a shape. Number four, is prepared to follow through, deciding in advance where the action will go and who tracks it. Fourth step is the one that most people skip, and it's the one that makes the most difference here. So step one is read the room. Start by reading the room honestly and let that pick the format that you want. If you are sensing frustration under the surface, use mad, sad, glad and let the feelings. The team is drifting from the goal, use the sailboat, which will surface whether you even agree on where you're all heading. If there are habits that nobody questions anymore, the starfish will get you the nuance that you need. And if you're fairly sure there's something that's been left unsaid, use lean coffee and let the team set the agenda. So choose for the situation in front of you, not for the format that you happen to like the most. Step two is to plan the five stages with actual minutes attached. Here's a 60 minute retro that generally works. So you set the stage. It takes 5 minutes, the purpose, a quick check in word from every person, and a brief reminder about safety. Number two, is gather data for 15 minutes, silent writing first, and then share because that silence is what protects the quieter voices from being drowned out. Three is generate insights, 20 minutes for this section, group the themes and dig properly into the two that matter the most. Decide what to do for about 15 minutes, one action, a named owner, a deadline, and a visible finish line. And then finally close for about 5 minutes, read the actions back to the room and ask how the retro itself felt. Write those timings down because a retro without them always overruns on the talking and starves the deciding. Okay, so planning it in notion. Again, free page with no add ons needed first thing should be the plan. So your format to five stages and the timings for each stage. The prompts, which are the exact questions you'll ask written out in advance. So this is related to the framework that you choose. And finally, the action log, which is just that small table action for the owner, for the deadline, and the status. So let's have a look at what that would look like in Noon. If you go back to my EdTech project, I've put here retro plan, and just for a random example, we've got sprint number 16, so we're pretty far ahead in this project. Here we go. So I've decided to use the sailboat format because we've all been the team has been working in the same way for a while. So I wanted yeah to recheck that we're going in the same direction. So here I've got, again, the five stages of the meeting and how long each stage should take. And then I've got the three questions. What's our wind? What are our anchors? What rocks can we see ahead and where is the island? I've left the spaces there for the answers that the team should provide, not you. The team should provide these answers. And then below, I've got so if we're saying that this is Sprint 16, I've chosen one action from the previous three sprints. I've added it to this table where we have the sprint number, we have the action agreed. We have the owner and we have the status. You could also include deadline here in this table if you want, but if your sprints are usually two weeks, then yeah, the deadline should be implied that it's the end of that sprint. But if you want to add a deadline to this table, that is fine and also completely normal. Now, you might notice if you set this up in motion, you might get a little notification that pops up. I think it's from the AI, which asks you if this is a retrospective. And then I think if you click this, you have some more options that you can use AI to format. So this is what a simple retro plan looks like, again, simple bullets and a simple table, and that's about it. Let's have a look at what good looks so you should check your plan against these four things. So pause the video. You can design your retrospective plan. When it's done, you can do the check. So the format fits the moment is the first check that you should make chosen for what the team needs now, not for novelty. Second, is that safety is built in with silent writing and questions aimed at the system rather than at individuals. Number three, it ends in one owned action, so not a wish list, but one thing with one name and one date. And finally, follow through his plan. You already know where that action goes and who will check it. If you hit these four things, then you've designed a retro that will actually make change. So a well designed retrospective is actually like the engine of the team that improves itself constantly. And now you can design one deliberately rather than running the same meeting again and again out of habit. Thank you for joining me in this lesson. In the next lesson and the next section, we'll step up a level, and we'll look at scaling Agile beyond a single team. I will see you there. 13. When Does Scaling Actually Become Necessary?: Welcome back. In this lesson, we're going to ask a question that many organizations skip straight past. Do you actually need to scale at all? Scaling Agile is a large, expensive and largely irreversible decision that is routinely made far too early. By the end of this lesson, you will know the signals that you need more than one team, the real signals, and the false signals that fool people and some cheaper things that you can try first. The honest answer, you should only scale when one team genuinely cannot do all the work itself. Not when the work merely feels large and not when someone senior in a meeting says the word scaling. And the reason to be strict about all of this is cost. Scaling adds coordination. Every single team adds meetings, handovers, and dependencies between people who just used to turn around in their chair to talk to each other. Worse than that, the cost is permanent and you pay it for every single sprint for as long as the structure exists. So the bar for adding a team should be genuinely quite high. Here are four honest indicators that it really is time to scale. Number one, the team is genuinely full. There is sustained demand over months well beyond what one team can deliver, and prioritizing harder hasn't closed any gaps. Two, you have distinct product areas. The work splits cleanly into parts that barely touch each other, which means that separate teams won't be tripping over one another. Number three, separate skill sets. The specialisms involved are so different that one team cannot realistically hold all of them. And four independent release needs different parts of the product genuinely need to ship on different timescales. Now, notice what all of these four indicators have in common. Each one describes a structural reality, not a feeling of pressure or being overwhelmed. Now for the false signals, and these are the ones that catch people out because each one sounds like a perfectly reasonable problem. Number one, we're behind schedule. Adding teams almost never makes work arrive sooner. In fact, in the short term, it makes things slower because new people need on boarding, and the coordination cost hits immediately. Two, the backlog is huge. A long backlog is a prioritization problem not a head count problem. And doubling capacity to work through a badly ordered list simply gets you more of the wrong thing. Three, leadership wants it. Scaling as a status symbol is one of the most expensive kind of status symbols there is, and everyone else does it. Other companies structures were built to solve other companies' problems, and copying the shape without the context rarely transfers. So before you add a team, here are four cheaper moves, any of which is often enough just on its own. Number one, prioritize harder. So doing less better genuinely beats doing everything slowly with more people. Two, remove the bottleneck. It's remarkably common for one slow step, a review queue single approver an environment everyone waits for more to cost more throughput than a missing team would add. Three, grow the team slightly. One or two more people is dramatically cheaper in coordination terms than standing up an entire second team. And finally, cut work in progress. Finishing what you've already started often frees up more real capacity than hiring does, because half done work is capacity sitting idle. If you work through these four things honestly first, then if the problem survives all of them, you have a genuine scaling problem, and we'll spend the rest of this section on how to handle that. So you should scale when the structure of the work demands it, not when the pressure does, and try the cheap fixes first because usually they work. Thanks for joining me in this lesson. In the next one, we will compare the three best known scaling frameworks, fairly, including their criticisms. I'll see you there. 14. SAFe, LeSS and Scrum@Scale: a Fair Comparison: Welcome back. In this lesson, we're going to compare the three best known frameworks for scaling Agile, safe, less and Scrum at scale. I'll tell you what each one actually does, who it suits, and probably more importantly, what its critics say. My aim here is fair comparison rather than a single recommendation. All three of these exist to answer the same question. How do many teams work together on one product? Where they mainly differ is how much structured they provide you with. And that's the real trade off here. So keep that in mind. More structure means clearer guidance, but also means more roles and more processes to carry. Less structure means it's lighter to run, but there's much more for you to work out for yourself. Neither end of that spectrum is virtuous. Now, none of these three is the right answer in the abstract. One of them, though, may be the right fit for you. So first is SAFe, which stands for scaled Agile framework. It's the most widely adopted and by far the most prescriptive of the three, and it's aimed squarely at large enterprises. So there's four ideas to know here. The Agile release train often shortened to ART. Teams are grouped into a train that shares one mission and one cadence, typically somewhere around 50 to 125 people. Next is a big planning event. All the teams in a train plan together in the same sessions every eight to 12 weeks, and that's known as PI planning where PI stands for planning interval. Next is layered levels. SAFe organizes things into a team program and portfolio concerns. So strategy connects all the way down to delivery and extra roles. I introduces dedicated coordination roles, the best known being the release train engineer or RTE who effectively facilitates the train. Now for the fair verdict, and here's the interesting thing, safe's greatest strength and the criticism leveled at it are the very same characteristic. The strength is that it tells you what to do. There is very detailed and documented guidance for almost every situation, which is genuinely valuable for a very large and cautious organization that needs a defensible plan. And also has hundreds of people to align. The criticism is that it can feel unagile because of the process weight and the additional layers which can quietly rebuild the hierarchy that Agile set out to flatten. And critics argue that you can end up performing Agile ceremonies inside an essentially traditional structure. There's one practical note here, SAFe is actively revised and its terminology changes between releases. So if you're working with this framework, check the current official guidance rather than relying on older material. Second is less, which stands for large scale Scrum, where safe adds less deliberately removes. The guiding instinct is that scaling should mean more Scrum, not more scaffolding. So there are four things that define it. One, product backlog. Every team pulls from a single shared ordered list. So there's one truth about priority for everyone. You have one product owner, a single person that holds priority access across all the teams, and you have one shared sprint. Teams run to the same rhythm, and they all integrate their work constantly rather than all at the end. And lastly, we have very few new roles, rather than adding coordination layers, Less tries to skip organizational complexity completely. So it comes in two sizes, plain less for a handful of teams, and less huge for considerably more teams. The honest criticism is that less is simple, but it isn't easy because it asks you to genuinely simplify your organization and to often remove rolls and layers, and that demands real structural change, which is potentially much harder than adopting across a process on top of the structure that you already have. Next up, we have Scrum at scale. So the idea here is that you scale by repeating Scrum and you adopt the framework in pieces rather than all at once. So we have four features here, the Scrum of Scrums. Representatives from each team meet regularly to sync on shared problems, and that pattern repeats upward as your company grows. You have two cycles, one concerned with delivery and how the work gets done, and the other with priority and what gets built, and they meet at the top of the organization. Is minimally prescriptive. You adopt only the components you actually need right now, which makes it feel far less disruptive to start. And finally, leadership is explicitly included with defined forums where leaders unblock things rather than interrupting the teams. The strength of Scrumma Scale is that it's gradual and it's modular adoption. Its criticism is the flip side. Because it's minimally prescriptive, a great deal of the detail is left for you to design. So you need genuine agile experience in house to make this work properly. Now, let's look at them side by side. Now, SAFe is best suited to large enterprises that want detailed guidance, and the thing to watch is process weight. Less is best suited to organizations with one shared product, and the thing to watch is that it requires real restructuring. Scrum at Scale is best suited to those companies that want gradual adoption rather than all at once. The problem is here that you will be designing a lot of the detail yourself. Now, these three aren't the only options. Another option is Nexus, which is a lighter framework from the same stable as Scrum and the so called Spotify model with its squads and tribes, which has been heavily copied, though it is worth knowing that it was a description of one company at one moment rather than one particular framework that was published for reuse and again and again and again, like these three. So how should you choose your framework honestly? The three principles that survive contact with reality are these. Start from your own problem. So name the specific pain that you're feeling in plain language and then look for the framework that eases that particular pain. Choosing a framework and then hunting for problems it solves is the wrong approach, and it happens quite a lot. Now adopt the least that you can. Take the parts that help you and leave the rest because you don't owe any framework total loyalty, whatever its certification program implies. And finally, judge by outcomes. If delivery and morale aren't improving, then the framework isn't really working. However faithfully you're following all the guidelines. These are three different frameworks with three different amounts of structure, and there's no universal winner you choose based on the needs of your organizations. So thank you for joining me in this lesson. In the next one, we'll get concrete about the coordination patterns that keep multiple teams working together well, whichever framework you decide to land on when you scale. I will see you there. 15. Cross-Team Coordination Patterns: Welcome back. Whatever framework you choose or if you choose none at all, you'll still need a handful of concrete patterns to keep several teams working together as one. During this lesson, we'll look at four patterns that you can use immediately and a clear method of handling the main thing that actually causes scaling pain, which is dependencies. Let's name the real problem upfront first because it's easy to misdiagnose. Scaling problems are almost always dependency problems. So it isn't the number of people that slows you down. It's the number of connections between teams. So teams waiting on each other is precisely what makes several teams slower than one, and the best fix is structural. You design your teams so they need each other as little as possible, each of them owning a slice of the product end to end. And where dependencies genuinely must exist, the best fip is to make them visible and owned so that they are managed deliberately rather than discovered at the worst possible moment. So here's the toolkit you can use, four patterns, all of which work independently of any particular framework. First is the Scrum of Scrums, which is a short and a regular sync between representatives of each team. Next is joint planning. Teams plan in the same room at the same time. So dependencies surface in conversation rather than in a crisis. Third is communities of practice, people who share a testers, designers, front end developers meeting across team boundaries to align on how they work, and finally, a shared standard. So one definition of done across all teams so that finished means the same thing everywhere, which actually matters enormously the moment that you are integrating work from several teams. So the Scrum of Scrums is the most commonly used of those patterns, and it's easily the most commonly botched. So let's look into it specifically. There are four rules. One is send one representative, so one person per team, not the whole team. Or you've simply just invented a very expensive meeting. Two is 50 minutes standing. It's a sink, not a status meeting, so protect the clock fiercely. Three is only cross team topic, so anything internal goes back to the team ruthlessly, because the moment this meeting becomes a general update, it stops being worth attending. And finally, end with owned action. So every dependency raised leaves the room, with a name against it, or it will still be there next week. So if you run this properly, this is 15 minutes a day for a whole program of teams, and run badly, it could end up being an hour or more of theater that convinces everyone that coordination is a waste of time. If I could give you only one coordination habit, it would be this one joint planning. It's probably the highest value thing that you can do. There are three parts plan in the same room, so all the teams all at the same time because dependencies will surface naturally in that conversation when the people involved are all within earshot of each other. Number two, make the ask explicit. So each team states out loud what it needs from whom and by when so that nothing is left as a private assumption. And finally, agree the sequence, so order the work so nobody sits waiting on somebody else's sprint to be able to finish their work. This is the underlying insight behind the big planning events in the scaling framework. You don't need their full machinery to get most of the benefit. You just need the teams talking to one another before they commit rather than afterwards. Now, this is an artifact that does the most work for the least amount of effort, a simple shared dependency list. Shared list beats any clever tool because people will actually read it. Three columns is enough what's needed from whom and by when. So login endpoint from the platform team by Sprint 17, approved copy from the content team by Sprint 17 and design for a parent view from the design team by Sprint 18. So you should then review this at every sync, and this is the whole discipline, more or less. A dependency that nobody can see is a dependency that nobody manages, and it'll reappear probably as a surprise on the day that it blocks a release. So writing it down converts a future crisis into a piece of ordinary plan. One warning to finish on coordination is a cost, not a virtue. So spend it carefully. It's very easy to end up with so many alignment meetings that nobody has time to build anything. So there are three habits that keep it lean. Run the fewest meetings that work, so add coordination only when a real problem mans it never preemptively. Refer written over meeting. So a shared visible list replaces most of the sinking, and it works across time zones. So if you have remote teams, this is very good. And finally, review the overhead itself, asking retrospectives whether each cross team meeting still earns its place and be willing to eliminate the ones that don't. Coordination should be reviewed exactly like any other work. Oh, four patterns, one visible dependency list and permanent skepticism about your own meeting overhead. That is cross-team coordination. So thank you for joining me. In the next lesson, we will look at what goes wrong when teams scale before they're ready and how to recognize it in time. See you there. 16. The Dangers of Premature Scaling: Welcome back. In this lesson, we're going to look at what happens when an organization scales before it really needs to because it's one of the most expensive mistakes you can make in Agile project management. In this lesson, we'll look at what premature scaling costs, how to spot that you've done it, and what to do about it. Let's start with why scaling happens in the first place because nobody scales prematurely on purpose. Adding teams feels like decisive action. It's visible, it's fundable, and it looks like leadership. But sometimes it could be just avoidance. It's considerably easier to hire than it is to fix the things that's genuinely slowing you down, especially if that thing is an awkward process, an unclear priority, or a senior person's pet project that nobody wants to challenge. Adding a team lets everyone feel that something has been done without anyone having the difficult conversation. So what is the bill? Here are four costs and you'll pay them every single sprint. One is communication overhead. Every new team multiplies the connections that have to be maintained, and that growth is far worse than linear. Next is slower decisions, more people to consult, means that everything takes longer to agree. So the organization gets more cautious precisely when you wanted it to be faster. Third, is diluted ownership when several teams own something in reality, nobody quite does, and the awkward bits fall between them. And finally, process for its own sake. Ceremonies appear to manage the coordination problems that you've just created, and then those ceremonies also need to be managed. So how do you know it's happened to you prematurely? Four symptoms are here, and you'll need to be honest to see them clearly. Number one is more people same output, capacity went up and delivery didn't, and this is probably the clearest signal there is. And it's also the one that people work hardest to explain away. Number two is meetings, crowding out work. Coordination is eating the very time it was meant to protect. Number three, everyone waiting on someone. Teams are blocked on each other more than they're actually building, which means your team boundaries are all in the wrong place. And then number four, nobody owns the outcome. You have plenty of teams, plenty of activity, but no clear accountability for whether the thing actually succeeds or. If you are recognizing one or more of these, the problem probably isn't that you need better coordination. It's that you have too much structure. Now, this brings me to the point of this lesson, and it's one that you may rarely hear said plainly. Scaling is allowed. Going back is valid, and it's actually quite a brave decision because here's the instinct when scaling hurts. Add more process. More coordination roles, another alignment meeting, a new tracking layer to manage the pain. And all of that reliably makes it worse because you are treating the symptom of too much structure with more structure. So the better move is to take structure away, merge two teams that were never really independent, cut a coordination layer out, give one team clear end to end ownership of something instead of splitting it three ways. Fewer moving parts means faster delivery, and no framework anywhere says that you're forbidden from simplifying. Structure exists to serve delivery, not to survive it. And if you unwound something that wasn't working, that's not a failure to admit. That's the inspect and adapt cycle doing exactly what it's for, but at the organizational scale. So premature scaling is expensive, and it can be hard to see from the inside, but it's entirely reversible if you're willing to be honest. Thank you for joining me in this lesson. In the next one, we'll pull all of this together, and we'll choose a scaling approach for your own project. I'll see you there. 17. Choosing a Scaling Approach for Your Project: Welcome back. In this lesson, we're going to make an actual decision. So by now, you know when scaling is justified. You know the frameworks, and you know the coordination patterns. So now let's turn that into a choice for a real project using four questions and a worked example. So by the end of this lesson, you'll have a method that you can apply to your own situation immediately. First, the principle that really should guide this whole decision is, choose the latest approach that solves your actual problem. So you can always add structure later pretty easily when a problem demands it. Removing structure, however, once the roles exist and people's job titles depend on it is far harder and considerably more expensive not to mention political. So if you're genuinely unsure, lean towards less. Four questions, and answering them honestly will narrow the choice very, very quickly. Number one is how many teams? So two or three teams needs far less machinery than 20, and this single answer will eliminate most options. Number two, is it one product or many? A single shared product points towards shared backlogs and shared plan while genuinely separate products points towards independent teams that barely need to coordinate at all. Three is how much appetite? Can your organization genuinely restructure, removing rolls and layers, or is that off the table? Be realistic here rather than aspirational. And finally, how independent are the teams? Can they ship separately or must everything land together, because that will determine how much synchronizing you will actually need. So let's work an example. Imagine a product with three small teams. The question is how many teams, three or quite small. One product or many, just one shared product. Appetite for restructuring, it's low for now because the organization has just been through one reorganization and has no stomach for another. Can ships team separately, mostly with some overlap around a shared login and a shared design system. So now that set of answers rules out a three small teams do not need an enterprise framework with layered portfolio governance, the overhead would swamp them. So equally low appetite for restructuring makes a framework that demands genuine organizational surgery, a poor fit right now. So here's the verdict for that example. Not a full framework at all, but a shared backlog, joint planning, and one weekly. Three teams don't need a release train. They need to talk to each other on purpose and to have one clear source of truth about priority, and that's genuinely it. And this will hold for a surprisingly long time. It's two habits that make choice a good one rather than a lazy one. Borrow don't adopt. So take the practices that help and leave the rest from wherever they come, take them and leave the rest without any guilt and revisit at ten teams or whatever number represents real change in shape for you because the right answer for all three teams is very unlikely to be the right answer at 15 teams. You're choosing for now, not choosing and finally, and this matters more than getting the decision perfect. Treat your choice as an experiment rather than a commitment. So you'll not get this exactly right the first time and you don't need to. Three things make being wrong survivable. One is pick a review date now while you're still clear headed, agree when you'll honestly reassess, and three months is usually plenty of time. Next is watch delivery and morale because those signals will tell you most of what you need to know about whether a structure is helping or not. And finally, be willing to reverse it. Hanging your mind in the light of evidence is competence, not failure. And a leader who can unwind their own decision earns far more trust than one who defends it indefinitely. So four questions and the latest option that works and a review date in the diary. That's how you choose a scaling approach without gambling. So thank you for joining me in this lesson. In the next one, it's your turn. You will sketch a scaling plan for your own project. I'll see you there. 18. Practice Exercise: Sketch a Scaling Plan for Your Brief: Welcome back. In this lesson, we are going to sketch a scaling plan for your project. One page that is honest and specific. I'll go through mine on screen in Notion, and then you can pause and you can build your own. Notion is free, and everything today works on the free plan with no add ons. So let's begin. Four steps. One state the real problem in one sentence and be specific about what's actually hurting. Two is answer the four questions. So teams, product, appetite, independence, and write the answers down where you can see them. Three is choose the lightest option, naming both the practices you'll adopt and the ones that you will deliberately skip. Then four set a review date so that you've committed in advance to checking honestly whether it worked or not. Your sketch needs four short sections, and it should fit on a single page. The first is the problem, what's actually hurting in one plain sentence. Two is team shape, how many teams and who owns which part of the product. Three is coordination, the specific practices that you use to keep all of those teams aligned, and what you are skipping, the parts of the frameworks that you are deliberately not implementing with a brief reason as to why. That last section is the one that people usually leave out, and it's one of the most useful of the four. So writing down what you're not doing and why stops it being relitigated every month, and it also makes clear that your choices were deliberate rather than accidental. So let's have a look at how to do it in notion. Again, a free page with no add ons needed. First, you have the problem, a single sentence at the top, so it anchors everything else. Then you have a team table with the team the area owned and who represents it at the sink and a dependency list. So what's needed from whom and by when, and this is reviewed weekly. So let's switch to notion and have a look. I have my EdTech project hub right here, and I've added a page at the bottom here called scaling Plan. In there at the top, I've added the problem. The problem is our team can't keep up with demand across the learner app and the teacher dashboard, and both need to ship independently. So I've added the team table here, the Team column. Area owned and the team's representative. So for the learner team, the area owned is lessons, quizzes, progress badges, and the representative in the meeting is going to be Pria. The teacher team, they own the dashboard and the class reports. Their representative is Sam, and the platform team who own login payments and a shared design system. The representative of that is Alex. And then below that, I have another small table with the dependencies. So what's needed from whom and by when. First, we have the login endpoint from the platform team by Sprint 17. Is a shared design system components for the parent view, and that would be from the platform team as well, by Sprint 18. And then finally, the approved copy of new lessons, and this comes from not the Nar team, the learner team, and that should be done by Sprint 18. So here we have the scaling plan and what a simple scaling plan looks like, which is also honest about the problem. So now you can sketch your own, and when it's done, you can check it against these four things that it names the real problem, not that we're growing, but something specific that's costing you right now. Check that it's the lightest option and that you genuinely could not remove any part of it without the problem coming back. Third, it says what you're skipping with deliberate omissions rather than accidental gaps, and then four, it has a review date, plan that you've committed to reexamining with some fresh evidence. If you hit those four things, then you've got something far more useful than most scaling initiatives ever produced. Scaling plan on one page, naming a real problem and the latest thing that solves it. That is a genuinely senior piece of work. Thank you for joining me in this lesson and this section. In the next section, we will turn to quality and risk, how to build both without drowning in paperwork. I will see you then. 19. Quality Is Everyone's Job: Building It In: Welcome back. In this lesson, we're going to talk about quality and specifically about why it can't be somebody else's job. There is a habit in a lot of organizations of treating quality as a stage near the end owned by whoever is holding the testing budget. That approach fails quietly and expensively. And by the end of this lesson, you will know what to do instead. So here's the idea the whole lesson rests on. Quality is not a phase. It is a habit. You cannot test quality into a product at the end. By the time something reaches a tester, the decisions that determined whether it's any good were made days or weeks earlier by people who weren't thinking about quality at that time. Testing at the end tells you what you've got. It doesn't change what you've built. So where does quality actually happen at every single step, not just the one marked testing. It starts at the idea where you decide whether this is worth building at all, then design, where you decide whether the thing will make sense to a human being. Then build where the craft goes in, then review where a second pair of eyes catches what the first one didn't, and finally, release where you decide whether this is genuinely ready to meet real people. Notice the trap in that sequence. A bad idea clearly specified and beautifully built is still a bad idea. Quality at the later steps cannot rescue a failure at the first one. That's why the cheapest quality work happens at the end where a flawed idea costs minutes to fix rather than at the end, where the same floor can cost days. Now, if your team writes automated tests, there's a shape those tests should have, and it is usually drawn as a pyramid. Let me take it from the bottom up. First, at the base unit tests. Many of them and very fast, these are tiny checks on single pieces of logic and a good suite of them runs in seconds. Second, in the middle, integration tests, fewer and slower. These check the separate parts, talk to each other properly, which is actually where a surprising number of real bugs live. And third, at the we have end to end tests, only a few and slow. These walk through whole journeys in a real system, which makes them genuinely valuable tests and also brittle and expensive to maintain. The shape here matters. Teams that invert this pyramid with hundreds of slow end to end tests and hardly any unit tests end up with a test suite that takes an hour to run and fails at random. People then start ignoring it, which is worse than having no tests at all because now you have some false confidence. You don't need to write these tests by yourself, but you do need to recognize the because if your team tells you the pyramid is upside down, they are telling you something important about why everything feels slow. This chart is probably the single most useful thing I can show you about quality. It's the cost of fixing the same defect depending on when you find it. At the idea stage, fixing costs a conversation. At design, it costs a redraw. During the build, it costs some rework. In testing, it costs a bug report. A fix, a re test, and a delay. And once it's live, it costs all of that, plus the incident, plus the support load, plus the erosion of trust from the customer who hit the problem. The curve climbs steeply, and that's the whole economic argument for building quality in early. So if quality is everyone's job, let's be precise about who owns what? Be shared responsibility with no specifics, is how things often get dropped. Team owns three things. First, the definition of done, the agreed standard applied to every item, not just the ones with time leftover. Second, peer review. Nothing merges on one person's judgment alone, and third raising concerns, being able to say this isn't ready without it costing them anything. You own three different things. First, protecting the time, quality work, gets real capacity in the sprint, not whatever's left at the end. Second, holding the standard and specifically holding it when a deadline makes it tempting not to because that's the only moment that your standard is actually tested. And third, making it safe, so bad news travels fast and costs nobody their head. If your team hides problems from you, you will find out about them at the worst possible time. So, quality is built in rather than tested in, and the cost of finding a defect climbs steeply the longer you leave it, and everybody owns a specific piece of it. Thank you for joining me in this lesson. In the next one, we will tackle technical debt explained without any single lines of code. I'll see you there. 20. Technical Debt Explained for Non-Developers: Welcome back. In this lesson, we are going to talk about technical debt, and I'm going to explain it without any code because you don't need to be a developer to manage technical debt well. You do, however, need to understand it because it's one of the main reasons that a team that used to be fast becomes slow, and it is also one of the hardest things to explain upwards. So let's begin. Let's start with the definition. Technical debt is the cost of a shortcut taken today. You get the speed now and you pay interest on it every sprint afterwards. The metaphor is financial and it's quite a good one. There are two parts to it. First, there's the debt itself, the messy code, the missing test, the workaround that you left in place. Second, and more importantly, there's the interest. So every future change in that area takes a little bit longer than it should. And that's the part that people miss. The shortcut isn't a one off cost that you absorb and forget. It's a small tax on everything you do in that area from now on. And this metaphor has a limit that's worth knowing about. Unlike a real loan, nobody sends you a statement. There's no monthly reminder telling you how much you owe, which is exactly why technical debt accumulates unnoticed. Now, here's the thing that people get wrong about technical debt, and it matters if you're going to have a sensible and honest conversation with your team. Debt is not the problem. Unmanaged debt is. Every real product carries some kind of technical debt. A code base that has none is usually a code base that nobody has shipped anything from. So the goal is never zero. The two questions that actually matter are, did you choose this debt deliberately and are you paying it down? If you get those two questions right, then debt is simply a financing decision, which is a perfectly respectable thing for a team to make. Helps to know that debt comes in different kinds because they deserve genuinely different reactions. So let me give you three of those. First is deliberate debt. That's a shortcut taken knowingly to hit a deadline. We'll do it the quick way now and we'll come back after the launch. It feels like a conscious trade off. And it is one, provided that somebody actually wrote it down. The right response is to simply schedule the repayment. Second is accidental debt. This is the code that was perfectly reasonable when it was written. And then the team learned a better way to do it. Nobody did anything wrong. It's just what learning looks like in a code base. And the right response is to refactor as you pass through, tidying the area next time you are working in it anyway. Then third, we have decay. Nothing changed in your code at all, but the world moved. For instance, a library went out of support, a platform version aged out, a dependency stopped being maintained. Now, this feels like slow rot that nobody quite notices until it's too late and something breaks. The right response for this is to budget for it routinely because it arrives whether you touch the code or not. Now you probably won't see the debt directly. What you will see are the symptoms, and here they are in roughly the order that they tend to appear. First is that estimates start coming back strangely high. So somebody says, that'll take longer than you'd think about a change that sounds trivial, and they're right because they can see the mess and you can't, the same area of the product keeps breaking. When one part generates a suspicious share of your overall bugs, that's not bad luck. That's a signal. Third, people start avoiding it. There is a part of a system that everybody quietly roots around and work gets designed to stay clear of it. That's a very late stage symptom, and it's quite a serious one. And finally, new people take months to become productive because the system defies explanation and only real documentation is in somebody's head. If you're hearing those, you don't have a motivation problem or an estimation problem. You have debt problem, and it will keep getting worse until somebody funds the repayment. So how do you manage it without turning it into a crusade? There are five habits, and none of them is particularly heroic. First is keep a visible list. Debt nobody has written down is debt that nobody will ever fix because it can't compete for attention against work that has a ticket. Second, reserve capacity each sprint, something like a tenth is reasonable starting point. The exact number matters far less than the fact that it's protected and doesn't get raided the moment a deadline appears. Next is repay where you're already working. Debt repayment that happens inside normal delivery is sustainable. Separate three month cleanup project is a thing that gets canceled in month two. Fourth, tie it to delivery. Don't ask for time to reduce technical debt because that sounds a little bit like housekeeping. Say that this repayment makes the next feature two weeks faster and name the feature. Same work, but with a completely different conversation with the people who fund it. And finally, never negotiate it down to zero for more than a sprint or two. Skipping repayment once is a decision. Skipping it every time is a trajectory, and everybody on the team can already see where it ends. So debt is the cost of a shortcut. The interest is what actually hurts, and the goal is deliberate. Manage debt rather than none. Thanks for joining me in this lesson. In the next one, we will look at managing risk without producing a document that nobody reads. I will see you there. 21. Risk Management Without a Risk Register: Welcome back. In this lesson, we are going to manage risk, and we are going to do it without a traditional risk register. Now, I want to be careful here because I'm not against writing risks down, per se. I'm just against the ritual that usually surrounds it. By the end of this lesson, you will have a lighter approach that actually changes decisions, which is the only thing risk management is actually for. So let's start with why the classic register so often fails, and it isn't the document itself, it's what happens around it. First, it gets written once and never reopened. Filled in at a kick off to satisfy process gate, and then it sits in the folder while the actual risks evolve. Second, it's owned by nobody. There's a column marked owner containing the name of a team or a department, which means that no individual human is thinking about it. And then finally, everything gets graded into meaningless. So everything is amber so nothing gets attention. You've sorted nothing and prioritize so let's look at what works instead. The things mirroring those failures. First, a short living list, five risks you could recite from memory because a list you can't remember is a list that you aren't managing. Second, a named person for each one, one actual human who is thinking about it. And third, review it in the open in planning where decisions genuinely get made rather than in a governance meeting where it's merely reported. Here is the sorting tool and it takes about 30 seconds per risk. Two questions, how likely is it, and how bad would it be? If you plot these two against each other, you will get a grid. Now, likelihood runs up the side and impact runs along the bottom, where a risk lands tells you what to do with it. If it's in the top right, if it's likely and severe, you should act now and today before you do anything else. Bottom left is unlikely and mild. You can ignore it genuinely and stop spending attention on it. The middle band you keep an eye on, the value of this isn't the grid itself. It's the forced comparison. And once risk sits next to each other, it becomes obvious that you've been worrying about the wrong one, which is a conversation a list in a document will never start. Now the test that separates real risk management from the theatrical kind, a written down risk is not a managed risk. So here's how to apply it. So look at your list and ask for each item, what is different about our plan because of this. If the honest answer is nothing, then you haven't prevented a surprise. You documented one in advance. And when it lands, you'll have the singularly unhelpful experience of finding it on a list you wrote three months ago and did nothing about. So, this brings us to the responses. Every risk you keep on the list gets one of four or it isn't being managed. Let me take them in order of how much they change your plan. First, avoid it. Change the plan so the risk simply cannot happen. If a third party integration is your biggest danger, not depending on it removes the risk entirely. So that's the strongest move, and the most often forgotten move. Second, is to reduce it, make it less likely to happen or less painful if it does happen. Now, that's what Spike does or a backup supplier or a phase rollout that limits the blast radius. Third, transfer it, move the risk to whoever is better placed to carry it, which is what insurance is and what a supplier contract with penalties is. And finally, accept it. To decide openly to live with it and say so out loud, that's a legitimate answer and often the right one, but it has to be said out loud and agreed because silent acceptance is just neglect with nice manners. So finally, where does all this actually live? The answer is in the meetings you already hold, which is what lets you skip the separate risk process entirely. First, in planning, before you commit to the sprint, ask what could stop this. That's risk identification, and it takes about 2 minutes. Second, in the daily stand up, today's blocker is simply yesterday's risk arriving now. Blockers are risks that came true, so listen to them that way. Third is in the review. Watch which of your assumptions the demo just proved wrong because that is free information about what else you might be wrong about. And finally, in the retrospective, ask which risk you saw coming and did nothing about, which is the question that over time will improve your judgment the fastest and the most comfortable sorry, it's the most uncomfortable one to ask. So a short living list, a person against each risk, and a grid to sort them, and one of four responses that actually changes the plan. No separate ritual required. Thank you for joining me in this lesson. In the next one, we will look at spikes and prototypes and how to untack the unknowns before they attack you first. I'll see you there. 22. Spikes, Prototypes and De-risking Unknowns: Welcome back. In this lesson, we are going to deal with the unknowns, the parts of your project where nobody quite knows how hard it's going to be. We'll cover the three tools that are constantly confused with one another, how to run one of these properly, and how to decide which unknowns are worth spending time on. Let's get into it. So here's the trap. Teams estimate unknowns instead of investigating them. Somebody asks how long the new payment integration will take, but nobody actually knows and rather than say so, the team produces a number and a confident number attached to a genuine unknown is fiction with a decimal point. It gets into a plan, the plan gets committed to, and then three weeks later, everyone is all of a sudden surprised by something that was entirely knowable at the start. So there are two ways to respond to an unknown. The instinct is to guess commit and to hope that the guess holds, but the discipline is to spend a little time buying the missing information and doing that first. So this is what this lesson is all about. So there are three tools, and they genuinely get muddled constantly. So let me be precise. They answer three different questions. First, a spike. The question is can we do this and roughly how? The output is an answer and usually some throwaway code, and the time box is a day or two strictly. Second, a prototype. The question is entirely different. Will people understand this and do they want it? The output is something a user can actually react to, and that might be a clickable screen with nothing behind them, for instance, it takes days and it's rough on purpose because polish invites feedback about the polish. Third, a proof of concept. The question is, does the approach work at all? The output is a narrow and a working demonstration of the risky part and nothing else. The time box here should be short and it should answer exactly one question. The distinction that matters the most, a spike is aimed at a technical uncertainty. A prototype is aimed at a human uncertainty. Reaching the wrong one here means you'll spend a week answering a question that nobody was even asking. So let's run a spike properly because an unbounded spike is just unmanaged research. So there are four steps. First, write the question down in one sentence. If you can't write it, then you are not ready to start, that in itself is useful information. Not investigate the payment provider, but can we take a payment in under 3 seconds using their standard interface? Second is set a hard time box, two days maximum. The clock is the entire discipline here because without it, a spike quietly becomes the project itself. Third, agree in advance what answered means, decide what evidence would settle the question so that you're not relying on somebody's feeling on Thursday afternoon. And finally, report back and bin the code. The output of a spike is the answer, not the builds. Last step deserves its own moment because it's the one that goes wrong most often. A spike does not ship, I answers a question. Spike code is written fast with no tests and no error handling to answer one question. The moment somebody says it basically works, let's just tidy it up. You've taken your quick deliberately disposable experiment and made it the foundation of a product. You've swapped a small risk for a large one, and you've done it at the exact moment that everyone felt relieved. It and write it properly with what you've learned. So when is this worth the time? Because you can't spike everything and a team that investigates every single unknown never ships. There are four steps to decide. First, spot it, name the thing that you genuinely don't know. Second, size it, ask how bad it would be to get this wrong. Third, spike it, but only if the answer to the second question was bad, finally, decide using what you learned. The filter here is the combination of the two things uncertainty and cost. Spike the unknowns that are both genuinely uncertain and expensive to get. Unfamiliar technology sitting on a real deadline is worth two days of investigation. Something you've done many times and simply don't enjoy is not an unknown. It's just a chore. And no amount of investigating will make that chore more pleasant. So spikes for technical unknowns, prototypes for human ones, a hard time box on both, and a filter that stops you investigating everything. Thanks for joining me in this lesson. In the next one. It's your turn, and you will identify and plan for three real risks on your own project. I'll see you there. O 23. Practice Exercise: Identify and Plan for Three Risks: Welcome back. This is a practice lesson, and we are going to identify three real risks on your own project, and we're going to plan what you'll actually do about each risk. I will show you mine on screen in Notion, and then you can pause and build your own. Everything today works on Notion's free plan with no add ons required. Here's the exercise in four steps. First is to list your risk, get all of the risks you can think of in your head and get them down on the page without judging any of them just yet. Next, is to sort them using likelihood and impact. Third, is to choose a response for each one, either avoid, reduce, transfer, or accept, and finally, assign an owner and assign that owner by name. So two things to do before you start. Do this with your team rather than alone because they can see risks that you structurally cannot and particularly the technical ones. And aim for at least three risks. Three risks that you can genuinely act on are worth far more than 20 that you merely just list. Be concrete as well. Delivery risk is a category, not a risk in and of itself. So name the actual thing that could happen. Let me sort three example risks so you can see how the placement drives the decision. The first is scope creep. It's highly likely because it always is, and its impact is moderate. That puts it top middle in the act now band and the response is to reduce it. Agree a change across a process now before it's needed. Second, a payment vendor delay. It's moderately likely and high impact if it lands because nothing ships without it. It's the middle right, also act now, and the sensible response is to reduce it by starting the integration early and by having a fallback. And third, a key person leaves. This is genuinely unlikely in the next few months, but it's high impact because a lot of the knowledge sits with them. So this is in the bottom right, so keep an eye on it and reduce it by gently spreading that knowledge around the team. Now notice that all three of these got a different level of urgency out of the same two questions. And none of that came from arguing about it. So let's have a look at how to write it up in notion. You only need one small table on the free plan. Four columns are enough. Maybe you can maybe you might want to use five or six. But the four columns are enough, you should have the risk written as a specific thing that could actually happen. Likelihood and impact, the response, which would be avoid, reduce, transfer or accept, so pick one of those. And the owner by name, plus the date you will next look at it. You might want to separate those into two separate columns. And everything here, as mentioned before, is on Notion's free plan. No need for any subscriptions or add ons. So let's go to my EdTech Project Hub. I've added a page here called Project Risks. And when we go into it, we have the title, and we have a table. Now, I've actually included six columns here. I'll show you exactly why in a minute. So first, we have the risk column. We have the likelihood column, impact column, the response column, the owner, and the review. So here I've got the first risk. The scope of the parent dashboard keeps growing. The likelihood is high, the impact is medium. Response is to reduce, the owner is Pria and the review is at the next sprint planning. The second risk, the payments vendor integration slips past our launch date. The likelihood of this is medium. The impact has been deemed high. The response here is to reduce it. The owner is Sam, and the review will be in two weeks time. And then finally, the third risk is that Alex is the only person who understands the logging service. So the likelihood of someone leaving is low, but the impact is high. And again, the response is to reduce the owner of that is me. Now, I've put me here, meaning the project manager because risk management is your job. And there will be some cases where you will be the one who will have to deal with the risk contingency plan or the risk, how you deal with the risk. Anyway, at the end of the month is when this will be reviewed. So a simple table of project risks. You might maybe you could have this page developed as your project goes along. Maybe you could have risks month by month or quarter by quarter. But you should have somewhere where you keep all of your risks. And in fact, in interviews from my own experience, this is a typical area of project management that has a question in an interview. So it's very typical in interview how you manage risks and how you foresee risks and what you do to manage them. So this is very, very important part of the notion, documentation. So now, you can pause a video and you can build your own. When you're finished, you should check your work against these signs. So the good signs first, each risk is specific enough that you could describe it to a colleague in one sentence. Next, something in your plan actually changed because of this exercise, and the owners named are individuals rather than teams. Now for some warning signs, if everything came out medium, you haven't really sorted anything, so force yourself to rank them against each other. If every response is accept, that's usually acceptance being used to avoid work. So look again at the top two. And if there's no review date, your list is already going out of date because risks change as the project moves. Well done. You can now build quality in rather than inspect it in, you can talk about technical debt in terms the business understands and you can manage risk without a register that nobody reads, and you can even attack your unknowns deliberately. Thank you for joining me in this section. In the next section, we will look at continuous improvement and how to build a team that keeps getting better without you having to drive every single step. I'll see you there. 24. Kaizen: Small, Daily, Deliberate Improvement: Welcome back. In this lesson, we're going to look at Kaizen, which is the practice of small, continuous deliberate improvement. It is the engine underneath everything else in this section, and it's the difference between a team that steadily gets better and a team that just steadily gets older. So let's take it apart. So here's the principle, not one big leap, but 1,000 small steps. Kaizen is a Japanese term meaning change for the better. And in practice, it means continuous incremental improvement made by the people doing the actual work. Instinct in most organizations is the opposite. Wait until things are bad enough to justify a big transformation. Then change everything at once. Kaizen says, improve by one small notch this week and then do it again. The improvement loop has four steps, and it's something that never stops turning. First is notice. Spot one specific piece of friction in how you work, something concrete rather than just a general feeling of dissatisfaction. Second, is try change one thing and make it small enough that you can start it today without the need for anyone's permission. Third is check. Ask honestly whether it actually helped using some concrete evidence rather than just a vague sense of things feeling better. And finally, keep or drop, either adopt it properly into how you work or discard it and move it on without regret. That fourth step is the one that some teams skip, and skipping it is why so many improvement efforts turn into a graveyard of half adopted practices that nobody quite follows and nobody quite abandons. Now, why insist on small? Because small changes compound in a way that big ones rarely do. So think about the arithmetic. One tweak in Sprint one is almost invisible, but by Sprint four, you've got four of them stacked up. By Sprint 12, the team is working at a noticeably different pace. And a year on, you have a genuinely different team without ever having run a single transformation. There is a risk argument, too. A big transformation is a bet, it's expensive, it's disruptive, and it might not work. However, a small change every sprint is compounding certainty because each individual step is cheap enough that being wrong costs you almost nothing. So it's worth being clear about what Kaizen actually is and what it isn't because the word gets borrowed a lot. So first of all, Kaizen is everyone's job and responsibility, especially the job of the people doing the work, because they are the ones who can see the friction that may be invisible from above. Next, it's small enough to try without asking permission. It's continuous, so it never has an end date, and it's evidence led, so you can actually check whether the change helped or not. What is and isn't a consultant led transformation program. It is not a change so large that it needs a business case and a steering group. It's not a quarterly initiative that quietly expires when everyone gets busy. Almost commonly, it's not a general feeling that things seem a bit better now, which is not really measurement. It's more like optimism. So how do you start this week? Deliberately and unambitiously, there are four steps. First, ask the team a very specific question. No how could we improve, which produces silence and is too general, but something more like, what wastes your time every single week. Now, that question will get answers because everyone has one to give. Second, is pick the smallest one. Resist the urge to go straight for the most important problem because the part of the first loop is to prove that the loop works, not just to fix the biggest thing first. Third, is change it for one sprint and agree in advance what better would look like. And finally, check honestly at the next retro, keep it, adjust it, or drop it, and then run that loop again. That's the entire practice of Kaizen. So small, daily deliberate and checked rather than assumed. Thank you for joining me in this lesson. In the next one, we will look at the culture that makes all of this possible and how to build a team that learns rather than hides. I'll see you in the next one. 25. Building a Learning Culture on Your Team: Welcome back. In this lesson, we're going to build a learning culture, which is the environment that makes every other improvement practice actually work. I'll be concrete about it because talk about culture can get vague quite quickly. So we'll look at the specific sentences that damage this culture, the specific responses that build it, and the habits that will make it stick. Let's start with the foundation which has a name, psychological safety. It's the shared belief that speaking up won't be punished. And I want to be precise here because it's widely misunderstood. It is not about comfort, and it certainly isn't about everyone being nice to each other. It's the freedom to say the awkward thing. I think the plan is wrong, or I broke the build, or I don't understand what we're doing without it costing you socially or professionally. So with that, problems surface while they're still small and cheap to fix. But without that, problems surface at the worst possible moment. Because everybody knew but nobody said anything. So let me give you some sentences that quietly kill this learning culture. These are well meaning things that leaders say all the time. The first is, how did nobody catch this? It sounds like curiosity, but really it's heard as someone is about to be blamed, and it had better not be me. The whole room quietly starts preparing a defense rather than thinking about the real cause. Second is, I don't want excuses. I want solutions. This sounds decisive, and it may be on a poster somewhere, but what it actually teaches people is to hide any problem that they can't already solve, which means you only hear about the ones that are still manageable and never about the ones that are getting away from everyone. So two more worth watching for, we've been through this already. Teaches people that asking again is a sign of weakness, and who signed this off, which converts a technical discussion into a hunt for a name. Said once in a bad week, these are forgettable, but said habitually, and they become the culture, and people learn precisely what it costs, to be honest with you. So here is the shift that undoes all of that. Ask what happened, not who did it. Blame explains an event wants and satisfies the urge to have someone accountable. Understanding the system prevents the next 20 events, and the practical test is simple. When something goes wrong, notice whether your first question contains the word who. If it does, replace it every time until the replacement is automatic. Let me show you the two responses side by side because the same incident produces two entirely different futures. The blame response goes like this. First, who did it? Second, add a rule, usually a new checklist item that nobody will read a year from now. And third, move on quickly because the discomfort has been discharged. The problem is that the discomfort ending is also the learning ending. The learning response goes differently. First, ask how it was possible what made this easy to do and hard to second, fix the conditions so the same mistake becomes harder for anyone to make again. And third, share it openly. So one team's failure becomes everyone else's lesson rather than one person's private embarrassment. So finally, how can you actually build this? You do it not by announcing it. Culture is built by repetition, and here is what to repeat. First, go first and often, name your own mistakes out loud before you expect anyone else to. So I set that deadline badly, and it cost us two days. Nothing you say about safety will outweigh what people see you do with your own errors. Second, reward the messenger. When someone brings you bad news, thank them visibly every single time, especially when the news is genuinely inconvenient. People are watching what happens to that person far more closely than they're listening to your values. Third is rum run blameless postmortems. Examine what happened without naming who until it becomes a habit rather than an event. And finally, protect learning time. Time to read, experiment, and share is capacity, not slack, and it's the first thing that tends to get cut when a deadline looms. Defending it is a leadership act. So psychological safety as the foundation and the word who removed from your first question and small repeated habit rather than a values poster. Thank you for joining me in this lesson. In the next one, we'll look at how to measure whether your team is genuinely healthy, not just productive. I'll see you there. 26. Measuring Team Health, Not Just Output: Welcome back. In this lesson, we're going to measure team health. Delivery metrics tell you what came out of the team. They tell you almost nothing about whether the team can keep producing it. And that second question is the one that will decide your next six months. So let's look at how to answer that question. Here's the blind spot. Team can hit every date and still be failing. Output metrics are backward looking. They describe what was delivered. They say nothing about whether the people who deliver it are actually learning trusted, sustainably paced, or about to resign. Team can be hitting every single commitment right up until the week two people leave. And from the outside, that looks like a sudden problem. It never was. So here are five dimensions worth watching. Together, they can give you a sample picture of how the team is really doing. First is psychological safety. Can people speak up without it costing them? Second, is clarity of purpose. Does the team know why this work matters and to who third, sustainable pace. Could the team work at this rate for another year? Fourth is learning and growth. Is anyone getting better at anything? And fifth is trust in the process. Does the team believe that the way you work actually helps or do they just endure it? There are two rules for this. It's scored by the team, not by you, because your view of the team's health is systematically the most optimistic. And the pattern matters far more than any single number. So in the example on the screen, safety and clarity are strong while pace is strained and learning is weak, and that is a very specific and actionable story. This team is well led and well liked, and it's being run too hard to grow. Three ways to find this out, and each catches something that the others miss. So first is the survey. So five simple questions scored one to five run at the same time each month. It's good for spotting trends and for hearing quiet voices who won't say it aloud. The critical condition here is anonymity. A survey people sign is a survey that people will manage. Second is the one to one. So a regular, unhurried, private conversation. This is the best source of depth and nuance, and this is usually your earliest warning of a problem. But that would depend entirely on the trust built long beforehand. So don't expect a candid answer in the first month. And the third is the signals, what you observe without asking. Now, this is good for noticing change as it happens, but this is easy to misread. So check what you think you're seeing before you act on it. On those signals, let's look at some specifics because read the room isn't really actionable advice. So healthy signs first. People disagree openly in meetings and then commit to the decision. Bad news reaches you early and calmly. The team fixes small annoyances without asking permission to do it, and holidays get taken fully without guilt or any apology. Now, here are the warning signs. Retros get shorter and more polite each time, which usually means that people have concluded that honesty changes nothing. You hear about problems only once they are urgent. Cameras go off, silence settles and nobody asks questions. Finally, resignations arrive without warning, which is almost always the end of a long, quiet process rather than a sudden decision. So practical routine here 20 minutes, once a month, and four steps. First, is score the five dimensions individually and anonymously one to five. Second is show the team the results before you discuss them with anyone else because that single choice alone can determine whether they'll answer honestly next month or not. Third, is discuss only the lowest scoring dimension because one is genuinely enough. And then finally, agree one change and report back on it at the next check. One little warning here if you collect this and nothing ever changes, you will have built a very efficient machine for teaching your team that you don't act on what they tell you. So don't run the check until you're prepared to do something with it. So five dimensions, which are all scored by the team, three ways to gather it, and one change acted on each month. Thank you for joining me in this lesson. In the next one, we'll take a look on the biggest health risk of all, which is burnout and what you can actually do about it if it happens in your team. I will see you there. 27. Avoiding Burnout While Staying Productive: Welcome back. In this lesson, we are going to talk about burnout, what actually causes it, how to recognize it developing, and what you as a leader can do. Now, I want to be quite careful with this one because burnout is a very serious and common matter, and it often is discussed either as a personal failing or something that a well being app can solve. And in reality, it's neither. So let's start with the pace because Agile has always said this, and most teams may comfortably ignore it. There are three settings, and you should know which one your team is on. First is sustainable. The team could work at this pace indefinitely and still think clearly. That's the target, and it should be the normal state. Second is strained, which is fine, genuinely fine for a short period. It becomes damaging if it becomes the standard week. Third is unsustainable. At this point, you're borrowing from people's health, and the bill will always arrive usually as illness, mistakes, or resignations. The practical argument here, if you need one beyond the human argument, crunch works briefly and then quietly reverses. You get more hours and you get less delivered because tired people make errors that cost more time than the extra hours brought in the first place. What actually causes burnout? It's rarely just a number of hours, which is why go home earlier often fails completely as advice. There are four causes here. First is sustained overload, consistently more work than there are hours with no end in sight. Notice the word sustained, a hard fortnight is not really burnout, an endless. Is burn out. Second is no control being told exactly what to do and precisely how to do it with no say in either. Third is the effort without meaning, so working on things that get canceled or shelved or ignored, which is corrosive in a way that hard work on something that matters simply isn't. And fourth is unfairness. Some people visibly carrying the load while others visibly do not. So look at this list again and notice something important. Every single one of those is a property or a failure of the system, and that system is yours to change as the project manager. So it also helps to know how burnout progresses because it rarely arrives suddenly. First is enthusiasm and long hours. This stage is often praised, and it's also mistaken for commitment rather than being recognized as the warning that it is. Second, tiredness that risk just does not fix. The weekend stops working, and Mondays start feeling like Fridays. Third is cynicism and detachment, where caring becomes a way paring less becomes a way of coping with having cared too much. You might hear it as it doesn't matter what we do anyway. Someone who in the past, used to be passionately argumentative about the work. And fourth is withdrawal. They're quieter in meetings. They are absent from the things that they use to drive. Now, the third stage, cynicism and detachment is the one that people miss because sometimes it can come across as a bad attitude, and usually it isn't one. So here's the honest bit, and it's a reason that a lot of these well being initiatives just do not work. Burnout is a workload problem, not a resilience one. So if your team is drowning, resilience training teaches them to drown more stoically. Fruit baskets, meditation apps these well being webinars are not inherently bad things, but offering them instead of changing an unsustainable system is at best, a distraction, and your team will read it as one. Only changing the system actually changes the outcome. So, what can you actually do as a leader? Encouragingly, most of the levers are yours rather than theirs. And here are five of them. First is plan to a pace that the team could sustain for an entire year, not for a fortnight. Second, is end every crunch with genuine recovery and say so publicly because crunch with no recovery simply becomes the new baseline. Third, is give people real control over how their work gets done since autonomy is one of the strongest protective factors there is. Fourth, is spread the load, watch for the person quietly carrying the team because they're the ones who are usually the last ones to complain, but the first ones to break. And then finally, take your own holiday properly because without this, your team will not copy what you do, and they may ignore what you say. So yeah, take your holidays. The team usually will do the you're a manager, not a clinician. If someone is struggling, your job is to reduce the load and point them towards professional support, whether that's occupational health, whether that's your employee assistance program or HR or even their doctor. It's not your job to diagnose them and it's not your job to become their therapist. Watch the pace, fix the system rather than the person, and know where your responsibility ends. Thank you for joining me. In the next lesson, it's your turn and you will do some designing of an improvement loop that runs on its own. I will see you in the next one. 28. Practice Exercise: Design Your Team's Improvement Loop: Welcome back. This is a practical lesson, so it's your turn to build something. We are going to design your team's improvement loop, a small repeating routine that keeps the team getting better without you personally having to drive every single step. So I'll show you mine in notion, and then you can pause and you can build your own. This all works on the free plan in Notion in the browser with no add ons required. So here is the exercise in four steps. First is to pick a signal, decide what will tell you that something needs improving. Second, is set a rhythm, decide how often you look at it. Third is name and owner, so the loop belongs to a particular person rather than the team. And then finally, close the loop, decide where the outcome gets recorded and reviewed. Two constraints here before you start. Only design one loop, not three because a single loop that works beats three aspirational loops. And then, second, is keep it small and dull. If your loop sounds exciting, it's probably too big to sustain past month two. So let me fill the loop in so you can see what a real one looks like. First is notice. Our signals are the monthly Team health check and the recurring themes from retrospectives. Second is try. So one change agreed at the retro with a named owner. Third is to check reviewed at the following retro, asking plainly whether it helped or not. And then finally, keep or drop, we either adopt it into how we work or we discard it and we say so out loud. How unremarkable this is. And that's the whole point. It's four sentences. It takes almost no extra time, and it will outperform any improvement initiative with a name and a logo. So next is choose your rhythm and match the cadence to the signal. First, retroactions, every sprint owned by the person who took the action. Second, the Team health check monthly, and it's owned by you. And then third, a review of the improvement quarterly owned by the whole team, where you look back and ask what has genuinely changed. The single most useful thing you can do with those is to write them into the calendar as recurring events. A rhythm that lives in your memory dies in a busy month, but a rhythm in the calendar will survive that busy month. So, let's have a look at the page in Noon, going back to my ED project Hub at the bottom, I've added a new page called Improvement Loop. And again, it's quite a boring page. We have the Titleimprovement loop. I've used Heading two here and typed the Loop, where you have the four stages, notice to a monthly check plus retro themes. Try one change, agreed at the retro with an owner. Check reviewed at the next retro. Did it help? And then keep or drop. So adopt it or discard it. Then we have our rhythm. I've bolded the rhythm here. So every sprint, we review the retroaction. Every month, we run the Team health check, and then every quarter, we review the improvement log. And here below, I have the improvement log, again, with heading two, with a simple table with three columns, the date change that we tried, and then what happened. So here, I've added yet either kept or dropped, and then the reason why. At the bottom, I have the loop owner and the last review date, which is March, again, using heading two. These should be very large because yeah, the loop owner is very, very important, as is the last time that it was reviewed. So again, this is something that only takes a few minutes, but can save you a lot of heartache in the long run, and it can also lead to some incremental and compounding improvements in your team. You can pause the video here and you can make your own improvement loop. So when you've done, you can check your work against these good signs and bad signs. The good signs, first, it runs on a rhythm, not on your memory. Each step has a named person attached to it. And third, the changes are small enough to try immediately without a business case or without asking for permission. Now, there are three warning signs. The first, it only happens when things are already going wrong. That's not an improvement loop. That's a fire alarm. Actionary. If you are the owner of every single step, this will stop the week that you're on holiday, and if nothing has ever been dropped, then nothing was ever really being tested, which means that you are collecting practices rather than improving. Wonderful. You can now run small deliberate improvements. You can build culture where people tell you the truth. You can measure how your team is genuinely doing. You can protect them from burnout, and you can wrap the whole thing up in a loop that runs itself. Thank you for joining me in this section. In the next one, we will bring everything together in the capstone and wrap up the entire course. I'll see you there. 29. Putting It All Together: Your Full Project Review: Welcome back. This is the capstone, so we're going to step back from the individual practices and review your whole project honestly. Not a status report and not a presentation for anyone above you. A genuine assessment of where you stand right now, so you know precisely where to put your next effort. Let's do it properly. Here is the framing. You've built all of the parts. Now look at the whole. It's very easy to be busy improving individual pieces and never asking the wider question, which is simply, is this project actually in good health, and how would I know? That second half matters. A review built only on impressions tells you what you already believed. A review built on evidence occasionally tells you something that you didn't want to hear, which is the entire point of doing it in the first place. Review has five passes, and I would take them in this order. First is delivery. Are we producing what we said we would at a predictable rate? Second, is process. Is the way we work helping or has it become ceremony? Third, people is the team healthy, learning and sustainably paced. Fourth is risk. Do we know what could derail this project, and are we doing anything about it? And finally, is next. So given all of this, what changes? Order is deliberate. Delivery is the easiest to see and the least revealing. People is the hardest to see and the most revealing. And the last pass depends entirely on the four before it. So resist the urge to jump straight to the solutions. Two ground rules throughout every judgment should be backed by something that you can actually point at, and the review should be honest rather than flattering. A review that services no uncomfortable findings isn't really a review. It's more of a celebration, and you can have one of those separately, if you wish. Here's how to score your project honestly. There are five judgments, each one out of five, and I would suggest these five dimensions. First is delivery predictability. Do we hit roughly what we forecast? Second, is process fit. Does how we work suit the work we're doing? Third is team health. How are the people doing genuinely? Fourth is risk management. Are we proactive or do we just describe problems after they arrive? And fifth, the improvement habit. Do agreed changes actually happen on the example scores that you can see, delivery and team health are strong at four out of five. Process fit and improvement habits sit at three, and risk management is at two described as reactive. We name risks, and we rarely act. And here's the thing to notice to notice. The lowest score is usually the most useful number on the page. It's tempting to talk about the fours because they're pleasant. Your next quarter, though, belongs to the the one that you've scored two out of five. To ground these scores in evidence, look at four things and know what question each one answers. First, is your board. Is work flowing or is it piling up somewhere in particular? Second, is your backlog. Is the priority genuinely clear? Or is everything somehow urgent? Third, your metrics. Are we actually improving or are we merely all just busy? And then fourth is your retro log. So do agreed changes actually happen? That last one is probably the most revealing document in your entire project. And the one that nobody looks at. If you read six months of retro actions and most of them never landed, then you've diagnosed something far more important than any individual problem on that list. Finally, how to run all of this well. Set aside half a day once and then follow these four rules. First, do it with the team, not about them because their view is the precious data rather than just an input. Second, is to score first in silence and then compare afterwards, since live scoring simply measures whether whoever speaks first and most confident. Is discuss only the two lowest scores because everything else can genuinely wait. And then finally, finish with three commitments, each with a name and a date against it. Three commitments from half a day of an honest review will do more for your project than any amount of quietly worrying about it. So five passes, five honest scores, evidence behind each one and three commitments at the end. Thank you for joining me in this lesson. In the next one, we will build the deliverable that outlasts this project, which is your own Coaching playbook. I will see you in the next one. 30. Your Agile Coaching Playbook (Final Deliverable): Welcome back. In this lesson, we are going to build your final deliverable, your Agile Coaching Playbook. This is the thing that you keep. Projects end, teams change, and tools come and go, but a clear account of how you lead and why travels with you. So let's build it. First, what a playbook actually is. It's a short document describing how you lead and why. Want to be clear here about what it is not because this is where people go wrong sometimes. It is not a textbook summary. Nobody reads another restatement of the Agile principles, east of all you. It's your judgment made explicit enough that you could hand it to someone else, and they'll understand it. It's worth doing for two separate reasons for you because writing it forces you to decide what you actually believe and what you don't, and you'll discover that you're less sure about some things than you assumed and for others because it's how you hand your approach to whoever comes next, instead of it all leaving with you if you leave the company. So there are six sections. One page is plenty. Let me take them in order. First is the principle. So the handful of beliefs that you actually lead by. Second is leading when you coach, when you manage, and when you direct. Third is ceremonies, how you run them, and just as importantly, what you refuse to do. Fourth is improvement, so your loop with its signals, with the rhythm, and who owns it. And then fifth is risk and quality, so your standard and how you protect it when there is pressure. And then six is difficult moments, your scripts for the conversations that you don't really want to have. So this is six pages, and that is the entire deliverable, and the constraint is doing the real work here because it forces you to decide what matters most. Now, three of those sections carry the most value, so let me tell you how to write each one and what to avoid. First, in principles, you should write five beliefs in your own words and test each one by asking whether you'd hold it under real pressure because a principle that you abandon on a bad Friday is a preference and not a principle. Avoid copying the Agile manifesto backo. No one needs that. Second is improvement. So you should write your loop and its rhythm concretely, and you can test it by asking whether someone else could run it on a Monday without you explaining it to them and avoid aspirations with no owner and no date attached. And then, third, you have the difficult moments where you should write actual opening lines that you would use, not just address underperformance early, but the real sentence, something along the lines of I've noticed the last three items have slipped and I wanted to understand what's going on or what's getting in the way. So test this out by saying it out loud and by checking that you could deliver it calmly. Avoid vague intentions to be more direct in the future. Here's the test for the whole document. If it reads like a textbook, you haven't written it yet. Playbook is useful precisely where it is personal, specific, and opinionated. If someone could have downloaded it, it isn't really doing anything for you personally. The sentences that feel a little too blunt to publish are usually the ones that are worth keeping for you. So there are four checks that you can do before you call it finished. First is to check that it's short with six pages that somebody would actually read from start to finish. Second, it's specific with real sentences that you would say, not just principles that you admire from a distance. Third, it's yours. Someone who knows you would recognize your voice in it. And then finally, it's dated because you will agree with some parts of it, and then you might disagree with some parts of it a year in the future. And that is a sign of growth rather than a flaw in the so there are six short sections written in your own voice and specific enough to reuse and dated so you can watch your own thinking change. Thank you for joining me in this lesson. In the next one, we will look honestly at where to go from here, including whether certifications are actually worth your time and your money. I will see you in the next one. 31. Where to Go From Here: Certifications and Beyond: Welcome back. In this lesson, we'll look at where you go from here, and I will be as straight as I can with you about certifications because there is a lot of marketing in this area with not much honesty. So we'll cover the different kinds, the common paths, and how to choose without wasting money, and what actually builds a coach. Now, let me start with the honest part. A certificate proves that you sat an exam. That isn't dismissive, but it also isn't nothing. Certifications do open doors, and they do pass recruitment filters, and in some organizations, they are genuinely required. However, a credential on its own does not make anybody a better leader, and in fact, you'll probably meet people who are certified who can't run a room as well as certified people. Now, broadly, there are three kinds of certification, and they differ in how you earn them. First is exam only. You self study, and then you sit the exam. This suits disciplined self starters, and it's the cheapest option. So it suits people who are on a budget because no training is bundled in. Next is course based. You attend regular training, and then you certify. This suits people who want a guidance and a cohort to learn with, and this costs considerably more because it's the teaching that you're actually paying for. And then competency based, you demonstrate skill often over an extended period of time. This suits coaching and facilitation tracks. However, these are a little bit slower and they sit closest to the actual capability. One practical note, prices, prerequisites, and even the names of these things change regularly. So check the awarding body directly before you commit to anything. Don't rely on a course, including this one for current fees. You should search those yourself. So these are three common paths, and the right one depends on the job that you want next. First, the Scrum track, a foundation certification, then an advanced one, then a professional level. This is the most widely held certification and the most recognized, and it's framework specific, which is a strength, especially if your organization runs Scrum and limitation and it's a limitation if it doesn't. Second, a broad Agile track practitioner level credentials that cover several frameworks rather than one moving up towards portfolio level work. These su experienced project managers and usually require documented experience as well as an exam. And third, the coaching track. So coaching skills, then facilitation, and then expert level coaching. This is the one to look at if the leadership side of this course is what interests you the most. Scaling frameworks have their own tracks as well, and these matter the most when your employer has already adopted one. In which case, the choice is largely already made for. So how do you choose one of these without wasting money? There are four questions in this particular order. Number one, what does your employer use? If they are standardized on a specific framework, then that decision is effectively already made, and going against it is an expensive way to be principled. Number two, what's the job you actually want next? So read ten job adverts for it and note the credentials that keep showing up. That's probably better market research than any ranking article, including the ones that appear when you search for them. Number three is do you learn better taught or alone. Now, that honestly answers course based versus exam only, and it's the single biggest driver of cost. Then finally, who is paying? Player funded changes the calculation entirely. So always ask before you spend your own money because many organizations actually have a training budget that oftentimes goes unclaimed simply because nobody ever asks. So always ask first. And then finally, most importantly, what actually builds a coach? Because no certificate covers this part. So what genuinely builds skill is leading a team through something genuinely difficult, which teaches you more in one project than any course would. Next is being coached by someone who's more experienced than you. Next is reading widely, including the critics of your own methods, the ones that you use, because a leader who has only read the advocates has opinions rather than actual judgment. And then finally, a community of peers who will tell you honestly when you are wrong. And what merely feels like progress electing credentials without changing how you work, reading only material that agrees with you in your little echo chamber, advising others on things you've never actually done, and also quoting frameworks rather than solving the actual problem. If you have to choose between another certificate and a genuinely hard leadership job, you should take the hard job. You'll learn a lot very quickly. So, know what a certificate does and what it doesn't prove. Choose deliberately based on your employer and your aspirations. And remember that the real development happens on the job. Thank you for joining me. In the final lesson, we will wrap everything up and I will leave you with one more challenge. I will see you there. 32. Closing Thoughts and a Final Challenge: Welcome back and welcome to the final lesson of the course. In this lesson, we'll look at how far you've come. I will give you the single idea that I would most like you to keep, and then I will set you one final challenge. So let's finish well. First of all, let's take a moment to notice how far you've come because it's easy to finish something like this and then immediately think about what you still don't know. Now, there are five things that are true of you now that we're not at the start of this course. First, you lead rather than direct. You serve the team. And you coach where you once would have told someone what to do. Second, you run retros that actually change things. They are structured, they are safe, and most importantly, they are closed properly with owned actions rather than just simple good intentions. Third, you can scale or you can deliberately decline to, which is the rarer and actually the more valuable of the two skills. You build quality in and you manage risk deliberately inside normal work without ceremony for the sake of it. And fifth, you improve on a rhythm with a loop that would run whether or not you remember to start it. Now, that is a genuinely different practitioner from the one who started this course. Now, if you remember one thing from this course, make it this. The framework serves you, you do not serve it. Every practice that we've covered earns its place by helping a real team deliver real value to real people. By being correct, not by being certified or trending, not by being what a book recommends. So when practice stops doing that job, you change it and you don't need anyone else's permission to do so. That's the difference between someone just doing Agile and someone who's actually leading in an Agile way. One person just follows the process. The other person understands what the process is for and adapts it when necessary. So, here is my final challenge, and it's deliberately very small. Change one thing about how your team works and see it through to the point where you know whether or not it helped. So one change with one owner and one honest verdict. There are two reasons for that particular shape. First is why one because a single finished change beats ten changes that were never finished. And then finally, why see it through. Because the verdict is the part that actually builds your judgment. Making a change is easy and can sometimes be quite enjoyable, but finding out whether it actually works is the part that makes you better, and it's the part that almost everybody skips or ignores. Now, if you'd like a slightly bigger plan, here's a 90 day plan that would set you up properly. First, in week one, write your playbooks principal page, just a single page. Second, in week two, run one honest retrospective using a format that you haven't tried before. Third, by the end of month one, start your improvement loop and put it in the calendar as a recurring event. Fourth, in month two, run a team health check and act on the lowest score. Then finally, in month three, go back to your playbook and change whatever you got. That's 90 days of small and specific and entirely achievable work, and at the end of it, you'll be leading noticeably differently. That is the end of the course. You came in, able to run a project, but now you're leaving, able to lead a team, and more importantly, able to build a team that keeps getting better without you standing over it every step of the way. That is a real achievement, and you should take a moment to be pleased with it and to give yourself a good old pat on the back. Thank you for your time and your attention and the work you've put in throughout. Now go out there and lead. Good luck. 33. Class Project: Create an Agile Team Leadership Playbook: For your class project, you will create your own Agile Team Leadership Playbook, a practical guide that demonstrates how you would lead, support, and continuously improve an Agile team. Start by defining a project or a team scenario. You can build on a previous project from this core series or you can create a new example that reflects your own work or interests. Then design the key elements of your leadership approach. Create a working agreement that defines how the team will collaborate and communicate, plan a retrospective format that encourages meaningful discussion and continuous improvement. If your project involves multiple teams, outline how they would coordinate and decide whether a scaling framework is appropriate. Next, identify several project risks and explain how your team would reduce uncertainty using Agile practices such as prototypes, spikes or iterative delivery. Finally, create a continuous improvement plan. Include how you'll monitor your team health, gather feedback, and encourage sustainable ways of working while maintaining productivity. When you're finished, you can upload your playbook, your diagrams, or presentation to the project include a short explanation of your leadership approach and why you made those decisions. The goal here isn't to create the perfect, Agile framework, but to demonstrate how you would help a team collaborate effectively, adapt to change, and continuously improve over time. I cannot wait to see your leadership playbooks. 34. Congratulations! What’s Next?: Congratulations on completing the course. You've now progressed beyond learning Agile frameworks and project management techniques to developing one of the most valuable skills in any organization, Agile leadership. One of the biggest lessons in Agile is that there's no perfect process. Every team is different. Every project presents new challenges. And great leaders are constantly observing, adapting, and improving. As you continue your journey, focus on building trust, encouraging collaboration, and creating environments where people can do their best work. The frameworks and the tools are important, but it's the people behind them who ultimately determine a project's success. If you haven't already, make sure to upload your project to the project gallery. I would love to see your Agile team leadership playbooks and the strategies you've developed. And if you've enjoyed this course, please consider leaving a review. Your feedback helps us improve future classes and also helps other learners discover the course, as well. Thank you so much for joining me throughout this journey into Agile project management Happy Leading.