Immer wieder stelle ich fest, wie schwierig es ist Menschen in meinem Umfeld zu erklären, was wir bei den Ninjaneers eigentlich tun. Software zu programmieren ist schon für sich alleine genommen ein komplexes Thema - zumindest wenn man dabei versucht zu erklären, auf was man als guter Entwickler achten sollte. Wir entwickeln Software darüber hinaus ja nicht für uns selbst oder zum Spaß sondern für Dritte. Im Folgenden möchste ich dich einladen, einen Blick in unsere Welt zu werfen um der Frage nachzugehen: Was bedeutet “Softwareentwicklung im Kundenauftrag”?
Es mag trivial klingen ist aber wichtig: Softwareentwicklung im Kundenauftrag bedeutet natürlich, dass die Kunden entscheiden, was entwickelt werden soll. Das stellt vor allem für kleine Unternehmen eine Herausforderung dar. Alle Welt spricht von Industrie 4.0, der Digitalisierung im Mittelstand und dem Internet of Things - aber nicht jeder ist plötzlich IT-Experte. Die formalen Prozesse aus der klassischen Softwareentwicklung wirken zusätzlich abschreckend. Dadurch sind kleine Unternehmen oft zögerlich auf Dienstleister wie uns zuzugehen.
Nach unserem Empfinden ist die Größe einer Firma nicht relevant. Auftraggeber und Dienstleister müssen vom Mind Set zusammenpassen, dann steht einer für alle Beteiligten zufriedenstellenden Zusammenarbeit nichts im Wege.
Besonders bei Beauftragungen mit geringem Umfang ist es wichtig wenig Zeit für Formalien zu verwenden. Traditionell beschreibt ein Auftraggeber präzise und vollumfänglich in einem Lastenheft was genau er produziert haben möchte. Hierauf gibt der Auftragnehmer in Form eines Pflichtenhefts ein Angebot inklusive Preis ab. Das alleine kann Tage oder Wochen dauern ohne das effektiv irgendetwas passiert. Die investierte Zeit (und üblicherweise einen Risikoaufschlag von 30%) muss der Auftragnehmer letztlich in sein Angebot einpreisen. Für eine kleine Firma ist das Budget damit häufig schon erschöpft bevor es losgeht.
Darum arbeiten wir gerne nach einem unkomplizierten, agilen Prozess wie zum Beispiel Scrum. Vertrauen und geringes Risiko für alle Beteiligten treten an die Stelle von Formalien und Rahmenverträgen. So können wir zügig mit der eigentlichen Arbeit beginnen. Was bedeutet das nun konkret?
Die Grundidee ist das Projekt zusammen mit dem Kunden in kleine, überschaubare Aufgaben (sog. Stories) zu unterteilen. Die Aufgaben werden - wieder zusammen mit dem Kunden - priorisiert und ihr Umfang grob geschätzt. Aus den wichtigsten Aufgaben wird ein Arbeitspaket (der Sprint) gebildet und mit einem maximalen Budget beim Dienstleister beauftragt. Wenn der Sprint abgeschlossen ist wird das fertige Ergebnis präsentiert und abgenommen. Hier ist fair play gefragt: Abgerechnet wird nur, was an Arbeit geleistet wurde. Im Gegenzug sollte der Auftraggeber Verständnis dafür haben, wenn die Aufwandsschätzungen am Anfang noch nicht präzise sind und in den ersten Sprints nicht alle Stories fertig werden. Scrum ist immer auch ein Lernprozess. Je länger das Team an einem System arbeitet desto besser werden die Schätzungen.
Größte Vorteile:
Wir wurden Ende 2016 von einer kleinen Agentur kontaktiert deren Geschäft das Verfassen hochwertiger Presseartikel ist. Dafür kam eine ältere Individual-Software zum Einsatz, die eine Reihe von Problemen zeigte. Nach einem kurzen Telefonat bin ich zum Kunden gefahren, habe mir das System erklären lassen und einen ersten Blick auf den Code geworfen. Zusammen mit den beiden Inhabern haben wir die dringendsten Aufgaben erarbeitet und priorisiert. Wir haben uns schnell darauf geeinigt, dass wir zuerst ein Problem mit dem Email-Versand angehen und anschließend weiter sehen. Nach insgesamt zwei Tagen (inklusive Vorbesprechung, Einarbeitung, Dokumentation etc.) konnten wir eine korrigierte Version auf dem Produktivsystem bereitstellen. Mit dem verbliebenen Budget haben wir - in einem zweiten “Mini-Sprint” - noch ein paar weitere Verbesserungen umsetzen können und der Kunde war zufrieden.
Wir arbeiten mit diesem Prozess aktuell erfolgreich mit mehreren mittelständischen Unternehmen aus dem Großraum Kassel zusammen und bekommen überwiegend positives Feedback.
Sehr häufig unterstützen wir bestehende Teams innerhalb von Firmen aus ganz Deutschland. Gründe hierfür sind meistens personelle Engpässe, Zeitdruck oder der Bedarf an speziellem Know How. Einige Unternehmen beschäftigen auch einfach ein Kontingent an externen Kräften um flexibel reagieren zu können. Neben den technischen Herausforderungen durch unvertraute Prozesse, neue Frameworks, spezielle Werkzeuge oder Programmiersprachen spielt auch hier die menschliche Komponente in wichtige Rolle. Den weltfremden Keller-Hacker mit Angst vor Sonnenlicht und fremden Menschen findet man bei uns daher nicht ;-)
Welche Rollen wir in einem Team letztlich ausfüllen richtet sich dabei nach den Bedürfnissen des Kunden. Meist arbeiten wir auf technischer Ebene als Softwareentwickler, mal behalten wir als Proxy für den Product Owner die fachlichen Anforderungen im Blick und koordinieren die Kommunikation zwischen der Fachabteilung oder Kunden und dem Entwicklerteam. Wir fördern als Scrum Master den Entwicklungsprozess als Ganzes oder unterstützen beim Aufbau einer Continuous Integration Infrastruktur für die automatisierte Qualitätssicherung. Je nachdem wie offen der Kunde hierfür ist bieten wir immer auch Wissentransfer und konstruktives Feedback an.
Die größte Herausforderung ist es natürlich eine neue Unternehmung von der frühen Gründungsphase bis zur Marktreife zu begleiten. Im Prinzip ist der Prozess dem für die Anpassung von Software im Kleinen sehr ähnlich nur mehrschichtig.
Am Beginn steht immer die fachliche Analyse des Konzepts; also die Frage: Was will der Kunde eigentlich am Ende erreichen? Als Ergebnis hiervon entsteht eine für alle Beteiligten verständliche Beschreibung des Produkts und ein paar Prozessskizzen. Zusätzlich validieren wir die technische Seite und unterstützen beim Erstellen von Szenarien. In dieser Phase muss auch die Frage gestellt werden ob das Projekt überhaupt ökonomisch tragfähig sein kann.
Seit unserer Gründung hat sich mehrfach die Möglichkeit geboten gemeinsam mit anderen Gründern ein Unternehmen auf die Beine zu stellen. Dabei waren ein paar Geschäftsideen die uns begeistert haben und GründerInnen, mit denen wir mit Freude zusammen gearbeitet hätten. Leider überstehen viele dieser Ideen die Machbarkeitsphase nicht. In einem Fall haben wir eine Gründerin mit einer tollen Idee kennengelernt und ihr angeboten die Idee als Joint Venture umzusetzen. Leider hat sich im Verlauf der ersten Treffen herausgestellt, dass sich mit der Idee wohl auf Jahre hinaus nicht genug Geld verdienen lässt um auch nur eine Person davon zu bezahlen.
In zweiten Fall kam ein Gründer auf uns zu dessen Idee uns ebenfalls begeistert hat. Im Rahmen der Marktanalyse für den Businessplan sind wir auf ein starkes Konkurrenzprodukt gestoßen, das trotz technisch guter Umsetzung und exzellentem Marketing keinen Erfolg hat. Frei nach Einstein wäre es in diesem Fall Wahnsinn nochmal das Gleiche zu tun und auf ein anderes Ergebnis zu hoffen.
Zu guter Letzt sind wir einem jungen Gründerteam empfohlen worden, dass eine B2B-Software entwickeln und vermarkten will. Wir befinden uns momentan am Übergang von der Machbarkeitsphase zur Entwurfsphase und es sieht soweit sehr gut aus! :-D
Wenn sich die Beteiligten einig sind, was das Ziel der Unternehmung ist und dass der Machbarkeit nichts grundsätzliches entgegen steht, geht das Projekt in die Entwurfsphase. Der Übergang ist natürlich fließend. Trotzdem ist es gut einmal deutlich zu sagen: Dies wollen wir machen und wir glauben alle daran, dass es ein Erfolg werden kann!
In dieser Phase geht es darum die Architektur der Software zu entwerfen und das System grob in funktionale Komponenten zu unterteilen. Als Daumenmaß gilt: Zwei Komponenten sind wahrscheinlich zu wenig, zwanzig sind zu viele. Auch hier stehen noch die fachlichen Prozesse im Zentrum aber es darf auch schon ein wenig über Technik gesprochen werden. Die Ergebnisse der Entwurfsphase sollten sich noch als Präsentation darstellen lassen.
Wie schon im letzten Absatz gesagt gilt: Die Trennschärfe zwischen den Phasen ist nicht 100%ig. Natürlich hat man schon während der Machbarkeitsphase einen groben Zeitplan vor Augen und diesen beim Architekturentwurf um erste Meilensteine ergänzt. Um sich nicht zu früh festzulegen und durch technische Fehlentscheidungen langfristig gebremst zu werden gilt: Erst jetzt wird entschieden, wie etwas gemacht wird.
Im Rahmen der Grobplanung werden die Komponenten genauer ausdefiniert, Prozesse detaillierter beschrieben und Szenarien durchgespielt. Was hängt wie zusammen? Gibt es funktionale Abhängigkeiten? Parallel werden die funktionalen Komponenten priorisiert: Was muss vorhanden sein, um überhaupt mit dem System arbeiten zu können? Welche Komponenten versprechen das beste Kosten-Nutzen-Verhältnis? Was macht das System einmalig und was ist zwar sexy aber nicht notwendig? Nach dieser Triage werden die Komponenten mit der höchsten Priorität in Stories unterteilt und damit das Backlog - die Liste aller offenen Aufgaben - gefüllt. Im Fokus steht hier ganz klar das Minimum Viable Product.
Im Prinzip ist egal ob jetzt Scrum, Kanban oder ein anderer Projektmanagementprozess zum Einsatz kommt. Wichtig ist was am Ende dabei heraus kommt. Der große Vorteil der agilen Methoden ist, das sehr schnell erste Ergebnisse vorliegen. Dabei ist regelmäßiger Kontakt zwischen dem Entwicklerteam und dem Product Owner sehr wichtig um das Ziel im Blick zu behalten! Und dieses Ziel darf sich gerne bewegen. Die Stories im Backlog dürfen verändert, ergänzt, umpriorisiert oder entfernt werden - einzig die Stories im aktuellen Sprint sind tabu.
Wir beraten und unterstützen unsere Kunden auch bei der Bereitstellung der Software. Wenn möglich etablieren wir eine Plattform für automatisiertes Testen (Continuous Integration) und automatisierte Bereitstellung (Continuous Delivery). Schließlich sollen neue Funktionen und Features möglichst schnell zur Verfügung stehen und gleichzeit sichergestellt werden, dass alles korrekt funktioniert!
Ich hoffe, dass dieser Einblick in unsere Arbeit dabei geholfen hat zu verstehen, was wir tun und wie wir arbeiten. Für Fragen rund um das Thema stehen wir natürlich gerne zur Verfügung - egal ob Online oder Offline in unserem Büro im Science Park Kassel.
Dirk Rühl hat uns im September 2016 in seine Radiosendung Das Leben ist kein Parkplatz eingeladen. Den Mitschnitt der Sendung gibt es auf seiner Homepage.
Im November 2016 hatten wir ein schönes Video-Interview mit Britta und Jonas von Just Startup.
Anfang 2017 habe ich mit Hendrik Klöters im Unternehmerkanal über das Thema IT-Dienstleister gesprochen.
Bild Gezeichneter Pfeil, Diskussion, Scrum Board, Roter Pfeil – Public Domain (CC0)
Bild UML – Urheber „MetaMarph“, Wikimedia Commons (CC BY-SA 3.0)
14 Mar 2017 #Software #Scrum #Produktentwicklung #Agil #Team #Gründer
