Agile Planning Cadence
Linking strategy to execution in the agile organisation
In Building the Agile Business we discussed pace layering as a way to understand agile planning and the different cadence at which elements of an organisation change. In Agile Transformation I took this further into how to link organisational strategy (which changes more slowly) through to adaptive execution (which is faster moving and changes more rapidly).
The recognition of the different cadences at which organisational components, strategy, and execution operate mean that we can create greater impact in value creation and change, and understand how to link the layers together in ways that make sense. Stewart Brand, in describing pace layering, talked about how:
‘Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.’
All durable systems, he says, have this kind of structure and this is what makes them adaptable but also robust:
‘Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and by occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power.’
Søren Raaschou’s concept of Agile Planning Circles is a nice build on this. Seeing planning as a layered discipline is an ideal way to navigate and reduce complexity. He references Mike Cohn’s ‘planning onion’ as a basic layered structure where planning is iterative but iterates at different cadences from annual strategic planning through to daily execution.
The idea of the agile planning onion is that the cadence and cycles become faster or more compressed as you go deeper with the inner three layers likely happening in the team environment — release planning works at the rhythm of the release cycle but it may take more than one iteration to fulfil a release cycle, and one iteration will likely comprise multiple daily standups. But planning like this enables the team to have good visibility and focus on what’s important across multiple horizons without getting tied in to an overly linear plan.
The outer three layers of the agile planning onion look further ahead. In product planning the product owner can look further out than the current release to consider the longer-term evolution of the product or system. Portfolio planning examines the potential of products to bring to life the vision of a business through its strategic planning, and where investment and effort should be made. Again, that link between organisational strategic planning and portfolio and then product planning is critical in implementing the strategic vision.
Some organisations (including some that I’ve worked with) fail to prioritise the creation of a product strategy that is closely aligned to the organisational or business strategy. The result is a weak or even non-existent product strategy which is not only poorly aligned with the needs of the business, but which can also result in product teams becoming very reactive and tactical, executing against the whims of multiple business stakeholders, leading to poor prioritisation and poor delivery of the company strategy and vision. In order to link business and product strategy well you need business stakeholders that understand the importance of product and product managers and owners that really get the business needs and strategy.
Søren Raaschou makes the point that a traditional Product Backlog can work well to contain what’s inside an Agile release cycle but if taken beyond this into product and portfolio planning can lead to challenges with maintaining the adaptability and true user focus that’s required. Breaking work down into Initiatives, then Themes, Epics and User Stories (work-breakdown structures) can be a useful way to link strategy with execution but it’s important to be wary of the kind of linear thinking that can creep in whereby in order to complete a Theme for example, we believe that we need to deliver all Epics within that theme. This belief about completing everything before continuing on can conflict with the agile principle of delivering the maximum value for the minimum effort. It’s not necessarily predictable up-front which User Stories or Epics will contribute the most value so we need to remain adaptive and able to re-prioritise at every stage.
Raaschou also notes how tempting it is to map a hierarchy of Themes, Epics and User Stories to organisational hierarchy and allocate ownership to descending levels within a business. The danger here is again that the delivery team become very executional and lose the autonomy that they need in order to make the best prioritisation and re-prioritisation decisions. Team members may also then lose the passion and motivation that naturally comes with the ability to really make a difference in the area that you are responsible for and in the visible contribution to and progress towards larger goals. Internal politics may also then skew the delivery of value towards individual interests rather than what is really needed. In Agile Transformation I frame this as a top-down-bottom-up melding of business goals with customer needs. At the team level the flexibility is needed to reprioritise around customer need and feedback and do what is most valuable for the minimum effort. The organisation still needs to pursue its strategic direction, but in a way that prioritises customer need and value.
The Agile Planning Circles that Søren Raaschou describes is a way of representing this and features three connected circles that operate at different cadences. The team, he says, should be responsible for both exploration and development with the team iterating in the green loop representing the classic build-measure-learn loop of lean start-up, and periodically moving into the blue loop perhaps using design thinking to explore new possibilities. The changing delivery and understanding can in turn inform the red strategy loop when needed but this of-course requires the engagement of the broader business in a deeper way. The loops don’t always follow a strict sequential order with the team doing what is necessary in order to deliver maximum customer value aligned to business goals. In a separate article Søren then goes on to detail the artefacts that may be used in each of these loops.
This is a really useful and practical way of linking business to product strategy to customer need and team delivery. It embeds an appreciation of the different cadences and layers of planning but also how they connect together. All the way through the process it is the interlinking of these circles that enables truly adaptive strategy and delivery.
For more like this, you can order your copy of Building the Agile Business Through Digital Transformation and the new book from Neil Perkin ‘Agile Transformation: Structures, Processes and Mindsets for the Digital Age’. You can also join our community to access exclusive content related to the book.
This post is also published on the Agile Business blog.
