SXK

Scrum, Xp und Kanban

SXK ist ein gesunder Mix für die professionelle Software-Entwicklung im Team. SXK beseitigt lustlose und damit sinnlose Daily-Scrums, nicht funktionierendes Pair-Programming und stellt unterschiedliche Talente jedes Team-Mitglieds in den Vordergrund. SXK erweitert Scrum, indem es mit Kanban den Workflow optimiert und mit XP wichtige Praktiken der Software-Entwicklung einführt.

Mindset?

In der folgenden Beschreibung werden nur die Unterschiede von SXK zu Scrum erläutert, da SXK auf Scrum aufbaut und Methoden von XP und Kanban zusätzlich benutzt. Es wird nur auf die pragmatische Anwendung eingegangen und nicht auf ein sogenanntes Mindset. SXK hat das Ziel, dass sich das Mindset durch die Anwendung automatisch ergibt und man sich dieses nicht erst gläubig einbilden muss, wie bei den anderen Agilen Methoden. SXK baut Zusammenhänge zwischen den verschiedenen Methoden Scrum, XP und Kanban auf und gibt den Scrum-Regeln einen Sinn. Workflow und Techniken muss man neben diesen Regeln ständig optimieren und anpassen.

SXK Techniken

Im Folgenden werden SXK-Techniken und Abweichungen zu Scrum erklärt:

SXK-Workflow: Arbeitsschritte des Taskboards

Durch Kanban wird der Workflow in seine wichtigsten Schritte unterteilt. Kanban führt für bestimmt Schritte WIP "Work in Progress" ein. Dies limitiert die Anzahl der Tickets, die in einem Schritt bearbeitet werden dürfen. Die Anzahl ist flexibel und soll ein Aufstauen von Tickets verhindern. Mehrere Tickets können, wenn es Sinn macht, zu einem Epic zusammengefasst werden.

1. Product-Backlogs
2. SPRINT: ToDo
   1. Sprint-Backlog
   2. Return-Log: Manchmal müssen halbfertige Tickets wieder zurückgestellt werden.
3. SPRINT: In Progress
   1. Architektur [WIP: onGoing/Done]
   2. Unit-Test [WIP: onGoing/Done]
   3. Development [WIP: onGoing/Done]
   4. Code-Review & Refactoring [WIP: onGoing/Done]
   5. Test [WIP: onGoing/Done]
4. SPRINT: Done
   1. Done
   2. Inkrement Done: Hier kommen nur die Tickets hinein, die auch wirklich in das Inkrement kommen.
5. Fertige "Product Incremente"

Aufbau eines Tickets

1. User-Story: Mehrere User-Storys können auch als Epic-Ticket zusammengefasst werden.
2. Kompetenz-Gebiet
3. Art (Bug,Feature)
4. Min/Max Zeit
5. Zeit gebraucht
6. Prio
7. Status (ToDo,InProgress,Done)

Kompetenz-Gebiete im SXK

Im SXK ist es wichtig, dass jedes Team-Mitglied seine individuellen Talente und Kompetenz-Gebiete kennt. Ein einzelnes Kompetenz-Gebiet wird immer von 2 Team-Mitgliedern gepflegt, damit im Krankheitsfall jederzeit einer einspringen kann. Ein SXK-Team ist stark, wenn es viele unterschiedliche Persönlichkeiten mit verschiedenen Talenten gibt.

Wissens-Austausch und Pair-Programming im SXK

Pair-Programming ist eine XP-Arbeitstechnik, bei der 2 Entwickler immer an einem Computer arbeiten. Dies soll den Wissensaustausch im Team verbessern. Wenn der eine Entwickler eine lernende Rolle und der andere Entwickler eine lehrende Rolle einnimmt, kann dies Sinn ergeben. Viele Entwickler mögen allerdings das Pair-Programming nicht, weil sie dadurch weniger selbst entscheiden können und sich womöglich kontrolliert fühlen. Im SXK gibt es Kompetenz-Gebiete. Hierbei wird das Projekt in Kompetenz-Gebiete unterteilt. Da 2 Team-Mitglieder ein Kompetenz-Gebiet pflegen, wird ein einzelnes, kleines Aufgaben-Ticket im Kanban-Tandem-Workflow bearbeitet. So erstellt der erste Entwickler die Architektur oder den Unit-Test für die Aufgabe oder macht sich grob Gedanken darüber, worum es in der Aufgabe geht und schreibt diese mit seinem technischen Wissen ins Aufgaben-Ticket. Jetzt programmiert der zweite Entwickler diese Aufgabe nach seiner Vorstellung mit dem Wissen des Kompetenz-Partners fertig (...währenddessen programmiert der erste Entwickler an dem vorbereiteten Ticket des ersten Entwicklers!). Im letzten Schritt macht der erste Entwickler eine technische Qualitäts-Kontrolle. Beide Entwickler bearbeiten gleichzeitig immer alle Bearbeitungs-Schritte im Kanban-Tandem-Workflow, mit dem Unterschied, dass bei einer Aufgabe die Schritte abwechselnd zwischen den beiden Entwicklern hin und her geschoben werden. Dadurch tauschen beide Entwickler ständig Wissen aus und verbessern so die soziale Kommunikation.

Das perfekte Entwickler-Team

Jeder Mensch ist unterschiedlich und kein Entwickler kann alles. Auch ein Entwickler, der angeblich alles kann, ist in seiner Kompetenz begrenzt. Ein solcher Entwickler muss lernen, eine kontrollierende Rolle im Team einzunehmen, indem er Software-Architekt wird, eine vorausschauende, planende und kontrollierende Tätigkeit einnimmt oder andere Entwickler anleitet. Es werden auch immer mehr technische Product-Owner gesucht. Also Hardcore-Experten, die nur noch die Planung machen. Es gibt allerdings auch sehr fokussierte Nerds, die sich mit großer Leidenschaft auf die größten Probleme stürzen und keinen großen Wert auf den kommunikativen Austausch legen. Diese sollten sich besser selbstständig auf die Probleme konzentrieren. Als letztes haben wir die begeisterten Bastler. Ohne diese kann kein Projekt fertig gestellt werden. Auf diesem Gebiet hat der Experte oft seine Schwachstellen, da manchmal die Umsetzung wichtiger ist als ständiger Perfektionismus. Bei SXK muss nicht jeder Entwickler auch ein perfekter Software-Entwickler sein. Ein perfektes Entwickler-Team haben wir nur, wenn wir viele unterschiedliche Persönlichkeiten und Talente haben.

Kreative Ideen

Ein innovatives Team tauscht Wissen aus und spricht offen über Hindernisse im Projekt. Diese Ideen und Probleme werden auf einem öffentlichen (nicht digitalen) Ideen-Board auf einem Notizzettel festgehalten. Jedes Team-Mitglied hat ein eigenes Ideen-Board, so dass man beim nächsten Daily-Scrum sofort sehen kann, worüber man in den nächsten 15 Minuten reden könnte. Unausgesprochene Ideen werden ganz links festgehalten. In der zweiten Spalte werden die besprochenen Ideen festgehalten. In der dritten Spalte werden die "krummen" und vielleicht irrationalen Ideen manifestiert. In der letzten Spalte werden die Super-Ideen festgenagelt.

Planung im SXK

Im SXK ist das Planen durch den Product-Owner eine wichtige Aufgabe. Natürlich ist inzwischen allen in der Software-Entwicklung klar, dass es schwer ist, eine technische Spezifikation oder Kunden-Spezifikation im Voraus zu erstellen, die wirklich eingehalten wird. Allerdings spricht nichts dagegen, User-Stories oder eine Spezifikation im Voraus mit dem Kunden zu erstellen. Diese dient als roter Pfaden, damit das Projekt nicht vom Weg abkommt. Eine Spezifikation dient als Wissensgrundlage, da man in der agilen Software-Entwicklung in 2-4 wöchigen Schritten (Sprints) die Software plant und umsetzt. Ein Sprint hat immer 50% "Feature" und 50% "Bug+Nice to have". Dies soll sicherstellen, dass in einem Sprint immer alle "Features" erfolgreich abgeschlossen werden. Das Team wird sich freuen, wenn es frühzeitig alle Ziele erreicht hat und kann sich dann mehr um die Qualität der Software kümmern und zusätzliche sinnvolle Features implementieren. Ziel ist es, dass das Team stressfrei 100% Leistung erreicht durch Anspannung und Entspannung.