Baue einfach bessere Produkte in einem besseren Arbeitsumfeld.

Für einen Berater mag das ein ungewöhnlicher Rat sein und alle die hier nicht weiterlesen wollen kann ich wohl vorerst aus meinem Kundenkreis verabschieden. Lasst uns in 10 Jahren noch mal darüber sprechen, wenn es so richtig eng wird.  

All jene die glauben, dass ein Fünkchen Wahrheit darin stecken könnte, mögen diesen Link bitte  weiterleiten, denn es handelt sich hier um einen Massenphänomen, das wir nur gemeinsam ausmerzen können.

Die folgenden Grundannahmen könnten uns dabei helfen:

Jeder will produktiv sein. Leider hat nicht jeder das Glück in einem Umfeld zu arbeiten in dem er das auch kann. Aber warum führen so viele Organisationen lieber Performance-Reviews, komplexe Arbeitszeitnachweise, Quartalsziele mit Bonuszahlungen und den ganzen Unsinn ein, anstatt das Problem an der Wurzel zu packen. Lasst uns doch lieber gemeinsam ein Arbeitsumfeld schaffen in dem Produkte entstehen können, die jemanden vom Hocker reißen! Ist ja nicht so, dass wir nicht wüssten wie es geht (Google, Apple, Facebook anyone?). 

Jeder will an einer guten Sache arbeiten. Leider gibt es viele Unternehmen, die regelmäßig das gleiche billiger anbieten. Außerdem gibt es noch Unmengen von Produkten, die wirklich niemand braucht. Gibt es eigentlich auch einen Award für Produkte die niemand braucht? Das wäre toll, denn dann könnte man auch gleich sehen wo man wirklich nicht arbeiten will. Nestlé Kindermilchschnitte gefällig?

Warum also nicht die Produktivität steigern? Ganz einfach. Es gibt nur zwei Gründe, warum ein Unternehmen Produktivitätsprobleme haben kann.  

a) Das Arbeitsumfeld passt nicht. So what? Fix it! 
b) Die Produkte passen nicht? So what? Fix it!

Dabei möchte ich noch anmerken dass a) und b) sich wechselseitig unterstützen. Manche Menschen sind bereit Lebenszeit in miese Produkte zu investieren, wenn dafür das Arbeitsumfeld einen Ausgleich schafft. Andere wieder basteln in ihrer Garage gerade die Spielveränderer von morgen.

Letztere sind die Hunde, die beißen. Wau!

Ich versuche schon seit Jahren Manager für neue Ansätze zur Unternehmensführung zu begeistern. Wenn Facebook heute die erste Billion Benutzer feiert und unsere Banken so nebenbei mal wieder eine Billion Euro haben wollen, müssen wir aber mehr hinterfragen als neue Wege in bestehenden Organisationen.

In unserer Geschichte ist Machtkonzentration schon oft als Wegbereiter für Unfrieden in Erscheinung getreten. Wenn die Kurzsichtigkeit, mit der Organisationen heute agieren, dann auch dazu führt, dass wir uns als Spezies den Atem abschnüren, dann müssen wir uns fragen, ob die Organisationsformen des letzten Jahrhunderts noch brauchbar sind.

Ich hoffe, dass mir das nun nicht als linke Träumerei ausgelegt wird, aber mir drängt sich eine Frage auf. Wenn Organisationen eine gesellschaftlich relevante Größe erreichen, müssten sie sich dann nicht auch den demokratischen Prinzipien unterwerfen an die die meisten von uns glauben?

Hätten wir alle wirklich Rupert Murdoch gewählt, um bestmöglich mit Information versorgt zu werden? Würde ein demokratisches System jemals Kernkraftwerke bauen, den Regenwald abholzen oder Millionen Liter Öl ins Meer gießen?

Wir müssen uns fragen, ob für größere Organisationen (jenseits der Dunbar-Zahl?) nicht völlig neue Spielregeln gelten sollten. In einem demokratisch legitimierten System (Wollen wir es wirklich noch Organisation nennen?) stellen sich viele Fragen nicht mehr, die uns heute quälen.

"Too big to fail" is actually failing. 

Viele erfolgreich umgesetzte Ideen erscheinen im Nachhinein oft entweder als die geniale Schöpfung eines Genies, oder als purer Zufall - mit einer deutlichen Tendenz zum Letzteren. Man denke nur an Facebook, Google, Twitter, SMS, Penicillin. Aber ist das wirklich so?

Für einige ist das jedenfalls Grund genug, um viel Energie in die Ideenfindung zu investieren, denn auf den Zufall kann man sich nicht verlassen. Tatsächlich hat aber jeder von uns Tausend Ideen pro Tag. Das beginnt mit „Kaffee wäre super“, steigert sich über unzählige berufliche Ergüsse und schließt meistens mit „Ich gehe jetzt schlafen“.

Ich bin oft versucht zu glauben, dass berufliche Ergüsse, spezieller und komplexer sind als all die anderen. Aber sind es wirklich die großartigen Ideen die zum Erfolg führen? Oder ist es vielleicht eher das ständige Austesten von Möglichkeiten und das konsequente Verwerfen von lieb gewordenen Ideen.  

Ich plädiere für letzteres. Lasst uns beim Kunden beginnen. Lasst uns gemeinsam Ideen entwickeln, sie austesten, anreichern und  auch mit Begeisterung wieder verwerfen. Es gibt keine größere Verschwendung als an einer Idee festzuhalten und ein perfektes Produkt zu entwickeln, wenn es dann niemand braucht.

Frei nach Peter Drucker: „Zuerst die richtigen Dinge tun, dann erst die Dinge richtig tun".

Tipps zum Nachlesen: 
Lean Startup (Eric Ries), Effectuation (Michael Faschingbauer)

Beim letzten Scrum Tuesday Vienna hat uns Clemens Böge etwas über Effectuation erzählt. Mein Fazit ist: Ein echter Innovationsschub kommt selten als Anforderung daher, sondern viel eher als Entdeckung beim Effektuieren. Ich möchte dich zu einem kleinen Gedankenexperiment einladen und beginne dort wo die meisten IT-Projekte beginnen: Bei den Anforderungen. 

Wenn von Anforderungen die Rede ist, schwingt im Unterton oft schon eine klare Ziel- und Sprechrichtung mit.  Die Anforderungen kommen vom Kunden. Der Kunde sagt wo’s lang geht und das Entwicklungsteam kümmert sich um das „Wie“. Klingt logisch. Ist es auch. Kausale Logik versagt aber bei komplexen Innovationsvorhaben häufig. Besonders dann wenn das Thema für alle Beteiligten neu ist. Sowohl das Team auch die Kunden müssen dazulernen. Das wird auch oft verstanden und unterstützt. Mit agilem Vorgehen nutzen wir kurze Feedbackzyklen, damit alle schneller dazulernen können. 

Wenn es um die Anforderungen für den nächsten Sprint geht, dann sind sich Product Owner und Team aber schnell einig, dass man vorab Klarheit braucht. Wenn das Ziel nicht klar ist, kann man auch nicht ankommen. So oder so ähnlich tönt es oft zu Projektbeginn.

Nicht so bei Effectuation. Effectuation kommt aus der Entrepreneurship- und Innovations-Forschung. Prof. Saras Sarasvathy hat in ihrer Forschung untersucht, wie erfahrene Unternehmer Produkt-Entscheidungen treffen. Sie kam dabei auf ein paar erstaunliche Ergebnisse. 

So steht z.B. nicht die Zielorientierung im Vordergrund, sondern die Mittelorientierung! Es steht auch nicht der erwartete Gewinn im Vordergrund sondern der leistbare Verlust. Unternehmer nutzen Zufälle und Partnerschaften.

Das steht im Widerspruch zum viel strapazierten Business Value, den wir in Scrum Projekten mit jedem Feature anstreben wollen. Henry Ford soll einmal gesagt haben „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde“. Ich behaupte, dass viele Product Owner, Produktmanager und Projektmanager das Tuning ihrer Pferde perfektionieren. Ein echter Innovationsschub kommt aber selten als Anforderung daher, sondern viel eher als Entdeckung beim effektuieren!

Ein Gedankenexperiment:

Was geschieht, wenn du dein nächstes Projekt nicht bereits mit einem voll aufgefüllten Backlog für den ersten Sprint beginnst? Anstatt gleich mit Vollgas in die falsche (?)  Richtung abzudampfen könnte es sich lohnen mehr Zeit zum Effektuieren zu reservieren:

• Was wissen wir schon über das Vorhaben? 
• Welche Fähigkeiten und Fertigkeiten haben wir im Team? 
• Für welches Thema haben wir vielleicht sogar schon einen Lösungsansatz? 
• Wie können wir ihn möglichst schnell validieren?
• Was können wir besonders gut und möchten es im Projekt als Stärke nutzen?
• Wie viele effektuierte Lieferungen (Features, Spikes) können wir uns leisten?
  Beispiel: 100% Effectuation im ersten Sprint, 50% im zweiten Sprint, 20% in allen weiteren. 
• Welche bestehenden Kontakte oder Partnerschaften könnten uns helfen, das Problem schneller oder besser zu lösen.

Im Projekt-Alltag wird das Wichtige oft vom Dringenden ausgebremst. Gerade zu Projektbeginn und davor kannst du mit Effectuation aber wichtige Weichen stellen.

Veranstaltungstipp: Michael Faschingbauer und Clemens Böge halten am 1.12 einen 1-tägigen Workshop zu Effection in Wien (http://bit.ly/effcn)

Im Anschluss an den PMA-Focus habe ich ein paar E-Mails mit Brigitte Schaden, der Vorstandsvorsitzenden der PMA zum Thema Agile und Zertifizierungen ausgetauscht. Ich finde die Haltung der PMA zum Thema Agile diskussionswürdig. Was meint ihr?

Michael Laussegger: Ich habe die Podiumsdiskussion zum Thema Agile gestern mit einigem Interesse verfolgt. Eine Frage ist für mich dabei offen geblieben: Warum sollte jemand, der in erster Linie agile Projekte abwickelt (bzw. abwickeln muss) eine IPMA-konforme Ausbildung und Zertifizierung machen?

Brigitte Schaden: Wenn jemand generell "nur" agile Entwicklung in der IT durchführt ist es sicher kein "Muss" sich zertifizieren zu lassen. Aber es handelt sich eben um die Methodik (Vorgehendsmodell) und nicht um eine ganzheitliche Projektmanagement-Kompetenz. 

Michael Laussegger: Überraschend fand ich ihre Schlussfolgerung, dass es Agiles Projektmanagement „nicht gibt“. Agiles Vorgehen impliziert schlanke Prozesse, persönliche Kommunikation, kurze Lieferzyklen, flache Hierarchien, selbstorganisierte Teams, aktives Wissensmanagement, kontinuierliches Lernen und eine Wertebasis die das alles erst ermöglicht. Das berührt alle Kompetenzbereiche der IPMA-Richtlinie. 

Brigitte Schaden: Eben, wie Sie selber sagen, das betrifft die Kompetenzbereiche der ICB und somit "generisches" Projektmanagement, das situationsbezogen (projektbezogen) eingesetzt wird. D.h. es gibt keinen Grund ein "agiles" PM zu "erfinden"

Michael Laussegger: Ich stimme ihnen auch zu, wenn sie sagen, dass das klassische Projektmanagement agiles Vorgehen nicht verbietet. Allerdings heißt das noch lange nicht, dass es dabei hilft. Und genau da sehe ich das Problem. Ich vermisse im klassischen Projektmanagement (Ausbildung und Zertifizierung nach IPMA) Werkzeuge, die im agilen Umfeld hilfreich wären. Dieser Werkzeuge sind seit über einem Jahrzehnt bekannt und werden weltweit erfolgreich eingesetzt. Gleichzeitig sind viele Elemente der Ausbildung in einem agilen Umfeld zwar nicht verboten, aber einfach unnötig. PSPs, Arbeitspaketspezifikationen und Netzpläne habe ich schon seit Jahren nicht mehr benötigt und das sind nur einfache Beispiele. Nützliche Praktiken aus der agilen Welt fehlen hingegen (zB Product Backlogs, Daily Standups, Burn Down Charts etc.). 

Brigitte Schaden: Nocheinmal, die IPMA Zertifizierung ist methodenunabhängig, d.h. es wäre auch möglich ein agiles Vorgehen zu wählen. Trotzdem würde es nicht genügen wenn der Kandidat nicht auch andere Projektarten managen könnte. Es geht darum die Kompetenzen aller 46 Elemente zu evaluieren. Zum Beispiel braucht auch ein Projektmanager in der agilen Entwicklung Sozialkompetenz und Kompetenzen in Kontextbereichen. Ich könnte mir durchaus vorstellen, dass bei etwaigen Methodenübersichten auch agile Werkzeuge angeführt werden können, aber eben nicht nur.

Michael Laussegger: Darüber hinaus wird in den Ausbildungen ein Mindset unterstützt, das einen streng kausalen, analytischen Managementansatz bevorzugt. Wir haben es aber zunehmend mit komplexen Systemen zu tun in denen Regelkreise wirken, die sich dieser Sichtweise entziehen. Und damit einer  längerfristigen Planbarkeit. 

Brigitte Schaden: Sehe ich auch so...

Michael Laussegger: Mir stellt sich heute die Frage nach dem Mehrwert, den die IPMA im agilen Umfeld zu bieten hat. Warum sollte jemand, der in erster Linie agile Projekte abwickelt eine IPMA-konforme Ausbildung und Zertifizierung machen? 

Brigitte Schaden: wie schon gesagt, wenn der Focus "nur" auf agilen Projekten liegt, kein "Muss". (abgesehen davon, dass für eine Zertifizierung keine Ausbildung vorgeschrieben ist...) Trotzdem bestätigt die Zertifizierung Kompetenz in allen 46 Elementen, davon sind eben nur die technischen "methodisch")

Once upon a time there was a little tribe, spread all across Europe. It was no more than a few hundred people. They had not much in common, despite their passion for people and new ways of hunting dragons. However, they happened to be the most excellent dragon hunters of their time.

Dragons were quite a common species back then. They were so huge; they could not even lift their bottom without the help of their soldiers. These soldiers were addicted to smoking Dragon weed. It was the only way they could stand their miserable lives and enjoy a few moments of inner peace every day.

Over decades, the Dragons were growing ever more fat and stupid. They turned much of Europe into a dark, smelly place. The sun was hidden behind dark Dragon fart. Dragon dung was covering places that long before had been known for their good karma and the beauty of their colorful scenery.

There was this little tribe though. They called themselves Ale. They went hunting for dragons year after year. They made the soldiers get a glimpse of a life worth living and one after one, the soldiers turned away from Dragon weed. They found out there is more to life than lifting someone else’s ass day in day out. Most of them joined the Ale tribe, and they brought new weapons with them. As the years went by they became the strongest members of the new tribe.

The dragons ran out of strong soldiers. Clumsy amateurs were trying to lift the Dragons’ bottoms but ultimately failed doing so. The fat and lazy Dragons were starving to death. The sky above Europe cleared. The sun returned and beautiful new plants emerged out of Dragon Dung.

The Ale tribe spread across the globe and world peace was to come soon. The Ale tribe held an annual gathering, the first of which was called ALE2011. It was the most vibrant event in dragon hunting history and will be remembered long after the dragon hunters of these times have passed away.

For some reason this tribe called itself like a beer and had champagne on their emblem, but this is an entirely different story.