I was involved in a wee little exchange on ye olde Twitter social medium over the weekend with @dcancel and @pt in which I said I didn’t like certain aspects of Scrum (which, by the way, is a software development methodology). I was asked to elaborate.
I think Scrum has a lot of good aspects. I’ll go a step further and say that for most startups and probably most software projects, Scrum should be your default. You should be required to make a case for not using it before moving to something else. However, there are two effects of Scrum that I don’t like.
Most importantly, I think Scrum does have a chilling effect on innovation. Common symptoms of this are people saying things like “Stick to what is in the sprint” or “That’s a super idea – put it in the backlog and let’s consider it during our next planning meeting.” Innovation and creativity don’t respond well to statements like this. They appear suddenly and without warning and are opportunities that you must seize and run with. Damn your plans. Scrum is part of a family called “agile methods,” and, by comparison, it absolutely is. Well, maybe sometimes it just isn’t agile enough. But I guess it depends on what you are optimizing for.
The second thing that I don’t like about Scrum is that if you have a highly functional team that is cranking, applying Scrum to the chemistry of your team will absolutely slow things down. As lightweight as it is, there most certainly is overhead involved. Perhaps there are other benefits of having Scrum in place, but speed isn’t one of them. That being said, Scrum can be fairly lightweight and is probably the most responsible choice you can make in the face of actual methodologies that you can, say, buy books about.
Now, what do I like if it’s not Scrum?
I like goals. The objective of a sprint (using Scrum parlance) is to complete the specified work. Hopefully that maps to your overall strategy. Hopefully that makes your goals a few steps closer than before. The reality is that reaching your goals are the most important thing, not necessarily how they are achieved. If you want to boost conversions, increase registrations, reduce latency, etc., it’s way better to stick with a few key numbers that you can measure against and simply chase those until you’ve moved whatever needle you are measuring. It is very frequently the case that you will have no idea what will end up working for you in terms of actual tactics. But the ability to make guesses, learn, retry and iterate is going to get you there. Sticking to a plan and realizing halfway through a sprint that things are Not Going Well is not going to lead to the desired outcome. And constantly changing the composition of a sprint makes the whole process seem very flimsy.
But Scrum is just a hammer in your toolkit. Choose it for the right job and it can be very valuable (yes, really!). If you adopt it during a phase in your company’s lifecycle when you are trying to focus on innovation, consider yourself warned.
Do you have techniques to make Scrum work better in an environment that requires innovative thinking put into practice?
