Agile Practices and Culture

Speaking of Agile Transitions, I often hear two kinds of hypotheses:

1. "We will have to change the culture here, to be able to introduce Agile practices."
2. "We will have to introduce agile practices here, to change our corporate culture."

Those statements are somehow opposed to each other. Sixty-four-dollar question: Which one is correct?

[...]

Maybe a short look on Dilt's pyramid of personal change helps?:

[...]

And the answer is (as always): None of them. It's somewhere in between!

Practices influence your culture and your culture defines largely, which practices you use. Both statements contain some truth, but both are not complete. If you want to change successfully, you will have to focus on changing practices and at the same time reinforce changing attitudes and cultures, thereby changing used practices...

See also:

• Agile - The Whole Story

Kanban on One Page

This drawing will appear as part of a Leanpub book, explaining several Agile topics in a and quick and entertaining way, soon. If you are interested in the book, I would very much appreciate if you subscribe here: https://leanpub.com/agileplanet

Resources:

• "Kanban: Successful Evolutionary Change for your Technology Business" - David J. Anderson
• Wikipedia on Kanban
• Arne Roock posts on Kanban topics regularly on his blog.

Public Secrets of Mount Change

Change is hard!

To change something does always mean, to risk something - to loose something. In exchange we always have the chance and hope to win something. Ideally, we loose something bad and win something good. But we do almost never know...

What we know is, that it is deeply human trying to adhere to the current state.We call that e.g.

• Loss aversion
• Risk aversion
• Ambigutiy aversion
• ...

So: Change is hard!

Does this mean that you should never change? No! But if you think you have to face a big change initiative, you should be able to really answer two questions for yourself:

1. Is there a desire, necessity or urgency perceptible that will make the effort of climbing Mount Change seem smaller than bearing the consequences of standing still?
2. Do you have a clear vision, mission or goal that will ensure that people roll down Mount Change together and in the right direction?

Only if you have clear and simply understandable answers to these two questions, you should start your efforts. For that you will not forever start and never reach the top of Mount Change. Nor will you roll down the hill and fall of some cliff because some people took the wrong direction.

Don't misunderstand me. You are not done with answering these two questions. But it is an important point to start. And you are ready to take up your hiking stick, then. Good reads on the change topic are:

• "The Corporate Culture Survival Guide" by Edgar H. Schein
  This book exposes the rich set of experiences of Edgar Schein, who is one of the first, most famous and influencial organizational psychologists.
• "How to Change the World" by Jurgen Appelo
  This book stresses out a view on organizational change that is based on systems- and complexity theory. It is not a complete collection of steps for a succesful transformation, but a brilliant guide to getting the right attitude towards organizational change.

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.

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.

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).