Second Order Agile Scaling

A post or so ago we talked about first order agile scaling… moving from a single agile team to more of a team of teams concept… one where each of the teams has to work together in a coordinated fashion to bring a product to market.  The degree of coordination is predicated upon how independent the teams are from each other.  The more dependencies between the teams… the greater the context and coordination costs.

 

This post we are going to lay the foundation to build on some of our first order scaling concepts.  We are going to introduce the idea of capability teams, explain why tradtional portfolio management fails, and introduce the notion of agile portfolio management.  Our goal is to be able to build out a delivery organization that is broader than a single product.  Second order agile scaling involves running multiple projects through your development organization simultaneously.  

 

 

We’ve talked about the idea that agile organizations coordinate the work of many small teams to deliver on the broader objectives of the enterprise.  We’ve also talked about the idea that agile teams can be organized around features or components… maybe even services (think SOA).  Regardless of what we have our teams work on… regardless of what we have them organize around… we are fundamentally bringing folks together to deliver capabilities to the enterprise.  These capabilities can be deployed whenever and however to deliver on the highest priorities of the business.

 

This is a very different approach from how we traditionally manage our project portfolios.  

 

Most of us think about deploying people and skills to do work… to perform activities.  If we are going to deploy people to do activities… we have to predict and plan and document so that they unambiguously know what we need them to do.  Becuase we have specified so much, it is tough to hold the people accountable for outcomes.  Dennis Stevens touches on this concept a bit when he talks about white space in projects.  Who manages the work that happens between the lines in our project plan?    

 

Rather than deploy individuals to do tasks, agile organizations deploy teams to deliver capabilites.  When we think about the capability as the outcome rather than the completed task, we can hold team team accountable for delivery… and let go enough to allow them to get the job done.  The teams fills the gaps… they fill the white spaces.  

 

From an organizational perspective… from the point of view of the portfolio… I need to be able to assess organizational capability… understand how fast I can deliver those capabilites to the business… predict when certain capabilities will be delivered… and understand how to pull the capabilities together to deliver our strategic initiatives.  We are intentionally broadening our definition of agile output from our traditional notion of a delivered feature to that of a delivered capability.  

 

Why you ask?  Well… at scale… it might not be an end to end feature a team delivers to the business.  Organizational capabilities and how fast I can deliver them… how fast I can integrate them…  are all that I fundamentally care about at the portfolio level.  When we plan around capabilities… througput can normalize over time.  Planning around individuals and tasks is consistently erratic and unstable.

 

 

Traditional project portflio managements fails becuase it focuses on the optimal utilization of individuals rather than focusing on the delivery of capabilities to the business.  

 

The application of people to work packages naturally results in periods of high activity and periods of lesser activity for the individuals on the project.  Because our focus is almost always on the task utilization of the individual and less on the capability througput of the team… we look for something else to keep that person busy.  

 

Since we have some folks with a little unallocated time… we go ahead and get started on the next project.  It doesn’t matter that the first project hasn’t finished yet… we need to keep people working on stuff.  So…. our second project has started but doesn’t have all the resource necessary to finish.  Furthermore, we have created dependencies between our first project and our second project.  To deliver either of these projects on time, we have to be on schedule with both.

 

It is hard enough to keep one project on schedule, let alone two.  What about when we try to get started on three projects… or four projects… or thirty projects?  Trying to model and manage the resource allocations across all these projects is mind-numbing.  Trying to predictibly deliver any of the portfolio projects is equally challenging.  Running behind on any of the portfolio projects puts them all at risk and invalidates all our detailed planning.  A single change creates a cascading ripple through the entire portfolio and everything has to be recalibrated.

 

You want to talk about dependencies and context and coordination costs?  The cost of traditional project porfolio management is through the roof, and often so disconnected from what is actually going on at ground level, it is an ineffective management tool at best… and at worst… down right deceptive.  A convenient and costly fiction.  

 

 

Building teams around capabilities is the first step toward untangling our portfolio management mess.  Not starting projects we don’t have the capability to finish is second.  The trick becomes how to intake projects… decide how to break them up… figure out how to distribute them across organizational capability teams… manage the flow of value through our capability teams… and forcast when capabilities can and will be delivered to the business.   

 

Next post we’ll blow this out a little tie it back to some of the concepts we talked about in the first order agile scaling post.