Your manager just asked why nothing is closed on the board. You shipped auth this sprint - tests, PR, QA walkthrough. But the parent ticket moved to QA, it is off your name, and on the dashboard it looks like you did nothing.
That is Agilefall: Agile in name, Waterfall in practice. Your team has sprints, standups, and story points. It also has a QA phase at the end of every sprint, a capital budget that locked scope in October, and a roadmap your team did not write. You are not failing at Scrum. You are playing a different game.
Surviving Agilefall is not another book about implementing Scrum correctly. It is a field guide for Monday morning in the company you actually work for - written from 30 years inside enterprise teams where Agile was the official language and October's capital plan was the real one.
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 negotiate inside that cycle.
- Move the needle incrementally when you will not transform the enterprise this quarter - and why that is enough.
The book includes a scored Agilefall diagnostic you can run with your team - questions that map exactly where your hybrid stands and which friction points to address first. Add dual-board workflow tactics, handoff discipline, 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 call themselves agile while demanding waterfall predictability. If your retros repeat the same action items, your velocity is ignored at planning time, and your sprint board is a graveyard of overcommitted stories - you are 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.
Stop drowning in process. Start shipping software in the environment you have.
