Scrum is not web friendly

tl;dr Do it properly, or get rid of it.

Ask different developers how long a scrum should be and you’ll get lots of different answers. That’s because there isn’t an ideal answer, but, there isn’t really a solid set of guidelines to discover what that answer should be. The only way to do that would be to be able to accurately predict how long each ticket will take in any given sprint. Anyone who has spent enough time doing estimations for tickets will know it’s more akin to art and guesswork than science. When somebody uses methods, such as gut instinct times two plus some percentage, it’s safe to say that it’s the wild wild west of planning. So if we can’t rely on our ability to provide accurate planning, we can at least make it easier by chopping up bigger jobs into smaller, more manageable tasks. This gets us some way there, yet only the most positive-thinking person would believe that this would lend itself to allowing the same amount of work, for the same amount of man-hours, from one sprint to the next.

The web is an ever-changing playing field, with updates taking place every minute, and yet, somebody introduced the idea that it’s better to wait anywhere between two and four weeks for an update. There are a couple of things wrong with this; why wait more time when you have a single new update or feature that’s complete and ready to go live? It’s crazy to have that hidden from the end user making zero impact. Also, the more changes that you release at any one time, the more things that can go wrong at any one time. By releasing a new feature or update as soon as it’s ready, it’s much easier to manage any problems that come along with that, and by adding value at a much more incremental pace, your application feels more organic and is easier to manage and reason about. The other elephant in the room is bugged. I’m not aware of any environment where it’s better to wait for a bug-fix to be released at the end of some pre-determined time span.

Sprints are a good idea for managers and paper pushers, but they are not good for a modern web application that lives and dies from one day to the next. The original idea behind scrum was to provide an environment where teams could stick to a plan over a typical two week or more period. But two weeks for a web application is an eternity. Some people will argue that scrum and continuous deployment can co-exist, but it’s not a natural fit at best. Others will argue that one-week scrums can be a thing, negating the retrospective and planning for the next sprint. Planning and prioritisation are moving targets, even without bugs in the wild, so, continuously plan, and continuously deploy.