Like many organizations, mine is one that has adopted agile in name rather than in spirit. That is to say, agile terminology is liberally scattered around, but little of it refers to the true definition or traditional application.

Take sprints.

In a product-centric structure, agile (and sprints) makes a lot of sense. By focusing on a functional outcome at the end of every sprint, you get to truncate the feedback loop, and time necessitates focus on the truly important rather than the nice-to-have periphery.

But we are not product-centric: We are an enterprise-scale project delivery organization. Not unlike many others in fact. I have a number of delivery and governance functions, all of which cater to different technologies and demands.

So do I slice horizontally, with a backlog and sprint cadence for each project? Or slice vertically, with a backlog and cadence for each function? With the former, I have a challenge of assigning and managing human capacity across project sprints. With the latter I have to manage project demands and conflicts across functions. It’s a lose-lose situation manifested by long delivery times, serialization across functions, and systemic capacity management challenges.

I’m trialling a new cadence that aims to address these challenges. Of course we won’t put out a working product each sprint: we don’t make products. But the rest just might work.