It's a bit of a pity that the waterfall model of software development is out of fashion, not? But maybe it's possible to tweak scrum/agile development to be almost like waterfall? What would be necessary?

First, introduce cycles and milestones to more or less replace the continuous delivery. Adult supervision requires setting goals. It's okay to run CI tools, as long as you have at least a couple of future magic dates, call them next step along the waterfall and final arrival at the ocean or call them internal/partner alpha launch and public launch date.

Do it right instead of the continous improvement. The waterfall model says that it's cheaper to fix bugs earlier, so do it right once and it'll stay right. This too is simple to integrate into Scrum, just boost the code review and pre-implementation consultation. Talk about how important it is to have the right design and to avoid technical debt. Make technical debt seem worse than the many other kinds of software deficiencies. With luck noone will notice that Scrum is being hollowed out.

Deemphasise the product owner. The waterfall model doesn't have a product owner. But it's quite simple to have a daily standup meeting even if the product owner is mostly blocked by another meeting.

Stories are key to the agile process, but they're not quite what responsible adults prefer. Playacting and roleplaying and foo. So forget to concoct stories at the start of each sprint. Mostly the product owner does that, so if you allow the product owner to fade out this may happen effortlessly.

Clear, well-defined goals is one thing agile programming doesn't have. The goals in an agile process are to have a happy product owner and deliver on tiny stories often. So to make scrum be like waterfall, try to introduce clear goals.

Longer-term focus. Something must replace the product owner, and that's the Plan. The goals, the delivery date, the milestones, the final product to be shipped or deployed. You can have occasional meetings to make sure the sprints don't add digressional features and that the product is approaching the declared goal.

Do all this, and you can have implemented the best waterfall development process in history, with both agile bugfixes and a stately procession of thoroughly planned features. Actual agile development would give you a good product instead of a well-planned one, but who am I to denigrate well-planned software?

The daily standup and periodic sprint planning in Scrum expose ideas to more people. There's more chat about things. Methodic code review pushes in the same direction.

That has many good effects. One which may not be so good is that dubious features are easily killed before they're implemented, or rejected when the first part is reviewed. Sometimes that makes me unhappy.

Dubious features are Schrödinger's cats: They can be anything from damaging to insanely great.

Insanely great features are insanely great in hindsight, but the ones I've written weren't great in advance, and I fear most of them wouldn't have passed the Scrum process. It's so easy to say no and concentrate on the sprint story. An answer like write it and see, we can always ditch it afterwards isn't in the spirit of scrum.

I suppose that's no bad thing, overall. More deadlines met. But fewer inspired features.

Now that we have two children, the daily routine has grown even worse. So we've adopted cross-paradigm best practice to manage and control complex projects, on-budget and on-time, improving parent/child satisfaction matrices.

We've adopted scrum. (more…)