Scrum – An Agile Project’s Best Friend

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