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.
At CC Pace, we've been doing Agile development in the private sector for over 10 years. In the last few years we have started to do work in the public sector as well. OPM has promoted Agile as the preferred approach for software development. I know there are of success stories in the Federal government. I recommend those that are interested in it to attend the Washington DC Federal Scrum Users Group meetings to learn more.
Kevin I'd love to hear of others using Scrum in non-development environments. You might also like this infrastructure talk the Socialize exec team did: http://go.GetSocialize.com/pull-back-the-cover
Hi Dainiel, thanks for the great post. Now that you know my other identity, a government worker I will share some insight into our public sector world. Also, I'm excited to see you mention the public sector in your blog.
A public sector developer I worked with in the past had scrum meeting each week. He hated them and my co-workers and I made fun of his scrum bag meetings. My point is, I think you have to have to whole team completely pumped about the scrum idea. (I can tell the Socialize team does, the amount of products you guys complete is impressive.) In my experiences most government workers aren't the most agile people. Does not mean I'm not going to try!!
Is anyone using Scrum across a marketing team and if so, how does this tie into your development Scrum process?
Thx Paul -- let me know if you hear of anyone using Scrum outside the developer community. I'd love to see it applied to different businesses, especially non-software product businesses. For example, Scrum would be great if applied in the public sector
And BTW yeah I agree 100% that it gives developers a much better environment in which to work. Removing arbitrary deadlines from projects reduces the stress level for everyone, while increasing productivity.
Beth good to hear from you! What do you like & not like about scrum? I'd love to hear your perspective.
We've been using scrum for a little over a year now, too, and it's really reduced our "overworked developer" syndrome. Another +1 for Scrum from me!
We've been using the Scrum agile development framework (or just "scrum") at Socialize since early this year. Hats off to Jason, our VP of Engineering, for really championing it and to Sean and Isaac for implementing it with the developers. Our workflow is to use Basecamp to discuss ideas (Basecamp is like Democracy: it's not great, but it's the best thing out there -- you can read my rants & raves about Basecamp here), then Github for issues & code repository, and Pivotal Tracker to manage our dev process. We do fast iteration cycles with one-week sprints, planning meetings every Monday and daily stand-ups to reconnect.
I'll explain what all that means below, if you don't already know, but here's the point of this blog post: Scrum has worked so well on the dev side -- what if it was possible to implement scrum across an entire company, including its non-development components like user acquisition, sales, even accounting, HR & finance?
We decided to find out. I'm going to write a series of blog posts with our experience implementing Scrum throughout our company, with a focus on the non-development parts of the organization, as I haven't really seen other companies do this yet. I figure this is a good opportunity to share our knowledge and learn from yours, so please post your experiences with Scrum, agile and general, and other workflow approaches in the comments.
In this first blog, I'll talk about what scrum is (at least to me) and show you a video of Jeremia, our developer evangelist, and Christine, our wordsmithstress, discussing the pro's & con's of implementing scrum in the user acquisition department (the first non-dev team we decided to test it with).
There are individuals within our organization that know scrum way better than I do because they're using it every day -- Jason, Sean, Isaac and our incredible developers, for example, and I'll invite their comments. Our goal is to institutionalize this agile mentality throughout the company.
We've been using the Scrum agile development framework (or just "scrum") at Socialize since early this year. Hats off to Jason, our VP of Engineering, for really championing it and to Sean and Isaac for implementing it with the developers. Our workflow is to use Basecamp to discuss ideas (Basecamp is like Democracy: it's not great, but it's the best thing out there -- you can read my rants & raves about Basecamp here), then Github for issues & code repository, and Pivotal Tracker to manage our dev process. We do fast iteration cycles with one-week sprints, planning meetings every Monday and daily stand-ups to reconnect. I'll explain what all that means below, if you don't already know, but here's the point of this blog post: Scrum has worked so well on the dev side -- what if it was possible to implement scrum across an entire company, including its non-development components like user acquisition, sales, even accounting, HR & finance? We decided to find out. I'm going to write a series of blog posts with our experience implementing Scrum throughout our company, with a focus on the non-development parts of the organization, as I haven't really seen other companies do this yet. I figure this is a good opportunity to share our knowledge and learn from yours, so please post your experiences with Scrum, agile and general, and other workflow approaches in the comments. In this first blog, I'll talk about what scrum is (at least to me) and show you a video of Jeremia, our developer evangelist, and Christine, our wordsmithstress, discussing the pro's & con's of implementing scrum in the user acquisition department (the first non-dev team we decided to test it with). There are individuals within our organization that know scrum way better than I do because they're using it every day -- Jason, Sean, Isaac and our incredible developers, for example, and I'll invite their comments. Our goal is to institutionalize this agile mentality throughout the company. So what is scrum, really? To me it's simply a way of thinking about getting things done. There are traditional development models like waterfall development, which (like a waterfall) takes a staged, or phased approach to development. I'm going to abstract "development" into "workflow" for the purposes of this blog, since we're talking about using these models in a larger sense throughout the company's divisions. The magic of scrum is that it takes time out of the equation. Or to put it another way, assuming you have employees that are dedicated and are working hard, things take as long as they take. You're not doing anyone any favors by setting arbitrary deadlines. "This project needs to be finished by Friday" or "This deliverable is due in 60 days" cause way more problems than they solve. When the team inevitably misses the goals, everyone is disappointed -- the goal setters blame those responsible for stepping up to an arbitrary date, and the implementers resent having a date put on them that didn't reflect reality. The scrum attitude is that things take as long as they take, so the best thing to do is embrace that reality and instead of setting deliverable-based goals, instead focus on prioritizing everyone's time effectively so the most important and value-added items are being worked on first. It's a very simple but monumental shift in thought. Things take as long as they take. Focus on what matters. Here's a video of Jeremia & Christine talking about implementing scrum in the UA department. In the next blog, I'll discuss some of the difficulties we've had implementing scrum in a non-development environment. >
Update: This is quite a long article. If you're looking for a quick read, it breaks down a bit like this:
Update 2: There are active and interesting discussions of this article on HackerNews and Reddit
I have a lot of love for Scrum, the software development process. I have my own little box of Index Cards and Sharpies, and I have sized Backlogs for many of my side projects. Scrum has potential to empower developers more than almost any other set of techniques.
But in almost every implementation of Scrum I've seen in The Real World™, managers are incentivized to help their team deliver broken software to a deadline, and usually end up succeeding in the former and failing in the latter. And when implemented like that, a system that should be an absolutely overwhelming win for developers becomes a tool to beat them around the head with...
So here's Scrum, simplified, and as it's meant to work: You have a Backlog of work to complete, broken down in to Stories, which are distinct pieces of work that should take a few hours to a few days to complete. These are frequently displayed on a Story Board, real or virtual.