Scaled Agile Framework Applied 2/5 - Demand Management and the Portfolio Kanban

Introduction

As described in the introductory post, the implementation being described is not managing an ‘enterprise level’ portfolio. Before delving into the operation of the portfolio kanban, it’s important to understand the functional design of the group.

They operate a “Business Intelligence Centre of Excellence (COE)”, and the relevant operational units within the COE are as follows:

• PMO - Demand management and financial governance
• Strategic Delivery - Delivery of functionality against the enterprise data warehouse (EDW) and the strategic technology stack
• Legacy Delivery - Delivery of functionality against a group of legacy warehouses being managed through end of life
• Express Delivery - Tactical solutions

Demand comes from three primary sources, with requests ranging in size from less than $50K to multiple million:

• Projects conceived elsewhere in the enterprise which impact applications under management by the COE.  Impact may include a requirement for new functionality or prevention of breakage to existing functionality
• Investment in pursuit of a strategic roadmap based on an annual funding process
• Smaller adhoc requests for reporting and analytic capability initiated by business users 

The SAFe framework is designed to have a single portfolio management layer with multiple programs or ‘release trains’ operating beneath it. In this context, the PMO operates the portfolio layer and each delivery group functions as a program below it.

The Strategic Delivery group (covered in Parts 3 & 4 of the series) is a fully operational release train. Legacy operates as an outsourced/offshored waterfall delivery program, and Express delivery is in transition from a waterfall lifecycle to kanban.

From a maturity/timeline perspective, SAFe was introduced in early 2012 at the program level in Strategic Delivery. Adoption at the portfolio layer was commenced in late 2012, and the Legacy and Express groups are now re-conceiving their program layers as lean value chains.

The Requirement Hierarchy

We need one last piece of context (and some key learnings) before delving into how it works – nomenclature. One of the things that resonates for a lot of people is the fact that Dean puts some hard and fast names on the framework. You have Epics at the portfolio level which are then divided into and prioritised within Investment Themes. Epics are decomposed into Features at the program level, which are further broken down into stories at the team level. For many who are constantly confused with local hierarchies between themes, features, minimal marketable features (MMF’s), epics and stories the idea of having a clear-cut enterprise-wide hierarchy is great. Dean tends to recommend that if you have additional layers you introduce ‘sub-Epics’ and ‘sub-Features’ but it all still makes sense.

So far so good, but now for the learning part. Our initial vision was too small and too localised. We viewed Strategic Delivery as the portfolio layer, and also lacked co-ordination between the various groups applying SAFe across the enterprise, winding up with 4 different hierarchies. The coming months will see some hot debates about which naming hierarchy wins J

In this context, the hierarchy is as follows:

• An Initiative represents any demand which enters the COE demand management funnel (correlating to an Epic in the standard SAFe framework)
• Initiatives are decomposed into 1 or more Epics which align to the Delivery group boundaries (correlating to Features in the standard framework)
• Delivery groups then decompose Epics into Features for Delivery (which are realistically sub-Features from the perspective of standard SAFe)

The role of the Portfolio Kanban

SAFe Portfolio Kanban

At a high level, the concept is as follows:

• Ideas are dropped into the funnel
• An initial assessment takes place to determine the rough size and value proposition of each idea
• Ideas which pass the ROI criteria for investment versus value proposition are approved and go into a queue for more detailed assessment
• Further refinement of the idea takes place to provide greater confidence on the estimate and value proposition and decompose it into smaller chunks for distribution to the programs required for delivery
• These smaller chunks (Features) then compete in a more fine-grained prioritisation queue for capacity in the delivery programs.

The primary role of the portfolio layer can thus be summarised as:

• Manage the prioritisation of investment ideas
• Elaborate and decompose ideas into smaller pieces of work aligned to delivery program capabilities and manage the distribution of these to delivery programs

The Portfolio Kanban Applied

We took a fairly classic approach to implementing this with the PMO demand management group - composed of a number of senior BA’s with architecture support. We spent a couple of workshops mapping their existing value-stream, introduced a lean flow visualisation and daily standups at the demand wall and began to tune from the generated learnings.

The demand management kanban is divided into 4 main phases:

• Impact Determination
• Solution & Costing
• Communicate & Engage
• End-States (Delivery or Termination)

Impact Determination Phase

This phase is effectively the ‘idea funnel’ management section of Dean’s diagram. It is where potential demand is first assessed to determine whether it qualifies for further investigation. Demand arrives in ‘Initial Assessment’, which is typically processed at the standup. The team discusses the Initiative, and will either decide that it can be discarded, is a definite need, or requires further investigation. Definite needs proceed immediately to the entry state of the Solution & Costing phase, discarded initiatives are moved to ‘No Impact’, and those which need further information move to the Validation state for clarification.

Solution & Costing Phase

Mapping fairly closely to the ‘Backlog’ and ‘Analysis’ phases in Dean’s diagram, the goal of the Solution & Costing phase is to determine a solution direction and a rough cost (+- 75%) for the initiative.

The ‘Validate Entry’ state is basically used as a queue to control when an analyst will pick the initiative up. Qualification for exit from this state will be a combination of timing alignment with other enterprise groups involved in the initiative and analyst capacity. On a complex initiative, there may be as many as 10 other delivery groups involved and analyst WIP is managed by holding the gate here until there is enough alignment to effectively move forward.

‘Understand Need’ involves the analyst gaining enough information about the initiative to determine a solution direction and rough costing. Whether this takes the form of workshops, business requirements review, or some other means will vary based on the source and nature of the demand. By the conclusion of the phase, the high-level architecture will be understood as will the COE delivery groups involved and the nature of the functionality to be delivered by each.

‘Cost’ is typically very quickly transitioned. Simpler initiatives may be estimated by a pair of analysts, whilst more complex ones may involve escalation to a solution direction forum for costing. One of the current focus areas is the introduction of ‘T-shirt sizing’ to further simplify this state.

Communicate & Engage Phase

This is basically the boundary line between Dean’s ‘Evaluation’ and ‘Implementation’ phases. It is here that the first significant investment decision is made. Whilst we now have a rough cost estimate, this must be further refined (to +- 30%) before funding approval is obtained for implementation. Given that the cost to obtain this confidence refinement is more significant, the preliminary costs/benefits are evaluated to ratify this further investment. If the initiative does not stack up, it will be withdrawn. If it does, the first funding increment will be supplied and the required Epics will be created and handed over to the delivery programs for further refinement.

Operating Rhythm of the Demand Management Team 

The team is spread across 3 states, and collaborates through both a physical kanban wall and a deeper level of detail captured in the Rally portfolio management functionality. Remote team members dial into the daily standup, and take care of updating the electronic wall whilst central members take care of updates to the physical wall.

There is then a twice-weekly standup attended by members of the delivery programs to share information on the state of the pipe and smooth the flow of demand understanding. All have access to the electronic initiative portfolio, and this standup provides a rich opportunity to capture concerns and convey additional insights.

Additional formal solution direction and steering committee forums operate to provide an escalation and strategic guidance overlay.

What's on a card?

Each initiative in the portfolio becomes a card on the wall. They are initially printed from Rally with whatever information is known at the time, then as significant information emerges it appears on the cards. In the image above, you'll notice the following:

• Who owns the card (standard kanban avatars)
• Which delivery programs have a part to play in the initiative (the SD, LL and EXP tags)
• The current estimate (on a post-it for easy updating)

Various other post-its will decorate the wall indicating blocked initiatives, information on delays and the like.  This is of course more richly backed in Rally through a combination of detail, discussion and attachments.

Portfolio Prioritisation

SAFe specifies the use of “Weighted shortest job first” (WSJF) for prioritisation at all layers of the framework. Full details can be found at http://scaledagileframework.com/wsjf/, but in brief this utilises a ratio between the value proposition (Expressed as ‘Cost of Delay’) and the size of the piece of work. The cost of delay is a combination of ‘Business Value’, ‘Timing Value’ and ‘Risk Reduction/Opportunity Enablement’.

In my experience, this has been one of the critical enablers at the enterprise scale. Traditionally, agile delivery is utterly focussed on the delivery of business value – preferably quantified, but at minimum in the eye of the product owner. At scale, you need more levers. In particular, timing value is crucial. In classical product development, it focuses on such things as the value of releasing a feature in time for an industry event such as a tradeshow or gartner review cycle. However, it is also extremely useful once you start to consider dependencies. When pieces of functionality need to be co-ordinated for simultaneous release across multiple delivery programs, the timing and opportunity enablement value allows you to start to visualise the chance you will hold up the delivery of significant business value in other dependent initiatives.

In the COE, timing value is the dominant influence on prioritisation. In effect, the vast bulk of prioritisation is driven by compliance to enterprise release schedules and dependent pieces of work. Initiatives with high localised value are then fed through the system as capacity is available above and beyond that required to meet external timing pressures.

Benefits to-date

In an idealised implementation of SAFE for commercial product development, one assumes a centralised pool of investment funding. Effective application of the portfolio layer provides you with the following:

• The use of investment themes to provide a structure to divide your overall funding into key investment areas.  For further information on this, see either Investment Themes or Baghai's investment horizon model as described in a previous post
• The WSJF model to prioritise investment initiatives within these themes
• A flow-based framework for progressing elaboration and delivery increment identification which minimises work in process and effectively feeds work to delivery programs "just in time" 

The application being described, however, faces different opportunities and challenges. The most significant of these challenges is the lack of a centralised pool of funding. The COE faces the daunting task of dealing with an extremely fragmented funding model and knitting together demand from dozens of funding sources into a strategic build-out of the core information platform whilst progressively decommissioning legacy applications.

Whilst this level of the implementation is still in its infancy, it is already yielding significant benefit – primarily through the power of visualisation and communication. Week by week the demand management team finds itself able to lift focus from a “project by project” view to a living “whole of portfolio” view. Patterns of demand are becoming visible which will lead to more effective strategic decision-making and far more synergistic prioritisation and implementation once exploited.

Further, as waste is eliminated from the value chain, more time becomes available to focus on exploiting these new insights. Less than 3 months into operation, the team has already eliminated close to 2 FTE’s time in administration and dramatically improved communication and co-ordination both between team members and with the delivery groups.

The next instalment

In the next instalment, we will pick up where the demand management team leaves us, with the entry of an Epic to the Strategic Delivery release train.