Um den Kunden herum organisieren wir ein eigenes Entwicklungsteam mit einer fachlichen und einer technischen Leitung. Dabei arbeiten wir agil - Scrum, Kanban, Pair & Extreme Programming und Test Driven Development sind unsere Werkzeuge. Wir entwickeln Software eher als langfristig laufende Produkte denn als kurzfristige Projekte und arbeiten lange mit unseren Kunden zusammen.

Unser Vorgehen

arbeitsweise-briefing-und-entdeckungsphase

1. Briefing- und Entdeckungs­phase - Sich kennenlernen

Zu Beginn einer neuen Produktentwicklung geht es darum, den Kunden kennen zu lernen. Wir wollen alles verstehen: Geschäftssituation, die Pläne und Vorstellungen des Kunden, die Kunden des Kunden, die Marktstrategie, die Systemlandschaft. Jede Kundenwelt hat ihre eigenen Begriffe, und das ganze Team versucht, diese neue Sprache zu erlernen. Wir wollen verstehen, was unser Kunde will. Welches sind die Probleme, die er lösen möchte? Welches sind die Kriterien, die uns von einem Erfolg sprechen lassen? Wir nennen das Domänenwissen.

arbeitsweise-rebriefing-und-auftakt

2. Rebriefing und Auftakt - Auf den Punkt bringen

Die Ergebnisse der Entdeckungsphase werden in einem Workshop präsentiert. Wir stellen dar, was wir verstanden haben, welche Modelle und Prozesse zu erkennen sind. Wir beschreiben, was wir in den Lösungsprozess einbringen können und wo wir Risiken sehen. Als Auftakt der gemeinsamen Arbeit erstellen wir, gemeinsam mit dem Kunden, eine lange Liste von Stories - das Backlog. Diese Stories skizzieren in einem ersten Bild unseren Weg zur Lösung. Die gemeinsame Arbeit am Backlog wird uns in dem gesamten Prozess begleiten.

arbeitsweise-iterieren

3. Iterieren - Die Implemen­tierung beginnt

Mit den Ergebnissen des Workshops starten wir die Implementierung. Wir haben uns auf eine Timebox festgelegt (zwei, drei oder vier Wochen) und abgestimmt, was wir in dieser Zeit erledigen wollen. Wir nennen solch eine Timebox Sprint. Am Ende des Sprints kommen wir zusammen, führen vor, was wir geschafft haben und planen gemeinsam mit dem Kunden den nächsten Sprint. Und das machen wir wieder und wieder, bis die neue Software live geht. Der Kunde weiß genau, wie weit wir sind, er sieht am Ende der Timebox den echten Stand. Wir wissen genau, wo wir in die richtige Richtung gehen und wo wir korrigieren müssen. Wir bekommen am Ende jedes Sprints echtes Feedback zum gemeinsamen Produkt.

arbeitsweise-live

4. Live - Das Leben ist nicht zu Ende

Mit dem Livegang eines Vorhabens ist die Entwicklung nicht zu Ende. In aller Regel geht es jetzt erst richtig los. Wir wollen mit dem Kunden gerne so früh wie möglich live gehen. So wie uns das echte Feedback unseres Kunden hilft, hilft unseren Kunden das frühe Feedback ihrer Kunden. Mit dem Livegang hören die Anforderungen an die Software nicht auf, aber sie verändern sich. Wir setzen die Sprints mit dem Kunden fort, um all die neuen Anforderungen umzusetzen, die bei der Weiterentwicklung des Produktes jetzt entstehen.

Smarte Leute in selbstorganisierten Teams, manchmal unbequem, nicht nur Lieferanten, sondern Partner unserer Kunden, davon überzeugt, dass das, was wir tun, einen Unterschied macht: das ist unser Erfolgsrezept bei der Produktentwicklung.

Werkzeuge

Unser Prozess funktioniert, weil er aus vielen kleinen Werkzeugen besteht, die wir zu einem Ganzen zusammensetzen und für jeden Kunden individuell anpassen.

scrum-prozess

Scrum

Scrum ist eine agile Arbeitsweise und basiert auf der Annahme, dass Entwicklungsprojekte oftmals zu umfangreich sind, um von Anfang an komplett durchgeplant zu werden. Bei Scrum wird in zwei- bis vierwöchigen Iterationen geplant, sodass Anpassungen an die Anforderungen weiterhin möglich sind. Durch die ständige Auslieferung lauffähiger Software sind Zwischenergebnisse jederzeit für alle Parteien zugänglich. Jeden Tag stecken wir die Köpfe zum sogenannten Daily Scrum zusammen und halten uns gegenseitig auf dem Laufenden. Alle Anforderungen an das Produkt werden in einem Produktbacklog gesammelt und priorisiert.

kanban-board

Kanban

Im laufenden Betrieb einer Plattform, in dem jeden Tag Neues passiert, setzen wir auf Kanban - eine Technik aus dem Toyota-Produktionssystem.
Alle Aufgaben werden in einem Backlog gesammelt und laufend abgearbeitet. Dabei gibt es keine Iterationen wie beim Scrum. Es gibt eine Limitierung von Aufgaben, die sich in Arbeit befinden dürfen. So wird sichergestellt, dass offene Aufgaben abgeschlossen werden, bevor wir neue beginnen. Das ganze visualisieren wir in Form von Boards. So kann jeder sehen, wer an welcher Aufgabe arbeitet und wie viele Aufgaben noch offen sind.

pairprogramming

Pair Programming

Vier Augen sehen mehr als zwei. Einer programmiert, während der andere über den generierten Code schaut und Fehler direkt bemerkt. Hin und wieder machen wir uns das sogenannte Pair Programming zu Nutze und verteilen unser Wissen so besser in den Teams. Der geschriebene Code ist qualitativ hochwertiger und oftmals fehlerfrei. Davon profitiert der Kunde und wir natürlich auch.

tdd

Test-Driven Development

Wir arbeiten nach dem Prinzip "tests first". Zuerst wird der Test programmiert, bevor wir die Anforderung umsetzen. Danach programmieren wir drauf los, bis der Test nicht mehr fehlschlägt. Dieses Vorgehen nennt man TestDrivenDevelopment (TDD) oder zu deutsch: Testgetriebene Entwicklung. Das garantiert uns, dass jede Zeile Code, die wir programmieren, auch tatsächlich getestet wurde. Ein schöner Nebeneffekt dessen ist, dass kein Code auf Vorrat erzeugt wird, der die Anwendung nur unnötig aufbläht. Es wird nur so viel programmiert, bis der Test auf grün ist. Mehr nicht.

Retrospektiven

Unsere Arbeitsweise überprüfen wir in regelmäßigen Abständen in Retrospektiven. Dabei schauen wir nicht auf die Entwicklungsergebnisse, sondern darauf, wie unser Entwicklungsprozess läuft und wie wir als Team mit dem Kunden zusammenarbeiten. Die dabei erarbeiteten Verbesserungspotentiale fließen dann in die zukünftige Arbeit ein.