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.

Audiencing is something we do everyday. We do it all the time. In fact, we are so familiar with giving attention to someone or something how we audience and the types of audiencing we are do are invisible. This book makes visible four types of audiencing, and you will discover what it means to do each form of audiencing and why this matters. Playful popular quotes, academic research, and anecdotes from numerous fields of endeavour from computer programming to jujitsu, from movie editing to watching a friend play football, are all used to demonstrate the characteristics and challenges of each audiencing type. Audiencing presents a far-reaching concept and a useful language to see and understand ourselves as audiences in our work and study, in the arts, communications, sport, on the internet, and in our everyday lives as we audience each other. To discover more – audience on.

No One is Coming to Save You is your no-fluff guide to thriving in chaos. Forget trends and templates—this book delivers the essential human skills (“Power-Ups”) you need to survive and grow in an uncertain world. Straight talk, real stories, and practical tools from two people who’ve failed forward so you don’t have to.

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

What You’ll LearnHow to measure impact and effectiveness of working differentlyThe mistakes you can make around agility and how to avoid themMeasuring team agility at scale, agnostic of any chosen frameworkReal case studies and examples from practical application in large organisations, rather than just theory

You already know how to work hard. The question is whether you know when to stop.Most frameworks optimize effort. The Ishi Spiral governs it. It is a discipline of self-governance that sustains performance under pressure without drifting into burnout or grinding past the point where continuation is still justified. The Guide is the Companion to 'Ishi: the Discipline of Determined Intent'.

Hai mai sentito dire “facciamo gli OKR come Google”?Bene. Questo libro inizia proprio spiegando perché non dovresti farlo. Tra aneddoti, canvas colorati e qualche camicia hawaiana di troppo, scoprirai che gli OKR non servono a correre più forte, ma a capire dove vale la pena andare.

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.

Value Stream Mapping for modern software teams. Learn how to measure lead time, expose bottlenecks, eliminate waste, and build a delivery system where value moves efficiently from idea to production.

67% of "velocity improvements" are measurement artefacts, not real productivity. After analysing 112,000 Flow Items across 47 projects, I discovered why your team hits sprint goals while projects miss deadlines by months—and the actuarial framework that replaces hope with mathematics.

A group of farm animals must redesign their pigpen after a storm destroys it. Each animal represents a common organizational role or mindset — the visionary rooster, the cautious cow, the practical pig, and the reflective goat. Guided by an unexpected newcomer — a sparrow who has seen “adaptive farms” elsewhere — they learn how to build not just a pigpen, but a smarter way of working together.

Product teams are shipping more than ever. Outcomes are getting harder to explain. Roadmaps promise certainty. Backlogs stay full. Delivery speeds up. Yet value lags behind effort and learning arrives too late. The Operating System of Product explores why this happens and what replaces it. It shows how product work changes when execution is no longer the bottleneck and why roles, prioritisation and feedback loops must evolve together. This is not a book about better roadmaps. It is about replacing the system that needs them.