Better than hippos!

I have been delivering software for 20 years, so I’m writing from a software delivery perspective. I’d love to hear from other industries…

In big and small software companies alike, there is always a problem in decided what work should be done next, or what order work needs to be completed in. There are many competing factors, strategy, technical debt, keeping it interesting, important sales, the list goes on.

A common way of choosing what to do next is HiPPO – Highest Paid Person’s Opinion. This isn’t wrong but is flawed. Generally, the HiPPO is the CEO. If the HiPPO is spending time deciding everything, then what important things aren’t getting done (signing off the yearly accounts, meeting with investors, staff development, keeping the expensive strategy consultants on target… seeing their family…getting enough sleep to avoid dying young).

Even if this isn’t the CEO and a degree of delegation has been put in place, always reverting to the HiPPO (in the room) results in disempowerment of the team and inaction as they wait for “the grown-ups” to decided everything. It will also sometimes come with a built-in bias, let’s say the HiPPO is Sales Director, well guess what – that person will value activities that add value through selling more, or more easily. The CTO may well value paying off technical debt more highly, so any HiPPO will introduce bias and therefore risk.

There are numerous methods of prioritising work; simple to complex, empirical to analytical. Here, I’m going to offer 1 simple approach, which is good for using where you have strong customer engagement/representation and engineers that get the need for (some) planning. I call this method “Relative work/value ratio”.

It is a top-down method that asks these questions:

Which work package is most likely to deliver more value? This question can be asked of several different stakeholder groups:

• voice of the customer, which may be the customer themselves, the salesman or the product owner.
• Service owner, who may “value” work packages that increase automation or reduce bugs so their team has less work or can remain at a certain size.
• Technical Architect – accountable for technical debt and ensuring the product is maintained, secure and that new work can be delivery quickly.

Which work package is biggest / smallest piece of work?

• This question is asked of the team that would undertake the work. In an Agile world this would be a cross-functional team that can take the work package from idea to in-use capability. In a more traditional setting, the question is harder to ask as it pulls from all multiple departs but the input needed is the same.

The critical part of both questions is that we are not aiming to understand absolute cost or effort. For each dimension we want to find what order the work packages would be ranked in with an estimated placing of relative size.

There is no sitting at a desk to come up with these assessments, it is done in discussion in a workshop environment. A key reason for this is that each work package can be worked out to a different level before the workshop, some may be well detailed, others outline ideas. This demands discussion to ensure a common understanding with documented assumptions and dependencies. During the workshop you place these rankings into a 2D plot, like the one seen next.

In this 2D plot I’ve presented each work package in the same way, i.e. with a blue dot and all blue dots the same size. As this process is empirical and involves estimation it is reasonable to include the uncertainty of each work package in each dimension. In doing this, the plot can get a little untidy, but is a visual way of including a level of detail from the workshop discussion.

The next step is to fit a 2x2 grid to the chart, putting the work packages into 4 separate groups.

In the left-hand chart, I presented 4 equal quadrants, but it is valid to have the segments unbalanced as seen on the right. This is valid if it is found that too many work packages are in 1 quarter or the work packages in 1 segment can easily be isolated, even given uncertainty. Equally, choosing which side of the dividing lines each work package should fall is a judgement call for the workshop.

So, which work packages should you do next? The obvious answer is high value with low effort giving you maximum bang for your buck. Following the same logic, avoid the Low value high Effort work packages.

But is it this simple? As we have said, value is determined differently by different people:

• Value to a salesman is how many units they can sell and at what price.
• Value to the operations manager may be to reduce the number of customer issues being raised, either to keep support headcount down, or to help increase a metric like Net Promoter Score.
• Value to a developer might be how little mundane or repetitious work needs to be done. In removing repetition from a developer’s day, may reduce error rates and increase throughput of work, increasing their ability to deliver more, reducing the scale of some of other work packages.
• Value to the business may be alignment to strategy, for example where a salesman may want to sell a lot of the same old thing, the business could recognise this as a dead-end and see a need to pivot.

So, there are a few opinions that can either be merged to define a single consensus value or kept separate to generate a few diagrams and express how different parts of the business see value. Where it is often possible to factor all these opinions to be by financial value, this feels like a step of extrapolation that is prone to interpretation, biasing and frankly rigging. Keeping this dimensionless, purely working on a relative scale (A has more “value” than B) does enough to gain the insight needed.

For now, let’s assume we have managed to gain consensus and merged the opinions of value into a single axis. The following figure shows what action should be taken with work packages appearing in each quadrant of the diagram.

In this 4-box model an activity for each quadrant:

1.    DO – This work is small enough to have a degree of certainty and delivers high enough value that getting on with it is logical. If there are so many work packages in this quadrant you are still left guessing, then going through the same process again only for work in this quadrant is a good way of setting priority. An alternative method is to look at the level of uncertainty in each, there may be some that are more certain than others and if you can’t say definitively one will deliver more value – then deliver the most certain.

2.    Delegate – In many businesses there are junior team members. These small work packages are ideal to help develop these team members. A reason they are low value is often because they are low impact. So, this is where you can afford some “getting it right”. It is better for the junior team members to learn from the senior ones and pair with them on higher value work, but sometimes, a bit of working on their own helps to consolidate their developing ability and gives them a feeling of self-determination and pride in the work.

3.    Break-up – Clearly not tackling these big high value work packages will mean the business may misses out on a lot of business, new markets and even fail because they didn’t take a calculated risk. The way to minimise this risk is to spend some effort on gaining understanding of these larger work packages through technical spikes and research, breaking them into multiple smaller work packages and addressing each as its own piece of work.

4.    Cherry-pick – This is like Break-up as it demands further understand of the larger work package. Having decided these work packages are low value this isn’t high priority, but it is possible that some of the larger work packages contain some smaller ones that could add standalone value sufficient to warrant execution.

Should you wait until your “DO” pile has gone before you look at the other quadrants? If you want to be able to consistently deliver value to your customers month on month the answer is no. Let’s say you deliver everything in your DO quadrant in 6 months, for this time you have very happy customers, lots of value being created, and a build-up of pressure on the recipients to realise value. Then you have a fallow period, where you are researching, understanding, breaking-up and delivering the lower value work. To the customer this looks rather stop-start and any customer just starting their relationship with you in this fallow period will question how good a supplier you really are as “nothing new turns up and my needs aren’t being met.”

So, to keep the delivery train chuffing along, you need to spend some time looking at the larger packages of work, cherry-picking and breaking-up, in effect moving elements of them into the lower effort end of the spectrum. This means you keep delivery at a consistent level.

This is like the 70/20/10 rule used in many sectors, but for software is often described as:

• 70% - Core innovation
• 20% - Adjacent innovation
• 10% - Disruptive innovation

In the terminology here we might consider this as:

• 70% as Do and Delegate (probably 80%+ in DO)
• 20% breaking-up and Cherry picking (again 80%+ in break-up)
• 10% creative off plan

Off plan… a new idea introduced very late in the discussion, but get real – we haven’t thought of EVERYTHING, some stuff will have just been forgotten, thought of at just the wrong time, based on a totally new technology and not understood at all. This doesn’t mean it should be ignored, in fact it means that some dedicate effort is required to understand it and get it factored so that by a later planning session/priority review it can be added to one of the 4 boxes and perhaps change order of some existing items, making some easier to achieve, or increasing value of others.

With all things planning – this isn’t a single event, done once, set in stone, and passed down to the troops. It is an inclusive and continuous process, punctuated by reviews and direction checks. For most team members, it need not consume a huge amount of their time, but it will give everyone an understanding of the context of their work, see how they are contributing to the business’s mission, empowering and helping all team members feeling their worth.

This method is like the Eisenhower Matrix used for assessing priority and importance, have a look at Robertson Hunter Stewart’s vlog on this if you are interested.