News

One of the significant benefits of using an Agile flow-based delivery model instead of large batch product development is the ability to change direction easily, not just at the level of the individual team working on a single initiative, but across the whole portfolio of work being undertaken in the organisation.

This provides the ability to tactically respond to churn in the marketplace, to feedback from customers and to changes happening in the ecosystem surrounding the organisation.  Tactical changes can influence strategy and tactics can be adjusted rapidly in response to strategic changes.

This is easy to say, however for many organisations it remains hard to achieve.  Mainly because the traditional thought processes and definitions of success get in the way.  We not only need to change our structures to support the new way of working, we need to change our thinking to enable a new focus on value.  These are not easy changes.

VUCA

The world is in a state of VUCA:

• Volatility – the rate of change is faster than has ever been experienced before, and is getting faster
• Uncertainty – we have no clarity about future outcomes and even when we believe we know what we want to achieve the rate of change means the goalposts move before we’ve had a chance to do more than take a few steps in their direction
• Complexity – there are myriads of factors which interact to influence the outcomes we could achieve.  These interactions are often unclear until after they have happened
• Ambiguity – there is haziness in almost every view of the future, we easily misinterpret events, their consequences and their causes

This presents a challenge 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 adapt to the VUCA realities which surround us. 

Agile Delivery is Necessary but not Sufficient

Agile software development was initially a reaction to the failures of predictive approaches to software engineering, it takes an empirical, feedback led approach to building software and has some key characteristics:

• Value driven, prioritised features
• Cross functional, empowered teams with all the skills needed to deliver working solutions
• Short cycles of work
• Close customer collaboration
• Rapid feedback
• Constant learning and adapting for both the product and the process

These characteristics result in better outcomes at the individual product level, and Agile software development has become the most prevalent approach to building software today.  

There is a new generation of software development team who have never worked in a “waterfall” project, those for whom the idea of trying to work in a predictive, sequential way from detailed requirements defined completely upfront is an anathema.

Agile development is undertaken by using a prioritised list of discrete items of business value to define the sequence in which items are worked on.  This “backlog” is stack-ranked and work is flowed through the system one item at a time, with each item being completed (to the production ready state) before the next one is started.  The backlog can and should be reprioritised frequently based on feedback from the customers and what they have learned by using the product in the wild. This reprioritisation can be as frequent as daily for highly volatile environments (production support using Kanban, for example) or less frequently where iterative delivery is used (eg in 2-week sprints if Scrum is the delivery framework).   By keeping the discrete items small the flow of work through the system becomes predictable and responsive to changing customer needs.

Agile software development works at the individual team and product level, and for complex products where multiple teams must collaborate in a program of work, there is a variety of “scaling” approaches which can be applied.

By constantly working on the next-most-important thing teams able to stop work on a single product at any point and what has been done will be valuable.  The Pareto principle is able to be applied – 80% of the value from any system almost always comes from just 20% of the features, so once the value threshold has been passed it makes sense to stop work on that product and focus on something more important for the organisation.

To truly get the benefits of Agile development, however, the organisation needs to rethink how we work at the portfolio level.

Adaptive Portfolio Management

By taking the idea of a prioritised backlog and extrapolating it to the level of the whole organisation we can have an adaptive portfolio.  One where the work being done at any time across all the teams is always the most important set of work that we should be doing.  The rate of reprioritisation is different to that used at the individual team level, and there needs to be good feedback mechanisms so the delivery of value can be made clearly visible from the teams up to the portfolio governance level.

At the portfolio level, it is important to be able to stop one initiative and switch the team(s) to work on something that is more important, once sufficient value has been delivered.  This may be sooner than was planned in the first place or it may be later – the metric of success is not meeting an arbitrary date or even a fixed budget, rather it is maximising the value to the organisation from the work done on an initiative, as illustrated in the diagram below: 

Some initiatives will be highly experimental and should have planning cycles measured in days and weeks, others may have more certainty in their understanding of customer needs and may have longer planning cycles, sometimes with roadmaps extending out for a year or more.  Even with long roadmaps, three months should be the longest planning horizon for almost any initiative, the reality is that longer planning cycles will be subject to massive pent-up change.

The cycle in which initiatives are re-evaluated should be related to the planning horizon of that particular product.  If there is a 3 month planning horizon for an initiative then the governance checkpoint should be every six weeks.  

The key is to be able to ruthlessly evaluate the value delivered by an initiative and recognise when the cost of building the next piece exceeds the value which will be derived from having that piece.  Stopping work on an initiative does not mean disbanding the team, rather it 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.

An adaptive portfolio is a key characteristic of a truly learning organisation, one that listens and responds to the ever-changing voice of their customer.  

"In the long run, the only sustainable source of competitive advantage is your organisation’s ability to learn faster than your competition."
Peter Senge

Post by Shane Hastie