Scrum-but and Agile anti-patterns
There are many stories and anecdotes about Scrum-but and agile anti-patterns. If you’re wondering about the term, it comes from the idea “we’re doing Scrum, but we” [do something that is completely the opposite of what it says to do in Scrum]. Here are some common ones to look out for.
Big up-front design
“We do scrum, but we do a big up-front design”. This one is very common, especially in organisations doing “Scrum-fall“, i.e. Waterfall but with a bunch of iterations in the Build phase. Now there is actually nothing wrong with some initial architecture, especially if done mainly in the form of exploratory coding, spikes, etc. You don’t want to lock down all your designs initially though. Break things into chunks, and design and build each chunk in order, instead of designing all the chunks first. Designs often need to change, so do them as you go.
Big releases
“We do Scrum, but we release every six months”. Another common occurrence in large organisations trying to go agile. There’s not much point doing one-week iterations if you release twice a year. You’re supposed to have a potentially shippable product at the end of a sprint, but an emphasis on the “potential”. If you’re not doing frequent releases, you can’t do Build Measure Learn, you can’t do DevOps, and you’ll be slow to respond to feedback.
Big user stories
“We do Scrum, but we have big user stories that cover all the use cases”. This is an easy one to avoid. User stories should be very small, ideally able to be completed in a few days, or even less. I once did a “carpaccio” exercise in some Agile training where we had to build software in sprints of three minutes. True story.
Lots of signoffs
“We do scrum, but we have to make sure everything is signed off, so it doesn’t keep changing”. The whole concept of “sign off” is stupid, and a lingering stench of Waterfall mindsets. I’ll write more about this later. UX can often be guilty of this. (Did I just say that?).
Lots of handovers
“We do scrum, but we have separate teams that are specialists in their field, and they hand over work to each other”. We’re supposed to have cross-functional teams; I wrote about this topic in more detail here. Handovers are a form of waste, introduce risks, and should be removed whenever and wherever possible.
Should we worry about Scrum-but and agile anti-patterns?
I’m not saying that every team has to follow the Scrum book to the letter. I don’t think it is helpful to be a “scrum nazi”, especially with teams new to Agile. Bashing people over the head with the Scrum guide every half hour is not a good idea. But I do think teams moving from waterfall to Agile should adopt it properly first, then try and experiment with it once they’ve got the hang of it. Doing something different to the canon is good if you’ve thought of a cool experiment or are looking to implement continuous improvement; doing it because you can’t get away from your old bad habits is not so good.
