Project Management with Scrum

Successful project management is easy. Successfully executed projects have at least these 3 common elements:

1. Somebody (or everybody) maintains a list of everything that needs to get done, broken down into manageable chunks, with time estimates for completing each chunk;
2. Every team member has a prioritized list of those chunks, which they are responsible for completing;
3. There’s at least one person who monitors the progress to make sure things are on track.

Perform the above 3 tasks, and your project will have the highest probability of success. Sounds simple and it really is that simple! Even if you did the above 3 tasks on paper, without the use of any fancy tools, your chances of succeeding would be greatly enhanced. Project management is not rocket science, but rocket scientists performed the above 3 tasks to land a man on the moon in 1969 with less collective computing power than the iPhone strapped to my belt.

Over time, however, best practices for how exactly to perform the above 3 tasks have emerged into hundreds (if not thousands) of project management books. Numerous methodologies have emerged, many from NASA. Most of these process-driven methodologies detail exactly how teams should perform every nitty-gritty task. Yet, with all these awesome project management methods and years and years of experience, NASA, perhaps the icon of organized project management, cancels and/or delivers more late and over-budget projects than it did back in the 60s.

Why is that? Why is it that NASA, with all of its project management wisdom, couldn’t dream of doing what a few engineers did with the leadership of Burt Rutan — building a spaceship for under $30 million and winning the X-Prize? Rutan and his team built a rocket that can carry 3 people into space and an airplane that carries the rocket to launch to a high launch altitude. And, they successfully launched it into space twice in two weeks.

The world is full of examples where “regular” amateurs with far fewer resources and a lot less project management structure end up beating out larger, well-established companies that have relatively unlmited budget and their process methodology down to a science.

What all of these amateurs have in common is that none of them use a heavyweight, well established process to manage their projects. There are no examples I know of where a new company or team used a six-sigma process to unseat a leader in the field, but there are plenty of examples of a couple of 20-year old kids who worked using the “fly by the seat of your pants” method on a computer, search engine, operating system, web site or some other gadget that ended up changing the world.

Corporate America is also taking note. Some companies have recognized that the biggest risk to their well-established business is the “fly by the seat of your pants” methodology and they’ve decided to embrace it, although most are doing so reluctantly, without enough urgency, and half-heartedly.

Adoption of agile software development techniques, such as Scrum, are rapidly growing as a result of the flexibility they provide in managing projects the way a team sees fit. Google is a great example of a company who has whole-heartedly embraced the fly by the seat of your pants, entrepreneurial techniques. They have built their success as a company who employs little process, manages through chaos and has little structure in anything they do. The result is a company that is nimble, quick and surprises the industry and competitors with both its hits and misses.

Axosoft’s own customer base, as illustrated by a recent survey, is also of the belief that rigid project management techniques don’t pay. More than 60% of Axosoft customers don’t use any particular software development methodology. But, of those who do, Scrum, a relatively new agile development technique, is the one that’s gaining the most popularity. That’s no accident.

A Quick Look at Scrum

Scrum’s popularity is rooted in its back-to-basics philosophy; its simplicity and flexibility in execution. If you are new to Scrum, you might want to start with s presentation that Ken Schwaber (co-founder of Scurm) delivered for Google.

When I watched this video, one thing that stuck with me was the fact that Google engineers were getting introduced to and encouraged to use Scrum. If Google, a company that thrives on chaos, is embracing Scrum to some level, then it’s worth investigating more. So I set out to learn as much as I could about Scrum.

There are a number of great resources on the web. The Wikipedia page on Scrum is a good starting place. After reading a ton of material on the subject, I started to truly appreciate Scrum’s simplicity.

Scrum can be summarized as follows:

1. Projects have a list of things that need to be accomplished. Since these items are not yet done, we’ll call this list the “Product Backlog“. It contains everything we’d like to have in the product.
2. To keep things manageable, we’ll select a handful of items from the product backlog, assign them to team members and focus on getting just those items to a ship-ready state. We’ll call this the “Sprint”. We’ll keep sprints relatively short so that in a particular product release, we have at least several sprints. The shorter our product release cycle, the shorter the sprint duration.
3. To keep track of where things are, we’ll add up all the estimated hours of work currently remaining and compare the total to previous days to make sure it is consistently going down at a rate that is in line with our expectations and will meet our goals. We’ll call this the “Burn Down”. Charting the burn down information is an effective way to visualize the progress.

With just the above 3 concepts, any team can successfully implement Scrum. To make sure I had the basic concepts down, I picked up the phone and had a conversation with Ken Schwaber (co-founder of Scrum, founder of Control Chaos and author of a few books on the subject). Ken and I hit it off right from the start. Scrum is about common sense. It doesn’t define a rigid process, but rather a flexible one. It focuses on project visibility while everything else is about the basics (making a list, prioritizing and checking them off one-by-one).

Flexibility is the key to success with Scrum. Some teams, especially those who come from a high-process background expect Scrum to have definitive bounds for everything, to explicitly define every detail. A sprint is exactly 30 days (it’s not!). A must-have stand-up meeting that’s precisely 4 minutes 30 seconds long. You get the idea. But Scrum is about allowing teams to define the ideal practices for their situation based on team size, project size, release cycles, etc. A 2-man team working in the same room on a new web product might have weekly release cycles and no need for meetings, while a 100-person team working on a 10-year old, mature accounting package will have vastly different needs. Scrum’s flexibility is what allows it to work for both teams.

To be sure, Ken Schwaber and Jeff Sutherland (the other co-founder of Scrum) have done a lot of work to define Scrum in far more detail. They define common terminology for roles, best practices for conducting meetings and other project management events that are generally required for a successful project. But the basic concepts, much like the basic concepts of boolean algebra, are simple.

Scrum and OnTime

If you are an OnTime user, you’re probably wondering how OnTime handles the needs of Scrum teams. Looking at the above 3 fundamentals of Scrum, OnTime manages them in the following ways:

• Product Backlogs – The default OnTime “Features” tab is an ideal place to store product backlog items. In fact, many OnTime customers who use Scrum rename the “Features” tab to “Product Backlog” or “User Stories” in order to use the Scrum terminology. You can do that from the Tools -> System Options menu.
• Sprints – The ideal way to manage sprints in current versions of OnTime is by creating a custom field called “Sprint”. The field could be a picklist populated with potential sprints. You can then assign items to these sprints. And, since OnTime’s main list of items can be filtered, sorted or grouped by sprint at this point, you can easily look at the items for a given sprint.
• Burn Down – Current remaining workload for a given sprint, release, project, or any other filtered list can be obtained by simply looking at the status bar in OnTime’s main window. However, OnTime falls short in providing historic burn down information in the form of a burn down chart.

Here are some screenshots of OnTime being used in a Scrum environment:

In the above screenshot, the following areas are highlighted:

1. As you can see, the “Features” tab has been renamed to Product Backlog (this is done from Tools menu -> System Options -> Item Types). To illustrate a focus on Product Backlog, I’ve also removed all other tabs from the view.
2. I’ve renamed “Feature” (the singular reference to the item type) to “User Story” which is more inline with the terminology used in Scrum. So in scrum, you add a new “user story” to your product backlog.
3. I’ve grouped my view by Sprint. In this case, I’m looking at all the sprints for the currently selected project and I’ve created a custom picklist with my sprint names.
4. In the taskbar area, you can see the highlighted section identifies the current workload for the items in our current view. Since our view can be filtered to a project, a sprint or by a user, you can quickly see the workload by a number of different criteria and you can see how much work remains.

It’s also worth illustrating how easy it is to assign a bunch of items to a particular sprint:

In the above screenshot, you can see how a group of items are being assigned to a particular sprint using the multi-edit menu. In the above screenshot, the view is grouped by the custom Picklist field I’ve created called Sprint and since items not assigned to a sprint are shown in the “[None]” group, it’s easy to quickly identify those items in our product backlog and assign them to a sprint.

Future of Scrum in OnTime

OnTime is an extremely effective tool for managing Scrum projects, but I think we can do a far better job in future versions of OnTime. To make sure we fully embrace Scrum for future releases of OnTime, I had our entire team learn about Scrum. I also made sure we had multiple team members attend a two-day workshop with Ken Schwaber to become certified “Scrum Masters.”

Axosoft has embraced Scrum in a big way and we have made Scrum one of the main focuses of the next major release of OnTime. More generally, OnTime 2009’s focus will be on Project Visibility, which will help every single OnTime customer, not just those using Scrum. But for Scrum teams in particular, especially those hungry for some burn down charts and other visualization tools, you won’t be disappointed.

I can’t wait to talk more about the upcoming features, but that’s for another blog and another time.