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.

Scaled Agile Framework Applied - Part 1/5: Introduction and Context

Since encountering Dean Leffingwell’s Scaled Agile Framework(SAFe), I have presented the model to dozens of senior executives and middle management from numerous enterprises grappling with the question of how to effectively scale agile.  Without exception, the ‘Big Picture’ resonates.  It is easily incorporated in their mental model of the key ingredients in delivering enterprise scale outcomes, and a 1 hour overview leads to the response ‘I can believe in that’. 

The challenge, of course, arises when you start to delve into the follow-on question – “Now how do I make it work in my special situation?”  Like any good framework, it is designed on a set of principles.   Implementation requires leveraging your understanding of the principles to tailor the detail to your situation.

In this series of posts, I will endeavour to illustrate with working examples the fashion in which it has been applied in the group I have been guiding for the past 9 months.  

Approach

The success of this implementation has attracted a great deal of interest in both the enterprise the group belongs to and other Australian companies grappling with scaling agility.   On a weekly basis, groups visit to understand ‘how it is done’.  

Over time, we have established a ‘2-hour tour format’ that walks the model.   Tours always begin at an A0 poster of the ‘big picture’.  We spend 5 or 10 minutes giving a brief overview, then proceed to work our way through the portfolio, program, feature and team kanban walls illustrating the way work flows through the layers of the model and the type of discussions they facilitate.  My intent in this series will be as much as possible to provide a simulation of a physical tour.  It will be structured as follows:

• Part 1 - Introduction and Context
• Part 2 - Demand management and the portfolio kanban
• Part 3 - Program level pipeline management and the program kanban
• Part 4 - In-play work and the program level feature wall
• Part 5 - Results to-date and Conclusion 

Context 

The setting is a large enterprise in the midst of an Agile transformation.    They experienced good success with many smaller agile projects, but encountered significant challenges in the early stages of applying it to major programs of work.  Over the course of 2012, 4 major groups across the enterprise successfully adopted SAFe.  Each applied it to different problems and tailored it to suit – the one I will be writing about focuses on business intelligence and data warehousing. 

In April, I heard Dean describe his typical approach with a new client as “give me your worst program, I’ll fix that first and we’ll keep adding a program at a time from there”.   It’s a fairly apt description of the case at hand.   Agile project teams existed, but knitting them together into a program with appropriate cohesion, visibility and governance continued to be traumatic.  The model was applied first at the program level (the 2^nd and 3^rd layers of the framework), then extended up to the portfolio level and additional programs are now being transitioned in.

One other piece worth noting is that we are not yet describing a full enterprise-level SAFe implementation.   It is being actively explored, and what is known so far is that it will require 2 additional portfolio layers as the various groups are brought together.  I will be describing an implementation keeping 3 programs or delivery groups and roughly 200 people busy, but the eventual target involves more than 5,000.

Having set the scene, in Part 2 I will explore demand management and the portfolio layer implementation.

Book Review: The Secrets of Consulting

When I started this blog, I set a rule for myself that I would never post simply to point out interesting ideas from others without adding some form of value regarding the application of those ideas.  I'm about to break it.

I was reading about Virginia Satir's techniques for helping others/yourself to transform ingrained behavioural rules a few days ago.  It offered the insight that you could apply a three-step transformation to a rule such as "I must always deliver good news" as follows:

1. Change the word "must" to "can" - ie "I can always deliver good news"
2. Change the word "always" to "sometimes" - ie "I can sometimes deliver good news"
3. Apply a "when clause" listing the conditions under which you can do it - ie "I can deliver good news when I don't have to lie to do it or what might seem 'bad' to me might be good to someone else".

I thought this was an interesting technique to apply in helping people move into transparency under Agile.  Sometimes the "Green status report" culture is so deeply ingrained it takes a lot of shifting, and I could see this system really helping people to move through the transition.  

Then, I took the 'self-examination' focus and thought about rules I could apply it to in myself.  I am constantly encouraging both people I coach and friends to pick up books that have inspired me.  Twice this week I handed my kindle to a friend and said "here, this book is gold .. check the stuff I highlighted and you'll see why you need to read it."  Last night I realised I can write myself a new rule:

I can blog simply to point out interesting ideas from others when my purpose is to inspire others to follow the ideas to their source for elaboration.  

So, with that rule in hand I would like to inspire those who read this blog to go read Jerry Weinberg's 'The Secrets of Consulting'.  Jerry has written many many books, and prior to meeting him at AYE this book would have been absolutely bottom of the priority list for me.  I looked to him as a source of inspiration on Systems Thinking, not consulting!  I've now read it and highlighted more insights than in any other book I've read in the last 2 years.  Despite being written long before Agile came into being, it is just a must-read for anyone who is either an Agile coach or some other form of change agent.

Following are my favourite dozen quotes (in no particular order), enjoy them and go to the source to read the anecdotes that lie behind them and discover your own favourites:

The First Law of Consulting: In spite of what your client may tell you, there's always a problem.

The Second Law of Consulting: No matter how it looks at first, it's always a people problem.

You'll never accomplish anything if you care who gets the credit.

People who can solve problems do lead better lives.  But people who can ignore problems, when they choose to, live the best lives.  If you can't do both, stay out of consulting.

Know-how pays much less than know-when.

The chances of solving a problem decline the closer you get to finding out who was the cause of the problem.

If you can't think of three things that might go wrong with your plans, then there's something wrong with your thinking.

Any time you're afraid to say no to your client, you lose your effectiveness as a consultant.

Sometimes when I'm not getting anywhere with the words, I listen to the music ... When words and music don't go together, they point to a missing element.

Your ideal form of influence is first to help people see their world more clearly, and then to let them decide what to do next.

It may look like a crisis, but it's only the end of an illusion

Your primary tool is merely being the person you are, so your most powerful method of helping other people is to help yourself.

PS: I'm unashamedly on a Weinberg kick right now.  The rule transformation technique is taken from "More Secrets of Consulting"

  

What I learnt at the AYE Conference

I spent last week in New Mexico at the Amplifying Your Effectiveness (AYE) conference with Jerry Weinberg, Esther Derby, Johanna Rothman, Don Gray and 75 other attendees.

Since hearing about the conference format and making the commitment to attend, my excitement had been growing.  The concept of a ban on powerpoint, no session shorter than 3 hours, and every session facilitated by someone I deeply respected sounded too good to be true.

The week before leaving, one of the recurring themes in the office was the difference between “Capital ‘A’ Agile” and “little ‘a’ agile”.  The metaphor mapped ceremonies and practices to the “Capital A”, and teamwork, collaboration and vision to the “little a”.   We had enjoyed some rich discussions around the temptation to settle for proficiency with the “Capital A” because pushing into the “little a” was where it got hard.

AYE’s theme was “Human Systems in Action”, and I was very much looking forward to experiencing deep teaching on the “little a” side.   The first lesson I learnt was that I had gone for the wrong reasons.  I anticipated a week of “filling up the toolbox” with new coaching tools and techniques, and by the end of the second day I was feeling a little frustrated.  I was debriefing on the day with my wife, and the tone of the debrief was “I’m learning lots, but I’ve got no new tools I can put into practice”.  She looked over at me and asked whether I was missing the point.  Of course I hotly denied it at the time, but it raised a seed of doubt that started to grow as the sessions went by.

In the final session of the formal conference, it finally sank in.  It was a consulting masterclass with Jerry Weinberg, and he ran it as a series of case studies.  It was initiated  by asking us each to consider the thorniest problem we were currently facing as a consultant.   I was then introduced to Jerry’s technique of selecting the last person to raise their hand as the most fruitful case to examine and found myself in the 'consultee' chair next to Jerry.   Over the course of the next 20 minutes, I was turned inside out as he showed me the way in which my lack of belief in myself was the cause of the problem.    Whilst on the one hand it was incredibly useful, it was also an incredibly challenging experience being laid bare in front of 45 people. 

Over the following 2-3 hours, the reality of the power of AYE sank in as one after another people came up to me and thanked me for my courage in the hot-seat, commiserating with me on the pain of the experience whilst sharing the fashion in which they had benefited. 

A quote from Jerry’s book The Secrets of Consulting is the most fitting way to sum up my eventual AYE learnings – “Helping myself is even harder than helping others”. 

I didn’t learn any magical new secrets.  I didn’t learn any stunning new facilitation techniques.    The truth is there are no “big bang” revelations or magical secrets to Human Systems.  What I did was learn some new things about myself,  recognise some poor decisions I have made as a coach, and discover some new areas in which I need to grow in order to be more effective for my clients.

In the process, I made an incredible number of new friendships with people I look forward to learning from in the years to come.  If only every conference could be so fruitful!

Now that I've had a week to start to internalise it, I think the biggest insight for me lies in checkpointing myself as a coach.  I (along with all good coaches I know) spend a lot of time looking to fill up my toolbox with new techniques or deeper insights into existing ones.  I spend a lot less time searching for people who I trust to reveal flaws in my current insights.  

Thanks to Jerry, Esther, Johanna and Don for creating an environment where not only do they as facilitators hold the mirror up to attendees but also foster the trust and safety for us to share the mirror with each other.