Books

Actionable Agile Metrics for Predictability is a comprehensive guide on how to use flow metrics and analytics to get the predictability your customers crave.

Är du välbekant med Agile medans begränsningsteorin bara är något du hört talas om? Eller tvärtom? Läs den här boken och lär dig hur du får ut det bästa av båda världarna. Den föreslagna metoden passar särskilt bra i stor skala, där det finns flera projekt/produkter som betjänar flera intressenter med överlappande deadlines och flera team.

You’ve facilitated your 50th retrospective. The same issues surface. The same action items are created. Nothing changes. Features marked "done" sit in queues for months. You’re doing your job perfectly—and it’s making no difference.What if the problem isn’t your facilitation skills? What if the Scrum Master role itself is trapped in an outdated model?

The second volume in a series on how to use flow metrics and analytics to get the predictability your customers crave.

You’ve spent hundreds of thousands, maybe millions, on risk and compliance. Yet you still can’t answer the most basic question: “At this very moment, are we compliant and within our risk thresholds?” Combined Assurance Blueprinting exposes why the system is broken and shows you how to finally fix it.

Modern Manual Testing: a pivotal guide for updating from manual to modern software testing practices. Embrace small, impactful steps towards long-term quality, mastering innovative techniques that transform your testing methods from traditional to cutting-edge with ease and efficiency.

There is a lot of noise out there about Kanban.  Search the interwebs and you will quickly get lost in the cacophony that is disinformation about flow.  We hope this book will help you navigate some of that noise around what we believe are the most exciting set of practices in the Lean-Agile world.   To learn more, please visit us at ProKanban.org!

Chapter 1: Welcome to the CasinoThe Planning Meeting Nobody Talks About Look around the room.There are eight people at this table. Four engineers, a product manager, a Scrum Master, a VP of Engineering, and a Director of Product who is visiting from the floor above and has brought her laptop, which she is not quite looking at. The calendar invite said "Sprint Planning" and blocked two hours. It is currently running at two hours forty minutes and nobody has acknowledged this.On the screen at the front of the room there is a spreadsheet. The spreadsheet has a column called Velocity and a column called Points Remaining and a column called Sprints To Go and a column called Projected Completion. The Projected Completion column says October 14.Nobody in this room believes October 14.The VP of Engineering, whose name is James, has been looking at a slightly different version of this spreadsheet for six months. Every two weeks the Projected Completion date moves. Not dramatically — two days here, a week there, occasionally a fortnight when a sprint goes badly sideways. The date has moved, in aggregate, eleven weeks since the project started. James has learned to present the date in a tone that suggests it is stable. He has become, without intending to, an expert in the performance of confidence he does not feel.The Director of Product, whose name is Miriam, knows the date is wrong. She has been in this industry for fourteen years. She has attended hundreds of sprint reviews. She has heard the date presented in exactly this tone — measured, considered, slightly defensive — at least forty times before. The date was wrong forty of those times. She is already doing the mental arithmetic for her own planning: take whatever James says and add eight weeks.The engineers know the date is wrong. The one sitting closest to the door — her name is Fatima, she has been on the project since week one — privately believes the project is at least sixteen weeks from completion. She has not said this out loud because the last time she said something like it, in a retrospective three months ago, the conversation became uncomfortable in a way that took two weeks to fully dissipate.The Scrum Master knows the date is probably wrong. He is twenty-six years old and this is his second job and he has not yet developed the vocabulary to say so in a way that will be heard rather than dismissed.The product manager knows the date is wrong and has already sent a Slack message to a peer in another department that says, essentially, don't count on October 14.Eight people in a room. Every one of them knows, to varying degrees and with varying specificity, that what is written on the screen does not correspond to reality. Nobody says so. The meeting continues. October 14 becomes the plan.This is not a dysfunctional team. This is a normal team. This is every team. This is the planning meeting that happens every two weeks at thousands of companies across the industry, in slightly different rooms with slightly different spreadsheets and slightly different versions of James and Miriam and Fatima — all performing the same ritual of false certainty that everyone in the room recognises as false and nobody has the structural support to name.Welcome to the casino. The Chips on the TableHere is what is actually at stake in that room.The October 14 date was mentioned to a customer in a sales call. Not committed to — mentioned, in the way that salespeople mention things when they are trying to close a deal and the prospect needs a rough timeline. The sales rep said "we're targeting Q4" and the prospect heard a commitment. There is now an enterprise contract in negotiation with an implied dependency on something in Q4.The October 14 date was included in a board update. Not the P50 from a Monte Carlo simulation — there is no Monte Carlo simulation. Just the number from the spreadsheet, presented as the plan. The board is making capital allocation decisions that touch this date.Two engineers were hired to help hit the October 14 date. They started three weeks ago. They are still ramping. They have, in the short term, reduced the team's throughput while they get up to speed — which is one of the reasons the last sprint came in below average, which is one of the reasons the Projected Completion column moved again.Fatima has been quietly considering a competing offer for two months. One of the things keeping her on the fence is that she doesn't want to leave in the middle of a project. The project, as represented by the spreadsheet, is six weeks from done. The project, as she understands it from the inside, is four months from done. If she knew the honest number, she would make a different decision about her career.The chips on the table are real. Customer relationships, capital allocation, hiring decisions, the career calculations of engineers who deserve accurate information — these are not abstract. They are denominated in money and time and trust and the professional lives of actual people.The spreadsheet is lying to all of them. What Velocity Was Supposed to BeBefore we go any further, let's be fair.Velocity was not designed to do this. The people who introduced it into software development were not trying to create a planning casino. They were trying to solve a real problem: how does a team know if it is moving at a sustainable pace? The original intent of velocity was as a team health metric — a rough signal, used internally, to help teams understand their own capacity and avoid over-committing. Not a forecast. Not a commitment. A pulse check.The corruption happened gradually and then all at once. Managers discovered that velocity numbers existed and requested them in status updates. Status updates became roadmap inputs. Roadmap inputs became commitments. Commitments became the basis for customer contracts, investor decks, hiring plans, and board presentations. The metric that was designed to help a team reflect on its own pace became the instrument by which that team's pace was judged, reported, and planned against by people who had no visibility into the assumptions baked into the number.Goodhart's Law arrived, as it always does: when a measure becomes a target, it ceases to be a good measure. Teams under pressure to maintain velocity learned to size stories generously. Generous sizing produced stable velocity numbers. Stable velocity numbers produced credible-looking spreadsheets. Credible-looking spreadsheets went into board decks. Board decks got funded.Nobody set out to build a casino. They built one anyway, one sprint at a time, one comfortable fiction stacked on another.The result is the room we described at the top of this chapter. Eight people. One wrong date. Everyone knowing. Nobody saying. The Gambler's PsychologyThere is a moment in a casino, familiar to anyone who has spent time at a card table, when the gambler knows the night is going in the wrong direction. The cards are cold. The stack is shorter than it was an hour ago. The rational decision — leave now, cut the loss, come back another night with a clear head — is obvious.The gambler doesn't leave.What keeps the gambler at the table is not stupidity. It is a set of cognitive mechanisms that evolved to serve humans well in environments that do not include card tables — and that malfunction badly at card tables, and at sprint planning meetings.The hot hand fallacy says: the last three sprints were good, we're in a streak, this momentum will continue. The gambler's fallacy says: we've had four bad sprints, we're due for a good one. Anchoring says: we told the board Q4, we have to make Q4 work, the original date structures all our thinking. Confirmation bias says: the burndown chart is actually fine if you interpret it the right way. Availability bias says: the one sprint that went smoothly is the one we keep talking about.These are not character flaws. They are features of human cognition that work well in many contexts and catastrophically in the specific context of software planning. They operate below the level of conscious attention. They run in the background while the intelligent, experienced, well-intentioned people in the room do their best to produce an honest forecast — and they corrupt the output anyway.The planning meeting is not a casino because the people in it are gamblers. It is a casino because it is designed the same way a casino is designed: to favour a specific outcome — the comfortable fiction, the confident date, the plan that ends the meeting — over the accurate picture of reality that would serve everyone at the table better.The casino is the architecture, not the people. What This Book IsThis book is for Fatima.It is for James, who is performing confidence he doesn't feel and deserves a better tool than the one he has. It is for Miriam, who has been adding eight weeks to every estimate in her head for fourteen years and would like to stop having to do that. It is for the Scrum Master who doesn't yet have the vocabulary. It is for the product manager who already sent the Slack message.It is for the engineers who have been told their velocity is too low and have responded by inflating their estimates — who know that this is wrong and do it anyway because the system gives them no alternative.It is not for the people who designed the casino. It is not aimed at dismantling the industry's planning mythology from the outside. It is aimed at the people inside the myth who can see it clearly and need both the analytical tools and the political vocabulary to push back.Here is what you will learn.Part II will give you the cognitive map of the biases that run the planning meeting. The hot hand fallacy, the gambler's fallacy, anchoring, confirmation bias, availability bias, survivorship bias — named, explained, and illustrated with specific people in specific companies making specific decisions that cost specific amounts of money. You will recognise these patterns. You have lived most of them.Part III will give you the statistical case. Not formulas — the concepts, in plain English, with the mathematics in an appendix for those who want it. You will understand coefficient of variation and why a CV above 30% makes velocity-based planning meaningless. You will understand fat-tailed distributions and why your disasters are ten times more likely than your model assumes. You will understand sample size and why eighteen sprints of data is not enough to support the confidence you're placing in it.Part IV will give you the tools. Monte Carlo simulation, explained well enough that you can run it in a spreadsheet by the time you finish the chapter. Sensitivity analysis that shows you scope is a more powerful lever than estimation accuracy by a factor of five. Bayesian updating that makes your forecast smarter as the project progresses rather than more defensive.Part V will give you the replacement system. Cycle time instead of velocity. Throughput instead of points. The probability roadmap. The pre-mortem and the designated skeptic and the forecast tracking spreadsheet. The five-component honest forecast and the three responses to "you seem uncertain."And it will give you the conversation — the one in the board meeting, the one with the CFO, the one with the customer who has a contract dependency on a date — done honestly, with confidence, armed with something better than a comfortable lie. The Only Promise This Book MakesThis book will not make software development predictable.Software development is not predictable. It involves human beings working on problems that have never been solved before, with tools that are evolving as they use them, in organisations that change around them. Uncertainty is not a bug in this process. It is a feature of the work itself.What this book will do is make your uncertainty legible. Nameable. Measurable. Presentable to a CFO without apology. It will show you how to tell the difference between the uncertainty that can be reduced — through scope management, team stability, batch size reduction — and the uncertainty that cannot, and must simply be accounted for honestly in the forecast.The teams that have made this shift — Priya Nair at Bridgeport Analytics, Cassandra Obi at Lakeshore Health Technologies, Robert Okafor at Thornfield Software, Daniel Achebe at Northgate Capital Systems — did not suddenly become better at predicting the future. They became better at describing their uncertainty accurately, and building planning systems that work with uncertainty rather than against it.Their stakeholders, initially resistant, eventually came to prefer the honest forecast over the confident fiction. Not because uncertainty is comfortable. Because trust built on reality is durable in a way that trust built on false certainty is not.The date on the spreadsheet says October 14.Nobody in the room believes it.That is not a planning meeting. That is a casino where everyone at the table knows the house is winning and nobody has said so yet.This book is the moment someone says so. Key TakeawaysThe planning meeting where everyone knows the date is wrong but nobody says so is not a dysfunctional exception — it is the industry norm. The room described at the top of this chapter is every room. The performance of false certainty is learned behaviour, not individual failure.The chips on the table are real. Customer commitments, board decisions, hiring plans, and the career calculations of engineers who deserve accurate information — all of them denominated in the date on the spreadsheet.Velocity was not designed to be a planning instrument. It was a team health metric. The corruption from internal pulse check to external commitment happened gradually and then all at once, one stakeholder request at a time.The cognitive biases that run the planning meeting are not character flaws. They are features of human cognition operating in an environment they were not designed for. Awareness alone does not fix them. Architecture does.The casino is the architecture, not the people. The planning system is designed — whether intentionally or not — to favour the comfortable fiction over the accurate picture. Redesigning the system is the intervention.This book is for the people inside the myth who can see it clearly. Not a dismantling from the outside — a toolkit for the people already in the room who need the analytical tools and the political vocabulary to push back.Uncertainty is not the enemy. It is a feature of the work. The goal is not to eliminate it but to make it legible, measurable, and honestly presentable — so that real decisions can be made on real ground. Coming Up NextBefore we get to the cognitive traps and the statistical failures and the replacement system, there is one question that deserves a direct answer.How did we get here?Velocity was a good idea once. It served a real purpose for the teams that invented it. Understanding exactly how it went from a useful internal calibration tool to the instrument of a planning casino — the corruption sequence, the specific decisions, the specific pressures that turned a team health metric into a commitment mechanism — is not just historical context.It is a warning about what happens to any metric when an organisation decides it is too useful to stay honest.Chapter 2 is the story of how a good tool became a bad one. It is, in miniature, the story of the entire book. Want to keep reading?The Gambler's Fallacy is available now on LeanPub in PDF and EPUB.You've just met James, Miriam, and Fatima. The rest of the book gives you everything you need to change the meeting they're trapped in — the cognitive map, the statistical tools, and the replacement system that turns false certainty into defensible, honest forecasts.Suggested price: $24.99 — or pay what you feel it's worth.Get the full book on LeanPub → © 2026 Theo van Stratum, PhD. All rights reserved. This preview chapter may be shared freely for non-commercial purposes with attribution.

Execution scales. Responsibility concentrates. As automated systems compress effort and multiply output, professional standing reorganizes around judgment rather than speed. This monograph examines how authority, accountability, and exposure shift when execution becomes infrastructure.

Change does not fail because of resistance. It fails because people lose clarity and ownership. Spiral Up gives you a simple framework to restore purpose, learning, and momentum at every level.

Change does not fail because of resistance. It fails because people lose clarity and ownership. Spiral Up gives you a simple framework to restore purpose, learning, and momentum at every level.

Većina problema u isporuci nije uzrokovana kodom, timom ili procesom upravljanja radom. Oni počinju uzvodno: načinom na koji zahtevi sazrevaju (ili ne sazrevaju). Ready uvodi Tok Sazrevanja Zahteva (RMF), sistem za kontrolu, razjašnjavanje i usklađivanje posla — pre nego što počne i bez menjanja vašeg frameworka. Ako vaši Sprintovi završavaju prenošenjem, doradama ili isporukom pogrešnih stvari, RMF je strukturno rešenje koje vam je nedostajalo.

A maioria dos problemas de entrega não é causada pelo código, pela equipe ou pelo processo de gestão do trabalho. Eles começam lá no início (upstream): na forma como os requisitos amadurecem (ou não). O livro Ready apresenta o Requirements Maturation Flow (RMF), um sistema para controlar, esclarecer e alinhar o trabalho — antes de começar e sem alterar seu framework. Se suas Sprints terminam com tarefas reportadas, retrabalho ou entregando algo diferente do esperado, o RMF é a solução estrutural que você estava precisando.

A maioria dos problemas de entrega não é causada pelo código, pela equipa ou pelo processo de gestão do trabalho. Eles começam a montante: na forma como os requisitos amadurecem (ou não). O Ready apresenta o Requirements Maturation Flow (RMF), um sistema para controlar, clarificar e alinhar o trabalho — antes de começar e sem alterar o seu framework. Se os seus Sprints terminam com trabalho transitado, retrabalho ou com a entrega da coisa errada, o RMF é a solução estrutural que tem estado em falta.

大多数交付问题并非源于代码、团队或工作管理流程。 它们始于上游：源于需求的成熟（或不成熟）过程。 Ready引入了需求成熟度流程（RMF），这是一个用于关卡控制、明确和协调工作的系统 — 在工作开始之前且无需改变您现有框架。 如果您的冲刺总是以工作结转、返工或交付错误内容而告终，RMF就是您一直缺失的结构性解决方案。