Team Communication

Tally sheets might help your team

There is a simple tool to let your team reflect on their communication. It might help you, if there is somebody on your team who talks very much and some people who remain mostly silent. The tool is: a sheet of paper and a pencil. Just participate on a teams meeting, search a quiet corner and make a tally sheet of who in the team spoke how often. After the meeting is over, offer the team to share your observations and let the team decide, what to make of this observation. Maybe a very healthy discussion will follow...

If there is no discussion coming up, there is eventually no problem with this fact or the team is not ready to tackle this at the moment. You might try it some time later again.

A Lean Startup Experiment

Today we (Sven Schäfer, Sven Winkler and myself) are starting a lean startup experiment. We all took one week of and want to explore, how to apply lean startup methods and how much of an app we are able to develop in this time. The experiment startet this morning at 9:00 CEST in the coworking space in Nuremberg. It will be finished on Friday evening - no matter what we accomplished in that time. We are now eager to learn :-)

Our first step currently is to formulate and validate our first hypothesis, which is: "In addition to Facebook and Google+, there is still room for an app that allows parents to share and show photos of their children in a clear, easy and secure manner."

We do currently try to validate this hypothesis in two ways:

1. We set up sites on Facebook and Google+ and uploaded photos of a paper prototype of our new app. We liked and postet on this platforms and will observe how many likes and "+1" we will get. If there will be a great number of likes, this is one indicator, that our hypothesis might be right. If nobody likes - we might be wrong with our assumption.
   Help us with feedback and have a look at our social media pages on Google+ and Facebook. 
2. We will soon go outside into the city of Nuremberg and try to show our paper prototype to some passers-by. We will observe their reaction and therefrom derive, whether our hypothesis is right or wrong. This channel has the advantage, that we can ask for additional feedback and maybe adapt the initial idea and to formulate new hypotheses.

First paper prototyp of the ThatsMyKid app.

Retrospectives of all days can be found here:

• Day 1
• Day 2
• Day 3
• Day 4

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!

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.