Contact

Portfolio Events - Exploring The Decisions Being Made

“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the solutions within Lean Portfolios but an exploration of the Problems to understand whether the solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.

Activities affecting the Epic Lifecyle

Epics have a lifecycle, they don’t magically appear fully formed. There is work to be done to progressively elaborate a business case and if the Epic is approved then there is further work to progress the Epic through implementation.

Previous posts have explored the states that an Epic progresses through in its lifecycle and the decisions that influence the Epic’s progress through the Portfolio Kanban that represents the activities needed to move Epic through the states of its lifecycle.

In this series of posts we will explore the Events that either perform, schedule or track the activities that affect the operation of the Portfolio.

Portfolio Events

The Scaled Agile Framework proposes a set of events to operate the Portfolio; those events are:

I was looking at those events, and in discussion with my fellow Fellow Ian Spence who at the time was busy sorting out the Lean Portfolio(s) of a large multinational organisation, we reached the conclusion that the events didn’t feel right. There is nothing intrinsically wrong with what Scaled Agile proposes but it felt like the events had been optimised to minimise the number of events rather than optimising for purpose. Context inevitably influences peoples’ decisions, if the Scaled Agile methodologists had been working with organisations that were suffering from “meeting overload” then there would inevitably have been a push to minimise the number of meetings, possibly at the expense of effectiveness. It’s a U-Curve optimisation, too few meetings and they lose their effectiveness because too much is trying to be squeezed into one meeting and the focus is lost, too many meetings and they lose their effectiveness because it’s meetings for the sake of having meetings rather than getting something done. There is a sweet spot somewhere in the middle, just enough meetings for each of them to have a sensible purpose and thus be effective, but not too many that they’re overwhelming.

This brings me to my one big complaint with SAFe’s Lean Portfolio; it proposes a lot of solutions but doesn’t cover the problems that those solutions are trying to solve. The solutions aren’t wrong, or bad, but the Portfolio is one of the areas of the Scaled Agile Framework that needs the most customisation and to propose solutions without first exploring the problem space to provide the context for those solutions makes subsequent customisation difficult. It breaks one of the fundamental principles behind Design Thinking, understand the problem first! Maybe they do understand the problems internally, but if they don’t explain the problems to everyone else then we have no way of comparing whether our problems are similar to the problems that they have identified and therefore understanding whether their solutions are applicable to us.

Given that I think the set of events has been optimised incorrectly it seems worthwhile going back to first principles and looking at the set of problems that they’re trying to solve and working forwards from there. As we build the operational events back up we can explore some of the options available when it comes to customising the events.

Root Cause Analysis


I think we’ve reached a fundamental at needing to survive1, however the main purpose is described towards the top, everything below is justification as to why we should be moving those artefacts forwards. The events are there to make decisions to either move the artefacts forwards or to validate that activites to move the artefacts forwards are happening correctly outside of the event.

The next question becomes: Which artefacts?

Portfolio Artefacts Alphas

There are three primary Artefacts that the Portfolio deals with: the Vision for Portfolio, the changes the Portfolio needs to make to achieve the Vision and the people that will make those changes. Actually, the physical representation of those things isn’t important it’s that these things exist; drawing upon some of the Essence terminology they aren’t artefacts, work items, they are Alphas. Alphas are fundamental things that exist, they have a lifecycle, but they could be physically represented in many different ways.

SAFe’s suggested artefacts to represent the Alphas are:

  • Vision: The Portfolio Canvas is used to describe the current and future states of the Portfolio Vision.
  • Changes: Epics are used to describe the changes that the Portfolio wants to make to.
  • People: Development Value Streams containing teams of People that can make the changes the Portfolio desires.

Before we move on we should probably discuss the criticism that is bound to arise from my above statements:

Just three artefacts? Portfolios deal with more artefacts than that!

They might do, they probably need more physical representations of things in order to do what they think they need to do, to make the decisions they need to make. Take all those different physical things and reduce them down to the purest essence of what is needed and I’d argue that you end up with just three primary Artefacts. The real question is: Are the additional Artefacts that you think the Portfolio should deal with valuable or waste? Are they contributing to the Portfolio’s goal of “Value in the sustainably shortest lead time?”

Some years ago Software Engineering Methods and Techniques (SEMAT) standardised what they thought represented the Essence of Software Engineering and, through the Object Management Group (OMG), defined it as the Essence Standard . They identified a Kernel, the very heart of what is needed, and expressed it as 7 fundamental things, Alphas, that are needed for any software development endeavour.

If we were take the above kernel can we answer what in SAFe represents the 7 fundamental Alphas from the Essence Kernel.

  • Opportunity: at the macro level, for the organisation as a whole, it is represented by the Portfolio Vision. For individual Opportunities it is represented by Epics.
  • Stakeholder: the Portfolio Vision or Epics should describe who the actual people are that are the Stakeholders, they could be internal or external to the organisation, and it is working with them that identifies the Opportunities.
  • Requirements: described within the Solution Intent for a Solution within a Development Value Stream.
  • Software System: Solutions owned by the Development Value Streams.
  • Work: Features within the Development Value Streams.
  • Team: the people within the Development Value Streams.
  • Way of Working: mostly the practices that the Development Value Stream is adhering to

The Development Value Streams own everything in the Solution and the Endeavour spaces; which makes sense, the description of the a Development Value stream is: all the people, processes, tools, infrastructure, etc.. to get value delivered.

The Vision and Epics acts as physical representation of the Opportunities Alpha and describe the Stakeholders that need to be engaged to identify and progress those Opportunities.

Detouring into Essence has been an aside; but it has validated that there are only a small number of things that the Portfolio needs to deal with. Important, influential things, but only a few.

All three Primary Alphas have a lifecycle of states that they move through:

For the Vision I’ve grabbed the Vision from Scrum@Scale, the cards are available here if you want to download them. Now, I appreciate that Scrum@Scale is “one of the other scaling frameworks” and that this is probably heretical in some people’s eyes, but a vision is a vision regardless of whose framework I grabbed it from. I could have gone and got the vision from Projects which even though it’s exactly the same, because a vision is a vision, the association with Projects would have meant it was tainted, unclean and unacceptable in many Agilistas eyes! The advantage of grabbing the vision from Scrum@Scale is that Scrum@Scale has been essentialised, someone has thought about the states that a vision progresses through, whereas SAFe just has the artefacts that represent the vision. Regardless, whilst it’s not a perfect it’s close enough. The SEMAT Experts will jump in and complain that I’ve grabbed a Work Product to represent what I’ve described as an Alpha and they’re not the same thing. So, having upset absolutely everyone by using the wrong framework, the wrong terminology and getting too close to old world paradigms, I will invoke “pragmatism”; I just needed something to illustrate that the thing, the Vision, needs to exist and it has a lifecycle of states it goes through even if the lifecycle is somewhat trivial.

The states attached to Epics have been discussed in the blog post: Epic Lifecycle – Epic States. Since the Epic states are a proposal by me they are hand drawn; wheras for the other Alphas I’ve been able to draw upon more official representations that have been ratified by the organisations and individuals that own the intellectual property.

For the Development Value Stream I’ve utilised the Essence Kernel’s Team Alpha. The Essence Kernel doesn’t talk a lot about money, it recognises that doing work has a cost but the route the money takes to pay for the cost isn’t, and shouldn’t be, described. You could fund the work, but equally you could fund the people doing the work. The arguments for and against funding the work vs funding the people have been discussed in a series of posts exploring Managing Agile Investments. We’ll need to be a bit flexible with our interpretation of Kernel; where it says “Team size is determined” you have to understand that in SAFe the team size is determined by the budget it has been given!

Decisions

In order to move the Alphas through their states activities need to be preformed. Sometimes those activities will be simple decisions, sometimes there will be more process.

Vision

The Vision; someone needs to decide what the vision for the Portfolio is. The lifecycle is trivially simple: understand the needs, understand what a solution could look like; not the detail but a generic, portfolio level understanding of the solution.

The more observant of you will already be nodding sagely and muttering design thinking, double diamond to yourself quietly. The Portfolio is problem space, solution space is for the Trains and Teams.

There is also a philosophical decision to have at some point: Is it a series of visions where one replaces the next; or one vision continually updated? Either way it doesn’t matter, decisions need to be made to create the new vision or update an existing one. What’s important is that there is a vision to provide intent to the Portfolio.

Epics

To progress Epics through their lifecycle of states a number of activities will need to occur.

Requested

Epics are requested, an idea is proposed. As described in the Portfolio Kanban posts there are decisions around: Is this a good idea? Is it really an Epic? Which Epics should make progress? Whilst these decisions could be done as part of a big scheduled event it could also be done on an as-needed basis as ideas appear.

Forecastable

The Epic Hypothesis Statement needs to be prepared; it contains the Elevetor Pitch that describes the change to the business that this Epic wants to make and the measurements, the Business Outcomes and Leading Indicators, that will allow the organisation to assess whether the Hypothesis set out in the statement has achieved what was intended.

To prepare for Budgeting & Road Mapping initial cost/effort estimates need to be added the aforementioned Epic Hypothesis Statement Template.

Neither of the above activities needs to occur as a scheduled event, but there may need to be some form of regular oversight from the Portfolio to ensure that the activities are taking place and any impediments arising from those activities are handled.

Review

Development of the full Lean Business Case by the Epic Owner ready for Approval. The development of the Lean Business Case can, and should, be done by the Epic Owner outside of any scheduled ceremonial events. The effort involved is non-trivial and different parts of the Lean Business Case require collaborations with different parts of the organisation. Technical staff might not have much input into predictions around value and Financial staff might not have much input into developing the technical strategy for the Epic.

Approval, given by Lean Portfolio Management, provides the Development Value Streams within the Portfolio with intent that this Epic is one that they should be drawing features from if necessary. The Approval decision moves the Epic from the Review state into Approved state and the decisions is supported by the development of the Lean Business Case. Given that approval is a group decision by the decision makers that make up Lean Portfolio Management this is likely to occur as part of a scheduled event.

Approved, Viable, Extracting

There is an activity to negotiate Features into the backlogs of appropriate Agile Release Trains within the Development Value Streams. This is a negotiation between the Epic Owner and the Product Manger(s) that own the Agile Release Train backlogs. The activity needs to happen prior to PI Planning but exact details of how and when it occurs can be deferred to the Epic Owner and Product Manager(s).

There is an activity to gather the Epic’s metrics, the Leading Indicators & Business Outcomes, to provide Lean Portfolio Management with enough insight to allow them to make informed decisions as to whether the Epic should to be allowed to continue negotiating for capacity from the Development Value Streams. The metrics will need to be prepared by the Epic Owner prior to any Cancellation decisions. Metric preparation can happen at any time, the Epic Owner just needs to arrange. Cancellation is a group decision by the decision makers that make up Lean Portfolio Management, therefore likely this is likely to occur as part of a scheduled event.

Development Value Streams

Seeded, Formed

Need to decide what the Development Values Streams are going to be and therefore who needs to be part of the Development Value Stream.

Collaborating, Performing

There may need to be some form of regular oversight from the Portfolio to check that the teams are running smoothly and regularly delivering value; address impediments as they arise.

Next Steps

This post has explored the Artefacts Alphas that the Portfolio has to deal with. The Alphas have states. To progress between those states activities need to be performed. Some of those activites should be performed as part of a scheduled event. The next post will develop the set of events that can perform those activities and will validate whether the proposal fits together properly and covers the problem space outline above.





#1 I’m sure there’s a reason we need to survive but I just get Gloria Gaynor singing when I try to search for it




More Great Topics for Agile Teams

How many Features do you take to PO Planning? PI Planning Tips

On the Nature of Portfolios; WSJF Estimating Portfolio & WSJF

Program Level WSJF & Feature Slicing Program WSJF & Feature Slicing

How to Prepare for PI Planning Series PI Planning - Just Say No To Waterfall Thinking

States of Epics The EPIC lifecycle

 

 

 

 

 

Contact Us