Lean on One Page

This drawing is part of a Leanpub book: https://leanpub.com/agileplanet. If you like it, you might want to have a look at the book, too.

References:

• "Implementing Lean Software Development" - The Poppendiecks
• "Leading Lean Software Development" - The Poppendiecks
• Presentation on Lean Software Development Principles - John P. Vajda
• Lean on Wikipedia

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.

Scrum as a Diagnostic Tool

Use the Scrum lens for inspection

What is Scrum? If you ask this question, you might hear a rich variety of answers. Reaching from „a method to process tasks“ over „a project management framework“ to „an instrument for organizational change“.

But this is not Scrum. These are different applications of the Scrum framework. Scrum is essentially just a collection of useful and proven to be succesful rules and practices. It is a theoretically close to ideal state for product development.

If you assume the Scrum framework to be a close to ideal state, then you can use it to find problems in different contexts – even without applying  it immediately. Let me give an example: Some years ago I was in trouble with a classically led project. At the same time I learned about the Scrum framework and thought: „How would it be, if we wanted to practice Scrum tomorrow?“. After asking myself this question, several issues why this would not work came to my mind, immediately. E.g. we would find no Product Owner, the customer would never work with us on a daily basis and we could never deliver software every two weeks. Thinking for a while I realized, that these issues where just the problems the project suffered from. Thus, trying to imagine using Scrum in my current situation helped me to consciously realize what the real problems were.

This idea is scalable: If you want to know what the real top five problems of an organization are, just go to a diverse set of people in this organization, explain shortly what Scrum is and ask them if this would work for them. Then carefully listen and note the reasons mentioned for the impossibility of using Scrum. After several interviews try to cluster and prioritize the issues you found and I bet you will have a very close picture of what the central and demanding problems of the respective organization are.

Just try it. This is much cheaper than hiring a consultancy and will – probably – deliver very similar results ;-)

Leadership Dojos

I see – and hear of – many organizations having trouble with leadership. Starting with the question „what is leadership?“ reaching to problems in concrete application of leadership skills in daily business. One urgent question is: „How can we make clear to leaders in our organization, what leadership is and what our organizations expectations to leaders are?“. Seminars and trainings are a frequently chosen approach in trying to sharpen the understanding of leadership in a company. But I have my reasons to doubt this tools are working.

A very pragmatic and effective way to deal with problems of alignment and lack of practice in software development and coaching are coding dojos and coaching dojos. I tried both tools and found them to be very useful in making clear what the expectation of the trainer is and recieving valuable practical lessons. Transfering this concept to the topic of leadership could look as follows:

1. Choose a standard – but not so easy – situation from the field of leadership (e.g. a worker is not motivated, there is a conflict between two co-workers, etc.)
2. Try to model the situation as good as possible and prepare a role play. There are three roles: the „leader“, the „challenger“ and the „observer“. Distribute these roles to at least three people („challenger“ and „observer“ might be taken by more than one person)
3. Take a time frame of approximately 30 minutes and a room where the prepared situation would be likely to happen in reality.
4. The „challenger“ will now try to play his prepared role as good as possible and the „leader“ has to try to „solve“ the given problem. The „observer“ is not allowed to speak and just observers the situation and makes notes for a later discussion.
5. After playing the role play for 30 minutes the game is stopped and the observer tells the leader about his observations. At this point expectations of an organization to their leaders can be made clear in a very practical, effective and sustained way (if the observer knows about these expectations).
6. Restart at step 1 based on the feedback oft the observer.

Did you try something like this before? What are your experiences? Do you have further ideas for concrete situations to role play? Feel free to use the comments section for your feedback!

Build Flexible Organizations!

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

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

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

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

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

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

Promote Your Teams

Promote your teams!

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

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

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

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

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

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

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

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

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.

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!

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

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.