-->

Donnerstag, 2. Juni 2011

Businesskaspern mit agilen Methoden helfen. Heute: Rendite steigern mit ohne Multitasking

Manche Entwickler werden das Gefühl nicht los, nur noch von Verrückten umgeben zu sein. Außer den Kunden wollen auch Geschäftsführer, Controller und alle sonstigen Businesskasper immer mitreden. Ständig ändern sie ihre Wünsche,von vernünftiger Projektorganisation haben sie keine Ahnung, aber alle Anfragen sollen sofort erledigt werden und nichts kann ordentlich zu Ende gebracht werden, bevor man das Nächste anfängt. (Disclaimer: Der Autor ist als MBA selbst graduierter Businesskasper  und bittet deshalb, von Beschwerden wg. ungebührlicher Wortwahl abzusehen)

Andersrum sieht die Sache ganz ähnlich aus. Der Businesskasper (vor allem der, der nie selbst entwickelt hat) hat mit der IT oft auch ein Riesenproblem. Er weiß nie genau, was die Entwickler vor ihren Kisten eigentlich tun und wenn man fragt, können sie es auch nicht erklären. Jedenfalls nicht so, dass es ein normaler Mensch verstünde. Aber dass sie der Firma mit ihren horrenden Gehältern fast die Haare vom Kopf fressen, ohne sich Gedanken darüber zu machen, wie das Geld wieder hinein kommt, dass ist für ihn offensichtlich. Das einzige was ihn und die Firma vor dem Ruin bewahrt, ist, dass er immer neue Aufträge anschleppt und so viel Druck macht, dass die Entwickler immer zumindest irgendetwas fertig stellen.

Zugegeben, diese Beschreibung ist etwas plakativ, aber nur etwas. Wahrscheinlich kennt jeder von uns mindestens ein Unternehmen, in dem es so läuft. Im Grund wünschen sich alle ein Ende des Projektchaos, die Geschäftsleitung und der Vertrieb verweisen aber zurecht darauf, dass man keinen Kunden warten lassen könne - und sich der Markt nun mal nicht nach den Vorstellungen der Entwickler orientiert. Die Entwickler sehen das natürlich auch ein, aber das Gefühl, dass da etwas grundsätzlich falsch läuft, bleibt doch irgendwie bestehen und irgendwie müssen sie die Sache immer ausbaden.

Oft ertönt bei den Entwicklern dann der Ruf nach einer agilen Vorgehensweisen. Man verspricht sich davon ein strukturierteres, gleichwohl flexibles Arbeiten. Die Überlegung ist auch richtig. Scrum und Kanban kommen ohne Bürokratie aus, eignen sich hervorragend für Entwicklerteams mit fünf bis fünfundzwanzig Mitarbeitern und sind recht einfach zu implementieren.

Aber ein Problem, das aber immer wieder aufkommt, lautet:
Wie können wir nur die Geschäftsführung davon überzeugen, dass es anders besser ginge?

Nun, wer mit Businesskaspern sprechen möchte, sollte nicht über seinen Stress mit den Projekten klagen. Das nützt gar nichts. Viel mehr hilft es, die Bedürfnisse und die Denkweise der anderen zu verstehen. Und dann, dann ergeben sich einige positive Schlussfolgerungen vielleicht von ganz alleine.

Möge mein heutiger Artikel Euch dabei behilflich sein :))


Des Businesskaspers liebstes Spielzeug: Kapital

Es gibt zwei Dinge, die dem Businesskasper ganz wichtig sind: Sein Eigenkapital und die Rendite. Alles, was er tut, hat immer zum Ziel, die Rendite des Unternehmens zu erhöhen. Ob er Geld für Werbung ausgibt,  Mitarbeiter einstellt oder entlässt, an den Produktpreisen schraubt oder eine Klimaanlage installiert: Am Ende soll immer eine höhere Rendite stehen. Was ja auch nicht falsch ist. Nur ein gut verdienendes Unternehmen ist gesund.

Lernpunkt 1: Im Business geht es immer um die Rendite



Die Höhe der Rendite wird üblicherweise in Prozent ausgedrückt. In Prozent zu was? Richtig, zum Kapital. Es macht einen Riesenunterschied, ob man mit 100 Euro Kapitaleinsatz 10 Euro verdient (10% Rendite) oder ob man mit 50 Euro Einsatz 10 Euro verdient (20% Rendite).

Der gewiefte Informatiker erkennt auf einen Blick, dass man hier an zwei Enden schrauben kann. Entweder die Einnahmen erhöhen, oder, wenn das nicht geht, den Kapitaleinsatz reduzieren.




Bei "Kapitaleinsatz reduzieren" denkt der gemeine Entwickler (zumindest der, der im Fernsehen zu viel Interviews mit dem Deutsche Bank-Chef Josef Ackermann gesehen hat), gleich an Entlassungen und verspürt ein deutliches Unbehagen. Obwohl er irgendwie ahnt, dass sein Unbehagen eigentlich unbegründet ist, weil auch dem abgebrühtesten Businesskasper klar sein dürfte, dass man Entwicklerteams nicht durch Entlassungen produktiver macht. Aber dazu später mehr ...

Lernpunkt 2: Will man die Rendite steigern, muss man den Ertrag erhöhen oder den Kapitaleinsatz reduzieren





Soweit dürfte alles klar sein. Nur eine klitzekleine, alles entscheidende Kleinigkeit müssen wir jetzt noch hinzu fügen: Den Faktor Zeit. Es macht natürlich einen großen Unterschied, ob unser fiktives Beispielprojekt zwölf Monate benötigt, oder ob es schon nach sechs Monaten abgeschlossen ist.


Wenn wir mit hundertausend Euro Einsatz ein Projekt über ein Jahr laufen lassen, und dabei zehntausend Euro verdienen, dann haben wir eine Rendite von 10% per Anno. Wenn wir mit den gleichen hundertausend Euro aber die gleichen zehntausend Euro binnen sechs Monaten verdienen, dann bekommen wir pro Jahr nicht eins, sondern zwei Projekte gebacken, verdienen zwei mal zehntausend Euro und haben wir eine Rendite von 20% p.a..

Lernpunkt 3: Rendite hat immer zwei Informationen: Die Höhe UND den Zeitraum


So, und jetzt wird es endlich spannend. Unser Geschäftsführer/Abteilungsleiter/Wer-auch-immer muss also gar nicht den Kapitaleinsatz reduzieren, wenn er die Rendite erhöhen will. Was er in der Praxis ja auch nicht tut. Sein Kapitaleinsatz ist vielmehr eigentlich immer gleich. Er hat irgendwann mal Geld ins Unternehmen gesteckt und damit irgendein Projekt vorfinanziert. Sagen wir mal, die besagten 100.000 Euro. Diese 100.000 Euro nimmt er jetzt ja nicht gleich nach dem ersten Projekt wieder raus. Sonder die läßt er drin. Und verwendet sie für das nächste Projekt. Und das übernächste, und das überübernächste... Er läßt das Kapital also dauerhaft arbeiten. Und deswegen nennt man diese 100.000 Euro auf Englisch auch "Working Capital".

Wie wir sehen, hat unser Held, der sich täglich und redlich um ein gesundes Unternehmen bemüht, nicht nur zwei, sondern drei Schrauben, an denen er drehen kann:
  • Die Einnahmen - aber so viel Luft wird da kaum sein, sonst hätte er das schon gemacht
  • Die Ausgaben - eher schwierig, wie wir wissen. Will man an den Festplatten sparen?
  • Die Zeit - Wenn man nur irgendwie mehr Projekte und damit mehr Einnahmen pro Jahr machen könnte. Irgendwie den Laden ins laufen bekommen, produktiver werden. Bloß wie?

Zwischenstand: Wenn wir unserem Businesskasper einen magischen Weg zeigen könnten, seine Rendite zu erhöhen, wird er uns alle unsere Wünsche erfüllen




Zaubern für Businesskasper: Rendite steigern mit ohne Multitasking


Gerade Dienstleister sind immer in dem Dilemma, dass man einerseits möglichst viele Aufträge hinein nimmt, andererseits aber weiß eigentlich jeder im Team, dass jeder weitere Auftrag die Zahl der parallel angefangenen Arbeiten und damit das interne Projektchaos noch weiter vergrößert.

Auch unserem Businesskasper ist dies "eigentlich" klar. Aber die Argumentationmuster sind immer gleich und haben zwei Glaubenssätze:

  • Die Kunden warten nicht
  • Wir können doch nicht auf Aufträge verzichten

Oder anders rum: Nur wenn wir dem entscheidenden Menschen vorrechnen können, das Multitasking kein notwendiges Übel, sondern die Quelle vieler Probleme ist und dass wir ohne Multitasking nicht nur besser arbeiten, sondern sogar den Unternehmensgewinn steigern - dann haben wir ihn auf unserer Seite.

Und tatsächlich ist das eigentlich sogar ganz leicht. Zuerst einmal eine kleine Grafik, die jedem Entwickler - und eigentlich auch jedem sonst - sofort einleuchtet. Wer im Multitasking arbeitet, braucht länger, weil er ständig zwischen den Aufgaben wechseln muss. Und dieses Wechseln kostet Energie, Zeit, Geld.

So sieht eine typische Projektbearbeitung aus, wenn drei Projekte, A, B und C "parallel" bearbeitet werden, die rosa Balken dazwischen ist der Aufwand für das Umschalten von einem Projekt zum anderen. Das mentale Umschalten, das Wiedereinlesen in die Requirements, die Neuabstimmung mit Kunden und Kollegen, das Hoch- und Runterfahren irgendwelcher Systeme etc. etc...:



Würden wir die drei Projekte nacheinander abarbeiten, dann würden wir einiges an unnötigem Aufwand sparen. Im Vergleich sähe das so aus:



So weit ist das für die meisten Entwickler klar. Aber jetzt versetzen wir uns mal in die Rolle des Big Boss und rechnen uns einmal die Rendite aus. Nehmen wir mal einfach an, unsere Projekte haben jeweils einen Zeitaufwand von einem Quartal.

Dann sieht es bei unserem Multitasking so aus, dass wir mindestens drei Quartale vorfinanzieren müssen. Ja, ich weiß, es gibt Anzahlungen und Meilensteine etc.. aber das ändert nichts am grundsätzlichen Problem.

Jetzt achtet mal auf die untere Zeile. Bei der seriellen Arbeitsweise müssen wir statt drei oder vier nur ein Quartal vorfinanzieren!



Lernpunkt 4: Wir können den Kapitalbedarf unserer Firma drastisch reduzieren, in dem wir die gleiche Arbeit nur anders organisieren



Die ganz aufmerksamen Leser werden noch einen anderen Effekt bemerkt haben: Bei der seriellen Arbeitsweise werden ALLE Projekte deutlich früher abgeschlossen - mit den entsprechend positiven Auswirkungen auf die Kundenzufriedenheit.

Und jetzt lasst uns ausrechnen, was dies für unser Unternehmen bedeutet. Wir haben gesehen, dass wir  bei der Multitasking-Arbeitsweise fast das ganze Jahr vorfinanzieren müssen. Wenn wir bei unserem Beispielprojekt von vorhin bleiben (hundertausend Euro Vorfinanzierung pro Projekt und zehntausend Euro Gewinn), dann müssen wir rund 300.000 Euro Kapital vorstrecken, um 30.000 Euro Gewinn zu erwirtschaften bzw. eine Jahresrendite von ca. 10% zu erzielen.

Bei der seriellen Vorgehensweise rechnen wir das erste Projekt aber bereits am Ende des ersten Quartals ab. D.h., das wir gerade mal 1 Projekt oder 100.000 Euro vorfinanzieren müssen. Absolut gesehen bleibt der Gewinn aus allen drei Projekten zusammen mit 30 T€ der gleiche, aber unsere Rendite explodiert, weil wir das Kapital viel besser nutzen: 30%.

Und da wir insgesamt früher fertig sind, können wir jetzt noch ein viertes Projekt dazu packen. Dann sieht unser Projektplan für das laufende Jahr so aus:

Vier Projekte statt drei

Und wenn der Gewinn pro Projekt weiterhin 10 TEuro beträgt, dann haben wir jetzt 40 TEuro erwirtschaftet und die Rendite vervierfacht!


Lernpunkt 5: Projekte seriell abarbeiten lässt die Rendite explodieren


OK, rein rechnerisch ist die Rendite jetzt gestiegen, aber hat dies auch praktische Auswirkungen? Oder ist das nur so eine virtuelle Zahl, an der sich nur Businesskasper berauschen?

Nun, die Wahrheit ist, dass wenn man diese Zahl steigern kann, man sehr sehr handfeste Ergebnisse bekommt. Die Rendite ist ja nicht nur rechnerisch gestiegen, sondern ein ganz wesentlicher Faktor dabei war, dass unser Unternehmen ganz real viel früher Geld verdient hat. Dass die "Kapitalbindung geringer ausfällt", bedeutet nichts anderes, als das unsere Firma mit dem vorhanden Geld viel mehr anstellen kann. Sie könnte beispielsweise bei gleicher Auftragslage drei mal soviele Entwickler beschäftigen wie bisher.

Könnt Ihr Euch vorstellen, welche Auswirkungen das  auf die Wettbewerbsfähigkeit der Firma hat? Ihr könntet drei mal soviele Serviceanfragen beantworten oder dreimal mehr Features implementieren oder oder oder ... 

Lernpunkt 6: Projekte mit ohne Multitasking bearbeiten führt dazu, dass die gesamte Firma wesentlich besser aufgestellt ist als vorher.


Noch Fragen ? Dann ruft mich an. Ansonsten gilt der


LernSchlusspunkt: Viel Erfolg beim nächsten Termin mit der Geschäftsleitung!






Dienstag, 26. April 2011

Wie Kanban hilft, sich von agilen Irrtümern zu lösen

Neulich habe ich wieder eines meiner "Agil Extrem"-Seminare gehalten. Wie bei allen vorhergehenden Seminaren waren wieder überwiegend Führungskräfte von Unternehmen dabei, die bereits seit geraumer Zeit versuchen, agile Methoden in ihrer Organisation einzuführen, mit den Ergebnissen aber nicht wirklich zufrieden waren. Und nein, es liegt nicht an diesen Führungskräften, dass die bisherigen Versuche gescheitert sind. Diese Menschen sind fachlich und sozial sehr kompetent, haben sich umfangreiches Wissen über agile Methoden angeeignet, Seminare besucht, Coaches engagiert – und trotzdem kommen ihre Teams nicht so ins Laufen, wie sie sich das vorstellen.

Wie kann das sein, wenn agile Vorgehensweisen im Großen und Ganzen und insbesondere Scrum doch recht einfach daher kommen? Man hängt ein Board auf, steckt alle Entwickler in einen Raum, macht brav seine Schätzungen und Daily Standups ….



Scrum ist für viele Entwicklerteams einfach nicht geeignet

Wenn ein Team mit Scrum Probleme hat, dann kommt in Foren oder bei Scrum-Stammtischen gerne eine Antwort im Stil von: "Na, ist doch klar, der Scrum-Master darf nie auch gleichzeitig der Product-Owner sein." Oder: "Ihr müsst euren Kunden eben beibringen, dass es produktiver ist, ein Team während dem Sprint ungestört arbeiten zu lassen".

Diese Antworten haben leider nur einen Schönheitsfehler: Die Welt, die ist nicht so, wie es im Scrum-Manual steht. Und dies führt dazu, dass die Umsetzung von Scrum im realen Leben überall dort auf Schwierigkeiten stößt, wo auch nur eines(!) der folgenden Kriterien erfüllt ist:

  • Wenn das Team sehr divers ist, z.B. der alte C-Spezialist neben dem Web-Praktikanten sitzt, dann werden gemeinsame Sprintplanungen schnell mühselig und frustrierend,
  • wenn nicht nur ein neues Produkt entwickelt, sondern parallel auch mehrere laufende Produkte gepflegt werden müssen: Kritische Bugs oder SLAs richten sich nicht nach Sprintbacklogs, diese werden deshalb laufend unterlaufen und es ist beim besten Willen keine Velocity mehr messbar,
  • wenn der Scrum-Master oder gar der Product-Owner im Team selbst produktiv mitarbeiten müssen und ständig zwischen ihren Rollen und Aufgaben als "Leitender" und "Teammitglied" oszillieren müssen,
  • Wenn die Befugnisse des Scrum-Masters nach innen und nach außen unklar sind. Statt dass die Dinge flüssiger laufen, entsteht ständig neue Reibung,
  • wenn über Einstellungen und Entlassungen entschieden werden muss – in vielen Scrum-Handbüchern ist der Scrum-Master einfach nur nett, Personalentscheidungen sind nicht vorgesehen. 


Kanban eröffnet völlig neue Perspektiven für agiles Arbeiten

Da Waterfall-Planung aus einleuchtenden Gründen nicht funktioniert, Scrum aber oft nicht zu den real existierenden Umständen passt, ist das gelebte Resultat häufig in vielen Organisationen eine Art von Durchwurschteln. Um diese Situation zu verbessern, starten viele Teams in letzter Zeit einen neuen Anlauf mit Kanban. Tatsächlich lassen sich damit, zumindest theoretisch, viele der mit der Scrum verbundenen Probleme lösen:

  • Kanban ist unabhängig von der formalen Struktur einer Organisation, es braucht z.B. keinen Scrum-Master,
  • es kann auch in heterogenen Teams verwendet werden,
  • es kann schrittweise und verträglich ("non-disruptive") eingeführt werden und
  • ohne dass es zu dabei einem signifikanten Performance-Verlust kommt.

Aber auch die Experimente mit Kanban liefert scheinbar recht häufig nicht den erhofften Qualitäts- und Produktivitätsschub.

Woran liegt es dann diesmal?

Kanban ist noch weniger greifbar

Der Grund ist, dass es in Kanban gibt ein paar Anweisungen gibt wie „modelliere deinen Prozess“, „setze Limits“, „messe den Work in Progress“ und ähnliches.  Aber diese sind recht vage gehalten und im Endeffekt kommt Kanban konzeptionell damit sogar noch schwerer greifbar daher als Scrum. So gibt es z.B. keine vordefinierten Rollen, keine standardisierten Meeting-Formate, keine Standard-Boards, kurz: keine Patentrezepte. 

Tauchen Schwierigkeiten oder Hindernisse auf, soll "das Team diese lösen". Wie dies aber konkret geschehen soll und aufgrund welcher Logik von Ursache-und-Wirkung Kanban insgesamt funktioniert, das bleibt in vielen Beiträgen und Veröffentlichungen im Dunkeln. 

Selbstorganisation ist kein sozialdarwinistisches Experiment

Im Zusammenhang mit Agil (Scrum, XP) oder Lean (Kanban) fällt an diesem Punkt dann oft das Schlagwort von den selbstorganisierenden Teams. Die weist zwar in die richtige Richtung, aber manche Evangelisten scheinen dies mit einem sozialdarwinistischen Experiment zu verwechseln. Da wird dann recht schlicht dazu aufgerufen, dem Team „zu Vertrauen“ und die „Mitarbeiter einfach mal machen lassen“. 

Auf dem Gipfel der Selbstorganisation schöbe der Scrum-Master höchstens noch ab und an noch einen Zettel unter der Tür durch, um abzufragen, ob mehr Pizza, Cola oder sonst etwas benötigt würde. Und nach sechs Monaten, wenn man die Tür wieder aufschlösse, fände man ein Welt-Klasse-Team vor, das ganz alleine ein paar Jahrtausende an Diskussionen über die richtige Organisation und Führung übersprungen hat und ganz bestimmt von selbst auf die <joke> Beste aller Lösungen </joke> gekommen ist.

Der tiefere Grund für agile Krisen: Vor den Methoden kommt eine anspruchsvolle Führung

Tatsächlich, so behaupte ich, kommen viele Teams mit Scrum (oder Kanban) deshalb nicht zurecht, ist, weil es nicht einfach um eine andere Form der Projektorganisation geht. Wer sich zu Beginn mit Arbeitstechniken wie Daily Standups oder Cumulative Flow Diagrams beschäftigt, verschwendet seine Zeit. Solche Dinge bringt man intelligenten Menschen - und die meisten Entwickler sind sehr intelligente Menschen - in zehn Minuten bei. 

Worum es bei agilen Methoden und bei Kanban wirklich geht, ist ein fundamental anderes Konzept von Führungsaufgaben. Es geht weder darum, die Arbeit der anderen wie im traditionellen Modell vorzuplanen und Top-Down zur organisieren, noch darum, sich aus der Führung zu verabschieden. Viel mehr kommt es darauf an, als Leiter eines Team dieses und seine Mitglieder zur Selbstorganisation zu befähigen. Und das Schlüsselwort hier heißt „befähigen“. Es geht um einen bewusst und aktiv gesteuerten Entwicklungsprozess. Eine Führungskraft, die erfolgreich agile Teams leiten möchte, muss verstehen:

  • Was Menschen und Gruppen motiviert,
  • welche Bedeutung Informationsfluss und Feedbackschleifen haben,
  • Warum die „Ergonomie“ der Organisation entscheidend ist und welches die möglichen Stellschrauben sind,
  • welche Rolle Werte und Kultur spielen (und was Teamkultur überhaupt ist),
  • wie man Lernprozesse initiiert, steuert und aufrecht erhält

  • und wie man diese und weitere Faktoren zu einem funktionierenden Ganzen zusammen fügt und aktiv am Laufen hält.


Kanban als Weckruf
Die für viele mechanistisch denkenden, agilen Evangelisten schlechte Nachricht ist also, dass, zumindest meiner Beobachtung nach, Scrum und andere agile Mythen derzeit zunehmend entzaubert werden. Vieles, was die letzten Jahre in Blogs und Foren und auf Events an Rezepten gepredigt wurde, wird von einem zunehmend kritischen Publikum als waschechter Fall von  Cargo-Kult-Management entlarvt.

In diesem Prozess geschieht meines Erachtens derzeit aber noch anderes, hochinteressantes. Über die  Bereitstellung eines sehr wirksamen Management-Konzepts wird Kanban ganz nebenbei offen legen, wie anspruchsvoll agiles Projektmanagement tatsächlich ist.

Die Diskussion um Kanban wird dazu beitragen, dass einige Irrtümern bezüglich agiler Patentrezepte offensichtlich werden und dass es Zeit wird, sich von diesen zu verabschieden. 

It's time to get real!


P.S. Einen ersten Überblick über Kanban als Führungskonzept gibt es in dem neuen Kompaktseminar, dass ich ab sofort anbiete. Zum ersten Mal am 10. Mai, 13:30 bis 18:00 Uhr im Business Alliance Center in der Bundesallee 171. Mehr Infos gibt es hier.