Scrum – An Agile Project’s Best Friend

Tweet

In an earlier article I wrote, we took a general look at project management and discussed what some of its pitfalls are that should be avoided. As part of that, I mentioned that you should, as much as possible, be using an Agile methodology, particularly Scrum, to manage development. I’d like to follow that up with a look at Scrum and at how we can use it to tame our projects.

I Know Everything, and Another Way to Think

-

Most project managers think they’re responsible for anticipating everything beforehand and laying out a complete road map of what must be done, when it will be accomplished, and how much it will cost before the project begins.

And if that statement isn’t true, then this one certainly is: most management people feel that project managers are responsible for anticipating everything beforehand and laying out a complete road map…

And so, either because of their own beliefs or the beliefs of others, most project managers give it their best shot to completely spec out everything before the start. But what happens when things don’t go according to plan? Well, obviously, the project manager is to blame. He didn’t anticipate everything. She didn’t give this enough thought. They are to blame. Hey, someone, get some rope. Where the heck is the bucket of tar we had yesterday?

Of course if we look at this with just a modicum of reality we know that it’s not possible to know everything that will happen with a project, especially since every project’s future is a moving target.

The mistaken notion that we can anticipate everything by thinking really hard is an outgrowth of the early 20th century movement to quantify all business activities as steps in a repetitive job, which in turn was fueled by the 18th and 19th century mathematical belief that everything was deterministic. I can’t remember who said it (and God knows I’ve tried looking it up), but “give me the initial conditions and I will predict all future acts” or something like that.

The truth is we can’t predict the future and we can’t anticipate everything. So why try?

At the same time, and using the same logic, the purpose of project management is not really to get things “done” by some prearranged time, but to get done when we’ve reached some prearranged goal. Yes, getting things done on time and within budget is a good thing, but it’s not the only thing. How may top management officials would trade a successful project (one that does everything you want it to do and is useful to everyone) that’s a month over due for one that’s on time but is only partially what was really wanted?

Projects cannot be realistically laid out in a deterministic fashion where everything is known up front and its a matter of keeping people’s noses to the grindstone. Life just isn’t like that. Software projects are slippery creatures, prone to changing shape and size, and there is only one way to deal with them – approach them iteratively. Do a version and see how it looks. Then refine it and see how it looks. We keep doing this until everyone says “yeah, baby, that’s what I’m talkin’ about.”

And Scrum Fits Into This How?

Agile is a project management technique that does not assume we know everything at the start. It doesn’t treat software projects like building a highway or bridge, but rather as something where uncertain things can happen. If there’s a central theme to Agile it is this: pay attention to today, to what you are doing, and what you didn’t do. Take care of the pennies and the dollars will take care of themselves.

Scrum is a technique for carrying out Agile development. Everyone seems to think of Scrum as a meeting, but it’s more than that. Scrum sets up a structure, provides a communications protocol (the daily Scrum meeting), and defines a way to measure and view progress (the burn down chart).

Scrum has it’s own vocabulary, different from other project management methodologies. Projects are referred to as “User Stories”. Specific tasks within the user story are called “Story Points”. An iteration is called a “Sprint”. The project manager is the “ScrumMaster”. The project owner is called the, uh, “Project Owner” (okay, so not everything is different).

The most well known part of the Scrum lifestyle is the Scrum meeting – a short daily project meeting which focuses on what is right in front of you.

People who understand Scrum will say this is no different from a waterfall-type project meeting, but I disagree. Sit in on any waterfall project management meeting and almost all of the time will be spent either talking about something that may or may not happen in the future or who is responsible for doing a particular task that has suddenly surfaced. It’s focused on the end of the road and things that nobody foresaw. And these meetings literally exhaust the project team; no work is done before the meeting because everyone dreads it, and very little is done after because everyone is tired.

The focus of Scrum is on the now, right this minute. What have we done in the past 24 hours? What are we going to do in the next 24 hours? What problems are you having? What is your best guess on how much longer the current task will take?

How to Scrum

Scrum is not complicated, but neither is it trivial. This article is not intended to be a tutorial on “going Scrum” but rather to get you interested in digging into it a bit deeper. For more information, I recommend starting with the excellent 10-minute video on the Axosoft website. There are some other references there that that you can follow, and Axosoft offers some excellent information on how to Scrum. But briefly, here’s some points to get you started:

Hold Smaller Meetings

By it’s very nature, a traditional project meeting covers a wide range of topics, many of which are future oriented, which are talked about every week and represent problems that either never materialize or else show up in a different form. With so many people involved, there turns out to be many variables involved, many different opinions about what should be done, and many topics brought up that only tangentially touch on the issues at hand.

And that is the way it should be. It’s a stinkin’ project management meeting. Everyone who has a stake in the project is invited so they can’t testify against you during the trial (that no one listed to them). By it’s very nature, it’s wide ranging and not focused.

Daily Scrum meetings, on the other hand, limit the people in attendance to those who are doing active tasks and the project owner. They should be short – no longer than 15 minutes – and stay sharply focused.

Limit Scope and Time Frame

We only talk about the important things in a Scrum meeting: the things that are happening now, the things that will impact tomorrow. But isn’t limiting the time frame and scope of issues closing our eyes to the future?

No, because the future for Scrum is to the next iteration. We’re not waiting for a month to pass before implementation, to the start of user testing to let people get their hands on things. Our horizon is the completion of the iteration, and the only thing that matters is how well we’ve used the past 24 hours to meet this goal.

Every Scrum meeting should be focused on real accomplishments; when will we be ready to dump something into the hands of the users that they can work with – not think about, but actually use?

Look for Feedback

We often look at user testing as something that sits almost outside of the project. But with Scrum, the results of testing are scheduled as achievable goals. When testing is done, it feeds information back to the project team.

But what if tests don’t feed anything back to the team? What if people just sleepwalk through it all? Well, Scrum doesn’t let that happen.

Scrum forces the proper effort out of tests so that rather than looking at potential problems as some future event, these problems become part of the next iteration, bringing them to the forefront much sooner than traditional project management would.

Constantly Rework the Time Remaining

In traditional project management, we decide ahead of time just how long it’s going to take to do something. But this is problematic at best, and some team members will go out of their way to hide any evidence that an estimate is not correct. The end result is that we get to the point when a task should be done and it isn’t and there was no warning.

Scrum asks team members daily to re-evaluate the time remaining on a task. This may be depressing sometimes, but it keeps things real and helps everyone see when things are beginning to get behind schedule.

Conclusion

What project could you have where worrying about what might or might not happen down the road is more important than looking at what is happening right now?

There are certain people of course who can’t do Scrum. Or, to put it another way, there are certain people who won’t do Scrum. They don’t want long meetings (or maybe they do, I’m never really sure) but they can’t let go of worrying about a future that they can’t control. Are you one of them?

Scrum espouses a belief that the best way to control the future is to make sure today turns out okay (followed by tomorrow, and the day after that, etc.). But some people just can’t dig it. And if they try to do Scrum they just screw it up; they call it Scrum but it’s really traditional project management.

For those who can use it (those who are willing to use it), Scrum is a tool that helps us focus on the only thing in this world that we can effect – today. And if all our todays fall in line, chances are our tomorrows are going to be fine as well.

Image via Fotolia

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://chrisoconnell.info Chris O’Connell

    It was Pierre-Simon Laplace who said, “An omniscient observer knowing with infinite precision the positions and velocities of every particle in the universe could predict the future entirely.”
    http://en.wikipedia.org/wiki/Physical_determinism#History

    • David Shirey

      Thanks! I should have known.

  • http://www.siliconrockstar.com Andy

    Wow, that was a freaking great article. I’ve always worked as a one-man-PHP-band and heard about Agile/Scrum but never had a team to use it with. Thanks to this article I just realized I can probably use a lot of the Scrum methodology to make my own projects flow more smoothly, team or not.

    • David Shirey

      Glad you feel that way (about using Scrum when you are the only Scrummer). I think there is a lot of truth to that. Scrum is not about having a team, it is about focusing on what you are doing now and setting frequent and realistic milestones.

  • David

    It certainly makes sense to break up one’s trials, errors, experiments and mistakes into smaller more immediate and less expensive chunks, making adjustments and corrections less time-consuming too. While the scrum analogy is interesting and even inspiring I would not be discouraged from occasionally advancing the ball by other means, running it with side-steps, dummy passes and the odd field drop goal. ;)

    • David Shirey

      Whatever it takes for a try!

  • http://www.squareflux.co.uk Tony

    I work on a project that has a number of product teams. Some use pure Scrum, some use Kanban. I’ve worked in both teams, and I prefer Kanban over Scrum. It feels less rigid in that you can start new stories if there is space, and you’re not all focused on the end-of-sprint date as the be all and end all. In my opinion, there’s also too many meetings in Scrum that last too long (Sprint Planning, Retrospectives, Backlog refinement). Scrum is good if you want to commit to delivering a certain piece of functionality, or a set number of stories within a sprint. But as long as the Work In Progress limits in Kanban are set at a realistic level, then it’s hard to over commit to doing too much in a sprint, and you still deliver a lot of functionality.

    • David Shirey

      This is an interesting comment. By itself, Kanban as a project management philosophy is pretty vanilla. It does not really proscribe any specific steps that need to be followed but instead emphasizes continuing the current work flow. Just as the Kanban manufacturing process is based on visual clues that the manufacturing process provides, so Kanban as a project management tool encourages the team members to continue to work on what they are doing. I am not sure I see it as being less intense in terms of the deadlines. To be honest, I have thought about this comment over the past week and will continue to do so. Thanks for your thoughts.