What the Heck Is Agile Project Management Anyway?

I’m currently exploring the topic of estimating (I wrote an article and made a video last week). I keep seeing books and articles about “Agile Project Management,” but for the most part, these seem to be how-to pieces on practicing agile product development. I guess putting the word “project” in there makes it more marketable or something.

In my experience, there is a significant difference between normal team operations as it relates to product or service development and a project. A project is a discrete set of events that differs from normal product development operations in several key ways:

1. It’s execution is discretionary?
2. It begins with at least a desired end date if not a hard deadline
3. It is usually (but not necessarily) a multi-team effort

It is these three key differences that make something a project vs normal product development operations. Some organizations may not see the difference. I would contend that if that’s the case, they are adding extra overhead to their product development efforts unnecessarily. Let’s break it down.

Discretionary

In my experience, this is the key differentiator in the sense that, while ongoing product development is normal and expected, projects tend to be evaluated for viability before they begin. This process is a point of tension for good agile teams. They are uncomfortable with the idea of a fixed scope and a fixed timeline. Yet, this has been the very nature of projects since time immemorial. So, how do we “agle-ize” a project?

First, everyone needs to come to terms with the fact that everyone is going to be asked to project (there’s that word!) how much they can get done and in what timeframe. To do this requires some major agile anti-patterns. The team(s) must pull together a list of requirements, estimate the effort to do the work, and provide an estimated time-to-deliver. Gosh! That sounds like waterfall to me. What makes it different is twofold:

1. The amount of effort that goes into it
2. What the estimate is used for

How Much Effort?

Agile teams know that despite their best efforts, they’re never going to hit the nail on the head when it comes to this process. They recognize that requirements will change, unknown unknowns will be discovered and known unknowns will be bigger than they expected. People will be gone from work unexpectedly, and the world will impose itself on any tightly manicured schedule.

So, the mandate is: don’t stress about the accuracy of the estimate. If the project has a hard deadline, the scope is going to float. Period. My suggested rule-of-thumb is to take the planning phase of a waterfall project and drop it by two orders of magnitude. For example, if the project would have needed six months to plan under waterfall, the agile planning should take six days (I will write about rough-sizing a project separately).

Using The Estimate

The other fundamental difference of agile project management is what the estimate you get up front is good for. We know it’s not good for holding anyone accountable. Doing this may well be the biggest agile antipattern of them all! In one bone-head move, leadership can undermine any trust or team autonomy that was heretofore built.

The estimate might be good for a go/no-go decision. If teams are not confident that they can deliver the requested value in a required timeframe, then the plan may be dead on arrival. That’s a good thing to know. If teams have done their estimating correctly, they have also prioritized the various components of the value they plan to deliver. This may provide an opportunity to draw a line under the absolutely necessary components to see if the effort can be brought in line with the timeline.

The information generated at this stage can also be useful for uncovering any dependency bottlenecks. Maybe one team will need the work of another team to stay on track, but they will not see those deliverables until far too late in the project. Can those dependencies be removed or not? Understanding this can help with the decision to go forward.

The bottom line here is that the upfront planning effort is minimal so that we can quickly get to a decision about whether to proceed with the project or not; and if the timeline is realistic. This effort is basically a throwaway. Once the project begins in earnest, things will change and teams will adapt, just as they do in any other agile product development effort.

The Deadline

While some projects might have a movable end date that the initial planning process can support or not, many (if not most) projects have a hard deadline. Getting ready for a tradeshow. Meeting an externally mandated due date (not necessarily a customer’s preference, but one that would be hard to change like an independent certification organization’s annual deadline). Or, the end of the year (good luck moving that one!).

When the end date is immovable, scope is going to have to be flexible. While teams make decisions based on self-imposed deadlines all of the time, they also have more flexibility in these situations around reducing scope and creating fast-followers. What makes a project different is that there is a minimal amount of scope that must be delivered by a specified time.

Multiple Teams

Cross team dependencies are not uncommon during normal product development efforts. As agile practitioners, we do our best in the architecture to minimize these, but some are unavoidable. Many projects have a more compressed timeframe and this causes these dependencies to be much more critical.?

It is important to identify as many of them as possible during the planning phase, so that each of them can be evaluated for their potential impact on the timeline. Given the nature of agile development, ample padding should be given to any “close calls” that might have a significant impact on the timeline.

Coordination

The one final difference between normal product development operations and a project centers around keeping up with a multi-team effort as the project progresses. In order to identify concerns early, it is important to establish sufficient communication channels. There are an infinite number of variations here and the size/scope of the project should dictate what is needed. In general, I like to have a chat communication channel (if you’re using Slack) that all members of all teams involved can watch to get spontaneous updates or requests; and some regularly scheduled check-in with at least one representative from each team involved to report progress, blockers, concerns.

Sometimes, people use spreadsheets or other more traditional project management tools to create a visualization of where the project stands. Again, it’s not the tool, but what it is used for that makes the project agile vs waterfall. In an agile project, it’s just another form of communication to keep everyone coordinated.

That’s it! The rest of it is normal agile practice. Just because you’re working on a project doesn’t mean you throw out all the great practices that agile offers in order to make the team more efficient and effective at delivering customer value.