Agile - The Whole Story

You perfectly adopted Scrum - but some people are still complaining, that this was not the big deal? Had a huge agile adoption, top management involved, lots of new structures - but defect rates in your systems are not where you expected them to be?

Maybe the reason for your observation is, that you did omit one or more levels of the Agile pyramid of needs.

The "Agile Pyramid of Needs"

Agile essentially is a mindset. A culture. Many processes and tools (left side in the picture) are derived from the core values of this culture and they work seamlessly in Agile cultures. This is because on every level, people think in Agile ways and tailor their respective field of work to fit an Agile approach.

Nevertheless, companies that do not inherently have an Agile culture might want to get there, too, because it does have great advantages. The first step on this journey is often to adopt one or more of the Agile tools and processes mentioned above. But none of those processes or tools addresses all levels of the pyramid. This leads to some improvements and eventually small cultural changes on several places, but the success of truly Agile companies is not achieved.

Have a look at the pyramid above and see, if your Agile efforts hit all levels of the pyramid. If they do not, many of the problems you encounter now might stem from different cultures emerging (or staying) at different parts of your processes and company.

Maybe the pyramid model helps you to identify areas, where you missed to think about the impact of Agile. Identifying those areas will not immediately help you to change the culture of your company to an Agile one. Culture cannot be bought and is really hard to change. But processes and tools do have influence on culture. So finding the tools that address the blind spots in your Agile adoption might be a good next small step towards becoming a better company.

-----

Levels of the "Agile Pyramid of Needs":

1. Basic Needs - solid craftsmanship is in place, everybody knows his business basics: Test Driven Development (TDD), Continuous Integration, Software Craftsmenship, ...
2. Safety - you can build and release securely and with high quality: test automation, experience, automated security tests, continuous integration & deployment, ...
3. Belonging - teams are in place and doing a great job jointly: Scrum, eXtreme Programming, team building, retrospectives, Scrum Master, Agile Coach, ...
4. Self-Esteem - you know your business value, speak about and optimize it: Kanban, Scrum, Beta-Codex Network, Radical Management, ...
5. Self-Actualization - you do organizational experiments: Stoos, Management Innovations, ...

What Agile tools and processes do you know? On which level of the pyramid would you see them? Feel free to leave your comments!

See also:

• http://www.bigvisible.com/2008/12/maslows-hierarchy-as-an-agile-adoption-framework/
• http://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs

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.

Is This Company Agile?

Recently Boris Gloger tweeted the question:

Why do you work for a non-agile company? (1) › bor!sgloger - http://t.co/4L3LcTNOAa
— Boris Gloger (@borisgloger) October 3, 2013

This made me think: "If I would switch positions to another company - how could I find out, if it is really agile?".

My first approach to answering this question was to answer the following two questions:

• Which interfaces are there between me and this company?
• How can I see, if it is only the interface looking agile or the whole company beeing agile?

This resulted in the following list of companies interfaces:

• Web Page
• Building
• Job Interview
• Friends working there
• Social Media
• Classical Media (e.g. Newspaper)
• Rating Sites (e.g. WorldBlu, Kununu, glassdoor)
• E-Mail
• Phone call
• Job Advertisement
• Products
• Customers

I tried to figure out, how one could possibly learn about the agility of an organization by observing those interfaces. And failed. The only interfaces, that are likely to give some clue about agility are the two "organic" ones where you meet somebody working in this company:

Job Interview

In 2012 I participated in a Stoos Stampede session, where some guys collected a large set of really nice questions for a job interview. Some other guys even ordered them in a nice way. I think this is a good resource to look at before your next job interview.
Anyway - you should take a round trip through the company and have look in the faces of people. Observe their interactions and just listen to what happens, what does not happen and how people behave.

Friends working there

Probably the best source for information about any company is your network. Look out for friends and people you know, working for this company. You should ask them every question, that you are interested in and will very likely get an honest answer.
However: Even friends and relatives have different receptions of reality and different tastes!

What else?

After looking on the other interfaces for several days and trying to figure out, how agile companies differ from non-agile companies, I realized that this is probably a mission impossible: Being agile is a deeply cultural thing (as you can see e.g. here and here) and you will not be able to assess a companies culture by observing artifacts only.

So - what else?

I then remembered a really good book, I read some months ago: "The Corporate Culture Survival Guide" by Edgar H. Schein. Schein proposes a cultural model in this book, which consists of three levels:

• Artifacts: All the things you can see, hear, taste, ... All of the non-organic interfaces mentioned above are artifacts.
• Espoused Values: This are the values, the organization communicates actively. E.g. "customers first" or "employees first".
• Tacit Assumptions: This is the real hot stuff. Tacit assumptions are things everybody in the organization knows implicitly and which determine the factual behaviour of employees. This is the core of the companies culture.

(I already explained this and other culture models in a former blog post)

Schein additionally proposes a workshop format to assess a companies culture. This consists of seven steps where three steps are actually used to investigate the tacit assumptions, i.e. the real culture of a company:

1. Identify and list artifacts: Look at all artifacts, you can observe. To do this for a company, you are not part of, you can use the interface list above and observe, how the company behaves over this interfaces. Do they react fastly on customers questions? How does the building of the organization look like? What about the design and usability of the website?
2. Identify the organizations espoused values: Try to get all statements about companies values, you can get. A good way to do this is the web site, where you might find a blog or other content about companies values. Another way is to search the web for the companies vision and mission. Especially the latter one will probably contain some espoused values.
3. Compare values with artifacts: Write all identified artifacts on the left side of a whiteboard or sheet of paper and all espoused values on the right side. Look out for conflicts between espoused values on the right and artifacts on the left. If you find a conflict, you have likely found something that points to a deeper lying tacit assumption held within this company.

If you have this list of tacit assumptions, you will probably get a good feeling for the agility or non-agility of a company. If you take this list to your job interview at this company and discuss it with your counterpart, you are very likely to get a good sense for the agility of the company you are interested in.

Do you have any other ideas, how one might be able to find out how agile a company is before one joins the company? Please use the comments section and spread your ideas!

Update 1: Further Readings (Blog posts recommended to me after publishing this, etc.)

• "Perspectives on Rightshifting" - Bob Marshall

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!

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

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