Managing Agile Delivery

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:

• Produce a forecast from empirical delivery data, expressed as a range with the reasoning behind it visible.
• Build a burn-up chart with best- and worst-case slopes, release milestones and total scope, and update it each cycle.
• Distinguish precision from accuracy, and explain to a stakeholder why a range is the more honest answer.
• Present a forecast to a steering committee, including one that has moved in the wrong direction.
• Read a cumulative flow diagram and a value-delivered chart, and use the latter to argue that work should stop rather than finish.
• Choose among de-scoping, trading scope, splitting work and re-forecasting when scope grows, and defend the choice.
• Identify technical debt, distinguish it from deferred scope, and select a repayment approach that fits the situation.
• Explain why adding people to a late team slows it down, and structure capacity growth around teams instead.
• Design alignment mechanisms that keep multiple teams coherent without creating a new bottleneck.
• Plan delivery against a conventional programme dependency using interface contracts and automated tests, with slack for change.

Curriculum and outline

1. Empirical forecastingSizing large items, normalizing against historical data, and deriving best- and worst-case rates from actual results. Building a burn-up chart with release lines and total scope on it — a chart that can be carried into every steering committee for the rest of the programme.
2. Precision and accuracyWhy a range beats a date; how precision improves as the cone narrows and variability drops; how to say something true and useful at the same time. Choosing between burn-up and burn-down by which constraint is actually fixed.
3. Reporting upwardPresenting a forecast as a range, explaining what changed, and the shift from withholding information until it is certain to sharing it while it can still be acted on. Coaching stakeholders before the first surprise rather than after it.
4. Flow and valueReading work in progress, finished-but-unshipped and shipped work off a single chart. Plotting value rather than effort, and using the curve it produces to decide when something should stop rather than finish.
5. When scope growsDe-scoping by value, trading scope between workstreams, splitting and dropping the thin slices, or updating the forecast — treated as an anomaly, a recalibration, or a full resize after significant learning.
6. Technical debtWhat separates it from deferred scope, why it accrues interest, and four ways to pay it down: as funded work, as a standing percentage of capacity, piggybacked onto whatever touches that area, or by stopping. Worked through non-software examples as well.
7. Scaling capacityWhy adding people to a late team makes it slower and how communication lines grow. Capacity added by adding teams rather than headcount. Team topologies — by value stream, by component or full stack — with the delay and dependency cost of each made explicit.
8. Alignment across teamsCommunities of practice that share knowledge and align roadmaps, run in the teams rather than in the community itself. Centres of excellence and how they differ. Coordination for dependencies. Scaling frameworks and the trade-off each makes between short feedback loops and empowered teams.
9. Hybrid deliveryWorking alongside a conventional programme: agreeing contracts at the interface, stubbing what does not exist yet, automating the tests that catch the contract breaking, and planning for both an interface change and a late delivery. Sequencing by value, by risk, and to the last responsible moment.