A visual approach to demand management and prioritisation

Never before have technology teams been under so much demand. Technology leaders can struggle to manage these demands effectively, with common anti-patterns being:

• Putting up a series of administrative hurdles for stakeholders to navigate, such that only the most resilient will persist.
• Focusing only on the "loudest voices in the room".
• Making unilateral decisions about what is most important.
• Agreeing to do everything that is being asked of them, working harder than ever before in the hope that it is just a short term spike in workload.
• The answer always being "we need more resource".

All of the approaches above may relieve the pressure in the short term, but will fail to deliver long term sustainable value. Side effects are:

• A technology estate that becomes misaligned from the goals of the organisation.
• An increase in technology related risk.
• The rise of shadow IT.
• Attrition in your team.
• Burn out.
• The cost of technology getting out of control.

In this article we describe a simple approach that can be used to engage stakeholders such that they:

• Understand the full spectrum of demands being placed on the team; and
• Are actively engaged in consensus driven prioritisation.

This approach is founded on three core principles:

1. Maintain a healthy balance.
2. Embrace agile principles.
3. Use visual tools.

1 - Maintaining a healthy balance

To achieve a balance, the different "types of work" need to be defined. This will vary for different organisations, but a typical example for a product based engineering team would be:

• Functional delivery - any effort concerned with building new features. This spans all stages in the lifecycle required to get "code ready to ship". This can often be split further into sub categories (such as requirements gathering, designing, coding and testing) to enable the balance across these lower level activities to be understood, but this level of detail is not a priority.

• Releasing - tracks the effort required to get new features into production. This is a separate category to "functional delivery" above because it is often where friction is often encountered in many organisations. A measure of the effort involved in "releasing" is a good indicator of the overall DevSecOps maturity of the organisation.

• Reactive maintenance - captures all of the unplanned effort: such as reacting to outages, fixing production bugs and responding to tickets that have been escalated for 2nd line support. It is important to recognise this and "plan for the unplanned" by setting aside capacity in the team for these types of tasks. The level of effort involved in "reactive maintenance" is an indicator of technical debt being carried.

• Proactive maintenance - is effort expended addressing issues commonly referred to as "technical debt". This includes addressing poor design or implementation decisions that were made for expediency. More significantly, it includes externalities, such as changed circumstances reflected in new, upgraded, or defective 3rd party dependencies; and new non-functional requirements. This will typically involve upgrading infrastructure and refactoring code.

• Continuous improvement - encompasses effort invested to remove technical impediments that impede the flow of delivery or put existing delivery at risk. Prime examples are building tools that automate repetitive processes in order to remove human effort, reduce friction and de-risk processes involved in building, testing and releasing code.

• Learning and development - involves giving individuals in the team space to learn new skills. This includes their personal training backlog as well as strategic skills.

• Other - a general bucket that can be used to track effort that does not fall neatly into any of the categories above. This should be negligible and typically captures obligations placed upon the team by the wider organisation. Recording effort in this category enables teams to discuss specific examples and to either accept it as a "necessary evil" or to do something about it.

In general, teams should seek to reduce effort in the categories of "Releasing" and "Reactive maintenance" by investing in "Proactive maintenance", "Continuous improvement" and "Learning and development". The former categories should be considered an "overhead" whilst the latter categories generate long term value for the organisation by committing to life long investment in people, processes and tools that will drive down the Total Cost of Ownership (TCO).

The categories above may not be a perfect match for your organisation, but the key is to:

• Define the categories that are right for your team - use the definitions above and adapt them as you see fit!
• Build a view of ACTUAL effort against these categories - capture how much effort is expended by your team on each of these categories. This doesn't have to be an exact science: for example, at endjin we analyse Slack posts and time sheets to build a company wide view of effort across these types of categories;
• Agree the TARGET - work with stakeholders to help them understand why each of these categories of work is necessary and why some are critical to generating sustainable value. Get their buy-in to a notional target split of effort across these categories. Use this to shape prioritisation so that balance is achieved across these different types of work.
• If necessary, map out the TRANSITION effort mix that will be necessary to move from the ACTUAL to the TARGET. This will often involve making short term sacrifices in some areas in order to create room for the team to address backlogs that have been built up. It may also involve retiring digital assets that are no longer generating sufficient value for the organisation - see digital asset register blog for more details.

The diagrams below illustrates the concepts of ACTUAL, TARGET and TRANSITION, showing an example for an organisation that:

• Is currently captive to reactive working (see actual).
• Has an aspiration to address this by adopting a more proactive approach (see target).
• Recognises that short term compromises will be required in terms of functional delivery in order to transition to the target state (see transition).

Embracing agile principles

For many organisations being "becoming agile" can become too focused on the strict adoption of methodologies such as Scrum, at the expense of loosing sight of the principles on which it is founded.

A common example of this is where agile is used to carve a large project up into weekly sprints, but where the release of production software is many months downstream - this is commonly called "scrumfall". This defeats one of the key benefits of agile: which is to get features out in front of end users as soon as possible and to use the feedback that they provide as valuable learning to shape future releases - i.e. to enable the "build, measure, learn" cycle.

This can be compounded by the tendency for stakeholders to overload their requirements, because they believe that this is the one chance they will have to build all of the features they "think" end users will require.

This principle of rapid cycles of "build, measure, learn" is fundamental to getting meaningful value out of agile practices. If your stakeholders or your team are not bought into this, there are likely to be more fundamental issues that need to be resolved such as:

• Applying new product development practices so that more confidence can be built before committing engineering resources to building an MVP, and / or;
• Investment in DevSecOps capabilities so barriers to releasing production software on a weekly cycle are removed and the team can commit to releasing at that cadence.

The other principle here is that agile practices rely less on detailed planning of the entire project and more on:

• Where less effort is spent on planning the next 6 months in detail, and more effort to be spent on articulating granular goals for each iteration.
• The concept of "squads" or "pods", which are small, self organising, multidisciplinary team that are "protected" so that they can focus on delivering iteration goals.
• Where the "definition of done" means simply that new features are released into production and put into the hands of users at the end of each iteration.

Use of visual tools

The use of visual prioritisation supports the two principles above, where:

• Swim lanes are used to encourage the right balance to be maintained in each iteration.
• Agile principles are applied by requiring work to be sized so that it is small enough to be committed to a single iteration and plans are constantly reviewed based on feedback loops.

The prime objective of visual planning is stakeholder engagement. By adopting an approach that is simple and light touch, all stakeholders can actively engage in the process. This promotes collaboration, leads to consensus and achieves collective responsibility.

A generic example of visual prioritisation tool is provided below. In practice it can be implemented using a whiteboard and coloured sticky notes or using a collaboration tool such as Mural.

Here's how the process of visual prioritisation can work in practice:

1. Stakeholders from any part of the organisation submit high level "ideas" for consideration in the forthcoming planning iteration - in this example a calendar quarter. Ideas are typically submitted via a simple proforma that captures key information in a succinct but structured way: title, short description, category (e.g "new feature" or "proactive maintenance"), value and OKRs impacted.
2. Each "idea" undergoes initial validation and "T shirt sizing" by team. If necessary, the idea is decomposed into smaller components so that each component can deliver value in its own right yet be accommodated within a single iteration.
3. ALL stakeholders attend a prioritisation meeting every quarter to review progress and agree what the team should commit to in the quarter ahead.
4. The meeting begins with reviewing the previous iteration, focusing on any impediments that were encountered during that iteration that prevented objectives being met.
5. Attention then shifts to agreeing what the team should commit to in the next iteration. The visual prioritisation tool above is used as the focus for this part of the meeting. Where necessary, stakeholders will make the case for their ideas to be prioritised over others.
6. There will generally be more "ideas" than there is capacity to accommodate, the visual board is used to maintain a healthy balance across the different effort categories. Throughout, somebody senior is in attendance (e.g CEO or MD) who can act as overall referee if necessary. In our experience, this type of intervention is seldom required as stakeholders tend to reach consensus once they understand the wider set of demands that are being considered.
7. Eventually, the priorities for the coming iteration are agreed and "locked in".
8. All agree to assume "collective responsibility" once they leave the meeting by speaking with one voice regarding the decisions that have been made.

Conclusion

The benefits of this approach are:

• Sustainability - by reinforcing the need to balance effort across different effort categories to protect the longevity of the digital assets and the technology team(s) that are responsible for them.
• Transparency and engagement - by running a transparent process where all of the key stakeholders are "in the room" reviewing all the demands and are actively involved in making prioritisation decisions.
• Asset management - it integrates with other processes such as a digital asset register to promote strategic treatment of technology assets.
• Continuous delivery of value - the workstreams promote a constant stream of high value effort, by putting an emphasis on proactive rather than reactive working.
• Exploiting agility - by involving stakeholders from across the organisation, the true value of agile practices can be exploited to flex priorities dynamically according to the evolving needs of the organisation.
• Digital transformation - helping senior stakeholders to understand how to wield the technology resources available to the organisation to achieve strategic goals.

Good prioritisation is not a skill that is unique to the technology domain. Other departments in your organisation will be facing similar challenges, so you have an opportunity to partner with others to share best practice and develop strategies that work for you and your organisation.