Scrumfall

A while ago in a company I worked for I noticed something strange. We were doing all the ceremonies of Scrum with the sprint plannings and retros and so on, yet we seemed to be moving intolerably slowly. Everything took forever to get to prod and was often not in good shape by the time it got there.

Looking up into the management layer, executives and board members were wanting to know what we were dropping over the next few quarters, what big splash features we planned to implement, and how they would attract further investment. Yearly roadmaps were diligently created and shared with stakeholders. Sales would, of course, promise features if it meant getting a deal signed and suddenly that roadmap included customer commits.

What was agile about any of this? Management was working in waterfall manner while engineering was trying using scrum and the two were just not gelling at all. The tight feedback loop offered by scrum was largely ignored and any feedback was backlogged as the roadmap had been promised so we had to move on.

I called this ScrumFall (only slight 007 vibes). We were going through all the time-consuming, mind-numbing process of scrum without any of the benefits it offers in return. It turns out that if you want to work in an agile manner then everyone has to be on board. Right up to those on the board. Management has to be tolerant of the vague delivery timelines associated with agile and the shifting nature of what is actually delivered.

Not all companies can operate this way and that’s fine. Scrum is not a one-size-fits-all tool and there are places where it just doesn’t fit. I personally think it is best suited for small startups that are trying to get to market and can pivot and shift as required by their user base to gain market traction. Once the company is an ongoing concern leadership tends to want more predictability which is at odds with the agile way of working.

It is important to understand when the process is not working for you and move on. Find your way of working that suits your team and your business. In this particular case, we chose to ditch scrum and moved into a way of working where teams estimated and then executed projects within a timebox to prevent the project from becoming a runaway. The timebox was set based on the team’s estimate and we tried to keep the deliverable scope small so we could deliver frequently.

Don’t be afraid to exit a way of working that isn’t … well … working, even (especially?) if its the latest and greatest.