Keep waterfall out of your agile

An insightful thing my pal Brandon Hays observed is that teams introduce little bits of waterfall into their agile processes when they get burned by scope expansion, bugs, infrastrucure, and such.

It’s tempting to try to eliminate potential sources of surprise and drama. Paradoxically, adding waterfall-style checkpoints seems to introduce more drama and surprise than it prevents. In my experience, checkpoints introduce bottlenecks and hand-offs that reduce the speed and quality a team produces software.

Instead of reinventing waterfall within an ostensibly agile process, I’ve found its better to note all the things that have surprised and caused drama. Consider if those are due to consistent conditions in your team. If they’re systematic, fix them. That is, do agile retrospectives.

If it’s not systematic, take a dose of optimism and keep going. Thoughtful, capable teams have a sense for the conditions that yield unpleasant surprises. They don’t need waterfall-esque checkpoints and documentation to avoid them. In my experience, they’ll tell you what they’re worried will bite them later. Just ask!