Hierarchie oder Innovation? – Unternehmen müssen sich entscheiden!

Am Freitag veröffentlichte die Süddeutsche Zeitung einen Artikel, auf den ich schon seit Wochen gespannt war: Was sind eigentlich die Root-Causes des Abgasskandals bei VW? Wie konnte eine falsche und illegale Entscheidung getroffen und über Jahre aufrechterhalten werden, bei der es so offensichtlich war, dass sie dem Unternehmen bei der Aufdeckung so massiv schaden würde?

Der Artikel von Caspar Busse und Alexander Hagelüken „Nie mehr rumschreien“ beginnt mit einem Zitat aus Gesprächen mit VW-Mitarbeitern: „Wer aufgemuckt hat, ist niedergebrüllt worden“. – Sie berichten von einer Firmenkultur, die weder Kritik noch alternative Lösungen zuließ.

Sie zitieren Psychologieprofessoren und Wirtschaftsforscher, die klar die Nachteile hierarchischer Strukturen im schnellen Wandel des 21. Jahrhunderts ansprechen und auf Beispiele anderer Konzerne verweisen, die den Wandel geschafft haben oder auf dem Weg dahin sind. Guido Hertel, Direktor des Instituts für Psychologie an der Uni Münster, erklärt, Globalisierung, Digitalisierung und kürzere Produktzyklen sprächen dafür, die Mitarbeiter stärker an Entscheidungen zu beteiligen. Die Firmen würden so schneller und effektiver: „Viele Konzerne führen flache Projektstrukturen ein, um flexibel und innovativ zu sein“.

Post-Chef Frank Appel wird damit zitiert, der ganze Konzern müsse über Vertrauen geführt werden, um die maximale Leistung der Mitarbeiter zu erhalten: „Wenn man Vertrauen geschenkt bekommt, schüttet man Glückshormone aus, ähnlich wie beim Verlieben “ und „Am Ende kommt es natürlich darauf an, wie man mit Kritik und eingestandenen Fehlern umgeht“.

Logisch, dass VW-Konzernchef Matthias Müller einen Kulturwandel ankündigt, wonach frisches Denken und offenes Äußern von Zweifeln möglich sein sollen. Im Interview mit Thomas Sattelberger, ehemals Personalvorstand bei Continental und der Telekom, in derselben Ausgabe, sagt dieser allerdings zum Thema Kulturwandel für VW: „Es müssen die alten Seilschaften aufgebrochen werden, in denen einer wie der neue Oberkontrolleur Pötsch hängt. Dann müssen die Systeme der Zielsetzung, Beförderung, Vergütung und die Privilegien radikal überprüft werden. […]. Am Ende muss das Führungstraining auf den Kopf gestellt werden, um offene Reflexion und Selbstkritik zu erreichen.“ Und „VW erzeugt mit seinen Rekrutierungen und Beförderungen Klone. Mir sagte ein junger VW-Ingenieur, er hätte als Erstes das Gewerkschaftsbuch unterschreiben müssen. So bricht man ideologisch das Genick. Man kommt nur durch Wohlverhalten nach oben. Eine gute Firma fördert Querdenker und Einsteiger.“

Diese ganzen Erkenntnisse sind ja nicht neu. Es gibt ja in der Wirtschaft weit über Deutschland hinaus die Bewegung in Richtung Werteorientierung und Selbstorganisation in flachen Hierarchien oder gar ohne Hierarchien, die mit dem Thema „Augenhöhe“ angesprochen werden. Der CEO von 3M, William Mc.Knight, führte schon seit den 30er Jahren die Delegation von Verantwortung und Entscheidungskompetenz an Mitarbeiterinnen und Mitarbeiter ein und forderte 1948 in seiner Business-Philosophie eine fehlertolerante Kultur: „Manager, die destruktive Kritik äußern, wenn jemand einen Fehler macht, töten den Drang zur Initiative in den Mitarbeitern ab.“

In den 80er Jahren begann der radikale demokratische Wandel der bereits in anderen Posts erwähnten Firma SemCo, der zu einer beispiellosen Steigerung von Rentabilität und Dieversifizierung führte.

Nach 2000 haben z.B. Firmen wie Ericsson einen massiven Wertewandel angestoßen, mit dem auch eine tiefgreifende Änderung der Firmenkultur einhergeht. Der Finnische R&D-Leiter Harri Oikarinen verdeutlichte bei der XP2015-Konferenz in Helsinki, dass das Bild der Firma zunehmend von der Hierarchie zum Netzwerk geht, und die Manager von einst schrittweise von „Leadern“ und „Enablern“ abgelöst werden.

Wie geht nun der Kulturwandel vor sich? – Interessanterweise sehen die Autoren der Artikel in der Süddeutschen Themen wie Agiles Projektmanagement auch kritisch:

Der Soziologe Norbert Huchler vom Münchner Institut für Sozialwissenschaftliche Forschung habe beobachtet, dass sich in als modern gepriesenen Organisationsformen wie Zielvereinbarungen oder agilem Projektmanagement oft mehr Hierarchie versteckt als gedacht. Etwa, wenn Mitarbeitern in einem Team der nächste Arbeitsschritt vorgestellt wird und sie abschätzen sollen, wie lange sie brauchen – wodurch ein Unterbietungswettbewerb entsteht. „Das sind letztlich Instrumente, um den Leistungsdruck hochzuhalten. Sie folgen dem Menschenbild, wonach Beschäftigte nichts mehr tun, wenn der Chef weniger kontrolliert.“

Klar, bei solchen Aussagen, die die „klassischen“ Zielvereinbarungen mit der „agilen“ Abschätzung von Arbeitspaketen in einen Topf werfen, schütteln sich erst mal die Fachleute. Man darf aber nicht vergessen, dass Methoden nie im größten Teil der Fälle vollständig und richtig angewendet werden, sondern gerade die Agilität ja oft in der untersten Hierarchieebene stecken bleibt, und letztlich nur mehr Transparenz nach oben die Folge ist – ohne eine entsprechende Umsetzung von Vertrauen und Transparenz nach unten, ohne echte Selbstorganisation, ohne Pull-Prinzip, und ohne Einfluss der Mitarbeiter darauf, mit welchen Mitteln sie welche Projekte realisieren, inklusive ihrer notwendigen ständigen Weiterbildung.

Claudio Perrone stellt das mit diesem sehr treffenden Bild in seinem Vortrag „Terraforming Organizations“ dar, wo es genau darum geht, den Kulturwandel in Richtung Agilität über die unterste Ebene hinaus zu bringen:

Slide from "Terraforming Organizations" by Claudio Perrone.

Slide from „Terraforming Organizations“ by Claudio Perrone.

Wenn die gesamte Hierarchie der Organisation immer noch dem „X-Modell“ des Menschen folgt – „Menschen müssen kontrolliert und überwacht werden“-, während das Agile Projektmanagement vom „Y-Modell“ ausgeht – „Menschen wollen sich entwickeln und großartiges leisten“, wird eine agile Transition immer unvollständig sein und nur dazu führen, dass Unmengen von sinnloser Arbeit mit höherer Effizienz durch die Teams getrieben wird. Noch dazu wird dabei ignoriert, dass Agilität eine nachhaltige Arbeitsmenge und –geschwindigkeit erfordert („sustainable pace“), die Teams sich ständig weiterbilden und ständig ihre Vorgehensweise verbessern verbessern müssen.

Wie der große Management-Guru Peter Drucker sagte, gibt es nicht so nutzloses, wie etwas effizient zu tun, was überhaupt nicht getan werden sollte.

Agilität funktioniert also nur dann, wenn sie auf allen Entscheidungsebenen angewandt wird: Wenn schon die Auswahl der Projekte und neuen Produktmerkmalen nicht nach dem zufälligen Zusammentreffen eines Vorstandes mit einem einflussreichen Kunden im Golfclub erfolgt, sondern nach Kriterien, die den ganzen Markt betrachten, und durch die intensive Verwendung von Experimenten und Feedbackschleifen.Viele der neuen Software-Giganten, die in den letzten Jahren ganze Industrien vom Markt verdrängt haben, folgen dem „Lean Startup“- Muster mit Experimenten, kurzen Feedback-Zyklen und intensivem Kundeneinbezug, wie etwa Spotify und Netflix. So werden die Perlen unter den Ideen identifiziert, und sinnlose Zeitfresser landen recht zuverlässig im Papierkorb.

Daher ist es auch kein Zufall, dass in der bereits erwähnten Firma 3M seit den Zeiten von McKnight bis heute jeder Mitarbeiter 15% seiner Arbeitszeit einfach herumexperimentieren darf, ohne von irgendeinem Backlog zu arbeiten. Auch das ist Teil einer innovativen agilen Organisation, sei es in dieser Form, sei es in Form von „Ship it days“ oder „Hackathons“, die sich von der australischen Firma Atlassian aus in den letzten 10 Jahren über die IT-Welt verbreitet haben.

So schafft man Innovation und sorgt dafür, dass sie auch in Produkte umgesetzt wird.

The hardest job in a lean/agile transition is with the managers

When you are doing a lean/agile transition in a traditional organization, definitely the hardest job is related to the management.
I already highlighted the role and responsibility of executives in a lean/agile transition in another post two years ago. The people on the working level get into their new roles and practices. They are constantly doing retrospectives and improving their work, and even driving improvement through the organization. They experiment, get feedback and learn from it.

Now what will the middle managers do when they are not frequently needed for fire fighting in the projects? How are they going to practice new skills and habits that they need in the new agile world? And how much of the newly created trust and self-organization can a manager destroy with some harsh enquiry to a team?

At the beginning, many of the managers are obviously more or less engaged in the transition itself. Managers will also sit together and find out how they can coach teams, how they can help people to grow, and how they should do now hiring, performance evaluation, and distribute salary increases and bonuses under agile circumstances.

However, also during the transition it is easy to stay in a command-and-control mode or at least frequently fall back into it. After that, it is getting worse. Managers are moving around in organizations, some leave the place, others join. These others may be joining the company or department for totally different reasons than wanting to be a servant leader, a coach for growing people. Maybe they just want to work in this area. Period.

Now we need practices by which the managers stay constantly engaged with lean and agile ideas.

Act-Your-Way_into_new-Thinking-640

One of these topics is Continuous Improvement. It is one of the two pillars of Lean. Hakan Forss explains this is his Toyota Kata presentation – see slides or video.It starts with a common vision for the process of the organization that can probably never reached, and realistic but challenging goals on their way there. Then a team or several teams are improving by experimenting with small changes towards a next target condition, in turn with measuring the results. A lot of learning is involved in this, for the participants as well as for the organization.

Managers can be part of a team for changing things, especially above the level of a single agile team, for solving organizational problems, problems with processes and tools – always following a common vision with the teams, of course. Or they can also train to be a coach for doing this change. Of course, they have to take care like any other coach, that they have practiced the improvement kata themselves often enough, probably with an external coach, before they try to coach someone else.

Managers need to study and practice lean values and practices that they apply to their work with the teams. This can happen in self-study groups with the other managers, and everybody applies it individually. The challenge is always how they are getting feedback to their behaviour.  A good starting point may be the book Management 3.0. by Jurgen Appelo, that give some backgrounds on how a team behaves as an adaptive complex system, and how to grow a team, how to stop demotivating it, and how the boundaries influence the behaviour. His new Management 3.0. Workout book has a lot of tools that managers can apply, from the kudo box to the delegation board, ready to use or to adapt to their organization. By using these tools they slightly change the way how they are treating teams and individuals, expression more respect for people, which happens to be the other pillar of Lean.

Apart from using lean and agile practices in their own work, managers should also do the famous „Gemba walks„. This means going to the people who are actually working, and listening to them, e.g. during their daily standup meetings. The main challenge here is to do it without disrupting or frustrating the teams, e.g. by listening to two sentences and then throwing in an „easy solution“ to a problem without having enough knowledge for really helping them. Instead, only when the team seems to be clueless they can ask a couple of good questions for enabling them to find a solution themselves.

I am curious to learn in which other ways companies get their managers into „lean mode“ and keep them actively thinking lean and practicing lean.

Large Scale Agile at XP2013 Vienna – exchanging knowledge at a great conference!

From my perspective, the 14th International Conference on Agile Software Development XP2013 in Vienna was a great success. It took me to another level of confidence about what is needed to create and sustain a large scale agile organization.

The XP conferences are traditionally about programming and testing in an agile – XP – way, and organizing the team so that it supports XP practices. But they have grown into a conference that also covers  product ownership and design, leading agile teams and organizations, and even extending agile to the rest of the organization – this is agile real life in the industry.  What I like very much at XP conferences in general is the good mixture of experienced agile people from industry, some very well known consultants, and a lot of academic researchers who also are working close to industry about agile topics.

image

(Photo: Hubert Baumeister)

On the first day I got absorbed by the Executives & Managers Track with firsthand experience from four different companies: ABB, Ericsson, Johnson Controls and Nokia. Most valuable! The managers were speaking openly about what it takes to get agile, how their company transformation programs took one step after the other to establish agile on all levels. And this is still an unfinished journey, but it has a clear north. An important point from the talk of Hendrik Esser, who is Head of Portfolio and Technology Management at Ericsson, is

To embrace change, you have to change 3 things together
· Culture
· Practices and process
· Structure

You should never see agile as a process only, this will inevitably lead to failure. The most important cultural foundation for the agile transformation is building trust, and on top of the trust you can build transparency.

These three important transformations were mentioned by Per Branger from ABB in Sweden, but are basically identical to what Ericsson is doing:
· Continuous Portfolio Management
· Continuous Release Management
· Continuous Development

When they noticed at ABB that they are really a big software developing company, coming from a background of electrical engineering, they launched a massive knowledge and skills improvement program. The remarkable thing is that they measure progress by self-assessment of every developer against description of expected skills, and that the training comes in small portions and by self-assignment as well. Wiki based knowledge bases and Q&A tools that remind a bit of the famous stackoverflow website support the learning as well.  “Carrots, no sticks” opens also the path to using common tools.

Gregory Yon is Agile Coach at Johnson Controls and talked about how he is extending agile into the rest of the organization, to the non-development teams as well as convincing different levels of management from the agile values and needs. From him as well as from the other managers I learned that we can never communicate too much to higher management about the advantages of agile, and that we need  to measure things and compare with previous projects to show how we have advanced since the old times of waterfall.

Jorgen Hesselberg, Senior Manager, Enterprise Agile Transformation, Nokia (Chicago US) explained how they are using on all levels Agile Working Groups, mixed from management and project roles, to start and sustain agile transitions at each Business Unit, and keep them up and to extend agile to the whole company. The positive results of agile on the results as well as on the employee motivation are impressive.

My own presentation on our Distributed Product Owner Team for an Agile Medical Development was on the second day, and I loved the discussion with a couple of other speakers and participants about the needed knowledge and skills for this role, and the needs for communication in the PO team and with teams and customers. I have also learned that there is actually an open group of experts from industry and research with the goal to foster software product management excellence across industries, the International Software Product Management Association (ISPMA) , who are interested in collecting such practical experience, and are creating resources for professional software product management training.

At the academic track, I found a couple of presentations on the last day very interesting: A research paper by Jeanette Heidenberg, Max Weijola, Kirsi Mikkonen, and Ivan Porres – A Metrics Model to Measure the Impact of an Agile Transformation in Large Software Development Organizations asks whether an agile transformation was worth the effort. For this, they were looking for metrics that support agile values, focus on the whole organization, not individual or teams, and are applicable to both waterfall and agile projects. Also they should be feasible to collect for past and ongoing projects, in any size of project, and be objective and clear. They did an iterative approach with first formulating the goal, then ask practitioners for metrics used, compare them against their values and goals, and finally select a collection of metrics. They have some really helpful metrics that we can apply to learn how much we have already improved through agile, at least in some aspects.

The paper Continuous Release Planning in a Large-Scale Scrum Development Organization at Ericsson by Ville Heikkilä, Maria Paasivaara, Casper Lassenius, and Christian Engblom was complementing very well with the talk of Hendrik Esser, as they are exactly describing how the release planning for individual features works, and which experiences people at Ericsson had with this method.

Of course there were also great keynote speakers at XP2013 in Vienna, a helpful Open Space, a wonderful conference reception, and great conversations in the breaks.

image

As always, thank you very much for the photos, Hubert Baumeister.

The next XP conference will take place in May 2014 in Rome, which is also a nice place to go to.  I will convince some of our colleagues and managers of submitting a talk and participating – we have a lot of experience we can share!

Best Regards
Andrea

Role and responsibility of executives in a lean/agile transition

1) Choose internal change agents carefully

Volunteers
Positive mind and change orientated
Sense of urgency
Capacity for reflection
Work level experience in software development
Transition team covers different project roles and organizational units
Involve line management
Involve product management / business people
Involve process / Quality Management early

2) Be sponsor to the transition team

Give your vision, or agree explicitly to vision and mission of the transition team
Tell them what the constraints are
Be interested in plans and results.
Reed at least one good book yourself that does not look like a Scrum Bible, but something explaining what may work and why.
Do not expect to have NO impact on project time lines, this is just wishful thinking.
Give a reasonable budget based on estimates of the transition team
Do not tell them how to make the transition. Rather be able to discuss organizational changes on their request.
Let the team choose external consultants, but ask these people a couple of tough questions before you contract them.

3) Take care about trust in your organization

Do you, and do your middle managers trust your teams to get their job done? This is an essential part of any lean/agile transition.
If you are still not there, expect transparency to grow at the project team level, but you have to inspire trust from the management level. You need to start! You need to express trust to your teams and act accordingly yourself.

4) Do not combine a lean/agile transition with negative measures

Especially, do not try to reduce headcount. This is directly counterproductive to encouraging people to share their knowledge.

5) Foster a learning organization

Expect your organization to be on a learning journey for more than the transition lasts. The agile principles expect you to hire the best people, and give them the environment so they can be productive. In traditional hierarchical companies, often people need to learn to learn again. And often the environment consists of crappy old tools that make them slow. You may have tons of legacy code without automated tests. They will not magically disappear at the agile transition. The teams have to learn and improve a lot until they will really feel agile.
You will see improvements very soon, but this is not the end of your journey.

6) Look for opportunities to benchmark your transition with others

As executive you should use your connections with your colleagues from other companies for exchanging with them and creating opportunities for the transition teams and different project roles for comparing and exchanging experience so that you all learn more quickly.