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.

It's not the Manager, Stupid!

There is not only plenty of talk about corporate culture. Another beloved target when talking about grievances in organizations are managers. This is not very surprising, since by nature they hold exposed roles and have great impact on the organization and its members. Additionally you will easily find flaws in every single manager, which makes him an easy target.

Bad news here: The manager is not the problem! The manager is a human individual like you and me. Of course he has his mistakes. As you and I have, too. Only do this mistakes have a much greater impact than do those of your fellow workers.

The real problem is, that the system he works in allows his errors to have such an enormous effect. There are only few mechanisms to mitigate bad decisions met by individual managers. Besides this many organizations do not have working mechanisms to cope with individuals not suitable for such a position (if they once have the position). Such mechanisms (for coping with organizational dept) are certainly a key success factor for sustainable successful organizations.

Organizational Dept

In the field of software development, there is a metaphor called "technical dept".  In short, this metaphor says that while you are programming you almost always build up dept. Dept in this case means that your code base decreases in quality over time. You will have to invest time and work to amortize this dept. If you do not amortize your dept, interests will take effect. Thus, as with regular dept, you will always be better off to amortize the dept as soon as possible. Otherwise compound interest will be the effect and at the end you will pay heavily - if you are able to pay back at all anymore.

Speaking about Agile transformations there is another kind of dept. I would call it "organizational dept". It is based on the same concept as technical dept but on an organizational level. As your organization grows, you will take hundreds of decisions. Not all of them will be perfect and thus, you will (with every decision) increase the organizational dept. How does organizational dept look like?

There are multiple instances of organizational dept. Just to mention a few:

• People in the "wrong" position (on jobs they are not suitable for)
• A wide gap between the culture wanted and the culture existing
• Unresolved conflicts between people
• ... and many more ...

As with technical dept, if you do not regularly and fastly cope with organizational dept, interests will occure and over time compound interests will make your dept almost unbearable. At some point you might not be able to pay back at all anymore! Speaking of technical dept, the consequence for a software system is then to be displaced by a new system. What do you think will be the consequence for a company if you get into this state with organizational dept...? I think, we all know!

This is one point why Agile is so successful. Agile folks generally reject living with dept and always try to pay back as soon as possible. The incarnation of this attitude is e.g. the retrospective in Scrum and the focus on continuous improvement and impediments in all Agile methodologies.

Update: Sven Winkler picked up the idea of organizational dept on Boris Glogers Blog and adds some interesing points of view.

It's not the Culture, Stupid!

In many Agile transformations there seems to be an issue with corporate culture. People in the company often think and say, that the current culture is not compatible with Agile and the culture would have to change.

Values often mentioned in this context are the Scrum values:

• Commitment
• Openness
• Focus
• Respect
• Courage

I do only have one issue with this. Try the following: Take this values and present them to some randomly selected persons in your company. Ask everybody the following question: "How important are these values to you and are they part of your set of values?". I made the experience, that every single person will find these values to be important and most consider them part of their individual set of values. How then is it possible, that the corporate culture seems to be a problem?

To answer this question try another exercise: Again take the above mentioned values and show them to some persons and ask them the following question: "How much do you think do people in your close environment live these values?". You might be supprised, that the results will now be much worse than the results of the first question.

Find the explanation for the observed gap and you will probably be a huge step further in your Agile transformation. You can probably do this just by making the gap transparent and asking the people for an explanation. Eventually a retrospective may be a good place to do this.

The 10 Worst Management Practices, And How To Turn Them Around

Summary of a session by Laurens Bonnema at the Stoos Stampede 2012 (Mary posted about this session here)

At the Stoos Stampede 2012, Laurens Bonnema facilitated a session about bad management practices. Not only was the content of the session quite interesting. The way Laurens facilitated it was very informative, too. The first thing, he did was gathering bad management practices from real life from all participants. He used silent brainstorming for this which was extremely productive.

Result of silent brainstorming management worst practices

After the brainstorming results were clustered and ranked by participants. We tried to assign a reason and a possible cure for the negative behaviours.

Here we go. The ten worst management practices drawn from real life in descending order:

1. Failing to act on impediments

You will probably not have to dig very deep in your memory to find your personal example of some manager confronted with a serious problem, finding many reasons (often financial ones) to do nothing about it. Since - at least in my understanding - removing impediments and optimizing the working environment are core responsibilities for every manager, this is a sad situation.
What could you possibly do to work with such a problem? One suggested approach is to make the problem as visible and transparent as possible. The responsible person will then have much lower chances to succeed with hiding the problem.

2. Spreadsheet terrorism

Several participants reported the habit of some managers to cover their subordinates with reporting stuff. Someone called this "spreadsheet terrorism". The problem is, that all those numbers do not really help you to focus on your work and will probably even slow you down. In some cases the only reason for this kind of management is that the respective person has no clue, what to do in her job and cannot cope with people problems. Thus she tries to reduce those problems to numbers giving her the feeling of beeing able to control something. The most common reason for this behaviour is probably uncertainty and a mean understanding of people and their problems.
It looks like there is no simple hint, how to solve this problem. You could eventually try to sensibilize him for the problems of management by objectives (numbers) and suggest, to focus more on the customer and the employees than on costs and numbers. Try to talk openly to her and discuss how to improve her skills in realizing and working with people problems.

3. Saying != Doing

There is not much to say about this. Can you do anything worse than talking left and walking right? It will not a take long time and nobody will trust you anymore. And trust is the base, really good relationships are built upon. Even in business!
The most effective thing you can do about this problem is making the gap between talking and doing and the consequences as transparent as possible to her (and eventually everybody else) so that she will have the chance to realize it the reception of her doing by the rest of the world.

4. Management by fear

Have you ever been in the following situation? Your manager calls you into her office and has a short but firm conversation monologue with you about some recent or current problem and makes very clear that a repetition of this problem will have serious consequences.
It is almost tragic that strategies of punishment and fear are still widely used to manage and lead people. Especially since it is broadly accepted that the negative consequences of punishement and fear - even if this works in hindsight of changing unwanted behaviour - far outweigh the advantages of this fast way of learning (see e.g. the research of B.F. Skinner). If your manager uses this type of learning for her subordinates one reason might be, that she is overloaded with work and does not see alternative ways to enforce the desired behaviours fast enough (punishment is a very fast way of changing behaviour). In this case you should try to find ways how to reduce the workload of the respective manager.
Another reason might be, that the manager does not know any alternatives to punishment. In this case she is definitely in the wrong place and one should urgently consider to educate him with basic leadership skills or - if this is not possible - replace her.

5. Divide & Conquer

A manager has fear that a team has such a momentum that she will not be able to control its behaviour in the near future anymore. Her solution is to break up the team and accept the dropping performance only to be able to have full controll again.
If a manager indeed acts in such a way, I personally cannot see any way to turn this behaviour around. There must be a lot of things going completely wrong.

6. Failing to really listen

A manager talks to you, but she does not really hear what you say. There might be several reasons for this problem. Classical communication problems could be one of them. In this case it is probably a good idea to involve a third person as facilitator who is able to reflect your communication problems to both of you.
Another reason might be that the manager is just to busy and her head is filled up with stuff of all sort but not with your problems and thoughts. In this case you should on one hand tell him the problem you sense in your communication and talk openly and constructively to her about how to reduce her amount of work or creating room for focused communication in other ways.

7. Avoiding conflicts

This is not only a classical management problem. Be honest: Who of us is always jumping on conflicts as soon as she discovers them? Nevertheless, this is a problem. The solution might be simple. Directly address the conflict you see and make it visible. Do this steadily and insist on a resolution of the conflict using any opportunity.

8. Management by numbers

Very similar if not equal to "spreadsheet terrorism".

9. Featurism over Quality

Mostly a problem of project managers who promised a fixed set of functionality for a fixed price working against a not negotiable deadline. The only dimension where speedup is possible is in quality (since nobody spoke about this initially).

I think, Agile folks know the solution ;) In short: assume quality to be fixed and not negotiable and prioritize your requirements!

10. Blaming Culture over Finding Solutions

I have seen this to often: A problem is at hand and the first (and often last) reaction is "yep - we know - that's a cultural problem in this company". The process of discovering possible solutions is thereby terminated. Nobody wants to talk about your problem any longer.
You can try to work on this problem, by understanding the perspectives of the people giving you this answer (be on the same boat) and suggesting small steps to move to a better world. One participant of the session suggested to let those people read the book "My life is a failure" by Jim Johnson.

Conclusion

It is really depressing, how many awful management practices are in use out there. The huge pile of practices backed by some real world stories underline boldly the bottom line of Stoos: "There has to be a better way."

Does Stoos Need a Manifesto?

Summary of a Stoos Stampede session, jointly facilitated by Steffen Lentz and my humble self.


Since Stoos was kicked off in January I had several discussions on this topic with different people. A question, that always arose was, why the initial Stoos21 did not come up with a manifestiish kind of document to make a bold statement on the mission of Stoos.

Now you cannot say, that the Stoos21 did not come up with anything. There is at least a description of the targeted problem and a vague idea how a different szenario could look like on the main page of the Stoos network. Additionally there is the clear message, that Stoos' intention is to change the world:

We are trying to change the world

Given the fact, that 21 people (mostly strangers) had only two days to come together, introduce each other, set up an atmosphere of trust and respect, this result is not bad! Still, to me - and most of the people I discussed with - there was a very central questions left open:

What exactly is the mission and vision of the Stoos network?

To address this question, I proposed the session "Does Stoos Need a Manifesto?" at the Stoos Stampede 2012. At the Stampede Steffen and I decided to join his session "Pitches and Propositions" and mine, since we seemed to have similar targets.

What happened at this session?


The somewhat provocative title of the session worked out nicely and some interested people came together. Steffen already described his view on the session and the participants at the StoosXChange-Wiki.

The discussion was really interesting and very clarifying! Initially some of the participants wanted to agree on a common set of values for the Stoos network, which was kind of obvious since there were certain values mentioned in nearly every session. But the attending Stoos21 participants resisted this move by explaining, that Stoos is not about values, but about "finding different ways" and that those ways can be different for every single organization. It became clear fastly, that this was a point accepted by all participants and that a manifesto would definitely not be the right way to express this.

But after approximately 30 minutes of discussion everybody in the room felt, that there was something missing. That the mission of Stoos could be made more concrete without commiting on certain values. The key common elements were: "finding a better way", "we believe in people and bring them together", "we want to create epiphany/enlightment moments and learning opportunities", and this should happen by "self-organization", which needs a certain container.

Result of the "Manifesto"-session

I will try to summarize my current understanding of the Stoos mission in short:

We believe in people and their potential! We bring them together to create epiphany moments and learning opportunities. Together we will find different and better ways to manage our organizations.

Does not fit into one tweet, thus there will probably still be a lot of work to do ;-). I am curious if there will pop up other views besides this and this (nice video!) in the next days and if a clear mission will be articulated.

Staying tuned :-)

Thanks to all participants! This was clearly one of the epiphany moments at the Stoos Stampede for me!

Update: Peter blogged about this session at his blog.

Update 2: Steffen blogged about the topic here.

Indicators for Corporate Culture (and How to Change)

Summary of a session I facilitated at the Stoos Stampede 2012

In my work I am almost every day confronted with the topics culture and change. Since the Stoos mission (I will eventually blog on this later) is to bring people together to provide learning opportunities, and I had the great chance to participate in the Stoos Stampede, I proposed a session on exactly this topics.

The main outline of the session was as follows:

1. Gathering different models for describing culture
2. Collecting indicators (with respect to this models) of non-Stoosian and Stoosian cultures
3. Discussing how to take steps from the non-Stoosian to the Stoosian culture

Sadly, the session ended before we could even start to discuss item 3. In the remainder I will summarize the results of steps 1 and 2.

Step 1 was intended to reveal models to describe corporate culture find an appropriate model for describing non-Stoosian and Stoosian cultures in Step 2.

Models to describe corporate culture found in Step 1

We came up with with three different models:

• One model described corporate cultures on two axes: One axis represents the focus on persons (impersonal vs. person-focused) the other axis represents the focus on time (future-focused vs. present-focused). The model then distinguished four cultureal quadrants.

• Another mentioned model was Spiral Dynamics - a model of human development, which can be adapted to organizations as well. Spiral Dynamics distinguishes multiple levels of development. Every level is associated with a color. Mentioned stages were blue, orange, green and yellow. Someone claimed that Non-Stoosian organizations would be on stages blue or orange, whereas Stoosian organizations should be on stages green or yellow.
• The third model was proposed and complemented in several forms. One could say that the basic model is the one, Edgar H. Schein proposes in his book "The Corporate Culture Survival Guide" (amongst others). This model divides culture in three stages:
  
  - Artifacts: Visible organizational structures and processes
  - Espoused Values: Strategies, goals, philosophies
  - Underlying Assumptions: Unconscious, taken for granted beliefs, perceptions, thoughts, and feelings
  - One participant added the dimension Purpose to this list
  
  Other participants pointed out, that Chris Argyris established the espoused theory and theory-in-use, with a similar distinction like the aspects mentioned by Schein.
  One of the attendees pointed out, that the Artifacts layer of culture is only 10% of what really drives corporate culture and the remaining 90% are the unvisible believes and assumptions.

Step 2 was devoted to collecting indicators for non-Stoosian and Stoosian cultures. We decided to use the culture model of Schein supplemented with the Purpose dimension as a basis for collecting those indicators.

Indicators for Non-Stoosian cultures where

• There are many secrets around - very intransparent
• Strong hierarchies and strict top-down control
• The company is led by ROI only (very money focused)
• The attitude "We know better than your customer" is custom
• The company is very focused on individuals (heroes)
• There are lots of reports distributed (e.g. plans, timesheets, evaluations of performance, KPIs)
• There are many defined processes set up
• The company is cost-driven
• There is much talk about efficiency
• Work is not fun for the employees
• In Spiral Dynamics: blue or orange

Indicators for a Non-Stoosian corporate culture

Indicators for Stoosian cultures where

• Transparency of management and decisions
• Company has a longterm vision
• Sustainability is a topic in the company
• There is a focus on employees
• The company is knowledge driven
• There are cross-functional teams at work
• Openness is a value and assumptions are visible
• Dawna Jones pointed out, that many of the artifacts depicted in the organic model here (http://www.lampindex.com) are indicators for Stoosian cultures
• In Spiral Dynamics: green or yellow (or above)

Indicators for a Stoosian corporate culture

As you can easily see all of the above listed indicators are very visible things and thus clearly on the Artifact stage of the cultural model. As Schein points out, there is not an immediate direct link from the artifacts of a company to its actual culture (you are missing 90% if you only know the Artifacts!). Therefore many questions remain open after this session. Maybe the next Stampede will shed some more light on this topic :-)

Ángel Medinilla used the last five minutes of the session to summarize and propose an interesting model. He hypothesized that on all stages of Schein's model the difference between Stoosian and non-Stoosian organizations is that Stoosian organizations are headed for the many while non-Stoosian organizations are headed for the few. To be more concrete:

• Stoosian organizations tend to work in teams (many) vs. Non-Stoosian organizations working as many individuals (Artifact stage)
• In Stoosian organizations you will encounter an atmosphere of humility (many) vs. in Non-Stoosian organizations you will encounter an atmosphere of arrogance (few)
• Stoosian organizations are thinking in long terms (many), while Non-Stoosian organizations tend to think in quarters (few).

This final words finished nicely a session which was - at least to me - full of interesting things and diverse views on the topic. I learned a lot and want to thank all the participants for the great input!


Update 1: Just found another short summary of the session by Joost Jonker: http://alustforchange.wordpress.com/2012/07/09/indicators-for-companies-culture-and-how-to-change-stoos-stampede/

Update 2: If you want to learn more about the 3rd planned point of the session (taking steps from non-Stoosian to Stoosian culture), you might have a look at the results of the "Culture Hacking"-Session here or here. And maybe here: #culturehacking

Update 3: Another thought on culture: It's not the Culture, Stupid!

Be the Change You Want to See!

Summary of the session "Be the Change U 1 2 C" on Agile Coach Camp Germany 2012 (#accde12)

Many people are talking about changing organisations, teams, managers, and many more to become more Agile. Inspired by an article on HBR, I proposed the session "Be the Change You Want to See" on Agile Coach Camp Germany 2012. Content of the session was the question: "Which concrete things can I do tomorrow, to be a good role model for the change I want to enable? How can I be the change I want to see?".

I would like to share the results of this session on this blog, since I feel that there are some very good points in the results. You are free to pick one or two items and to start changing yourself, before changing others:

• Play Failure Bow
• Make your Impediment Backlog public
• Prepare your meetings
• Make your decisions and their reasons transparent
• Communicate important decisions face-to-face
• Let others speak (and accept their opinions)
• Make transparent who may decide what and to what degree
• Make transparent what your interests and goals in any discussion are
• Reflect on yourself
• Read business cards as you recieve them as a sign of respect
• Give people time to react on your feedback - do not walk right away immediately after giving feedback
• If you do not give positive feedback very often: Search for somebody and tell him, that you want to do this in the future
• Use and distribute "Thank You" Cards (e.g. the ones distributed by Martin Heider at the Coach Camp)
• Make your own work transparent (e.g. have a public Backlog)
• Make your own daily retrospective by writing up three things you were grateful for today every evening
• Play appreciation games, e.g. "Positive Paranoia" by Ben Furman
• Do what you say - be reliable
• Give up control
• Play a role play "change of perspective" to establish trust
• Offer your help
• Make your failures public
• Do not work longer than you expect your collegues to work

Not all of this items are very concrete, so if you have ideas to make them more concrete or if you have any other ideas - feel free to leave them in the comments section!

To me it was a great session and a nice finish four the Agile Coach Camp. I want to thank all participants for bringing so many great ideas to the session and sharing openly! You all made my day!

Session result

 

When is Scrum applicable?

Over the years, I was oftened asked the question: "Is Scrum applicable in this context?" or alternatively "When or under which circumstances can I apply Scrum?". I gave (and read) lots of more or less sophisticated answers to that question, but have a very simple approach to answer this now.

You are able to (and probably should) do Scrum if:

1. You are able to fill a Product Backlog
2. You have - or can establish - a Team (which means team - not group!)
3. You have - or can establish - a Product Owner
4. You have - or can establish - a Scrum Master

That's it.

Of course you can still use several single practices and tools of the Scrum framework if these conditions are not fullfillable - which is not a sin. But you should not call it "Scrum" then!

Value People over Techniques

Many people ask themselves: "What makes a successful organization?". And since there is so much question  and therefore much money to earn there are tons of consultancies and "simple technical" solutions to this question. So far, I did not see any of those solutions succeed. Even my personal favourite "Agile" is definitely not a solution in terms of "do it and you'll succeed". Why is that?
I think it's pretty easy: It's because the problems we have to cope with in todays environments are mostly "social" problems and only rarely technical problems. But people love to approach all kinds of problems with technical solutions, because it is the easiest and considered to be most "scientific and exact" way. It is for sure the most convenient way, since you must not bother with complex and not linearly answerable questiones.
This said, I personally believe that to align your environment to a more successful direction, you will have to focus on the more complex "social" questions first and at least become aware of these crucial factors and derive "technical" solutions later as one aspect of the way to go. Concretely this means, to focus on:

• Corporate culture before defining corporate strategies
• Values of your employees before implementing rules and guidlines
• Satisfying your customer before maximizing your profit
• Maintain the ability to change and adapt before maximizing the efficiency to produce.

Hereby I mean that everything mentioned above is absolutely important, but one should focus on the "social" items on the left first and derive adequate "technical" solutions on the right then.
Easy? Not at all. To me this evokes many serious and hard questions immediately:

• How do I know, what corporate culture I have? And how can I describe this appropriately? How can I measure this? How can I present advancements? (and many more...)
• How can I know what the values of my employees are? And how can I influence these? Is this possible at all?
• How do I meassure the satisfaction of my customer? It is sure not as simple as just implementing some simple tool (NPS, etc....).
• What is the right amount of ability to change? And what is the threshold where I must lay more value in efficiency?
• and tons of more questions ...

But after all: If you would agree, that in principle the four sentences stated above are right, the immediate consequence must be to focus on these questions first and think about the "technical" aspects later (which is, what for example the Stoos Network seems to do).

The Thing Missing in Scrum

I am working with Scrum very successfully for several years now. And it is by far the best methodology crossing my way in software development. Yet, I think there is one thing, missing in Scrum - its slack time.

Most Scrum coaches would probably say: "No, no, no... Slack is not missing. It is ...

1. ... automatically emerging, because the team is self-organized. It is in the responsibility of the team to take whatever slack is needed to accomplish their work."  
2. ... an optional add-on to Scrum. You can just implement some slack additionally as you like. But Scrum does not lack slack. Slack is not missing more in Scrum than it is in traditional work environments."

I personally think, those arguments are not valid. 

Argument 1 is questionable: Nobody knows when he "needs" some slack, to be creative and thoughtful. Slack happens to help sometimes and does not help on other occasions. Thus, slack must just be there from time to time (for every single individual - not the team as a whole), so you get a chance to let your brain defocus and accidentially stumble over some very good ideas and thoughts. The tricky thing about slack is, that you will not "miss" it at a specific point. The need for slack ist not foreseeable. Thus a even a self-organized team cannot be expected to know when to take some slack time.


Argument 2 has its flaw, too: You could similarly say that Scrum has no need to contain the role of a Product Owner, but one should implement it as an add-on to Scrum. But this is obviously wrong, since you need somebody giving input to the team, having a more global vision, and beeing responsible for creating business value. Scrum needs to define this role, since it removes the role of the project manager (who was responsible for this tasks earlier).
I think the same is true for slack: Scrum is much about focus and productivity. This is not wrong, but it lacks a necessary concept of slack. Even more, it squeezes some natural amount of - often healthy - slack out of the team that occurs in most classically organized companies from time to time. The point is: Because you are working so much more focused on creating value for the customer (which naturally comes with Scrum) and achieving Sprint goals, a certain amount of slack should be built in, too. This is why I personally think that slack is the missing thing in Scrum.

I guess it would be of great value to Scrum if the framework contained some slack space for every individual in the team (e.g. everybody has one "free" day, where he is not expected to contribute explicitly to the sprint goals).

What do you think? Is there the necessity for slack time in Scrum or are there indeed mechanisms in place substituting this need? What are good mechanisms to build slack into a Scrum team?

Priority Race - A Game for Effective Retrospectives

I will introduce a game I invented for facilitating effective and active retrospectives. As every experienced ScrumMaster knows, it is not only important to prioritize (or more correctly: order) your product backlog, but it is also important to prioritize your impediments. This game can help you, making retrospectives more active and fun while obtaining a good order for your impediments.

Material: Non-transparent tape, Scotch tape, flashcards or sticky notes (red and green), flipchart marker, wall or big table

Preparation: Before the retrospective begins, you will have to search for a wall, where you can draw some vertical lanes with your tape. You can alternatively use a large table, which is the second best option. Mark the lanes as follows:

Initial setting: Draw some vertical lanes on a wall (this is the "race track")

It often helps, to put numbers at the top of every column (you can do this easily, using post-its).

How the game works

Step 1: Split your team into several groups of approximately four people. The groups then collect positive and negative feedback on cards (you can alternatively let everybody bring his own feedback, but I like having initial conversations in small groups).

Step 2: Let the groups explain their feedback and put the cards on the wall/table. At the same time, group the feedback cards to clusters of equivalent topics.

Step 3: Put all card clusters to the starting line of your race track, that is position 0, as depicted below.

Put the impediments and things that work fine in the first column (column 0)

Step 4: Now everybody has to execute two moves with green and two moves with red cards. I.e. advance one card two columns to the right or two cards one column with every color. Everybody should try to get her favourite feedback cards as far as possible to the right (but at most two steps). Do this until everybody executed four moves. You can either let the participants do their moves one after another or at the same time (which saves time).

Player 1 advances two green cards one column and a red card two columns

Player 2 moves two green cards one column to the right, and so does he with two red cards

Done: The result will be, that all cards are distributed on the racing track. The distribution is not arbitrary, but reflects the prioritization of the issues in the team.

All Players moved four steps: Prioritization is done.

 
You are now free, to continue with your retrospective, going through the feedback from the right to the left. You can also take a fixed number of green and red cards to focus on in the remainder of your retrospective or take the order as input for your impediment backlog.

You could now focus on the top three cards for further discussion

Hint: You should do some computation before starting the game: Depending on the number of participants you should adapt the number of columns or/and the number of allowed card moves to do for every participant.

You can also use this mechanism for prioritizing any other kind of material (even your backlog) with a larger group of people. I used this game with up to 20 people, prioritizing up to 20 items.

Real world example: Initial setting

Real world example: Result

The great advantage over prioritization with dots or other markers on the cards is, that the result is immediately clear and much more intuitive and visible. No counting - just looking!

Just try it - and if you have any ideas for improvements, different applications, variations, or positive or negative experiences I will be deeply grateful for any comments.

Why Agile is Doomed to Succeed - If Done Wholeheartedly

and why Scrum implementations sometimes fail - or do not deliver what they promised


I recently read the book "Drive - The Surprising Truth About What Motivates Us" by Daniel H. Pink, which is much about motivation in the 21st century workplace. There is a tight connection between the ideas expressed there and the thinking and principles behind the Agile movement (e.g. Stoos-Network, Scrum, XP, etc.). I want to try to work out this connection, so you can understand one of the key success factors of Agile. If one understands these, one has - as a byproduct - immediately a good understanding at hand, why Scrum implementations do sometimes either fail or not deliver what was expected of them.
I will at first try to explain the core drivers and levels of motivation Pink describes in his book. He destinguishes three levels of Motivation:

• Motivation 1.0: This is what essentialy motivates every kind of mammal to do whatever it does. It's about the basic necessities for survival: eating, drinking, reproducing, security, etc. In essence Maslow's hierarchy stages 1-3. This was probably fine for humans in stone-age and earlier times.
• Motivation 2.0: Essentially based on rewards and punishment (or as Pink states it - carrots and sticks). This was one of the main drivers of the industrialization era where thinkers and managers where broadly influenced by the theories of Frederick W. Taylor and his "scientific management". It is all about command & control and extrinsic motivation. Work in this times was in huge parts not very complex and consistet much of simple repetitive tasks, that are done by computers and robots nowadays.
• Motivation 3.0: There is strong evidence from scientific research of the last five decades, that Motivation 2.0 (rewards & punishment, extrinsic motivation) are very unreliable and weak motivators in our current social and industrial environment (but still relevant for some very specific settings). If you want to read about and understand this hints - read the book! Following the book there is a better motivation scheme than Motivation 2.0, wich is based on intrinsic motivation. This motivation scheme has three core drivers:
• Autonomy: Not to confuse with independence! Autonomy means the need and ambition to have as much as possible autonomy over the work to do. It means having the opportunity of acting with choice (e.g. choice over how to do the work and when to do it best). "Control leads to compliance; autonomy leads to engagement".
• Mastery: The willingness, to strive for excellence. It is about continuous improvement and perfection of the personal skills. Which is not the willingness to be the best of the best, but more the drive, to make the most out of the talents and abilities one has (which is the most you can expect!).
• Purpose: Everybody wants to see the work he does in a greater, meaningful context. The work one is doing from day to day should have some greater sense, which is indeed almost always the case, since most of all work is done for some customers.

So far - so good. But where is the connection to Agile?

It is essentially very simple. Agile is in big parts build exactly around the core drivers of Motivation 3.0. Let me explain this shortly:

• Autonomy: Starting with XP, continued with Scrum and now discussed in the Stoos-Network is the central idea of the self-organizing team. The idea is to give a team as much as possible autonomy over the work to do.
• Mastery: Here craftmanship (XP) and continuous self-improvement (Scrum, Stoos-Network) are the keywords. These postulations and processes are inseparably connected to agile processes and ideas.
• Purpose: Agile frameworks generally build upon integration of the customer. The tighter - the better. Direct feedback and collaboration with the customer is probably the best way of getting sense and meaning to your work. This is because you immediatly see, who benefits and get direct feedback.

OK, I understood that, but where is the point of failing Scrum implementations? How does this motivation stuff help me understanding the why of failure? It is not hard:

Scrum works out well, if you encourage these points, since motivation of your teams is very likely to increase. Increased motivation leads to increased productivity and - by the way - to increased satisfaction.
If you do only use the mechanics of Scrum, but do not really let the teams self-organize (giving them the freedom to make their own decisions!) or do not cultivate craftmanship (invest in education, encourage and set the stage for self-education) or do not bring the customer as close as possible to the team, motivation will not flourish. Thus, you are very likely not to improve very much - and be doomed with another process corset. Which I would just call failure.

Making the Case for Story Points

Or: Why Story Points Outperform Man-Days easily

I introduced Scrum to a number of teams now. There was always big discussion whether estimation in Story Points is of any use. I think estimating in Story Points is one of the really great inventions of the Scrum framework and I want to draw out the reasons for this believe in this post.

Estimating in Story Points has great advantages in multiple aspects:

Team Advantages

• Story Points are a team metric. They are always estimated by the whole team. In my experience those estimates clearly outperform man-day estimates, since they depend not so much on who actually carries out the estimated task. Thus Story Point estimates are more reliable.
• Since everybody in the team participated in the estimation most people feel more accountable for the work behind the Story. This is often not the case with man-day estimates which are in many cases given by experts and carried out by someone else.
• Since the whole team estimates, much more information is shared among team members. This supports reducing islands of knowledge.
• In emerging discussions during estimation open questions and risks are discovered very early.

Abstract Number Advantages

• There is no immediate connection between Story Points and real working hours. This makes estimation often much easier and removes useless points from the discussion agenda in estimation meetings.
• Estimating in Story Points makes you almost immediately think a little more abstract during the estimation. You often do not loose yourself in the details of the implementation which makes estimation faster but still accurate enough.
• Story Points are usually estimated in fixed and fastly growing steps (e.g. the Fibonacci Numbers). Therefore the amount of uncertainty and risk is simply expressed in the resulting number. The bigger the number - the higher risk and uncertainty. This is clearly expressed by not having numbers like 427 available (which would suggest high accuracy for outside observers).
• You can estimate earlier in Story Points than in man-days. The reason is that you can much earlier say how big a task is relative to other tasks, than to determine exactly how many days you would need to implement it. Relative estimation seems to be easier to accomplish for human beings than absolute estimations.
• Estimations in Story Points are often more honest than estimates in man-days. The reason is, that you do not have the feeling to "promise" to be done in X days.
• Since the Story Point number is abstract you do not have the temptation to build in buffers. Thus you have much better control about the real state of work.

Efficiency Advantages

• Estimation in Story Points is often much faster than classical estimation in man-days. Many of the reasons for this point are still mentioned above. Additionally, there are methods to get those estimates really fast (e.g. Planning Poker or Magic Estimation).
• By estimating in Story Points you avoid unnecessary discussion and justification for the time needed ("Why can't you do this in three days? Five really seems a little to much...").
• You additionally avoid useless discussions about teams performance ("you are three guys working five days a week - why did you only finish work estimated for six man-days last week?"). To be clear: discussions about teams performance (positiv or negative) are legal and often good hints for impediments, but not in the indicated tone. Thus Story Points can switch your attention from justifying to solving problems.

Self-Improving Mechanism

• In my experience you get an excellent predictability for your projects progress with Story Points in early project stages. This is because Story Points contain a self correcting mechanism. Slow or fast progress will show up early in the project.
• If you made some errors during your estimations the errors are very likely to be averaged out. Thus you do not have to care so much about the correctness of your estimates, which saves you good amounts of time.
• The estimates in Story Points are self adapting. If a team changes, the mechanism adjusts itself immediatly. If the teams performance increases or decreases you do not have to re-estimate. All estimations stay valid and you can still easily predict progress.

I do not love to say this, but there are two disadvantages at hand with Story Points from my point of view:

Shortcommings

• Firstly, they are hard to explain. Almost everybody is familiar with some estimation in man-days. The concept of relative and abstract estimates are difficult in the first place. But this vanishes after only a few weeks.
• The second point is that in our times and organisations you often have to do some recalculation from Story Points to man-days for financial reasons. This is easy, but is work that generates only limited value.

If you have any other arguments on estimations in Story Points - feel free to comment on this post.

In essence, the central goal of estimations is to get the necessary metrics and information to make progress transparent. This is obviously possible with both, man-days and Story Points. But considering the huge amount of advantages of Story Points this - at least to me - seems to be the better and more efficient way to achieve this.

But after all - it's an estimation technique and the only thing you can be certain about is that it's to some degree uncertain.

YABAA - Yet Another Blog About Agility?

For quite a time I was absolutely sure, that I could not help anybody by writing about my personal opinions or experiences. And if there is no value in writing for somebody, I will probably be better off spending my time in more value creating ways.

However, during the last few weeks I had lots of discussions giving me the impression that some of my expriences and insights could be of some value for others doing similar stuff as I do. Furthermore I am now convinced that writing about specific topics is of great value for myself, because it enforces me to reflect more on those topics. Since my main focus lies on applying and introducing agile methods I will probably mostly - but not exclusively - write about specific methods or insights I generated while doing exactly this.

So by now I am not anymore absolutely sure about the uselessness of my writing for others. This is a point following me through all of my life. In many things I was certain that assumptions hold true and was later convinced that good old reality thinks different.

• Long time ago I was convinced, that I am an exorbitantly bad student - advancing from school to university convinced me that this is not generally true 
• Long time ago I was convinced, that the US would not be a country I would like very much - traveling there convinced me that this is not true 
• Some time ago I was convinced, that perfectly executed classical project management is the only way to succeed - Scrum and agile methods convinced me that this is absolutely false 
• And there are many examples to be made...

What I learned from all of this is that you do not know anything for sure, until it is done and history - and even then you can discuss about facts...

So I decided to make one of my personal key insights the title of this blog: "It's Certainly Uncertain". Hoping, I will discover many, many more wrong assumptions in my further life and keep on learning.