Ursprünglich stammt Scrum aus der Softwareentwicklung. Inzwischen gehört der Ansatz fest zur agilen Projektentwicklung und zum agilen Projektmanagement. Doch obwohl es bei Scrum keine ausufernde Konzeptphase gibt, ist das Vorgehen keineswegs planlos. In diesem Beitrag erfährst Du, was agile Projektentwicklung und agiles Projektmanagement mit Scrum ausmacht: Wichtige Rollen und Tools, die Umsetzung von Scrum in der Praxis, Scrum Vorteile und die Kostenkalkulation von Scrum Projekten.

Scrum: Agile Projektentwicklung aus der Softwareentwicklung

Projekte, die auf klassische Weise angegangen werden, stützen sich auf das Wasserfall-Modell. „Wasserfall“, weil Projektbeteiligte möglichst detaillierte Vorarbeiten mit genauen Arbeitsanweisungen erhalten. Beim Scrum Ansatz sieht das anders aus. Scrum Teams erhalten erst einmal nur genaue Zielvorgaben. Der Weg dorthin ist jedoch nicht definiert, sondern entwickelt sich innerhalb Teams während der Projektarbeit. Scrum ist also nicht planlos. Statt die Art der Umsetzung im Vorhinein angegeben zu bekommen, erarbeitet das Projektteam diese im laufenden Prozess. Gruppendynamik und stetig neue Erkenntnisse fließen so in die Projektentwicklung ein.

Was aber macht Scrum noch aus? Ursprünglich stammt Scrum aus der Softwareentwicklung. In dieser ist es üblich, ein Gesamtprojekt in kleinere Teilprojekte zu splitten. Der Scrum Ansatz nimmt genau dieses Vorgehen auf: Ein Gesamtprojekt, beispielsweise der Launch einer neuen Website, wird in kleinere „Häppchen“ aufgebrochen. Diese Teilprojekte werden nacheinander in Sprints umgesetzt. Das Ziel eines jeden Sprints ist es dabei, den darin bearbeiteten Teilaspekt des Projektes vollständig und funktionsfähig auszuliefern. In der Softwareentwicklung heißt das: Funktionsfähiger und qualitativ hochwertiger Code steht am Ende des Sprints zur Verfügung.

Bleiben wir bei dem Beispiel der Website, könnte das Endergebnis eines Sprints etwa die Website als zentrale Ausgangsseite der Internetpräsenz sein. Die Arbeit mit Scrum benötigt allerdings eines: Akzeptanz. Der Entwicklungsprozess ist nicht vorherzusehen und das muss von allen Projektbeteiligten akzeptiert werden. Wer Scrum als Ansatz für sein agiles Projektmanagement und die agile Projektentwicklung wählt, hat als oberstes Ziel, das bestmögliche Ergebnis unter Berücksichtigung von Kosten, Funktionalität, Zeit und Qualität zu erzielen – der Weg dorthin steht hinten an. Sie wollen mehr zum Einsatz von Scrum lesen? In unserem Beitrag erfährst Du, wie Marketeers Scrum erfolgreich einsetzen – und wann sie es besser lassen sollten.

Drei Prinzipien von Scrum

Der Scrum Ansatz charakterisiert sich durch drei einfache Prinzipien: Transparenz, Überprüfung und Anpassung. Bei der Transparenz gilt es, den Fortschritt, aber auch eventuelle Hindernisse, eines Projektes täglich und für alle sichtbar festzuhalten. Die Überprüfung erfolgt in regelmäßigen Abständen. Dabei werden Funktionalitäten, die das Produkt liefern soll, genauestens hinsichtlich ihrer Qualität beurteilt. Unter dem Prinzip der Anpassung versteht man bei Scrum, dass Anforderungen an das Produkt bzw. das Projektziel nicht ein für alle Mal im Vorfeld festgelegt werden. Mit jedem fertigen Sprint werden die Anforderungen neu bewertet und bei Bedarf angepasst. Wie Scrum die Projektarbeit beeinflusst, kann anhand des Agilen Manifests besser verstanden werden. 2001 haben IT-Verantwortliche zwölf Thesen zum Scrum-Ansatz verfasst, die die Kernaspekte widerspiegeln. Die Thesen sind natürlich auf die Softwareentwicklung bezogen, können aber ebenso auf andere Projekte anwenden. Wir haben die Inhalte der Thesen einmal allgemein für Projekte aller Art übersetzt.

12 Thesen zum Scrum Ansatz

1. Die höchste Priorität ist es, Kund:innen zufriedenzustellen, indem Produkte schnell und qualitativ ausgeliefert werden.
2. Änderungen von Anforderungen, die selbst in späteren Projektphasen entstehen, werden zum Wettbewerbsvorteil für die Kund:innen.
3. Ziel ist es, funktionierende Produkte bzw. Produktkomponenten in regelmäßigen und kurzen Abständen zu liefern.
4. Die Projektbeteiligten müssen während des Projekts täglich zusammenarbeiten.
5. Die Projektbeteiligten sollten alle motiviert sein. Gleichzeitig sollen sie das Umfeld und die von ihnen gewünschte Unterstützung erhalten. Ansonsten heißt es: Vertraue darauf, dass die Projektbeteiligten ihre Aufgabe erledigen.
6. Funktionierende (Teil-)Produkte sind das wichtigste Fortschrittsmaß eines Projektes.
7. Informationen innerhalb des Projekt-Teams zu teilen ist am effizientesten und effektivsten im direkten Gespräch.
8. Agile Prozesse fördern eine nachhaltige Entwicklung. Auftraggeber:innen und Projektbeteiligte sollten daher ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Agilität wird durch ein ständiges Augenmerk auf Funktionalität gefördert.
10. Einfachheit ist zentral. Getane Arbeit soll nicht maximiert werden.
11. Selbstorganisierte Teams schaffen den Raum für die besten Ergebnisse.
12. Das Team reflektiert in regelmäßigen Abständen, wie es Prozesse effektiver gestalten kann, und passt sein Verhalten darauf an.

Scrum Team – drei Rollen, drei Gruppen

Im Scrum Team übernehmen die Projektbeteiligten klassischerweise drei Rollen. Diese bestehen aus dem Product Owner, dem Scrum Master und dem Entwicklungsteam. Jede einzelne Rolle hat spezifische, ihr zugewiesene Aufgaben auszuführen. Hinzu kommen die drei Gruppen Customer, User und Management. Wichtig ist: Auch wenn es einzelne Rollen und Gruppen gibt, steht während des gesamten Projektes immer das komplette Scrum Team im Vordergrund. Dieses gewinnt zusammen und muss auch zusammen auf neu auftretende Herausforderungen reagieren.

Product Owner: Brücke zwischen Kund:innen und Scrum Team

Der Product Owner gibt die Anforderungen und die Projektstrategie mitsamt der Priorisierung von Anforderungen und Tasks vor. Anforderungen und Tasks werden von ihm mit dem Entwicklungsteam innerhalb des Product Backlog als User Stories abgestimmt und erfasst. Die User Stories beschreiben dabei die gewünschten und nötigen Funktionalitäten des Produkts aus Sicht der User. In den Aufgabenbereich des Product Owners fällt zudem die Überprüfung der Ergebnisse am Ende eines jeden Sprints. Er entscheidet über Features, Kosten und Auslieferungszeitpunkt des entwickelten (Teil-)Produkts. Er wird in der Regel vom Auftragnehmer gestellt und fungiert als Brücke zwischen dem Kunden (Customer) und dem Scrum Team.

Scrum Master: Administrator des Teams

Anders als der Product Owner arbeitet der Scrum Master als „Moderator“ des Scrum Projekts. Er verantwortet den Erfolg und führt Scrum Regeln für die Projektdurchführung ein. Der Scrum Master begleitet die Meetings und ist für das Scrum Team der erste Ansprechpartner bei auftretenden Herausforderungen im Scrum Prozess – beispielsweise Kommunikationsprobleme oder das Aufkommen neuer bzw. veränderter Anforderungen an das (Teil-)Produkt. Scrum Master arbeiten dabei zwar eng mit dem Entwicklungsteam zusammen, sind aber kein direkter Teil von diesem, sondern viel mehr die Führungskraft des Entwicklungsteams. Sein Schwerpunkt ist administrativer Natur. Wir zeigen Dir außerdem, warum agile Projekte einen Scrum Master brauchen.

Entwicklungsteam: Umsetzung des Projektziels

Die letzte Rolle im Scrum Team ist das Entwicklungsteam, das je nach Projektgröße meist aus fünf bis sieben Beteiligten besteht und sich selbst organisiert. Diese sind für die Entwicklung des Projektziels (z.B. ein Produkt) verantwortlich und setzt die im Product Backlog geforderten Anforderungen/ Funktionalitäten um. Dabei arbeiten sie interdisziplinär zusammen: Die Übernahme von Testaufgaben gehört ebenso zu ihrem Einsatzgebiet, wie die Entwicklung an sich.

Innerhalb des Scrum Prozesses übernimmt das Entwicklungsteam zudem im ersten Sprint die Überprüfung der gesetzten Anforderungen und diskutiert diese. Das Entwicklungsteam gibt geschlossen Rückmeldung an den Product Owner hinsichtlich der Umsetzung des ersten Sprints und darin enthaltenen Anforderungen. Gleichzeitig verpflichtet sich das Team, die selbst definierten Anforderungen auch zu erreichen, und erarbeitet gemeinsam detaillierte Umsetzungsmethoden. Die Anforderungen werden in User Stories vom Team festgehalten und in die einzelnen Tasks heruntergebrochen – wie oben erwähnt in Zusammenarbeit mit dem Product Owner.

Gruppen: Customer, User und Management

Die Gruppe der Customer umfasst den oder die Kund:innen des Scrum Teams. Der Customer steht im direkten Austausch mit dem Product Owner, nicht aber mit dem gesamten Scrum Team. Als User werden wiederum die späteren Anwender:innen des entwickelten Produkts bezeichnet. User können zugleich Customer sein, müssen es aber nicht. Die User sollten im Scrum Prozess vor allem beim Sprint Planning und den jeweiligen Reviews der einzelnen Sprints einbezogen werden. Denn sie beurteilen das entwickelte Produkt hinsichtlich Funktionalität, Qualität und Usability. Die letzte Gruppe im Scrum Team ist das Management. Dessen Aufgabe besteht darin, die Rahmenbedingungen für ein erfolgreiches Scrum Projekt zu schaffen. Das Management stellt die dazu notwendigen Ressourcen und Unterstützung des Scrum Teams bereit.

Ablauf eines Scrum Prozesses

  Ein agiles Scrum Projekt ist nicht planlos. Das zeigt sich auch wieder im Scrum Prozess selbst. Dieser teilt sich in verschiedene Phasen auf. Am Anfang steht der Product Backlog. Darauf folgen zwei Sprint Planning Meetings, bevor es an die Projektumsetzung innerhalb verschiedener Sprints geht. Hinzu kommen Daily Scrums als Kurzmeetings während der Sprints. Am Ende jedes Sprints erfolgt ein Sprint Review und die Retrospektive. Die einzelnen Projektfortschritt werden dabei in einem Burndown Diagramm festgehalten. Aber zuerst mehr zu den einzelnen Prozessabschnitten.

Product Backlog: Zentrales Element des Scrum Projektes

Der Product Backlog ist der Dreh- und Angelpunkt des Scrum Projektes. Hier werden die Anforderungen vom Product Owner festgehalten und priorisiert. Die Liste ist das Herzstück der Produktentwicklung, da sie alle Aspekte beinhaltet, die das fertige Produkt enthalten muss. Die Anforderungen werden User-orientiert in User Stories erfasst. Das Product Backlog wird im Verlauf des Scrum Projektes weiter vom Product Owner gepflegt und aktualisiert. Wie sieht eine ideale User Story eigentlich aus? Grundsätzlich beantwortet die User Story sieben Fragen: „Wer“, „was“, „wozu“, „wo“, „wann“, „wie“ und „warum“. Ein Beispiel zu den ersten drei Fragen: „Als User möchte ich diese Funktionalität, damit ich folgenden Nutzen habe“.

Sprint Planning Meeting 1: Vorstellung und Diskussion der Anforderungen

Der Product Owner stellt die Anforderungen aus dem Product Backlog dem Entwicklungsteam vor. Idealerweise ist dabei auch ein User dabei, der die gewünschten Funktionalitäten noch einmal aus der eigenen Sicht darlegen kann. Das Entwicklungsteam macht sich während des ersten Sprint Planning Meetings mit den Anforderungen an das Produkt bzw. das Projektziel vertraut und klärt eventuell aufkommende Fragen. Zudem werden am Ende des Meetings die Abnahmekriterien für den anstehenden Sprint definiert. Das Sprint Planning Meeting 1 findet also vor jedem einzelnen Sprint statt und sollte maximal eine Stunde betragen. Die im Sprint Planning Meeting besprochenen Anforderungen und deren etwaige Änderungen werden im Sprint Backlog erfasst.

Sprint Planning Meeting 2: Entwicklungsteam organisiert Umsetzung

Im anschließenden Sprint Planning Meeting 2 klärt das Entwicklungsteam eigenverantwortlich, wie es die zuvor vorgestellten Anforderungen umsetzt. Dazu teilt das Team die einzelnen Anforderungen in Tasks ein, die in der Regel nicht länger als einen Tag in Anspruch nehmen sollten. Diese Tasks werden am Taskboard angebracht, um einen laufenden Überblick zum Projekt, den anstehenden Aufgaben und deren jeweiligem Status zu bekommen. Wie das Sprint Planning Meeting 1 sollte auch das zweite Meeting nicht mehr als eine Stunde betragen. Und wie beim ersten Meeting werden auch die Ergebnisse des zweiten Sprint Planning Meetings im Sprint Backlog festgehalten. Jeder Task wird hier eine der Ausprägungen „Task to Do“, „Work in Progress“ oder „Done“ zugewiesen.

Sprint: Die konkrete Umsetzung beginnt

Auf die beiden Sprint Planning Meetings folgt dann die Umsetzung des ersten Sprints, mit den zuvor definierten und abgestimmten Tasks. Die Bearbeitung erfolgt anhand der im Sprint Planning erarbeiteten Priorisierung. Das Entwicklungsteam geht Task für Task vor und stellt für jede einzelne Aufgabe sicher, dass alle Anforderungen abgearbeitet wurden. So wird vermieden, dass unfertige (Teil-)Ergebnisse abgeliefert werden.

Während eines Sprints konzentriert sich das Entwicklungsteam also ausschließlich auf die für diesen Sprint definierten Anforderungen und Tasks. Der Scrum Master sorgt während des Sprints dafür, dass aufkommende Herausforderungen in der Bearbeitung geklärt und beseitigt werden. Er darf allerdings keine Anweisungen an das Team erteilen, sondern lediglich an die Erreichung der definierten Ziele erinnern. Ein Sprint endet immer gemäß dem angesetzten Zeitplan, der in der Regel zwischen zwei und vier Wochen dauert. Am Ende muss ein funktionierendes (Teil-)Ergebnis des laufenden Projektes verfügbar sein. Der oder die Kund:in entscheidet nach jedem Sprint, ob er dieses (Teil-)Ergebnis bereits produktiv einsetzen will.

Daily Scrum: Tägliches Meeting während des Sprints

Innerhalb eines Sprints stehen Daily Scrums für das Entwicklungsteam an. Das sind maximal 15 Minuten lange Meetings zum aktuellen Stand der Entwicklung, den aktuellen und zuletzt bearbeitete sowie für den Tag anstehenden Tasks. Die Meetings dienen unter anderem dazu, möglicherweise zu große Tasks, die nicht innerhalb eines Tages bearbeitet werden können, in kleinere herunterzubrechen. Ebenso sollen Fragen und Probleme geklärt werden. Ist dies nicht im Kurz-Meeting möglich, werden diese an den Scrum Master übergeben, der solche Aspekte im Impediment Backlog erfasst und bearbeitet.

Sprint Review und Retrospektive: Ergebnisse überprüfen und Sprint evaluieren

Ist der Sprint abgeschlossen, erfolgt das Sprint Review und die Retrospektive. Hier stellt das Entwicklungsteam dem Product Owner (und dem User) das (Teil-)Produkt bzw. (Teil-)Ergebnis vor, das aus den im Sprint Planning Meeting 1 definierten Anforderungen/ Tasks hervorgegangen ist. Der Product Owner entscheidet dann anhand dieser Anforderungen, ob das Ergebnis abgenommen werden kann oder nicht. Die Anforderungen müssen zu 100 Prozent getroffen sein. Ist das nicht der Fall, werden nicht erfüllte Anforderungen vom Product Owner als neue bzw. nochmalige Tasks in das Sprint Planning Meeting für den kommenden Sprint übernommen. Das Gleiche gilt für Ideen oder Anforderungen, die sich im Sprint Review ergeben. Dann gibt der Scrum Master die neuen Anforderungen an den Product Owner zur Erfassung im Product Backlog weiter.

Nach Abschluss des Sprint Reviews trifft sich das gesamte Scrum Team (Product Owner, Scrum Master und Entwicklungsteam) zur Retrospektive. Hier werden eventuelle Probleme, Learnings und Verbesserungsmöglichkeiten diskutiert, die in den nächsten Sprint einfließen. Sofern es sich um Verbesserungen handelt, die das Entwicklungsteam alleine betreffen, werden sie von diesem selbst gelöst. Andere Probleme o.ä. fallen in den Aufgabenbereich des Scrum Masters. Er nimmt diese im Impediment Backlog auf und gibt sie an den Product Owner zur Bewertung für den folgenden Sprint weiter.

Burndown-Diagramm – Aktueller Entwicklungsstand immer im Blick

Der aktuelle Entwicklungsstand wird idealerweise in einem Burndown-Diagramm dargestellt. Dieses zeigt auf einen Blick: Den Zeitaufwand für das Scrum Projekt, die Anzahl bearbeiteter und verbleibender Tasks und den Idealverlauf des Projekts. Hier ein Beispiel eines Burndown-Diagramms: Je nach Abweichung vom Idealverlauf kann sehr schnell beurteilt werden, ob das Entwicklungsteam in time ist oder Verzögerungen bestehen. Auf das Burndown-Diagramm haben alle Projektbeteiligten, also auch der bzw. die Kund:in, Zugriff. das erhält die Transparenz während des Projektes.

Scrum Vorteile im Überblick

Die Vorteile der agilen Projektentwicklung mit Scrum sind vielfältig. Wir liefern Dir eine Übersicht der Scrum Vorteile:

1. Flexibilität: Zum einen arbeiten Teams deutlich flexibler, da ein Großprojekt in kleinere Teilprojekte (Sprints) heruntergebrochen wird diese einzeln nacheinander realisiert werden. Nach jedem Teilprojekt erfolgt ein Review. Die Erkenntnisse fließen dann wieder in die nachfolgenden Teilprojekte ein. Damit können Änderung am Markt oder neue Erkenntnisse und Ideen jederzeit aufgegriffen und in einem der kommenden Sprints berücksichtigt werden.
2. Kurze Kommunikationswege, schnelle Problemidentifikation und geringerer Administrationsaufwand: Durch die klare Einteilung in Rollen werden Kommunikationswege verkürzt. Jeder Projektbeteiligte weiß, mit wem er im Austausch steht und wer für welche Kommunikation zuständig ist. Die klare Aufgabenzuweisung sorgt ebenso dafür, dass der Aufwand für Administration und Dokumentation verringert wird. Gleichzeitig ermöglichen die kleinen Teilprojekte, Probleme schneller zu identifizieren und effektiver auszuräumen.
3. Höchstmögliche Transparenz: Das ist einer der größten Vorteile von Scrum. Alle Projektbeteiligten haben zu jedem Zeitpunkt vollständige Transparenz im Hinblick auf den aktuellen Entwicklungsstand sowie etwaige Hemmnisse. Das ermöglichen der Zugriff auf Backlogs, auf Burndown Diagramme und auf die aktuelle Testumgebung. Hier kann jeweils sehr zeitnah bei Problemen gegengesteuert werden. Böse Überraschungen bleiben somit aus.
4. Kontinuierlicher Verbesserungsprozess: Durch die permanente Diskussion in der Gruppe sowie die Reflektion am Ende eines jeden Sprints werden die Ergebnisse stetig verbessert. Das wirkt sich nicht nur fachlich, sondern auch auf die wirtschaftlichen Belange positiv aus.
5. Motivation und Effektivität durch Selbstorganisation: Aufgrund der „häppchenweisen“ Realisierung arbeiten Entwickler konzentrierter und auch fokussierter. Durch das Arbeiten im Team und den gegenseitigen Ansporn steigt die Motivation. Die Arbeitsergebnisse werden mithilfe von Scrum insgesamt deutlich besser.
6. Zeitnahe Realisation von Projektergebnissen: Der Scrum Ansatz bietet den Vorteil, dass schnell (Teil-)Ergebnisse eines Gesamtprojekts verfügbar sind. Sie können, je nach Wunsch der Kund:innen, sofort eingesetzt werden.
7. Realistische und genaue Aufwandsschätzungen: Anhand der Zerlegung in Teilprojekte können Unternehmen den Aufwand des Scrum Projekts besser einschätzen. Wie die Kostenkalkulation von Scrum durchgeführt werden kann, erfährst Du im folgenden Abschnitt näher.

Nachteile eines Scrum Projekts

Zu den Nachteilen von Scrum gehört, dass es keinen Gesamtüberblick über die komplette Projektstrecke gibt. Weitere Nachteile bilden der Kommmunikations- und Abstimmungsprozess. Denn der Aufwand nimmt trotz kürzerer Kommunikationswege zu. Der Grund: Scrum beinhaltet mehr Abstimmungs- und Review-Schleifen. Auch gibt es nur wenige konkrete Handlungsempfehlungen. Unternehmen müssen dem Scrum Team entsprechend viel Vertrauen für die Projektumsetzung entgegenbringen. Gleichzeitig besteht innerhalb der Task-Bearbeitung die Gefahr eines „Tunnelblicks“. Es ist daher wichtig, das Gesamtziel nie aus den Augen zu verlieren. Bei sehr großen Projekten, die mehrere Entwicklungsteams benötigen, kann die Koordination erschwert werden.

Kostenkalkulation von Scrum Projekten

Die Projekt-Arbeit stellt die Kalkulation je nach Auftraggeber vor Herausforderungen. Viele Unternehmen fordern ein Fixpreis-Angebot. Bei der Projektentwicklung ist dies allerdings nachteilig: Bestimmte Anforderungen und Features lassen sich im Vorfeld nur schwer vernünftig schätzen. Zudem kann es während der Projektphase zu weitreichenden Änderungen kommen, welche die Kalkulation über einen Fixpreis ausstechen. Ein Fixpreis-Angebot zieht vor allem zwei Probleme nach sich: Anbieter:innen kalkulieren in der Regel Unsicherheiten und Unwägbarkeiten ein, was aber deutlich teurer als der tatsächliche Aufwand ausfallen kann. Darüber hinaus sind Nachkalkulationen bei Fixpreis-Angeboten nicht auszuschließen. Oder der Auftragnehmer arbeitet innerhalb des Budgets, dafür aber weniger qualitativ. Diese Faktoren sind Nachteile, die bei der Frage nach Fixpreis-Angeboten berücksichtigt werden sollten. Zumal der Scrum Ansatz Möglichkeiten bietet, Aufwandsschätzungen detailliert durchzuführen. Dazu kann der Product Backlog dienen.

Product Backlog zur ersten Kalkulation

Bei Scrum Projekten hat sich in der Praxis bewährt, den Product Backlog dafür die erste Abschätzung der Kosten hinzuzuziehen. Aufgrund der erfassten Anforderungen können Kund:innen gemeinsam mit dem Product Owner anhand der Sprints eine Kalkulation des Projektumfangs umreißen – und das bereits in einem sehr frühen Stadium. Der Auftraggeber kann dabei die Kosten deckeln und die definierten Anforderungen entsprechend anpassen. Denkbar ist auch, dass der kalkulierte Aufwand als Höchstgrenze angesetzt wird. Diese Grenzen kann das Entwicklerteam dann beim Projekt berücksichtigen. Am Ende geht es also nur um die tatsächlich angefallenen Aufwände. Durch den Zugriff auf Projektmanagement-Tools können Auftraggeber diese Aufwände täglich einsehen und überwachen. So lässt sich mit Scrum sogar ein Projekt mit einem vorab fixierten Budget realisieren. Reicht das Budget dennoch nicht aus, können in Abstimmung mit dem Auftraggeber Funktionalitäten angepasst oder gestrichen werden.

Fazit

Unternehmen sollten sich definitiv beim nächsten Projekt auf das Thema Scrum einlassen. Die Scrum Vorteile lassen sich auch außerhalb von IT-Projekten für die agile Projektentwicklung und das agile Projektmanagement nutzen. Unternehmen gewinnen an Flexibilität und Qualität hinsichtlich der Projektergebnisse. Darüber hinaus schafft Scrum eine weitaus höhere Transparenz für alle Projektbeteiligten. Die Einteilung in kleinere Teilprojekte sorgt dafür, dass die Bearbeitung des Gesamtprojekts effizienter und schneller erfolgt. Das Entwicklerteam kann sich besser auf die einzelnen Tasks fokussieren, was sich in der Motivation und der Qualität der Ergebnisse niederschlägt. Gleichzeitig ermöglicht der Scrum Ansatz eine detaillierte Kostenkalkulation, bei der nur die tatsächlichen Aufwände berechnet werden. Unternehmen sollten jedoch auch beachten, dass der Scrum Ansatz nicht vor Sackgassen in der Projektentwicklung schützt. Er bietet aber eine Möglichkeit, schneller und früher auf solche zu reagieren.

Der Beitrag Scrum Vorteile: Was zeichnet Scrum aus und welches Potenzial steckt dahinter? erschien zuerst auf contentmanager.de.

Beinahe jedes IT-Projekt setzt auf die ein oder andere Art und Weise Features um. Jedes Software Produkt brüstet sich mit einer umfangreichen Feature Liste und Feature getriebene Entwicklung scheint, auf den ersten Blick, das Normalste der Welt zu sein. Der Teufel steckt jedoch, wie so oft, im Detail: in der Ausgestaltung der einzelnen Features.

%CAD2%

Was ist ein Feature?

Ein Feature ergibt sich in einem klassischen Digital-Projekt aus einer Kombination aus verschiedenen Anforderungen – sowohl fachlich als auch technischer Natur. Es beschreibt primär eine Eigenschaft oder Funktion, die das Produkt erhalten soll. Dies ist natürlich sehr unspezifisch. Die Frage muss daher wesentlich konkreter gefasst werden: Was ist ein geeignetes Feature, um das Projekt voranzutreiben und dem Entwicklungsteam sinnvolles Arbeiten zu ermöglichen?

Feature versus Story

In heutigen Softwareentwicklungstools wie JIRA und anderen Ticketsystemen entspricht ein Feature oft einer sogenannten User Story. Kommt die Feature getriebene Entwicklung also aus dem agilen Umfeld? Und kann sie nur dort angewendet werden? Definitiv nein.

Vielmehr hat die agile Entwicklung das Feature erneut wieder in den Fokus der Entwicklung gerückt. Auch die klassischen Konzeptpapiere sind Sammlungen von Features und deren Beschreibung. Nur sind in Vorgehensweisen wie Wasserfall oder V-Modell die Definition eines Features und dessen Umsetzung zeitlich voneinander getrennt. Teilweise ist fachliche und technische Konzeption auch aufgeteilt in Pflichten- und Lastenheft.

Im agilen Umfeld – sei es nun Scrum oder Kanban oder eine Mischform – sind Definition und Umsetzung wesentlich näher beieinander.

Die Feature getriebene Entwicklung stellt nun das Feature ganz klar in den Mittelpunkt des Projekts. Während der Umsetzung gilt das Ticket als zentrales Dokument bzw. Artefakt, um alle Informationen zu einem Feature zusammenzustellen.

Warum Features?

Durch die Aufteilung der Konzeption in Pflichtenheft und Lastenheft und einem sehr späten Beginn der eigentlichen Umsetzung entstehen lange, parallele und damit getrennte Handlungsstränge.

Hinzu kommt, dass umfangreiche Konzeptpapiere oftmals nicht gelesen werden. Viele Kunden stehen kurz vor dem Start der Umsetzung schon so in den Startlöchern, dass für das Studium des Feinkonzepts oftmals nicht die nötige Muße vorhanden ist und teilweise auch die Zeit fehlt, es in der Tiefe durchzugehen. Und wer kann die Komplexität eines so umfangreichen Projekts anhand eines 350 Seiten Konzeptes noch erfassen? Es bleibt trotz einer Unmenge an produziertem Papier viel Raum zu Interpretation und Missverständnissen.

Dadurch kommt im Projektverlauf trotzdem zu Auseinandersetzungen, weil die Erwartungen nicht getroffen wurden. Und als Dienstleister zieht man langfristig meist “den Kürzeren”. Die Beziehung zwischen Kunde und Dienstleister leidet und wirklich Spaß macht das Projekt so auf jeden Fall nicht mehr.

Zudem können die althergebrachten Argumente der agilen Vorgehensweise hier ebenfalls ins Feld geführt werden: Anforderungen ändern sich über die Zeit, daher sollten sie erst kurz vor der tatsächlichen Umsetzung konkret formuliert werden. Aber dies ist kein Artikel über Scrum versus Wasserfall, sondern er zeigt, wie man gute Features definiert und welche Erfolgsfaktoren hierbei eine Rolle spielen.

Gemeinsame Verantwortung

Wichtig für eine erfolgreiche Umsetzung ist besonders die gemeinsame Verantwortung von Fachbereich und Entwicklung. Nur gemeinsam kann ein Feature konkret genug beschrieben werden, um ein gemeinsames Verständnis der Aufgabe herzustellen. Eine gleichartige Erwartungshaltung ist extrem wichtig, um ein Projekt erfolgreich abzuschließen.

Daher sollte auch das jeweilige Ticket, in dem das Feature beschrieben ist, allen Projektteilnehmern gemeinsam gehören. Im Ticket werden u.a. die folgenden Details beschrieben:

Fachliche Anforderungen: Was ist das zentrale Ziel, das die Fachabteilung erreichen möchte?

• Kurze Beschreibung des Features, worum geht es?
• Was sind die Key Points, die der Fachabteilung besonders wichtig sind?
• Wie soll ein Feature funktionieren, welche Abläufe sind essentiell?
• Was sind Akzeptanzkriterien, wie weiß das Entwicklungsteam, dass das Feature fertig ist?

Rückfragen: Ein temporärer Bereich, in dem das Entwicklungsteam Rückfragen für ein Meeting mit der Fachabteilung oder dem Product Owner sammeln kann.

• Dies könnte auch in einem verknüpften Ticket gesammelt werden. Es kann aber sinnvoll sein, dies zu Dokumentationszwecken direkt im eigentlichen Feature Ticket zu verorten

Technische Umsetzungsplanung: Welche Ideen hat das Entwicklungsteam bereits gesammelt?

• Welche Technologie wird eingesetzt?
• Welche Annahmen über die Ausgangslage werden getroffen? Welche Abhängigkeiten gibt es?
• Welche Entwurfsmuster oder Ansätze werden verfolgt?
• Wie sind die Zuständigkeiten zwischen Frontend und Backend aufgeteilt?
• Wie können aus den Akzeptanzkriterien bereits Testszenarien abgeleitet werden?
• Wieviel Aufwand sieht das Entwicklungsteam für die Umsetzung des Features

Ein Wort zur Aufwandsschätzung

Viele Entwicklungsteams, die “Scrum nach Lehrbuch” praktizieren wollen, tun sich schwer damit, in Stunden oder Personentagen zu schätzen. Es wirkt “zu konkret”. Es scheint keine Schätzung mehr zu sein, sondern ein Ergebnis.

Letztendlich ist die Schätzung in Stunden aber auch eine Komplexitätsbewertung. Und um die geht es beim klassischen Planning Poker hauptsächlich. Letztendlich rechnen viele Entwickler die Punkte des Planning Pokers ohnehin wieder in Stunden um, damit sie die korrekte Bewertung für sich im Kopf machen können. Und beim Planning selber ist es in einem Kunde-Dienstleister Verhältnis ebenfalls wichtig, die Aufwände für das Projekt konkret genug zu kennen, damit ein Sprint oder eine Umsetzungsplanung halbwegs treffsichere Erkenntnisse liefert.

Bisher war es nach einer kurzen Umgewöhnung noch nie ein Problem für Entwickler, Features in Stunden und Tagen statt in Punkten zu schätzen. Die Diskussionen, warum ein Entwickler 2 Stunden und einer 6 Stunden schätzt, sind genauso hilfreich und decken die gleichen Dinge auf, wie ein Unterschied in Punkten.

Tipps für die Praxis

Was sollte man bei der Definition von Features beachten?

• Immer eine feste Struktur: Legen Sie alle Feature Tickets nach dem gleichen Schema an. So ist sichergestellt, dass kein Aspekt vergessen wird und alle Projektmitarbeiter sich jederzeit zurechtfinden.
• Lieber eine Frage zu viel stellen, als eine Frage zu wenig: Bei der Beschreibung eines Features gilt das Motto: Viel hilft viel. Jede Frage, die bereits bei der Definition gestellt wird, sorgt für weniger Abstimmungsaufwand im Laufe der Umsetzung.
• Auch offensichtliche Annahmen konkret hinterfragen: Manches erscheint auf den ersten Blick “normal” und “selbstverständlich”. Doch viele Projekte zeigen deutlich, dass gerade hier die Erfahrungswelten der Beteiligten voneinander abweichen können. Das macht Missverständnisse in diesem Bereich besonders ärgerlich, weil damit keiner gerechnet hat.
• Ein Bild sagt mehr als tausend Worte: Viele Themen lassen sich entweder mit viel Prosa beschreiben oder mit einem Diagramm schnell auf den Punkt bringen. Auch Scribbles oder Ergebnisse des Paper Prototyping können wertvolle Informationen für die Umsetzung enthalten.
• Mehrdeutigkeit vermeiden: Machen Sie vor dem Finalisieren der Definition auf jeden Fall noch einen Plausibilitäts-Check. Oft kommt es vor, dass im Rahmen von Diskussionen plötzlich widersprüchliche Informationen im Ticket angekommen sind. Hier fällt es nachher schwer, die gültige Definition zu ermitteln. Gehen Sie also auf Nummer sicher und prüfen Sie die fertiggestellte Definition. So können Sie unangenehme Überraschungen vermeiden.
• Überschaubare Größe eines Features: Der Aufwand pro Gewerk sollte nicht mehr als einen Personentag betragen. Beteiligt sein können beispielsweise Frontend, Backend, Administration, Design, etc. Hierdurch wird das Risiko für das einzelne Feature auf genau diesen Aufwand minimiert.
• Abhängigkeiten reduzieren: Features sollten möglichst so gekapselt werden, dass keine konkreten Abhängigkeiten bestehen. Je isolierter ein Feature umgesetzt werden kann, umso besser kann es auch getestet und abgenommen werden.
• Akzeptanzkriterien und Testkriterien gehören zusammen: Das zentrale Element für die Abnahme eines Features durch den Fachbereich sind die Akzeptanzkriterien. Sie ermöglichen es, die Erwartungshaltung genau zu definieren. Im Optimalfall können an die Akzeptanzkriterien der Fachabteilung direkt Testszenarien der Entwicklung geknüpft werden. So wissen beide Seiten, wann das Feature als abgeschlossen gilt.

Kunst oder Wissenschaft?

Die Tipps zeigen, dass es an der ein oder anderen Stelle durchaus knifflig werden kann. Welches Feature hat schon keinerlei Abhängigkeiten? Kann man immer so genau zwischen acht und zehn Stunden Aufwand differenzieren? Hier verschwimmt die Grenze zwischen Kunst und Wissenschaft. Das optimale Beschreiben eines Features basiert in den meisten Fällen auf Erfahrung und einer Intuition, wie ein Feature am besten “geschnitten” wird, damit man möglichst alle Tipps beachtet. Sie sollten jedoch nicht als Dogma betrachtet werden.

Gibt es beispielsweise Features, die länger als acht Stunden im Backend bedeuten, so kann es durchaus sinnvoll sein, dies trotzdem so beizubehalten. Wenn beispielsweise die Umsetzung mehrerer Webservices gebündelt Sinn macht und die Vorgehensweise klar ist, so ist auch das Risiko für dieses Feature nicht besonders hoch. Es handelt sich um “Fleißarbeit”, die gut abzuschätzen und planbar ist.

Chancen und Herausforderungen beim Dienstleister

Wie man sieht, maximiert die gemeinsame Verantwortung bei den Tickets (und damit den Features) die Transparenz im Entwicklungsprozess. Die Fachabteilung darf und muss sich aktiv einbringen. Sie bekommt mit, welche technischen Hürden bestehen und welche Anforderungen eventuell trivial sind. Das Entwicklungsteam bekommt mit, warum welche Funktionen benötigt werden und erkennt, dass die Wirklichkeit wesentlich “dreckiger” ist als in der schönen Welt von 0 und 1. Schließlich sind Digital-Projekte meistens komplexe Abläufe in komplexen Umfeldern, die nicht am Fließband abgearbeitet werden können.

In der Theorie wird somit das gemeinsame Verständnis füreinander gestärkt. Soweit so gut. Was sind nun die Risiken der Feature getriebene Entwicklung für Dienstleister? Findet die Entwicklung komplett In-House und ohne externen Dienstleister statt, sind die Fronten geklärt und die Kosten liegen komplett intern. Hier kann es natürlich auch zu Unstimmigkeiten kommen, aber dies kann innerhalb der bestehenden Organisation gelöst werden.

In der Beziehung zwischen Dienstleister und Kunden gibt es eine andere Dynamik. Man muss sich daher im Klarem sein, dass Transparenz ein großes Maß an Vertrauen und Goodwill erfordert. Nicht jede Beziehung hält dies aus. Wenn eine Atmosphäre des Misstrauens besteht, dann kann das Entwicklungsteam nicht offen über technische Hürden sprechen. Bereits getroffene Entscheidungen können nur sehr schwer für eine noch bessere Lösung in Frage gestellt werden. Und fehlende Kompetenz in einem Bereich kann nicht offen zugegeben werden, weil man sich sonst in ein schlechtes Licht rückt. Die Aufwände können beim Kunden für Unverständnis sorgen und es kann zu handfestem Streit bei den gemeinsamen Meetings kommen.

Spielen beide Seiten mit offenen Karten, so zeigt die Erfahrung aber: Es lohnt sich! Die Transparenz stärkt das Vertrauen in die Kompetenz und die Arbeitsweisen. Die Vorgehensweisen des Dienstleisters werden nachvollziehbar. Das Anliegen des Kunden wird deutlich. Die Ergebnisse der Umsetzung sind besser und passen genau zu den Erwartungen des Kunden. Beide Seiten können ein erfolgreiches Digital-Projekt feiern.

Typische Herausforderungen und mögliche Lösungsansätze

Auch, wenn man sich gemeinsam und mit jeder Menge Vertrauen in das Abenteuer eines Relaunchs oder einer Produktentwicklung stürzt, zeigt die Projekterfahrung, dass es doch einige Herausforderungen zu meistern gilt:

Stakeholder können Anforderungen schlecht formulieren

Viele Mitarbeiter von Fachabteilungen sind es nicht gewohnt, Anforderungen so zu formulieren, dass sie jemand anderes, geschweige denn ein Entwickler mit einem ganz anderen Erfahrungshintergrund, genauso versteht, wie es gemeint ist. Ein Entwicklungsteam mit einer großen Domain Knowledge, also Vorerfahrung in dem Fachbereich um den es geht, kann hier helfen. Es kann hilfreich sein, die Untiefen des Leasingerlasses zu kennen, um die größten Klippen zu umschiffen. Wie damit aber von Kunde zu Kunde intern umgegangen wird, kann nur die Fachabteilung definieren.

Die Erfahrung zeigt, dass zwei Aspekte sehr hilfreich sind: On-Boarding und Coaching-on-the-Job. On-Boarding kann durch einen vorgelagerten Workshop geschehen. Hier werden alle Beteiligten anhand von Beispiel Features durch den Prozess geleitet. Es wird klargemacht, welche Rolle im Projekt für welche Themen verantwortlich ist. Idealerweise wird gegen Mitte des Workshops bereits das ein oder andere Feature aus dem Projekt heraus als Übungsgegenstand verwendet.

Das Coaching sollte im Rahmen der Umsetzungsphase in regelmäßigen Intervallen geschehen. Hier bietet es sich an, anhand von anstehenden Features das Refinement mit einem Scrum Master oder Projektleiter gemeinsam vorzunehmen. Zu Beginn des Projekts kann dies intensiv geschehen, bspw. mit zwei Terminen pro Woche. Später sollte man es von der Art der Features und den Erfahrungen des Entwicklungsteams abhängig machen.

Die Fachabteilung unterschätzt den eigenen Aufwand

Wie man vielleicht vermuten kann, bedeutet das konkrete Formulieren von Features einen nicht zu unterschätzenden Zeitaufwand. Kann man sich um das Lesen eines 350 Seiten Konzepts noch irgendwie herumdrücken oder überfliegen, ob die eigenen Annahmen getroffen wurden, ist die Zusammenstellung von Features für Fachabteilung und Entwicklungsteam harte Arbeit. Arbeit, die sich lohnt, aber die getan werden muss.

Wieviel dies im Einzelnen bedeutet, wird von vielen Fachabteilungen unterschätzt. Teilweise werden durch Rückfragen des Entwicklungsteams auch Herausforderungen im Prozess aufgezeigt, die vorher noch gar nicht klar wurden. Dies bedeutet an vielen Stellen Hausaufgaben für die Fachabteilung und kann im schlimmsten Fall für Verzögerungen in der Umsetzung sorgen, da noch aufwändige Abstimmungsrunden durchlaufen werden müssen.

Wer kümmert sich beispielsweise um die Anfragen, die über das neue Kontaktformular eintreffen? Die Zentrale? Die Niederlassung? Gibt es in jeder Niederlassung kompetente Ansprechpartner? Gibt es ein professionelles Input Management für Anfragen, die ausgedruckt oder als Fax übermittelt werden? Wie wird auf diese Anfragen geantwortet, wenn der restliche Prozess komplett auf E-Mails ausgerichtet ist?

Wie sieht der Entwicklungsprozess aus?

Heutzutage gibt es viele geeignete Softwareentwicklungs-Tools. Eine sehr weit verbreitete Suite für die Abwicklung verschiedenster Projekte bietet Atlassian an. Hierzu zähle JIRA als Ticketsystem, Stash als Repository-Verwaltung und Bamboo als Build & Delivery Server. Die folgende Beschreibung orientiert sich zwar an Atlassian Produkten, kann aber ohne Probleme auch auf andere Kombinationen übertragen werden.

Ticket wird erstellt und Informationen werden ergänzt – gemeinsam oder asynchron

Als zentrales Dokument während der Umsetzung steht zu Beginn der Entwicklung das Ticket in JIRA. Hier werden, angelehnt an die Tipps aus der Praxis, die Anforderungen an das Feature festgehalten und alle sinnvollen Beschreibungen erfasst.

Feature wird geschätzt

Auf Basis der Informationen im Ticket werden die voraussichtlichen Aufwände geschätzt. Das Verfahren richtet sich hier nach der Projektmethode. Bei Scrum-Projekte würde dies beispielsweise im Rahmen des Planning Pokers stattfinden und das Entwicklungsteam würde die Schätzung gemeinsam vornehmen. Die geschätzten Aufwände werden am Ticket erfasst. JIRA bietet hierfür verschiedene Möglichkeiten, unter anderem auch das Schätzen in Stunden oder Tagen.

Feature wird für die Umsetzung vorgesehen

Damit das Feature auch tatsächlich umgesetzt wird, erfolgt eine Priorisierung der verschiedenen Features für den nächsten Umsetzungszeitraum. Bei einem Scrum-Projekt würde es beispielsweise für das nächste Sprint Backlog vorgesehen, bei Kanban zur Liste der anstehenden Aufgaben hinzugefügt und entsprechend sortiert. In einem Wasserfall-Projekt würde es in den Projektplan aufgenommen.

Feature Branch wird erstellt

Das Entwicklungsteam erstellt auf Basis des Feature Tickets einen eigenen Feature Branch im Git Repository. So ist die Arbeit an dem Feature gekapselt und es kann isoliert entwickelt und getestet werden. In JIRA ist das Erstellen eines neuen Branches bequem über einen Link im Ticket möglich. Dabei übernimmt Stash das Anlegen und Benennen des Feature Branches und das Team kann danach den Feature Branch direkt auschecken und bearbeiten. ID und Bezeichnung des Features werden direkt in den Branchnamen übernommen, so dass jederzeit klar ist, welches Feature in welchen Branch gehört.

Die Umsetzung wird durchgeführt

Das Entwicklungsteam kann nun im entsprechenden Branch das Feature umsetzen, Tests schreiben und das Feature beispielsweise auf eine interne Test-Umgebung deployen. Hierbei können einzelne oder mehrere Entwickler am Feature im Feature Branch arbeiten. So kann ein Frontend Entwickler den View für die Eingabemasken für ein Kontaktformular erstellen und ein Backend Entwickler parallel die Models und Controller für die Verarbeitung erstellen. Während der Arbeiten wird der aktuelle Stand vom CI System gebaut und ein Tool wie bspw. Sonarqube ermittelt die Qualitätsmetriken als Indikator für das Entwicklungsteam.

Ein Pull Request wird erstellt

Nach Abschluss der Arbeiten erstellt der Hauptverantwortliche für das Feature einen Pull Request. Andere Entwickler führen anhand des Pull Requests einen Code Review durch. Je nach Art des Features oder auch nach Art des Projekts kann es ausreichen, wenn ein Teil des Entwicklungsteams den Pull Request genehmigt. Bei kritischen Features sollte jedoch das gesamte Team den Pull Request prüfen. Dies unterstützt wiederum auch die gemeinsame Verantwortung innerhalb des Entwicklungsteams und die sogenannte Collective Code Ownership.

Der Code Review geschieht entweder gemeinsam in einem Meeting oder asynchron und toolgestützt, beispielsweise über Stash. Wobei sich auch bei einem Meeting Stash als zentrale Plattform eignet, damit das Ergebnis des Reviews dokumentiert werden kann.

Nach erfolgreichem Code Review wird der Feature Branch in den aktuellen Entwicklungsstand zurückgeführt. Auch dies kann komplett über die Web Oberfläche von Stash durchgeführt werden.

Der neue Entwicklungsstand wird bereitgestellt

Über Bamboo kann nun der neue Entwicklungsstand, meistens ein Branch mit dem Namen develop, development oder trunk, auf die einzelnen Umgebungen verteilt werden. Hierbei greift der Build & Delivery Server auf die Branches im Stash zu und erstellt auf deren Basis nachvollziehbare Releases. Diese können dann auf ein QA-System oder nach Freigabe durch den Kunden auch auf das Produktionssystem ausgerollt werden.

Das Feature ist fertig

Um im Nachhinein noch Zusammenhänge zu einem Feature nachvollziehen zu können, sind im Ticket nach der Fertigstellung folgende Informationen zu finden:

• Welcher Branch im Repository gehört zu diesem Feature?
• Welche Commits gehören zu dem Feature?
• Wie viele Builds gibt es zu dem Feature und wie ist der Status der Builds?
• In welchen Umgebungen wurde das Feature bereits bereitgestellt (Development, Testing, QA, Production)

Durch den Einsatz des Atlassian Stacks werden viele dieser Informationen automatisiert erfasst und dokumentiert. Aber auch andere Systeme bieten diese Automatisierung. Wenn man keins dieser Systeme einsetzt, bietet es sich trotzdem an, diese Informationen manuell im Ticket zu erfassen.

Hybridansätze

Oft ist es so, dass die eigentliche Feature Entwicklung erst auf einem Basis-System aufsetzt. So kann bspw. ein Intranet Projekt auf einem Portalsystem wie Liferay aufsetzen. Oder ein Website Relaunch wird mit TYPO3 durchgeführt. In beiden Fällen gibt es viele Standardaufgaben, die beim Einrichten des Systems durchgeführt werden müssen, die aber keine konkreten Feature-Definitionen bedeuten. Hier kann das Digital-Projekt in zwei Phasen aufgeteilt werden: Die Setup Phase und die Feature Phase.

In der Setup Phase werden die üblichen Dokumente in abgespeckter Fassung erstellt. So ist nachvollziehbar, was die Ausgangsbasis für die Umsetzung der Features ist. In der Feature Phase gelten dann die oben beschriebenen Vorgehensweisen.

Rollen im Projekt

• Entwicklungsteam: Das Team von Entwicklern, das für die Umsetzung des Projekts oder Produkts verantwortlich ist.
• Stakeholder: Wichtige Ansprechpartner des Kunden, die Anforderungen an das Projekt definieren. Dies können CEO, CTO, IT Leiter, CFO, Aktionäre, Betriebsrat uvm. sein. Hierzu zählen vor allem aber auch: die Mitarbeiter der Fachabteilungen. Vertrieb, Customer Service, Administration oder Sachbearbeitung.
• Fachabteilungen: Fachliche Ansprechpartner, die konkrete fachliche Anforderungen an das Projekt definieren.
• Projektleiter: In klassischen Projekten organisiert er das Projekt, erstellt Statusberichte und informiert die Stakeholder über den Projektfortschritt
• Scrum Master: In agilen Projekten der Ansprechpartner, der für das Entwicklungsteam Stolpersteine aus dem Weg räumt und für das Einhalten des Scrum Prozesses zuständig ist.
• Product Owner: In agilen Projekten ist er verantwortlich für die Priorisierung der Features/Stories und gibt die Richtung für das Projekt oder das Produkt vor.

Tools für die Umsetzung

• Ticketsystem: JIRA, Redmine, Trello, Mantis. Es eignet sich jedes System, in dem ein Feature gemeinsam beschrieben werden kann. Eine Integration in die anderen Systeme erleichtert das Arbeiten für das Entwicklungsteam. JIRA erlaubt bspw. das direkte erstellen eine Feature Branches in Stash aus dem Ticket heraus.
• VCS: Version Control System. Oftmals Git oder Subversion, bspw. Stash, Gitlab, Github, Bitbucket. Für die Feature getriebene Entwicklung eignet sich besonders ein Tool, das Feature Branches unterstützt und das Branchen und Mergen erleichtert.
• Build und Continuous Integration: Bamboo, Jenkins, Travis CI, Gitlab CI. Mit diesen Tools werden die Feature Branches gebaut, die Tests ausgeführt und Software Metriken erhoben. Idealerweise werden diese dann in einem Tool wie Sonarqube gesammelt.
• Delivery: Bamboo, Jenkins. Hiermit wird das Projekt oder ein bestimmter Feature Branch auf eine der Umgebungen gebracht.

Fazit

Feature getriebene Entwicklung bietet viele Chancen, ein Digital-Projekt erfolgreich zu machen. Seine größten Stärken spielt es sicher in der agilen Entwicklung aus, da viele unterstützende Prozesse bereits vorhanden sind und es mit der User Story ein Instrument gibt, das ideal geeignet für die Beschreibung eines Features ist. Aber auch Wasserfall-Projekte können stark davon profitieren, das Feature in den Mittelpunkt zu stellen.

Anforderungen werden hinterfragt. Der Fokus wird auf den Mehrwert für die Anwender und Nutzer gelegt. Fachabteilung und Entwicklung arbeiten wesentlich enger miteinander.

Hauptgrund für das Scheitern von Digital-Projekten sind oftmals unterschiedliche Vorstellungen von dem, was der Kunden wünscht und dem was der Dienstleister verstanden hat. Diese Kluft wird durch das Fokussieren auf das einzelne Feature stark verkleinert und es werden durch die gemeinsame Arbeit an der Definition des Features eine Menge Brücken gebaut, die das gesamt Projekt in eine konstruktive und offene Atmosphäre versetzen.

Man darf nicht vergessen, dass diese Art der Entwicklung nicht weniger Aufwand für Konzeption und Abstimmung bedeutet. Aber dieser Aufwand wird an der richtigen Stelle eingesetzt und maximiert damit den Output für das Projekt. Auch in Konzeptphasen vorab wird nun über konkrete Features gesprochen und nicht mehr im stillen Kämmerlein “vor sich hin konzipiert”. Das Verständnis beim Kunden ist größer und er hat in diesem Szenario viel eher die Möglichkeit, Einfluss zu nehmen und Missverständnisse zu korrigieren.

Der Beitrag Chancen einer Feature getriebenen Entwicklung erschien zuerst auf contentmanager.de.

In der Softwareentwicklung setzt sich Scrum als agile Projektmanagement-Methode zunehmend durch. Inzwischen gibt es zahlreiche Workshops, umfassende Literatur und eine große Anzahl erfahrener Scrum-Experten. Im Scrum-Kontext wurde es bisher jedoch vernachlässigt, andere Elemente und fachliche Disziplinen, die essenziell für ein starkes Produkt sind, zu integrieren – wie beispielsweise das User Experience Design. Eine gute User Experience (UX) führt dazu, dass Anwender ein Produkt bzw. eine Software gerne nutzen und ist damit ein wesentlicher Erfolgsfaktor.

%CAD2%

Dennoch treten in der Praxis das User Experience Design und der Scrum-Prozess bisher meist nur nebeneinander an und haben wenige Berührungspunkte: Das User Experience Design – vom User Research über die Definition von Personas bis hin zur Erarbeitung von Skizzen und Wireframes – wird oft im Voraus erstellt und dann für die Umsetzung dem Entwicklungsteam übergeben. Erschwerend kommt hinzu, dass meist externe, spezialisierte Agenturen – die oft nach der klassischen Wasserfall-Methode arbeiten – das User Experience Design gestalten. Das liegt zumeist daran, dass bei der Gründung insbesondere der seit längerem bestehenden IT-Unternehmen das Thema UX noch nicht so sehr im Vordergrund stand wie heute.

Mit der zunehmenden Bedeutung und Verbreitung des Internets – bis auf die Bildschirme unserer Smartphones – haben sich die Ansprüche der User an eine Software jedoch verändert: Sie legen deutlich mehr Wert auf das Design und die Nutzerführung einer Software oder einer Internet-Anwendung. Um den stetig steigenden Ansprüchen der User gerecht zu werden und nicht zuletzt, um Marktanteile zu halten oder gar auszubauen, muss das UX-Design den User nicht nur bei der Anwendung unterstützen, sondern ihm auch ein gutes Gefühl bei der Nutzung der Software vermitteln. Je weniger Software-Unternehmen also auf ein optimales User Experience Design verzichten können, umso wichtiger ist es, diese Disziplin mit dem Scrum-Prozess zu verzahnen, der von ihnen meist für die Entwicklung eingesetzt wird. Denn nur wenn das User Experience Design und die Entwicklung im Rahmen eines agilen Prozesses gemeinsam antreten, steht am Ende ein Sieg: ein erfolgreiches Produkt, das nicht nur funktioniert, sondern das die Nutzer auch gerne anwenden.

Die drei wichtigsten Aspekte für eine erfolgreiche Integration von UX-Design in den Scrum-Prozess

Erfolgsfaktor 1: Räumliche Nähe – für mehr Austausch und gegenseitiges Verständnis

Eine gelungene agile Zusammenarbeit zwischen UX-Designern und Softwareentwicklern

wird durch viele Faktoren bestimmt, der Hauptfaktor aber ist das Team selbst. Häufig ist jedoch das Verhältnis zwischen Designern und Entwicklern eher angespannt. Das liegt nicht selten daran, dass beiden Gruppen nur wenig über die Arbeitsprozesse der jeweils anderen Gruppe wissen. So ist es für Designer oft nicht leicht nachzuvollziehen, wie die Entwickler mit den von ihnen zur Verfügung gestellten Designs weiterarbeiten. Die Entwickler wiederum können sich häufig kein Bild von den Prozessen machen, die Designer durchlaufen, um ein valides Konzept zu gestalten. Für beide Seiten ist es mitunter sehr intransparent, was die jeweils andere Gruppe in ihrer täglichen Arbeit leistet.

Aufklärungsarbeit seitens der Projektleitung und der Teammitglieder selbst kann hier zunächst ein grundlegendes Verständnis schaffen. Dabei sollte erklärt werden, was die Aufgaben der einzelnen Rollen sind und inwiefern sich durch die Integration der Designer auch Prozesse in der Softwareentwicklung anpassen müssen. Es ist wichtig, dass alle Teammitglieder verstehen, dass nur durch ein gutes Zusammenspiel beider Prozesse – User Experience Design und Softwareentwicklung – ein gelungenes Produkt entstehen kann.

Um das Verständnis für die Arbeit der jeweils anderen zu verbessern, ist räumliche Nähe ein wesentlicher Aspekt: Wenn Designer und Entwickler zusammen im gleichen Raum arbeiten, bekommen sie mit, an was der jeweils andere arbeitet. Sie können sich Fragen stellen und/oder ihre Arbeitsschritte wie z. B. Designs oder Softwarearchitektur-Bilder sichtbar im Raum anbringen. Durch das offensichtliche Visualisieren der aktuellen Arbeiten können einfacher und schneller Gespräche und Diskussionen entstehen. Diese Kommunikation – die weitaus häufiger stattfindet, wenn ein Team in einem Raum sitzt – fördert den kontinuierlichen Austausch, auch im Hinblick auf die technische Realisierung von Design-Ideen. Kurze Kommunikationswege führen dazu, dass Fragen häufiger gestellt und schneller geklärt werden, und wirken sich damit positiv auf das Produktergebnis aus.

Wenn es zeitlich möglich ist – und das entsprechende Fachwissen vorliegt – können die Designer die Entwickler auch bei der Programmierung unterstützen, etwa im Bereich der Frontend-Entwicklung. Der Vorteil: Selbst entworfene Designs lassen sich auch gleich technisch umsetzen und somit auf ihre Machbarkeit prüfen. Umgekehrt können sich auch die Entwickler im Rahmen des Scrum-Prozesses an der Erstellung des User Experience Designs beteiligen, etwa indem sie Mockups oder Prototypen erstellen.

Erfolgsfaktor 2: UX-Design schon in Sprint 0 berücksichtigen – für relevante Personas und gute User Stories

Im Scrum-Prozess wird die Zeit vor dem ersten Sprint für vorbereitende Maßnahmen genutzt, wie z. B. die Aufstellung der technischen Architektur. Dieser Zeitraum wird auch als Sprint 0 bezeichnet. In diese Phase lassen sich die ersten konzeptionellen und kreativen Prozessschritte des UX-Designs gut integrieren. Ziel von Sprint 0 ist in diesem Fall, gemeinsam ein grundlegendes Verständnis für den User und eine einheitliche Produktvision zu erarbeiten

Hierfür empfiehlt sich ein Workshop, in dem alle Projektbeteiligten – Entwickler, User Experience Designer, Product Owner und idealerweise auch die Stakeholder – ein Big Picture der UX-Idee entwickeln. Ebenso sollten bereits in Sprint 0 die ersten Schritte des UX-Designs umgesetzt werden: User Research, Persona-Erstellung und das Erarbeiten von Anforderungen in Form von User Stories. Auf dieser Basis können die Beteiligten gemeinsam ein für alle verständliches Product Backlog erarbeiten. Bereits im Sprint 0 sollten Daily Scrum Meetings stattfinden, in denen sich die Teammitglieder gegenseitig über den Fortschritt und aktuellen Stand der Vorbereitungsphase informieren.

Die User Stories, die im Sprint 0 zusammen erarbeitet werden, sortiert der Product Owner am Ende des Sprints nach ihrer Priorität. Am höchsten werden die User Stories priorisiert, die das sogenannte Minimal Viable Product (MVP) abbilden – also das Produkt oder Feature, welches mit dem geringsten Aufwand den größtmöglichen Nutzen für den User bringt. Diese User Stories sollten dann in den ersten Sprints umgesetzt werden.

Um abschätzen zu können, wie viele Sprints benötigt werden, um das MVP umzusetzen, sollten die Entwickler in Sprint 0 eine Aufwandsschätzung der priorisierten User Stories vornehmen. Aufgabe der User Experience Designer in dieser Phase ist es, den Wert und Nutzen einer User Story zu beschreiben und die Entwickler an den Aufwand für die Umsetzung des Designs zu erinnern.

Für die Entwickler kann es schwierig sein, eine Aufwandsschätzung abzugeben, wenn noch kein definiertes User Experience Design vorhanden ist. Um ein gemeinsames Verständnis – und damit eine genauere Schätzung – der User Stories zu erreichen, empfiehlt es sich, während Sprint 0 einfache (Papier-)Prototypen zu erstellen. Die Ideen aller Projektbeteiligten lassen sich auf diese Weise schnell visualisieren und so besser in der Gruppe diskutieren. Die tragfähigsten Ideen können dann weiterentwickelt und idealerweise anhand von mit Prototypen noch in Sprint 0 auf ihre Benutzerfreundlichkeit getestet werden, z. B. von Kollegen. Das Feedback der Tester lässt sich dann in einer schnellen Iteration berücksichtigen.

Der parallelen Entwicklung geschuldet, wird es im Laufe des Projekts nur noch den User Experience Designern möglich sein, den kompletten Prozess immer wieder durchzuführen, d.h. kontinuierliche User Research, Anpassung – und falls erforderlich Neuerstellung – von Personas, Erstellung und Test von Prototypen etc. Die User Experience Designer sollten im Laufe des Prozesses darauf achten, ihre gewonnenen Erkenntnisse und Resultate regelmäßig mit dem restlichen Team zu teilen.

Erfolgsfaktor 3: UX-Designer an allen Scrum-Meetings beteiligen – für das „Big Picture“

Voraussetzung für eine ganzheitliche Integration der User Experience Designer in den Scrum-Prozess ist deren Teilnahme an allen Scrum-typischen Meetings. Dazu zählen Daily Scrum, Plannings, Product Backlog Refinement, Retrospektiven und Reviews.

Im Rahmen dieses „institutionalisierten“ Austauschs zwischen Entwicklern und User Experience Designern – idealerweise zusätzlich unterstützt durch räumliche Nähe – können beide Gruppen schnell herausfinden, ob sich das erstellte User Experience Design mit angemessenem Aufwand umsetzen lässt. Weiterhin haben die Entwickler so auch die Möglichkeit, ihre Ideen und Ansichten in den UX-Design-Prozess einfließen zu lassen.

Ebenfalls empfiehlt sich eine enge Zusammenarbeit zwischen UX-Designern und Product Ownern, speziell bei der Ausgestaltung von User Stories. Sie können ihre Erfahrung im Umgang mit den Nutzern und deren Bedürfnisse bei der Erstellung von User Stories einfließen lassen und User Experience Designs zu den geplanten User Stories anfertigen. Dabei sollte darauf geachtet werden, sehr detailliertes User Experience Design erst dann zu erstellen, wenn es benötigt wird – und nicht schon weit im Voraus. Das Gleiche gilt auch für die finale Ausformulierung der User Stories, da es sehr wahrscheinlich ist, dass sich initiale User Stories aufgrund neuer Erkenntnisse im Laufe des Projekts ändern. Somit ist es ratsam, die User Stories auch hinsichtlich ihrer User Experience erst ein bis zwei Sprints vor der geplanten Umsetzung zu finalisieren, um den Arbeitsaufwand zu minimieren.

Als fester Bestandteil eines Scrum Teams stehen die User Experience Designer jederzeit für Rückfragen zur Verfügung. Das trägt dazu bei, Mehrfach-Arbeit zu verhindern, etwa wenn ein Detail zum Verhalten des User Interfaces vom Entwickler anders verstanden und ohne Rückfrage implementiert wurde. Indem sie die Akzeptanzkriterien einer User Story prüfen, unterstützen die UX-Designer auch den Product Owner, der die User Stories maßgeblich mitprägt.

User-Tests sind ein weiteres Aufgabenfeld, dessen sich UX-Designer während der Entwicklung annehmen können. Hierfür empfiehlt es sich, mit ausgewählten Anwendern in regelmäßigen Abständen – etwa alle zwei Sprints – Usability-Tests durchzuführen, idealerweise zunächst mit Prototypen. So hat die Zielgruppe die Möglichkeit, neu implementierte Produktinkremente zu evaluieren. Eine frühe Rücksprache mit den Anwendern hat den Vorteil, dass etwaige Änderungswünsche der User umgehend berücksichtigt werden können. Insbesondere wenn die Anpassungen bereits an Prototypen erfolgen und nicht erst an der bereits entwickelten Software, bedeutet das enorme Zeit- und Kostenersparnisse. Anpassungen lassen sich direkt in einer darauffolgenden Iteration vornehmen, oder die Änderungswünsche werden in neuen User Stories verankert. Um den transparenten Austausch mit dem Scrum Team aufrecht zu erhalten, sollten die UX-Designer die Ergebnisse der User Tests im Daily Scrum präsentieren.

Fazit

User Experience Designer können in einem Scrum-Team umfassende Aufgaben übernehmen und wesentlich zum Erfolg des Produkts beitragen. Voraussetzung dafür ist, dass die UX-Designer als Doppelpartner der Entwickler im Scrum-Prozess mitspielen. Zum einen ist es ihre Aufgabe, nach vorne zu schauen und mittels User Research, User Tests und Prototyp-Erstellung eine auf den Anwender ausgerichtete Entwicklung des Produkts voranzutreiben. Zum anderen sollten sie immer für Nachfragen der Entwickler bezüglich aktuell bearbeiteter User Stories verfügbar sein, die bereits implementierten User Stories validieren und gegebenenfalls an der Zielgruppe testen.

Dabei sollten sich alle Beteiligten bewusst sein, dass es in der agilen Softwareentwicklung im Grunde keine endgültige Lösung gibt. Mit sich verändernden Bedürfnissen der User muss sich schließlich auch das Produkt verändern – indem es stetig angepasst und weiterentwickelt wird. Daher sind mit der Freigabe eines Softwareprodukts die Entwicklung und das User Experience Design nicht abgeschlossen. Im Prinzip beginnt in diesem Moment schon ein neues Match.

Autor: Heidi Oltersdorff, Consultant bei diva-e Digital Value Enterprise GmbH (www.diva-e.com)

Der Beitrag Ein gutes Doppel: User Experience Design und Scrum erschien zuerst auf contentmanager.de.

Seit einiger Zeit fördern agile Ansätze im Projektmanagement die effiziente Teamarbeit und garantieren erfolgreiche Projekte. In der komplexen Welt von heute, die geprägt ist von Digitalisierung auf allen Ebenen und mobiler Internetnutzung, versagen immer häufiger Prinzipien des klasssichen Projektmanagements, die in den letzten 50 Jahren gut funktioniert haben. Agile Prozesse sind geprägt durch enge Abstimmungen untereinander, laufende Kommunikation, flexible Vorgänge und kurzfristig abgesteckte Ziele.

Der Kunde kann zu jeder Zeit Einblick und Mitbestimmung erhalten und die Entwicklung des Projektes verfolgen. Sowohl der End-Termin als auch das Budget werden zwar bereits zu Beginn festgelegt. Die Umsetzung und auch die Priorisierung der Aufgaben bleibt aber flexibel. Es gibt beispielsweise akute Änderungswünsche am Design? Diese Aufgabe kann direkt vorgezogen werden.

PRAKTISCHE TIPPS: WER DIGITAL SEIN WILL, MUSS AUCH AGIL SEIN

SO BAUEN SIE EIN AGILES TEAM AUF

Ob Scrum oder Kanban: Agile Teams wählen die Methode gemeinsam in Bezug auf das Projekt aus. Die Team-Mitglieder bringen verschiedene Fähigkeiten ein, sodass sich das Team ideal ergänzt. Die Werte und Prinzipien des agilen Projektmanagements sollten dabei von allen Mitgliedern bis hin zum Management akzeptiert und gelebt werden. Zu diesem Prozess gehört:

• Den Kunden frühzeitig durch Teilerfolge begeistern
• Ein gleichmäßiges Tempo einhalten
• Information mit den Teammitglieder teilen
• Motivation durch Vertrauen und eine fordernde Projektkultur
• Transparenz und Integration sind entscheidend
• Eine Führungskraft als Coach, die ihre Mitarbeiter unterstützt und die Ziele nicht aus den Augen verliert

 WHITEBOARD UND DIGITALES BOARD IM EINSATZ

Whiteboards kommen im agilen Projektmanagement in verschiedenen Ausführungen zum Einsatz. Software oder virtuelle Boards ergänzen die flexible Methode. Aufgabenbereiche in Form von Post-its lassen sich auf dem Board flexibel bewegen. Keinerlei Technik wird benötigt, um Prozesse anzupassen. Die Visualisierung hilft den Status des Projektes zu erfassen und ist äußerst interaktiv.

TESTING IST DAS A UND O

Auch beim agilen Projektmanagement bedarf die technische Entwicklung eines regelmäßigen Testings. Durch die erzielten Ergebnisse in Sprints können Lerneffekte aus vorangegangenen Schritten herausgezogen werden. Durch eine schrittweise Entwicklung und nachhaltiges Testing kann sowohl der Entwickler als auch der Kunde die klaren Projektfortschritte erkennen. Damit ergibt sich eine hohe Transparenz.

PLANNING: EIN TAG FÜR DAS TEAM

Das Element “Planning” ist ein weiterer Praxistipp für erfolgreiche agile Projekte. Planning gliedert sich in sogenannte Sprint Reviews, Sprint Planning und die Retroperspektive. Die Sprint Reviews präsentieren dem Kunden die Arbeitsergebnisse der letzten Sprints. Im Sprint Planning gehen die priorisierten Aufgaben in die konkrete Arbeitsplanung über. In der Retroperspektive finden Team-Events statt, um Prozesse, das Team-Gefüge oder Projektwerkzeuge noch weiter zu optimieren. Im Planning können alle Mitglieder Feedback geben, sodass sich Änderungen unmittelbar in die Projektarbeit integrieren lassen.

KANBAN VS. SCRUM

Kanban und Scrum sind die gängigsten Methoden des agilen Prozessmanagements. Kanban ist eine relativ freie Prozesssteuerungsmethode, während Scrum ein genaues Vorgehen vorraussetzt. Es bietet dabei aber stets höchste Flexibilität:

3 PRINZIPIEN IM AGILEN PROJEKTMANAGEMENT

• Vereinfachen Sie Prozesse und Strukturen:Jedes neue Projekt sollte so einfach wie möglich aufgesetzt werden, denn die Komplexität wird von ganz allein entstehen.
• Gehen Sie kurze, gemeinsame Wege:Wenn ein Meeting nicht zu einem konkreten Ergebnis oder einer Entscheidung führt, sollten Sie es auch nicht stattfinden lassen. Entschlacken Sie die Meeting-Kultur und lassen sich Ihr Team selbst organisieren.
• Seien Sie offen für Veränderungen:Alte Konzepte und Budget-Planungen für die nächsten 5 Jahre bringen zwar eine Konstante in Ihr Unternehmen, aber keine Innovationen. Verabschieden Sie sich von starren Unternehmensstrukturen und öffnen sich für agile Projektmethoden.

FAZIT

Beim agilen Projektmanagement bedarf es Mut zur kontinuierlichen Veränderung. Der Wille zur Verbesserung der Prozesse ist sowohl bei Scrum wie auch bei der Kanban-Methode Voraussetzung. Alle Mitarbeiter, nicht bloß das Management, sollten dabei beteiligt sein, um eine ganzheitlich effiziente Arbeitsweise zu gewährleisten. Zu viele Projekte scheitern an einem nicht eindeutig definierten Arbeitsaufwand und unerwarteten Herausforderungen.

Der Beitrag Agiles Projektmanagement: Tipps aus der Praxis für die Praxis erschien zuerst auf contentmanager.de.

Besonders wertvoll ist das Feedback von Personen aus dem direkten Arbeitsumfeld, denn selbst erfahrenen Führungskräften fällt es oft schwer, ihren Mitarbeitern konstruktive Rückmeldungen zu geben, wenn sie nicht unmittelbar mit ihnen zusammenarbeiten. Feedbackgespräche im Projektteam bergen jedoch auch einige Hürden, die es zu überwinden gilt: Manche Kollegen möchten nicht als „Besserwisser“ wahrgenommen werden und trauen sich daher nicht, offen auf Schwächen und Stärken anderer hinzuweisen. Andere wiederum äußern Kritik und sind dann überrascht, wenn es negative Reaktionen gibt.

Besonders herausfordernd ist der Feedback-Prozess in Teams, die eine sehr heterogene Struktur aufweisen: beispielsweise, wenn Mitarbeiter des Kunden zum Team gehören oder auch in Projektteams, die aus Mitarbeitern mehrerer organisatorischer Einheiten zusammengestellt sind. Hier bestehen oft Hemmungen, die den offenen und ehrlichen Austausch behindern. Und auch wenn sowohl der Bedarf als auch der Wunsch nach Feedback vorhanden ist, fehlt es oftmals an Wissen, wie man es richtig macht und welche Regeln beim Feedback sinnvoll sind.

Die nachfolgend erläuterte Methode hilft Teammitgliedern dabei, sich fair und konstruktiv Feedback zu geben, indem sie einen Rahmen dafür definiert. Entwickelt wurde dieses Vorgehen für die Retrospektive von Projektteams, in denen Softwareentwickler, Vorgesetzte und Mitarbeiter des Kunden zusammenarbeiten, die jeweils über einen sehr unterschiedlichen Erfahrungsschatz verfügen. Ein Team also, dessen Zusammenstellung ein direktes und offenes Feedback – sowie den konstruktiven Umgang damit – spürbar erschwert. Folgende acht Schritte helfen, eine Retrospektiven so zu gestalten, dass es dennoch relativ leicht möglich ist, offenes – und vor allem für den einzelnen wertvolles Feedback – zu geben Dabei stellen der vorgesehene Ablauf sowie die speziellen Fragestellungen sicher, dass sich die Teilnehmer tatsächlich konstruktives Feedback geben und Wertschätzung füreinander zeigen. Selbstverständlich kann auch der Scrum Master als Teammitglied aktiv an der Retrospektive teilnehmen – in diesem Fall muss jedoch ein externer Moderator die Feedback-Runde leiten.

Schritt 1: Vorbereitung

Benötigt werden: Ein namentlich gekennzeichnetes und mit den entsprechenden Fragen/Bereichen vorbereitetes Blatt für jeden Teilnehmer, idealerweise im DINA2-Format, ein ausreichend großer Tisch, Filzstifte.

Schritt 2: Einstimmung – Abstand zum Tagesgeschäft schaffen

Eine kleine Übung zum Einstieg sollte den Teamkollegen ein „anderes“, entspanntes Setting ermöglichen und Abstand zum Tagesgeschäft schaffen. Beispiele für mögliche Aufgaben:

– Jeder soll etwas von sich erzählen, was die anderen noch nicht wissen.

Oder:

– Jeder erzählt eine Wahrheit und eine Lüge über sich – das Team schätzt, was gelogen ist.

Zeitrahmen: ca. 15 Minuten.

Schritt 3: Erwartungshaltung ermitteln

Die Retrospektive startet mit einer Selbstreflexion der Teilnehmer. So wird allen klar, dass es vorrangig um den Einzelnen persönlich geht. Dafür beantwortet jeder Teilnehmer schriftlich für sich die folgenden zwei Fragen auf seinem Blatt:

– Was kann man von mir erwarten?

– Was erwarte ich vom Team?

Zeitrahmen: ca. 10 Minuten.

Schritt 4: Schriftliche Feedbackrunden

Nach der Einstiegsphase startet die Feedbackrunde. Dazu sollen alle Teilnehmer die folgenden zwei Sätze auf ihrem persönlichen Blatt notieren:

– Was ich an Deiner Arbeit schätze:

– Was ich Dir wünsche, das Dir besser gelingt:

Danach reicht jeder sein Blatt an seinen Tischnachbarn weiter. Dieser vervollständigt schriftlich die beiden oben genannten Bereiche. Dabei sollte der Moderator / Scrum Master nochmals betonen, dass die Antworten sich nicht auf die Person beziehen sollen, sondern auf die geleistete Arbeit.

Die spezifische Formulierung der Feedbackbereiche stellt auch bei offensichtlichen Kritikpunkten sicher, dass das Feedback wertekonform ausgedrückt wird. Bereits von anderen Teammitgliedern notierte Aspekte dürfen nicht wiederholt werden, können aber gegebenenfalls präzisiert oder durch konkrete Beispiele erläutert werden.

Dieser Teil der Aufgabe wiederholt sich so lange, bis jeder Teilnehmer wieder sein persönliches Blatt vor sich liegen hat. Das Resultat: Jeder hat für jeden sowohl Lob als auch Verbesserungspotenziale aufgeschrieben.

Zeitrahmen: 7 Minuten pro Runde.

Schritt 5: Selbstreflexion

Die Retrospektive wechselt nun wieder vom gegenseitigen Feedback in die Selbstreflexion. Jeder liest sein persönliches Feedback, welches die anderen Teammitglieder auf dem Blatt notiert haben. Die Selbstreflektion kann wertvoller werden, indem die Teilnehmer Verständnisfragen zu dem Feedback stellen, das sie erhalten haben. Dadurch kann ein offener Dialog entstehen, der den einzelnen Teilnehmern weiter hilft. Hier sollte sich der Moderator bzw. Scrum Master explizit Gedanken über die Teamdynamik machen: Anschuldigungen und Rechtfertigungen gilt es zu verhindern. Gegebenenfalls sollten vor dem Einstieg in den Dialog nochmals grundsätzliche Feedbackregeln erläutert werden, z.B. Senden einer Ich-Botschaft, entsprechend dem Feedback-Model „WWWW“ – Wahrnehmung, Wirkung, Wunsch, Werte – oder nach dem Model „BAHN“ – Beobachtung, Auswirkung, Hintergrund, Nachfrage.

Folgende Fragen können darüber hinaus dabei helfen, persönliche Schwerpunkte zu setzen, weshalb zwei Bereiche auf dem Blatt vorgesehen sind:

– Darauf bin ich stolz:

– Was nehme ich mit?

Zeitrahmen: 10 Minuten.

Schritt 6: Selbstoffenbarung

Im Anschluss an die Selbstreflexion erläutert jeder Teilnehmer den anderen Teammitgliedern, welche der notierten Aspekte für ihn persönlich besonders relevant erscheinen. Um tatsächlich Änderungen vornehmen zu können, sollte jeder nur ein oder zwei Schwerpunkte zur persönlichen Verbesserung setzen und versuchen, diese nachhaltig zu verbessern, anstatt viele Aspekte jeweils nur ein bisschen anzugehen. Die Entscheidung, was dem Team gegenüber transparent gemacht wird – und was nicht – trifft jeder Einzelne für sich.

Die Selbstoffenbarung kann erweitert werden, indem die Teilnehmer, die dies möchten, die Kollegen im Hinblick auf bestimmte Aspekte um Unterstützung bitten.

Zeitrahmen: 2 Minuten pro Teilnehmer.

Schritt 7: Ausklang – z.B. mit „Pleased & Surprised“

Zum Abschluss der Retrospektive sollte jeder kurz erläutern, was ihn an dieser Feedbackrunde überrascht hat und / oder was ihm besonders gefallen hat.

Zeitrahmen: 1-2 Minuten pro Teilnehmer

Schritt 8: Nachhaltigkeit sichern

Der Moderator / Scrum Master sollte die Teilnehmer dazu ermutigen, sich das Feedback immer wieder einmal anzusehen und zu reflektieren, eventuell kann er das Team auch nach einigen Wochen aktiv daran erinnern. Ebenso kann es sinnvoll sein, nach fünf bis sechs Monaten eine weitere Retrospektive zu veranstalten, die entweder auf der vorherigen aufbaut oder lediglich in der gleichen Form wiederholt wird.

Fazit

Die hier beschriebene Form der Retrospektive wurde bereits mehrfach in Softwareentwicklungsteams, die mit Scrum arbeiten, durchgeführt und von diesen als sehr wertvoll erachtet. Sie hat sich insbesondere bei der Arbeit mit Teams bewährt, die schon eine Weile im Rahmen eines Projekts zusammenarbeiten, aber bei denen sich der offene Austausch aufgrund sehr heterogener Strukturen schwierig gestaltet. Gerade wenn klar ist, dass das Team in dieser Zusammensetzung noch über einen längeren Zeitraum bestehen bleibt, kann diese Form des Feedbacks dazu beitragen, dass sich die Zusammenarbeit und die Produktivität spürbar verbessern.

Ebenso eignet sich die Methode auch für Feedbackrunden im Kontext von Teamklausuren. Die Ergebnisse können auf Wunsch des Mitarbeiters auch im regulären Mitarbeitergespräch berücksichtigt werden. Das Ziel ist dabei stets, Wertschätzung für die Kollegen zu zeigen und gleichzeitig den eigenen blinden Fleck hinsichtlich persönlicher Verbesserungspotenziale zu verkleinern.

Autor: Markus Fidelak, Scrum Master / Teamleiter bei Netpioneer GmbH

Der Beitrag Scrum-Retrospektive für heterogene Teams erschien zuerst auf contentmanager.de.

Der Scrum Master als Trainer

Der Scrum Master bildet die Teammitglieder in den agilen Grundlagen aus und begleitet ein Projekt umfassend über einen längeren Zeitraum hinweg. Als Trainer betreut er die Entwickler, den Product Owner sowie alle weiteren Beteiligten des Unternehmens. Zu Beginn des Projekts stehen zunächst die Entwickler im Fokus. Ziel ist es, das Team zum regelmäßigen Liefern kompletter Features zu bringen. Dies geschieht hauptsächlich durch die Durchsetzung des Scrum Frameworks.

Der Product Owner wiederrum vertritt bei der Produktentwicklung nach Scrum die Businessseite. Er verantwortet Priorisierung, Releaseplanung, Kosten- und Risikoanalyse und hat das Recht, das Projekt betreffende Entscheidungen zu fällen. In vielen Unternehmen hat er dabei jedoch nicht die volle Kontrolle über die Ressourcen, die er benötigt. Der Trainer hat hier die Aufgabe, sowohl dem Product Owner als auch den Personen, die ihn benennen, dessen Verantwortung bewusst zu machen und sicherzustellen, dass er über entsprechende Kompetenzen und Entscheidungsbefugnisse verfügt.

Der Wert eines Scrum Masters als Trainer:

• Er ist ein integrierter Bestandteil der Organisation und damit ein Zeichen für das Engagement der Organisation.
• Den Hauptwert erzeugt er dadurch, dass er allen in der Organisation die agilen Grundlagen vermittelt.

Der Scrum Master als Moderator und Vermittler (Facilitator)

Oft lässt sich die Qualität von Meetings und Meeting-Ergebnissen verbessern. Als Facilitator sorgt der Scrum Master dafür, die Sitzungen effizient zu gestalten. Er vergewissert sich, dass jeder Teilnehmer die Erwartungen an das Meeting kennt und kann fordern, dass das Meeting einen bestimmten Output generiert.

Während des Meetings beteiligt er sich in der Regel nicht aktiv an der Diskussion. Er fasst zusammen und stellt klärende Fragen. Obwohl er sich nicht inhaltlich äußert, folgt er den Diskussionen und achtet auf die Stimmung der Teilnehmer. Dabei ist es von großem Vorteil, wenn er als unparteiisch wahrgenommen wird. Er sorgt dafür, dass sich das Meeting im richtigen Rahmen bewegt, dass der Fokus stimmt und er stellt sicher, dass die benötigten Materialien in der richtigen Qualität vorliegen.

Der Wert eines Scrum Masters als Facilitator:

• Er stellt sicher, dass Meetings mit einem verwertbaren Ergebnis enden – einer Entscheidung, zu erledigenden Maßnahme oder einem gemeinsamem Verständnis der Teilnehmer über einen bestimmten Aspekt.
• Er sorgt dafür, dass keine unnötigen Reibungen entstehen.

Der Scrum Master als Enabler

Agile zu machen, bedeutet lediglich, ein Rahmenwerk einzuführen, welches einige Vorteile hat und Dysfunktionen in der Organisation sichtbar machen kann. Der Scrum Master jedoch führt die Menschen in der Organisation zum Agil sein. Agil zu sein heißt, Produkte zu entwickeln, die Kunden begeistern. Es heißt, in regelmäßigen, kurzen Zeitabständen Nutzerfeedback in die Lösung zu integrieren und so den Wert des Produkts zu steigern. Es heißt, in kurzen Zeitzyklen mit einer konstanten Geschwindigkeit hochqualitative Software zu liefern.

Agil zu werden und agil zu bleiben bedeutet Arbeit und Fokussierung. Vorgehensweisen, Gewohnheiten, Ziele und Prozesse müssen kontinuierlich geprüft, angepasst und verbessert werden. Dem Scrum Master kommt bei diesen Bemühungen eine Schlüsselrolle zu. Er verliert sich nicht in fachlichen oder technischen Details, sondern betrachtet die Organisation aus systemischer Sicht. Er weist gegebenenfalls auf Strukturen hin, die geschäftskritische Prozesse ausbremsen, zeichnet die Wertschöpfungsprozesse auf und zeigt Engpässe, wo sich Arbeit anstaut. Im Hinblick auf das Produktentwicklungsteam sorgt er dafür, dass die Wertschöpfung durch die Förderung der technischen Fähigkeiten gesteigert wird. Darüber hinaus hält er organisatorische Hindernisse vom Team fern und befähigt es, diese selbst zu bewältigen.

Der Wert eines Scrum Masters als Enabler:

• Er führt die Organisation zum Agil sein.
• Kosteneinsparungen durch die Beseitigung unnötiger Arbeit und höhere Gewinne durch die Fokussierung auf wertschöpfende Tätigkeiten.

Der Scrum Master als Konfliktnavigator

Wenn Menschen zusammenkommen, um etwas zu erreichen, geht das meistens nicht ohne Konflikte. Es ist auch nicht gewünscht, eine Arbeitsumgebung zu haben, wo alle stets der gleichen Meinung sind, denn ein homogenes Team tendiert zu einer eingeschränkten Sicht. Große Risiken werden dabei oft ignoriert. Eine Chance, die Entdeckung potenzieller Risiken zu erhöhen, besteht darin, mit heterogenen Teams zu arbeiten. In einem echt heterogenen Team herrscht ständig eine gewisse Konfliktatmosphäre. Die Herausforderung für den Scrum Master besteht darin, das Team in dieser produktiven Konfliktatmosphäre zu halten.

Entscheidend dabei ist, dass ein grundlegender Respekt füreinander herrscht und dass jedes Teammitglied akzeptiert wird. Wenn die Teammitglieder einander vertrauen, kann sich das Potenzial jedes Einzelnen entfalten, wodurch nicht zuletzt die Produktivität deutlich gesteigert wird. Es ist die Pflicht des Scrum Masters, diese Atmosphäre zu erzeugen. Manchmal muss er dafür ein zu homogenes Team herausfordern, manchmal muss er eskalierte Konflikte navigieren. Das kann jedoch nur gelingen, wenn er als unparteiisch wahrgenommen wird – er kann daher nicht gleichzeitig Entwickler oder Produkt Owner und Scrum Master sein.

Der Wert eines Scrum Masters als Konfliktnavigator:

• Er stellt einen bewussten Umgang mit Risiken sicher.
• Er sorgt für ein sicheres Arbeitsumfeld.
• Er bewirkt eine Steigerung der Produktivität.

Der Scrum Master als Mensch

Der Scrum Master behandelt alle gemäß der Überzeugung, dass jeder zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt hat. Gründe für ein Scheitern und dafür, dass nicht in jedem Sprint ein perfektes Produktinkrement erstellt wird, gibt es immer. Im Rahmen von Retrospektiven finden der Scrum Master und das Team diese Gründe heraus.

Der Scrum Master erkennt an, dass die Teammitglieder keine betriebswirtschaftlichen Ressourcen sind, sondern Menschen mit individuellen Eigenschaften, Träumen und Ängsten. Wenn er es schafft, dies jedem Einzelnen klar zu machen, wird auch das Unternehmen irgendwann erkennen, dass die Mitarbeiter nicht Ressourcen, sondern das Herz der Organisation sind. Das ist der Wert, den der Scrum Master als Mensch erzeugt.

Checkliste: Die 5 wichtigsten Aufgaben eines Scrum Masters

• Er vermittelt Entwicklern, Product Ownern und allen weiteren Beteiligten im Unternehmen die agilen Grundlagen.
• Er sorgt dafür, dass Meetings effektiv ablaufen und mit einem konkreten Ergebnis enden.
• Er beseitigt organisatorische Hindernisse und sorgt für eine Fokussierung auf wertschöpfende Tätigkeiten.
• Er sorgt für eine produktive, respektvolle und wertschätzende Atmosphäre und fördert so ein herausforderndes, aber gleichzeitig sicheres Arbeitsumfeld.
• Er nimmt die Teammitglieder als Menschen wahr, nicht als Ressourcen und vermittelt diese Sicht auch dem Unternehmen.

Autor: Björn Radon, Agile Coach / Expert Scrum Master, Netpioneer GmbH (www.netpioneer.de)

Der Beitrag Warum agile Projekte einen Scrum Master brauchen erschien zuerst auf contentmanager.de.

In der komplexen Welt von heute, die geprägt ist von Digitalisierung auf allen Ebenen und mobiler Internetnutzung, versagen Prinzipien des Projektmanagement, die in den letzten 50 Jahren gut funktioniert haben. Seit wenigen Jahren setzen sich im Projektmanagement agile Arbeitsweisen, wie z.B. Scrum oder die Kanban-Methode durch. Insbesondere für Digitalprojekte ist ein agiles Projektmanagement bereits Erfolgstreiber Nummer 1. Absolute Flexibilität und permanentes Testing in der technischen Entwicklung ist dabei das A und O.

VIELE VORTEILE DURCH FLEXIBILITÄT UND AGILITÄT

Agile Ansätze im Projektmanagement fördern die effiziente Teamarbeit und versprechen erfolgreiche Projekte. Die operative Readiness ist dabei eine wichtige Grundvoraussetzung, um erfolgreiche Vorhaben umzusetzen. Agile Prozesse sind geprägt durch enge Abstimmung untereinander, ständige Kommunikation im Projektmanagement, flexible Vorgänge und kurzfristig abgesteckte Ziele.

AGILE METHODEN: SCRUM VS. KANBAN

Nicht nur bei Zalando wird bereits seit Längerem mit der Kanban-Methode gearbeitet, um Projekte schnell und effizient umzusetzen. Bei Kanban werden alle anstehenden To-Dos auf Post-its geschrieben und je nach Projektstatus sortiert. Auf dem Post-it werden neben der Benennung des konkreten To-Dos der Name des Mitarbeiters sowie eine konkrete Deadline vermerkt. Die Klebenotizen werden, je nach Status, in die folgenden Spalten eingeordnet:

• Eingang
• Auftragsklärung
• in Bearbeitung
• Testing
• Qualitätssicherung
• Erledigt

Sehr kurzfristige Projekte, die sogar möglicherweise noch am gleichen Tag erledigt werden müssen, können auf eine sogenannte Fastlane gesetzt werden. So ist auf einen Blick erkennbar, wo es gerade im Projekt hakt und welche To-Dos noch offen sind, bzw. wieviel bereits erledigt wurde. Nachdem die erledigten Aufgaben in der Done-Spalte verschoben worden, können Sie zur Ergebnis- und Effizienzmessung gesammelt und ausgewertet werden. Das Kanban-Board ist somit eine optimale Möglichkeit, sowohl kleinere Aufgaben als auch Groß-Projekte zu planen und visualisieren.

Während Kanban eine relativ freie Methode des Projektmanagements ist, verlangt die Scrum-Methode ein genaues Vorgehen, bietet aber stets höchste Flexibilität. Dies sind die wichtigsten Phasen und Begriffe im Projektmanagement mit Scrum:

• Sprint (Zeiteinheit der Arbeitsperiode)
• Planning (Welche Aufgaben sind zu erledigen)
• Estimating (Wie lange dauern die einzelnen Aufgaben?)
• Dailys (tägliches Stand-up Meeting, max. 15 Minuten Tagesplanung)
• Reviews (Bewertung der Ergebnisse)
• Retrospektive (Rückblick auf die Teamarbeit)

Neben den verschiedenen Phasen und Begriffen sind auch genau abgesteckte Rollenverteilungen wichtig, um ein Scrum-Projekt zum Erfolg zu führen. Ein Team besteht aus sechs bis zehn Mitgliedern und wird von einem Scrum-Master geleitet. Er ist Projektleiter, Mentor, Coach, und Moderator in einer Person und erste Anlaufstelle für alle Projektmitglieder. Der Product-Owner vertritt die Wünsche des Kunden, der auch die lebendige Schnittstelle zum Kunden ist, um diesen komplett aus dem Projektmanagement herauszuhalten. Die Entwickler sind für die technische Umsetzung des Projektes zuständig.

5 Tipps für ein erfolgreiches agiles Projekt:

1. Beginnen Sie zeitig

Legen Sie von Anfang an ein klares Projektziel fest und verfolgen Sie dieses stets mit jedem Teilschritt und To-do. Es sollten frühzeitig alle verantwortliche Projektmitglieder an einen Tisch gebracht werden, um eine klares und einheitliches Ziel vor Augen zu haben. Durch eine langfristige Planung können eventuelle Stolperfallen identifiziert werden und alternative Prozesse entwickelt werden.

2. Entwickeln Sie ein Konzept

Mit jedem formulierten Ziel sollten klare Möglichkeiten der Umsetzung und Verantwortlichkeiten einhergehen. Überlegen Sie sich im Voraus ein gutes Konzept, dass Ihnen Leistungsfähigkeit, Schnelligkeit, Produktivität und dennoch Flexibilität ermöglicht. Fragen Sie sich ob sich Scrum, Kanban oder doch besser die klassische Methode für Ihr individuelles Projekt eignet. Bleiben Sie dennoch flexibel und lernen Sie aus Fehlern. Sollten sich unüberbrückbare Hürden ergeben, müssen Sie zeitnah einen Plan B für den Erfolg Ihres Projekts umsetzen können. Durch die Nutzung einer ausgeprägten Lernkultur fördern Sie Teamwork, Partizipation und Commitment.

3. Definieren Sie klare Verantwortlichkeiten

Aufgaben, Ideen und Risiken müssen aktiv gemanagt werden. Dies kann nur durch eine eindeutige Rollenverteilung und Klärung der Verantwortlichkeiten passieren. Eine offene Kommunikation im Projektteam ist unerlässlich, um Gefahren schnell zu erkennen und zu lösen.

4. Messen Sie Fortschritte

Machen Sie im Verlauf des Projektes erreichte Teilziele transparent, beispielsweise mithilfe von Schulungen oder Reviews. Erfassen Sie Fortschritte sowie Kapazitäten und beleuchten Sie neue Risikofelder.

5. Bleiben Sie positiv

Legen Sie nicht das Augenmerk auf Dinge, die schief gelaufen sind, sondern konzentrieren Sie sich auf die daraus gewonnen Learnings und bleiben Sie positiv. Haben Sie den Erfolg im Blick und wissen stets genau, was dafür nötig ist – und was nicht. Es ist zwar wichtig Krisenszenarien zu entwicklen, doch Sie sollten nicht von den zu erreichenden Zielen ablenken.

FAZIT

Vermeiden Sie eine unklare Arbeitslast und undefinierte Erwartungen im Projekt. Viele Projekte scheitern an einem nicht eindeutig definierten Arbeitsaufwand und unerwarteten Herausforderungen. Alle Beteiligten sollten noch vor Beginn wissen, welche Anforderungen ein Projekt stellt und welche Erwartungen zu erfüllen sind. Darüber hinaus ist es wichtig, individuelle Prozesse zu entwickeln, statt lediglich nach Schema F zu planen.

Der Beitrag Leitfaden Projektmanagement: So führen Sie Ihr Digitalprojekt zum Erfolg erschien zuerst auf contentmanager.de.

Die Netpioneer GmbH  hat für die Kassenzahnärztliche Vereinigung Baden-Württemberg (KZV BW) einen umfassenden Relaunch des Online-Auftritts realisiert.

Als Berufsorganisation der Vertragszahnärztinnen und -zahnärzte Baden-Württembergs stellt die KZV BW die flächendeckende zahnmedizinische Versorgung der neun Millionen gesetzlich Krankenversicherten in Baden-Württemberg sicher. Auf ihrer Website  bietet die KZV BW für die Zielgruppen Patienten, Zahnärzte und Medien umfassende Informationen rund um Zahnpflege, Behandlungsmöglichkeiten, Praxismanagement sowie Beruf und Ausbildung.

Da der bestehende Online-Auftritt in puncto Usability, Design und Performance nicht mehr den aktuellen Anforderungen entsprach, beauftragte die KZV BW Netpioneer mit einem Relaunch, um die Internetpräsenz sowohl technisch als auch optisch auf den neuesten Stand zu bringen. Netpioneer implementierte mit der Open Source-Lösung Hippo ein komplett neues Content Management System und realisierte eine übersichtliche Website mit modernem Design gemäß den aktuellen Standards und Marktansprüchen der Zielgruppen.

Darüber hinaus führte Netpioneer folgende Neuprogrammierungen aus: eine standortbasierte Notdienst- und Praxis-Suche, eine Jobbörse sowie ein Formular für Patientenfragen. Ebenso integrierten die Karlsruher Spezialisten Social Media-Buttons und den persönlichen Servicebereich für Zahnärzte und Praxen. Da sich Netpioneer und die KZV BW für ein agiles Projektvorgehen entschieden hatten, konnte die neue Website fast zwei Monate früher als geplant online gehen.

„Unsere User wollen individuell auf sie zugeschnittene Informationen und rund um die Uhr verfügbare Services. Mit unserer neuen Website www.kzvbw.de gelingt es auf ganz hervorragende Weise, die Erwartungen unserer Nutzer zu erfüllen“, sagt Guido Reiter, Leiter Kommunikation und Medien der KZV BW.

Heute profitieren nicht nur die Besucher von einer intuitiven Navigation, aufgeräumten Content-Strukturen sowie aktuellen Funktionen und Design-Elementen. Das neue CMS sorgt auch dafür, dass sich die Workflows für die Redakteure der KZV BW deutlich verbessert haben, so dass sich neue Inhalte wesentlich schneller und einfacher bereitstellen lassen.

Der Beitrag Neue Website für die Kassenzahnärztliche Vereinigung Baden-Württemberg erschien zuerst auf contentmanager.de.