Scrum Foundations for Flow

0:00All right, welcome to skill number one of the PSK course. Professional Scrum with Kanban or Kanban if you prefer. I don't think it matters. In either case, this is a fun course. Let's go. So a workflow board like the one you see on the screen can make a team look organized. Metric can make its work look measurable. Work in progress limits or WIP can make the process look controlled. But none of these things guarantee that the team is learning. A team can visualize chaos without understanding it. I know I can. It can collect numbers without using them. It can even impose limits while continuing to make decisions through assumptions, pressure, or whoever is just yelling the loudest. Professional Scrum with Kanban begins somewhere deeper with the foundations that allow those practices to produce meaningful improvement.

1:01Remember TIA, transparency, inspection, adaptation, aka learning, aka improvement. Scrum gives us the empirical framework for navigating complex work. It creates regular opportunities to make conditions transparent, inspect what's actually happened, and adapt based on what we've learned. Lean thinking, something else that's going to pop up very, very quickly, encourages us to reduce waste, focus on what matters, and improve how value, value moves through the system. And if you aren't familiar with lean thinking, think the waste of waiting, the waste of defects, the waste of transportation, the waste of movement, and there's like four more.

1:51So Kanban builds upon all of that. So Kanban builds upon those foundations. It helps the Scrum team define its workflow, visualize the work, actively manage items within the workflow, and inspect flow through meaningful measures. Remember, if you can't measure it, can you really manage it? And I think not. Now Kanban doesn't replace Scrum and it's not trying to. It doesn't eliminate Sprint, so there's no get out of Sprint free jail cards here. It doesn't introduce new accountabilities and it does not create a separate delivery system. What it does do is help the Scrum team see more clearly inside the system that it already uses. So think Scrum framework and inside of it, Kanban. That's where this course is going to take you. So in this skill, we're going to talk about empirical thinking. We're going to talk about lean principles, Scrum values, and self-management because all of that is needed to make the visibility that Kanban brings useful. We'll also distinguish evidence-based adaptation from changes driven primarily by opinion, urgency, external

3:09controls, think stakeholders. So let's face it, improving flow begins long before we can calculate cycle time. It begins with whether the team is willing and able to see reality, learn from that reality, and change what it does next. I'm super excited because I'm very excitable and I drink a lot of coffee. So get ready, buckle up, here we go.

0:00Let's jump right into Section 1. This section is all about explaining Scrum as the operating framework and Kanban or Kanban. I probably should just pick one and stick with it. But either way, think of it as a complementary strategy for optimizing flow. It's not a replacement, it's not a competing framework, and it's not a collection of isolated tools. Take a quick look at the screen. Scrum remains intact. That means everyone has their accountabilities, product owners, Scrum Master, developers. There are five events. You should know what they are, plus the artifacts, plus the commitments, and then we add the Kanban flow strategy. And what you end up with is this, an observable flow that you can then adjust from.

0:52So let me clean this up, let me hit the talking points, and let's go, Joe. Here it is. So think about the board we just saw. It doesn't create improvement all by itself. Many teams start their Kanban journey by creating columns on a board. To do, in progress, done, testing, goodbye, I hate you, whatever it is. They label them all kinds of things. Probably not I hate you, but I think you understand my point. They move a few cards around and they declare we are now using Kanban. And that board may provide some visibility, but visibility alone doesn't improve anything. Let's say you're standing on your back porch looking at your yard and the grass is two feet tall. Yeah, you can see it, but is it really getting better if you just stand there on the porch? That may be a silly analogy, but I think you understand it. So if the team continues starting too much work or hiding delays or assigning people to separate tasks and responding to every request as urgent, the board simply gives everyone a better view of the same dysfunction. So what? This is an important distinction for this course. Kanban is not defined

2:09by the presence of a board. The board supports a broader strategy for understanding and improving flow. Before the team can use that strategy effectively, it needs a sound foundation for learning and adaptation. And where do we get it? Scrum, because it's the operating framework. So here's what we know about Scrum. It's a lightweight framework designed to help people, teams, and organizations generate value through adaptive solutions to complex problems.

2:41It also supports incremental delivery, lower risk, faster to the customer, more adaptation, far better than predictive in its space, especially for software. It also gives the Scrum team a structure for pursuing goals, creating usable increments, receiving feedback, and adapting as conditions change, as they often do. Scrum defines accountabilities, events, artifacts, commitments. Those elements create enough structure to support focus and learning without prescribing every activity that the team has to do. When Kanban practices are introduced, Scrum doesn't disappear into the background. Sorry, not sorry. That's not what happens. The Scrum team still remains accountable for its work. The sprint continues. Scrum events retain their purposes and their time blocks. The artifacts and their commitments still create transparency and focus.

3:42Scrum encompasses all of that. And Kanban operates inside that framework. So empiricism changes how decisions are made. Scrum is founded on empiricism. Knowledge comes from experience, and decisions are based on what's observed. Doing, learning, learning, doing. PDCA, the dimming cycle. That's basically what we're talking about. And that sounds straightforward, but teams violate it all the time. They assume a delayed item is nearly finished.

4:16Really? They believe more work will increase productivity. They predict delivery based on optimism. They reorganize the workflow because someone disliked what the board appears to show them. Empiricism asks the team to slow down and separate what it knows from what it merely believes. What can be observed? What's actually happened? What evidence supports your conclusion? What can we change? And then what can we inspect after? Kanban gives the Scrum team additional ways to answer those questions, but it's Scrum's empirical foundation that makes the answers matter.

4:54And it's lean thinking. That's what changes what the team optimizes. It's not just a board. It's not just tracking. It's not just columns. There's a lot more to it. Scrum is founded on lean thinking, which reduces waste and focuses attention on what's important. That doesn't simply mean working faster or cutting costs. It means questioning whether the system helps valuable work move towards completion or keeps people occupied without producing meaningful outcomes. Busyness, not producing bidness. I think you know the difference. Partially completed work creates no usable value. Waiting consumes time even when no one is actively working. Task switching divides attention. So don't give me that, oh, I'm a great multitasker. No, you're not. You're just a really rapid unitasker, one at a time. And rework consumes capacity that could have been used someplace else. The team can look very busy and very little work actually finishes. Lean thinking moves attention away from maximizing individual activity and towards improving the movement of

6:11value through the overall system. That shift prepares learners for nearly everything that follows in this course. And Scrum intentionally left room for any of these other practices. Have you ever heard of SAFE? That's Scrum on steroids, at least to me. Instead of one team, we have 20 teams. But the Scrum events don't go away. They are still there. Scrum can tell you what must exist within the framework, but it doesn't prescribe a detailed workflow for every team. It doesn't specify which workflow states must appear on the board. It doesn't establish a universal work in progress limit. It doesn't prescribe how cycle time should be visualized or what service level expectations every team should use. That flexibility is not an accident.

7:04It's intentional. Different products, technologies, risks, and organizational environments create different workflow needs. There is no one size fits all. A prescribed process would quickly become unsuitable for most of them. Kanban helps the Scrum team make those workflow decisions deliberately. It adds practices that reveal how work moves through without changing Scrum's underlying framework. The team is not filling a flaw in Scrum. It's selecting a complementary practice suited to the context of that team, that company, that industry, that product. So Kanban is a strategy for optimizing flow. Within professional Scrum with Kanban, Kanban is understood as a strategy for optimizing flow of value through the process. And that definition is broader than moving cards around a board. The team must understand what constitutes a work item, where the workflow begins and ends, what states it passes through, how much work should be active, and what policies guide the movement. The team then actively manages that work and uses flow measures to inspect what is happening. Later skills will examine each of those practices in great detail. For now, the

8:24essential idea is that Kanban helps the Scrum team turn an otherwise vague workflow into something observable, discussable, and improvable. It makes the movement of work part of the team's empirical evidence. So Kanban complements Scrum. It's not trying to replace it. Adding Kanban doesn't create a hybrid framework in which the team selects whichever Scrum element it feels like. Sprints do not become optional. The daily Scrum does not become a board status meeting. Flow metrics don't replace the Sprint goal. A service level expectation, which we'll talk about, doesn't become a promise that overrides empiricism. The Scrum team continues using Scrum. Kanban enhances transparency into the team's workflow, and this improved that transparency can strengthen conversations during Scrum events, expose threats to the Scrum goal, and that's a really good one, support more realistic forecasting, and provide evidence for improvement during the Sprint retro, sorry, retrospective. That relationship is complementary, not in conflict. So Scrum creates the empirical

9:42learning system. Kanban helps the team see and improve the flow occurring within that system. Because of that, we can change the question. Without a flow perspective, teams ask questions like, is everyone busy? Who owns this particular task? Can we start this request today? And why isn't this person working on something else? Those questions emphasize individual activity and the starting of work. A flow perspective, aka Kanban, changes the conversation. Where is the work waiting?

10:19What is preventing this item from moving? How much have we started compared to what we've finished? What does our evidence suggest will happen next? And what change might improve the entire system? This is the mindset shift that begins with professional Scrum with Kanban. We're not adding practices merely to manage more work. We're creating enough transparency to understand how work actually flows and enough empirical discipline to improve it. With that said, I'll be right back for the next section, so hang on.

0:00All right, all right, all right. I hope Matthew McConaughey doesn't sue me for that, but I figured I would try it. Okay, welcome to section two. Let's talk about the empirical flow loop, and you can see it on the screen. Let me grab Mr. Penn. Let's try blue. Earlier, I talked about TIA, Transparency Inspection Adaptation, the three pillars of Scrum. Notice that right here in the middle, we have what could be Kanban, sitting clearly in the middle of TIA, Transparency Inspection Adaptation.

0:36Fantastic. I'm going to explain it more, but I really love this graphic. Well, I created it, so I hope I love it. Anyway, enough of that nonsense. Let's keep going. So empiricism requires something observable. Transparency, we can observe it. Well, if we can't observe it, how can we inspect it? And the answer is, we can't. So empiricism depends on observation. If the team can't see what's happening, it can't make decisions based on what it sees, and that sounds obvious, but there's a ton of knowledge work that remains hidden.

1:16A work item might appear active, even though no one has touched it for several days. It's aging. A developer might be waiting for a clarification. Testing might be overwhelmed while new work continues entering the system at the front end. And several items may be described as almost finished without meeting the DOD, the definition of done. And when these conditions remain invisible, the team just fills in the gaps with assumptions. Well, what are assumptions, Bob?

1:47Well, assumptions are beliefs we hold to be true or false in the absence of proof. We don't have evidence. So making work observable gives the scrum team a shared reality from which learning can start. It doesn't solve the problem all by itself, but it does allow the real problem to be seen. So transparency is more than visibility. Transparency is sometimes reduced to putting information where everyone can see it.

2:18Okay, I can see it, but I don't know what it means. But information can be visible without being understandable. A board containing dozens of outdated work items is visible. A report filled with unexplained measures is in fact visible. A work item placed in a column called in progress may be visible and it won't tell you anything about the actual condition of that item. Meaningful transparency requires a shared understanding of what the information represents, what it means, not what you think it means, because what you think it means is an assumption.

2:58For example, when does work enter the workflow? What does each workflow state mean? What conditions must be satisfied before an item can move from one state to the next? And what does it mean for the work to be finished? If team members interpret the same information differently, the appearance of transparency is very misleading. So transparency must reveal uncomfortable conditions. It's valuable when it tells you something that someone else would rather not be seen.

3:29Yeah, I think I said that right. Maybe too much work has been started. Maybe an item has been blocked far longer than anyone realized. Maybe the team repeatedly misses its forecast because of it. And maybe a specialist has become a bottleneck. These conditions aren't failures of transparency. Revealing them is the purpose of transparency. Scrum's values become very important here. Openness and courage help the team expose problems without disguising them.

4:01Respect helps people examine the system without immediately blaming one another. But I do like to blame others, but only for fun. If information is cleaned up to avoid difficult conversations, the team may feel more comfortable, but the decisions will be based on an edited version of reality. And then we have inspection, which is a purposeful examination. Notice I didn't say cursory. It means something different.

4:31Once conditions are transparent, the Scrum team can inspect them. Inspection is not just looking at the board. It's not attending an event. It's not just reading a report. It's a purposeful examination of evidence to understand progress, emerging conditions, risks, possible problems, whatever it is. A team might inspect progress towards a sprint goal or the conditions of an increment or changes to the backlog or the patterns within the workflow.

5:03But the important question isn't, what do we see? The important question is, what does this evidence suggest about our ability to achieve the goal and deliver value? We can never forget value. Inspection turns visible information into learning. And without that thinking, transparency becomes passive reporting. And Scrum creates a cadence for inspection. Scrum's events create tons of opportunities to inspect and adapt. Sprint planning establishes why the sprint is valuable and what the team intends to accomplish.

5:38The daily Scrum allows developers to inspect progress towards the sprint goal and adapt. The sprint review examines the outcome of the sprint, aka the increment, and changes the environment based on what comes out of it. The sprint retrospective inspects how the Scrum team worked and identifies useful improvement opportunities. Now, these aren't the only moments where inspection can occur. A team shouldn't wait for a scheduled event when a serious condition becomes visible.

6:10That's why we have self-management. And yes, I'm going to keep using air quotes whenever I feel like it. So the events create a dependable cadence, bringing order to the chaos. While Kanban practices provide additional workflow evidence that can make those conversations more informed and more specific. Because adaptation changes what we do next. Inspection has almost no value if nothing changes after it.

6:40Adaptation means adjusting the product or the plan or the workflow or the behavior in response to what we've learned. It should occur as soon as the team determines that remaining on the current path would produce an unacceptable result. And the adaptation doesn't need to be dramatic. It doesn't need to be grand, but it does need to happen. The team might collaborate on something that's aging or stop starting new work or clarify workflow policy or remove a source of delay or change the plan to reach the sprint goal.

7:16The size of the change matters less than the connection to the evidence. The evidence should tell you what the size of the change probably should be. Small evidence, small change. Large evidence, I think you get the rest. Empirical adaptation is not random experimentation. It's a reasoned response to something that the team has observed and inspected. And now we are adapting. And then measures support inspection, but they don't perform it.

7:50Kanban will give the scrum team several flow measures, work in progress or WIP, cycle time, work item age, throughput. Those measures strengthen transparency, but they don't turn around and start making decisions for the team. A rising cycle time doesn't automatically identify the cause. A lower throughput doesn't prove that people were less effective when they worked. An aging item doesn't tell the team which intervention is most appropriate. Measures provide evidence that deserve inspection.

8:23The scrum team still has to interpret that evidence within the context of the product, the goals, the workflow, the current circumstances. The numbers begin the conversation, they don't end it. Using metrics without context merely replaces one form of opinion with another. And finally, the loop remains connected. Transparency, inspection and adaption should be understood as one continuous learning loop. Remember the Deming cycle, plan, do, check, act it?

8:56I know what I said. But they're almost the same thing. Transparency without inspection creates information that no one cares about. Inspection without adaptation produces discussion without improvement. Adaptation without transparency becomes change driven by instinct, hierarchy, frustration or pressure. Each part strengthens the others. When the team adapts its workflow, the results of that change become new evidence. The team makes those results transparent, inspect whether the change helped and adapts again whenever it's appropriate.

9:34And this is how empirical process control supports continuous improvement. Kanban's not trying to replace that loop. What it's trying to do is help the scrum team see more of what's happening inside of it.

0:00All right, I'm going to stay off screen for just a minute because there's a lot going on in this graphic and I don't want my mug sitting on any of it. So this section is all about the focus on value, the essentials and waste reduction. Hopefully by the end of it, you'll recognize how unfinished work or queues and excessive activity interferes with flow. And you can see it between the busy system and the flow system. We've got a bunch of stuff ready and a bunch of stuff active.

0:31Man, we must be killing it. And then we have a bunch of stuff ready for testing and review. But wait a minute, why did we only finish one thing? Well, because the busy system is not the same thing as the flow system. Notice we have fewer items ready, fewer items active, which means fewer items in review. And eventually what you'll find is that you'll get more done. No, it's not an accident.

1:01No, it's not a risk. So let's wander over here, come back on the screen and talk about it. So all of that activity can look like progress. Organizations quite often interpret busyness as evidence of productivity. We're all busy. If every person has an assignment and every specialist has a queue and new work begins as soon as capacity appears, the system may look great. No one is waiting and everyone appears fully utilized.

1:32But activity and progress aren't the same thing. A team might start 10 items and finish none. People can spend a whole day switching between tasks, attending handoffs, resolving dependencies and reporting status without producing a single usable increment. Lame thinking challenges the assumption that maximizing individual activity will also maximize value. The better question is not, how do we keep everyone busy? The better question is, how do we help valuable work reach completion?

2:06So value must move through a system. And yeah, I'm kind of tired of the air quotes too. So I think I'll back off a little bit. Work doesn't become valuable simply because someone begins doing it. An idea must move through a sequence of activities before it produces a usable outcome. Depending on the product, that might include discovery, design, development, review, testing, integration, deployment, other work, whatever it is. Excuse me.

2:37And together, those activities form a workflow. Flow describes how effectively work moves through that system from a defined starting point to a defined finishing point. If the team doesn't understand where the workflow begins and ends, it'll struggle to measure or improve that flow. Different people might count different portions of the work and reach very different conclusions about the performance. Defining the workflow will become one of Kanban's essential practices.

3:07And let's face it, unfinished work is just inventory. In physical production, unfinished materials accumulate as inventory. Knowledge work creates inventory too, but it's easier to overlook because it may exist only as cards or files or code or documents or unresolved decisions. Every stated but finished item consumes some portion of the system's attention. It may need to be tracked, updated, discussed, reviewed, protected from change, or understood again when someone comes back to it.

3:43It may also age while waiting. The more unfinished work the team carries, the more complicated the environment becomes. And that doesn't mean all work must be completed one item at a time. It means unfinished work has a cost, even when that cost is difficult to see. Excessive WIP or work in progress just divides attention. So WIP or work in progress represents work that started but not yet finished within the workflow.

4:17As WIP increases, attention becomes divided across more items. People switch context, questions remain unanswered. Blocked work competes with new work. Team members spend more time remembering where they left off and coordinating across partially completed efforts. This can produce a strange outcome. More work is active, but each individual item takes longer to finish. Limiting WIP is not about preventing people from working.

4:47It's about directing available capacity towards completing valuable work, rather than continuously expanding the inventory of unfinished work. We're going to talk about that practice much more throughout this course. So waiting is part of the work's experience because there is always waiting somewhere. Teams frequently measure the times people actively spend working on an item while overlooking the time that the item spent waiting. From the customer's perspective, both count.

5:18An item might wait for clarification or approval or testing, review, deployment or availability of a specialist. No one may be doing anything wrong, but the work is still aging inside of your system. This waiting is often invisible because each person sees only a portion of the workflow. One group finishes the activity and considers the work handed off to someone else. It's not my problem anymore. Another group might see it as one more item in a growing queue, think testing.

5:51Visualizing the entire workflow helps the team see the work's experience, not merely each person or each state's activity. And local efficiency can damage the whole. One specialist or department might appear highly efficient while making the overall system slow. Think about one person getting their work done and just dumping it into the queue. Is that really helping the whole? I don't think so. If one part of the workflow is producing work faster than the next part can handle it, the first group looks productive because it's got a bunch of stuff done.

6:28But downstream, the queue grows, work waits, it ages and feedback arrives later than it should have. Optimizing one portion of the system has damaged the whole. Lean thinking encourages the scrum team to look across the entire workflow. The goal is not to maximize the output of every single stage. The goal is to improve how effectively value moves through all of it. Collaboration may occasionally leave one person less busy while helping the system finish more valuable work.

7:01And finishing creates value and then learning. Starting work usually creates possibilities, but finishing work creates outcomes that can be inspected. A done increment can be evaluated by stakeholders, used by the customers and released when appropriate. And compared to the assumptions that led to the creation in the first place, it produces what evidence. Unfinished work can not provide the same learning. This connects lean thinking directly with empiricism.

7:34When work finishes sooner, feedback arrives sooner. When feedback arrives sooner, the scrum team can adapt before investing heavily in the wrong direction. Flow is not merely an efficiency concern. It affects how quickly the organization can learn whether it's creating something valuable. Better flow shortens the distance between an idea and the evidence that produced it. And finally, lean thinking leads towards Kanban. Lean thinking directs attention towards value, essentials, waste, unfinished work, and the performance of the overall system.

8:11And Kanban gives the scrum team practical ways to act on that thinking. The team defines and visualizes the workflow. It controls how much work is active. It manages work items based on their current conditions. It looks at measures that reveal how work has been flowing. And these practices make lean concerns real. Instead of vaguely agreeing that the team should reduce waste or finish more work, the team members can examine where the work is accumulating or building up, how long it remains active or ages, and what's preventing it from moving.

8:48Lean thinking gives us perspective. Kanban gives us practices for applying that perspective within scrum.

0:00All right. Welcome to section four. It's time to get on the slide, Clyde. And this one is all about the Scrum Values. You can see them on the screen. Let me grab Mr. Penn just to make sure we're on the same page. We have commitment. We have focus. We have openness, respect, and courage. And the interesting thing here is value makes a flow improvement possible. The Scrum Values. Let's see what we're talking about here. So, let me clear that. Let me grab Mr. Penn, move him over there. Let's go over here to the talking points. So, values must become behavior. The Scrum Values are something presented as admirable words the team should remember. Commitment, focus, openness, respect, courage. See? I remember them. But values displayed on the wall don't affect flow. The value becomes meaningful through the choices people make when work becomes tough. Do they expose a delay or quietly hide it? Do they help finish an aging item or start something new? Maybe it's interesting. Do they examine the workflow or blame the person nearest the problem? She did it. Again, I'm not down with the blame game, especially if I'm the one being blamed. Kanban can reveal

1:20uncomfortable conditions, but it can't guarantee a productive response. This is where the Scrum Values come in. They help create an environment which greater transparency leads to learning instead of defensiveness, punishment, manipulation, or just all-out chaos and war. Healthy flow depends as much upon team behavior as it does upon the workflow design. So, let's talk about commitment. We are committed to protecting a shared goal. Commitment doesn't mean promising to complete every work item placed in front of the team. It means committing to the Scrum team's goals and supporting one another. Let's imagine an important item supporting the sprint goal just stops moving. Other team members are busy with their own work, and several new items are ready to jump in. A team focused on personal completion might allow that item to keep aging. Everyone is occupied, but the sprint goal is now threatened. Commitment changes that response. The shared goal becomes more important than maintaining individual activities. Team members reconsider priorities, they offer assistance, and they organize around what the team is trying to accomplish together.

2:37And then we have focus. Well, it reduces competing attention. Go back to my previous line, I'm a great multitasker. No, you're not. You can multitask only when using different parts of the brain. So, focus directs the Scrum team's attention towards the most important work, the work needed to make progress. Without focus, everything might be urgent. Team members begin additional work whenever they encounter difficulty or delay. They simply move on.

3:09Work spreads across the whole system, and important items compete with everything else for attention. So Kanban practices will eventually help the team establish explicit limits and policies, but those mechanisms require people to honor them. Focus supports the discipline of finishing rather than casually starting more. When an aging item threatens the sprint goal, the team asks what deserves its attention now. It doesn't automatically add the problem to everyone else's existing workload. Focus means creating deliberate choices about where limited capacity will create the greatest benefit. And openness, our next value, reveals the true condition.

3:55Think transparent. Flow can't be improved when people conceal the condition of the work. A team member might avoid identifying an item as blocked because that delay feels embarrassing. A team might leave a card in an active state because moving it backwards looks like a failure. A stakeholder might be given a confident forecast even though the evidence no longer supports it. Openness means being honest, transparent about the work, about the challenges, and the team's current ability to achieve its goals. That honesty improves transparency. And I don't know why I'm doing all this, but I'm having a good time with it. A team can show that an item is waiting, acknowledge the uncertainty, discuss an unexpected dependency, or admit that the original plan is no longer realistic. Openness does not eliminate difficult conditions. What it does do is give the Scrum team an opportunity to respond before those conditions get worse. And then respect changes how problems are examined. When a workflow problem becomes visible, teams can examine the system or search for someone to blame. Respect recognizes that team members are capable

5:13professionals doing the best they can within the conditions surrounding them, within the system they are working in. It encourages curiosity before judgment. Instead of asking why a tester is slowing everything down, the team might be asking why testing receives work in such large batches. Instead of criticizing a developer over an aging item, it might examine unclear requirements, excessive dependencies, or competing responsibilities. Respect does not prevent accountability, but it does improve the quality of the investigation. People are more likely to reveal problems when they believe the team will respond constructively. Have you ever heard someone say, can I offer you some constructive criticism? Uh, no, you can't. Because criticism by its very nature is destructive, not constructive. If you're using that, stop. And that psychological safety supports better transparency, more accurate evidence, and earlier intervention. And then we have courage. Courage converts awareness into action. Teams very often recognize workflow

6:28problems long before they deal with them. They may know that too much work is active. They might know that an approval step adds little to no value, or that urgent requests repeatedly disrupt the sprint. Changing those conditions may require an uncomfortable conversation with someone or many someones. Courage enables the scrum team to confront difficult problems and do the right thing. The team can actually stop starting new work despite stakeholder pressure. It might challenge a policy that's causing a delay. It may expose an unrealistic expectation or acknowledge that its existing approach simply isn't working. Kanban can make a problem difficult to ignore. Courage determines whether the team acts upon what's now visible. Evidence becomes useful only when people are willing to follow wherever it leads, and the values reinforce one another. The five scrum values are not independent. Openness without respect may feel unsafe. The team is asked to reveal problems and expect criticism when it does. So why would they? Focus without commitment may become personal tunnel vision. Individuals concentrate on their own work and the shared goal suffers. Commitment

7:49without courage might produce unrealistic promises. People agree to expectations they know the team can't possibly meet. When the values reinforce one another, the team can expose difficult conditions. They can look at them honestly, and they can organize around an appropriate response. This becomes very important when Kanban practices increase transparency. Seeing more of the system provides greater opportunity for improvement, but there's also greater opportunity for blame if the scrum values are weak. And finally, the workflow behavior reveals the values. A team doesn't need a value survey to begin understanding whether the scrum values are actually present. Their workflow behavior becomes the evidence. Does the team start new work while ignoring important items that are blocked? Does it disguise or mask delays? Are WIP limits ignored whenever pressure increases from stakeholders? Do people protect their individual assignments instead of collaborating towards the sprint goal? Every one of those behaviors tells a story. The purpose is not to grade the team's character. It's to recognize that workflow problems may have behavioral and cultural causes, not merely

9:10mechanical causes. Scrum values support the trust required to make work transparent and the discipline required to improve it. Kanban can show the team where flow is struggling. The values help determine what happens after the team sees it.

0:00Welcome to section five. We are still alive. Let's go. This section is all about self-management guided by evidence. You can see it right here on the screen. These are the what's. Let me just go ahead and put that right there. The what. Clear boundaries with the product goal, the sprint goal, the DOD, the scrum accountabilities and the real constraints. But once you start, we move over to the how. And that's where self-management comes from.

0:32It's far better than external assignments, just making sure everyone is busy. Why does it really matter though? Because if the team is self-managing, they can move important work, not just the work they're being told to do. And then they have better observable evidence. Go back to TIA. Transparency, inspection, adaption. There's a reason they are self-managing. Well, let's take a look at some of those other reasons.

1:02Let me move over here. Here we go. So self-management, well, that's team level authority. A self-managing team decides who does what, when and how internally. Now that doesn't mean everyone acts independently or works independently or selects whatever assignment is most interesting. Self-management is at the team level, not the individual level. The team organizes around a shared goal. They look at the whole body of work and they coordinate the contributions needed to create a valuable, usable increment.

1:36So this authority allows decisions to be made close to the work. Why wouldn't it? And where the greatest amount of current information exists, which is where the work is being done. When workflow conditions change, the scrum team doesn't need to wait for an external manager to redesign every assignment. Why would they want to? It can see what's happening, adapt the plan and determine how members should collaborate going forward. Self-management enables faster empirical response, but self-management has boundaries.

2:10It doesn't mean operating without goals or rules or accountability. The product owner is still accountable for maximizing product value. He or she has to manage the backlog, the product backlog, just in case you're checking. Developers are accountable for creating a usable increment. They're accountable for the sprint goal. The scrum master is accountable for establishing scrum based on the scrum guide and supporting the team's effectiveness, removing impediments.

2:41I know you've read that stuff because I have too. The product goal, the sprint goal, the DOD, the definition of done, they provide important direction and boundaries. But then we have organizational policies, legal requirements, security obligations, technical constraints. All of those shape the team's environment as well. The scrum team manages itself within those conditions. Autonomy is not the absence of boundaries. It's meaningful authority within those boundaries.

3:14So the team organizes around the work. Traditional management, think predictive, begins by assigning work to individuals. Everyone gets a task, everyone reports progress, and they remain responsible for moving that assignment forward. When work is blocked, the individual might wait, escalate, or start something else. A self-managing team begins with the shared work, and they ask how the members can organize it to move towards completion. One person might take the lead and others contribute.

3:47Team members might swarm around an important problem or redistribute activities or temporarily work outside of their usual specialty. It really does depend, but they do it collectively. The objective is not to prevent perfect individual ownership. It's to achieve the team's goal and create a done increment. Flow makes this distinction visible when the work item, not the utilization of the individual, becomes the central concern.

4:19And then we have pull, which supports self-management. In a pull system, and I'll be very clear, new work begins when the system has the capacity to handle it, not just because more work is available or someone says it needs to start. And this reinforces self-management. The Scrum team can look at the current work. They can look at the workflow policies, the goals, and the available capacity before they pull another item into progress.

4:50Team members coordinate around what the system needs rather than accepting an endless stream of externally assigned work. Now, pull doesn't mean ignoring the product backlog ordering or allowing everyone to choose favorite items. It means making responsible decisions about when work should enter each part of the workflow. And that decision becomes especially important when starting something new would delay work that's already active. So we're going to talk about pull and whip as we move further through these skills, excuse me.

5:25And then evidence makes autonomy responsible. Self-management doesn't produce decisions based solely on preference. A team might feel it needs more people, that testing is a bottleneck, or that urgent requests are the real source of delays. And those conclusions might be correct, but they should be compared against observable evidence. What does the workflow show? Where does the work actually wait? Which items are aging? How often does work finish?

5:57Are some conditions recurring or is the team just reacting to an unusual event? Evidence gives the Scrum team a stronger basis for exercising its authority. The team is not asking other stakeholders to trust an unsupported opinion. It can explain what it saw, how it interpreted that situation, and why a particular adaptation appears appropriate. But opinion can disguise itself sometimes as experience. Experienced people develop strong instincts.

6:28Those instincts can help the team notice possible problems, but experience doesn't make every conclusion correct. Statements like, well, testing always slows us down, or we need to start this immediately, or maybe adding one more person will solve this problem. They may sound good, but aren't they really untested assumptions? An empirical team treats those statements as hypotheses worth inspecting. What evidence supports that claim?

7:00What evidence can challenge it? What's the smallest responsible change that we can make? How has it determined whether that change even helped? Experience can guide where the team looks, but evidence should influence what it does next. This keeps self-management from becoming opinion-driven management. And then we have external directions, which can weaken the flow. External intervention often begins with good intentions. A manager who sees someone available and just gives them something to do.

7:34A team member to begin an urgent request. A specialist is moved to a different initiative because another department needs help. Each individual decision might seem reasonable, but collectively, they can increase WIP, work in progress. They disrupt focus. They hide the team's true capacity, and sometimes they threaten the sprint goal. The problem is not that people outside of the scrum team have no legitimate needs or useful information, because they do. The problem occurs when those needs bypass the team's shared decision-making and workflow.

8:10Healthy self-management allows new information to enter the conversation without automatically converting every request into active work. And finally, self-management turns evidence into adaptation. Kanban will make the workflow evidence available to the entire scrum team. The team may discover that work consistently ages in one state, or that WIP exceeds capacity, or an unexpected completion date is no longer realistic.

8:40Self-management allows the team to respond. It could stop pulling new work. It might collaborate or swarm on an aging item. It might need to clarify a policy, negotiate a change in scope, or adapt the plan towards the sprint goal. The team can select the response that fits the current context, rather than waiting for someone outside the work to give them one. It's faster. And this is where the foundation comes together. Transparency reveals the condition.

9:13Inspection creates understanding. Scrum values support an honest response. And self-management enables adaptation. The remaining question is, can team members apply that thinking when a realistic delivery problem doesn't provide an obvious answer? I guess we'll find out in the final section.

0:00So in this final section, let's run a scenario. Let's see what happens. So we have scrum teams with a company called PulsePoint Medical. Now, PulsePoint Medical is fictitious. I made it up in my head, but I really like it because they are a medical device company specializing in wearable devices for cardiac patients. That's enough for now. I talked about it a bunch in previous skills, and I'm probably going to talk about it some more. With that said, one of their teams, the Orion team, not the Onion team, although I may say that, is on day six of a 10-day sprint. Now, they selected 11 items to pull in from the backlog, and you can see them. There's one, there's two, there's three, four, there's another one. All of that together is 11. You can see what's what. One is still in selected, waiting. Two in development, three in review, four in testing, and one of them is a sprint goal item, and it's aged three days. Well, of those 11 items, only one of them has finished. Hmm. I wonder what that means. Well, if you walked by that board, you might think, well, it looks like testing has a problem. They need more help, or all of the other

1:19developers need to get on that one item so we can get this done. But is that really what we should do? I don't think so. What we should probably do is observe before diagnosing, because everything I said a moment ago was without observation and understanding. Yeah, you can see it, but do you understand what it means? I don't think so. So, what do we actually see? We see 10 items started, and one is done. That's a fact. We can see it. If they have it done right on the board, it's legit. We can see that work is accumulating here, or it appears to be. We can also see that one of these items is pretty important. It's a sprint goal item waiting for three days.

2:07Now, we don't know why the work is waiting. These are just observation. We don't know whether this happens in every sprint. We don't know if testing doesn't have capacity, or whether items entering testing are full of defects. We have no idea. But the workflow creates conditions worthy of inspection, but it won't tell you the cause. It's not supposed to. So, what should we do? Separate evidence from assumption. Several assumptions sound reasonable. Testers are working too slow. The team needs another tester. Development is producing work too quickly.

2:44The items going into testing have quality problems. They are junk. Or maybe the workflow is improperly designed. Maybe it's just poorly designed. I don't know. And maybe the team selected too much work. Any one of them might eventually be proven correct, but none of them have been established by the current evidence. Even saying testing is a bottleneck deserves care. Yeah, the board shows work accumulating there, but that's a single snapshot. The empirical response preserves the distinction between what the team sees and what it believes might be happening.

3:21Assumptions can guide investigation, but they shouldn't masquerade as conclusions. So, let's inspect what matters most. The sprint goal deserves focus because it's been waiting for three days, and that makes the item more important than keeping every person occupied or beginning all 11 items. The team needs to inspect that condition. What's preventing it from moving? I don't know, but I bet we can figure it out if we ask. Is the item actively being tested, or is it just waiting? Does it need clarification, correction, additional skills? Can other people jump in and help? What other work is competing for that capacity? The goal is to help the team understand where inspection should begin, and then we need to evaluate responses.

4:12Maybe we can start all of the work to make sure everyone is fully utilized. Okay. Or maybe we should get an external manager to tell us what we should be doing. I'm thinking no on that one. Maybe we should hire or transfer another tester in because more people means more work, right? No, it doesn't. Or we have the scrum team collectively inspect the aging sprint goal item, stop additional new work, and determine how members can help move that work towards done. So that last one is obviously the best response. The team is just not going to introduce new work, and they're going to take a look at that item. The testers explain to them, hey, several acceptance conditions are unclear, and that defects discovered during testing required repeated handoffs. So the team collectively decides that one developer will collaborate directly with the tester, while another clarifies the acceptance conditions with the product owner. So now we have three people at a minimum looking at that one item.

5:21Other team members examine the items waiting for review before they do anything new. This is not a permanent solution or a declaration that the workflow has been fixed. It's a timely adaptation based on the best evidence currently available, not assumptions. The team is using focus, openness, respect, courage, and commitment while exercising self-management around a shared goal. And then we simply inspect the results from that adaptation. An empirical response means we have a way to learn something after we do whatever we do. The team should observe whether collaboration helped that sprint goal move, and whether that the testing queue decreases, or whether similar clarification and defect problems show up in other items. If an item reaches done, but the same conditions come back, the team might be dealing with a broader workflow issue. It may be outside of the team.

6:22It may need to inspect how the work is prepared, developed, reviewed, or handed into testing. And the team shouldn't declare victory because they get that one item over the line into done. The adaptation created new evidence, and that evidence must become transparent and be inspected before the team decides what to change next. And what's happening? The empirical loop continues. Transparency, inspection, and adaption. Plan, do, check, act. So that response wasn't picked because it guaranteed success. It was picked because it responded to observable conditions. It was picked because it protected focus of the sprint goal. It was picked because it avoided increasing unfinished work. It preserved self-management. It used the scrum values to support collaboration, and it created a learning opportunity. So this scenario is just to reveal the team's current information.

7:25The board shows you where the work is located, but it doesn't provide explicit workflow policies, a whip limit, historical cycle time information, throughput trends, or a service level expectation. Now those elements will give the team stronger evidence and more deliberate ways to manage flow. But for now, the foundational lesson is very straightforward. Do not rush from visibility to certainty. Observe the condition, inspect what it means, make a responsible adaptation, and learn from what happens next.