This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Scrum-but – So What?
For the past couple of years, there has been a fun sort of “designation” for folks who want to do scrum software development, but not necessarily exactly as written. The saying goes “Sure we are doing scrum…but….we don’t do daily stand-ups.” At first, this seemed like a great, lighthearted way to point out that so much of the power in scrum is in the interplay of the various prescribed practices. Lately though, it seems that we are getting more involved in identifying who is the “most scrum” instead of concentrating on what interactions and practices will help us make the best software, in the timeliest manner.
I remember there were similar discussions in the early days of extreme programming. Lots of folks were saying XP doesn’t work. When asked which of the XP practices failed for them, they would invariably come back with an admission that the only one they tried was “no documentation”. So we often had to point out that if you didn’t try all of the practices, you really couldn’t blame XP if it didn’t work. This didn’t mean you were wrong if you didn’t use them all, you just couldn’t blame XP if it failed.
So where are we today? Do we really have to do all of the activities prescribed in scrum to have a successful agile development project? I personally have found that my teams have been more agile when they spent less time worrying about estimating tasks and more time developing software. I have seen other teams that really didn’t get much out of the retrospectives. So if I am able to adapt my teams’ plans to what makes them the most agile, and delivers the best product for our customer, does that make me a “scrum-but?” Perhaps it does. So what?