And when I say you have no idea what the costs will be – without estimation other than a WAG each morning you can easily find yourself doing the highest priority task every day for your customer.. doing the right thing.. and at the same time burning through their budget like a forest fire.
I’ve seen a large software project that pivoted wildly every week – and spent millions with nothing to show for it. But, hey, it was a tax write-off for a billion-dollar company; NBD.
SCRUM IS JUST SHORT BURSTS OF WATERFALL
This usually prompts comments from the theoretical PMP crowd, and I’ll leave you to ponder articles like A Sprint is Not a Mini Waterfall if you really care about semantics. I’m no accredited PMP, I’ve just seen a lot of software being made.
To me, and most developers, waterfall simply means you have a complete definition up front, and you can build it without distraction from requirements changing.
So, just like a Scrum sprint then.
The obvious advantage is that with more definition you have more estimation and are more likely to hit your date. Not 100% likely of course, but we’re in the same ballpark at least.
With sprints – or short waterfall projects – the customer needs to be highly responsive, but only during the initial planning phase. Less so during implementation, because the requirements are frozen.
Which you choose depends on your priorities and your culture. I’ve met developers who prefer a customer who pivots regularly, and others who want stability and change freaks them out. Hire them into the wrong environment and you’ll soon know.
EVEN WITH SPRINTS, SHIT HAPPENS
No changes during sprints is a great policy – until you have to make one.
Even product companies have to respond to high-level-interrupts. Everyone had better take it seriously when the CTO of your biggest client calls your CEO. Or your top salesman is sitting on a potential seven figure deal that needs an answer.
We’re all in this to make money.
(ASIDE: Make no mistake, we’re there to make the company more money than we cost. I’m all for perfect process and rules, but pragmatism is #1.
I’ve said this to many developers – until you’ve built and run your own company and paid a mortgage with the profit, you don’t really understand why sometimes you need to write second-class code or take a shortcut with process)
Anyway, to get back on track – when interrupts come, how do you manage them? Communication of course – Tell Them Everything.
Do you have a Change Control Board? Yes you do! If not a formal one, your VP/CTO/COO/CEO is your CCB.
So, tell them (all of them) immediately what the effect will be. What’s the cost and other consequences such as timeline?