Surviving Agilefall

When your company does Agile, except not really.

Your team has sprints, standups, story points, and a Jira board. It also has a QA phase at the end of every sprint, a capital budget that locked scope months ago, and a manager who needs exact delivery dates on work that is not estimated yet. That is Agilefall: Agile in name, Waterfall in practice. And it is everywhere.

Surviving Agilefall is not another book about implementing Scrum correctly. It comes from decades inside the messy middle: enterprise scale, sprint planning that is really scheduling theater, and the week your manager wonders whether you have been doing anything because your finished dev work vanished into QA's queue. This is a field guide for Monday morning in the company you actually work for.

You will learn how to:

• Keep your work visible when tickets leave your name the moment they hit "Ready for Testing" - so mid-sprint reports stop implying you did nothing.
• Survive estimation on two tracks - story points for the team, days for finance - without pretending they measure the same thing.
• Commit to sprints realistically when scope and dates were fixed before you saw the backlog.
• Partner with QA instead of fighting over rollover, velocity, and who broke the board.
• Manage up without selling out - including how not to win an argument and lose three years of career (a lesson paid for in public).
• Understand the budget trap - why October's capital plan becomes January's "agile" roadmap, and how to work inside that cycle.
• Move the needle incrementally when you will not transform the enterprise this quarter - and why that is enough.

Along the way you get an Agilefall diagnostic you can score with your team, tactics for dual-board workflows, and dry humor that sounds like a senior developer venting to a friend who has seen it all before. The preface is honest about limits: you will not fix the organization alone. The epilogue is honest about hope: a real project where the process actually worked, under real pressure, when the conditions finally aligned.

Who this book is for: developers, tech leads, and engineering managers in organizations that say they are agile while still demanding waterfall predictability. If your retros repeat the same action items, your velocity is ignored for planning, and your sprint board is a graveyard of overcommitted stories, you are in the target audience.

Who this book is not for: coaches selling a clean agile rollout, or teams already living the manifesto without compromise. If that is you, please write your own book.

Perfect for readers of Agile Anti-Patterns who need Monday-morning survival tactics, not another rollout deck, and for fans of The Unwritten Laws of Engineering who want sprint-specific vocabulary for the hybrid you already live in.

Surviving Agilefall is drawn directly from teams that were absolutely doing Agile and also somehow never were.

Stop drowning in process. Start shipping software in the environment you have, while you nudge it toward something better.