Introduction to Lean Portfolio Management
The meaning of Lean Portfolio Management is illustrated by a horticultural example: the process from seed selection to harvesting.
Well and good! That's the big secret.
(Ferenc Kazinczy 1808)
Agile transformation often starts experimentally, at the level of one or two teams. These teams, are equipped with a better toolkit than other teams so in this way they can become more effective. This situation may not seem bad to start with - but let's look at what can happen at an organisational level if the agile team or teams exist in a fenced-in, enclosed unit in an environment that they cannot control and which operates under a different set of rules.
In a perfect world, in a lab environment the agile team - equipped with new methodologies - delivers ever more efficiently. Let's say that the market conditions change and the product the team is working on becomes redundant - or, in a less extreme case, the original plan needs to be redesigned. In a traditional organisation, it is very difficult to make such changes after the annual budget has been approved, especially without requesting new funding - which tends to be very long and cumbersome to get approved.
So the team continues to deliver unnecessary releases quickly and efficiently, or it regresses demotivated and the whole "agile experiment" is a failure.
In such cases, it is worth thinking about scaled agility, which means to adopt a new way of thinking at an organisational level. There are different schools for this (such as SAFe, LeSS, DaD, S@S, Nexus...). In a well built model, one of the most important work should be done at the portfolio level. Portfolio management itself is not an agile invention, but it is in this approach that it has become really popular. Let's see why through an example.
A gardener sowed four unknown different seeds in four small pots. Each received plenty of water and filtered sunlight.
After a few months, the first seed did not even sprout. The second seed grew into an acacia tree, the third into a cactus, the fourth into a rose. The gardener continued with the original care, watering all four plants and providing adequate sunlight.
Again, a few months have passed. The first pot still gave no sign of life. The acacia had apparently stagnated in growth. The cactus began to brown, rot and eventually die. The rose bush produced leaves, but no any flowers.
What did the gardener do wrong?
Let's start with the obvious - watering unviable seeds is a waste of time and energy. A cactus needs less water and much more sunshine. A tree, given its size, would have needed a larger pot, and later planting in the open would have been optimal, with the amount of water increasing in proportion to its growth. Roses, like most flowering plants, appreciate watering, but they will bloom profusely if regularly watered and in this case it would be worth considering planting in the open ground, perhaps in the sunlight filtered by the already mature acacia, which is sufficient for flowering but does not burn off the delicate petals.
Such changes occur if we are always alert to changing circumstances and manage resources accordingly. If a gardener decides in January how much to irrigate in August and does not take the current weather into account, he is unlikely to be successful in growing plants.
It is essential to constantly monitor results and market conditions, review decisions and, if necessary, react quickly and adapt to take advantage of the current situation without sacrificing long-term business strategy. Lean Portfolio Management, used in agile operations, is the answer.
What portfolio management is?
To organise, select and control the tasks, issues and "seeds" that are important to the organisation, according to the organisation's business strategy and available resources.
Typically, the demand is infinite and the resources are finite, hence the need for a decision system that can prioritise, break down tasks if necessary and allocate available resources as efficiently as possible. Let us first look at what happens in a traditional, waterfall-style, project-based budget.
The hippo in dangerous waters, or Project-based funding
The use of the word “project” in everyday life has also become very popular in recent years. A homework for a second-grade student was the environmental project, during quarantine self-development projects were all over social media - projects included homemade sourdough and homemade bread, learning Spanish and room painting. We also hear about parallel projects running in parallel from companions, which probably says a lot about our society's bonding skills. Why do we love projects so much?
In everyday life, a project is generally defined as a task that has a predefined goal, which is achieved within a defined timeframe and with the use of defined resources. Positive psychology has taught us that individual goals are important for motivation. There are very bad books and very good books about how important motivation is in maintaining our mental health.
In the business world, a project is also a unit that has a predefined duration, purpose and budget. In the traditional sense, a business plan and its rather rigid schedule are the result of a close relationship between need and resource, over a period of years or even several years.
If all the employees involved know exactly what they have to do and when it is due, the so-called waterfall methodology - which also fits in well with controlling processes - can be an effective solution. Sometimes a familiar routine is repeated and you are sure not only of the expected result but also of the stability of the circumstances. But in a world still struggling with the coronavirus epidemic, it is unnecessary to elaborate that stability is a much more nuanced concept than we thought even at the beginning of 2020 and that we may encounter unexpected currents in seemingly calm waters.
Well-designed, long-term project plans are easy to break down in many ways. Business objectives are often irrelevant after a year, no matter how much resources are devoted to preliminary research. Meanwhile, most performance-related targets linked to bonus schemes are easy to achieve.
For cost-efficiency, all working hours are planned in advance, often dividing the developer's or tester's day between several parallel projects. In addition, minor slippages not only in a given project, but also in all other portfolio items, can make it difficult to keep ourselves to the planned schedule, forcing us to divert resources from where they were originally planned. As a result, we are faced with long, unfinished to-do lists, delays and rising costs on several fronts. So initiatives to motivate employees are understandable, but even in the most efficient moments they are a maintenance exercise for the business, not a source of new value.
Such decisions are most often driven by the gap that typically exists between decision-makers and reality. The so-called HiPPO model, or Highest Paid Person's Opinion, is a phenomenon where the company leader has the last word, even if he or she cannot adequately justify or back up the decision with data.
Value stream instead of project flow, or why Lean Agile Budgeting works?
In a good case, building on the initial success of the isolated agile team, the organisation embarks on a larger transformation, applying agile principles in a scaled-up way. In such cases, it soon becomes clear that the traditional budget makes it difficult or even impossible for the organisation to transform.
The main difference between the two portfolio management methods lies in the financing. While traditionally we talk about the cost per project, Lean Agile Budgeting focuses on the value stream. What is the value stream and why do we need it?
A value stream is the process used by an organisation whose steps consistently produce a solution (product, service, system) that delivers ongoing value to the user. An agile portfolio consists of one or more value streams. According to the Lean rules, the main objective of a value stream is to reduce the time between order (so-called trigger) and delivery (time to market). This can be achieved not only by working faster (which can often be at the expense of quality), but mainly by eliminating waiting, non-productive periods.
Value stream mapping is a technique that outlines the steps in the process, from order to delivery, and can show, among other things, unnecessary waiting time. A thorough understanding of the workflow is essential to create a stable, efficient team with relevant competencies for the value stream. For more complex value streams, multiple teams may be required (team of teams), but it is important that the teams can work effectively among themselves, transferring tasks to each other while reducing the aforementioned waiting time.
If we have carefully assembled the teams and have a good understanding of the workflow, we can finance the value stream directly. It is important to think about the investment from all four horizons: not only to develop the solution dynamically, but also to ensure its deployment and eventual withdrawal, managing technological changes and responding to market needs. In the meantime, new value streams need to be created occasionally or obsolete ones need to be replaced. Portfolio investment guardrails help to determine how much of each resource is deployed at each investment horizon.
The risk of waiting time - this time for our organisation - is when we create a new product in a traditional project. We develop it to a detailed business specification, test it, refine it, all the while time passes. Many circumstances can affect the success of the final product, and from the start of the project to delivery we work only from concepts and estimates, without confronting the product with the real world, with users.
The answer to this is MVP (Minimum Viable Product). A common misconception is that MVP is a "half-finished" version with minimum functionality. According to Eric Ries' definition, an MVP is a version of a new product that provides the team with as much real information about the target audience as possible, using as few resources as possible. The term “viable” is important: it is a product that brings value in its initial version, is likeable and niche and can be delivered to customers.
According to Paulo Caroli (author of Lean Inception), traditional project-based development is like a cake and MVP is like a cupcake. A multi-layered cake takes a long time to develop, then to make, and in the end it may not be liked by the customer at all. A cupcake can be made faster, even in multiple versions, and each can be decorated separately. It is important that it is attractive to the taster and that the feedback gives the pastry chef direction on where to improve the flavour.
Larger units should be broken down into smaller tasks for several reasons. In addition to a lower time-to-market, the risk of slippage is typically reduced, which also makes planning more accurate. Work involving smaller tasks is easier to estimate. Try putting larger pebbles in one cup and smaller ones in another. Then put them both on a scale, recording the weight of each. At the end, count the number of pebbles in each glass. Not only are there more small pebbles in quantity, they are also considerably heavier in weight, as there is less unused space left in the cup. This example illustrates that by dividing the tasks, we can achieve a better result not only in quantity but also in quality.
Of course, developing a product is a bit more complicated than putting pebbles in a cup. There are larger, unbreakable units, but it is important to be able to estimate and prioritise these as accurately as possible. No two tasks are the same, so it is necessary to develop an estimation system that makes the decision possible and even clear. One of the most popular systems, also proposed by SAFe, is WSJF, or Weighted Short Job First. It is based on a clear understanding of the cost of postponement (the components of which are the business value of the job, its urgency and the reduced risk/new opportunity it creates) and the resources required for the job.
Furthermore, analysing data and metrics can be a huge help in prioritisation. We face this not only for the initial estimation, but also for the necessary redesign. Lean Agile Budgeting usually works in quarterly cycles, but there are also more frequent planning/redesign opportunities within a cycle. This means that what is really important at the moment is delivered, rather than what was considered important several months ago but has since become irrelevant and a loss to the organisation. At the same time, new ideas that bring value can be quickly introduced into the portfolio, as they do not have to wait a year until the next budget.
A very important factor in Lean Agile Budgeting is a metrics system that is accessible to everyone and, if possible, automated. The amount and nature of the data measured is product specific. It is a common mistake to analyse some common data without a broader context. A well-designed measurement system enables stakeholders to make data-based relevant decisions (data based decision making), avoiding the louder or the better paid person (HiPPO principle).
In most cases, development teams are empowered to make important decisions (decentralize decision making), based on their expertise and the metrics available to them.This of course not only reduces waiting time (the team is able to act immediately when a problem arises, in most cases not having to wait for a supervisor or the next planning event), but also increases the team's confidence, decision-making ability and responsibility.
Expanding the scope of decision making is not the only agile tool to move both the organisation and the team forward. A very important principle is the return on teams, i.e. to ensure that teams have the opportunity to develop, in the form of training, workshops, coaching. In this way, funding the value stream itself increases the knowledge it holds, while also increasing motivation at individual and team level, providing real value on both sides.
Similarly, transparency is also an agile pillar. MVP, dynamic planning, frequent and iterative delivery does not exclude, in fact it explicitly requires, a long-term strategy. In this case, however, we are not just talking about a secret plan accessible to the most important people in the company, but a shared vision that is transparent and to be followed by all units in the organisation.
In forecasting, we can estimate the next steps, but in most cases the final decision and commitment cannot be made more than six months in advance without incurring a loss. Developing the right functionality at the right moment, in response to the actual need, is what is known as the pull model (its opposite, the push model is the delivery of functionality according to the original schedule).
Based on the previous example, and putting this into the long-term strategy, this means that “although the forecasts predicted a frost-free May, we planned to plant the tomato plants in the open field at that time, but in the event of unexpected snowfall, it is advisable to reschedule.” This rescheduling will not affect our vision of eating delicious tomatoes from our own garden in the summer.
Epilogue: the twilight of projects, free after Wagner
Siegfried's body is the first victim of the Great Fire. Brünnhilde wants to die with him - she rides into the fire on her steed. The Rhine rushes out of its bed, flooding the place of the bonfire. The ring is returned to the mermaids, but Hagen runs madly into the waves, demanding the ring: the mermaids pull him down into the depths. The flames of Valhalla will rise - the kingdom of the gods will be destroyed.
Drawing inspiration from the final scene of The Ring of the Nibelung, one could say that project managers and coordinators are destroyed in the fire of delays, the value stream flows out of its channel and floods the project plan's space, the decision (the ring) is returned to the agile teams who pull the insanely rushing CEO down into the deep... of course this is not the case.
There is no methodology that can cover the whole business world at any given moment. Change takes time, not all steps can be taken immediately and there are undoubtedly situations where the classic waterfall project is still the best option. Our second-grader or our bread-baking sister-in-law can probably call her initiative a project without much loss, but even today many organisations think in terms of projects, with varying degrees of success. But it is important to make a conscious decision to get the most out of your organisation.
If you need expert help to assess the situation and choose the best portfolio management method, please contact our team.
