Otto InnoDays 2016: Der Kulturwandel

Der Otto-Konzern will sich modernisieren und fit für das digitale Zeitalter werden.Wie groß dieser Schritt ist, kann man an einen Ausspruch eines Otto-Mitarbeiters festmachen: “Otto ist eine Behörde mit angeschlossenem Versandhandel.”

Otto-DW-Wirtschaft-Hamburg

Im Bereich eCommerce sind in den letzten Jahren beachtliche Erfolge erzielt worden: Skaliertes Scrum mit mit einer auf Verticals basierenden System-Architektur stellt die technische Basis bereit, auf der Business Agility (um mal ein Buzz-Word zu benutzen) möglich wird.

2016-04-28 11.13.06

Die InnoDays 2016 waren ein weiterer Schritt in Richtung einer auf agilen Werten beruhenden Unternehmenskultur. Bei den InnoDays habe ich erlebt, wo diese Schritte bereits mutig gegangen werden, aber auch wo alte Strukturen immer wieder hervorbrechen.

Silos

In einigen Teams waren klassische Silo-Strukturen deutlich erkennbar. In einer Ecke saßen die Programmierer in einer anderen die Tester und ganz zentral der “Projektleiter”, der die Idee eingebracht hat.

Das zeigte sich auch, als ein Team einen geplanten Interviewtermin absagte, weil der Interviewer nicht da war. In einem agilen Team hätte ich erwartet, dass jemand anderes aus dem Team das Interview durchgeführt hätte.

Ich habe aber auch ganze andere Teams erlebt, in denen wirklich gemeinsam auf Augenhöhe gearbeitet wurde. Die Verwendung von Mob-Programming in einigen Teams war ein gutes Zeichen für diese Art der kooperativen Arbeit.

OTTO_InnoDays16_Brainstorming

Ränge

In einigen Teams soll es mehrere Mitglieder aus der Profession “Projektmanager” gegeben haben, die im Team um die Richtung gestritten haben.

In einem agilen Teams kann es natürlich auch Streit geben. Der Umgang ist allerdings anders als in der traditionellen Welt. In der agilen Welt wird der Konflikt möglichst weit geklärt. Wenn dann noch unterschiedliche Meinungen übrig sind, definiert das Team Experimente, um mehr über das Thema zu lernen und später eine gute Entscheidung treffen zu können.

Hier scheint die “klassische” Kultur noch durch und zeigt, dass die agilen Werte und Prinzipien noch nicht durchgängig von allen gelebt werden.

Technik vor Nutzen

Es gab für die Teams die Möglichkeit, vor der Präsentation ihre Prototypen einigen potenziellen Nutzern vorzustellen und Feedback zu erhalten. Von dieser Möglichkeit haben nur wenige Teams Gebrauch gemacht. Der Grund war wohl Zeitmangel. Man wollte lieber weiter an der Entwicklung arbeiten als zu dem entwickelten Feedback einzuholen.

Das könnte ein Indiz dafür sein, dass einige Teams sich lieber mit der Technik als mit Kunden beschäftigen. Es könnte aber auch einfach bedeuten, dass die Zeit, die für die Entwicklung zur Verfügung stand doch etwas knapp bemessen war.

Und was ist mit Endkunden?

Das, was meiner Meinung nach den nächsten großen Schritt in die richtige Richtung bringen kann, ist der direkte Kontakt mit Endkunden. Bei den InnoDays 2016 war immerhin die Fachseite eingeladen. Auch wenn diese sich sehr gut mit dem Markt auskennen, sollte man die Fachseite nicht mit den Kunden verwechseln.

Nur im direkten Kundenkontakt können wirklich neue Bedürfnisse identifiziert und Lösungen schnell gegen diese Bedürfnisse validiert werden.

Einige Projekte haben sich daran versucht, junge Menschen auf die Otto-Plattform zu kriegen (z.B. durch Sprachsteuerung und Chat-Roboter). Allerdings frage ich mich, auf welcher Basis das passiert ist. Otto macht sehr oft A/B-Tests für neue Features auf der Plattform. Das nützt aber wenig, wenn die mit dem Feature adressierte Zielgruppe noch gar nicht auf der Plattform unterwegs ist. Dann muss man den direkten Kontakten zu echten Menschen aus der Zielgruppe suchen.

Wenn bei den InnoDays 2016 Endkunden ganz oder teilweise dabei wären, dann könnte das der ganzen Veranstaltung nochmal deutlich mehr Schub verleihen und die Lösungen noch besser machen.

Fazit

Ich habe eine insgesamt umgängliche, offene, engagierte Atmosphäre bei den InnoDays 2016 gespürt. Da hat Otto definitiv große Schritte in die richtige Richtung unternommen. Natürlich sind mehr als 100 Leute keine homogene Masse. Daher verwundert es nicht weiter, dass in einigen Teams bereits stärkere Anzeichen einer agilen Kultur zu sehen waren als in anderen.

Die stärkere Integration von Endkunden hat meiner Meinung nach sehr großes Potenzial – nicht nur bei den Otto InnoDays, sondern bei den meisten Hackathons, die ich gesehen habe.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

 

May 25, 2016 at 9:26 pm Leave a comment

Otto InnoDays 2016: Ziele und Ablauf

Ziele

Das Ziel der Otto InnoDays war, innovative Ideen zu generieren. Sabrina Hauptman dazu: “Wir wollen Freiräume schaffen und zum Anders-Denken anregen; Out-of-the-box-Denken.”

Rahmenbedingungen

Es gibt eine Mission für eCommerce bei Otto:

Mit unseren OTTO Experten finden wir innovative Ideen, die dem Kunden einen relevanten Nutzen verschaffen.

Dafür entdecken wir Unbekanntes, untersuchen komplexe Probleme und lernen aus Nutzerfeedback.

Wir erschaffen gemeinsam Innovationen für die OTTO E-Commerce Plattform.

Es wurden drei Challenges definiert, die im Rahmen dieser Mission Fokuspunkte setzen sollten:

  1. Otto ist da, wo Du bist.
  2. Voller Datendrang
  3. Reduce to the max

Für jede Challenge sollte es später einen eigenen Challenge-Sieger geben. Tatsächlich haben sie viele Projekte an den Challenges orientiert. So sind Mission und Challenges ein gutes Beispiel dafür, wie Alignment hergestellt werden kann, wenn das Was und Warum klar ist. Dann richten sich selbstorganisierte Systeme automatisch daran aus.

Überblick über den Ablauf

Die Otto InnoDays 2016 verliefen insgesamt über zwei Wochen. Die achttägige Ideenphase sollte inspirieren, Ideen hervorbringen und Ideen für die Umsetzungsphase selektieren. In der dann folgenden dreitägigen Umsetzungsphase wurden die selektierten Ideen von Teams so umgesetzt, dass sie am Ende der Woche präsentiert und bewertet werden konnten. An die Umsetzungsphase schloss sich eine Entscheidungsphase und eine potenzielle zweite (vorwöchtige) Umsetzungsphase an, die allerdings etwas von dem Event InnoDays abgekoppelt waren.

Ablauf

Ideenphase

In der Ideenphase wurden nicht einfach nur Ideen gesammelt. Es wurde auch Wissen vermittelt – z.B. zu Interviewtechniken und Prototyping. Auch die Nicht-Programmierer sollten erkennen, dass sie sinnvoll an der Umsetzung teilnehmen können. So konnten sie z.B. erfahren, dass man bereits viel über eine Idee lernen kann, wenn man “nur” einen Papier-Prototypen herstellt.

Schließlich wurden die Ideen publiziert und es wurde mit den Füßen abgestimmt. Wer ausreichend viele Mitstreiter für seine Idee finden konnte, konnte diese in der Umsetzungsphase umsetzen. Ideen, für die sich keiner interessierte, wurden nicht weiter umgesetzt.

In dem Foto sieht man alle eingereichten Ideen. Auf der roten Seite (links) finden sich die selektierten Ideen, auf der blauen Seite (rechts) stehen die Ideen, für die sich keine Teams gefunden haben.

2016-04-28 10.29.59

Umsetzungsphase I

In der Umsetzungsphase arbeiteten die Teams an ihren Projekten. Den Teams standen für die Arbeit durchaus “startuppige” Räumlichkeiten bei Otto zur Verfügung:

2016-04-28 11.13.06

Soweit ich das überblicken konnten, entwickelten dafür alle Teams lauffähige Software. Viele Teams haben ihren Code sogar direkt in die produktiv laufende Plattform integriert.

Die Ideen wurden am Freitag nachmittag im Planung vorgestellt und durch die Teilnehmer und eine Jury bewertet.

2016-04-29 13.36.40

Es gab verschiedene Kategorien, die jeweils eigene Gewinner haben konnten.

Entscheidungsphase

Besonders war, dass mit der Kürung der Gewinner die Geschichte noch nicht zu Ende war. Die Gewinner gingen in einen Recall, in dem bewertet wurde, wie diese zur Otto-Strategie passten. Sollte es einen Match geben, sollte das Projekt zeitnah weitergeführt werden. Dazu war in der Roadmap ein Puffer von 4 Wochen vorgesehen.

Diese Integration in die Roadmap ist im Gegensatz zu anderen Hackathons eine Besonderheit. Das Unternehmen committet sich vorher darauf, auch mind. eine Idee auch weiter zu verfolgen. Dadurch kann effektiv dem Gefühl entgegengewirkt werden, dass die ganze Verstanstaltung am Ende nur “Opium für die Entwickler” ist, um diese bei Laune zu halten. Otto zeigt mit seinem Ansatz deutlich, dass es um mehr geht: Es sollen tatsächlich innovative Ideen generiert werden, die auch ernsthaft für eine dauerhafte Umsetzung in Betracht gezogen werden.

Umsetzungsphase II

In der Umsetzungsphase II sollte dann im Rahmen der Roadmap 4 Wochen lang an einem der Gewinnerthemen weitergearbeitet werden. Jetzt, wo ich diesen Blogpost schreibe, ist mir nicht bekannt, ob und welches Projekt diese Entwicklungszeit erhalten hat.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

May 21, 2016 at 8:59 pm Leave a comment

Otto InnoDays 2016: Warum ich zuerst skeptisch war und dann doch teilgenommen habe.

Als Otto in Person von Sabrina Hauptman mich fragte, ob ich an den InnoDays 2016 teilnehmen wollte, war ich mir unsicher, wieviel mir das wirklich bringt. Schließlich hatte ich schon ähnliche Veranstaltungen besucht: Hackathon, FedEx Day und wie sie alle heißen. Und so richtig überzeugt war ich nie.

Erstmal sieht das alles ganz einfach und plausibel aus. Das Unternehmen möchte innovativer werden (wer möchte das nicht?) und bei vielen Entwicklern gibt es den starken Wunsch, die ganzen neuen Technologien mal auszuprobieren, die “da draußen” gerade angesagt sind.

Also lässt man der Kreativität der Entwickler mal einen oder zwei Tage lang freien Lauf und guckt mal, was herauskommt. Die Veranstaltungen sind dann auch durchweg cool. Man kann die Energie spüren und die Entwickler haben sehr viel Spaß. Das alleine ist für viele Unternehmen bereits eine große Anstrengung und respektiere den Versuch sehr.

Probleme mit vielen Hackthons

Meist ist es aber eben auch nicht mehr als ein erster Versuch:

  • Es gibt keinen definierten Prozess, was mit den Ergebnissen passiert. Es gibt lediglich die diffuse Hoffnung, dass irgendjemand “da oben” schon die Genialität der Ergebnisse erkennen und dann die Projekte in die Roadmap aufnehmen wird. Passiert aber nicht.
  • Die Ergebnisse sind meist extrem technisch (wer wollte nicht schon immer mal einen Hadoop-Cluster aufsetzen oder Docker in Docker laufen lassen?) und der Mehrwert für das Unternehmen bleibt unklar. Auch daher verwundert es mich nicht wirklich, dass niemand die Ergebnisse zu echten Projekten macht.
  • Radikale erste Ideen sind so gut wie immer Mist. So werden dadurch zu guten oder sogar großartigen Ideen, dass sie über einen längeren Zeitraum durch verschiedene Köpfe gehen und mit anderen Ideen kombiniert werden (siehe [Sawyer2008]). Das leisten die Hackathons, die ich gesehen habe, kaum oder gar nicht.

So sind viele Hackathons nicht viel mehr als ein Strohfeuer, als kurz aufflammt, aber letztlich keine Wirkung hat. Es kann sogar zu Frustration führen, wenn die Teilnehmer diese Wirkungslosigkeit erkennen.

Siehe zu dem Thema auch meinen Blogpost zum Konzept der Slack-Time, in dessen Kommentaren Markus Andrezak das Konzept als “Opium für die Massen” bezeichnet hat. Das trifft auch auf so manchen Hackathon zu: Tut er mehr, als die Entwickler zu beruhigen?

Otto InnoDays

Sicherlich ist es bereits eine bemerkenswerte Leistung, wenn ein Konzern wie Otto einen Hackathon wie oben beschrieben umsetzt und damit zeigt, dass sowas nicht den neuen hippen Internet-Unternehmen vorbehalten ist.

Trotzdem blieb für mich die Frage, was ich dabei lernen könnte.

Die ersten Otto InnoDays fanden 2015 statt – damals nur mit den internen Mitarbeitern der Entwicklung. 2016 wurden die InnoDays geöffnet für externe Mitarbeiter und für die Fachabteilungen. Das hört sich schon mal ganz gut an, weil es die Chance bot, aus dem reinen Techno-Fokus herauszukommen. Außerdem waren die Otto InnoDays 2016 sehr groß angelegt – mit einem Prozess, der letztlich zwei Wochen lang lief. Und die Organisation machte auch nicht irgendjemand “mal nebenbei”. Stattdessen stellte Otto nennenswert Kapazitäten für die Vorbereitung und durch Begleitung bereit. Die schienen es wirklich ernst zu meinen.

Damit waren meine Zweifel noch nicht ausgeräumt. Aber die Neugier begann zu überwiegen und so sagte ich zu.

Ziele und Ablauf der InnoDays 2016

Details… (folgen noch)

Otto InnoDays 2016: die ganze Geschichte

Dieser Blogpost ist ein Artikel in einer Blogpost-Serie.

Überblick über die ganze Blogpost-Serie…

Referenzen

  • [Sawyer2008] Keith Sawyer: “Group Genius: The Creative Power of Collaboration”

May 3, 2016 at 2:07 pm 1 comment

Otto InnoDays 2016: Start einer Blogpost-Serie

Ich war bei den Otto InnoDays 2016 dabei. Auf Twitter konnte man die Veranstaltung unter dem Hashtag #innodays2016 verfolgen.

Dieser Blogpost ist der Auftakt einer kleinen Blogpost-Serie zu dem Thema. Ich habe mit Otto vereinbart, dass ich hier keine Lobhudelei betreibe und offen alles beschreiben darf. Ich darf insbesondere auch das benennen, was in meinen Augen besser gemacht werden kann (lediglich persönliche Beleidigungen darf ich hier nicht veröffentlichen – will ich auch gar nicht :-). Und mir ist Einiges aufgefallen, was besser gemacht werden kann. Das sollte aber nicht den Blick auf das trüben, was schon erreicht wurde. Im Vergleich mit ähnlichen Veranstaltungen in anderen Firmen waren die Otto InnoDays 2016 auf jeden Fall ganz vorne mit dabei. Und wenn ich dann bedenke, dass Otto ein Konzern mit über 4.000 Mitarbeitern und kein eBusiness-Unternehmen mit nur 200 Mitarbeitern ist, ziehe ich meinen Hut. Von den Otto InnoDays 2016 können sich viele vermeintlich agilere Unternehmen eine große Scheibe abschneiden.

Ich plane, in den nächsten Wochen die folgenden Themen in dieser Blogpost-Serie zu behandeln:

Teil 1: Warum ich zuerst skeptisch war und dann doch teilgenommen habe.

Als Otto in Person von Sabrina Hauptman mich fragte, ob ich teilnehmen wollte, war ich mir unsicher, wieviel mir das wirklich bringt. Schließlich hatte ich schon ähnliche Veranstaltungen besucht: Hackathon, FedEx Day und wie sie alle heißen. Was sollte hier jetzt so besonders interessant sein – außer dass das Format jetzt auch von Konzernen praktiziert wird?

Details…

Teil 2: Die Ziele und der Ablauf

Die InnoDays sollten zum Querdenken anregen und auch Platz für disruptive Ideen bieten. Die InnoDays erstreckten sich insgesamt über zwei Wochen. Es begann mit einer Aufwärmphase, gefolgt von der Ideengenerierung. Die Ideen wurden dann gefiltert (Abstimmung mit den Füßen) und die selektierten Ideen prototypisch umgesetzt. Die Ergebnisse wurden zum Abschluss vorgestellt und von einer Jury bewertet. Außerdem gibt es einen definierten Prozess, wie die „Sieger“ in den Roadmap-Planungsprozess eingespielt werden.

Details…

Teil 3: Der Kulturwandel

Der Otto-Konzern will sich modernisieren und fit für das digitale Zeitalter werden. Dazu sind im Bereich eCommerce in den letzten Jahren beachtliche Erfolge erzielt werden. Skaliertes Scrum mit mit einer auf Verticals basierenden System-Architektur stellt die technische Basis bereit, auf der Business Agility (um mal ein Buzz-Word zu benutzen) möglich wird.

Die InnoDays sind ein weiterer Schritt in Richtung einer auf agilen Werten beruhenden Unternehmenskultur. Bei den InnoDays habe ich erlebt, wo diese Schritte bereits mutig gegangen werden, aber auch wo alte Strukturen immer wieder hervorbrechen.

Details…

Teil 4: Die Projekte

Es wurden insgesamt 18 Projekte durchgeführt. Ich habe mir diese inhaltlich angesehen und nach verschiedenen Kriterien klassifiziert. Wieviele disruptive Ideen waren bei den Projekten wirklich dabei? Wieviele Projekte basierten auf spinnerten Ideen, die sich am Ende nicht umsetzen lassen würden? Welche Projekte sprechen neue Zielgruppen an und welche optimieren „nur“ den existierenden Service für die existierenden Kunden? Und woran liegt es, dass es so gekommen ist, wie es gekommen ist?

Details…

Teil 5: Die großen Filter

Bei den InnoDays wurden Ideen bzw. Projekte mehrfach gefiltert. Zuerst wurden die Ideen durch Abstimmung mit den Füßen gefiltert. Bei der Abschluss-Präsentation wurden die Sieger herausgefiltert. Diese gehen in einen Roadmap-Planungsprozess, in dem erneut gefiltert wird.

Dieses Vorgehen entspricht dem Stand der Kunst für solche Veranstaltungen. Allerdings ist der Ansatz aus meiner Sicht noch nicht optimal. Radikale Ideen sind in ihrer ersten Fassung fast immer Mist. Sie müssen durch verschiedene Köpfe wandern, dort verändert und mit anderen Ideen kombiniert werden. Dann können wirklich großartige Dinge entstehen. Der große Filter-Ansatz verhindert diesen Prozess und tendiert daher dazu, mittelmäßige Ideen Realität werden zu lassen. Das ist schon mal nicht so schlecht, weil immerhin die schlechten Ideen ausgesiebt werden. Es geht aber viel besser: Diverge & Merge ist leistungsfähiger als Diverge & Filter.

Details…

Teil 6: Ein paar Thesen

Aus den InnoDays können Otto und andere Unternehmen viel lernen – auch über die internen Prozesse und Strukturen. Ich habe dazu ein paar Thesen zusammengeschrieben. Vielleicht helfen diese, in der Zukumft noch bessere InnoDays zu gestalten.

Details…

Teil 7: Zusammenfassung

Think, Create, Learn: das war das Motto das Otto InnoDays 2016. Wie stellt sich die ganze Veranstaltung rückblickend vor dem Hintergrund dieses Mottos dar?

Details…

 

 

May 1, 2016 at 12:52 pm 7 comments

Disziplinarische Führung in Scrum

Immer mehr Unternehmen entscheiden sich dafür, Scrum oder andere agile Verfahren nicht nur für einzelne Projekte einzusetzen, sondern als Standard-Ansatz für die Entwicklung. Damit wird die Frage nach der Mitarbeiter-Führung in solchen Umgebungen immer drängender. Bisher ist dazu die eine heilsbringende Lösung (Silver Bullet) nicht gefunden worden. Tut mir leid. Aber es gibt auch eine gute Nachricht: Wir sind auch nicht vollkommen ahnungslos.

Führung muss sich der Arbeitsorganisation unterordnen

Werfen wir zunächst einen Blick auf das klassische Modell von Führung: Das Unternehmen ist in funktionsorientierte Abteilungen (z.B. Marketing, Vertrieb, Entwicklung, Qualitätssicherung) zergliedert. Wenn die Abteilungen ausreichend groß sind, sind sie nochmal in Gruppen oder “Teams” organisiert. Entlang dieser Zergliederung findet die disziplinarische und  fachliche Führung statt. Die Abteilungsleiter führen die Gruppenleiter, die Gruppenleiter führen ihre Mitarbeiter. Diese Form der disziplinarischen Führung passt zu dem klassischen Paradigma, Arbeit zu organisieren (Teile und Herrsche kombiniert mit funktionaler Zergliederung).

Die agile Welt folgt einem anderen Paradigma, Arbeit zu organisieren: Interdisziplinäre Teams vereinigen die Skills, die notwendig sind, um Wert aus Kundensicht zu schaffen. Es ist kaum zu erwarten, dass für diese andere Art der Arbeitsorganisation der klassische Ansatz disziplinarischer Führung funktionieren kann. Die Organisation disziplinarischer Führung muss sich der Arbeitsorganisation unterordnen. Dauerhaft kommt man bei flächendeckender agiler Entwicklung nicht um eine Reorganisation der disziplinarischen Führung herum kommen.

Funktionen von Führung können verteilt werden

Für eine Reorganisation disziplinarischer Führung müssen wir uns gedanklich von einem weiteren klassischen Dogma lösen, nämlich dass alle Funktionen disziplinarischer Führung bei einer Person liegen müssen. Dazu lohnt es sich, eine Liste mit den Funktionen zu machen, die heute im Unternehmen unter Führung verstanden werden. Dabei kommen typischerweise Dinge wie die folgenden heraus:

  • Sicherstellen, dass die Mitarbeiter das Richtige tun.
  • Sicherstellen, dass die Mitarbeiter effizient arbeiten.
  • Arbeitsmittel bereitstellen.
  • Für die Weiterentwicklung der Mitarbeiter sorgen.
  • Urlaubsanträge unterzeichnen.
  • Mitarbeiter einstellen.
  • Mitarbeiter entlassen.
  • Leistung von Mitarbeitern beurteilen.
  • Gehälter festlegen.
  • Für Mitarbeiterzufriedenheit sorgen.
  • Unter- und Überlastung von Mitarbeitern verhindern.
  • Fürsorge (z.B. Burnouts verhindern)
  • Eskalationsinstanz
  • etc.

Warum sollte so eine lange Liste von Funktionen unbedingt in einer Person gebündelt werden? Mitunter wird eingeworfen, dass es “so schön einfach” wäre. Das ist definitiv der Fall, aber es ist das falsche Kriterium. Es geht nicht darum, ob etwas einfach im Organigramm aussieht, sondern darum, ob es wirksam ist. In einer agilen Welt ist die Bündelung der o.g. Funktionen in einer Vorgesetzten-Position nicht besonders wirksam.

Führungsfunktionen in Scrum

Mit dieser Idee der Funktionsverteilung kann man jetzt flexibel entscheiden, wo welche Funktionen von Führung liegen. Ein paar Dinge klärt Scrum bereits:

  • Der Product Owner sorgt dafür, dass die Entwickler das Richtige tun (durch Priorisierung des Product Backlogs).
  • Das Entwicklungsteam entscheidet darüber, wie die Arbeit konkret organisiert wird.
  • Der Scrum Master sorgt dafür, dass das Team effizient arbeiten kann (z.B. durch Hindernisbeseitigung).
  • Das Entwicklungsteam sorgt zusammen mit dem Scrum Master dafür, dass bei der Arbeit weder Unter- noch Überlast entstehen.

Und der Rest?

Damit bleiben eine Reihe von Führungsfunktionen zunächst ungeklärt, z.B. die langfristige Weiterentwicklung von Mitarbeitern, Einstellungen, Entlassungen und Gehaltsfestlegungen. Hier findet sich häufig die Auffassung, dass die Weiterentwicklung von Mitarbeitern und die Gehaltsfestlegung an derselben Stelle liegen sollte. Das ist aber gar nicht notwendig und häufig sogar problematisch. Es ist problematisch, weil für die persönliche Weiterentwicklung des Mitarbeiters offen über seine Schwächen und Fehler gesprochen werden muss. Wenn gleichzeitig über eine Gehaltserhöhung entschieden wird, wird der Mitarbeiter nicht besonders offen bzgl. vermeintlicher Schwächen sein. Und es ist nicht notwendig, weil eine erfolgreiche Weiterentwicklung Auswirkungen auf die Wirksamkeit des Mitarbeiters haben sollte und die Wirksamkeit sollte schließlich entscheidend sein, wenn es um Gehaltserhöhungen geht.

Dinge, die ich in der Praxis gesehen habe für die Führungsfunktionen, die per Scrum nicht fest verortet sind:

  • Über den Urlaub entscheidet das Team selbst. (Und achtet dabei darauf, bestimmte Constraints einzuhalten, z.B. Verfügbarkeit von Support für die produktive Software).
  • Über Einstellungen entscheidet das Team.
  • Bei Einstellungen redet das Team auf Augenhöhe mit.
  • Teams entscheiden darüber, ob Teammitglieder das Team verlassen müssen. Diese setzen sich dann auf die Ersatzbank und sind für andere Teams verfügbar.
  • Die langfristige Weiterentwicklung der Teammitglieder liegt beim Scrum Master.
  • Die langfristige Weiterentwicklung der Teammitglieder liegt im Team.
  • Die langfristige Weiterentwicklung der Teammitglieder liegt in selbstselektierten Peer-Groups.
  • Der Scrum Master verantwortet die Mitarbeiterzufriedenheit.
  • Ein Feelgood-Manager verantwortet die Mitarbeiterzufriedenheit.
  • Das Team verantwortet die Mitarbeiterzufriedenheit.
  • etc.

Es gibt also nicht die eine richtige Art und Weise, Führung zu organisieren. Man wird mit verschiedenen Ansätzen experimentieren müssen, um die Form zu finden, die für das eigene Unternehmen passt. Und man wird sich darauf einstellen müssen, dass auch Mitarbeiterführung einem kontinuierlichen Verbesserungsprozess unterliegt.

Mit diesem Ansatz, Führungsfunktionen zu verteilen, wird übrigens jedes klassische hierarchische Organigramm vollkommen nutzlos.

July 19, 2015 at 9:18 pm 15 comments

Salaries at it-agile

There are some discussions about open salaries coming up. Sometimes it-agile is mentioned but I think we never published what we are doing. So, here we come (we are about 30 people at it-agile).

Fixed salaries

We have fixed salary levels (roughly 9% difference from level to level).

Transparent salaries

These salary levels are transparent within it-agile and everybody at it-agile knows who is at which salary level.

No positions

We have no fixed positions at it-agile, just roles. Therefore the salary is not bound to a position. In principle everybody could “climb” to the highest salary level.

Setting the salary level

We experiment a lot with the process to find the appropriate salary level for the it-agile people. What we have done (and dismissed) in the past:

  • The CEO sets the salary of each colleague (except himself).
  • A group of senior people set the salary of each colleague.
  • The peergroup (a self selected group responsible for the personal development of a colleague) sets the salary of the colleague.
  • The salary set is set by some kind of crowd voting.

The current state is: A group called “salary checkers” (Gehaltschecker) that is elected by the it-agile colleagues sets the salaries of the colleagues and owns the process of finding the salary. Whenever a colleague want’s to get to the next salary level he is obligated to consult colleagues about his request. He has to select also critics for the consultation. When the colleague thinks the request is justified (based on the feedback he got during the consultation) he approaches the salary checkers with his request. The salary checkers check if the consultation was done properly and the feedback justifies the next salary level. If this is the case he is “promoted”.

We don’t have fixed criteria to determine the salary level. It’s more about: Where do I stand related to the colleagues below my salary level, to the colleagues at my current salary level und to the colleagues at the next higher salary level.

And the salary checkers still improve the process.

May 19, 2015 at 8:53 am Leave a comment

Three horizons innovation management and Product Ownership

3 horizons

The book “The Alchemy of Growth” (Merhdad Baghai, Stephen Coley, David White) describes the 3 Horizons model that differentiates three levels of innovation and growth.

  1. Horizon 1 is about the core business where the company make its main money. In horizon 1 you won’t do very risky things but innovation is still necessary to optimize the product/service and get ahead of the competition (or to stay ahead of the competition).
  2. Horizon 2 is about the upcoming future business. In horizon 2 companies develop the business models and products/services that should make essential money in 2 to 4 years.
  3. Horizon 3 is about the vague ideas with an unclear future. These are the startup-like ideas and statistically 9 out of 10 ideas won’t make it into relevant products/services.

Every horizon has to be managed differently and needs different optimization criteria (like KPIs), types of people, processes and structures.

Horizon 1

The purpose of the products/services on horizon 1 is not only to pay the salaries and make money for the shareholders but also to finance horizon 2 and 3. The products/services of horizon 1 need a compromise of stability and innovation for optimization. The goal of the optimization is to ensure (or even improve) the market position. The successful products/services need to be improved (and often cost reduction is an important part of this improvement).

The products/services and the market in horizon 1 are well understood and relatively stable. Therefore it is possible to calculate business cases for innovations. Every innovation should have a short payback period and the payback forecast will often match the reality.

Horizon 2

The purpose of horizon 2 is to develop the products/services that will move to horizon 1 in a few years. The innovations of horizon 2 often need new organizational structures and processes. The business model is not yet validated and relevant users needs are still unknown. Therefore detailed long term planning doesn’t make much sense. A rough sketch of the key features and best guess for budget and time (e.g. one team with 8 developers for 6 months) are as accurate as it can get. The details are figured out during the development with short feedback cycles and intense market/customer contact.

For the products/services in horizon 2 there is a high confidence that they will be successful in the market. Therefore minimizing time-to-market is essential. The team should work full time on the product/service and must not be restrained be bureaucratic stage gate processes.

When horizon 1 and 2 are mixed, conflicts will arise and most times horizon 1 wins (since it makes the money). But also in an environment where horizon 2 is isolated from horizon 1 conflicts will occur, when horizon 2 products/services are developed and move to horizon 1. Therefore horizon 1 innovations need a powerful driver (e.g. CEO).

Example: Steve Jobs drove the first iPhone and then the iPad development.

Horizon 3

The purpose of horizon 3 is to obtain and secure options and validate business ideas. In horizon 3 most of the bad ideas should be eliminated and most of the options won’t be exercised.

MVPs, (Minimum Viable Products), prototypes and mockups are king. Often there is no real product development necessary in horizon 3. Within horizon 3 we need to accept that most of our attempts will fail. We need to embrace failure and need to minimize learning cycles.

Product Ownership

Every horizon needs another type of product ownership. According to the three types of product owners Eric may serve horizon 3 best, Jeff may be necessary to drive a horizon 2 innovation and Marty may be best suited for horizon 1 innovations.

December 20, 2014 at 4:53 pm 1 comment

Older Posts Newer Posts