Weihnachten 2013 – Zeit für ein Agile Management Review 2013. Was waren meine Themen und meine Beobachtungen in der Beratung dieses Jahr in der embedded Softwareentwicklung?
Über mehrere Kunden und Projekte hinweg habe ich meinen Kunden folgende Dinge empfohlen:
- Teams von verteilten Standorten zusammenlegen bzw. anders schneiden
- Entwicklungskapazitäten aus Ost-Europa und Asien zurückholen
- Personal (Softwareentwickler) aufbauen
- Entwickler von bestimmten Management-Ebenen abschotten
Naja, das klingt nicht gerade beratermäßig ;) und klingt nicht gerade kostenbewusst. Doch diese Ratschläge erfolgten immer in dem Kontext Entwicklung schneller, besser und preiswerter zu machen. Schauen wir uns die Hintergründe der oben gemachten Statements einmal genauer an:
Teams zusammenlegen
Bei (erschreckend) vielen Kunden begegnet mir die Frage: “Wie kann ich ein Entwicklungsteam das über 5 Standorte auf 3 Kontinenten verteilt ist agil entwickeln?”. Die ehrlich Antwort ist: “gar nicht”. Ich habe noch nicht herausgefunden, was viele Unternehmen dazu veranlasst Teams auf diese Art zu schneiden. Alleine die sichbaren Reibungsverluste wie z.B. der Reiseaufwand für gemeinsame Besprechungen sollten auch den tayloristischsten aller Manager zum Nachdenken bringen. Viel gravierender sind aber die versteckten Reibungsverluste durch eingeschränkte Möglichkeiten zur informellen Kommunikation und zur sozialen Bindung. Dies sind die Faktoren die bewirken dass ein Team mehr ist, als die Summe seiner Teile, im Sport, in der Luftfahrt oder in agilen Teams kann das gut beobachtet werden.
Teams sind leistungsfähig, innovativ und wachsen über sich selbst hinaus. Über Standorte verteilte Gruppierungen von Mitarbeitern sind aber keine Teams.
Entwicklungskapazitäten zurückholen
Software-Entwicklung wird heutzutage “offgeshored”, also in Länder mit niedrigerem Lohnniveau verlegt. Damit kann man auf den ersten Blick Kosten einsparen. Oft habe ich jedoch beobachtet, dass zwischen den Entwicklern in Deutschland und den “offgeshorten” Entwicklern keine präzisen Schnittstellen definiert sind, oder gar Teams über Kontinente hinweg geschnitten werden (siehe oben). Die hier entstehenden Reibungsverluste, auch die die es mit präzisen Schnittstellen gibt, sind nicht leicht zu erfassen. Wohl deshalb werden Entscheidungen hin zum Offshoring erleichtert. Nichts bringt jedoch das Thema so gut auf den Punkt, wie eine Situation die mir dieses Jahr in einem Projekt begegnet ist: Da die Requirements-Manager in Deutschland mit zu wenigen Ressourcen besetzt waren, startete die Softwarentwicklung ihre Arbeit direkt mit den Kundenanforderungen. So weit vielleicht nichts besonderes, in diesem Fall aber problematisch, weil die Kundenanforderungen auf Deutsch verfasst waren und die Hälfte der Softwarentwickler in Osteuropa sitzen. Nach einigen gescheiterten Versuchen der deutschen Entwickler die Kundenanforderungen ins Englische zu übersetzen, sah die Best Practice so aus, dass die Gruppenleiter(!) in Deutschland ihren Kollegen in Osteuropa täglich mehrere Stunden telefonisch die Anforderungen übersetzt und erklärt haben. Wie viel Geld das Offshoring in diesem Fall gespart hat, darf jeder für sich selbst abschätzen.
Offshoring erzeugt einen nicht zu vernachlässigenden Kommunikationsoverhead. Dieser kann entweder durch präzise Schnittstellen und hochwertige Dokumentation sichtbar gestaltet werden oder aber durch ungünstig geschnittene Teams und zwangsläufige Improvisation unsichtbar gestaltet werden (viele Unternehmen tendieren zu letzterem). Verschwinden wird der Overhead aber nicht. Ist man sich dessen bewusst und bezieht die Overheadkosten mit in die Entscheidungsfindung ein, kann Offshoring eine mögliche Lösung sein.
Personal aufbauen
Nach wie vor finden sich im Mittelstand viele Firmen, die sich gerade in der Transition vom Maschinenbauer zum Software-Schmiede befinden. Meine Beobachtung ist, dass die Tragweite dieser Umstellung nicht immer erkannt oder angemessen berücksichtigt wird. Dies ist aus der Historie der Firmen heraus auch verständlich: Nach und nach hat die Software Einzug in die produzierten Geräte und Komponenten gehalten. Die Software taucht plötzlich als eine kleine Position auf der Stückliste auf und muss nun auch produziert werden. Schnell sind 1-2 Programmierer eingestellt und los geht es. Parallel dazu ändert sich jedoch auch der Markt. Nicht mehr nur der Maschinenbau entscheidet über die Position im Markt, die Fähigkeit des Unternehmens Kunden- oder Marktanforderungen schnell und mit hoher Qualität in Software umsetzen zu können wird zunehmend wettbewerbsentscheidend. Die ersten Anzeichen sind, dass das die neu aufgebaute Software-Abteilung zum Engpass in den Projekten wird. Personal wird jedoch nicht aufgebaut, in der Annahme dass der aktuelle Engpass dem Initialaufwand geschuldet ist und die Personaldecke für die folgende Wartung ausreichend ist. Es fehlen meistens erfahrene Architekten und Tester. Die Bedeutung von Reaktionszeit und Qualität wird nach meinen Beobachtungen oft massiv unterschätzt.
Am preiswertesten ist es, gar keine Software zu entwickeln. Am teuersten ist es, “ein wenig” Software zu entwickeln. Am erfolgreichsten ist es, in ein professionelles Software-Team zu investieren, denn dieses wird in Zukunft die Wertschöpfung und die Wettbewerbsvorteile bringen, nicht der Maschinenbau.
Management vs. Entwicklung
Uiuiui…. was ich da wieder erlebt habe: Schätzungen werden vom Top-Management halbiert, Terminzusagen werden ohne Rücksprache mit der Entwicklung gemacht, das alles bei gleichzeitiger Einführung neuer Technologien. Das Ergebnis: tief rote Projekte, hohe Fluktuation, Micromanagement über mehrere Hierarchieebenen hinweg…
Wie kommen wir da hin, die Aufgaben von Entwicklung und Management klar zu definieren bzw. zu trennen um gemeinsam für den Unternehmenserfolg zu arbeiten? Meines Erachtens die größte Herausforderung für die nächsten Jahre. Prozessreife, funktionale Sicherheit usw. sind da eher die Randthemen. Naja, ganz so extrem ist es nicht, aber das Thema “Management von Entwicklungsorganisationen” werden wir 2014 mehr in den Fokus nehmen.
Das hier soll kein Manager-Bashing werden, vermutlich würden Entwickler den Managern genauso reinreden, wenn die Hierarchie es hergeben würde. Die oben genannten Negativ-Beispiele zeugen nicht von bösem Willen der entsprechenden Manager, viel mehr von Unwissenheit gepaart mit einem Hauch von Hilflosigkeit und manchmal auch Sorglosigkeit. Entwicklungsorganisationen und sozial Systeme funktionieren nur selten so wie es die letzten 150 Jahre gelehrt und gelebt wurde. Das veränderte Rollenverständnis des Managements ist inzwischen auch ein Wettewerbsfaktor in Zeiten von immer kürzeren Produktzyklen und Fachkräftemangel. Doch wo geht die Reise hin?
Etablierte Managementansätze (besser: “praktizierte” Managementansätze) wurden die letzten Jahre zunehmend in Frage gestellt. Die agilen Ansätze bieten eine Perspektive für ein neues Rollenverständnis von Managern, zunächst in Entwicklungsorganisationen, später auch in anderen Industrien und Dienstleistungen. Es lohnt sich (nicht nur für Berater ;)) sich mit diesen Themen auseinanderzusetzen.
Literaturtipps
Jurgen Appelo: Management 3.0
Dave Gray: The Connected Company
Gerhard Wohland: Denkwerkzeuge der Höchstleister