StartseiteHome » Blog » Software-Entwicklung: Erfolgreich mit agilem Projektmanagement

Software-Entwicklung: Erfolgreich mit agilem Projektmanagement

Projektmanagement-Interview mit Bob Schatz, CEO Agile Infusion

Bob Schatz ist schon seit rund 30 Jahren im Feld der Software-Entwicklung aktiv. Er blickt auf zahlreiche Jobs in Führungspositionen in Großunternehmen wie GE/Lockheed-Martin und Liquent zurück. Aktuell ist er Chef des Schulungs- und Beratungsunternehmens Agile Fusion. Bob Schatz ist Referent beim Project Zone Congress Ende April in Frankfurt, den Can Do als Sponsor unterstütz. Das folgende Interview, von dem Can Do einen Auszug präsentiert, führte der Veranstalter des Events.

Projektmanagement-Interview

Can Do führt regelmäßig Expertn-Interviews

Project Zone Congress (PZC): Sie haben die Einführung von agilen Methoden wie Scrum für die Entwicklung von Projektmanagement-Systemen gemeistert. Warum und wie sind Sie auf die Idee gekommen, agile Methoden in diesem Bereich einzusetzen? Gab es bestimmte Probleme, die diesen Schritt notwendig machten? Und welche Überraschungen haben Sie bei der Einführung erlebt?
Bob Schatz: Ich glaube, serh viele Menschen, die heute agile Methoden nutzen, haben ähnliche Erfahrungen wie ich gemacht – insofern taugt meine Geschichte bestimmt als lehrreiche Anschauung. Ich habe im Jahr 2001 bei einem Software-Hersteller als Vice President Development angeheuert. Sehr schnell habe ich bemerkt, dass eins der Hauptprobleme des Unternehmens das Projektmanagement war, darauf hatte mich der CEO des Unternehmens im Vorfeld bereits vorbereitet. Das war insofern recht lustig und merkwürdig, weil dieses Unternehmen eine Projektmanagement-Software herstellte, die ursprünglich im Anlagen- und Maschinenbau eingesetzt wurde, neuerdings vermehrt auch in IT-Abteilungen. Bei diesem Projekt, die Software auf die Erfordernisse von IT-Abteilungen anzupassen, schien das Unternehmen zu scheitern.
Ein weiteres Kuriosum bei meinem Eintritt in das Unternehmen war, dass ich Projektmanagement-Software nicht sonderlich mochte. Also stellte sich meine Aufgabe bei meinem Arbeitsantritt wie folgt dar: Ein Unternehmen, das zwar eine Projektmanagement-Software entwickelt, aber im Bereich Projektmanagement deutliche Schwächen zeigte, sollte sich von mir helfen lassen, der ich keine Projektmanagement-Software mag, aber erfahren bin im Umsetzen von Projekten. Das waren doch beste Voraussetzungen für meinen Job, nicht wahr!

Can Do, Project Zone Congress, Veranstaltung

Can Do ist Sponsor des Project Zone Congress

PZC: Ihr Chef, der Sie angestellt hatte, hat dies bestimmt ähnlich gesehen?
Bob Schatz: Ja, das hat er. In meinem ersten Jahr hatte ich die Leitung von über 130 Mitarbeitern inne. Im Laufe des ersten Jahrs habe ich versucht, bewährte und erfolgreiche Vorgehensweisen, mit denen ich vertraut war, zu implementieren. Trotzdem hatten wir weiterhin noch zahlreiche Probleme. Nach etwa einem Jahr musste ich etwas Grundlegendes ändern, denn meine Mitarbeiter, die regelmäßig zahlreiche Überstunden machten, wurden allmählich kapuut: Sie wurden körperlich krank und bekamen auch im Privaten immer mehr Probleme. Und obwohl wir richtig hart arbeiteten – mit Überstunden und viel Schweiß -, die Ergebnisse, also unser Output, waren schrecklich: Wir haben ein Produkt entwickelt mit Funktionen, die unsere Anwender nicht mochten, und mit zahlreichen Fehlern – und dafür zahlten unsere Kunden nicht wenig Geld. Deshalb habe ich entschieden: „Schluss mit Überstunden für etwas, das niemand mag und das nicht funktioniert. Das ist die investierte Arbeitszeit nicht wert, deshalb Schluss damit!“ Und ich beschloss, dass wir einen neuen Prozess aufsetzen müssen, denn der alte funktioniert nicht – wie wir über Monate hinweg anschaulich bewiesen haben.
Ich ging in mich und erinnerte mich daran, dass ich in meiner Zeit, als ich bei einem Startup-Unternehmen gearbeitet hatte, sehr gute Erfahrungen mit agilen Methoden gemacht hatte. Ich las daraufhin Fachliteratur über Scrum und kam zur Überzeugung, dass dies genau das Richtige für uns ist: Es ging darum, sich bei der Entwicklung auf etwas intensiv zu konzentrieren, sich auf eine Sache zu fokussieren und das dann schnell und konsequent umzusetzen. Ich wollte das unbedingt ausprobieren! Gesagt, getan – doch so einfach ließ sich das Ganze dann doch nicht umsetzen. Die Situation verbesserte sich zunächst nicht, sondern es wurde schlimmer. Denn wir sahen, was wir in Wirklichkeit bisher getan hatten: Hier waren Produktprobleme, hier stimmte der Prozess nicht, dort gab es personelle Schwierigkeiten, einfach die falschen Leute in der falschen Position. Der Anfang gestaltete sich also ziemlich frustrierend und holprig. Trotzdem rauften wir uns zusammen und waren gewillt, den eingeschlagenen Scrum-Weg weiterzugehen. Und mit der Zeit wurde es besser und besser und nach 6-8 Monaten hatten wir schon einige Probleme erfolgreich gelöst. Das Resultat war, dass wir unsere Kunden mit ins Boot genommen und in den Entwicklungsprozess eingebunden hatten. Und die Kunden waren darüber sehr zufrieden, sie merkten, dass die Produktqualität besser wurde. Plötzlich konnten wir wieder etwas abliefern, das „richtig fertig“ war – eine nahezu neue Erfahrung für uns.
Das Resultat: Wir hatten Teams, die nun gut zusammenarbeiteten, wir hatten unsere Scrum Master ausgebildet und zu richtigen Führungskräften weitergebildet. Das hat unsere gesamte Organisation besser gemacht: Die Leute mussten keine Überstunden mehr machen, trotzdem wurden mehr Funktionen für die Software entwickelt. Auch für meine Mitarbeiter verbesserte sich die Situation grundlegend: Sie bekamen ihr Privatleben zurück und fanden wieder Spaß und Freude an ihrer Arbeit. Und unsere Kunden profitierten davon, dass sie eingebunden wurden, denn sie bekamen endlich das Tool, das sie wirklich wollten.

Scrum, agiles Projektmanagement, agile MethodePZC: Sie sagten, es habe rund 8 Monate gedauert, bis erste Ergebnisse vorlagen.
Bob Schatz: Erste Fortschritte haben wir schon früher bemerkt, aber handfeste Ergebnisse hatten wir nach 6-8 Monaten. Dann fühlten wir uns auch wohl mit Scrum und wussten, dass wir die Methode beibehalten wollten. Die ersten Sprints verliefen natürlich nicht sonderlich erfolgreich, aber sie belegten, dass wir in der Lage waren, Funktionen in kurzer Zeit zu entwickeln. Wenn ich vor der Einführung unseren Leuten gesagt hätte, „wir schaffen es, neue Features innerhalb von 4 Wochen umzusetzen“, wären sie geschockt gewesen. Aber wir machten die grundsätzliche Erfahrung, dass dies möglich ist und bewiesen das dann auch in einer Reihe von Sprints.

Projektmanager Burnout

Stress und Überstunden – ohne Erfolg

PZC: Lassen Sie uns nun über die Unterstützung durch die Unternehmensführung sprechen: Sie kamen mit einer neuen Methode zu ihrem neuen Unternehmen, das eine Menge Probleme hatte und sich dessen auch bewusst war. Das scheint mir eine komfortable Ausgangssituation für die Einführung gewesen zu sein. Wie hat sich das Top-Management verhalten?
Bob Schatz: Einerseits war meine Position in der Unternehmens-Hierarchie förderlich bei der Einführung: Ich habe Scrum als Vice President Development eingeführt. Ich wollte das nicht gegen den Willen der Leute machen, sondern sie bei Einführung mitnehmen, sie überzeugen. Ich habe ihnen verdeutlicht, dass wir nicht einfach so weitermachen können, dann zeigte ich ihnen meine Vision auf, wie es bei uns laufen könnte. Schließlich erklärte ich ihnen, dass Scrum uns auf dem Weg dorthin sehr nützlich sein würde. Ich malte eine Vision auf und ergänzte sie um Werte, die wir verinnerlichen wollten. Dann machte ich meinen Leuten bewusst, dass der Veränderungsschmerz, den wir mit Sicherheit haben werden, geringer sein wird als das Übel, das wir aktuell ertragen mussten. Erst als mein Team das verstanden hatte, ging es so richtig los.
Andererseits gab es eine Hierarchie über mir, der CEO und der COO. Beide gehörten zu den Gründern des Unternehmens und sind sehr versiert in Projektmanagement. Sie konnten nicht verstehen, warum ihr Unternehmen mit Projektarbeit solche Probleme hatte und diese nicht mit ihrem Projektmanagement-Tool lösen konnte. Zunächst weihte ich sie in meine Scrum-Pläne nicht ein – die ersten Sprints verliefen quasi geheim. Ich wollte nicht, dass sie glaubten, ich würde eine Nicht-Projektmanagement-Methode anwenden, um eine Projektmanagement-Software zu entwickeln. Zu den Sprint Reviews allerdings lud ich sie ein, ohne dass ich diese Begrifflichkeit verwendete. Ich sagte lediglich, dass wir uns die Entwicklungs-Ergebnisse der letzten vier Wochen anschauen würden. Die beiden kamen und waren wirklich überrascht, nahezu geschockt. Nach dem dritten Sprint Review nahm mich der CEO beiseite und sagte „Ich weiß zwar nicht, was Sie hier treiben, aber es ist großartig. So etwas habe ich noch nicht erlebt. Das einzige, was mir  Sorgen macht: Wir machen schon noch Projektmanagement, oder?“. „Ja“, sagte ich, „es ist zwar kein klassisches Projektmanagement mehr, aber wir arbeiten projektorientierter als jemals zuvor – und sind damit sehr erfolgreich, wie die Ergebnisse demonstrieren.“ Ich sagte ihm, dass sich das Ganze Scrum nennt und offensichtlich recherchierte mein CEO zu dem Thema und teilte dann meine Einschätzung.

Heute sage ich meinen Kunden, dass die Unterstützung durch das Top-Management bei der Einführung von agilen Methoden sehr wichtig ist. Denn irgendwann stößt das Team oder einzelne Mitglieder auf Probleme oder sind überfordert. Dann muss die Führungsriege bereitstehen und Arbeitsbedingungen schaffen, wo es möglich, Werte für Kunden zu schaffen – und darum geht es letztlich. Ich versuche nicht den Prozess als Ziel zu beschreiben, es geht immer um das Ziel eines Prozesses. Wer die Einführung von Scrum nicht an die große Glocke hängen möchte, der sollte es heimlich einführen und dann mit den Resultaten überzeugen – so wie ich das gemacht habe.

Project Management in Real-TimePZC: Sie führten eine Abteilung mit 120 Entwicklern – haben Sie Scrum auf breiter Front eingeführt oder zuerst in einem kleinen „Pilot-Team“?
Bob Schatz: Zunächst wollte ich mit einem Pilot-Team starten und dann schrittweise die ganze Abteilung auf Scrum umstellen. Wir hatten dann im Team eine Woche lang intensive Diskussionen darüber, so dass ich zu dem Entschluss kam, Scrum gleich von Anfang an in der ganzen Abteilung einzuführen. Wir waren in einer solch verzweifelten Situation, dass wir den Sprung ins kalte Wasser wagen konnten – schlimmer konnte es kaum werden.
Heute rate ich meinen Kunden, sofern sie sich nicht in einer ähnlich schlimmen Situation befinden wie wir damals, zuerst einen Piloten zu starten, um erste Erfahrungen mit Scrum zu sammeln. Aber wenn es die Situation erfordert, empfehle ich manchmal auch, auf den Piloten zu verzichten und gleich abteilungsweit auf Scrum umzustellen.

Software-Entwicklung

Hier erfahren Sie, wie Can Do bei der Entwicklung vorgeht

PZC: Die Einführung von agilen Methoden erfordert Entschlossenheit und einen hervorragenden Veränderungsprozess. Können Sie uns eine Roadmap zeichnen, wie der Widerstand bei der Einführung agiler Methoden überwunden werden kann?
Bob Schatz: Am wichtigsten bei der Einführung ist es zu erklären, warum eine agile Methode eingeführt werden soll und welche Konsequenzen dies mit sich bringt. Dann erst geht es um Veränderungsprozesse und um die Frage, ob zunächst ein bestimmtes Projekt agil umgesetzt werden soll, ob ein Pilot-Team gebildet werden soll oder ein bestimmtes Produkt so entwickelt werden soll. Die Einstiegsfrage lautet stets, wie soll etwas umgesetzt werden? Dann wendet man den Blick auf das Team, darauf, dass es ums Team und nicht um Individuen geht. Es muss klar sein, dass der Kunde und seine Anforderungen im Mittelpunkt stehen. Das ist wie eine Art Schulung, die das Team durchlaufen muss. Wenn das verinnerlicht ist, kann und muss es losgehen.
In der Umsetzung kommen dann Themen auf, die gelöst werden müssen. So findet jede Organisation ihren agilen Weg. Letztlich muss die Einführung des Agilen bereits agil umgesetzt werden: Fangen Sie einfach an, justieren Sie nach, lernen Sie aus Ihrem Vorgehen und passen Sie Ihr Vorgehen an und beginnen dann wieder von vorn. Nur das hilft.
Wenn Sie möchten, dass eine breite Unterstützung vorherrscht, hilft folgendes: In Großunternehmen formiere ich das Führungsteam als Scrum-Team, dessen Aufgabe es ist, Scrum zu implementieren. Das Führungsteam lernt dann Scrum während es Scrum einfügt – und das betrifft dann das gesamte Unternehmen.