Skip to content

Bottlenecks Explained Why Faster Coding Is Not Enough Software Engineering Full Course Lecture 4

Jump to bottom
FurkanGozukara edited this page Oct 17, 2026 · 1 revision

Bottlenecks Explained: Why Faster Coding Is Not Enough | Software Engineering Full Course, Lecture 4

Full tutorial link > https://www.youtube.com/watch?v=SQ6TDGisaC0

Bottlenecks Explained: Why Faster Coding Is Not Enough | Software Engineering Full Course, Lecture 4

image Hits Patreon BuyMeACoffee Furkan Gözükara Medium Codio Furkan Gözükara Medium

YouTube Channel Furkan Gözükara LinkedIn Udemy Twitter Follow Furkan Gözükara

This is the fourth lecture of the Software Engineering course. A small team builds Campus Rooms, a fictional room-booking service, with eight work cards on one board: after four rounds every station has been busy, yet only three cards are done and five wait for review. Eight interactive scenes answer one question: where is work waiting, and what would actually improve the flow?

Links:

SECourses Patreon: [ https://www.patreon.com/SECourses ]

SECourses Discord: [ https://discord.com/servers/software-engineering-courses-secourses-772774097734074388 ]

You will learn why finished parts can still be one late discovery, how to find a bottleneck from queues instead of from how busy people look, why a work-in-progress limit shortens cycle time while lead time stays the same, why a range with its assumptions beats a single number, which next step reduces the most uncertainty, what separates coded from ready to rely on, and how to test a process change like a hypothesis.

Main topics include feedback batches and slices, increments and iterations, plan-driven work, Scrum and Kanban, bottlenecks, work in progress, throughput, work item age, cycle time and lead time, estimates and ranges, risk, reversibility, cost of delay, the Definition of Done, blameless retrospectives and sources.

Use the chapters to jump to any scene, the measures, the principles or the sources.

Chapters:

00:00:00 Everyone is busy: why are only three cards done?

00:00:56 Is everyone busy? Every station worked, three cards done

00:01:14 The question of this week: where is work waiting?

00:01:39 Five cards wait for review, and four questions follow

00:02:44 From week 3's models to the eight work cards

00:03:44 How the board works, and what you will learn

00:04:42 Feedback batches: when would the team learn it was wrong?

00:05:55 One large batch: the misunderstanding shows in round 9

00:06:51 Small usable slices: the same misunderstanding found in round 3

00:07:47 Increment versus iteration, and the principle of early feedback

00:08:30 Later feedback points: more finished work to reconsider

00:10:17 Small slices still need an agreed identity interface

00:12:01 Plan-driven, Scrum and Kanban: what does each make visible?

00:12:55 How each approach coordinates and what it shows

00:14:00 When feedback arrives, and what stays open to change

00:14:56 Where each approach is strongest, and why meetings alone fail

00:15:50 Incidents at unknown times: every approach needs new policies

00:17:30 Stepping the board: where does the next card wait?

00:18:32 Rounds 1 to 4: the review queue grows to five

00:19:55 Rounds 5 to 9: review sets the board's pace

00:20:49 Doubling implementation: the Run button and the same finish

00:21:48 Why doubling implementation did not double completion

00:22:26 Doubling review instead: done in round 5, the limit moves

00:24:07 Which clock does the person who asked experience?

00:25:06 Asked, started, finished: lead time and cycle time

00:26:07 Waiting in Ready: inside lead time, outside cycle time

00:26:27 A work-in-progress limit of 2 with the same demand

00:27:29 Work item age and a shorter cycle time

00:28:09 Lead time unchanged: the waiting moved outside the boundary

00:28:44 "Three days": effort, elapsed time or a promise?

00:29:52 Behind the number: known work, dependencies, open questions

00:30:26 Five similar changes: a range instead of one number

00:31:11 The cost after the estimate: waiting and continuing support

00:31:42 Identity interface not agreed: widen or qualify the estimate

00:33:32 Which next step reduces uncertainty? A decision table

00:34:26 Judging three candidates on five criteria, row by row

00:35:40 Investigate, implement, reduce scope or defer, and opportunity cost

00:36:25 A hard-to-reverse identity choice changes the order

00:37:49 The smallest estimate can be the most expensive choice

00:38:39 The code runs: is the cancellation change done?

00:40:00 A completion policy with five kinds of evidence

00:40:59 Acceptance examples versus the Definition of Done

00:41:19 An internal wording fix: the same policy, relevant evidence

00:42:55 The review queue keeps growing: a blameless system view

00:44:20 A process change stated and tested like a hypothesis

00:45:16 Faster but shallower review: flow and quality together

00:46:55 Five measures of one board and their boundaries

00:48:28 Eight principles of development flow and decisions

00:49:30 Six checks with answers, including a library team

00:51:16 What carries forward to week 5, and the sources

This lecture is for students of the Software Engineering course and for anyone whose team is busy all day and still waits for results. Every name, number and round is a teaching example from the fictional Campus Rooms service.

Background music in the silences: Infinity, Serene View, Romantic 05, Relaxation 04, Digital Clouds, Your Breath, Stylz, Down the River, Vastness, Opalescent, Curiosity, Pilates and Yoga (Mixkit, Stock Music Free License).

For questions, updates and the rest of the course, check the links in this description, the pinned comment, Patreon, Discord and the comments below. Thank you for watching.

Video Transcription

  • 00:00:00 Greetings everyone. This is week 4 of the Software  Engineering course, and today I am going to show  

  • 00:00:06 you why a busy team can still finish only 3 cards.  Here is the situation. A small team is improving  

  • 00:00:13 Campus Rooms, our fictional booking service. 8  work cards, 1 board, and 4 rounds of work so far.  

  • 00:00:20 The board has 5 columns. Ready holds the cards  nobody has started, and it is empty. Implementing  

  • 00:00:26 takes 2 cards per round, and this round it worked  on W07 and W08. Then comes Waiting for review,  

  • 00:00:35 with 5 cards. The Review step finishes 1 card per  round, and this round it finished W03. Done holds  

  • 00:00:43 3 cards. Now room staff ask a question: when  will W05, accessible feedback, be ready? W05  

  • 00:00:52 is right here, in the waiting column, with a blue  ring around it. Before answering, a very common  

  • 00:00:57 first question is whether everybody is working  hard. I click Is everyone busy, and the answer  

  • 00:01:02 appears below the board. Implementation took 2  cards in every round, and review took 1 card in  

  • 00:01:08 every round it could. So yes, everyone is busy.  And still only 3 of 8 cards are done. That is the  

  • 00:01:15 question of this week, in the middle card: where  is work waiting, and what would actually improve  

  • 00:01:21 the flow? The card offers 3 answers. Option A,  speed up implementation, because it looks busiest.  

  • 00:01:29 Option B, find where cards wait and improve that  step. Option C, start more cards so nobody is  

  • 00:01:36 idle. Pause and pick one. Keep your answer,  because scene 3 tests it on exactly this board.  

  • 00:01:43 Now I click Where is the work waiting, and the  review column lights up. 5 cards wait for review,  

  • 00:01:50 and W05 is one of them. Its developer finished  it, and nobody can use it yet. The waiting, not  

  • 00:01:56 the working, decides when people get it. On the  right are 4 questions this lecture answers. First,  

  • 00:02:02 when does the team learn it built the wrong thing?  Scenes 1 and 2 answer that one, about feedback.  

  • 00:02:09 Second, where is the work waiting, and for how  long? That is scenes 3 and 4, about flow. Third,  

  • 00:02:16 what does three days promise, and what should  come first? Scenes 5 and 6. And fourth, when is  

  • 00:02:22 a change done, and did a change to the process  itself help? Scenes 7 and 8. So this lecture  

  • 00:02:28 builds 1 board, and the decisions around it. Check  out the tutorial description to see the chapters,  

  • 00:02:34 so you can jump to any scene. To move between  pages I use the arrow buttons at the top right,  

  • 00:02:40 and I click the next page button now. Before the  first scene, let me connect this to week 3. Week  

  • 00:02:47 3 drew 5 models of 1 booking, B-001: a journey, 2  state models, a data model, a decision table and  

  • 00:02:54 sequence diagrams. And week 3 ended on a question:  who turns these models into working behavior,  

  • 00:03:01 in what order, and where does that work wait? This  lecture starts with the last part. The example  

  • 00:03:08 this week is 8 work cards. W01, the conflict rule.  W02, the duration boundary. W03, cancellation  

  • 00:03:17 ownership. And W04, room closure. W05, accessible  feedback. W06, notification recovery. W07,  

  • 00:03:26 search response time. And W08, support diagnosis.  Each card is 1 piece of work on Campus Rooms.  

  • 00:03:33 Room closure is still an open need, as in weeks  1 and 2, and it gets its answer only in week 14.  

  • 00:03:40 Here it is simply 1 card among 8. How the board  works: time moves in rounds. Implementation takes  

  • 00:03:47 2 cards per round, and review takes 1. A card  implemented in a round joins the review queue  

  • 00:03:54 for the following round. Every card is the  same size, and all 8 are requested at round 0.  

  • 00:04:00 Rounds are teaching units, not measured developer  performance, so the board is a model you can  

  • 00:04:05 reason about. On the right, what you will be able  to do by the end. First, distinguish iteration,  

  • 00:04:11 increments, and a single large batch of delivery.  Second, locate a bottleneck using queues and  

  • 00:04:17 completion evidence. Third, distinguish work  in progress, throughput, cycle time and lead  

  • 00:04:23 time. Fourth, explain an estimate as conditional  information rather than a guarantee. And fifth,  

  • 00:04:30 choose a next action using risk, dependency,  feedback value and capacity. That is the whole  

  • 00:04:36 route, so let's open the first scene with the next  page button. This is the first scene, an anchor  

  • 00:04:43 scene, so we take our time. Its title asks: when  would the team learn it built the wrong thing? The  

  • 00:04:49 red banner at the top holds the one thing that  goes wrong. The team has misunderstood 1 need:  

  • 00:04:54 students need clear cancellation feedback. The  same misunderstanding sits in both plans, and the  

  • 00:05:00 rounds here are teaching units, not real days.  2 lanes, 2 plans for the same 8 cards. Plan 1,  

  • 00:05:08 at the top, builds everything and integrates  at the end. Plan 2, below, uses small slices  

  • 00:05:14 early. Before any step, decide. When would the  team learn that its cancellation messages miss  

  • 00:05:22 what people need? Option A, when the last card  is finished. Option B, when people use a small  

  • 00:05:29 working part. Option C, only after the release.  Pause here and choose. A finished card only tells  

  • 00:05:37 you that the code exists. The need shows up when  a person actually uses the result, so keep that  

  • 00:05:44 in mind as we step. To move through a scene I use  the Step button at the top right, and the dots in  

  • 00:05:50 What is happening count the states. I click Step  to follow plan 1. Plan 1 builds 1 card per round:  

  • 00:05:58 W01, the conflict rule, in round 1, then the  duration boundary, then cancellation ownership,  

  • 00:06:04 and so on, up to support diagnosis in round 8. In  round 9, the team integrates all 8. Until then,  

  • 00:06:11 nothing can be used, so nobody outside the  team can tell whether the cards are right.  

  • 00:06:16 I click Step. People first use the result in  round 9, and now the misunderstanding shows:  

  • 00:06:23 the cancellation messages do not tell people  clearly what happened. Look at the rework: every  

  • 00:06:30 card's messages are re-examined after integration.  All 8 cards are outlined in red, because in one  

  • 00:06:36 integrated whole, nobody knows yet which card is  wrong. That is a late discovery: 8 finished cards,  

  • 00:06:43 and 1 misunderstanding found at the very end. Now  let's follow plan 2. I click Step. Plan 2 builds  

  • 00:06:51 a small usable slice first: book a room and cancel  it, with the messages people see. Slice 1 holds 3  

  • 00:06:58 cards: the conflict rule, cancellation ownership  and accessible feedback. Slice 2 adds booking  

  • 00:07:04 limits and the notices people receive, and slice  3 adds faster search and support answers. After  

  • 00:07:11 each slice, people use it: the blue circles  mark those moments. Same cards, same team,  

  • 00:07:17 same misunderstanding. The only difference is  when a real person touches the work. I click  

  • 00:07:22 Step. People try slice 1 in round 3, and the  unclear cancellation message shows at once,  

  • 00:07:30 because this slice is exactly where people  cancel a booking. And look at what changes:  

  • 00:07:36 only accessible feedback, 1 card. Nothing else  was built yet on the wrong message, so the fix  

  • 00:07:42 is small and early. I click Step. 2 words come  out of this. Each slice adds usable capability:  

  • 00:07:50 that is an increment. Changing the message after  feedback revises the team's understanding: that  

  • 00:07:56 is an iteration. So an increment adds something  people can use, and an iteration goes back over  

  • 00:08:03 what you believed. Small slices give you both,  early. I click Step. Learned in round 3 instead of  

  • 00:08:10 round 9, with 1 card to revise instead of 8. The  principle: shorter feedback loops can expose wrong  

  • 00:08:18 assumptions earlier; useful increments must still  make sense as a system. In short: show slices  

  • 00:08:24 early, and make them fit. That last part matters,  and the next 2 conditions test it. Now let's  

  • 00:08:30 change 1 condition. The presets sit at the top of  the rail. I click Later feedback, and the scene  

  • 00:08:36 starts again at its first state under the new  condition. Same slices, same misunderstanding.  

  • 00:08:43 Only the moment people first use the work  moves. The question: keep the misunderstanding,  

  • 00:08:47 but let people see the work later. What changes?  Option A, nothing, the fix is the same. Option B,  

  • 00:08:56 more finished work must be reconsidered. Option C,  the misunderstanding goes away. Pause and decide.  

  • 00:09:04 Think about what sits on top of a wrong message.  Every card built after it may copy it or depend on  

  • 00:09:10 it. Let's move the feedback point. I click Step.  Feedback in round 3, as before: the first slice is  

  • 00:09:17 in use, and only its cancellation message changes.  1 card to reconsider, accessible feedback. I click  

  • 00:09:25 Step. Now feedback arrives only in round 6.  By then, the second slice reused the unclear  

  • 00:09:32 cancellation message in its notices. 2 cards to  reconsider: accessible feedback and notification  

  • 00:09:38 recovery. Same misunderstanding, 3 rounds later,  and the work to redo has doubled. I click Step to  

  • 00:09:45 push the feedback point to the very end. Feedback  only in round 9, as in the batch. Now every card's  

  • 00:09:52 messages are re-examined after integration: all 8  cards, in the lane at the top. 1 misunderstanding,  

  • 00:09:59 and the later you learn it, the more finished work  stands on it. I click Step for the summary. 1,  

  • 00:10:06 then 2, then 8 cards to redo. The feedback  point decides how much work stands on a  

  • 00:10:13 wrong assumption. That is the first half of the  principle. Now the second half: useful increments  

  • 00:10:20 must still make sense as a system. I click  Interface, the third preset. The constraint:  

  • 00:10:27 the identity interface must be agreed before  slices 2 and 3. Both need to know who a member is.  

  • 00:10:34 Can each slice decide that on its own? Option A,  yes, slices are independent. Option B, agree the  

  • 00:10:41 interface first. Option C, decide it at the end.  Pause and choose before I step. Small slices sound  

  • 00:10:49 independent, but they share parts of the system  underneath. Let me show that dependency. I click  

  • 00:10:54 Step. Here it is: slices 2 and 3 both depend  on 1 decision, agree the identity interface,  

  • 00:11:02 and that decision has to come before either  slice is built. What happens if the team skips  

  • 00:11:08 that decision and lets each slice move fast on  its own? I click Step. Without the agreement,  

  • 00:11:15 slices 2 and 3 each assume their own way of naming  a member, and joining them later reopens both. 2  

  • 00:11:23 fast slices, 1 slow repair. Small does not mean  independent. Slices still need an agreed interface  

  • 00:11:30 and a sensible order. I click Step to see the  fix. Agree the identity interface by round 3,  

  • 00:11:37 then build both slices on it. Now both carry the  green agreed interface tag, and they fit together  

  • 00:11:44 as one system. So the full principle: shorter  feedback loops expose wrong assumptions earlier,  

  • 00:11:51 and useful increments must still make sense as a  system. Next, how teams organize this feedback. I  

  • 00:11:58 click the next page button. The second scene is a  bridge scene, and its title asks: does a meeting  

  • 00:12:05 create a feedback loop by itself? 3 columns, 3  ways to coordinate the same team. Plan-driven work  

  • 00:12:13 agrees a plan up front. Iterative timeboxes,  as in Scrum, set a goal for each Sprint. And  

  • 00:12:19 flow policies, as in Kanban, keep a visible  workflow with explicit policies. Decide first:  

  • 00:12:26 3 teams build the same capability. Which one  learns first that its plan is wrong? Option A,  

  • 00:12:32 the team with the most detailed plan. Option  B, the team with the most meetings. Option C,  

  • 00:12:38 the team that inspects something usable  first. Pause and choose. A detailed plan  

  • 00:12:45 and many meetings both feel like progress. What  actually tells a team it is wrong is something  

  • 00:12:51 real to look at. I click Step to compare the  rows. Row 1, how each coordinates. Plan-driven:  

  • 00:12:58 a plan agreed up front, and each stage hands  its result to the next. Scrum: a Sprint Goal,  

  • 00:13:05 for a Sprint of 1 month or less. Kanban: a defined  workflow with explicit policies, and a controlled  

  • 00:13:13 number of items in progress. 3 different ways to  decide what happens next. I click Step. Row 2,  

  • 00:13:20 what each makes visible. The plan, its milestones  and each handoff. The Product Backlog, the Sprint  

  • 00:13:27 Goal and the Increment. And for Kanban, where  each item is, how long it has aged, and where  

  • 00:13:34 work waits. Below, Scrum names 3 accountabilities:  the Product Owner for value, the Scrum Master for  

  • 00:13:41 how well Scrum works, and the Developers for  the work. They are where these decisions become  

  • 00:13:45 visible, not job titles. So visibility differs:  a plan shows commitments, a Sprint shows a goal  

  • 00:13:54 and a usable result, and a flow board shows  waiting work. I click Step. Row 3 is the heart  

  • 00:14:01 of this scene: when feedback arrives. Plan-driven  work gets it at planned milestones and handoffs,  

  • 00:14:07 often late, when much is already built. In  Scrum, the Sprint Review inspects the Increment,  

  • 00:14:13 and the Retrospective inspects how the team  works. In Kanban, feedback comes continuously,  

  • 00:14:19 from flow measures and delivered items. Notice  the pattern: in each approach, feedback comes from  

  • 00:14:25 something delivered and inspected. A Sprint Review  with no usable Increment has nothing to inspect. I  

  • 00:14:31 click Step. Row 4, what stays open to change. In  plan-driven work, little, once the handoffs have  

  • 00:14:39 started. In Scrum, the next Sprint Goal and  the order of the Product Backlog. In Kanban,  

  • 00:14:45 which item to pull next, and the workflow  policies themselves. An early decision that stays  

  • 00:14:51 reversible is cheaper to get wrong. I click Step.  Row 5, where each one is strongest. Plan-driven  

  • 00:14:59 coordination is strongest for a costly external  integration, or a required evidence handoff,  

  • 00:15:06 where an agreed date matters. Scrum is strongest  for a product goal whose details are learned from  

  • 00:15:12 each usable Increment. Kanban is strongest for  a steady stream of items whose arrival times are  

  • 00:15:18 unknown. And there is another way to learn before  committing, in any of the 3: an early prototype,  

  • 00:15:24 or a risk investigation. I click Step. A meeting  alone is not feedback: a review with nothing  

  • 00:15:31 usable to inspect, or a board nobody pulls  from, changes no decision. That is a ritual,  

  • 00:15:37 not a feedback loop. The principle: choose  coordination practices for the uncertainty  

  • 00:15:42 and constraints of the work, not for their  labels. In short, pick practices for the work,  

  • 00:15:48 not the name. Now I change the work itself.  I click Incidents: support reports arrive at  

  • 00:15:55 unknown times, some urgent, instead of 1 planned  capability. Which approach wins now? Option A,  

  • 00:16:03 plan for them. Option B, wait for the next Sprint.  Option C, none by name, each needs a policy. Pause  

  • 00:16:10 and think. Nobody can plan the arrival of an  incident that has not happened yet, and waiting  

  • 00:16:18 a whole Sprint is too long for an urgent one.  I click Step. What still helps. Plan-driven:  

  • 00:16:26 the fixed parts, such as an agreed date for  the external integration. Scrum: the Sprint  

  • 00:16:32 Goal keeps the planned work visible. Kanban:  arrivals join a visible queue, and the limit  

  • 00:16:39 on items in progress protects the work already  started. I click Step. What each must revise:  

  • 00:16:46 plan-driven work cannot schedule an arrival nobody  knows yet. Scrum needs a policy for urgent work,  

  • 00:16:53 including when the Product Owner renegotiates the  goal. Kanban: an explicit policy for urgent items,  

  • 00:17:00 and a limit on how many run at once. Every  column changed its policy. I click Step. No  

  • 00:17:07 universal winner. Each approach needs a revised  policy, and the question is what the work needs:  

  • 00:17:13 when feedback arrives, and which decisions can  still change. So choose coordination practices  

  • 00:17:19 for the uncertainty and constraints of the work,  not for their labels. Now let's watch work flow  

  • 00:17:26 through a board. Next page. The third scene is  an anchor, and it is the board from the opening,  

  • 00:17:34 run round by round. Its title asks: make one stage  faster, does the work finish sooner? Across the  

  • 00:17:42 top, the 5 columns: Ready, Implementing, Waiting  for review, Review and Done. Below them, the names  

  • 00:17:49 of the 8 cards, a chart of the rounds, and a table  of the same numbers. Round 0: 8 cards requested,  

  • 00:17:56 none started. Implementation takes 2 cards per  round, review takes 1, and a card implemented in  

  • 00:18:03 a round joins the review queue for the next round.  Decide first. Implementation finishes 2 cards per  

  • 00:18:09 round and review 1. Where will the next unfinished  card wait? Option A, in Ready. Option B, in the  

  • 00:18:17 review queue. Option C, nowhere: both stations  keep up. Pause and choose. 2 cards go in every  

  • 00:18:24 round and only 1 comes out, so the numbers already  tell you something. Let's watch it happen. I click  

  • 00:18:30 Step. Round 1. Implementation takes W01 and W02;  they sit in its 2 slots for this round. Review is  

  • 00:18:41 idle, because nothing was waiting when the  round began. Those 2 cards now wait for review,  

  • 00:18:47 and they can be reviewed only in the next round.  The table and the chart record round 1: 2 waiting,  

  • 00:18:53 none done. I click Step. Round 2. Review finishes  W01, its 1 card for the round. Implementation  

  • 00:19:02 adds W03 and W04. 2 in, 1 out: now 3 cards wait.  Look at the chart: the yellow line is the queue,  

  • 00:19:12 the green line is done, and the dashed blue line  counts cards started. Started races ahead of done.  

  • 00:19:18 I click Step. Round 3. W02 is done, and W05 and  W06 join the queue. 6 started, 2 done, 4 waiting.  

  • 00:19:29 I click Step. Round 4, the board of the opening.  All 8 cards are started and only 3 are done. 5  

  • 00:19:38 cards wait for review, and both stations were busy  in every round. This is where busy people and fast  

  • 00:19:45 delivery come apart. Implementation looks finished  with its work, but nobody outside the team can use  

  • 00:19:51 5 of those cards yet. I click Step. Round 5.  Nothing is left to start, so implementation is  

  • 00:19:59 idle. Review still finishes 1 card per round,  and 4 cards wait. I keep stepping. Round 6. W05,  

  • 00:20:08 accessible feedback, is finally done, 3 rounds  after its developer finished it. The queue shrinks  

  • 00:20:14 1 card per round, at review's pace. Step. Round  7: 2 cards wait, and 6 are done. Round 8: I step  

  • 00:20:24 again, and only 1 card waits. Round 9: I click  Step, and W08 is done. Implementation finished its  

  • 00:20:33 part in round 4, but the board finished in round  9. Review set the pace. Count it on the table:  

  • 00:20:40 once review was busy, done grew by exactly 1 card  per round. The limiting stage decided when the  

  • 00:20:47 whole board finished. Now the tempting fix: make  implementation faster. I click Implementation 4,  

  • 00:20:55 and the board starts again with only that 1  condition changed. Implementation now finishes 4  

  • 00:21:02 cards per round. Review still finishes 1. The  dotted lines on the chart are the baseline,  

  • 00:21:08 kept for comparison. When is the last card done?  Option A, round 5, about twice as soon. Option B,  

  • 00:21:16 round 9, as before. Option C, round 8, a little  sooner. Pause and decide. This time I use a  

  • 00:21:23 different control. The Run button, next to Step,  advances the model by itself, 1 round every second  

  • 00:21:30 and a half, until the last round. I click Run now,  and I just watch. The yellow line climbs: 4 cards  

  • 00:21:37 start in round 1, all 8 in round 2. Then the queue  drains 1 card per round, while the green line of  

  • 00:21:45 done climbs as slowly as before. Done in round  9, exactly as before. Doubling implementation  

  • 00:21:52 did not double completion, because review still  finishes 1 card per round. The only thing that  

  • 00:21:57 grew was the queue, to 7 cards at its peak. Look  at the dotted baseline and the solid line of done:  

  • 00:22:05 they lie on top of each other. More activity at  1 stage, and not one card sooner for the people  

  • 00:22:12 waiting. The principle: local activity is not the  same as system throughput. Improve the limiting  

  • 00:22:18 flow, not merely the busiest-looking stage.  In short, speed up the step that limits flow.  

  • 00:22:25 So let's relieve the real limit instead. I click  Review 2: implementation is back at 2 per round,  

  • 00:22:31 and review now finishes 2. When is everything  done now? Option A, round 9. Option B,  

  • 00:22:38 round 5. Option C, round 3. Pause and work it out  from the capacities. Implementation still needs 4  

  • 00:22:46 rounds to start 8 cards at 2 per round, and review  follows 1 round behind. I step through it round  

  • 00:22:53 by round. I click Step. Round 1: W01 and W02 are  implemented, and review waits for its first cards,  

  • 00:23:02 just as before. Step. Round 2: review finishes  both W01 and W02, and 2 new cards arrive.  

  • 00:23:11 The queue holds at 2. Step. Round 3: 4 done, 2  waiting. 2 cards come in and 2 go out every round,  

  • 00:23:21 so the queue never grows. Step. Round 4: 6 are  done, implementation has now started all 8 cards,  

  • 00:23:30 and Ready is empty. I step once more. Done in  round 5 instead of round 9. The review queue  

  • 00:23:39 never held more than 2 cards. Relieving the real  constraint moved the whole board forward. And look  

  • 00:23:47 where the limit went: implementation, at 2 per  round, now sets the pace. Relieve one limit and  

  • 00:23:53 the next one appears, so you keep looking at  the flow. Improve the limiting flow, not the  

  • 00:23:59 busiest-looking stage. Next, the clocks behind  all that waiting. I click the next page button.  

  • 00:24:07 The fourth scene is a bridge, and its title asks:  which clock does the person who asked experience?  

  • 00:24:14 Each row is 1 card of the baseline board. The bars  show where each card spends its rounds: the dashed  

  • 00:24:22 line is waiting in Ready, blue is implementing,  the hatched yellow is waiting for review,  

  • 00:24:28 and green is review. The legend below repeats  it. Someone asked for W08, support diagnosis, at  

  • 00:24:35 round 0. Which clock do they experience? Option A,  from when the team starts W08. Option B, from the  

  • 00:24:44 request to the finished change. Option C, only the  time W08 spends in review. Pause and decide which  

  • 00:24:52 clock matters to that person. From their side, the  waiting started the moment they asked, whatever  

  • 00:25:00 the team was doing. Let me put markers on every  card. I click Step. 3 markers per card. The circle  

  • 00:25:08 is when it was asked for, and every card was  asked for at 0. The blue bar is when work started,  

  • 00:25:14 and the green diamond is when it finished.  W08 starts at 3 and finishes at 9. The whole  

  • 00:25:21 row is highlighted, because we follow this 1 card.  I click Step. From the request to the finish:  

  • 00:25:28 9 rounds for W08. This is the lead time, the clock  of the person who asked. It runs from the moment  

  • 00:25:35 they asked. The lead time column now shows it for  every card: 2 rounds for W01, up to 9 for W08. I  

  • 00:25:44 click Step. From the declared start to the finish:  6 rounds. This is the cycle time, the team's  

  • 00:25:51 clock. It starts when implementation begins, a  boundary the team declares. 2 clocks for 1 card:  

  • 00:25:58 9 rounds for the person, 6 for the team. The cycle  time column holds the team's clock for every card.  

  • 00:26:05 I click Step. Where did the other 3 rounds go?  W08 waited in Ready, before anyone started it:  

  • 00:26:13 inside its lead time, outside its cycle  time. Inside the cycle time it waited too:  

  • 00:26:19 4 rounds for review, the hatched part. On average,  cycle time is 4 rounds and lead time is 5.5. Now a  

  • 00:26:27 change teams often make: limit work in progress.  I click Limit 2: at most 2 cards may be started  

  • 00:26:35 and not yet finished. Demand stays the same:  the same 8 cards, asked for at 0, with the same  

  • 00:26:42 capacities. A card starts only while fewer than 2  cards are in progress. So what happens? Option A,  

  • 00:26:50 both clocks get shorter. Option B, cycle time  shrinks and lead time stays the same. Option C,  

  • 00:26:57 neither clock changes. Pause and decide. Before  the answer, remember where W08 started without  

  • 00:27:05 the limit: at round 3. I click Step to apply the  limit. Starts spread out. W08 now starts at 6, and  

  • 00:27:14 at most 2 cards are in progress at once, instead  of 5. The limit holds cards back in Ready. Look at  

  • 00:27:22 the finish diamonds: they sit exactly where they  were before. Keep that in mind. I click Step. Work  

  • 00:27:29 item age: for a started card that is not finished,  the time since it started. At the end of round 6,  

  • 00:27:35 the oldest started card is 2 rounds old, not 4.  That looks better inside the team. But W08 has  

  • 00:27:43 already waited 6 rounds in Ready, outside every  clock the team measures. I click Step. Cycle time  

  • 00:27:51 falls: W08 takes 3 rounds from start to finish,  and the average drops from 4 to 2.9 rounds. On  

  • 00:28:00 a report of cycle time, that looks like a much  faster team. Now look at the other clock, the one  

  • 00:28:06 the person experiences. I click Step. Lead time  is unchanged: W08 still finishes in round 9, and  

  • 00:28:14 every card finishes in the same round as before.  The limit moved the waiting outside the cycle  

  • 00:28:20 time boundary. A limit can make queues visible and  protect focus, but here it served nobody sooner.  

  • 00:28:27 The principle: timing metrics are meaningful  only when their boundaries and excluded waiting  

  • 00:28:32 are explicit. In short, say where each clock  starts and stops. Next, a number that everyone  

  • 00:28:39 plans around. I click the next page button. The  fifth scene is a bridge, and its title asks:  

  • 00:28:47 three days, effort, elapsed time or a promise? It  starts from 1 card, W03, cancellation ownership.  

  • 00:28:56 The change is small to describe: only the owner  may cancel a future confirmed booking, which is  

  • 00:29:02 rule R-03. The team says it will take three days.  Decide first: what does three days mean? Option A,  

  • 00:29:09 three days of one person working on it. Option B,  finished three calendar days from now. Option C,  

  • 00:29:16 a promise others plan around. Pause and choose.  The number alone cannot tell you, and each reading  

  • 00:29:25 leads people to plan differently. I click Step.  3 meanings, 3 different numbers. Effort is the  

  • 00:29:32 working time of 1 person. Elapsed time is calendar  time until it is finished. And a commitment is a  

  • 00:29:38 promise that others build their plans on. Three  days of effort can easily take 6 calendar days,  

  • 00:29:45 and neither of them is a commitment until  someone says so. Let's look behind the  

  • 00:29:49 number. I click Step. Behind the number is known  work: the ownership check before a cancellation,  

  • 00:29:57 the denial message for another member, and checks  for the 4 cancellation cases. And 2 dependencies,  

  • 00:30:04 in yellow: the identity interface, which  tells the change who is asking, and review,  

  • 00:30:10 which finishes 1 card per round, as on the board.  1 question is still open: how the identity service  

  • 00:30:18 names a member. Every one of these can stretch the  calendar without adding any effort. I click Step.  

  • 00:30:26 Now evidence instead of a guess: 5 earlier  changes of similar size. They took 2, 3, 3,  

  • 00:30:32 4 and 6 working days, from start to done. 3 of the  5 took 3 to 4 days. One took 2, and one took 6,  

  • 00:30:41 when review was busy. A single number hides that  spread completely. I click Step. With its basis,  

  • 00:30:49 the estimate becomes: 3 to 4 days elapsed, and  1 to 2 days of effort, if the identity interface  

  • 00:30:55 is agreed. The range sits beside the single  number. This range summarizes 5 real examples,  

  • 00:31:03 and it names the assumption it rests on: the  identity interface is agreed. I click Step.  

  • 00:31:10 And the estimate is only part of the cost. Doing  the change takes 1 to 2 days of effort. Waiting  

  • 00:31:17 is elapsed time, not effort: the review queue and  the identity decision. Afterwards comes continuing  

  • 00:31:23 support: questions about denied cancellations, and  updates whenever the identity interface changes.  

  • 00:31:29 That cost continues long after the estimate  ends. The principle: an estimate is a conditional  

  • 00:31:35 statement whose assumptions should travel with  it. In short, state what the number assumes. Now  

  • 00:31:42 I change exactly 1 assumption, the one the range  rests on. I click Interface open: the identity  

  • 00:31:49 interface is not yet agreed. What should happen to  the estimate? Option A, keep three days. Option B,  

  • 00:31:57 widen it, or state its condition. Option C, double  it to be safe. Pause and decide. Doubling a number  

  • 00:32:06 is still a guess, and keeping it hides the risk.  Let's see what the dependency does to the range.  

  • 00:32:12 I click Step. Until the interface is agreed,  the change cannot finish, so the range widens  

  • 00:32:18 to 3 to 9 days. The red band on the chart shows  how wide the uncertainty really is. A range this  

  • 00:32:26 wide is still honest: it tells everyone that the  plan depends on a decision nobody has made yet.  

  • 00:32:32 I click Step. The other honest form is a qualified  estimate: 3 to 4 days after the identity interface  

  • 00:32:41 is agreed. The condition travels with the number.  Anyone who reads it knows what must happen first,  

  • 00:32:48 and when the number starts to count. I click  Step. Now the value of resolving the uncertainty:  

  • 00:32:56 a half-day conversation with the identity  team narrows 3 to 9 days back to 3 to 4.  

  • 00:33:02 Half a day of talking is worth more than any  amount of careful guessing about the same unknown.  

  • 00:33:08 I click Step. Finally, the trigger: revise the  estimate when the identity interface is agreed,  

  • 00:33:15 or when review falls behind. An estimate that says  when to revise it stays useful. An estimate is a  

  • 00:33:23 conditional statement whose assumptions travel  with it. Next: what should the team do first?  

  • 00:33:28 I click the next page button. The sixth scene  is an anchor, and its title asks: what should  

  • 00:33:36 the team learn before committing more work? 3  candidate next steps, judged on 5 criteria in  

  • 00:33:43 words, not invented numbers. The criteria are the  column heads: impact, uncertainty, reversibility,  

  • 00:33:50 cost of delay, and information gained. Then what  each step would clarify, and what failure would  

  • 00:33:56 cost. Decide first: what should the team learn  before it commits more work? Option A, the visual  

  • 00:34:03 refinement, quick and visible. Option B, show that  simultaneous bookings cannot overlap. Option C,  

  • 00:34:11 investigate the unclear identity dependency. Pause  and choose. The easy, visible option is tempting,  

  • 00:34:19 because everyone can see it. Let's judge each  row on the same 5 criteria. I click Step. Row 1,  

  • 00:34:27 the visual refinement: low impact,  low uncertainty, easy to reverse,  

  • 00:34:32 a low cost of delay, and little information  gained. It clarifies how the booking page looks,  

  • 00:34:39 and nothing about the rules. If it goes wrong, the  cost is small and easy to change later. Pleasant,  

  • 00:34:45 but it teaches little. I click Step. Row 2: show  that simultaneous bookings cannot overlap. High  

  • 00:34:53 impact and high uncertainty: 2 requests for 1 room  can arrive at the same moment, and R-01 must still  

  • 00:35:00 hold. Medium reversibility, a high cost of delay,  because every later booking feature relies on it,  

  • 00:35:07 and a large information gain. If it goes wrong,  2 people arrive for 1 room. I click Step. Row 3:  

  • 00:35:15 investigate the unclear identity dependency.  High impact and high uncertainty again,  

  • 00:35:20 because R-03 depends on who is asking, and nobody  knows yet how the identity service names a member.  

  • 00:35:27 Its reversibility is low if the guess is wrong: a  wrong identity reference would be built into the  

  • 00:35:33 cancellation rule. A medium cost of delay, and a  large information gain. I click Step. Each step  

  • 00:35:40 can also be chosen 4 ways. Investigate: a short,  bounded look before committing. Implement: build  

  • 00:35:47 now on the current assumptions. Reduce scope: ship  owner cancellation first, and staff actions later.  

  • 00:35:53 And defer: leave the visual refinement until the  rules are settled. I click Step. The baseline  

  • 00:36:00 decision: first, show that simultaneous bookings  cannot overlap. It has the highest cost of delay  

  • 00:36:07 and a large information gain, and the identity  choice can still be corrected. Then investigate  

  • 00:36:13 the identity dependency. And the visual refinement  waits. The value it would have delivered now  

  • 00:36:19 is the opportunity cost of this choice, and no  invented money figure is needed. Now 1 condition  

  • 00:36:26 changes, and only 1: reversibility. I click  Hard to reverse: the temporary identity choice  

  • 00:36:33 becomes a difficult data migration. The identity  choice will be stored in every booking record,  

  • 00:36:39 so changing it later means migrating  data. What changes? Option A, nothing,  

  • 00:36:46 keep the order. Option B, seek evidence on  identity before building on it. Option C,  

  • 00:36:53 skip the investigation to save time. Pause and  decide. The other 4 criteria of the identity row  

  • 00:37:00 stay exactly as they were. Watch the one cell that  moves. I click Step. Reversibility of the identity  

  • 00:37:08 row drops to very low, in red: changing it means  migrating every booking record. Nothing else in  

  • 00:37:16 the table changed. A hard-to-reverse choice is  exactly where extra evidence pays for itself,  

  • 00:37:22 because a mistake would be copied into every  record. I click Step. The decision changes:  

  • 00:37:29 first, investigate the unclear identity  dependency, then show that bookings cannot  

  • 00:37:34 overlap. A hard-to-reverse choice deserves more  evidence before work builds on it. Same options,  

  • 00:37:40 same impact, same uncertainty. Only reversibility  changed, and it was enough to change the order. I  

  • 00:37:47 click Step. And a warning about small estimates.  A quick identity workaround now has the smallest  

  • 00:37:54 effort, no waiting, and a low opportunity cost  right now. But its continuing support is high,  

  • 00:38:01 and its exit cost is high: a migration of every  booking record. The smallest implementation  

  • 00:38:07 estimate can be the most expensive choice over  the change's life. I click Step. What remains  

  • 00:38:14 uncertain is still named: how the identity service  names a member, until the investigation reports. A  

  • 00:38:21 good decision table keeps its open questions  visible. The principle: prioritize not only  

  • 00:38:27 output, but also the decisions and uncertainties  that could make later work wasteful. In short,  

  • 00:38:33 learn what could waste later work. Next page. The  seventh scene is a bridge, and its title asks: the  

  • 00:38:42 code runs, is the cancellation change done? The  card on the left is W03, cancellation ownership.  

  • 00:38:50 It is coded, and 1 case already runs: Ari, U-01,  cancels B-001 at 09:00, and it is allowed. That  

  • 00:38:58 is the happy path. Is the change done? Option A,  yes, the code runs. Option B, not until the other  

  • 00:39:06 R-03 cases behave as required. Option C, yes, once  it is merged. Pause and choose. Running code tells  

  • 00:39:14 you 1 case works, and R-03 has more cases than  that. I click Step to try the next one. Next case:  

  • 00:39:21 Bo, U-02, cancels Ari's booking B-001. R-03 says  denied. The change says allowed, with a red cross.  

  • 00:39:29 The ownership check is missing. The code runs, and  it does the wrong thing for a case nobody tried.  

  • 00:39:34 The status chip now says happy path only. I click  Step. And there is a second gap. After Cancel, the  

  • 00:39:43 screen shows no status message at all. R-05 says  people must perceive meaningful status, so Ari  

  • 00:39:50 cannot tell whether it worked. 2 missing pieces,  both invisible if you only run the happy path. So  

  • 00:39:56 what should done mean for this team? I click Step.  The team's completion policy, sized to its risk,  

  • 00:40:04 lists 5 kinds of evidence. The first, intended  behavior, is missing: the ownership check. Review  

  • 00:40:10 means another developer read the change. Checks  means automated checks run on every change.  

  • 00:40:16 Operability means a denied cancellation is logged  with its reason. And documentation is missing:  

  • 00:40:22 the success and denial messages people see. 2 red  crosses, 2 gaps we found by trying cases. I click  

  • 00:40:29 Step. Now the ownership check and the message are  fixed. All 5 badges are green, and the status says  

  • 00:40:37 ready to rely on, not only coded. The cases table  grew too: Bo is denied, Ari at 10:00 is denied  

  • 00:40:44 because the booking has started, and a request  that is not signed in is denied. And the screen  

  • 00:40:51 now says: B-001 is cancelled, the room is free  again. Ari knows it worked. I click Step. One  

  • 00:40:59 more distinction. Acceptance examples belong to 1  requirement: the R-03 cases above. The completion  

  • 00:41:05 policy applies to every change the team calls  done. In Scrum, that shared policy is called the  

  • 00:41:11 Definition of Done: a description of the state  an Increment must reach to meet the quality the  

  • 00:41:18 product needs. But should every change carry the  same weight? I click Wording fix: a typo fixed in  

  • 00:41:24 an internal log label, with no behavior change.  Does it need the same evidence? Option A, yes,  

  • 00:41:31 1 checklist, all of it, every time. Option B, the  same policy, only the relevant evidence. Option C,  

  • 00:41:38 no evidence, it is only words. Pause and decide.  Even a typo in a log label can break something:  

  • 00:41:46 a search, a dashboard, an alert. Let's see what  is relevant. I click Step. Intended behavior:  

  • 00:41:53 no behavior changes, so there is nothing new to  accept. Review: 1 reader checks the new wording.  

  • 00:41:59 Checks: the existing checks still pass. The  comparison on the right fills in as we go:  

  • 00:42:05 the cancellation change on one side, the  wording correction on the other. I click Step.  

  • 00:42:11 Documentation: the corrected label is the change  itself. And operability, the interesting one:  

  • 00:42:17 log searches that used the old label must still  find it. So the small change still has a real  

  • 00:42:24 risk, and the policy found it, without demanding  any ceremony that adds nothing. I click Step. 2  

  • 00:42:32 changes, 1 policy. The evidence fits each change:  all 5 items for the cancellation, and a lighter,  

  • 00:42:39 relevant set for the wording fix. The principle:  a shared completion policy should make quality  

  • 00:42:45 expectations visible and proportionate. In short,  agree what done means, sized to the risk. Next  

  • 00:42:52 page. The last scene is a bridge, and its title  asks: the review queue keeps growing, what should  

  • 00:43:01 change? The first box holds the observation,  straight from the board. The review queue grows:  

  • 00:43:07 5 cards wait at the end of round 4. The small line  is the baseline queue from scene 3, peaking at 5.  

  • 00:43:15 What should the team do next? Option A, tell the  reviewer to hurry. Option B, try a stated change  

  • 00:43:22 to the review step. Option C, stop starting new  cards for good. Pause and choose. Notice that  

  • 00:43:30 option A is about a person, and option B is about  the system. That difference matters more than it  

  • 00:43:38 seems. I click Step. The reviewer is too slow  blames a person. The system view says: 2 cards  

  • 00:43:45 per round arrive at a review step that finishes  1. That is not a character flaw, it is arithmetic,  

  • 00:43:52 and we watched it happen on the board in scene 3.  I click Step. Why keep the discussion blameless?  

  • 00:44:01 People report delays and mistakes honestly only  where reporting them is safe. Blame teaches  

  • 00:44:07 people to hide the queue. Blameless discussion  and psychological safety make the process data  

  • 00:44:13 trustworthy, and without trustworthy data, every  process change is a guess. I click Step. Now the  

  • 00:44:20 change, stated like a hypothesis. The proposal:  share review work, so a second developer reviews  

  • 00:44:27 and review takes 2 cards per round. The expected  effect: the review queue stays at 2 or fewer,  

  • 00:44:34 and all 8 cards are done in round 5, just  like the review 2 condition of scene 3. I  

  • 00:44:40 click Step. And before trying it, decide what  would show it is wrong: the queue still grows,  

  • 00:44:46 or reviewed cards come back with problems. Also  watch 1 side effect: issues missed in review.  

  • 00:44:53 3 measures, before and after: the round in which  all 8 are done, the longest review queue, and the  

  • 00:44:59 issues found after review. Before the change:  9, 5 and 1. I click Step. After the change:  

  • 00:45:06 done in round 5, the queue at most 2, and issues  found after review unchanged at 1. The evidence  

  • 00:45:13 agrees with the expected effect. But a faster flow  is not the whole story. I click Faster, shallower:  

  • 00:45:20 another team speeds review up by reading less  carefully, and their board is also done in  

  • 00:45:25 round 5. Is that better? Option A, yes, the same  speed up. Option B, look at quality and rework  

  • 00:45:32 first. Option C, yes, if nobody complains. Pause  and decide. Remember the side effect we chose to  

  • 00:45:41 watch before the change: issues missed in review.  I click Step. The new column: done in round 5,  

  • 00:45:48 queue at most 2, exactly like the careful version.  But 4 issues were found after review, not 1. Flow  

  • 00:45:55 measures alone would call both versions a success.  Only the quality measure tells them apart, and it  

  • 00:46:01 tells a different story. I click Step. 4 cards  were reopened after review. Counting the rework,  

  • 00:46:09 the last card is done in round 7, not round 5.  The fast review was slower in the end. A single  

  • 00:46:15 target number, like the round in which everything  is done, would have rewarded the shallow review. I  

  • 00:46:21 click Step. So judge a process change on flow and  quality together. When the results disagree with  

  • 00:46:29 the expected effect, change the explanation first,  then the process. The principle: change a process  

  • 00:46:36 deliberately, observe its consequences, and revise  the explanation when the evidence disagrees. In  

  • 00:46:43 short: try a change, watch its effects, revise.  That was the last scene. Next, the 5 measures of  

  • 00:46:49 this lecture on 1 page. I click the next page  button. This page brings 5 measures of 1 board  

  • 00:46:57 together, with where each one starts and stops, on  1 timeline: W08 in the baseline, asked for at 0,  

  • 00:47:05 started at 3, finished at 9. Each card below is 1  measure. When I click one, its 2 boundaries light  

  • 00:47:14 up on the timeline. I click Work in progress.  Work in progress: items started but not finished,  

  • 00:47:21 counted at a moment. On the board it was 5 at  the end of round 4, and at most 2 with the limit.  

  • 00:47:28 Next, throughput, and I click it. Items finished  per unit of time, counted at the finish line:  

  • 00:47:35 1 card per round, once review was busy. Work item  age, click. For an item not yet finished, from its  

  • 00:47:43 start to now. At the end of round 6, W08 was 3  rounds old. Cycle time, click. From the declared  

  • 00:47:51 start to the finish: 6 rounds for W08, and 3 with  the limit. And lead time, click. From the request  

  • 00:47:59 to the finish, the clock of the person who asked:  9 rounds, with or without the limit. The first 4  

  • 00:48:06 are the flow measures of the Kanban Guide. Lead  time is the stakeholder clock this lecture adds,  

  • 00:48:12 because the waiting before the start is real  waiting. A timing measure is only meaningful with  

  • 00:48:18 its 2 boundaries, and with the waiting it leaves  out named. Now the principles and checks. Next  

  • 00:48:25 page. 8 principles, 1 per scene, and 6 checks.  Principle 1: shorter feedback loops can expose  

  • 00:48:34 wrong assumptions earlier; useful increments  must still make sense as a system. Principle 2:  

  • 00:48:41 choose coordination practices for the uncertainty  and constraints of the work, not for their labels.  

  • 00:48:47 Principle 3: local activity is not the same as  system throughput. Improve the limiting flow,  

  • 00:48:52 not merely the busiest-looking stage. Principle  4: timing metrics are meaningful only when their  

  • 00:48:58 boundaries and excluded waiting are explicit.  Principle 5: an estimate is a conditional  

  • 00:49:05 statement whose assumptions should travel with  it. Principle 6: prioritize not only output,  

  • 00:49:10 but also the decisions and uncertainties that  could make later work wasteful. Principle 7:  

  • 00:49:17 a shared completion policy should make quality  expectations visible and proportionate. Principle  

  • 00:49:22 8: change a process deliberately, observe its  consequences, and revise the explanation when  

  • 00:49:28 the evidence disagrees. Now the 6 checks. Decide  your answer before I open each one. Question 1:  

  • 00:49:35 review processes 1 item per round. Will doubling  implementation necessarily double completion? I  

  • 00:49:43 click it. No: review remains the limiting stage in  the stated model, exactly what the Implementation  

  • 00:49:50 4 condition of scene 3 showed. Question 2:  what is the difference between iteration and  

  • 00:49:56 increment? Click. Iteration revisits or refines  understanding or a solution, and an increment  

  • 00:50:02 adds usable capability. Question 3: why might a  risky assumption deserve attention before an easy  

  • 00:50:09 visible feature? Click. Resolving it can prevent  later work from relying on a false premise.  

  • 00:50:15 Question 4: what should accompany a process  improvement claim? Click. A baseline, a stated  

  • 00:50:20 change, a relevant outcome measure, and attention  to quality or other side effects. Question 5:  

  • 00:50:27 why can the smallest implementation estimate still  be the more expensive choice? Click. Waiting,  

  • 00:50:31 integration, continuing support, exit cost and  displaced valuable work can change the lifecycle  

  • 00:50:38 comparison. Question 6 leaves room booking  behind. A library team writes changes faster,  

  • 00:50:44 but maintainers can review no more than before.  What should it inspect next? Think before I open  

  • 00:50:50 it. Click. Inspect waiting work, review capacity,  accepted changes and rework. Faster drafting can  

  • 00:50:57 grow the queue without improving completion, so  choose the next improvement from the constraint  

  • 00:51:02 and its quality consequences. That is the whole  lecture in 1 example: the constraint, the queue,  

  • 00:51:08 and the side effect on quality. The principles  carry across domains. Now the last page. What  

  • 00:51:16 carries forward, and where to read more. Week 5  starts from this question: when one requirement  

  • 00:51:22 changes, which parts should need to change?  Carried forward: 1 prioritized change, changing  

  • 00:51:29 a booking policy without causing widespread edits.  And the board and its measures: where work waits,  

  • 00:51:35 and which clock a person experiences. And the  open decisions: the identity interface, and  

  • 00:51:41 room closures, which stay an open need until week  14. Open items stay visible until someone decides  

  • 00:51:48 them. In practice, in 2026, boards and queues  live in tools such as Jira, GitHub Projects,  

  • 00:51:54 Linear or Trello. Their reports chart the same  measures we built by hand. The middle card lists  

  • 00:52:02 the terms of this lecture: batch, increment,  iteration, feedback loop and bottleneck,  

  • 00:52:08 then work in progress, the work in progress limit,  and throughput. Then work item age, cycle time and  

  • 00:52:15 lead time with their boundaries, and estimate,  cost of delay, reversibility, opportunity cost,  

  • 00:52:21 completion policy and blameless review. On the  right are the 5 sources: the Software Engineering  

  • 00:52:28 Body of Knowledge, the Computer Science  Curricula 2023, the Agile Manifesto principles,  

  • 00:52:34 the Scrum Guide and the Kanban Guide. So that is  lecture 4. Find where work waits before speeding  

  • 00:52:41 anything up. Show working slices early, and keep  them fitting together. Say where each clock starts  

  • 00:52:47 and stops. Let estimates carry their assumptions,  learn what could make later work wasteful, and  

  • 00:52:55 test every process change like a hypothesis. Thank  you for watching, and I will see you in week 5.

Clone this wiki locally