Stop Snowplowing in Agile

This time of year in Chicago I can’t help thinking about snow. We haven’t had a real snowstorm yet but it is inevitable.

What should not be inevitable is snowplowing. Or more specifically, snowplowing in agile. Snowplowing in agile is a holdover from traditional project management approaches. It stems from the belief that projects are predictable, there are no unknowns, and fixed scope and fixed delivery dates for projects are not only possible, they are wise. Snowplowing reflects a lack of agile mindset.

The old PM mantra is, plan the work, work the plan.

Except it doesn’t really work that way for the vast majority of technology projects. In fact, that approach has been shown to fall short of success for three out of every four technology projects.

Let me share with you a short client story to illustrate the point.

A Client Sets Up Snowplowing in Agile

Several years ago I was asked to help a client team that was adopting agile. I was asked specifically to help with snowplowing. It was the first time I had heard the term in relation to agile teams so I was a little puzzled. I ask what they meant by snowplowing.

It seems the manager wanted the team to try agile ways of working. The manager worked with the team to break out all the stories they needed for the project. So far so good.

Then they created a release plan for six sprints worth of work. They allocated all the stories to the six sprints evenly (fixed scope). They did this based on when they committed to the customer that their work would be done (fixed timeline). Unfortunately, they filled all the sprints to the brim with the work to be completed before they had completed any sprints and had any idea how much the team could complete.

Uh oh.

Do you see what I see? Six full sprints? Full to the brim.

More accurately I think you could say full to the brim. In fact, without any idea of capacity and velocity of a new team, you have no idea if the sprints are full. How do you know what is full? What is full if you have a brand new team and you don’t know what their velocity might be?

The other thing that is noticeable is that all the sprints have the same amount of planned work. Is that realistic?

What actually happened with this new team won’t surprise anyone who has been on an agile team. In sprint 1, less work was completed than planned. Surprised?

The first sprint for a new agile team is a period of big adjustments and learning. Even if you ignore the forming-storming-norming part of the first sprint, you have a team of people who likely haven’t worked as a true team before using agile approaches. How likely is it that they are going to hit the ground running in their first sprint and hit it out of the park? Slim.

In fact, I advise new agile teams to treat the first sprint like the first batch of pancakes. You might get something good, but you also might wind up feeding the pancakes to the dog. Better to keep expectations low and realistic. So creating a plan that shows the team with a consistent velocity, which is your wild guess, is not only foolish it is a setup for failure.

As you can probably imagine, since the team had a fixed finish date and the scope wasn’t flexible, at the end of each sprint they just “replanned” by allocating ALL the remaining work across ALL the remaining sprints. Wait, what?

I guess the assumption was that the team could pick up the velocity to get more done. That was not replanning in any sense of the word, it was simply insanity.

Insanity – Doing the same thing over and over and expecting different results.

What should they have done instead?

5 Steps to Avoid Snowplowing in Agile

1. Don’t Expect Much Output in the First Sprint – As mentioned above, I try to keep expectations really low for output in the first sprint. There is a much more important thing going on in the first sprint and that is that the team members are practicing new team skills and learning what it is like to work incrementally and collaboratively. They are usually also spending time learning from each other about the business domain and various technical skills. At the end of the first sprint, they may not produce a lot of valuable software, but usually learn a significant amount and expand their capacity dramatically.

2. Don’t Treat the Backlog as Fixed Scope – The backlog should be viewed as an approach that achieves a goal or business need. It is more like a set of planned experiments, rather than a set of 100 steps that must all be completed to get the project done, like a WBS.

You could think of the backlog as a flexible approach to achieve the mission. You might have to add some new backlog items and delete some as you learn and deliver. That is what is called emergent, and that is one of the “E”s in the DEEP acronym. And that is the point of agility.

It might also be possible to get all the business value with very few of the backlog items. The product backlog should be prioritized to those that deliver the biggest bang for the buck.

3. Expect Change – The further out in time you are forecasting, the more you have to allow for change. It should come as no surprise. If you have 6 full sprints, you don’t leave any room in the future for things to change. Or for the team to learn anything new as they begin to build out the solution.

So what might change? LOTS!

How about learning about better ways to work? Or better ways to achieve the goal?

How about learning about new business needs that we had not forecast? How about as we complete work and break down large backlog items, the backlog grows in size?

In our big room planning events where teams are asked to plan out 6 sprints worth of work, we always leave room after the first sprint. Always. And this is for experienced teams. Graphically, the planned workload might look like this for 6 sprints when planning, even for an experienced team.

4. Replan Using Real Data – The other key to avoiding snowplowing is to use reality. As in facts and data. Don’t just spread the incomplete work over the time you have available as if team productivity and capacity are fungible. That was one of the key problems with traditional project planning! Instead, replan using actual data.

Once the team has even just one sprint completed, they can use their measured velocity to re-forecast the remaining sprints. They can also evaluate their backlog to make sure their sizing is correct. They should use actual measured velocity and actual resized backlogs at the end of each sprint to re-forecast the completion of the remaining work. They want to use reality-based forecasting to get the most accurate predictions possible.

5. Don’t Look at Agile as a Fast Way to Complete a Short Project – Project thinking is short term thinking. I’ve heard of organizations wanting to adopt agile on a mission-critical project that was going to take a month. Don’t even bother. Agile teams can deliver something in one, two, or three months, but they won’t really hit their stride and become predictable until three to six months. Don’t think of agile as a technique to speed up delivery. It misses the point entirely.

This article originally appeared here and has been republished with permission

Business & Finance Articles on Business 2 Community

(25)