Becoming agile

Agile, through the storms

Don’t reorganize – Deorganize!

Organizations tend to do this every now and again: Reorganize the structure to suit a new strategy, a change in the management team, try out a new hierarchy model, and so on.

In this post I lay out some alternatives, and end with a practical first step.

One of the pitfalls of reorganizations is that they provoke a huge amount of anxiety and resentment: people’s direct and indirect managers change, their role description changes, their promotional path becomes unclear.

I would like to suggest a different approach. Instead of a reorganization, gradually deorganize. Shed away redundant structure, and replace them with loose structures. Allow your organization to grow in response to real market needs, and not according to a decision that was made a couple of years earlier based on data that may have been momentarily correct, but have become irrelevant for today’s reality.

Sounds impossible? Actually, you see such structures every day of your life. When you see ants collecting food for winter, when you see schools of fish swimming together, when you watch migrating birds practicing towards their long flights and when they embark on their fantastic and inspiring far-away journeys.

Waders in flight Roebuck Bay. Photo by Mdk572, Source: Wikipedia http://en.wikipedia.org/wiki/Bird_migration

These structures are not decided upon – they emerge according to changing needs of the group. Even ants have changing realities: when their nest is being attacked or flooded, as well as when they prosper and have food in abundance to accumulate for rough times.

In our business life we like to think that we can create strategies that can predict our organizations’ growth and needs for upcoming years. The truth is as far from this as can be. A good strategy is one that enables the organization to continually change in reaction to its present reality.

There are several keys to enable such strategies. There must be more, and I will share the ones I can think of now:

  • Build the organization around stable, self-organized, self-maintained teams. Birds breed, old birds perish, and the survival of the individuals depends on the continuity of the flock.
  • Build teams around the teams to manage their boundaries, and not manage their people. There is no chimp or seagull in command – and yet there order emerges; the role of the leaders is to protect the boundaries, not to order individuals what to do next.
  • Create mechanisms to identify dependencies and dissolve them to increase their self-organization and self-maintenance. Survival of the fittest is not the strongest in physical strength; rather the ones most fit to endure change – guide your teams to the changing reality.
  • Reduce integration effects among teams by modularity of the teams’ products. Species that depend on a small variety of foods find it harder to survive. Unless…
  • Sometimes dependencies are inevitable, if only for a transient period. Encourage such teams to develop mutual relationships that will lead to win-win conditions. Symbiotic creatures benefit from each others’ strengths, and protect one another from their weaknesses.
  • Like ants, continually prepare for rainy days. Education, refactoring, learning, are among the activities that will enable such teams to survive rough times
  • Encourage diversity within and among teams. Diversity may manifest itself in members’ credentials (developers, testers, writers, …), seniority and experience, idiosyncrasies, gender, and more. A beehive with only queens or workers will not survive.

If you are a leader in your organization, and you want to learn how to respond faster, how to enable your teams to surpass even their own predictions, start by learning what makes your organization rigid in its current form.

Dan North, the originator of BDD and Deliberate Discovery, will be holding this one day workshop at the Agile Practitioners 2013 conference.

As Prof. Deming so elegantly put it: “Learning is not compulsory. Neither is survival”.

About these ads

Single Post Navigation

6 thoughts on “Don’t reorganize – Deorganize!

  1. Execlent post! I love your writing.

  2. Tobias on said:

    A truly lovely post to start the new year. Immediately twittered :)

  3. Geoff Wilson on said:

    This post really got my attention, as it maps well to the lessons we have learnt in our agile journey. We currently have around 30 teams across four locations working approximately as you describe above.

    Some of the challenges we’re now facing include how to handle bigger projects/features that span multiple teams, how to spread learning across teams, and how to get consistency on the few things that are needed (eg. some consistency on use of production environment, consistent UX “feel”)

    I look forward to your future posts, and please feel free to get in touch as I’d be interested in chatting further.

    • @Geoff,
      I’m glad that the post hit a chord – shifting to this kind of structure requires courage, more so in large enterprises where are are so used to traditional management styles.
      As for projects spanning multiple teams: In the same token as this post, I say: “Don’t Scale Agile – Descale Agile!”. That is, the fantasy is that we will enforce a common architecture or common look and feel that it will defuse into the teams – but this does not happen.
      Instead, I am suggesting to put more trust in the teams, and to let inter- and intra-team forums develop these standards. This is no trivial task, because teams need to evolve into it, and managers need to evolve out of former structures.
      You can read more about it in Henrik Kniberg’s Spotify case study here: http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
      Indecently, I also use the term Guilds, as per this article, to foster a community of professionals (developers, testers, architects, and so on) at the clients I work with. The term Tribe refers to stability of the organisation.
      Let me know if you find Henrik’s article handy. In second thought, let Henrik know first, and me afterwards.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 980 other followers

%d bloggers like this: