Roadmapping with Enterprise Agile – Balancing Capacity Against Demand

roadtrip-645x250

Frequently I’m asked

There is a seemingly endless set of good ideas that are demanding capacity in our organization, how do we make our demand and capacity visible so that we can create a roadmap that will best balance demand against capacity?

This is the key question that most organizations are struggling to answer while trying to create an actionable roadmap.  I have a couple of basic rules that I use to help keep the answer simple.

  1. Identify a common unit of measure for quantifying demand and capacity, and
  2.  Identify a unit of time that best represents the period of time that will be used for planning

Rule 1: Identify a common unit of measure for quantifying demand and capacity

As you may recall, my favorite unit of measure is always currency.  That said, I find that when roadmapping its frequently helpful to use a more abstract measure that will similarly represent both capacity and demand.  Currency provides too many variations as an answer to the question “How much of this do you want to invest or how much capacity will you spend to bring idea x to fruition?”  To address this, I typically recommend that an organization either use a program team or a delivery team as the unit of measure.

With the common unit of measure set to either program or delivery teams, we can now answer the following question to help with balancing demand and capacity:

We have 20 delivery team’s worth of capacity available, how many of them are we either willing to dedicate towards bringing this idea to market or how many do you think you will need to bring the idea to market?

Rule 2: Identify a unit of time that best represents the period of time that will be used for planning

This is a great start; but, we haven’t yet applied time to the process.  To really map demand against capacity we will also need to be able to answer the question of how long are we willing to apply the team to this idea.  If a planning team needs to release items into the market within months then I tend to encourage them to plan against team weeks.  If their release plans are more oriented around quarters, half-year or year durations I will usually steer them to think in terms of team quarters.  With both the unit of measure and unit of time selected we can now map both capacity and demand for a period of time.  As an example, I may answer the above question as follows:

I am willing to allocate 5 delivery teams for a quarter to bringing this idea into the market.  That will leave 15 teams worth of capacity open for other ideas or features that I want to create as well this quarter.

Using team weeks or quarters as a unit of measure and planning duration for your roadmap enabling a planning team to simplify the capacity that is available by planning period down to a ratio of planned capacity/available capacity. (Eg.  5/20 or 25% of the available capacity for the quarter, with the above example).

Finally, when the time is right, its possible to translate the cost of a roadmap item by establishing an average cost per team (say $250,000 per quarter) and then multiplying that cost by the number of teams allocated for the period.

What are your thoughts? Have you used anything similar or different?

Thanks!

Advertisements

Hold on… what do you mean when you say business capability?

capabilities enable an organization to understand the options available for moving their boat in the desired direction

This term is one that I spend a lot of time defining and discussing with the teams that I coach.  Its interesting how it can become overloaded to represent various “things”.  Why is it that I spend a lot of time discussing this term?  As you may have seen in previous posts, most businesses engage with me as an enterprise agile coach because they find their current structure and processes make it hard for them to “turn the ship” quickly so that they can take advantage of opportunities in the marketplace.

A key part of making this happen comes down to understanding what are the underlying pieces and parts of the business that it can leverage when trying to quickly turn the ship.  These are what I broadly refer to as the business’ underlying capabilities.   To better define my intended definition of the term, I’d like to leverage the definition below as expressed by Ulrich Kalex in his paper on Business Capability Management:

A business capability defines the organization’s capacity to successfully perform a unique business activity. Capabilities:
– are the building blocks of the business
– represent stable business functions
– are unique and independent from each other
– are abstracted from the organizational model
– capture the business’ interests

Trust me… Agile just won’t work here…

I usually smile when I hear a statement like this: “Our culture is way too …” fill in the blank “Agile just won’t work here!”

Why do I smile?  I find that people are typically referring to a common belief that in order to be “agile” an organization’s culture needs be one of “trust”.  The belief is that an organization should trust its people to:
(1) make the right decisions, and
(2) do their best to deliver products and services that will make the business succeed.

All good stuff, very good in fact.  But, good or not, its a really steep hill to climb for an organization’s culture to go from (a) low-trust: managing projects for performance against their time, cost and scope commitments while focusing on departmental efficiencies to (b) high-trust: self-managed delivery systems that act responsibly within the available time and budget.

As we see in HBR’s article on organizational culture “Culture is powerfully shaped by incentives”.  As a result, we need to figure out how to (a) build trust, and (b) change the incentives.  Doing this is actually fairly straight-forward if you are working with your business’ leadership and solving for their issues.  What are their issues?  In most organizations, their issues are how to make and meet commitments in a way that is within their defined budget.

Becoming agile isn’t about using this method or that method.  It’s not even about trust.  Its about creating a system that can respond to change in a way that creates safety for the business’ leadership by respecting their immediate needs.  So, instead of trying to just go out and be agile, I think we need to start with a business need and find ways to meet it while creating safety for the individuals involved.  We need to create a roadmap to go from point a to b.

Most business leaders are desperate for better ways to deliver against their commitments while having the ability to adapt their plans along the way when things change.  Most leaders are absolutely thrilled to trust their people; but, remember, to establish the trust we have to be willing to first make and meet commitments in a way that shows them we can be trusted.

Thoughts?

How do I prioritize work?

Value is a funny thing.  In enterprise agile coaching, I’m frequently encountering teams that are trying to either (1) complete every single project at the same time because they are all equally valuable, or (2) using a nebulous unit of sorts (say a 100 point scale) to indicate how valuable a work item may be.

In the first case, its usually pretty straight forward to identify that all of the projects are not truly equal in importance and we limit the number of work items to the actual capacity of the delivery system.

In the second case, a team has typically taken my advice and is now trying to figure out what work items are really the next most valuable the business.  Frequently these teams will ask for a value scale, one that helps them to figure out if they need to build item ‘A’ or item ‘B’ next.  My answer in this case is almost always a question.  It goes something like this:

Me: “Which of the two items have a higher cost of delay?”
Team: “I don’t know, I think item ‘B’; but, if we ask person A or B from some other part of the organization they would probably say item ‘A’.”
Me:: “Well, do you know the cost of delay for both items, it should be simple math to choose between them if you do”
Team: “No, we have a guess, but we really don’t know”

It is usually around this time that the team’s will start asking for a method or system that can be used to help establish value for work. My answer is usually a bit over simplified; but, then again, perhaps it isn’t. My answer is usually ‘currency’. If the business exists to make money, then the value we are placing on work should always tie back to the potential for currency.

If a team is making tradeoffs based on value, I would like to see how that work item will turn into real money for the business.

What are your thoughts? Have you found any other approaches that work equally well?

Are we succeeding with an enterprise transformation?

Over the past few years I’ve had the amazing opportunity to work with over 65 different teams in various levels of small, medium, and large businesses.  In each case I was either leading the teams or advising the teams on how to become more adaptive.  When I joined LeadingAgile, I was thrilled to have access to the systems and tools that Mike and Dennis had employed and discovered while working with the hundreds (if not thousands) of teams that they had coached over the years.

One of the first tools that I encountered was a set of adoption attributes that we could share with a team to would help the team learn about how teams operates when they are valuing: (1) individuals and interactions over processes and tools,  (2) working software over comprehensive documentation, (3) collaboration over contract negotiation, and (4) responding to change over following a plan… or the agile manifesto.

From the adoption attributes I was able to work with a team to both show them the areas where they were seeing good adoption as well as the areas where they need to grow.  This was incredibly helpful for the team and me as it provided a spot light into areas where I could target coaching while at the same time giving the team the opportunity to grant me permission to coach in that area.

As time went on, I had more and more opportunities to participate in organizational assessments that were aimed at understanding the organization’s business drivers, identifying their change management concerns, and identifying a pilot slice of the to-be value delivery structure where the transformation should start.  Throughout this process I learned more and more on the adoption attributes and began thinking holistically around how to establish a repeatable system of transformation that was oriented around multiple phases of adoption.

Phase 1: Become predictable

Phase 2: Make risk and dependencies visible

Phase 3: Organize around capabilities to reduce or eliminate external dependencies

Phase 4: Streamline the delivery system

Phase 5: Fast ROI with quality and predictability (end-state business drivers)

This proved really helpful when framing up a roadmap for a transformation and thinking about it as an iterative and incremental process.  I was able to work with both teams and business leaders to clarify a pathway towards the end-state that didn’t require me to solve all of the adoption problems at the same time.  My initial hypothesis was that each of the phases would have different metrics to inform me that the key goal of the phase had been accomplished.

What I found, though, was that changing the metrics from phase to phase inspired confusion about how to know if the organization’s transformation was succeeding in delivering on the initial business drivers.  In addition, I found that hitting phase 5 based on the adoption characteristics would indicate that a slice of the organization has adopted practices that could help deliver the business drivers in spirit; but, isn’t actually using business metrics to help them clarify along the way to ensure that they are able to deliver fast roi with quality and predictability.

My question then became, how can I best use the business drivers’ key performance indicators as a focusing point for throughout the transformation.  One of the tools I came across for connecting the various perspectives of a organizations health to the organizations KPI’s was the balanced scorecard.

So… here is my question/new hypothesis: is it true that for a transformation to really deliver the end-state goal, it needs to be measured through the organization’s balanced scorecard or other business metric dashboard?  I think this is true and I also would advise that a transformation not be nesessarily deemed a success until the scorecard demonstrates that the business is responding to change, accomplishing fast ROI with the desire quality and predictability within their markets.

Thoughts?

Thanks!

Read the next article in this series