5 Erkenntnisse aus meiner agilen Karriere, für die ich dankbar bin
Es ist gerade Thanksgiving hier in den USA. Daher habe ich mir etwas Zeit genommen, um über einige Lektionen nachzudenken, die ich im Laufe meiner agilen Laufbahn gelernt habe und für die ich sehr dankbar bin. Auch wenn diese Erkenntnisse sich nicht ausschließlich auf Scrum oder Agile beziehen, haben sie doch zu meinem Erfolg mit Agile beigetragen.
Bei jeder dieser Lektionen werde ich kurz mit Hilfe einer Geschichte erläutern, was ich gelernt habe und wie. Ich hoffe, dass ich Ihnen dadurch helfen kann, diese Fehler zu vermeiden, die ich gemacht habe, bevor ich diese Lektionen verinnerlicht hatte.
1) Wenn es zwei Wege gibt, nimm den Richtigen
Einer meiner ersten Programmierjobs war in der Rechtsabteilung eines großen Consultingunternehmens. Ein Großteil unserer Arbeit hatte mit plötzlichen Anfragen von den Anwälten der Gegenpartei zu tun, denn wir entwickelten Software, die unsere Anwälte dabei unterstützen sollte, diesen Anfragen nachzukommen.
Häufig bedeutete dies, Programme zu schreiben, die nur ein einziges Mal genutzt wurden, die aber innerhalb von 24-48 Stunden perfekt sein mussten. Mein Boss war ein Unix-Shell-Genie und entwickelte fast alles ohne Hinblick auf zukünftige Wiederverwendung. Jedes Programm war zu 100% neu. Er passte nicht mal alte Programme an, um die neuen auf deren Basis zu entwickeln.
Das war nicht zwingend eine schlechte Entscheidung. Oft war es einfach die schnellste Option, um auf die Anfragen der Anwälte zu reagieren. Ich wusste jedoch, dass wir langfristig sogar noch schneller reagieren konnten, wenn wir anfangen würden, eine gemeinsame Code-Bibliothek zu erstellen. Aber würde es das wert sein? Hatten wir überhaupt die Zeit, heute 10% langsamer zu sein, um später 50% schneller sein zu können?
Kurz nachdem ich in das Projekt gekommen war, wurde mein Chef befördert und arbeitete von nun in einem anderen Bereich dieses Projekts. Ich musste eine Entscheidung fällen: Sollte ich weiterhin so arbeiten wie bisher? Oder sollte mich darauf konzentrieren, eine Bibliothek zu erstellen?
Ich kann mich noch genau an einen Samstag mit Sean und David, zwei anderen Programmierern, im Büro erinnern. Wir unterhielten uns darüber, ob wir anfangen sollten, die Bibliothek zu bauen oder ob die Deadlines so dringend waren, dass wir uns nur darauf konzentrieren konnten. Am Ende war es eine einfache Entscheidung. Wir einigten uns darauf, immer, wenn wir an etwas arbeiteten, dies auch zur Bibliothek hinzuzufügen.
Das war eine der besten Entscheidungen, an denen ich jemals beteiligt war. Sie zahlte sich viel schneller aus, als ich es jemals erwartet hätte, denn nur ein paar Monate später standen wir Herausforderungen gegenüber, die wir ohne die wiederverwendbare Bibliothek nicht hätten überwinden können.
Daher bin ich froh, die folgende Lektion gelernt zu haben:
Wenn es zwei Wege gibt, nimm den Richtigen!
Der richtige Weg scheint manchmal länger zu dauern oder schwieriger zu sein, aber aus meiner Erfahrung kann ich sagen, dass es das immer wert ist!
2) Das Leben ist zu kurz, um mit Leuten zu arbeiten, die man nicht mag und respektiert
Einer der letzten Jobs, die ich vor Mountain Goat Software hatte, war in einer sehr dysfunktionalen Kultur. Diese Kultur existierte schon lange, bevor ich in das Unternehmen kam, aber leider hatte ich das während der Jobinterviews nicht entdeckt. Vielleicht war ich so geblendet von der coolen Software, die ich mitentwickeln sollte, dass ich die Kultur verdrängte und den Job annahm.
Es war schrecklich. Ich war einer von fünf Leuten, die dem CEO Bericht erstatten mussten. Eines Tages entschied sie, dass die Leute länger arbeiten mussten. Nicht, weil es eine wichtige Deadline einzuhalten galt, sondern einfach nur so. Jedem von uns fünf teilte sie einen Tag in der Woche zu, an dem wir bis 19:00 Uhr im Büro sein mussten, damit die anderen Mitarbeiter sehen würden, dass wir länger blieben. Und das sollte sie motivieren, das Gleiche zu tun.
Jeder, der mich kennt, weiß, dass ich ein Workaholic bin, weil ich nun mal liebe, was ich tue. Aber ich habe auch eine Schraube locker. Egal, wie groß ein Projekt ist, denke ich immer, dass wir es bis zum nächsten Tag fertigstellen können, wenn wir nur die Nacht durcharbeiten. Mein Verstand weiß, dass das Quatsch ist, was mich aber nicht davon abhält, es zumindest zu versuchen.
Was ich damit sagen will: Ich mache oft Überstunden. Aber ich mache das auf meine Weise. Ich beende meine Arbeit gerne zu einer vernünftigen Zeit, vielleicht 17:00 Uhr. Dann mache ich ein wenig Sport und esse mit meiner Familie zu Abend und danach (manchmal ziemlich spät abends) arbeite ich noch etwas.
Aber sagt man mir, ich müsse bis 19:00 Uhr im Büro bleiben, meldet sich mein Anti-Establishment-Ich und will rebellieren. Auch wenn ich oft sogar länger als bis 19:00 Uhr im Büro war, regte es mich auf, wenn mein Chef mir das vorschreiben will. Und auch die Botschaft, die es an Andere sendete, gefiel mir nicht. Tatsächlich wartete ich bis unser CEO das Büro verließ (meistens nicht später als 17:15 Uhr) und sagte dann allen, die noch im Büro waren, sie sollten nach Hause gehen.
Unser CEO war nicht die einzige dysfunktionale Person in diesem Unternehmen. Es gab viele. Da gab es den Architekten, der den Sitzungssaal des Vorstandes verwanzte, um die Meetings abhören zu können. Dann gab es den Entwickler, der behauptete gegen unser Gebäude allergisch zu sein und sich nach zwei Tagen im Job krank schreiben ließ. Ich könnte noch länger so weiter erzählen.
Eines Tages verkündete unser CEO wieder eine neue völlig abstruse Regel – ich kann mich nicht mal mehr an die Einzelheiten erinnern. Als ihre E-Mail kam, war ich im Büro eines Kollegen. Er las mir die Mail vor, wir beide schauten uns an und wussten:
Das Leben ist zu kurz, um mit Leuten zu arbeiten, die man nicht mag und respektiert!
Wir hatten beide entschieden, dass wir nie mehr mit Leuten arbeiten würden, die wir nicht mögen und respektieren. Das ist es einfach nicht wert. Innerhalb eines Monats hatten wir beide das Unternehmen verlassen und es nie bereut. Heute haben wir unsere eigenen erfolgreichen Agile Coaching und Training Unternehmen und waren nie glücklicher.
3) Jemanden aus dem Team zu werfen, ist nie so schlimm, wie man denkt
Jemanden zu feuern, ist nie leicht, auch wenn es berechtigt ist. Ich musste einmal einem System Engineer kündigen, weil er Hardware aus der Firma gestohlen und online verkauft hatte. Die Polizei ertappte ihn bei der Hehlerei mit Hardware, die er für das Unternehmen gekauft hatte, die aber in unserem Rechenzentrum nicht auffindbar war und die passenden Seriennummern aufwies.
An seiner Schuld gab es keinen Zweifel und seine Verhandlung stand an. Dennoch stand mein Chef nicht hinter meiner Entscheidung, dass der Kollege das Unternehmen verlassen sollte. Die Begründung meines Chefs war: „Weißt du, was die mit hübschen Jungs wie ihm im Gefängnis machen?” Jawohl, genau das hat er zu mir gesagt und zögerte, die richtige Entscheidung zu treffen, nur weil er zu viele Filme geschaut hatte. Natürlich musste die Person das Unternehmen verlassen, aber sogar so jemanden zu feuern, war keine leichte Entscheidung. Das ist es nie.
Manchmal ist es schwer, jemanden zu feuern, weil derjenige der einzige ist, der einen bestimmten Job machen kann und das Team von der Person abhängig ist. Die Befürchtung ist dann, dass das Team wesentlich langsamer wird, sobald diese Person nicht mehr da ist.
Aus meiner Erfahrung heraus kann ich sagen, dass diese Befürchtungen oft sehr übertrieben sind. Ich musste schon ein paar mal Leuten kündigen, die die einzigen Personen waren, die eine wichtige Sache erledigen konnten oder sich mit wichtigem Code auskannten. Aber diese Personen gehen zu lassen und zu sehen, wie schnell sich die Teammitglieder diese Fähigkeiten und Kenntnisse aneignen, lehrte mich eines:
Jemanden aus dem Team zu werfen, ist nie so schlimm, wie man denkt.
Teams sind erstaunlich resilient. Wenn es etwas dazuzulernen gibt, werden sie sich damit auseinandersetzen und es lernen.
Außerdem kann man davon ausgehen, dass zu dem Zeitpunkt, an dem ein Manager bemerkt hat, das jemand gefeuert werden sollte, er sich dann tatsächlich damit auseinandersetzt und die Personalabteilung davon in Kenntnis setzt, das Team schon seit Monaten wusste, dass derjenige besser gehen sollte. Die Teammitglieder bemerken diese Dinge normalerweise wesentlich schneller als Manager.
Jemandem zu kündigen, sollte immer wohl überlegt sein. Aber es ist nie so schwer, wie man vorher dachte.
4) Die klügste Person im Raum ist nicht klüger als der ganze Raum
Viele Führungskräfte haben die Karriereleiter erklommen, weil sie gut sind, in dem, was sie tun, und weil das jemand bemerkt hat und sie schließlich befördert hat. Daher waren viele Führungskräfte und Manager zumindest zeitweise die klügste Person im Raum.
Wenn eine Entscheidung anstand, haben sie ihre Meinung verteidigt, die Diskussion darüber, wie es gemacht werden soll, gewonnen, und somit sehr häufig das Team zur richtigen Entscheidung geführt. Aber egal, wie klug die klügste Person im Raum auch sein mag, es ist äußerst unwahrscheinlich, dass diese Person auch klüger ist als die kollektive Weisheit des gesamten Teams.´
Diese Erfahrung habe ich früh in meiner Karriere gemacht. Ich war der Leiter eines Softwareteams, was bedeutete, dass ich ungefähr 3-5 Jahre mehr Erfahrung hatte als die anderen Teammitglieder. Aufgrund dessen war ich wohl auch bei bestimmten Diskussionen die klügste Person im Raum.
Ich kann mich noch an eine Situation erinnern, in der ein Teammitglied plötzlich und ganz ohne Diskussion seine Meinung änderte. Als ich fragte, warum er seine Meinung geändert habe, sagte er, dass ich es als Leiter des Teams nun mal am besten wüsste. Das hat mich geschockt. Auch wenn das in einigen Situation vielleicht der Fall gewesen sein sollte, wollte ich nie, dass die Teammitglieder nur aufgrund meiner Position und meines Jobtitels mit mir einer Meinung waren.
Seitdem hasse ich Jobtitel. Sie sind das, was wir der Welt von uns zeigen wollen. Innerhalb eines Unternehmens sollten Jobtitel bedeutungslos sein.
Ich bin mir sicher, dass dieser Junior-Entwickler in manchen Fällen bessere Ideen hatte als ich. Welch eine Schande es gewesen wäre, wenn er diese Ideen aufgrund meines Titels zurückgehalten hätte.
Von dieser und ähnlichen Situationen habe ich gelernt:
Die klügste Person im Raum ist nicht klüger als der ganze Raum!
Egal, wie klug jemand ist oder wie viel Erfahrung jemand hat, die kollektive Weisheit des Teams ist größer. Die besten Ideen und Entscheidungen entstehen aus Diskussionen und nicht aus dem Verstand einer einzigen Person.
5) Ohne Erwartungsmanagement kann man erwarten, zu scheitern
Diese Lektion habe ich von dem wahrscheinlich am wenigsten technisch versierten Boss gelernt, den ich je hatte. Jedoch hatte er verstanden, wie wichtig Erwartungsmanagement ist.
Damals bauten wir ein großes Call Center System, das von dem Pflegepersonal in unserer Firma genutzt werden sollte. Das Projekt war sehr erfolgreich und half dem Unternehmen dabei, von 100 auf über 1.600 Mitarbeiter innerhalb weniger Jahre zu wachsen.
Wenn ich jedoch ein paar Monate vor Beendigung des Projekts nicht meinen Fokus geändert hätte, wäre dieses Projekt wohl ein komplettes Desaster geworden.
Das Problem waren die völlig übersteigerten Erwartungen der Nutzer. Die Pflegekräfte glaubten plötzlich, dass die Software Dinge tun müsse, die selbst jetzt nach über 20 Jahren noch nicht möglich sind. Einige der Dinge, die sie sich überlegt hatten – und miteinander geteilt hatten – waren großartige Ideen.
Ich war mir der Diskrepanz zwischen den Erwartungen der Nutzer und der Realität bewusst. Jedoch war ich zu sehr mit den technischen Aspekten des Projekts beschäftigt, um mir darum Gedanken zu machen. Doch eines Tages gab mir mein Chef einen Rat, der mich zum Umdenken bewegte. Er sagte, um erfolgreich zu sein, müsse das Projekt zwei Dinge erfüllen:
Die nötige Funktionalität liefern
Die Erwartungen der Nutzer erfüllen bzw. übertreffen
Er teilte mir mit, dass, wenn wir einen der beiden Punkte nicht erfüllen würden, das gesamte Projekt fehlschlagen würde. Mir war direkt klar, dass wir die aktuellen übersteigerten Erwartungen unserer Nutzer nie übertreffen oder auch nur erfüllen konnten. Da es nicht in meiner Macht stand, unsere technischen Möglichkeiten zu ändern, fing ich an, an der Einstellung der Nutzer zu arbeiten.
Ich richtete meinen Fokus sofort neu aus und verbrachte die Hälfte meiner Zeit damit, mich mit den Nutzern darüber zu unterhalten, was das System können würde und was nicht. Ich besuchte alle paar Wochen alle vier Call Center im ganzen Land und präsentierte den Pflegekräften unser Äquivalent eines Sprint Reviews an jedem Standort.
Ich habe Folgendes daraus gelernt:
Ohne Erwartungsmanagement kann man erwarten, zu scheitern
Hätte ich mich weiterhin rein auf die technische Seite des Produkts konzentriert, hätten unsere Nutzer am Ende gesagt: „Ist das Alles?” Ihre unrealistischen (umöglichen!) Erwartungen hätten dazu geführt, dass sie von einem sehr guten Produkt enttäuscht gewesen wären; von einem Produkt, dass dem Unternehmen am Ende mehrere Milliarden Dollar einbrachte.
Fazit: Ich bin dankbar für diese Leadership-Lektionen
Es gibt noch viel mehr Lektionen, für die ich dankbar bin. Ich muss gewisse Erfahrungen manchmal öfter machen, bis ich sie verstanden habe. Alle Erfahrungen, die ich hier geteilt habe, habe ich relativ früh im Laufe meiner Karriere gemacht und alle hatten einen großen Einfluss auf meine Karriere.
Aber eine Sache möchte ich noch mit Ihnen teilen:
Ohne euch könnte ich nicht das tun, was ich tue.
Ich habe darüber geschrieben, was ich gerne tue, und das ist so, weil ich ein Workaholic bin. Abgesehen davon, dass es sich für mich meistens nicht nach Arbeit anfühlt. Ich könnte nicht tun, was ich gerne tue, wenn es nicht Leute gäbe wie Sie, die gerne meinen Blog oder meine Tipps lesen.
Und dafür bin ich sehr dankbar.
Werde zertifizierter ScrumMaster oder [Certified Product Owner](/de/product-owner/certified-scrum-product-owner/ "Certified Product Owner") mit der Agile Academy. Unsere ausgezeichneten Trainer helfen dir auf deinem agilen Berufsweg und bieten dir eine Vielzahl an Trainings und Fortbildungen an.