Agile: is it hype?

In January 2014 I wrote a blog ‘Designing for Agility’. I’ve just re-read it to see if/how my thinking has shifted since then.  I’ve been prompted to do this because, this week I again heard myself saying again that ‘agile’ – as applied to organisational design and effectiveness – is a massive hype that has, as the authors in one article point out, ‘entered the business lexicon like few other terms in recent memory.’

In 2014, when I wrote the blog, I don’t think I heard/read the words agile/agility as much as I had by 2016  when I was reading that agility has become a ‘meaningless buzzword …  It’s another word business leaders use to sound dynamic and edgy (often while laying off staff), like disruptive, innovative or even intrapreneur’.

Another two years have passed and the rate of usage of the words agile and agility seem  to be still shooting up.  Is it even more meaningless now?  Are there degrees of meaningless-ness?  Has the hype has overtaken good sense?

One of the issues around the meaninglessness is because definitions around agile/agility ‘remain loose, situational, informal, confused, and sometimes non-existent.’ (Chris Worley’s words). This lack of definition is one of the issues that makes me uneasy about the agile  ‘movement’.

Lucy Kellaway, takes a sideswipe at agility in her (2009) FT management guff column, saying,  ‘The latest Harvard Business Review contains an 11-page article telling us that the best way to survive financial meltdown and global recession is to be like Muhammad Ali when he met George Foreman for their Rumble in the Jungle in Kinshasa, Zaire. What the renowned boxer’s performance teaches us about thriving in turbulent markets is that we must all be agile and we have to absorb blows. The point is helpfully summarised by various charts, diagrams and a two-by-two matrix with agility up one side and absorption along the other.’

Agile may be a meaningless buzzword,  the definitions may be loose, and it’s easy to knock the movement, even so, the intent of it is worth looking at.  It is intended to act in the spirit of the 2001 12-principles Agile Manifesto. However, that’s where another of the issues lies.   There’s a tendency to take aspects of the agile methodology and principles – which were originally devised for a better way of developing software – and try to apply them in a wide range of business contexts and situations, in the hope that by the application of the selected principles the organisation will be(come) more adaptable and responsive to the operating context.

However, as a McKinsey podcast points out ‘that agile is not a menu of things from which you can cherry pick … you need to think of them in a holistic way. You can’t just cherry pick a few of them … it’s a system.’   Saying you’re ‘doing agile’ if you are running daily ‘stand-ups’ is not going to make an organisation ‘agile’.

The band-wagon effect of wanting to be or do ‘agile’, reminds me of similar attitudes to TQM, Six Sigma, Lean, Continuous Improvement, and other methodologies which have emerged over the decades and which were each the ‘flavour of the month’  at some point.  (See a comparison of TQM, Six Sigma and Lean here)

Agile is of the same stock as these – not only because it is a ‘flavour of the month’ but also because it has a similar intent to all these methodologies in aiming to build the adaptability and responsiveness necessary to do well in the emerging context through   plan-do-check-act types of cycle (in agile, often called ‘test and learn’).

In also has roots in other methodologies.   A colleague, asking me what I thought of agile, offered his views: ‘From my fragmented research it seems there is a link [to agile] between ideas from old school socio-technical systems, participative methods, self-managed teams, and distributed leadership (though rarely acknowledged) … fashionably re-packed.’  And in another conversation I had on agile, socio-tech was mentioned as having some similarities to agile.

I am not saying that we should not aim to be adaptable and responsive, to put the customer first or to give workers more autonomy and discretion.  All of that is laudable but it is not new or specifically ‘agile’.   In fact, I don’t think there is much about ‘agile’ that we haven’t discussed, seen, worried about or worked with before, agile is not new or different.  It is well-packaged to look new and different.

Another example, take the recent McKinsey article Leading agile transformation: The new capabilities leaders need to build 21st-century organizations, in which the authors discuss nine new leadership capabilities:  Shifting from reactive to creative mind-sets, fostering innovation/collaboration/value creation, helping teams work in new ways, design thinking and business model innovation, applying the principles and practice of agile organisation design, shaping an agile organisational culture.  (We discussed the article on last week’s Organization Design Forum, Global Conversation –  you can register to join these regular global conversations that discuss articles listed in the monthly newsletter).

To me, adjusting for the language of the time, these capabilities are pretty much the same as Deming’s 14 principles of management (published 1982) or the leadership traits that Peter Drucker talked about in his long career.  I can’t really see anything about the capabilities that is ‘new’ or specific to ‘agile’.   Although, if pushed I could agree that ‘design thinking’ is ‘new’ at least in this context, but hardly ‘new’ in the history of design.  (On Design Thinking see a view from Natasha Jen, Design Thinking is Bullsh*t).

If the leadership capabilities and the methodological concepts around ‘agile’ are not new, then what is it that ‘agile/agility’ is promising that we are so entranced by?  In our focus on the buzz we have not examined closely what the promise is and, more importantly, whether it can be delivered on by ‘agile’.   I think we think the ‘agile’ promise is that it will enable us to cope with the utterly different context (geo-political, social, economic, technological, etc) that we face.  And we can’t resist that promise.

In an excellent piece (thanks Stefan for sending it to me), Dude you broke the future, sci-fi writer, Charlie Stross tells us how he used to be able to write good sci-fi by a recipe of ‘90% of the next decade’s stuff is already here today… another 9% of the future a decade hence used to be easily predictable … it’s the 1% of unknown unknowns that throws off all calculations.’ He continues saying, ‘’But unfortunately the ratios have changed. I think we’re now down to maybe 80% already-here—climate change takes a huge toll on infrastructure—then 15% not-here-yet but predictable, and a whopping 5% of utterly unpredictable deep craziness.’

And it’s here that I am alarmed.  I see us jumping on what appears to be a very attractive, agile band-wagon.   Who can resist the McKinsey metaphor, ‘as a gardener, the agile leader might pay attention to creating the fertile soil and environment that will enable growth and creativity to flourish.’?   The metaphor sounds lovely, aspirational even, and that is where we are stuck at the superficial non-critical level of agile’s promise.  We are not thinking deeply and talking reflectively and collectively about the ‘deep craziness’ in which we are living.

This ‘deep craziness’ is one where are lured by the metaphor of ‘creating fertile soil’ and faced with the reality of, ‘A third of the planet’s land is severely degraded and fertile soil is being lost at the rate of 24bn tonnes a year, according to a new United Nations-backed study that calls for a shift away from destructively intensive agriculture.’

Everywhere we look we see multiple world-issues  of this scale that we are ill-equipped to respond to.   

Is what we talk of and practice asAgile’ the route to handling this level of challenge?  Is it hype or does it hold a real and realisable promise?  Let me know.

Developing the transition plan

(Each of my blogs in August is an edited extract from my book Organization Design: the Practitioner’s GuideThis is the fourth – from Chapter 6)

Imagine that in the design phase the high-level design team has determined that the organization should no longer be a bureaucratic hierarchy, but be a ‘flatarchy

The characteristics of this flatarchy are very different from those of the current organization. As part of the design work, the design team has developed a ‘from–to’ description

Your task now is to develop the detailed design of the ‘to’:  how many people, what are their skills, what will they be doing, how will they be working, what technology will they be using, what work processes will they be following?

Start by arranging a ‘kick-off’ meeting with the people who worked on designing the high-level model and the people who are going to take this model and work it into a detailed plan for the transition that takes the organization from current to new design.

Think of the kick-off meeting as like passing the baton in a relay race between one team and the next. The difference is that the designing group tends to be one team (although that is not always the case) and the planning group tends to be several work teams, (although, again, this is not always the case).

The kick-off meeting should:

  • Review the work that has happened to this point.
  • Confirm the chosen high-level design option (consider retesting the design for workability and capability to deliver the future state).
  • Log any amendments, new ideas, issues and concerns.
  • Identify obvious areas of work to close the gap between the current and new design
  • Setup teams to work on each area of work with a designated team lead.
  • Do a very high level scope of each team’s work and develop the broad-brush initial actions and outputs envisaged by each work stream. Use activity cards or a Kanban board to keep track.
  • Schedule the next few meetings.

Each team’s task is to work out what, for their part of the system, has to happen to move from the current state to the new organization design. Their work must align with the work of each of the other teams to deliver something that is more than the sum of the individual parts.

Working through this gap-closing exercise to carry out all the tasks and activities needed and putting them into a project plan with milestones and resources required takes time and is an iterative process that starts during the kick-off meeting. Judging how much time is reasonable to allow for transition planning depends, among other factors, on:

  • the scale and complexity of the design project;
  • the level of comfort staff feel with more or less depth of detail and planning; and
  • whether stakeholders are willing to start transitioning some aspects of the design ahead of others.

Borrowing some of the methods of agile methodology and applying them to the transition planning is one way of speeding up this phase and entering the transition phase.  For example, the concept of ‘minimal viable product’ is helpful. In software development, this relates to a point when a new product is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.

For this phase of organization design, consider what are the absolutely key things that have to change in order to move from the current to the future desired state (determined by impact, or consequences of not changing, etc.)  Plan these first, and then start to action them as you continue with the transition planning.  Starting to act as planning proceeds prevents people from getting stuck in the planning.

Another agile concept that can be usefully applied during this detailed design work is that of ‘sprints’. One organization introduced a hybrid of agile methods, including sprints, to OD projects and explained the approach through a series of ‘Rough Guides’ – one for each phase of the design method. The Guide to Transition Planning opens with the statement:

We are increasingly familiar with agile methodology and terminology. Agile is an alternative to traditional PM, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work, known as sprints.

This Guide shows you how to use the agile methodology and terminology in the transition planning phase of an OD piece of work.

In this approach, transition planning teams work in a series of sprints with daily stand-ups.  An OD lead and the project manager hold daily stand-up meetings with OD leads from the work streams. The OD team members keep track of consistency across the pieces of work and, as the detailed planning proceeded, liaise with the project manager on what should go on the plan.

At the end of each two-week sprint the teams meet in a workshop to review progress on the design, discuss what they have learned and/or tested, and agree the objectives for each team for the next two weeks. Usually after a 3 or so 2-weeks sprints most aspects of the high-level design have been detailed, tested further, verified and validated, and an implementation plan is ready to be signed off.

In a more traditional approach, each team lead reports weekly to the project manager and OD lead, who co-ordinate, monitor and support their activity. A straightforward and useful way of capturing weekly progress is through ABCD reports, where A = Achieved this week; B = the Benefit this activity has brought to the project implementation planning; C = any Concerns or issues that have surfaced during the week; and D = the planned activity for the coming week (to Do).

This is a simple format for keeping the detailed design teams on track and feeding information to the project manager that will go into the plan. Each team lead completes it for their team. The team leads circulate their updates to one another for discussion at a weekly face-to-face or telephone meeting with the project manager and OD consultant. Following the meeting (when actions have been agreed), the project manager consolidates the information in one document and circulates it to the project steering group members, along with the plan on a page from the starting phase to refer back to and discuss/amend in the light of reported progress.

As this detailed planning work proceeds, the project manager focuses on three things: ensuring that each work stream is delivering to target, populating and updating the transition plan, ensuring alignment with any parallel initiatives or other work going on in the organization that will affect the new design but is outside its scope.

Making the connections with interdependent projects and work is helped, not only by formal governance, but also by encouraging informal collaboration and transparency across the organization and asking questions, for example: ‘Are we making the connections?’, ‘What are we missing?’, ‘What are the possible impacts of what I am doing on other aspects of work I know about?’ Also ask employees to raise an alert if they see a ‘join the dots’ opportunity that may be being missed.

The ‘product’ coming out of the detailed designing usually includes the following:

  • a developed, articulated and communicable vision of the new organization;
  • clearly described and agreed business objectives and measures;
  • the detailed organization structure (levels, layers, spans, linkages, co-ordination mechanisms);
  • mapped core business processes/workflows with interdependencies and hand-off points;
  • defined units of work that feed into roles and jobs;
  • descriptions of the jobs and person specifications with decision and authority levels;
  • descriptions of ways of working (behaviours, principles, protocols);
  • a transition/implementation plan that closes the gap between the current and the new design state with a timeline and metrics.

How do you do the detailed planning to move from a current to a new design?  Let me know.

Image: Planning v improvisation