The unpredictable cadence

Why is it that agile execution or dev teams seem to be the only ones who MUST be on some kind of cadence?

When I observe scaled organizations I see that we have all kinds of work thrown at an overwhelmed Product Owner or application development manager who happens to have a set of teams.

It's interesting to me because often the work is not qualified, but folks want a commitment to how much time it will take you to deliver something without anything to go on and they want to understand your current capacity.

Sound familiar?

So let's look at the qualification of the work first.

There's a scope of work...or is there? Do we know what's in and out of scope? For the scaled teams who are striped across the organization, are we aware of the enablers needed from other teams like systems or shared services teams?

Probably not. Because on a whim, someone came up with a project, added some legalistic language for the scope, listed a few business and functional requirements and simply handed it off to discuss in a meeting with 147 of your closest friends.

Now let's look at the capacity question.

They want your capacity. But it is not to understand this effort. It is to understand how many more efforts they can push or assign to you. So the first thing we have to account for is how much time it will take us to "build, test and deploy" but the team still doesn't truly know what's under the hood. So capacity is a wild shot in a dark room with hopes to nail something and many people just throw a number out there without metrics to back it up, all in the name of simply getting them out of our tailpipes.

So the gap that must be addressed in the scaled world is qualifying the request. I think we all know that part. It's the 'doing it' that we usually don't have such a good handle on.

That's where the fun comes in and I'm here to help!

So we said to start this post that agile teams are the only folks in the scaled organization who are expected to be on some cadence like sprints or iterations or quarterly planning.

But why not the folks who are asking for the work?

What's wrong with the idea of the product/project team, the requestors or the 'dirty pushers' to be on a cadence as well?

If the organization recognizes 6 2-week sprints per quarter, then how can we organize the rest of the contributors to recognize some cadence?

A team has alot better chance to properly diagnose, elaborate and deconstruct work if they know it's coming, yet requestors routinely blindside them will commitments that are already determined (on their behalf).

Stop the madness, folks!

Sprint 1: Prioritize your top 3 things (no more than that and maybe less, depending on size)

Sprint 2: Organize into smaller slices of work (separate and clarify the asks)

Sprint 3: Put an elaboration session together and do homework following that event

Sprint 4: Get all your documentation and enablement ducks in a row

Sprint 5: Put another refinement session on the books together and get the PBIs together

Sprint 6: Reach a mutually-agreeable plan for commitment to what has been split, sliced and deferred

This helps to set expectations, qualify the work, put those accountable in place and empathize with the capacity concerns.

Let me know how you handle the larger efforts in a scaled world in the comments!