LET’S TALK
Bucht ein kostenloses und unverbindliches Erstgespräch mit einem unserer Docs oder ruft uns einfach an.
Ein Accelerator (engl. accelerate = beschleunigen) wirkt im Grunde wie ein „Beschleuniger“ für neu gegründete Startups oder Unternehmensbereiche. Durch externe Dienstleister (z.B. Softwareentwickler, Coaches, Berater, ...) wird ein Team aus Mitarbeitern ergänzt, damit man möglichst schnell ein neues Produkt/Innovation zur Marktreife führt. Die Unterstützung erfolgt jedoch meist innerhalb eines sehr begrenzten Zeitrahmens und legt den Fokus auf Schnelligkeit und Wachstum (im Gegensatz zu sogenannten Inkubatoren).
Es gibt sogar richtige Accelerator-Programme, die einer Art „Boot Camp“ für Gründer gleichen. Dabei werden die Unternehmensideen und Geschäftsmodelle, die von den jeweiligen externen Gründerteams stammen, von Spezialisten des Acceleratorprogramms intensiv betreut.
Das Konzept von Acceleratoren ist sehr kostenintensiv und wird in der Praxis in erster Linie von großen Unternehmen oder durch entsprechendes Funding realisiert. Klassische Startups können sich die oftmals massive externe Unterstützung schlichtweg gar nicht leisten. Aus strategischer Sicht sollte man überlegen, ob ein Accelerator sinnvoll ist oder ob man nicht lieber auf einen nachhaltigeren Prozess (z.B. als Inkubator) setzen möchte. Der Knowhow Transfer zwischen Internen und Externen muss sehr gut organisiert werden und man läuft immer Gefahr eines sogenannten Vendor Locked In (=Abhängigkeit zu einem Dienstleister).
Im Februar 2001 entwickelten 17 führende Agilisten (u.a. die Erfinder von Scrum, Extreme Programming, etc.) ein folgende vier Leitsätze über die Werte und Verhaltensregeln agiler Teams:
Diese vier Leitsätze sollen zeigen, was beim agilen Arbeiten im Vordergrund steht (linke Seite) und was im Gegenzug nicht so wichtig ist (rechte Seite).
Viele Agilisten beziehen sich in ihrer täglichen Arbeit auf diese vier agilen Leitsätze und interpretieren diese mehr oder weniger immer etwas unterschiedlich. Man kann aber sagen, dass diese Leitsätze in erster Linie eine Art von Gewichtung darstellen sollen und keine Schwarz/Weiß-Betrachtung sind.
Beispielsweise sind Prozesse und Tools natürlich auch im Rahmen einer agilen Zusammenarbeit sehr wichtig. Allerdings sollte eine Organisation so wenige Prozesse und Tools wie eben notwendig vorgeben und lieber darauf vertrauen, dass das Team für sich einen optimalen Modus entwickelt. Dies fördert die Selbstorganisation und lässt oftmals pragmatischere und zielorientierte Lösungen zu.
Der Begriff ist im Kontext der vierten industriellen Revolution entstanden und umfasst die Veränderungen der Arbeitsformen und Arbeitsbedingungen – sowohl im industriellen Bereich, als auch insgesamt in der Arbeitswelt. Es geht vor allem darum, dass die menschliche Arbeitskraft immer stärker mit der IT zusammenwächst und man dadurch monotone Tätigkeiten weitestgehend für den Menschen eliminiert ("gute Arbeit" steht im Vordergrund). Dies hat vielfältige Auswirkungen auf die Art und Weise, wie wir in Zukunft arbeiten - nicht nur technologisch, sondern vor allem auf der Ebene der Team- und Mitarbeiter-Psychologie.
Vor allem durch die Digitalisierung von Prozessen geprägt, lassen sich hierunter viele andere Begrifflichkeiten wie IoT, New Work, VUCA, digital Workplace oder eben auch agiles Arbeiten miteinander verbinden, ohne dass es immer eine echte Trennschärfe zwischen diesen Begriffen gibt. Der Begriff "Arbeitswelt 4.0" ist jedoch nicht ganz so stark verbreitet und wird eher selten verwendet (vieles wird unter New Work subsummiert).
Der Begriff leitet sich aus dem Lateinischen ars, artis und factum ab und steht letztendlich für ein Arbeitsergebnis bzw. ein Resultat. Im Scrum gibt es offiziell drei Artefakte: das Product Backlog (die priorisierte und strukturierte Sammlung aller bekannten Anforderungen), das Sprint Backlog (das Hausaufgabenheft der Entwickler für den aktuellen Sprint) und das eigentliche Produkt/Inkrement (die Software als solches im aktuellen Stand der Entwicklung).
Der Begriff Artefakt ist zumindest im Deutschen eher weniger verbreitet und wird seltener genutzt. In der Regel wird das entsprechende Artefakt direkt beim Namen genannt (z.B. Product Backlog). Es handelt sich also eher um einen Überbegriff aus der Literatur/Theorie und weniger aus dem gelebten agilen Alltag.
Das Backlog ist ein Überbegriff mit dem man allgemein eine Sammlung von Anforderungen, Aufgaben und To Dos beschreibt, die in der Regel in eine Art von Ticket System verwaltet und gepflegt werden. In der agilen Welt (insbesondere bei Scrum) unterscheidet man dann noch mal zwischen einem Product Backlog und einem Sprint Backlog, wobei sich diese in erster Linie durch die jeweiligen Verantwortlichen und die zeitliche Priorisierung unterscheiden. Auch in Kanban und anderen agilen Frameworks findet man diesen Begriff in ähnlicher Form wieder.
Ein Backlog muss verwaltet und gepflegt werden, damit das/die Team(s) immer wissen, woran als nächstes gearbeitet werden soll.
In der Toolwelt verschwimmt die Differenzierung zwischen Product und Sprint Backlog oftmals, da die Softwarelösungen (z.B. Jira, Asana, Trello, MS Planner, etc.) hierin nur bedingt unterscheiden - meistens lediglich auf der Ebene der zeitlichen Priorisierung. Die Kunst besteht darin, ein Backlog möglichst zielführend und effizient zu strukturieren/pflegen. Nicht selten befinden sich darin etliche hunderte oder gar tausende von Tickets.
Viele Teams haben über die Zeit so viel Anforderungen gesammelt, dass sich im Backlog immer wieder veraltete Stories und Doubletten finden. In diesem Fall hilft nur konsequentes Aufräumen und die Optimierung der Backlog Struktur. Stakeholder fällt es übrigens in der Regel schwer, auf Basis eines Ticket Systems den aktuellen Projektstand zu erkennen. Hierfür eignen sich dann eher andere Sichten (z.B. agile Roadmaps oder Story Maps).
In einem Burndown Chart wird grafisch die noch zu erledigende Arbeit in Relation zu der bereits verstrichenen Zeit (z.B. Sprint oder Iteration) gezeigt. Die noch zu erledigende Arbeit (in Form von Tickets oder Issues) wird üblicherweise auf der senkrechten Achse dargestellt, die Zeit auf der waagerechten. Viele Tools wie Jira bieten Burndown Charts als Standardreport an, in dem eine Ideallinie und eine "echte" Verlaufskurve der abgearbeiteten Tickets angezeigt wird.
Als Skala wird in der Regel die Einheit "Story Points" verwendet. Ein Sprint startet also in der Regel mit einem gewissen Arbeitsvolumen (z.B. 55 Story Points) und wird von Tag zu Tag weniger, da jeden Tag ein paar Aufgaben abgearbeitet werden, welche zuvor im Planning mit einem gewissen Story Point Wert bewertet wurden. Die fallende Linie zeigt also an, wie viele Story Points bisher abgearbeitet (Done) wurden.
Burndown Charts sind ein wichtiges Element für agile Teams, sollten aber auch nicht überbewertet werden. Sie dienen in erster Linie als Indikator für die Teamzusammenarbeit. Nimmt man sich zu viel Arbeit vor, wird der Burndown nicht fertig und es kommt zum Spill Over (eingeplante Aufgaben müssen in den nächsten Sprint/Iteration verschoben werden). Verläuft die Linie zu Beginn eher waagrecht und fällt erst zum Ende des Sprints steil nach unten, spricht dies für ein spätes Testing. Läuft die Linie hingegen während des Sprints im Zigzack hoch und runter, spricht dies für ein suboptimales Backlog Management und ständige Repriorisierungen.
Ein Burndown sagt allerdings nie die ganze Wahrheit. Man kann aber bereits erste Ursachen für vorhandene Probleme ableiten und gleichermaßen den Grad der bereits erzielten Optimierung draus ablesen. WICHTIG: Die Burndowns verschiedener Teams kann man in der Regel nicht miteinander vergleichen (höchstens den Verlauf - nicht aber die Menge der geschafften Story Points). Unter Velocity findet ihr hierzu noch mehr.
Der Change Request (= Änderungsantrag) kommt aus dem klassischen Projektmanagement und hat in der agilen Welt eigentlich keine Relevanz. In einem klassischen Softwareprojekt wird von einem Kunden ein sogenanntes Lastenheft erstellt, in dem alle Anforderungen möglichst detailliert umschrieben sind, die man an eine Softwarelösung hat. Die Dienstleister beantworten diese Anfrage in der Regel mit einem Pflichenheft, welches im Falle einer Beauftragung auch zum Vertragsgegenstand wird. In diesem Pflichtenheft steht drin, wie genau der Dienstleister diese Anforderungen umsetzen wird - ebenfalls so genau wie möglich umschrieben/definiert.
Wenn es dann (nach der Beauftragung) zu Änderungswünschen kommt, werden diese über Change Requests angefragt, bepreist und auch also solche beauftragt. Man könnte also auch sagen, dass es sich um eine formalisierte Art von agilem Anforderungsmanagement handelt, da man hierüber Änderungen an dem zuvor beschlossenem Vorgehen im klassischen Projekt vornehmen kann.
Viele Organisationen (insbesondere große Unternehmen) arbeiten noch in hybriden Strukturen, d.h. die agilen Teams arbeiten zwar nach Scrum & Co. - die Organisation selbst hat aber noch ein klassisches Projekt- oder Portfolio Management darüber gestülpt. Gerade im Rahmen der Vertragsgestaltung kommt es hierbei aber immer wieder zu Schwierigkeiten. Die juristisch anerkannten Vertragskonzepte wie Dienst- und Werkvertrag bieten nur bedingt den Rahmen, den man für eine echte agile Zusammenarbeit benötigt. Man findet in der Praxis deshalb verschiedene Lösungsansätze (z.B. den agilen Festpreisvertrag), die aber in der Praxis nicht wirklich helfen und eher dem mittleren Management eine gewisse Sicherheit vorgaukeln.
Fakt ist: in der agilen Zusammenarbeit sind Change Requests nicht vorgesehen, da wir per se über Feedbackschleifen arbeiten und jegliche Änderung mit einer neuen Anforderung gleichsetzen.
Bei einer Community of Practice handelt es sich um eine selbstorganisierende, praxisbezogene Gemeinschaft von Personen, die sich zu fachspezifischen Themen regelmäßig oder unregelmäßig treffen und austauschen. Je nach Reifegrad kann diese Community aber auch über den einfachen fachlichen Austausch hinausgehen und gemeinsam an Standards, Best Practices oder gar internen Richtlinien arbeiten.
In der Praxis sind vor allem organisationsübergreifende Communities bekannt. Auch unsere Agile Clinic Community auf der Plattform Meetup ist nichts anderes als eine CoP - also Leute, die sich zu einem bestimmten Themengebiet (in unserem Fall "agiles Arbeiten) organisieren, austauschen und Themen treiben.
Immer mehr Organisationen fangen an, interne CoPs aufzubauen - insbesondere dann, wenn man von einer klassischen Ablauforganisation in eine Produktorganisation wechselt. Der Aufbau von lebenden, wirklich selbstorganisierenden CoPs ist allerdings nicht ganz so einfach und sollte nicht über die Management-Ebene getrieben werden.
Software untergliedert man gerne in einzelne Bausteine und Elemente. Eine Komponente ist darin ein Oberbegriff, der ein Modul beschreibt, das im besten Fall von einem Entwicklerteam möglichst autark (weiter)entwickelt werden kann. Je weniger Abhängigkeiten einzelne Komponenten (engl. Components) zueinander haben bzw. je besser die Schnittstellen zwischen diesen organisiert und definiert sind, desto stärker ist eine echte Selbstorganisation innerhalb eines agilen Teams möglich.
In Atlassian Jira gibt es das Element "Component", welches für die Strukturierung von größeren Produkten/Projekten eingesetzt werden kann, damit man mit mehreren Teams an einem großen Backlog arbeiten kann.
In der Praxis wird der Teamschnitt (nach Komponenten) nicht immer beachtet, was bei größeren Projekten/Produkten zu höheren Aufwänden für Abstimmungsprozesse und zu vielen Abhängigkeiten zwischen den Teams führt. Oftmals findet man dort auch eher einen horizontalen Teamschnitt anstatt eines vertikalen Teamschnitts.
In Jira nutzen viele Teams das Element "Component" nicht - schlichtweg, weil dieses in Jira nur wenigen bekannt ist und deshalb oftmals andere Elemente (wie z.B. Epics) verwendet werden oder man über die Verschlagwortung (Tagging) und entsprechende Filter arbeitet.
In einem crossfunktionalen Team finden sich alle Fähigkeiten und Erfahrungen, die es braucht um ein konkretes Produkt oder Ergebnis zu erstellen. Agile Teams sind daher bestenfalls funktionsübergreifend bzw. interdisziplinär besetzt und entwickeln gemeinsam die technische Lösung für eine fachliche Aufgabenstellung. Vor allem in Scrum wird bei der Teamkonstellation sehr stark auf eine crossfunktionale Zusammensetzung geachtet, da nur so ein Inkrement entstehen kann, welches von dem Team auch ganzheitlich verantwortet werden kann.
Echte crossfunktionale Teams bilden die Grundlage dafür, dass ein Team echte Verantwortung für ein Produkt/Service übernehmen kann. Je autarker und eigenverantwortlicher ein Team agieren kann, desto stärker identifiieren sich die Mitarbeiter mit dem Produkt/Service und entwickeln diesen stetig weiter. Gleichzeitig können in einem crossfunktionalen Team besonders schnell Entscheidungen getroffen werden, was vor allem an den kurzen, direkten Kommunikationswegen und der direkten Zusammenarbeit unterhalb von organisatorischen Grenzen liegt.
Dieses Event (oftmals auch nur "Daily" genannt) aus dem Scrum Framework wird in erster Linie von den Entwicklern verantwortet und organisiert. Es dauert 15 Minuten, findet täglich statt und soll dem interoperativen Austausch zwischen den Entwicklern dienen. Oftmals wird über den aktuellen Stand des Sprint Backlogs gesprochen, in dem jeder seinen aktuellen Arbeitsstand mit den anderen teilt und somit alle wissen, woran als nächstes zu arbeiten ist. Aber auch Impediments jeglicher Art werden hier angesprochen und erfasst.
Es handelt sich allerdings nicht um einen Statusreport, sondern vielmehr um ein Art der teaminternen Kollaboration, die sehr stark auf Effizienz und Fokussierung ausgerichtet ist. In der Regel unterstützt ein Scrum Master bei diesem Event - der Product Owner nimmt nicht daran teil.
Dieses Event gehört wirklich den Entwicklern – in der Praxis nehmen trotzdem oftmals die Product Owner teil. Hierbei ist zu achten, dass diese dann eine passive Rolle einnehmen und nur auf eventuelle Fragen der Entwickler eingehen. Das Daily ist definitiv nicht für Anforderungsklärungen oder Refinements gedacht.
Bei vielen Teams hat sich folgende Fragestruktur bewährt:
Einfach gesagt wird die Arbeit eines Teams erst dann zu einem Inkrement, wenn es die entsprechenden Qualitätsmaßnahmen durchlaufen hat. Die Definition of Done schafft ein gemeinsames Verständnis darüber, was zu tun ist, damit die erforderliche Qualität sichergestellt ist und wir von einem auslieferbaren (releasable) Produkt sprechen können. Die DoD wird somit zur Grundvoraussetzung für einen Review oder gar einen Release.
Die DoD wird von den Entwicklern und der gesamten Organisation zusammen erstellt um ein gemeinsames Qualitätsverständnis zu entwickeln – und dieses zu leben. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.
Im Gegensatz zu Akzeptanzkriterien handelt es sich bei der DoD um allgemeingültige Qualitätsstandards und nicht um Spezifikationen einer einzelnen Anforderung.
Die DoD wird leider (immer noch) von vielen agilen Teams sehr stiefmütterlich behandelt. Einmal halbherzig und eher oberflächlich formuliert, hängt sie bei vielen Teams als Poster an der Wand oder ist irgendwo auf einer Confluence oder Sharepoint-Seite abgelegt. In den letzten Jahren haben aber immer mehr Teams den Mehrwert einer wirklich gelebten Definition of Done schätzen gelernt und diese in die Qualitätsstandards fest integriert.
Demzufolge umfasst eine gute DoD folgende Themenfelder:
Eine DoD sollte gelebt werden, d.h. in den täglichen Arbeitsfluss integriert sein. Ein guter Weg ist zum Beispiel, die DoD innerhalb der Retrospektiven als fester Bestandteil zu integrieren - gerade dann, wenn man gemeinsam die aufgetretenen Bugs, Test Issues, etc. bespricht. Ziel sollte sein, dass die DoD zu einem gelebten Dokument des Teams wird, mit dem sich alle identifizieren und welches gemeinsam stetig weiterentwickelt und optimiert wird.
Die Definition of Ready beschreibt die Qualität der Anforderung. Es ist eine Aufstellung von Vereinbarungen, die das Scrum Team trifft. Sie dient zur Entscheidungserleichterung, welche Items soweit so gut beschrieben sind, das sie von den Entwicklern in einem Sprint bearbeitet werden können.
In der Praxis unterscheidet sich die DoR kaum von der Praxis. Allerdings ist es für viele Teams immer wieder eine Herausforderung, diese Qualität überhaupt zu erreichen. Viele stolpern immer wieder im Refinement-Prozess, da die Anforderung zu Beginn nicht immer klar sind und näher spezifiziert werden müssen.
Andere befassen sich in der Praxis immer wieder mit den eigentlichen Kriterien einer DoR. Wann ist eine Anforderung wirklich "ready" und wie kann man sicherstellen, dass die einzelnen Anforderungen wirklich verstanden werden. In diesem Bereich geht es oftmals um die richtige Verwendung von verschiedenen Tools und Systemen - insbesondere in Kombination miteinander.
Ein crossfunktionales und selbstorganisiertes Entwicklerteam, das pro Sprint ein Increment produziert. Die Entwickler sind für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem tragen sie die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Sie sind für die Umsetzung der Product Backlogeinträge verantwortlich.
In Eigenverantwortung
Der Begriff setzt sich aus den Begriffen Development und Operations zusammen. DevOps ist ein Ansatz zur Verbesserung der Zusammenarbeit beider Bereiche mit dem Ziel, hochwertige Produkte zu erhalten.
Der die Digitalisierung begleitende Prozess, in dem vorhandene oder geplante Prozesse, Geschäftsmodelle, Zusammenarbeit, etc. grundlegend neu gedacht werden. Durch die Digitalisierung ergeben sich andere Formen der Produkterstellung, Vernetzung, Arbeitsweisen und Geschäftsmodelle.
Der Prozess, bei dem Daten über informationstechnische Systeme zur Verfügung gestellt werden, die zuvor beispielweise ausschließlich in Papierform zur Verfügung standen.
Als Disruption bezeichnet man eine grundlegend verändernde Innovation, die bisherige Produkte, Geschäftsmodelle, etc. obsolet macht.
Early Adopter gehören zu den Ersten, die eine neue Software, eine neue Idee oder ein neues Produkt übernehmen. Sie sind oftmals entscheidend für den Erfolg eines Produktes, da sie wertvolles Feedback bzw. Verbesserungsvorschläge geben. Somit wird ein Produkt entsprechend weiterentwickelt und findet dadurch eine höhere Akzeptanz bei einer größeren Käufergruppe.
Scrum beruht auf den drei empirischen Säulen: transparency, inspection, adaption. Letztendlich wird damit beschrieben, dass sich Scrum sehr stark auf eine permanent lernende, weiterentwickelnde Arbeitsweise einstellt und diese als Grundlage für die Scrum Abläufe (Events, Artefakte, etc.) nutzt.
Eine größere Aufgabeneinheit, die wiederum in mehrere kleinere Aufgaben (Stories) unterteilt werden kann. Ein Epic ist genau genommen eine User Story, die so groß ist, dass sie zur Bearbeitung in mehrere kleine User Stroies aufgeteilt wird. Innerhalb eines Projektes fasst ein Epic so Anforderungen und Funktionen thematisch zusammen.
Balkendiagramm, stellt die zeitliche Abfolge von Aktivitäten grafisch in Form von Balken auf einer Zeitachse dar.
Es ist der Output nach einem Sprint und somit ein konkreter Schritt in Richtung des Produktziels. Es soll jeweils eine Mehrwert erzielen, also muss es ausliefer- oder nutzbar sein.
Eine Institution, die Gründer:innen/Start-Ups bei der Existenzgründung unterstützt und fördert. Oft auch als Brustkasten bezeichnet, bietet ein Inkubator optimale Bedingungen zur Entwicklung von Geschäftsideen.
Es wird regelmäßig gemeinsam überprüft, welchen Fortschritt man in der letzten iterationsperiode erzielt hat.
Eine agile Projektmanagementmethode; die Visualisierung und Planung eines Projektes erfolgt in Form eines Kanban-Boards.
Führungsverhalten, das zur Digitalisierung passt. Neben der Nutzung von digitalen Kommunikationskanälen und Kooperation geht es darum, das eigene Führungsverhalten der Industrie 4.0-Welt anzupassen. Das bedeutet motivierend, situationsbezogen und mitarbeiterfokussiert zu handeln.
Die Lean Inception ist ein Workshop-Konzept von Paulo Caroli, in dem Elemente von Design Thinking und Lean Startup verwendet werden, um das Minimum Viable Product (MVP) im Sinne eines Lean Product zu definieren.
Die Idee ist, dass ein agiles Team, Squad oder Produktteam ein gemeinsames Verständnis für das Produkt entwickeln, dieses kollaborativ konzeptionieren/planen und sich letztendlich auf eine Roadmap einigen.
Dieses Workshop Format ist vor allem im Rahmen eines Kickoffs während der Sprint Zero (vor dem ersten Sprint) sinnvoll. Alle Teammitglieder bekommen ein klares, gemeinsames Bild von dem, was sie in den nächsten Wochen und Monaten entwickeln sollen. Wir von der Agile Clinic haben dieses Konzept genommen und noch mal weiterentwickelt bzw. angepasst. Daher verwenden wir in unseren Projekten den Begriff Inception Week, da es sich hierbei um eine klar strukturierte Agenda handelt, mit der wir fast alle Projekte starten. Der große Vorteil liegt darin, dass die Teams direkt nach der Inception Week mit der Entwicklung starten können, weil alle konzeptionellen Arbeiten für die nächsten Iterationen bereits erfolgt sind und man ein gemeinsam Ziel anstrebt. Im späteren Verlauf des Projektes kann sich das natürlich noch mal mehr oder weniger verändern - aber wir haben ein klares Bild, wie wir starten.
Lean Thinking ist eine Methode, die Wertschschöpfung ohne Verschwendung fokussiert.
Die fünf Leitprinzipien des Lean Managements:
1.) Value: Der Kundenwert des Produktes ist spezifiziert.
2.) Value Stream: der Wertstrom wird identifiziert.
3.) Flow: Der Wertstromfluss ist unterbrechungsfrei. Verschwendung wird vermieden.
4.) Pull: Der Takt der Bearbeitung ist gesteuert, z.B. nach Kundenauftrag oder Vorgaben eines Auftraggebers.
5.) Perfection: Es wird auf kontinuirliche Verbesserung (KVP) geachtet.
Ein Minimum Viable Product (oder auch manchmal als Minimum Valuable Product beichnet) wird im Deutschen als ein „minimal brauchbares oder existenzfähiges Produkt“ verstanden. Gemeint ist damit die erste funktionsfähige Iteration eines Produktes, die genau so viel Funktionen bietet, dass man sie einsetzen/nutzen kann (z.B. auf den Markt bringen kann). Getreu dem Motto "fail early, fail cheap" geht es also in erster Linie darum, möglichst früh die Produktidee bzw. die Lösung im Markt zu validieren.
In der Praxis wird der Begriff sehr unterschiedlich gelebt. Insbesondere deusche Unternehmen tendieren eher dazu, ein MVP als ein relativ weit gereiftes, fast komplett fertiges Produkt zu definieren. Wenn das Management von einem MVP spricht, meint es oftmals ein Produkt, mit dem man auch im Wettbewerb bestehen kann. Genau hier entstehen dann die Konflikte, da dieser Reifegrad naturgemäß erst nach einer längeren Entwicklungszeit erreicht wird und man eben NICHT so schnell die Fehler entdeckt, die man erst im echten operativen Betrieb findet.
Immer mehr agile Teams verwenden daher den Begriff MCP (Minimum Crappy Product) um auf dem Weg dorthin auch schon mit Vor-Versionen arbeiten zu können/dürfen, bei denen die Erwartungshaltung nicht so hoch liegt und man aber frühstmöglich in die Feedbackschleife kommt. Hierzu gibt es ein sehr schönes Video von Jeff Patton auf YouTube.
OKR ist ein Akronym für Objectives and Key Results. OKRs sind ein Leadership-Tool der modernen und fokussierten Führung. Mit OKRs erreicht man eine einheitliche Ausrichtung, Commitment und Transparenz, um unternehmensweit die Umsetzung der Strategie zu unterstützen. Die Grundidee ist, dass jedem Ziel (Objective) ein Schlüsselergebnis (Key Result) zugeordnet werden kann.
OKRs leiten sich aus dem Moals (mid-term goals) ab und werden in der Regel quartalsweise festgelegt.
Planning Poker/Scrum Poker ist eine konsensbasierte, gamifizierte Schätztechnik des Aufwands oder der relativen Größe von Produktentwicklungsaufgaben in der Softwareentwicklung.
Das Product Backlog ist eine emergente Liste von User Stories bzw. Anforderungen (Product Backlos Items) für ein zu entwickelndes Produkte. Es ist die einzige Quelle, aus der sich das Scrum Team bedient, um ein Produkt zu entwickeln. Der Product Owner ergänzt und priorisiert die Liste fortlaufend mit dem Ziel der Wertmaximierung für das Produkt.
Im Refinement-Meeting werden diese Product Backlog Items in kleinere, präzise Elemente aufgeteilt und so gut definiert, dass die Entwickler im Verlauf eines Sprints diese ohne Probleme umsetzen können.
Das Produktziel (Product Goal) beschreibt das Produkt im gewünschten Endzustand. Es ist somit das langfristige Ziel und dient dem Scrum Team als Planungsleitplanke.
Alle im Product Backlog hinterlegten User Stories zahlen auf das Produktziel ein.
Trägt Verantwortung für die Ergebnismaximierung des Produkts sowie für das Backlog Management. Entscheidungen des Product Owners müssen von der gesamten Organisation respektiert werden.
Der/ die Produktverantwortliche pflegt das Product Backlog und vermittelt zwischen Stakeholdern und Entwicklern.
Die Produktvision beschreibt das “Warum” des Produkts – sie ist somit das Leitbild für die Produktentwicklung und immer auf einen längeren Zeitraum ausgerichtet.
Das Pull-Prinzip (engl. "pull" steht für "ziehen") kommt eigentlich aus der Logistik bzw. aus der Produktionsplanung und hat über das klassche Kanban (entwickelt von Toyota) seinen Weg in die agile Welt gefunden. Das Pull-Konzept sieht vor, dass sich die Mitarbeiter/Teams die Arbeit aus dem Backlog aktiv holen (=ziehen), anstatt diese einfach aufgedrückt (=push) zu bekommen. Typischer Weise unterstützt man diesen Prozess durch den Einsatz von Work-in-Progress-Limits (WIP-Limits), also durch die Limitierung der in Arbeit befindlichen Aufgaben. Lest hierzu mehr unter Kanban.
Sehr viele Teams arbeiten bereits nach Kanban (oder in Kombination mit Scrum auch Scrumban) und nutzen entsprechende Kanban-Boards für die Visualsierung. Das Pull-Prinzip wird allerdings noch nicht bei allen Teams gelebt – Gleiches gilt für die WIP-Limits. Wenn man das Pull-Prinzip konsequent anwendet, kann man deutlich schneller die eigentlichen Bottlenecks aufdecken und diese gezielt als Team optimieren.
Der Vorgang, durch den Product Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden.
Scrum ist ein leichtgewichtiges Rahmenwerk für die agile Produktentwicklung, in dem ein selbstorganisierendes Team durch einen iterativen Prozess ein Produkt/Service entwickelt und diesen stetig optimiert. Das ulitmative Ziel besteht in der Wertmaximierung. Scrum wurde 1993/1994 durch Ken Schwaber und Jeff Sutherland entwickelt, wobei sich der Namen aus einem Spielzug im Rugby ableitet, bei dem sich die Teams eng zusammenstellen und ihre Kräfte bündeln. Scrum bedeutet frei übersetzt soviel wie "Gedränge" oder noch freier übersetzt "zusammenraufen".
Wie alle Frameworks befasst sich der Scrum Guide (das Regelwerk von Scrum) vor allem mit dem "was" und nicht mit dem "wie". Das Framework kennt drei Rollen bzw. Verantwortlichkeiten: den Product Owner, den Scrum Master und den/die Entwickler. Alle anderen Akteure werden als Stakeholder bezeichnet und nicht näher behandelt. Zudem umfasst das Framework drei Artefakte und fünf Events, die in Kombination den gesamten Ablauf des Scrum Prozesses umschreiben, der sich von Iteration (Sprint) zu Iteration permanet wiederholt.
Scrum ist mit großem Abstand das wohl bekannteste und am stärksten verbreitete agile Framework. Es lässt sich hervorragend mit anderen agilen Frameworks wie Kanban oder DevOps kombinieren und bietet die Möglichkeit, auch größere Produkte durch entsprechende Skalierungsframeworks wie SAFe, LeSS & Co. zu entwickeln.
In der Praxis gibt es allerdings auch zahlreiche Hürden. Die wenigsten Organisationen sind in ihrem Aufbau und bestehenden Rollenmodell für agile Frameworks konzeptioniert und müssen entsprechend angepasst werden. Dies ist nicht ganz so einfach und erfordert einen größeren Change Prozess. Deshalb wird Scrum in vielen Organisationen mehr oder weniger stark angepasst - was nicht immer hilfreich ist. Ein Scrum Master soll bei der Implementierung und Anpassung von Scrum unterstützen – aber auch diese Rolle wird in der Praxis nicht immer richtig positioniert und/oder besetzt.
Ist der Leitfaden zu Scrum Framework, der die Regeln, Rollen, Events und Artefakte beschreibt Er wurde von Ken Schwaber und Jeff Sutherland verfasst.
Trägt Verantwortung für die Einführung des Scrum Frameworks und stellt sicher, dass das Scrum Team sowohl theoretisch versteht als auch praktisch anwendet. Er hat damit drei Jobs:
dem Product Owner coachen und beraten, wie man das Product Backlog bestmöglich organisiert und wie man sich auf den Mehrwert fokussiert
die Entwickler auf ihrem Weg in die Selbstorganisation unterstützen und dabei helfen, dass diese Verantwortung für die technische Lösung übernehmen können
die Organisation dabei unterstützen, agile Frameworks (wie z.B. Scrum) erfolgreich zu implementieren, in dem er/sie sich um die Impediments (Hürden) kümmert, die ggf. noch im Weg stehen.
Das Scrum Team besteht aus einem Scrum Master, einem Product Owner und Entwicklern. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt‐Ziel.
Das Scrum Teams ist interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht.
Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Es ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholdern, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert - deshalb ist es auch als Ganzes ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Inkrement zu schaffen.
Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren.
Daher sollten sie sich ein Produkt‐Ziel, ein gemeinsames Product Backlog und einen Product Owner teilen. Auch hier gilt: je autarker das Team agieren kann, desto besser kann es seine Aufgaben wahrnehmen.
In der Praxis sind die Teams leider nicht immer so geschnitten (gerade bei größeren Produkten/Services), dass sie wirklich autark arbeiten und agieren können. Je mehr Abhängigkeiten zwischen Teams bestehen, desto schwieriger wird es, wirklich agil zu arbeiten. Deshalb empfehlen wir einen vertikalen Teamschnitt (Komponenten-, Feature-, Journey-Teams, etc.) anzustreben, anstatt eines horizontalen Teamschnitts (z.B. Frontend-, Backend-Team).
Scrum beruht auf fünf elementaren Werten, die im täglichen Leben eine übergeordnete Rolle spielen:
Die fünf Werte können in der Praxis nicht immer konsequent gelebt werden. Damit ein Scrum Team ein echtes Commitment entwickeln kann, muss es auch wirklich Verantwortung für ein Produkt/Service übernehmen können. Abhängigkeiten zu anderen Teams und ungünstige Teamschnitte bremsen dies jedoch immer wieder aus.
Gerade bei deutschen Organisationen ist man oftmals als Unternehmen weniger offen für echtes Feedback und zögert dieses heraus. Ein MVP ist oftmals schon sehr weit entwickelt und eher ein fertiges Produkt. Demzufolge kann erst sehr spät echtes Feedback eingeholt werden, was aus wirtschaftlicher Sicht (und auch im Bereich des Markteintritts) nicht zu empfehlen ist.
Scrum + Kanban. Bei der Verschmelzung der beiden agilen Methoden wird Kanban zur Visualisierung genutzt, die Organisation richtet sich nach den Scrum Events.
Ein Scrum Team ist selbstorganisiert und funktionsübergreifend tätig. Sie wählen im Team selber wie sie die Arbeit am besten erledigen und werden nicht von außen gesteuert. Daraus ergibt sich, dass sie alle Kompetenzen innerhalb des Teams benötigen, um ihre Aufgaben unabhängig von anderen erledigen zu können.
Ein Spike ist eine User Story oder ein Task, welches auf das Ziel ausgerichtet ist, eine Frage zu recherchieren oder ein Problem zu lösen.
Der Sprint ist das Zeitintervall, in dem die Entwickler die im Sprint Backlog festgelegten Anforderungen realisiert. Somit ist er das Kernelement für die Produktentwicklung. Die Sprint-Länge wird vorab festgelegt und bleibt dann für den gesamten Produktentwicklungszeitraum gleich. Ein Sprint dauert maximal vier Wochen. Ein neuer Sprint beginnt unmittelbar nach Abschluss des vorangegangenen Sprints.
Das Sprint Backlog besteht aus dem Sprintziel und den Items, die die Developer im Planning aus dem Product Backlog ausgewählten haben. Es ist der Plan für die Entwickler für den aktuellen Sprint, mit dem sie das Sprintziel erreichen wollen. Somit stellt es einEchtzeitbild über den aktuellen Status der Entwicklungsarbeit in dem aktuelle Sprint dar.
Das Sprint-Ziel (Sprint Goal) ist die einzige Zielsetzung, die sich das Scrum Team für den jeweilige Sprint gegeben hat. Mit der Festlegung des Sprint-Ziels geben die Developer ein Commitment darüber ab, welche Elemente sie bis Ende des Sprints entwickelt haben wollen. Somit wird ein fokussiertes Arbeiten bei gleichzeitiger Flexibilität in Bezug auf die genaue Arbeit ermöglicht.
Das Sprint-Ziel wird während des Plannings definiert und in den Sprint-Backlog übernommen.
Planung und Commitment des Scrum Teams darüber, was sie im nächsten Sprint umsetzen möchten. Im Planning wir das Sprint Backlog erstellt – der Plan für die Developer für diesen Sprint. Die Developer schätzen den Aufwand pro Task.
Ein Scrum Event, bei dem es um den gemeinsamen Rückblick des Scrum Teams auf den Verlauf des aktuellen Sprints in Bezug auf die Qualität des Sprints, die Zusammenarbeit im Team und Verbesserungsmöglichkeiten geht. Es dient zur Steigerung der Qualität und Effektivität. Das Team überprüft die Interaktionen, Prozesse, Tools und die Definition of Done. Es bespricht was im letzten Sprint gut gelaufen ist und was verändert werden soll. Mit der Sprint Retrospective schließt der Sprint ab. Sie ist auf maximal drei Stunden für einen vierwöchigen Sprint festgelegt - bei kürzeren Sprints entsprechend kürzer.
Das Sprint Review Event dient dem Zweck, das Ergebnis eines jeweiligen Sprints zu überprüfen und Anpassungen für die weitere Entwicklung festzulegen. Das Scrum-Team stellt während des Events den Stakeholdern die Ergebnisse ihrer Arbeit vor. Es ist ein Arbeitstermin, bei dem auch das Product Backlog entsprechend des Product Goals angepasst wird, sofern es neue Erkenntnisse gibt.
Das Sprint Review ist zeitlich begrenzt auf maximal vier Stunden bei einem vierwöchigen Sprint. Bei kürzeren Sprints ist auch das Event entsprechend kürzer.
Story Points sind eine Maßeinheit zur Einschätzung des Gesamtaufwandes, der für die vollständige Umsetzung eines Product Backlog Items nötig ist.
Bei einer testgetriebenen Entwicklung schreibt der Entwickler zu Beginn einen Test (z.B. Unit Test) gegen die Akzeptanzkriterien der Anforderung (z.B. einer User Story). Erst danach fängt er mit der eigentlichen Programmierung an. Dadurch wird schon während des Codings geprüft, ob der Code das gewünschte Ergebnis liefert. Anschließend werden Code + Test als Paket auf die entsprechende Stage (Umgebung) geschoben, wo dieser Test im Rahmen der Testautomatisierung immer wieder durchgeführt werden kann, sobald es neue Deployments gibt. Damit wird sichergestellt, dass bestehende
Auch wenn TDD viele Vorteile bietet, wenden nur sehr wenige Teams diesen Ansatz durchgängig bei ihrer täglichen Arbeit an. Gerade zu Beginn eines Projektes ist es natürlich zeitaufwendiger, für jeden Code einen entsprechenden Test zu schreiben und es setzt sehr viel Disziplin im Team voraus. Allerdings lassen sich über solche Ansätze viele technische Schulden vermeiden, da man von Beginn an eine deutlich stabilere und vor allem automatisiert testbare Produktumgebung erhält. Wenn man jedoch ein echtes Produkt (App, Service, etc.) langfristig betreiben und entwickeln möchte, führt kaum ein Weg an einem ordentlichen Testmanagement vorbei.
Timeboxing ist eine effektive Methode des Zeitmanagements. Die Timebox ist ein fester Zeitrahmen, innerhalb dessen ein Vorgang bzw. ein Event erledigt sein muss.
Im Scrum Framwork gibt es folgende timeboxed events:
Die Nachvollziehbarkeit von Tätigkeiten, Ergebnissen und Arbeitsschritten für alle Team-Mitglieder und Stakeholder.
Der Use Case (Anwendungsfall) beschreibt die Interaktion zwischen Anwender und Software. Es wird aus Kundensicht beschrieben, wie die Software reagieren soll, um das Bedürfnis des Nutzers (Anwenders) zu befriedigen.
Beschreibt die Anforderungen an die Funktionalität eines Software-Features aus Sicht des Endnutzers. Ein kurzer, einfacher Satz, der zusammenfasst, was der Nutzer will – ohne technische Informationen und für jede Person verständlich.
Beispielaufbau: Als [Nutzer] möchte ich [Funktion], damit/um/weil [Wert].
Die Velocity im agilen Umfeld ist eine Maßeinheit für die Schnelligkeit eines Entwicklerteams. Sie misst die Arbeitsmenge, die die Developer in einem Sprint bewältigen können. Im Laufe der Zusammenarbeit wird die Velocity von den Entwickler immer passgenau eingeschätzt.
Die Velocity hilft dem Product Owner zur Release-Planung, indem er dadurch relativ genau bestimmen kann, wie viele Sprints die Entwickler für bestimmte Funktionalitäten eines Produkts benötigen.
VUCA (bzw. deutsch VUKA) ist das Akronym für Volatility, Uncertainty, Complexity, Ambiguity.
In der Regel fällt der Begriff im Zusammenhang mit der "VUCA-World" und beschreibt, dass unsere Welt zunehmend komplexer, unberechenbarer und als mehrdeutig empfunden wird.
WIP-Limits beschränken die maximale Anzahl an Arbeitselementen in den verschiedenen Spalten eines Kanban-Boards. Durch die WIP-Limits entsteht eine Fokussierung darauf, einzelne Elemente erstmal fertigzustellen, bevor etwas Neues dazukommt.
Bucht ein kostenloses und unverbindliches Erstgespräch mit einem unserer Docs oder ruft uns einfach an.