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.
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.
Fremdwörter? Kurz und knapp!
Agile Methoden zeichnen sich durch selbstorganisierende Teams aus. Dies führt zu mehr Selbstvertrauen im eigenen Handeln. Dadurch kann man zusammen flexibel auf veränderte Anforderungen des Kunden reagieren. Offene Kommunikation und Wissensaustausch stehen im Vordergrund. Es wird immer nur das Wesentliche für ein funktionierendes Produkt umgesetzt.
Scrum ist eine agile Methode für das Projektmanagement. Ein Projekt wird immer nur für 2-4 Wochen schrittweise zusammen mit dem Kunden geplant und in diesem Zeitraum in kleineren Aufgaben abgearbeitet und fertig gestellt. Danach wird der nächste Schritt geplant, abgearbeitet und fertig gestellt.
XP oder Extreme Programming funktioniert ähnlich wie Scrum. XP macht allerdings enge Vorgaben für die Qualitätssicherung professioneller Software-Entwicklung.
Kanban ist eigentlich keine agile Methode und dient hauptsächlich zur Optimierung des Workflows der Arbeitsschritte. Aus diesem Grund findet Kanban auch Anwendung bei nicht projektbezogener Arbeit.
Im Folgenden werden SXK-Techniken und Abweichungen zu Scrum erklärt:
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.
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.
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.
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.
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.
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.
Scrum ist eigentlich ganz einfach. Natürlich kann man sich ganz viele Bücher dazu durchlesen, aber man sollte neben diesen Regeln und Schritten Scrum ganz pragmatisch angehen und einfach anwenden. Zusätzlich sollte man sich noch mal das Agile Manifest zu Gemüte führen. Ein Team kann nur stark sein, wenn man Mitmenschen und Kunden respektiert.
Damit ein Projekt überhaupt in Angriff genommen werden kann, muss dieses vom Product-Owner, dem Planer, geplant werden. Dieser ist gleichzeitig Fach-Experte und hat das Ziel, die Kundenwünsche zu erfüllen. Für das Einhalten der agilen Regeln ist der Sozialarbeiter zuständig. Oft wird dieser auch Scrum-Master genannt. Er kümmert sich um das Team und ist kein Projektleiter. Das Team darf selbstständig agil entscheiden und erfüllt somit zusammen die Rolle eines Projektleiters. Das Team selbst ist für die Umsetzung des Produktes zuständig. Eine Rolle darf nicht doppelt besetzt werden.
