Agile Foundations

Scheduled sessions

Dates are confirmed on booking. If a session has to be rescheduled, registrants are given at least 10 business days' notice and may transfer to the next scheduled session or take a full refund. To book, email lukas@klose-coaching.com.

Learning objectives

At the end of this course, the learner will be able to:

• Distinguish overburden, variation and waste in a real workflow, and name concrete instances of each in their own organization.
• Explain why a push system accumulates work at its bottlenecks and a pull system does not.
• Build a board that reflects how their team actually works, with stages as columns, work-in-progress limits, and at least one written policy.
• Make a bottleneck visible to people who currently cannot see it, and open a conversation about it.
• Classify a problem as obvious, complicated, complex or chaotic, and justify the classification by what is known and how strongly inputs determine outputs.
• Select the delivery approach and leadership style that fits the domain, and explain the cost of getting that choice wrong.
• Define an increment of their own work that carries value, produces learning, and could be delivered inside two weeks.
• Read what a delivery team reports — flow, throughput, cycle time — and tell progress from activity.
• Argue the case for an empirical approach in terms of risk and problem type rather than in terms of ceremonies.

Curriculum and outline

1. How work management got hereScientific management, the assembly line and the changeover problem that forced large batches. Toyota’s pull system, where nothing is made until something downstream asks for it, and the obligations a pull signal places on the rest of the organization.
2. Flow, and its three enemiesOverburden, variation and waste. The seven wastes worked against participants’ own examples. Why throughput degrades exponentially rather than proportionally once a system is pushed past capacity. A simulation run twice, with the improvements proposed and tested rather than described.
3. Work in progressWhat limiting work in progress does to throughput, to lead time and to the people in the system, including the cost of splitting attention across too many things. Protecting the team’s attention: a single point of intake that shields specialists from sporadic direct requests, and the sequencing rule that follows from the cost of context switching — not doing less, but finishing one thing before starting the next.
4. The cost of finding defects lateDefect cost by lifecycle stage, and what a hundred-fold multiplier looks like in practice — recalls, reputational damage, and rework built on rework.
5. Kanban in practiceFour principles and six practices, taken in order — visualize the workflow, limit work in progress, manage flow, make process policies explicit, implement feedback loops, improve collaboratively — and why the method starts from the process you already have rather than replacing it. The metrics that fall out of the simulation: throughput, cycle time and quality. Improving collaboratively as an experiment rather than an opinion: observe, hypothesize, intervene, measure, then keep, amplify or discard, using an experiment canvas of context, hypothesis, tools and measurement — one intervention at a time, because the system is already working, imperfectly. Building a board for real work: stages rather than people, types of work distinguished from classes of service, swim lanes sharing the column’s work-in-progress limit, what backwards movement tells you, and where a board breaks when someone senior arrives with something urgent. Explicit policies: writing down what “emergency” and “done” actually mean, treating every column boundary as a gate with a quality standard attached, and an emergency lane with a work-in-progress limit of exactly one.
6. Problem typesTwo problems solved as a group, each participant controlling a single shape: first arranging the shapes by grey tone, which one person can solve by looking, then forming an equilateral triangle with two others of their own silent choosing, where every move changes everyone else’s problem. Obvious, complicated, complex and chaotic domains drawn out of the exercise rather than illustrated after it. Why a complicated problem yields to sense–analyse–respond and a complex one does not, so you probe, sense and respond instead. Why obvious problems have best practices, complicated ones several good practices, and complex ones neither — causality is weak, not absent, so what you can find are patterns. Leadership and cost by domain, and the cliff between the obvious and the chaotic that has taken established companies down.
7. Choosing an approachPlacing real examples in a domain and defending both the placement and the delivery approach that follows from it. The most expensive mistake is not a bad plan but a good plan applied to the wrong kind of problem.
8. Incremental deliveryTwo competing multi-year plans for the same objective, and what each is worth when circumstances change halfway through. Business, technical and financial risk, and which plan retires which. What an increment has to carry to count as one. Participants define the next real increment in their own work.
9. Scrum as a worked exampleThe events, the flow, and what each part is for. The three accountabilities and how they pull against each other on purpose. Product and sprint backlogs, and which principle each element of the framework is an answer to.
10. Technical enablersShifting testing left, continuous integration and delivery, and where test automation pays for itself — worked to a level a non-technical colleague can be persuaded with.
11. Making the caseParticipants build and deliver the argument they would have to make at home: what the practices are and why they are ordered that way, what makes a problem complex, and why an empirical approach beats an intuition-based one.