Scrum: Interview mit Gregor Groß

Wie arbeitet eine Firma in der agilen Hardewareentwicklung? Wir haben uns mit Gregor Groß von der alpha-board GmbH aus Berlin erklären lassen, wie er sein Unternehmen als effektiven Dienstleister etabliert hat.

Gregor Gross ist seit 2008 Geschäftsführer der alpha-board GmbH. In einem lockeren Austausch (wie man im laufe des Interviews merkt), erklärt er wie seine Firma Scrum in der agilen Hardewareentwicklung einsetzt.

idalab: Was macht ihr eigentlich genau?

Gregor Groß: Wir bei alpha-board machen für unsere Kunden agile Hardwareentwicklung, wir designen elektronische Produkte im Kundenauftrag. Also haben wir selber keine Produkte, sondern machen nur Hardwareentwicklung für Kunden für deren Produkte und in letzter Zeit agil und mit Scrum.

Ihr habt also keinen Fokus, ich kann zu euch mit irgendwas kommen?

Also so einen richtigen Fokus haben wir nicht, aber in letzter Zeit viel drahtlose Kommunikation, Wearables, IoT, so’n Zeug. Also bei Hardware-Entwicklung. Wir machen ja auch noch verschiedene andere Dienstleistungen, wir haben ja auch noch einen Fertigungsservice. Bei Fertigung ist es so, dass wir für manche Kunden nur Leiterplatten fertigen, die wollen die gar nicht bei uns entwickelt haben. Und zwischen Entwicklung und Fertigung, Fertigen heißt Leiterplatte liefern und bestücken, dazwischen gibt es den Schritt des PCB Designs und für manche machen wir nur diesen Schritt ohne Entwicklung und Fertigung. Für manche machen wir alles. Für die PCB Designs, da kann ich nicht sagen, ob wir da eine Spezialität haben.

Bevor ihr jetzt angefangen habt agil zu arbeiten, wie habt ihr eure Projekte an Kunden verkauft, auf was für einer Basis habt ihr mit denen gearbeitet? Festpreise, nach Aufwand?

Aufwand schätzen, Festpreis machen und dann hoffen, dass Du da gewinnst. Sozusagen ein Werkvertrag. Der Werkvertrag ist ne Erfindung von bösen Leuten, um Risiken auf arme Dienstleister abzuwälzen, das ist meine Sicht. Und von Anfang an hast Du ja in einem Werkvertrag entgegengesetzte Interessen, weswegen der nie glücklich zu Ende gehen kann. Der Auftraggeber möchte so viel wie möglich rein packen, und der Dienstleister möchte so wenig wie möglich Arbeit leisten um das Werk vollendet zu haben, damit er sein Geld kriegt. Und das ist ja nunmal genau das Gegenteil. Am Ende, wenn mindestens eine Seite und meistens irgendwie beide Seite unzufrieden sind sagt man dann, man hat die Anforderungen nicht genau genug festgelegt. Aber das ist das Problem, man lernt ja erst im Projekt, was genau die Anforderungen sind. Noch schlimmer ist es, wenn man ein Projekt macht ohne den Nutzer zu fragen, dann lernst Du es erst nach dem Projekt. Von daher kannst Du per Definition die Anforderungen nicht festlegen, somit auch nicht den Aufwand schätzen, den Du dafür benötigst, und von daher ist der Werkvertrag unfair, finde ich.

Das klingt sehr plausibel. Wenn Du das so beschreibst, wie konnte man überhaupt jemals bei innovativen komplexen Problemen mit Festpreisen arbeiten? Warum macht denn das die ganze Welt? Euch gibt’s ja auch nicht erst seit heute, wie habt ihr das so lange ausgehalten?

Wir haben es ja nicht ausgehalten, wir haben uns unglücklich gefühlt.

Na gut, aber euch gibt’s ja schon seit über 10 Jahren!

Naja, Du versuchst so wenig wie möglich zu machen, um das hinzuwurschteln, da sind Risiken dabei, die sind unerhört. Wie gesagt, ausgedacht haben sich das Leute, die im Einkauf arbeiten und denken verhandeln funktioniert indem man den anderen erdrückt und fertig macht. So funktioniert Verhandeln aber nicht. Ich finde, es geht darum, dass man Zusammenarbeit mit dem Kunden hat und nicht gegen ihn.

Übrigens: wir sind ja gar nicht so weit weg vom Werkvertrag. Wir sagen, die gesamte Funktionalität deines Projekts fällt dir sowieso erst im Rahmen des Projekts ein. Weil Du und Deine Anwender den Prototypen erst dann sehen, und die Annahmen hinsichtlich der Funktionalität erproben können. Und dann findest Du heraus welche Funktionalitäten Du haben willst und welche Du eigentlich gar nicht brauchst.

Und das Problem beim Werkvertrag ist übrigens noch, dass man dann sagt, man kann den Umfang festlegen und über Schätzungen sicher sein wie lange es dauern wird. Bloß Schätzungen sind per Definition eben Schätzungen. Besser wäre es, man legt fest, wieviel man ausgeben kann, daraus ergibt sich Teamgröße und Dauer. Teamgröße natürlich nicht beliebig, aber die Dauer. Dann schauen wir welchen Umfang wir liefern können in der zur Verfügung stehenden Zeit. Und damit der Kunde mit diesem aus dem Budget abgeleiteten Umfang auch leben kann, sortiert man dann die Funktionalitäten so, dass man mit den wichtigen anfängt und mit den unwichtigen aufhört. Unserer Erfahrung nach ist dann kurz vor Budgetende sowieso Schluss mit der Arbeit, weil der Kunde sagt, der Rest interessiert ihn garnicht mehr. Und wir füllen dann die Sprints des Projekts, derzeit eine Woche lang bei uns, mit diesen priorisierten Funktionalitäten und fangen halt mit den wichtigen an.

Und so ein mit Funktionalitäten gefüllter Sprint ist ja dann wieder ein Werkvertrag, weil wir gesagt haben, wir liefern das in der Zeit des Sprints. Wenn wir damit nicht fertig werden, müssen wir dann halt nacharbeiten, um das zu liefern.

Für den Kunden bedeutet das, folgende Frage zu beantworten: Was ist dir denn dieses Projekt wert?

Gab’s bei euch so einen Moment an dem Du gemerkt hast so kann es nicht weitergehen, ein Schlüsselerlebnis?

Steter Tropfen höhlt den Stein. Und ich war mal in einer Softwarefirma, die schon seit acht Jahren dabei ist, Scrum durchzuziehen. Und in dieser Firma war alles anders. Die Leute waren leise, friedlich, lieb, motiviert und die haben weggeklotzt und das war einfach ne coole Firma. Da saß ich drei, vier Tage zum Hospitieren, weil ich den Chef kenne. Da hab ich gedacht, das will ich auch haben. Die hatten vorher auch lauter Werksverträge und irgendwelche Risiken, immer alle unzufrieden, immer Stress. Und jetzt, wenn Du da hinkommst, denkst Du die sitzen da zum Meditieren nebeneinander. Also es ist ein ganz anderes Arbeiten, da sind wir noch ein paar Lichtjahre entfernt von, also zumindest ein paar Parsecs.

Wie lief das mit den Kunden, Du hast ja bestimmt schon lange Beziehungen?

Ich weiß darüber nicht so viel, denn das macht der Vertrieb, ich halte mich raus.

Personas eShisha alpha-board

Aber Du kriegst das mit?

Meine Erfahrung ist, wenn man den Leuten sagt wie man’s macht, dann finden sie es ok, dass man es ihnen gesagt hat und machen mit. Manch einer wird dann sagen, so kann er sich das nicht vorstellen, aber meine Erfahrung ist, wenn man denen erklärt, warum du das machst, dann sagen sie “gut, verstehe”. Der Druck auf Kundenseite hin zu SCRUM, der steigt auch.

Elon Musk baut diesen Tesla. VW macht sich in die Hosen, denn VW braucht 2.5-3 Milliarden um ein Serienauto auf die Straße zu kriegen und Tesla hat es gerade für eine Milliarde gemacht. Der macht das für einen Drittel des Preises, so hört man, und das ist von der Qualität ein ernstzunehmendes Auto. Soll jetzt nicht heissen, dass Tesla VW bedroht, denn er baut 30k Autos im Jahr. Jetzt will er ja 200k bauen, da werden vielleicht auch bei Tesla ein bisschen Probleme auftreten, wir werden sehen. Aber er bringt ein ernstzunehmendes Auto auf die Straße für ein Drittel der Kosten

Warum kann er das? Weil er es agil macht! Das weiß ich, weil der, der uns gecoacht hat, auch Zulieferer von Tesla berät und die versuchen nun krampfhaft agil zu werden, damit sie für Tesla als Lieferant in Frage kommen. Denn Tesla will nur Lieferanten haben, die so arbeiten wie sie, was anderes interessiert die nicht. Da kannst Du davon ausgehen dass VW das bald auch will und bei der Deutschen Bahn habe ich auch schon gehört, dass sie es wollen.

Und wenn so Riesen jetzt anfangen sich mit dem Thema zu beschäftigen, dann werden die kleinen Lieferanten, die normalen Firmen das auch machen. Und wir haben ja schon einige Kunden, die extra deswegen zu uns kommen, weil sie das gehört haben. Und bei anderen ist meine Erfahrung, wenn du das denen genau erklärst warum du das so und so machen willst, dann akzeptieren sie das. Die verstehen, sehen den Sinn.
Es geht hier um Kommunikation, wir reden mit den Leuten und auf einmal sagen alle “ja klar, gute Idee, machen wir”. Vorher hast Du nie darüber geredet. Die meisten Einwände gegen SCRUM bei uns im Team sind im Konjunktiv: “Der Kunde würde …”, “Wir könnten …” und was weiß ich alles. Aber hast Du mal einen Kunden gesprochen? Ruf doch mal an, sag ihm das mal und dann ist es immer anders.

Was ich sehr interessant finde, was du gerade gesagt hast, dass agil sozusagen das neue ISO 9000 ist. Man muss agil sein, um überhaupt als Geschäftspartner in Frage zu kommen. Was ist denn agil? Ist agil gleich Scrum? Ist Scrum eine Art agil zu sein oder wie verhält sich das?

Agil für Hardware ist so [Hände weit auseinander] und Scrum für Hardware ist so [Hände näher beieinander], also es ist nur ein Teil davon. Du kannst auch andere Sachen machen, dann bist Du noch agil. Nach außen branden wir uns als “Hardware Scrum”. Aber agil sind noch ein paar andere Sachen, z.B. schnell Feedback kriegen.

Auch ein Unterschied zum Werkvertrag: Wir formulieren die Funktionalität des gewünschten Produktes in lauter einzelne Funktionalitäten, die muss der Kunde dann erstmal nach Wert für ihn sortieren, was vorher im Lastenheft nie passiert ist, das stand alles in einem Dokument. Und wir packen dann daran eine Komplexität, die schon in Richtung Aufwand deutet. Dann kannst Du zum ersten mal sagen “diese Funktionalität, dieser Aufwand”. Dann kann der Kunde entscheiden: “Diesen Kikifax, ich weiß gar nicht, wer das da rein geschrieben hat, das interessiert mich echt nicht, dafür soll ich jetzt 15k Euro auf den Tisch legen? Hab ich gar keine Lust zu”.

Vorher kriegte er ein Pflichtenheftheft, da steht alles drin und er kriegt einen Gesamtpreis, aber niemand weiß, was jeder einzelne Funktionalität darin kostet. Das ist ein großes Problem.

Und wie entstehen Lastenhefte (die Vorlagen für die Pflichtenhefte)? Jeder im Unternehmen schreibt rein, was er kann, damit er bloß nicht später Ärger kriegt, dass er irgendwas vergessen hat. Also kriegst Du häufig mal ein mega-aufgeblasenes Dokument, wo Quatsch drin steht, den kein Mensch braucht. Da stehen natürlich auch noch Sachen drin, die man wirklich braucht, aber das meiste davon steht bloß drin, weil sich irgendwer absichern will. Was eigentlich nie drin steht, sind Infos wie “Wie sieht ein Anwender aus?”, “Wozu brauchen die Anwender das?”.

Dann schätzen wir das und dann gibt es einen Gesamtpreis für das zu diesem Zeitpunkt noch nicht vom Anwender betrachtete Werk. Und so entscheidet man dann, ohne die Kosten für jede einzelne erdachte, aber nicht mit Anwendern besprochene Funktionalität zu kennen, ob die Gesamtsumme in die eigenen Planungen passt oder nicht.

Wenn die Kunden wüssten, welchen Aufwand die gewünschten Funktionalitäten erzeugen,würde das alles vereinfachen. Es zwingt die Kunden darüber nachzudenken, was sie eigentlich wollen. Und dann wie gesagt schnell Feedback sammeln mit den Anwendern, denn eigentlich bestimmen die die Funktionalität, die sie brauchen.

Wir trennen übrigens, seit wir uns mit SCRUM beschäftigen, ganz stark zwischen Kunde und Nutzer.

SCRUM Board alpha-board

Was sind denn deine Erfahrungen damit so eine Organisation in diese Richtung zu bewegen?

Schlimm. [lacht] Das ist ja jetzt der dritte Anlauf. Das läuft jetzt seit ca zweieinhalb Jahren.
Der erste Anlauf war vor drei oder vier Jahren und da ist mir klar geworden, da wehren die Leute sich dagegen, da gibt’s hier nur Krieg.

Aber warum eigentlich?

“Der Prophet gilt nix im eigenen Land”.

Dabei sind die einzigen, für die SCRUM was verschlechtert, Leute in mittleren Positionen, die sich eigene Machtbereiche gesichert haben, zum Beispiel als Mini-Abteilungsleiter. Oder jemand ist der Einzige im Unternehmen, der was Bestimmtes kann, der ist sozusagen ein Flaschenhals aufgrund seiner Expertise. Und kann damit alle anderen erpressen und kann machen, was er will. Diese Leute leiden natürlich unter Scrum, denn Scrum möchte, dass das ganze Team zusammenarbeitet. Idealerweise ist dann irgendwann dieses Flaschenhalswissen keines mehr, denn die sitzen dann immer daneben und sehen was Du machst.

Erfahrene Scrumer, musst Du dir vorstellen, haben ein T-Profil. Also eine Expertise, die richtig tief reicht. Bei allen anderen Sachen haben sie oben einen fetten Balken, blicken also ein bisschen durch bei ganz vielen Sachen. Immer wenn wir einen Flaschenhals identifizieren, dann sagen wir: Das muss jetzt “gepairt” werden, der muss mit jemand anders zusammen den Job machen. So lernen andere, was es da zu tun gibt, und das Team kann einige dieser Dinge oder einen Teil dieser Dinge künftig selber machen.

Also der erste Anlauf war vor vier Jahren und da war “der Prophet gilt nix im eigenen Land”. Ich musste warten bis ich einen Agenten habe, der das für mich ändert. Dann war ein Typ von uns auf einer Projektmanagement Schulung, kommt zurück und verkündet mir, er weiß wie wir es retten, die Welt verbessern, und sagt “Scrum!” und ich endlich “Ja, da ist er!”.

Dann haben wir es eingeführt, alle auf Schulung geschickt und auch Fortschritte gemacht. Dann ist er aber vier Monate später gewechselt, da kam ein Startup. Und genau deswegen weil er eben eine Ausbildung hatte und Erfahrungen darin, haben sie ihm das doppelte Gehalt geboten. Da war er wieder weg und dann haben wir hier sozusagen abgebaut, es blieben nur noch Reste übrig..

Ein Artikel, den ich damals über SCRUM für Hardware schrieb, hat sehr viel Aufmerksamkeit erzeugt. Viele Berater sprachen uns an, Zeitschriften etc. Und irgendwann haben wir mit einem dieser SCRUM-Coaches gesagt, wir ziehen das jetzt nochmal durch und führen SCRUM ohne Rücksicht auf Verluste komplett bei uns ein. Aufgesetzt haben wir das mit Boris Gloger, Deutschlands bekanntestem SCRUM-Autoren. Umgesetzt hat es bei uns Marcus Stadelmeier, aus dem Team von Boris Gloger. Mein Dank an beide!

Und dann haben wir gemeinsam so stark die Weichen gestellt, dass es jetzt schwieriger ist zurückzufallen, als bei SCRUM zu bleiben. Wir sind jetzt über die Wasserscheide drüber sozusagen.. Aber trotzdem ist es ein Kampf, manche Sachen laufen auch noch nicht so.

Wir haben hinten ein Team, das will noch nicht Scrum oder wollte das von Anfang an nicht, die arbeiten jetzt mit Kanban. Die lassen wir in Ruhe. Und demnächst, wenn wir im vorderen Team nachweisen können, dass wir dramatisch schneller sind, werden die auch folgen, denke ich mal. Schon jetzt sind sie von deutlich kritisch zu leicht positiv umgeschwenkt in ihrer persönlichen Einstellung dazu. Aber ansonsten, jeder Change, jede Veränderung im Unternehmen erzeugt hier Spannungen. Und auch in dem SCRUM-Team musst Du ja dann erstmal diese Phasen durchlaufen “Forming”, “Storming”, “Norming”, “Performing”.

Wie lange ist es her, dass ihr damit angefangen habt?

Zehn Wochen. Nach einem halben Jahr müssen wir definitiv besser sein. Ich finde, wir sind noch nicht dramatisch besser geworden. Wir haben nur mehr Fokus in der Arbeitsweise.

Aber da sind noch keine sozusagen “unsichtbaren Effekte” entstanden. Weil sich das Team irgendwann schlauer organisiert, was Du von oben garnicht machen kannst, von außen. Das müssen sie selber machen.

Und wenn jetzt in der neuen Scrum Welt etwas schief läuft: Was läuft da schief? Auf welche Art und Weisen gehen dann da Dinge schief?

Wir haben derzeit Schwierigkeiten, wie wir unsere Sprints befüllen. Das liegt am Zerlegen in kleine Aufgaben, an den Schätzungen und an Abhängigkeiten von außerhalb des Teams. Wie wir das genau machen müssen, lernen wir schon noch. Derzeit iterieren wir da etwas.

Schwer fällt uns auch das Pairen, also dass immer zwei Leute gleichzeitig an derselben Aufgabe arbeiten. Das erhöht die Qualität, verbreitet Wissen über Software, Best Practice und die Kundenproiekte. Es erhöht das gemeinsame Verständnis, aber es fühlt sich manchmal einfach komisch an.

Wir wissen noch gar nicht, wie automatisches Testen aussehen soll. Bei Software gibt’s das und es merzt Fehler aus und gibt den Programmierern Sicherheit (und spart Zeit). Bei Hardware ist es nicht so einfach. Aber wir sind dran an diesen Themen.

Wir kommunizieren in festgelegten, quasi ritualisierten Terminen im Team, mit dem Product Owner und anderen Leuten aus der Firma. Mit den Kunden kommunizieren wir intensiver als früher und viel zeitnäher. Mit Anwendern noch nicht so oft, wie wir uns das wünschen, weil unsere Kunden uns oft nicht an die Anwender ran lassen.

Wenn man dann viel mehr kommunizieren muss, dann verändert sich vielleicht irgendwann das Anforderungsprofil an die Entwickler. Vielleicht müssen das ja kommunikationsstärkere Menschen sein? Würdest Du das so sehen, braucht man neue Personen, andere Rollen?

Nein, ich glaube das können die. Denen wird auch viel klarer, was sie kommunizieren sollen, damit es klappt.

Am Anfang saßen unsere Ingenieure da und wollten nicht planen. “Warum sollte ich denn was auf einen Zettel schreiben, das kostet ja Zeit.” Da haben wir darauf hingewiesen, dass man so im Team und außerhalb besser sieht, wie viel noch zu erledigen ist und wo man helfen kann. Und jetzt machen sie das.

Scrum ist, wie wenn Du eine Mauer um den Kindergarten baust und dann dafür sorgst, dass sie in dem Kindergarten alle erwachsen werden.

Super. Schönes Schlusswort. Danke.

Gregor Gross

Gregor Gross arbeitet seit 2005 bei alpha-board GmbH.
Seit 2008 ist er Geschäftsführer.

Share

Leave a Comment

Your email address will not be published. Required fields are marked *