Build Flexible Organizations!

It is said, that one of the huge challanges of our time is the great volatility of end customer markets. To face this fact, many companies debate, how to cope with this new market reality. Not surprisingly there are thousands of solutions out there, eagerly sold by consultancy companies:

• You need a flexible and highly adaptive IT ecosystem (see SOA)
• You need to be flexible in handling your requirements (see, Agile, Scrum)
• You need flexibility in your high level planning processes (see Beyond Budgeting, Beta-Codex)
• You need flexibility everywhere. Google for "flexible it solutions" and you will find more than 60.000.000 hits...

But having implemented this "solutions", lots of companies find themselves in situations where they are not really satisfied with the flexibility they gained. Why?

It is just not sufficient, to demand all your processes, tools and people to be flexible. After all it is not your processes, tools or people reacting to the market - it is your entire organization as a system, reacting.

Thus, if you want to stay competitive your first priority should probably be to design or redesign your organization in a way that the resulting system is capable to cope with change as a whole. In other words - you should try to build an organization that avoids organizational dept. 

One of the major challanges of our time might therefore be, to build a sustainable organization where management, leadership and structure are much more situational and much less permanent.

Promote Your Teams

Promote your teams!

Last year I wrote a blog post about self-organization. During the last weeks I talked, read and thought a lot about this topic and my (not so groundbreaking) conclusion so far is, that self-organization describes a great variety of possibilities to organize yourself.

An interesting and fundamental model of levels of self-organization can be found in Hackman's book "Leading Teams". He describes four such levels:

1. Manager-led teams (team executes team tasks)
2. Self-managing teams (team monitores and manages work process)
3. Self-designing teams (team designes itself and the organizational context)
4. Self-governing teams (team sets its own overall direction)

Hackman writes, that well functioning teams are mostly on levels 2 and 3. But even on those two levels you can certainly find more distinct levels of self-organization and team responsibility.

After all I read and saw so far, the effectiveness of a team correlates strongly with its ability to self-organize. The more a team is able to work on level 3, the more effective it can be. But sadly not every team is able and/or willing to take the responsiblities necessary to function well on level 3 without damaging its context or parts of the team.

After this being said - this sounds very much like a classical career path to me. Not for individuals, but for whole teams. If your goal is to develop effective teams in your organization and you believe, that a high level of responsibility and self-organization is necessary to become effective as a team - then why don't you make this explicit by having a team career path? This might be one way, to empower your teams step by step. Of course it must be clear which levels exist, and what preconditions and responsibilities are bound to what level. Additionally you will surely need some expert coaching for your teams to guide them on their way up the team career ladder.

Don't get me wrong - I do not say that you should abolish individual career paths. I just suggest to have an additional career path for teams, too. Furthermore the rewards for climbing up this career ladder must not be financial ones, but just giving a team more freedom and rights in its actions if it has proven to be able and willing to take more responsibility.

What do you think about the idea of team careers? Do you have any experiences with concepts like this?

Empower! Your! Teams!

Empower the Team!

I have seen it time and again: Teams that would probably be able to be high performaning, but are not able to live up to their potential. Why? Because they are used, seen and organized as efficient task processing units.

Most teams could deliver a much greater performance and experience, if they would only be given serious challenges and the freedom to act.

Unleash the potential of your teams and

• compose them in a way that they are able to resolve real holistic challenges (you might call it cross-functional)
• let them use their creative potential by not giving them only tasks - but challenges (maybe a Product Owner that writes some demanding and sufficiently unclear User Stories)
• let them really self-organize and find the best local process to resolve those challenges
• let them evolve as a team (and not only a bunch of individuals) - e.g. have carreer paths for teams
• tell them clearly what they are responsible for and what not
• give them some useful coaching (e.g. a ScrumMaster)

You might now say: Hey, that sounds like I should do Scrum with my teams. But the bad news is: Scrum is only a process and might probably help you to identify the problem of an underperforming team. But it will not solve your problems. Besides this, Scrum has the disadvantage to introduce the roles ScrumMaster and Product Owner, which empirically draw to much attention away from the teams.

So - don't wait! Not for Scrum and not for any other useful or useless framework. Start tomorrow and seek ways to EMPOWER YOUR TEAMS!


Disclaimer: I love Scrum! It is the best framework for software development I have seen so far. The roles Product Owner and ScrumMaster are very essential and useful roles and in my opinion absolutely necessary. Nevertheless you should never forget, that the ultimate goal should always be to deliver a great product - which lays in the hands of the team in great parts!

Testivus zum Thema Test Coverage

vor einigen Tagen bin ich auf eine nette Anekdote zum Thema "Code Coverage" von Alberto Savoia gestoßen. Ich finde die Geschichte so gut, dass ich sie gerne ins Deutsche übersetzten möchte:

Testivus zum Thema Test Coverage

Am frühen Morgen fragte ein junger Entwickler den Großmeister:

"Ich würde gerne ein paar Unit-Tests schreiben. Welche Code Coverage sollte ich erreichen?"

Der Großmeister antwortete:

"Mache Dir keine Sorgen über Code Coverage. Schreib einfach ein paar gute Tests."

Der junge Entwickler lächelte, verbeugte sich und ging.

Später am Tag kam ein zweiter Entwickler mit der gleichen Frage.
Der Großmeister zeigte auf einen Topf mit kochendem Wasser und sagte

"Wieviele Reiskörner soll ich in den Topf werfen?"

 Der Entwickler schaute ein wenig verstört drein und antwortete

"Wie soll ich das sagen können? Das hängt doch davon ab, wieviele Personen davon essen sollen, wie hungrig sie sind, was sonst noch an Essen angeboten wird und so weiter."

"Genau."

sagte der Großmeister
Der zweite Entwickler lächelte, verbeugte sich und ging.

Gegen Ende des Tages kam ein dritter Entwickler und fragte die gleiche Frage zum Thema Code Coverage.

"Achtzig Prozent und nicht weniger!" 

Antwortete der Großmeister in hartem Ton und schlug mit seiner Faust auf den Tisch.
Der dritte Entwickler lächelte, verbeugte sich und ging.

Nach dieser letzten Antwort ging ein junger Auszubildender auf den Großmeister zu:

"Großmeister, heute habe ich gehört, dass Sie auf die gleiche Frage zum Thema Code Coverage mit drei verschiedenen Antworten reagiert haben. Warum?"

Der Großmeister stand von seinem Stuhl auf:

"Lass uns einen guten Tee trinken gehen und darüber sprechen."

Nachdem sie ihre Tassen mit heißem grünen Tee gefüllt haben erklärte sich der Großmeister:

"Der erste Entwickler ist noch neu und fängt gerade erst mit dem Testen an. Momentan hat er eine Menge Code und keine Tests. Er hat noch einen langen Weg vor sich; sich zu diesem Zeitpunkt auf Code Coverage zu fokussieren wäre nur deprimierend und recht nutzlos. Er wird weiter kommen, wenn er einfach übt gute Tests zu schreiben und auszuführen. Über Code Coverage kann er sich auch später noch Gedanken machen.

Der zweite Entwickler aber ist schon recht erfahren mit Entwicklung und Testen. Als ich ihn gefragt habe, wieviele Reiskörner ich in den Topf werfen soll habe ich ihm geholfen zu verstehen, dass die Menge von Tests abhängt von der Anzahl und dem Gewicht verschiedener Faktoren. Diese Faktoren kennt er weit besser als ich - es ist immerhin sein Code. 

Es gibt nicht die eine richtige Antwort und er ist clever genug mit dieser Wahrheit umzugehen und damit zu arbeiten."

"Ich verstehe", sagte der junge Auszubildende, "aber wenn es nicht die eine einfache Antwort auf diese Frage gibt, warum haben Sie dann dem dritten Entwickler gesagt: 'Achtzig Prozent und nicht weniger'?" 
Der Großmeister lachte so herzlich und laut, dass sein Bauch - der darauf hindeutete, dass er nicht nur Tee trank - auf und ab wippte.

"Der dritte Entwickler will nur einfache Antworten hören - auch wenn es keine einfachen Antworten gibt ... und am Ende folgt er ihnen dann sowieso nicht."

Der junge Azubi und der grauhaarige Großmeister tranken ihren Tee in nachdenklicher Stille fertig.

Hier noch einmal der Link zum Original-Blog.

The Limited Backlog - Addendum

In an earlier post I argued to limit the size of your product backlog. Some days ago, I met a co-worker who told me that some agile experts told him, that product backlogs always have to be limited in size. Superficially, this looks like the very same statement, I made in this former blog post. You might eventually be surprised to read, that I disagreed with the statement, my co-worker made.

Why? Because it is very important to understand why and when limiting the size of your backlog makes sense! The main argument for limiting the size is to avoid the maintenance costs of many backlog items. Especially, if there is a probability, that they will never be implemented at all or the items are deteriorating fastly (what a waste!).

Now comes the pitfall: If limiting the size of your backlog leads to emerging "backlogs" in other places (e.g. at your customer!) you might eventually even increase the overall costs of maintaining the items, if the maintenance costs at the other spots are even higher than they would be in your backlog. This is definitely not what you wanted to achieve in the first place, when you limited your own backlog.

So if you do indeed limit your backlog (which is still extremely valuable), watch out and have a careful look, if the discarded items do indeed vanish, or are only cultivated elsewhere.

So --- What Exactly is "Self-Organized"?

One of the fundamental concepts in the context of Agile and Scrum is the self-organizing team. Despite the fact, that this concept is rooted so deep in the core, the perception of self-organization is controversial - at least in an organizational environment.

Self-Organization and Anarchy

I do often hear that self-organization does not work, since anarchy will rise if no individual controlls the actions of a group. Obviously I am not the only one who hears such concerns frequently. You can read about some frequent misconceptions about self-organizing teams here.

Indeed parts of the definition of self-organization sound very much like anarchy. But there are two important points to be made here:

1. Anarchy is not under all circumstances a bad thing by definition.
2. The main reason for the negative reception of the term anarchy in this context does not come from the definition of anarchy, but from the fact, that "unmanaged systems can behave in a way that the stakeholders don't value".

We are getting closer to the core question, which - to me - is: "If self-organization is good and similar to anarchy and anarchy might behave in a way I cannot accept. What are the borders I have to draw to get a properly working overall system? How do I work with self-organized teams?"

The Theory Behind Self-Organization

Let's dive a bit into the theory of self-organization. The concept of self-organization stems from systems theory. In systems theory (complex) systems and their interactions are observed and described. A special case of complex systems are complex adaptive systems (CAS).

A complex adaptive system is a system that is:

1. complex because of its multiple, diverse connected elements
2. adaptive because it is able to learn from experience and react to circumstances

This matches well with the definition of self-organization of Scott Barton where "self-organization [is a] process by which structure or pattern emerges in an open system without specifications from the outside environment". (Barton, S. "Chaos, self-organization and psychology" (pp. 111-138). San Diego, CA: Academic Press)

Some Facts About Complex Adaptive Systems (CAS)

Therefore if we want to learn about the term self-organization it pays off to have a look into the literature and research in the field of systems theory and complex adaptive systems. A valuable source in this hindsight is Roy J. Eidelsons paper "Complex Adaptive Systems in the Behavioural and Social Sciences".

I will just quote some parts of this paper in the following:

"... some complex systems may not exist in a particular form because the parts simply cannot be assembled that way." (p. 47)

What we might learn from this is, that if you try to construct a complex adaptive system (or self-organizing team) from the outside, chances are, that your system (team) is non-viable. It therefore will not behave like a team for a long time. If you intervene in a living team - you might kill it.

"The course of self-organization in complex adaptive systems is often influenced by positive feedback." (p. 49)

To me, this means that it is important to detect damaging positive feedback loops (e.g. increasing distrust) and it might be a chance to find positive feedback loops (e.g. fast feedback) the team benefits from.

"A common instance of positive feedback is the competency trap [where] successful learning drives an individual, organization or society to a stable but suboptimal solution." (p. 49)

One should look out to avoid the competency trap, which is getting stuck at a local optimum where much better global optimums are possible but not reachable by the team without influence from the outside.

"It should be kept in mind, however, that successful self-organization for a particular system as a whole can produce undesireable consequences for some of its individual parts and for other CAS." (p. 49)

Self-organized teams might behave in a harmful way. Thus we have to set boundaries to avoid a self-organizing team to damage other teams or systems (by intent or accident). Furthermore we should be careful that no individuals in a team become aggrieved.

It might be tempting idea to try to find a "stable" state for a team. But stability might not be the best thing for a team. J A. Scott Kelso writes about the human brain (one example of a CAS) in  "Dynamic patterns: The self-organization of brain and behaviour":

"By living near criticality, the brain is able to anticipate the future, not simply react to the present."

Thus, a state that looks close to chaos  (from the outside) might be a perfectly reasonable way for a CAS to exist and adapt.

Learnings

To me the key learnings from this in working with self-organizing teams are the following:

1. Ideally seek the right positive feedback mechanisms. Look out for side effects and alignment with the organizations goals/vision/mission.
2. Set out your expectations clearly and let the self-organizing team find solutions to fulfil them. Communicate clearly the responsibility of the self-organizing team and ask what they need to take this responsibility.
3. Think hardly about what boundaries are needed to avoid damage that could possible done by a self-organizing system.
4. Try to identify competency traps and find ways out of them (use items 1 and 2 to do that)

Mary Poppendieck summarizes most of this points in Implementing Lean Software Development: "Respecting people means that teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals."

Even easier stated by Jurgen Appelo: "Change the Environment, Not the People".

Update: Uploaded slides from a presentation at Agile Monday Nuremberg.

The Backlog - Keep it Short!

A problem faced by many Scrum teams is an overcrowded Product Backlog. But the even bigger problem is that many of those teams do not even see, that this is a problem! Why is it not a good idea to have a very large pool of work to do? It might even look like a positive message in the first place.

The problem with overloaded backlogs are manyfold:

• A backlog must be maintained and communicated. The longer the backlog, the more work this is.
• A long backlog often contains items, that will never be implemented - bringing those to the backlog and maintaining them is a waste of time and resources.
• A long backlog has a frustrating and demotivating effect. Nobody wants to feel like Sisyphos all the time.
• A long backlog is nothing more than a long queue. You might read "Flow" by D. Reinertsen and let you convince, that long queues are one of the worst things that can happen to you in product development.
• ...

But what is the solution to this problem?

An obvious and easy solution would be to limit the work pooled in the Product Backlog (i.e. applying a WIP constraint on the Backlog). You can do this either by limiting the number of Stories in the Backlog or by limiting the number of Story Points. Two questions emerge immediately from this approach:

1. What will I do with the work, the customer wants me to do that does not fit into my product backlog?
2. What might be a reasonable upper limit for the amount of work in the Backlog (maximum queue size)?

My first answers would be:

1. If the customer has work to do that is more important than work currently in the backlog - let him replace some items. If the customer asks for less important features tell him to come back later. This approach adresses many of the problems with long backlogs and makes transparent to the customer that he is working with a bottleneck (your Backlog!). You can then work on problems causing this bottleneck.
2. Inspect and Adapt on this number! A good first shot would probably be to limit the backlog to the work that is possibly achievable in three month. This depends largely on your context and how stable requirements or User Stories are.

If this solution seems to be to mild for you and you need more radical solutions this article might be a valueable source for you :-)

Update 1: Some further remarks on this topic.