Optimisation vs Transformation

By AgileBusiness, Disruptive Innovation, Strategy No Comments

transformation

There’s one metaphor that I’ve found to be particularly useful in my work with clients in helping to articulate the opportunity and challenge in making smart decisions around technology and transformation. Now, more than ever of-course, these kind of decisions are critical.

If we look for examples of change within nature perhaps one of the most obvious is that of metamorphosis. There are two key types of metamorphosis, incomplete and complete, both of which are good analogies for the true opportunity that technology can afford – the opportunity of both optimisation and transformation.

Incomplete metamorphosis: Like the grasshopper above, in incomplete metamorphosis a big grasshopper looks like a small grasshopper – it simply sheds its skin as it changes and grows. This is a good metaphor for optimisation. The opportunity to use technology to do what we did before but better, faster, more efficiently or in more scaled ways. There is huge benefit within optimisation. But a bad or outdated process optimised is still a bad or outdated process. So sometimes we need to do more.

Complete metamorphosis: The caterpillar transitions into the pupa or chrysalis stage where everything goes into a kind of biological soup, the physiology and functional structure of the animal changes dramatically, and out emerges a beautiful butterfly. This is a great metaphor for transformation. The opportunity to reinvent, reimagine, remodel because to realise full the potential of technology we’re required to redesign processes, structures, operations, and culture. The challenge with this is two-fold:

  1. The ‘messy middle’ stage of transformation which is typically characterised by higher levels of uncertainty and complexity
  2. The need to unlearn some of what we know in order to put it back together again in a different way. The need to avoid looking at the new through the lens of the old. The need to move on from what we were before and embrace the new. Don’t mourn the caterpillar. Be the butterfly.

Making smart decisions about the application of technology is about understanding where the opportunity is to enhance or to drive new efficiencies, and where we need to rip it up and start again. Optimisation vs transformation.

Dealing With Agile Team Dependencies

By AgileBusiness, Teams No Comments

When scaling agile working and small multi-functional teams through the organisation we need to remove the barriers that prevent teams from progressing and learning quickly. An important part of this is being ruthless about keeping the team small. But we also need to ensure that teams have the necessary support and input that they require, and that they can access what they need when they need it in order to generate and maintain real momentum.

The model of Agile team onions, originated by Agile practitioner Emily Webber, is a way of structuring dependencies which in a large organisation might include necessary functional inputs (perhaps ops, legal, analytics, compliance, finance etc) that are involved in some way in delivery but which are still situated in vertical silos, around the core team. The onion is a way of creating understanding about who is in the wider team, and inviting them in without disrupting the small (and effective) size of the core team. As Emily describes it:

‘This isn’t just a stakeholder map, it is about bringing the organisation in and having shared responsibility for what you are creating together.’

The onion is classified thus:

Core team:

  • Purpose: delivery of digital services
  • Communication: Daily (all stand-ups, retrospectives, planning, show and tells)
  • Co-located: daily, all day
  • Types of people: product owner, scrum master, developers, designers etc

Collaborators (who might be working with multiple teams):

  • Purpose: bring in specialist information to assist the team, assurance as needed, reduce dependencies and blockers (open doors)
  • Communication: regularly, they come to some agile meetings
  • Co-located: on a regular basis (as a guide ~2 days a week) — this also depends on what is needed and the phase of project — but enough to be able to not block anything
  • Types of people: other delivery teams working within the same portfolio, security liaison, policy liaison, portfolio manager, operations, suppliers etc

Supporters

  • Purpose: keep informed, feed into broad organisational priorities
  • Communication: every sprint / iteration (show and tells, ad-hoc when needed)
  • Co-located: monthly or as needed
  • Types of people: steering groups, senior leaders, wider organisation

Mapping out your team onion, inviting people in, agreeing expectations and protocols establishes the right footing for it all to work. So ultimately, an organisation may consist of many overlapping onions.

In this way, the core team is kept at a suitable size to maintain velocity, collaborators provide necessary inputs to maintain momentum, and supporters remove barriers and provide direction to empower agility.

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.

Agile Planning Cadence

By AgileBusiness, Strategy No Comments

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.’

The Agile Planning Onion

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.

Image result for nike cohn planning onion

Image source

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.

Agile Planning Circles

Image source

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.

Agile Transformation – Announcing the Launch of My New Book

By AgileBusiness No Comments

Agile-Transformation

I’m delighted to announce the launch of my new book Agile Transformation: Structures, Processes and Mindsets for the Digital Age. To help explain why I’ve written this book, and why I believe it’s themes and ideas are urgent and indispensable, I’m giving you a preview of the opening section to the book:

Writing Building the Agile Business was something of a cathartic exercise for me, having worked for many years to help corporates of all types become more native to the digital empowered world in the way that they think and operate. When we wrote that book our observation was that there was plenty of material that talked about the ‘why’ of transformation, but precious little that talked about the ‘how’. The book was designed to fill this gap, and thankfully it seems to have struck a chord.

The work that I’ve undertaken since that first book came about, working with a broad range of large global businesses, has served to validate a lot of the approaches that I set out in that book but it has also opened the opportunity to go deeper in to some of the fundamental areas of change and opportunity. I fully expect this book to also be a means to catharsis as whilst the business environment has fundamentally changed forever, many companies still haven’t truly adapted to face this challenge.

Digital technologies have impacted in countless ways to create a climate of rapidly changing competitive and consumer dynamics, heightened unpredictability and disruptive new market entrants, and yet many businesses remain stuck. Stuck in outdated modes of working that keep them from moving fast. Stuck with structures that originated in a different era and that actively hinder agility and horizontal collaboration. Stuck with processes that make bold innovation difficult if not impossible. Stuck with cultures that reward conformity and status rather than entrepreneurialism and originality. Stuck with approaches that celebrate efficiency over learning.

After several years of corporate focus on digital transformation many organisations still pursue rigid, linear change management programmes that are doomed to fail. Many still prioritise chasing shiny technology over empowering their people to drive lasting change. Many pay lip-service to new ways of operating without ever really changing the fabric of how the organisation works or building the culture that can genuinely support change.

More recently the potential of agile working and principles to generate business value far beyond technology teams has been recognised by some enlightened companies as a route to greater organisational agility. And yet in so many cases these principles remain poorly understood, undervalued, or badly applied. In some organisations the word ‘agile’ has become overused and abused to the point where it is no longer helpful, and where it fails to represent the true potential of what is possible. Many businesses are playing at the edges, or scratching the surface, or still failing to grasp the scale of change that is really needed.

If we are to truly reshape organisations for the new world we need to take a more sophisticated, adaptive approach to transformation. We need to rethink embedded assumptions about structures, processes and leadership that were born of a legacy, industrialised world. We need to understand how we can scale agile principles and culture appropriately to support lasting change. We need to take a far more sophisticated approach to the application of different ways of working, both new and old. There is a need to build on what has come before, to go beyond most interpretations of ‘digital transformation’ and to go deeper in to fundamental aspects of organisational structure, process, culture and leadership to help define what organisational agility really means and help leaders of all kinds to build a practical roadmap for lasting change. There is a wider need to reimagine what the organisation is, how it operates, and how it is lead.

Agile Transformation is about helping businesses to become unstuck. It is about generating an entirely new level of organisational agility. It is about transforming business to become truly fit-for-purpose for a very different world.

The book is published in the UK on October 3rd, and in the US on October 28th. You can pre-order Agile Transformation via Kogan Page the publisher or via Amazon. And you can of-course also sign up to our email list for periodic updates and exclusive content.