Adaptive Portfolio – An Introduction
Organisations that utilize batch principles to deliver work are often synonymous with old legacy systems, batch-process thinking, big up-front planning and long feedback cycles. Requirements are thrown into a black hole and we expect that our perception of value will materialize once delivered. In most cases this heavy process driven enterprise is not the Starship Enterprise and cannot change direction fast enough to capitalize on the demands of market.
This gives Agile a huge benefit of the doubt, as it allows the organisation to respond tactically to churn in the marketplace, to customer feedback and to changes happening in the macro environment surrounding the organisation. Tactical changes can influence strategy and tactics can be adjusted rapidly in response to strategic changes.
It remains difficult for organisations to pivot their focus to accommodate such churn, largely due to old fashioned ways of thinking and definitions of success are in the way. Not only does the organisational structures have to change to support this way of working, but their very fundamental way of thinking about the new way of work is pivotal, and these changes are far from easy. By applying Adaptive Portfolio thinking to the organization, we are able to start working towards such a mindset.
We find ourselves and the world in a state of VUCA:
- Volatility – The rate of change is forever increasing, and keeps on speeding up;
- Uncertainty – No clarity exist over future outcomes, and even if we think we know what we want to achieve, the rate at which change manifests itself means that the goal posts always move themselves before we had a chance to move closer to that goal;
- Complexity – Our achieved outcomes are significantly influenced by an array of interacting factors. These interactions are often manifested as a surprise rather than something we could have planned for.
- Ambiguity – There is fog surrounding every possible end state that we envision. We often misinterpret events, their direct consequences and their causes.
As you realize by now, all of these factors presents great challenges for organisational planning and drives towards a different approach. The multi-year portfolio of a stream of projects which are completed sequentially, leaves us without the ability to change direction and to adapt to the VUCA that constantly surrounds us.
Agile delivery is indispensable but not sufficient
Agile software development is a by-product of the process-heavy wasteful frameworks for managing software projects, but in this case more specifically geared towards software development. We have to re-align our thinking and realize that it takes an empirical, feedback led approach to building software which demonstrates thee characteristics:
- Value driven prioritized features
- Cross functional empowered teams with all the skills needed to deliver a working increment of the solution
- Short cycles of work, limited Work-in-Progress (WIP)
- Close customer collaboration
- Short, quick feedback loop
- Constant learning and adapting, both for the organisation as well as the process
Research shows that these characteristics results in better outcomes on the product level, and agile software development has become the most prevalent approach to building software today.
Agile development is characterized by using a prioritized list of distinct items of business value to define the sequence in which items are worked on. This list of requirements, or the backlog, is stack ranked in priority descending order, and work flows through the system one piece at a time with each item being completed (potentially shippable) before consuming the next piece of work.
The backlog is a living organism as it is being re-prioritized constantly as requirements move through the Cone of Uncertainty, macro- and micro economic influences, customer feedback and specific metrics all influence a work item’s priority in the backlog. This re-prioritization can be as frequent as daily in highly volatile atmospheres (Kanban in production support as an example) or less frequently where iterative and time-boxed development takes place (if using Scrum as the delivery approach). By keeping the distinct items small and digestible, the system’s ability to flow becomes so enhanced that it becomes predictable and responsive to changing market needs.
Agile software development methods work at the individual team and product level, and for complex products where product portfolio delivery depends on collaboration between multiple teams. Various scaling methods are available to handle situations like this, such as Scaled Agile Framework (SAFe©), LeSS, DAD, the Spotify method etc.
While we are always working on the most important thing in agile which means the team could stop at any time and work on the next most valuable thing, and the item placed on hold would not be waste. We can apply the Pareto principle – 80% of the value from any system almost always comes from just 20% of the features, so once the point of diminishing returns has been reached it makes sense to stop work on that initiative and focus on something more important for the organisation.
In order to truly reap all the fruits of our agile endeavors, the organisation desperately needs to think about how we work at the portfolio level.
Adaptive Portfolio Management
When taking the idea of the prioritized backlog and inducing it across the entire organisation we could have an adaptive portfolio. A portfolio where every team, at any time, is busy with only the most important thing at that point in time. The speed at which reprioritisation is done on the portfolio level is different to that of the team level which illuminates the importance of quick feedback loops within all structures of the organisation in order for the delivery of value to be transparent across all governance levels of the organisation.
It is important to have the ability on the Portfolio level to quickly switch team(s) effort from one initiative to another, once sufficient value has been derived from that initiative. This may or may not be sooner than planned. However, the metric is not some arbitrary date or fixed budget, rather it is maximizing the value to the organisation from the work done on the initiative.
In exploring new frontiers, there will always be spike type work (investigative, POC type work) which would naturally have shorter planning cycles, while others may have better understanding of the requirements and therefore is able to construct longer term plans with roadmaps that could span beyond one year. It is still key to only plan on three month horizons for most initiatives as this is the half-life of any requirement before it changes.
The cycle in which initiatives are re-evaluated should have a correlation to the planning horizon of that particular initiative. If there is a 3 month planning horizon for an initiative then the governance checkpoint should be every six weeks.
Constant re-evaluation of an initiative and recognising when the point of diminishing returns has arrived is essential to keep the organisation focused on building the right product. Stopping work on an initiative only means bringing the next most important initiative (which could be a different set of features for the current product or a completely different product) to the team so they are always working on the most important pieces of work in the organisational level backlog.
Once you are so in-tune with your portfolio, or having an adaptive portfolio, is a key characteristic of a truly agile organisation, an organisation that listens and responds to ever changing product stimuli.
If this subject interests you, please join our Agile Portfolio Management Course which is the second leg of the Value Management track of the International Consortium for Agile’s learning curriculum. In order to complete the track, one would need to undergo the Agile Business Value Analysis Course on this Value Management track as well.