Forecasting: Is it EVIL in Agile Portfolios?

*Part two of a two-part series

In my last post, I set the stage for why forecasting can be “Evil” in agile contexts because organizations don’t effectively engage their teams. Here are five reasons why engaging your teams is the best way to forecast. It’s not all-inclusive, but simply intended to show the “why” behind my recommendation that forecasting is evil IF you don’t engage your teams in the effort.

5 Reasons to Engage Your Agile Teams in Forecasting

Velocity is a fragile thing

First of all, anyone who is using velocity as a measure of his or her agile team’s output or performance must realize that it’s a fragile thing indeed. Beyond not wanting to compare it across teams, there are simply so many factors that can influence velocity. For example, illness, attrition, interrupts, multi-tasking, skill, team maturity, and co-location are just a sample of the factors.

Now I’m not saying not to use it. I consider it quite a valuable metric. It’s just that you need to consider it within the context of each team and not over/under react to sudden changes in velocity. If we include the teams in the planning mix, they’ll take a more reasoned approach to estimating their velocity AND the possible variations they might experience due to “external forces”.

Team cohesion matters

I’ve found that teams take quite a long time to come together and to truly become cohesive as a team. Once formed, they are incredibly capable, but if you start nit-picking teams members away for special projects or higher priority interrupts, then you undermine the capability of the entire team.

Often in our traditional forecasting we ignore the “real world” of multi-tasking, project interrupts, focus factors, customer support, and such. If we include our teams in the planning mix, they naturally include these factors.

People or not “resources”; they’re not fungible

If you’re dealing with chairs or computers desktops, then I could literally see someone else forecasting the needs over the next few years as being reasonable. These are fungible “resources” and of course they can be forecast.

Are people (skills, collaboration, morale, ability to attract/hire, etc.) so easily handled? My broad experience tells me – no.

So if we include our teams in the planning mix, we’ll get a sense for the capabilities of the team that we’ve formed. We’ll find out if they have the equipment, tools, and training to do the job.

Under commit and over deliver

It’s incredibly easy for someone not doing the work to commit to an outcome. Often, they’re quite optimistic about the level-of-effort – maintaining a sunny day view to everything and not truly considering risks. I think its human nature. There’s a reason that your building contractor not only estimates building your home, but they build it as well. Can you imagine if I was doing the estimation for your contractor?

Sure many of them come in “over schedule”, but I guarantee a terrible result if I’m doing the estimation for them.

If we include our teams in the high-level planning mix, we’ll get much more realistic plans that include risk and contingency. The other thing that always impacts our plans is cross-team and external dependencies. Teams can more realistically and broadly consider and plan for these.

Speak truth about unknowns and ambiguity

In other words, be willing to say – “I don’t know”.

One of the things I’ve always found interesting when getting estimates from an “advisory team” as opposed to the eventual team themselves is that I rarely hear those magical words – I don’t know.

If you think it’s hard for a team member to admit this, it’s even harder for these more seasoned folks to admit their lack of specific knowledge and/or practical experience. If you want to accurately understand your projects, then having this honest dialogue about unknowns and ambiguity as early as possible is exactly what you want.

Wrapping Up

Now that I think about it, do I have trouble with forecasting? Actually, no!

It’s the perceptions around it that are the problem, words like: commitment, fixed date and scope, customer expectations, and promises made for the teams. If you truly forecast as a high-level triangulation mechanism, but don’t believe/use those level-of-effort estimates until the teams “make them their own”, then I’m perfectly fine with forecasting.

Now that sounds easy in words, but in my experience the devil is in the details readjusting those initial “commitments”. It’s not for the team to do. It’s for the leaders, stakeholders, architects, managers, product owners, and project managers to do. They are the ones who are often “disconnected from reality”.