Sutherland und Schwaber
Agiles Arbeiten und feste Spielregeln erscheinen auf den ersten Blick als Widerspruch. Doch das in den 90ern entwickelte und kürzlich aktualisierte Scrum-Framework von Jeff Sutherland und Ken Schwaber beweist das Gegenteil: Agiles Arbeiten im Team wird dann am effektivsten, wenn es klar umrissenen Regeln folgt.
Was ist Scrum?
Scrum und agiles Arbeiten sind zumindest in der Produktentwicklung keine neuen Begriffe mehr. Schon in den frühen 1990er Jahren formulierten Jeff Sutherland und Ken Schwaber ein erstes Scrum-Konzept, das bis heute hauptsächlich in der Softwareentwicklung und im Produktmanagement Anwendung findet. In ihrem 2017 veröffentlichten Scrum Guide definieren sie Scrum als „[a] framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value“. Es handelt sich um eine konkrete Umsetzung der Philosophie des agilen Arbeitens, bei der es darum geht, so effektiv, flexibel und kreativ wie möglich an einem Produkt zu arbeiten, um am Ende das bestmögliche Ergebnis zu erzielen. Anstatt ein festes langfristiges Ziel zu verfolgen, soll durch kurze Entwicklungszeitfenster und ständige Reflexion optimal auf Marktveränderungen und sonstige Problemstellungen reagiert werden.
Eine detailliertere Definition liefert der zuvor zitierte Scrum Guide von Jefferson und Schwaber. Sehr anschaulich wird das Framework auch in diesem Video des Unternehmens Organize Agile erklärt. (© Youtube)
Wie funktioniert Scrum?
Damit das Framework funktioniert, gibt es klar umrissene Rollen, Zeitfenster (Time-Boxing) und Prozesse, die auf alle produktorientierten Vorgänge übertragbar sind. So ist es die Rolle des Product Owners, die Entwicklung des herzustellenden Produkts zu überblicken und das sogenannte Product Backlog – eine Liste der Anforderungen an das Produkt – zu formulieren. Diese Anforderungen muss das Development Team, eine kleine Gruppe unterschiedlich spezialisierter Fachleute, während eines Sprints, der in der Regel höchstens einen Monat dauern soll, bestmöglich umsetzen. Dabei geht es nicht darum, sofort das perfekte Ergebnis, sondern innerhalb kürzester Zeit das bestmögliche Inkrement – sprich: die nächsthöhere Produktstufe – zu erzielen. Grundgedanke dieser Vorgehensweise ist es, immer eine Version des Produktes zu haben, die in irgendeiner Form fertig (done) und funktionsfähig ist. Dazu formuliert das Development Team während des Sprint Plannings ein Sprint Backlog mit den während des kommenden Sprints zu realisierenden Elementen des Product Backlogs. Der Fortschritt wird täglich im Daily Scrum reflektiert. Im anschließenden Sprint Review präsentiert das Development Team ihr Ergebnis dem Product Owner, der das Produkt neu bewertet und das Product Backlog aktualisiert. Die abschließende Sprint Retrospektive dient dem Development Team dazu, ihre Vorgehensweise während des vergangenen Sprints zu reflektieren und ggf. anzupassen, bevor der nächste Sprint beginnt. Die dritte Instanz des Scrum Teams ist neben dem Product Owner und dem Development Team der Scrum Master, der die Umsetzung und Funktionsweise des Frameworks überwacht und den anderen Teammitgliedern in Sachen Scrum beratend zur Seite steht.
Zusammenfassung: Scrum ist nicht nur ein Framework für effektives Arbeiten in der Produktentwicklung, sondern hat als konkrete Umsetzung der agilen Arbeitsphilosophie darüber hinaus das Potential, ergebnisorientiertes Teamwork in allen Bereichen zu revolutionieren. Natürlich müsste die Umsetzbarkeit dieses speziellen Frameworks in anderen Bereichen erst erprobt und ggf. angepasst werden. Aber Scrum zeigt: Ein klar umrissener Fokus, feste Zeitspannen und Prozesse sowie festgelegte Rollenverteilungen ermöglichen eine umso flexiblere, aktivere und effektivere Arbeitsweise in der Gruppe. Genau das praktizieren wir in unseren Workshops bei CONNECTINGSCIENCE.