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.

Scaling Agile with Frameworks – a SAFe path to LeSS work?

Ok, I admit right away that am just fooling around with the names of the two known large scale agile frameworks in the title – SAFe is the Scaled Agile Framework by Dean Leffingwell and company, and LeSS is Large Scale Scrum by Bas Vodde and Craig Larman.

The first book I read about scaling agile was from Dean Leffingwell, in 2007. I met Bas Vodde at my first Scrum Gathering in Stockholm 2008, and after I heard him talk about feature teams, I bought the book about scaling agile by him and Craig Larman as well, and of course we tried to apply much of that during our agile transition at Siemens Healthcare SYNGO. The book came very helpful since it clarified many of the questions behind the simple mechanics of agile, e.g. which effects queues have on you development organization, or how should the organization structure adapt to agile, and which other topics or areas beyond R&D are concerned.

In the last couple of months various people kept asking me about “Should we apply a large-scale framework to our agile transition?” – and asking back I get the underlying questions, of course, will we be faster, safer, cheaper, avoid start-up problems, will we have to read less stuff and discuss less if there are solutions available online and even people rolling out the one or the other framework licensed by the respective framework’s prophet(s)?

OK, let’s see if they themselves come with a warning message, like the drugs do in Germany, a little paper full of text that is in each box.

 

LeSS

„LeSS is not “new and improved Scrum.” Rather, it is regular Scrum, an empirical process framework in which you can inspect and adapt to any method and work in a group of any size. Large-scale Scrum is a set of additional rules and the set of tips that we have seen work in large multi-team, multisite, and offshore agile development initiatives. These tips are experiments to try in the context of the classic Scrum framework.“ (http://less.works/less/principles/large_scale_scrum_is_scrum.html)

 

SAFe

The Scaled Agile Framework (SAFe) is a proven knowledge base for implementing agile practices at enterprise scale.” “We, the contributors, offer this web version to the market in the hope that it will help all software development practitioners and team – as well as their employers – enjoz the satisfaction that comes from delivering ever-higher quality software at ever-faster speed” (http://www.scaledagileframework.com/about/)

OK, sounds good, but how can people start using it?

Now I switch to the “Implementation” page of SAFe: (http://www.scaledagileframework.com/implementing/)

Implementation is done in three steps, which come with lots of training and certification with trained and certified SAFe trainers: step 1 Change Agents, step 2 Management & Executives, step 3 teams and agile release trains – challenging, in 5 days per train, 8-12 Scrum teams per release train. Maybe it is intended for different kinds of enterprises than those I know, which have a lot of legacy to reflect about: structures, processes, products, codebases… and include properly into their new setup, so that they can go on delivering something to their customers.

 

So what do the LeSS guys say about implementation?

“These principles are crucial to an organizational LeSS adoption:

  • deep and narrow over broad and shallow
  • top-down and bottom-up
  • use volunteering”

“Prefer applying LeSS in one product really well over applying LeSS in many groups poorly.

Focus LeSS adoption effort on one product group, give them all the support they need, and ensure they work really well. This minimizes risk and if you fail it triggers a focused learning opportunity. And when you succeed it creates a positive “word on the floor” that’s vital nourishment for further adoption.”

And so on. I could not have phrased it better.

It reminds me of what a manager from another big company reported last year: lean and agile transitions worked great in their organizations which had self-chosen to transition with a mixed bottom-up/top-down approach, and where there were convinced local coaches. It did not work at all in organizations that were made “lean” through a big top-down rollout.

Frankly, I cannot imagine that any internal coaches who have neither seen nor done any agile work themselves, in product development teams on the ground, can be of much use in a large-scale rollout. So you need to start small, experiment, learn your own lessons.

By the way: yes, the LeSS guys are also offering trainings and even certifications. I would recommend to send people there who are already such local agile practitioners and have either worked in an agile team themselves for at least one year, or have been active participants in a transition team at smaller scale for at least the same time, and take the course in order to know more and improve, or roll out to a larger part of their organizations.

Don’t get me wrong: I think the SAFe framework can also a great source of inspiration and hints for solutions for organizations going agile in small or large-scale. I remember that we had a problem with making the product owner team feel responsible for prioritizing technical debt and technical improvements high enough, and we found a good example in SAFe how this can be solved: by agreeing on a percentage of the organization’s velocity dedicated to technical improvements by mutual agreement between architects and product owners, and then prioritization of actual technical backlog items by the architects.

Then only thing that I am very convinced about is that you cannot buy a large-scale agile transition, you do have to do it yourselves.

Slides for ScanDev 2013 DONE: distributed product owner team – strategies

One week to go for this year’s ScanDev conference in Gothenburg, and slides are done.

image

Topics covered are mainly:
Strategies for growing a distributed product owner team, when the problem space is very different from the normal experience world of a software developer. Strategies for communication and customer collaboration in the distributed setup.

For preparation, I made a lot of personal interviews with product owners on different hierarchy levels and multiple sites. I learned a lot about the reality behind our official agile framework, and how much the real success depends on people and their skills and goals.

To convert my knowledge into an interesting presentation I used a marvellous book, a classic: Presenting to Win: The Art of Telling Your Story by Jerry Weissman. What is very helpful in this book is that he tells you a lot of stories to make sure you know what you want to tell, to whom, and how you will bring this across to your audience. So I started to create my presentation on a lonely day at home, using hundreds of sticky notes on my personal whiteboard, instead of bothering with Outlook templates or -beware!- assistants. Then I selected a structure for the slides that would allow me to tell my story, and then I created each single slide on a sheet of paper, put them into the structure, re-ordered and finally bright them to the office.

image

There, of course, I had to take a corporate template, and also picked a lot of photos, that would this time nicely fit with the topic. As structure I had selected a pyramid. I created it with corporate colors, and let it build up throughout the slides.

At the beginning of this week, it was finished, and I submitted it for review and release. And -wow! -I got it released after considering a few remarks, in less than two days. I can say, the release process got much more agile since I first used it for an external presentation four years ago, when it still took me four weeks, but obviously as well my own professionalism in creating publications has increased a lot since then.

Speaking at ScanDev 2013 about our Distributed Product Owner Team @ Syngo.via

I am speaking at SCANDEV 2013

This week I received the news that my new talk has been accepted for SCANDEV 2013 on March 4th to 5th in Göteborg, Sweden. The title is „Distributed Product Owner Team @ Syngo.via“

What is it all about?

We are developing medical imaging and workflow software in an agile way with development teams distributed to several countries. One of the major challenges is how to set up and communicate within the Product Owner team.

  • There we have to deal with the distribution, e.g., have the Product Owner either onsite with her peers or with her Scrum team, travelling, or with proxy.
  • We need people who are good in two different fields of knowledge: medical and software development.
  • As a third issues, the environment of the customers may be different in different countries.
We have ramped up local Product Owners in different countries, have found local collaboration customers, and have developed  a set of communication channels and workshops how to synchronize Product Owners in the team, share a common vision and backlog with their Scrum teams, and collaborate with customers locally and globally.
While I am putting my presentation together, I would be interested very much in what my customers want to know about. You can ask me questions, and whatever is feasible I will include into my talk. So Product Ownership is being directly applied.

A great audiovisual 15 min training on Product Ownership

Yesterday a friend sent me the link to a great audiovisual mini-training on Product Ownership, that Henrik Kniberg just published on the CRISP blog http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell.

It is amazing. It does not only explain important aspects of the Product Owner role is an easy to understand way, but also visualizes central aspects of agile software development like fast feedback, velocity, and release forecast. And all of this in only 15 min!

The technique used reminds me of the famous „RSA Animate“ 10 min science videos. One of the most remarkable maybe the one explaining Dan Pink’s research about what motivates us. http://www.youtube.com/watch?v=u6XAPnuFjJc

Well done, Henrik!

Agile is about the people!

Sometimes I see blog posts or LinkedIn discussions where some agile specialist or special agilist reasons about the exact amount of minutes to spend on each Scrum meeting according to sprint length, or he asks how he can measure and compare the productivity of teams.
Often I have the impression if I asked him now “How is the motivation of your teams? How do they feel, are they happy or frustrated? Do they have all the tools to get their job done? When did you last time clear some organizational obstacles out of the way for them? Have you hired the right people, and given them lots of opportunities to learn?” or anything alike, this kind of specialist would stare at me without getting the issue.
Actually, this is the centre of the universe – is the people, not the final twisting and tuning of an ideal Scrum process. Scrum is about the people!
Even the managers I know, some managers who have done so incredibly many things right, – even they, at rare times, of course, come up with something like “but now if I would like to compare the productivity of two teams, how would I do it?” and they think very hard about it. 
 
Then I ask them: Have you invested already enough time into how they can learn something new about the product domain, stay up to date with their architecture and programming knowledge, know how to use the latest tools you have bought them? Have you spent a similar amount of time on how to sharpen the product vision with the Product Owner, so that he can really make developers happy working on this marvellous project? If I wake up a Scrum team member in the middle of the night, would he or she be able to tell me the product vision? Have you thought about organizing a FedEx day so they can try out new features of their favourite programming language just for fun, and get fresh motivation for a couple of sprints?

This is what I ask my managers in such cases. Metrics and measurements are fine, but you always need to seed before you harvest.
Hey, it’s about the people!