There‘s a book (I haven’t read) called If You’re So Smart, Why Aren’t You Happy?

My riff in it for software is “if you’re so smart, then why don’t you ship?”

Most teams in software think they’re above standards SDLC practice. They’ll adopt the easy stuff (sprints, ceremonies, etc), but make bizarre changes to “suit the needs of the team”. Just today, a principal engineer suggested 4 week sprints, with the first week reserved for planning. This, he says, is perfect for us, because it gives us the space to figure out what we’re doing.

This is supposed to help us reliably commit to work and deliver it on time. No other changes to how we intake projects or refine them or decompose them or assign them. We‘ll just tweak a couple of variables. Compress all the refinement into one week, and tack an extra week into the working time.

I’m a scrum purist. Or a Shape Up purist. Hell, I’d even get behind waterfall if we followed the methodology to a T. I think I’m pretty smart, but I’ve learned that I’m not smarter than a coherent SDLC methodology. Your company is not going to win because you have a novel way of delivering software.

The best teams I’ve worked with live and die by the book. Except that they don’t die, they just reliably deliver high quality software, then go home to live in bliss, because they didn’t spend all day trying to untangle whatever mess their newfangled project management system got them into.

Like every other team that does this, we’ll try it out for a couple of months, realize it isn’t working, and chalk it up to “learning as we go”. But god forbid someone suggest that we just follow the handbook. That’s just not going to work for us. We’re different. Our team is special.

To which I say, “if we’re so smart, why aren’t we happy?”