Most people hear the word “Scrum” and think of something that’s stuck to the bottom of their shoe. Au contraire. Scrum is an agile software development methodology designed to foster iterative and incremental development. Scrum projects are broken down into 24-hour development cycles contained within 30 day sprints. Team members agree upon which work items for the product (the product backlog) they will tackle in the next 30 days; this becomes the sprint backlog. The goal at the end of 30 days is to have a working application with a certain number of features completed.
I’m a huge Scrum acolyte. On many teams, this makes me a minority of one. I’ve been on several teams that have used the Scrum project management methodology for both software development and technical documentation production. In each case, the backlash against Scrum was so great that these teams eventually abandoned it in favor of that tried-and-true methodology called “Whatever We Were Doing Before Scrum.”
What is it that makes teams resistant to Scrum? In my experience, there are three major blocking points. The good news is, none of these need be fatal. Teams can – and should! – adjust Scrum to meet both the needs and temperaments of their members.