Agiles ABC

28. Nov 2018
Michaela Ulrich

Wir wissen mittlerweile, dass Agilität nicht nur eine Anhäufung englischer Begriffe ist, sondern ein sinnvolles Organisationskonzept für Unternehmen. Doch trotzdem kann man mit all den Begriffen – besonders anfangs - leicht durcheinanderkommen. Deswegen wollen wir Euch den Start erleichtern - und vielleicht auch für uns ein Nachschlagewerk aufbauen - und erklären folgend alle Begriffe, die bei uns immer wieder fallen und was sie bedeuten. 

Titelbild agiles ABC

Agilität

Agiles Arbeiten ist zurzeit ein großes Thema, sowohl in kleinen wie auch in großen Unternehmen. Im Wesentlichen geht es darum, in einer Welt ständiger Veränderungen schneller und flexibler auf neue Problemstellungen reagieren zu können. Dies geschieht, indem in kürzeren Abständen und mit ständigem Kundenfeedback am Produkt gearbeitet wird, die Entscheidungswege verkürzt werden und die interdisziplinären Teams mehr Eigenverantwortung erhalten, um immer bessere Ergebnisse erzielen zu können.

Agiles Manifest

Dieses Manifest wurde von 17 Experten entwickelt und beschreibt die 4 Werte und 12 Prinzipien der agilen Softwareentwicklung. Es bildet die Grundlage für Scrum und weitere agile Methoden und Frameworks.

Backlog

Das Backlog ist eine Sammlung aller Anforderungen, die noch zu erledigen sind. Alle neuen, projektbezogenen Aufgaben werden in diese Liste eingetragen und warten dort auf Abarbeitung. Man unterscheidet das Product Backlog, also alle das Produkt betreffenden Anforderungen und das Sprint Backlog, also die Anforderungen, die im jeweiligen Sprint abgearbeitet werden.


Boards

Oft werden unterschiedliche Boards eingesetzt, um die Aufgaben eines Sprints zu visualisieren und den aktuellen Stand ablesen zu können. Typisch für Scrum als agile Methode sind die Scrum Boards: dort werden die jeweiligen Tasks des Sprints priorisiert, zugeteilt und in Rubriken wie "to do" oder "in progress" eingeteilt. Es gibt analoge Boards mit Post-It´s oder die digitale Variante, zum Beispiel mit Tools wie JIRA.

Business Owner

Der Business Owner, kurz BO, ist eine bei empiriecom neu geschaffene Rolle um den Kontakt zu den Mandanten (Baur und Unito) noch besser zu pflegen. Der Business Owner ist das Pendant zum Product Owner und vertritt die Wünsche und Bedürfnisse des Kunden als Teil des interdisziplinären Teams. So kann das Produkt noch besser an die Mandanten angepasst werden.

Daily

Das Daily stellt einen der wichtigsten Termine der agilen Methode Scrum dar. Das Daily findet – wie der Name bereits erahnen lässt – jeden Tag, meistens morgens statt. Standardmäßig trifft sich dabei das gesamte Team und jedes Mitglied erzählt reihum an welchen Tasks es am Vortag gearbeitet hat, welche es heute bearbeitet und ob es möglicherweise Probleme dabei gibt. So wird die Zusammenarbeit und Kommunikation im Team gestärkt und Schwierigkeiten können schneller beseitigt werden.

Designer UX/UI

Unsere Teams beinhalten neben den typischen agilen Rollen auch User-Experience und User-Interface Designer. Durch die direkte Zusammenarbeit von Designern und Entwicklern können neue Features am Produkt schneller realisiert werden, da eine Idee nicht mehrere Abteilungen durchlaufen muss.

Developer

Egal ob Frontend oder Backend – Entwickler sind ein wichtiger Teil von agilen Teams. Sie sind die Programmierer, die sich um die Umsetzung neuer Features kümmern und den bestehenden Code warten und verbessern.

Impediment

Als Impediment werden alle Arten von Hindernissen bezeichnet, die die Abarbeitung einer Aufgabe behindern. Diese müssen durch den Scrum Master beseitigt werden, um den Weg für die Entwickler freizumachen.

Interdisziplinär

Agile Teams bestehen nicht mehr aus fachlichen Teams, deren Mitglieder sich auf ein gleiches Thema spezialisiert haben, sondern aus interdisziplinären Teams. Spezialisten verschiedener Fachrichtungen arbeiten nun zusammen. Dies sind im einzelnen Product Owner, Scrum Master, Entwickler und Designer, jeder auf seinem Gebiet hoch qualifiziert. Durch diese Zusammenstellung müssen Aufgaben nicht mehr durch verschiedene Abteilungen gereicht werden, sondern können gleich bei der ersten Ausarbeitung perfektiert werden.


Kanban

Kanban ist eine agile Methode, bei der die Verbesserung aller Prozesse angestrebt wird. Dabei wird die Abarbeitung paralleler Aufgaben limitiert, um das Multitasking zu reduzieren und einzelne Tasks schneller umzusetzen.

Planning

Das Planning, auch Sprint Planning genannt, ist das erste Meeting zu Beginn eines neuen Sprints. Hierzu kommt das gesamte Team zusammen. Meist wird der Termin vom Product Owner geleitet. Er wählt dafür Aufgaben aus dem Product Backlog, welche im Sprint bearbeitet werden sollen. Diese werden dann in das Sprint Backlog übertragen.

Planning Poker

Das Planning Poker, oder auch Scrum Poker, bezeichnet eine gamifizierte Technik zum Schätzen der Komplexität einer Aufgabe. Dabei werden Karten mit Zahlen an die Teammitglieder verteilt, welche diese zum Schätzen verdeckt auf den Tisch legen, gemeinsam umdrehen und anschließend diskutieren können. Dadurch werden die einzelnen Teammitglieder nicht von der Meinung anderer beeinflusst, jeder Beitrag wird gewertet und nichts vergessen. Kommt es zu Unstimmigkeiten in der Bewertung werden die Schätzungen besprochen und die Anzeige mit den Karten wiederholt, bis eine Übereinstimmung erreicht wird.

Product Owner

Der Product Owner, oder kurz PO, ist für das Team der fachliche Ansprechpartner, der sich mit dem Produkt und all seinen Feinheiten auskennt. Er steht am engsten in Kontakt mit dem Kunden und kennt dessen Wünsche. Dadurch kann er den Entwicklern bei Fragen zum Produkt jederzeit behilflich sein.

Pull-Prinzip

Im klassischen Projektmanagement werden Aufgaben mittels des Push-Prinzips verteilt: eine Person entscheidet, wer welche Aufgaben erledigen soll und teilt sie entsprechend zu. Im agilen Umfeld wird das Pull-Prinzip gelebt, bei dem jede Person selbst entscheidet, welche Tasks sie übernehmen will. Das Teammitglied wählt hierzu aus einem Pool von Aufgaben, meist dem Sprint Backlog, eine aus, bearbeitet diese und geht danach zur Nächsten über.


Refinement

Das Refinement ist ein vom Product Owner geleiteter Termin, bei dem priorisierte Themen aus dem Product Backlog vorbereitet werden, um diese im nächsten Sprint bearbeiten zu können. Wenn User Stories noch Fragen aufwerfen oder Probleme darstellen, kümmert sich der Product Owner um die Bereinigung dieser, fragt eventuell bei den zuständigen Stellen nach oder formuliert die Aufgaben besser verständlich. In jedem Sprint sollte Zeit für das Refinement reserviert werden, um den nächsten Sprint perfekt starten zu können.

Retrospektive

Am Ende jedes Sprints findet ein wichtiger Termin statt: die Retrospektive oder kurz Retro. Dieses Treffen wird vom Scrum Master geleitet und betrifft das interne Team ohne Führungskräfte oder Stakeholder. Alle Teammitglieder kommen zusammen, besprechen den abgeschlossenen Sprint und diskutieren sowohl über Probleme oder Hindernisse, welche entstanden sind, also auch darüber, was gut lief und beibehalten werden sollte. Hierbei geht es nicht um fachliche Aspekte, sondern die menschliche Zusammenarbeit im Team selbst, was das Teamwork und die Produktivität steigern soll.

Review

Die Review ist ein abschließender Termin in jedem Sprint, bei dem alle erledigten Aufgaben mit dem Product Owner und weiteren interessierten Stakeholdern überblickt und fachlich bewertet werden. Dieser Termin dient der Vorstellung und Übersicht darüber, welche Neuerungen entwickelt wurden und fördert zudem neue Ideen zur weiteren Verbesserung der Produkte zu Tage. Dabei wird entschieden, ob die Aufgaben korrekt ausgeführt wurden oder zurück in das Backlog müssen

Scrum

Scrum ist die wohl bekannteste agile Methode, die aktuell in Unternehmen eingesetzt wird und die auch wir bei empiriecom verwenden. Die Methode verkörpert den Ansatz “empirisch, inkrementell und iterativ” und baut ebenfalls auf dem agilen Manifest auf.

Scrum Master

In der agilen Methode Scrum gibt es eine Rolle namens Scrum Master. Dieser ist zuständig für die Verbesserung des Teamzusammenhalts und der Zusammenarbeit. Er bedient sich dabei aus einem Set von Methoden, um Hindernisse oder Probleme innerhalb des Teams aufzudecken und zu beseitigen. Der Scrum Master kümmert sich um alles Organisatorische, wie das Planen von Meetings und Terminen und sorgt dafür, dass die agilen Prozesse eingehalten werden.

Sprint

Als Sprint wird eine zeitliche Einheit zum Bearbeiten von Aufgaben bezeichnet. Je nach Unternehmen dauert ein Sprint zwischen 1 und 3 Wochen. Die Teams bei empiriecom legen ihre Sprintdauer eigenständig fest. Zu Beginn findet immer ein Sprint Planning statt, um Aufgaben aus dem Product Backlog in das Sprint Backlog zu übertragen. Während des Sprints arbeiten die Entwickler dann an den jeweiligen Tasks. Und am Ende eines jeden Sprints findet eine teaminterne Retrospektive sowie eine teamübergreifende Review statt.

Stand-Up

Im agilen Umfeld wird Stand-Up oft mit Daily Stand-Up gleichgestellt. Wir bei empiriecom unterscheiden dabei jedoch. Einerseits gibt es das Daily (wie unter “Daily” beschrieben) und andererseits ein Stand-Up, welches ein vom Management organisierter Termin ist, bei dem alle Mitarbeiter zusammenkommen und über alle wichtigen, die Firma betreffenden Anliegen, diskutieren. Die Mitarbeiter haben die Möglichkeit bei diesem Termin Themen, die sie beschäftigen, offen anzusprechen.. Dieser Termin findet üblicherweise im Stehen statt und erhält daher auch seinen Namen. Bei anderen Unternehmen wird diese Art des Zusammenkommens auch Townhall-Meeting genannt.

Story Points

Story Points sind eine Punkteeinheit, um User Stories zu bewerten. Je mehr Punkte eine Aufgabe dabei erhält, desto „größer“ ist sie. Welche Kriterien – beispielsweise Komplexität, Zeitaufwand oder Einarbeitungsaufwand - genau bewertet werden, entscheidet jedes Team selbstständig. Story Points können teamübergreifend nicht verglichen werden, da jedes Team eine eigene Dynamik beim Bewerten entwickelt. Die durchschnittliche Menge an geschafften Story Points pro Sprint kann dann als Richtwert für darauffolgende Plannings verwendet werden.

User Story

Eine User Story, oder Anwendergeschichte, ist eine Anforderung des Kunden an das Produkt, also ein Item aus dem Product Backlog, dass noch bearbeitet werden muss. Die User Stories sind bewusst kurz und knapp gehalten und werden meist in Umgangssprache formuliert. Im Gegensatz zu klassischen Requirements erläutern User Stories auch den Grund, warum etwas getan werden muss. Der Grund oder der Anlass ist für das Team wichtig, um eine passende Lösung zu entwickeln.


Zusammenfassend: Sprints sind nicht nur schnelle Kurzstreckenläufe, ein Product Owner ist nicht jeder, der schon einmal etwas gekauft hat und beim Planning Poker kann man auch kein Geld gewinnen - leider. Hoffentlich sind trotzdem einige Sachen nun klarer.

Verwendet Ihr bei Euch noch weitere Begriffe oder habt andere Definitionen? Schreibt uns doch! Wir freuen uns.

0Noch keine Kommentare

Ihr Kommentar
Antwort auf:  Direkt auf das Thema antworten
3041 + 3
Diese Webseite verwendet Cookies. Durch die Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Datenschutzinformationen