Becoming agile

Agile, through the storms

Archive for the tag “Professor Deming”

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. Read more…

Advertisements

Built for Endurance

You just need to take a look at a crocodile, to see that this species goes back to prehistoric times. Same goes for the Komodo Dragon.

Source: http://en.wikipedia.org/wiki/Komodo_dragon

How come these creatures have endured so many thousands of generations? This will be part of the talk I will lecture on at the Agile Practitioners 2012 conference. I believe that the reason for the success of these creatures is that they are built (so to speak) for endurance. The single value, if you can call it that, that unconsciously guides these lizards to propagate, is to create successive generations that will succeed to produce further successive generations. A pretty Darwinist view, no doubt.

What has this to do with software organizations and agile, you might ask?

Many organizations declare mission statements, and values, and vision. This may come as a paragraph of text, a few bullets, or words:

“Our goal is to dominate the <Paste-Your-Business-Here> market”

“Provide superb customer experience”

“Low prices always”

What would be an adequate value for a software organization? In my view, Built for Endurance” is a worthy goal. Something that can permeate throughout the company.

A few examples:

What would be the effect of adding a 4th question to the SCRUM daily standup: “Is this sprint Built for Endurance”? What would that do to the team’s quality targets? Will surrendering to external pressure to deliver bring the team closer or farther from this value?

What would requirements look like, if the Definition of Done will include the statement: “Built for Endurance”? Will this guide the Product Manager/Owner to require better tests in the criteria?

What would the sales organization sell to customers, if they sell solutions that are “Built for Endurance?”

How about Human Resources? What would attrition rate be, if HR is called to support a work force that is “Built for Endurance”?

In my view, quality is very much about endurance, and very little about testing. If your quality organization relies on testing, you are probably trying to prove where your product and process is not endurable. If, however, you wish your products to be endurable, try thinking about the earliest point in the process to take this into consideration.

Where would you start? I will share some more insight about my talk in the coming few weeks. I will also be happy to hear from you about your ideas.

Post Navigation