I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead I’ll be much more succinct.

Is forecasting evil in agile portfolios?

YES!

The context for this conclusion and subsequent discussion is three-fold:

1. Forecasting when you are just building your agile teams OR are in the early stages of an agile transformation;
2. And, when you’ve been doing agile for awhile, and you’ve become overconfident with your capacity awareness;
3. And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning and forecasting.

And let me be clear, in my experience this IS the way traditional projects have been forecast. Usually a small group of product folks will get together with technical managers, a project manager, architects and perhaps a technical team lead or two.

Often QA and other functional team representation are left out of the mix, with the thinking being that the developers can estimate “for” them. The product folks present an “ask” to this small team and they estimate the LOE (Level-of-Effort) associated with the functionality. If it’s a Waterfall project, then who (# of Dev, QA, etc.), how long (days, weeks, months, transitions or workflow, etc.), and output (lines of code or components, tests, documents, etc.) are the usual units of estimation.

In agile contexts, the same things occur. However, the estimation units usually change to be specific numbers of small agile teams, velocity or capacity, and number of iterations.

To be even clearer, these folks are not destined to do the work. But they set an expectation for the work and then go back to whatever their day job is. At some point the “ask”, if the cost and ROI are deemed worthwhile, is handed off to a set of teams to deliver. Often, the view is that the “hard work” has already been done, and there is simply “execution” left for the teams.

My key problem…

My key problem with all of this is that someone else is estimating for, and let’s be real here – committing for, the teams. I know, I know, there are many excuses; I mean reasons for it. Here are some I often hear:

1. The team is working on something important right now. We simply don’t have the time to interrupt them to estimate another project. And it would COST too much to do that as well. What we’ll do is select a small set of high-skill team members to do the pre-work before we get the entire team engaged.
2. This project is WAY too BIG to get everyone together. We do Enterprise-level projects around here. We have large numbers of teams AND many of them are distributed around the world. There’s just no way that we can get EVERYONE together.
3. This project has new technologies and new approaches intended. The team doesn’t have a clue about this. But Bob, the architect does. We’ll get Bob and his team to “iron out” the hard-bits in advance of the team’s execution. Bob can even run some “Lunch & Learns” as a way of passing off technical knowledge in the beginning.
4. We’re trying to prioritize our entire PORTFOLIO right now and we need high-level LOE estimates to do that. So there’s no way we can ask the entire team to estimate 10-15 major initiatives.  Of course, we’ll give each team the opportunity to pull together a more realistic estimate before we start execution.

Now there is validity to all of these points. And I truly understand the balance in getting things done (current project work) versus planning & forecasting (determining future capacity).

But if our goal is to accurately forecast and best understand our projects, then I still feel the best way to do that is to engage as much of our team targeted towards the work, as early as possible, so that we get the most realistic estimates.

Here are five reasons that 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

1) 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”.

2) 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.

Not that long ago I had someone ask me what was the “ramp up factor” for a new agile team? In other words, how many sprints would it take for a new team to become fully functional? They were looking for a magic number to plug into some spreadsheets as they did their forecasting.

My answer to them – there is no magic number for this AND you might want to “ask your teams”. While I felt it the “right” answer, I don’t think they appreciated it.

3) 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.

But 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. We’ll find out how long it will take the team we’ve formed to do the job we’ve placed before them. They might even include real-world events like vacations and family events in the plans.

4) 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 LOE – maintaining a sunny day view to everything and not truly considering risks. I think its human nature. But 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. Again, teams can more realistically and broadly consider and plan for these.

When I do release planning (PSI – Potentially Shippable Increment planning for you SAFe folks) with agile teams I’m coaching I often talk about discovering what I call “glue stories or glue work”. This is work that isn’t typically associated with a functional Feature or User Story, but it needs to be completed in order for the PSI or Release to be usable or considered complete. My experience is that ~40% of the work for a project/release/PSI usually surrounds this non-obvious or hidden work.

And only your teams can truly surface these risks, dependencies and hidden work in your plans. You ever wonder why most projects are over schedule? I think this is one of the major reasons for it.

5) 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. But 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.

And in my experience, teams doing planning will have a tendency to “Tell Truth” much more often than folks who have seniority or perceptions to worry about.

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 do forecasting as a high-level triangulation mechanism, but don’t believe/use those LOE estimates until the teams “make them their own”, then I’m perfectly fine with forecasting.

SAFe conceptually handles this quite nicely. It allows for ongoing portfolio and project-level planning. But there is NO COMMITMENT to a PSI or Release Train until the team gets the chance to break down the features into user stories and pull together their PSI plan (a response) to all of the higher level planning. Then they commit to the PSI and begin execution.

If the leaders and stakeholders planned for the team releasing 10 Features in this PSI, but the team only committed to 5, then those leaders and stakeholders should have made soft enough commitments so they can go back and reset them to 5. And they should also use that data-point of “5 feature velocity or capacity” to readjust their portfolio and project level forecasted plans.

Now that sounds easy in words, but in my experience the devil is in the details readjusting those initial “commitments”. And 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 “disconnected from reality”.

Stay agile my friends,

Bob.