Why I really love SCRUM
We've been using scrum all over the company for the past year, and the more I use it, the more i love it. I previously wrote a blog about using the scrum agile development methodologies in a non-development capacity -- i.e., with a sales or marketing team. I got a lot of questions from that blog about exactly why Scrum was so great, so in this post my goal is to tell you why I love Scrum so much, and why I recommend it to be adopted within any company (and if the US Government ever implemented Scrum -- correctly -- we'd seriously save trillions of dollars. That's probably an impossible wish, but after all, thinking big is free.)
Here's a good 7 minute video describing Scrum. If you're not at all familiar with the methodology, you might want to read my case study below before you watch the video -- it'll make more sense that way.
Video: Scrum in 7 Minutes:
Scrum Case Study:
Here's a real-life example of why scrum is so amazing. The Socialize marketing department uses scrum to prioritize projects and tasks. Here's how we do it:
Awesome Reason #1: "Hey, wouldn't this be cool" How often do you hear someone in your company have an idea of something that "would be cool" to do? The idea may, in fact, be the coolest ever, but where do those ideas go today? Do they get recorded somewhere? Do they get lost with a dismissive "yeah that would be cool"? How do you prioritize all those cool ideas? The first absolutely enormous value of the scrum agile methodology is that it gives all these cool ideas a home. That home is called the "icebox." The icebox is a place where ideas can be placed by anyone in the company who has access to the scrum project. We use and love Pivotal Tracker to track our scrum projects and I suggest you do the same. It's the best scrum software I've found to date (I'm happy to hear about others in the comments, though). Here's what the icebox looks like (right-side of the Pivotal Tracker screen)
(In the image above, i've blurred out sensitive information but kept as much unblurred as possible).
Now, whenever anyone in your company has an idea, just have them put it into the icebox. This can be accomplished directly in Pivotal Tracker, or with a great Mac dashboard widget that I use constantly to drop stories right into the icebox for review during the sprint planning meetings. In this way, you're divorcing the idea itself from the prioritization of the idea.
I should also define what a "story" is, because that term is used all the time. A story is a project requirement that's given from the perspective of the stakeholder. What that means, really, is that a story is told in a way that adds value. Instead of "build widget," as a requirement, a story might be "The customer must be able to use a widget to change the color of a picture without having any programming skills." It is, literally, a mini story that describes what has to be done in plain English. Mike Cohn has a great template that a story be written as "As a [end user role], I want [the desire] so that [the rationale]".
Awesome Reason #2: Meetings: The way scrum teams also interact is different from what you might be used to. Where normally, you'll schedule meetings in an ad-hoc fashion to go over progress in a project, scrum projects have a very structured meeting schedule: A planning meeting at the beginning of each sprint (a sprint is a cycle which repeats and can be of any length -- we typically do one week to two week sprints depending on the department) can last several hours and encompasses the entire team. It's where the project (or product) owner moves ideas out of the icebox and into the backlog based on the project's requirements. It's also where the project owner prioritizes the backlog so the most important tasks are at the top of the backlog. Then there are quick (15 minutes or less depending on the size of the team) daily stand up meetings (yes you should really stand up -- meeting ends faster that way) between the project team members where everyone gives a progress report.
Awesome Reason #3: Think for Yourself: So the first two reasons I love scrum are awesome enough, but here's there the methodology really shines: As you can see from the screenshots above, there's are icebox, backlog, current and done categories. A story moves from right to left as it gets completed -- it starts in the icebox and then gets moved to the backlog based on prioritization. But here's the beauty: From that point forward, the actual developers (or those doing the work if not developers) hit "start" on a story and get the work done, and then hit "finish" when they think it's done. They can make notes in the story about the work they did. Team members get to pick the stories they work on based on prioritization. Say someone only has an hour to do a chunk of work -- s/he simply chooses to start a story from the backlog with a lower point score, indicating it's an easier block of work to finish in that time period. In this way, those doing the work get to think for themselves instead of having tasks mandated by a project manager.
Once the story is marked as "finished," it gets kicked over to the project owner to accept or reject. If the story looks good, it's accepted, and if not it's rejected, moving the story back in to a "restart" status.
This is what makes scrum so special -- it's an asynchronous way for teams to work and collaborate together incredibly efficiently, without worrying about the element of time, because the time is set in a sprint cycle. The time might be, say a 2 week sprint, and so the most important work is always prioritized at the top of the backlog to be worked on. So instead of asking "when will this project be done?," you can start looking at the number of stories left in the project, and you'll know that the stories that matter the most to you as a project owner are being worked on first, so the most important work always gets done first. Another way to look at this is to consider the fallacy of arbitrarily picking a "project completion date" at the beginning of a project. A body of work will take as long as it takes -- nothing will change that. Picking a fictional completion date will not make work get done faster. Instead, the important thing is to prioritize the project such that the most important work gets done first.
Awesome Reason #4: Stop Interrupting Me: Even the best laid plans go to waste when unexpected roadblocks pop up, and oftentimes those roadblocks are caused by internal team members within the company. Although the project owner is the one defining the requirements of the project, each scrum team has a scrum master whose job it is to remove impediments from the project succeeding (i.e., keeps everyone productive). Part of this is also keeping the project owner in line. Oftentimes, a project owner will want to redefine requirements half-way through a project. Scrum deals with this by keeping sprint cycles sacred and uninterrupted-- if the project owner wants to make a change, it goes into the icebox (just like everyone else's ideas), to be re-prioritized at the next planning meeting. The key here is to keep sprint cycles short enough so that feedback and business prioritization changes can be incorporated into the next sprint, while making it long enough so that meaningful work can be accomplished. The team members will relish this "walled garden" approach where a project owner can no longer walk up to them mid-cycle and make a bunch of unanticipated changes.
I'd love to hear your rants & raves on scrum -- we've been using it a year and I'm sure there are those of you out there who have a lot more experience with it than we do. And if anyone wants more detail on how we use scrum, just post a comment below -- if I get enough interest, I'll interview some of our key team members to capture their thoughts, too.