Modern Project Management - An introduction to Agile
•Download as PPTX, PDF•
0 likes•260 views
Basic introduction to Agile methodologies, why they are good, how they are implemented and how to keep the teams' output as efficient and effective as possible. Original presentation at EBC Hochschule in Hamburg Germany by Dr. Konstantin Wemhöner
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Modern Project Management - An introduction to Agile
Similar to Modern Project Management - An introduction to Agile (20)
Recently uploaded
Recently uploaded (9)
Modern Project Management - An introduction to Agile
- 1. 1 MODERN PROJECT MANAGEMENT an introduction to agile methodology HAMBURG 1ST NOVEMBER 2018
- 2. 2 BI, DATA & MARKETING DR. KONSTANTIN WEMHÖNER Data science, BI and growth marketing Human biology, PhD on cardiac arrhythmia Worked in marketing and BI for 6 years before self-employment Building data-driven marketing and BI setups for startups and SMCs Mentor for students and startups
- 3. 3 AGENDA KEMB01 Project management basics02 Agile Methodology - SCRUM03 What’s more?04
- 4. 4 KEMB
- 5. PURPOSE 5 kemb GmbH is a mixed consultancy & project platform of four like-minded guys who met at a startup in Munich. We consult mainly small to medium sized companies that want to achieve further growth by optimizing areas like marketing, BI, IT and finance for them. We are all C-Level professionals in our fields that overlap and greatly match to offer a broad range of consultancy topics. In order to further deepen our knowledge we have projects on the side, where we invest time in growing businesses and platforms together with friends and interested partners.
- 6. KEMB PORTFOLIO 6 BUSINESS INTELLIGENCE FINANCE & LEGAL DIGITAL MARKETING & BRANDING ORGANISATION & PRODUCTIVITY OWNED BRANDS
- 9. THE WATERFALL 9 REQUIREMENTS DESIGN IMPLEMENTATION VERIFICATION MAINTENANCE PRODUCT REQUIREMENTS DOCUMENT SOFTWARE ARCHITECTURE SOFTWARE
- 10. PITFALLS OF THE WATERFALL 10 - Regularly exceeding budget and time scope - No full alignment on scope between customer and project team - Customer expectation - Linearity - Changing requirements during the project
- 12. REFINEMENT OF PRODUCT BACKLOG SCRUM 12 PRIO 1 Ticket + Prio Ticket + Prio PRODUCT BACKLOG SPRINT (max one month) ITERATIVE- INCREMENTAL DEVELOPMENT & DELIVERY POTENTIALL Y RELEASABLE INCREMENT 24 HOURS DAILY SCRUM MEETING SPRINT BACKLOG Ticket + Prio Ticket + Prio PRODUCT OWNER Liaison between stakeholders SPRINT PLANNING 1. Team forecast PBIs 2. Plans the work SPRINT REVIEW SPRINT RETRO STAKEHOLDERS
- 13. THE ROLES 13 PRODUCT OWNER Project Manager DEVELOPMENT TEAM Project Team STAKEHOLDER Customer SCRUM MASTER
- 14. PRODUCT OWNER 14 Management of Backlog Analysis of Product Vision Modulating Development Team Coordination with Scrum Master
- 15. DEVELOPMENT TEAM 15 DEVELOPMENT TEAM Prioritize the Sprint Backlog Estimate the effort to implement a story Identifying complexity of a user story Splitting user stories into tasks Completing tasks to achieve sprint goal Unit and initial acceptance testing Self-organizing Attending meetings and ceremonies Implementing test cases Communicating the status of the work daily
- 16. SCRUM MASTER 16 Facilitator/ Removes Barriers Shields team from external interference Enables Close Cooperation Enforce Scrum Principles Improve Productivity
- 17. SCRUM EVENTS & ARTIFACTS 17 USER STORY AND EPIC PRODUCT BACKLOG PLANNING SPRINT BACKLOG SPRINT DAILY SCRUM REVIEW RETROSPECTIVE
- 18. USER STORY & EPIC 18
- 19. USER STORY & EPIC 19
- 21. PLANNING I: ESTIMATION 21 ROLLER BLADES BICYCLE SCOOTER TRACTOR CAR TRUCK TRAIN HELICOPTER AIRPLANE .5 1 2 3 5 8 13 20 40 SPACE SHUTTLE 100
- 22. PLANNING II & SPRINT BACKLOG 22
- 23. SPRINT & DAILY SCRUM / STANDUP 23 PRIO 1 2 3 4 SPRINT BACKLOG PRODUCT BACKLOG CLIENT PRIORITIZES 1-4 WEEKS SPRINTS POTENTIALL Y SHIPPABLE PRODUCT 24 HOURS DAILY SCRUM MEETING BACKLOG ITEMS
- 24. SPRINT & DAILY SCRUM / STANDUP
- 25. REVIEW - ALL PARTICIPANTS 25 PRODUCT OWNER Project Manager DEVELOPMENT TEAM Project Team STAKEHOLDER Customer SCRUM MASTER SCRUM TEAM BUSINESS SPONSOR MANAGEMENTCUSTOMER SPRINT REVIEW SPRINT REVIEW MEETING FACILITATE
- 26. RETROSPECTIVE 26 SUCCESS FAILURELEARNING Add text WHAT WORKED OR WENT WELL? Add text WHAT DID NOT GO WELL? Add text WHAT CAN BE DONE BETTER?
- 27. REFINEMENT OF PRODUCT BACKLOG SCRUM 27 PRIO 1 Ticket + Prio Ticket + Prio PRODUCT BACKLOG SPRINT (max one month) ITERATIVE- INCREMENTAL DEVELOPMENT & DELIVERY POTENTIALL Y RELEASABLE INCREMENT 24 HOURS DAILY SCRUM MEETING SPRINT BACKLOG Ticket + Prio Ticket + Prio PRODUCT OWNER Liaison between stakeholders SPRINT PLANNING 1. Team forecast PBIs 2. Plans the work SPRINT REVIEW SPRINT RETRO STAKEHOLDERS
- 28. LIMITS OF SCRUM 28 - No guarantee for success - Usage of gathered information -> will to improve - Role conflicts - SCRUM in working / freelance contracts
- 29. 29 WHAT’S MORE?
- 30. KANBAN 30
- 31. AGILE IN DAILY WORK 32
- 32. 33 THANKS FOR LISTENING For more details please check out the blogpost on wearekemb.com
Editor's Notes
- The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3][4] although Royce did not use the term waterfall in that article. Royce presented this model as an example of a flawed, non-working model; which is how the term is generally used in writing about software development—to describe a critical view of a commonly used software development practice.[5]
- Wünsche im Hinblick auf Funktionalität, Benutzbarkeit (Usability), Performanz und Qualität beurteilt. In Scrum ist das der Product Owner. Aufgaben und Verantwortlichkeiten des Product Owners Pflege des Product Backlogs vertritt die fachliche Auftraggeberseite und somit sämtliche Stakeholders priorisiert die Product Backlog Items so, daß der Business Value des Produkts maximal wird und die Möglichkeit früher Releases von Kernfunktionalität besteht, um einen schnellen Return on Investment zu erreichen wohnt nach Möglichkeit den Daily Scrums bei, um sich (passiv) zu informieren steht für Rückfragen des Teams bereit Manchmal wird der Product Owner im Jargon auch scherzhaft als SCN (single chokable neck) bezeichnet, um klar (und überhaupt nicht scherzhaft) herauszustellen: Er trägt die Verantwortung dafür, daß die richtigen Anforderungen im Product Backlog stehen und daß sie in einer sinnvollen Reihenfolge abgearbeitet werden. Dadurch hat er maßgeblichen Einfluß auf das Arbeitsergebnis und ist, so gesehen, wirklich die eine Person, deren "Hals gewürgt wird", wenn das Team - gemäß Vorgabe - Mist produziert. Was der Product Owner NICHT tut Rolle des Chefs für das Team übernehmen Daily Scrums moderieren oder ungefragt dort reden Während des Sprints den Sprint Backlog beeinflussen (Zusatzanforderungen, Streichung von Aufgaben etc.) im Projekt als Team Member (z.B. Entwickler, Software-Architekt) mitarbeiten (? Interessenkonflikt!) versuchen, gleichzeitig den ScrumMaster zu mimen (? Interessenkonflikt!) seine Aufgabe nur zu Beginn und am Ende der Sprints wahrnehmen
- Merkmale und Eigenschaften eines Scrum-Teams besteht aus fünf bis zehn Personen (ideal sind sieben) größere Gruppen werden in mehrere unabhängige, aber miteinander kommunizierende Teams aufgeteilt ist interdisziplinär zusammengesetzt (Entwickler, Architekten, Tester, technische Redakteure), wenn von Vorteil - und das ist meistens der Fall ist sein eigener Manager (Self-Organisation) entscheidet selbständig über das Zerlegen von Requirements in Tasks und deren Verteilung an einzelne Mitglieder (Erstellung des Sprint Backlog aus dem aktuell anstehenden Teil des Product Backlog) trifft sich täglich zum Daily Scrum, in dem die Team Members einander jeweils einen kurzen Statusbericht liefern liefert nach jedem Sprint ein Increment of Potentially Shippable Functionality ab und präsentiert dieses im Sprint Review Meeting jedes Team Member kennt das Big Picture des Projekts jedes Team Member aktualisiert täglich die Restaufwände seiner Tasks im Sprint Backlog Was ein Scrum-Team NICHT tut Fachkonzepte schreiben - dafür gibt es das Product Backlog des Product Owners sich vom Product Owner seine Arbeitsweise vorschreiben lassen im Daily Scrum dem ScrumMaster und/oder dem Product Owner berichten - die Team Members berichten einander das Sprint Backlog vernachlässigen ungestörtes Arbeiten während des Sprints verwechseln mit dem Sitzen im Elfenbeinturm
- Aufgaben und Verantwortlichkeiten des ScrumMasters trägt Verantwortung für den Scrum-Prozeß und dessen korrekte Implementation ist ein Vermittler und Unterstützer (Facilitator) strebt maximalen Nutzen und ständige Optimierung an beseitigt Hindernisse(!) sorgt für Informationsfluß zwischen Product Owner und Team moderiert Scrum-Meetings hat die Aktualität der Scrum-Artefakte (Product Backlog, Sprint Backlog, Burndown Charts) im Blick schützt das Team vor unberechtigten Eingriffen während des Sprints Was der ScrumMaster NICHT tut Rolle des Chefs für das Team übernehmen das Projekt in dem Sinne leiten, daß er anschafft, wer welche Arbeit auf welche Weise zu erledigen hat Doppelfunktion als Team Member oder Product Owner übernehmen (? Interessenkonflikte!)
- Priorisierte Liste von Anforderungen (→ Requirements) mit Schätzwerten (Estimates), welche den jeweiligen Funktionsumfang, ggf. auch ihre Komplexität, relativ zueinander widerspiegeln. Wichtig ist, daß es um eine "gefühlte Größe" geht, nicht um eine absolute Aufwandschätzung in Personentagen o.ä. Als Einheit der Schätzwerte wird oft der sog. → Story Point - nicht zu verwechseln mit einem Function Point - verwendet. Je höher die Priorität einer Anforderung, desto feingranularer sind tendenziell die Schätzwerte, da das Product Backlog im wesentlichen nach absteigender Priorität abgearbeitet wird. Das Product Backlog ändert sich im Lauf der Zeit, ist also keine endgültige, vorab festgelegte Spezifikation, sondern eine Anforderungsliste, die im Fluß ist und sich den Gegebenheiten des Projekts kontinuierlich anpaßt : In einem → Sprint realisierte oder verworfene Requirements werden entfernt, Schätzwerte aufgrund Teilbearbeitung oder neuer Erkenntnisse aktualisiert, neue Anforderungen aufgenommen, Prioritäten verändert, grob geschätzte Themen oder Funktionsblöcke verfeinert, also in kleinere heruntergebrochen etc.
- Time-boxed (8 h) Input: Product Backlog Output: Sprint Backlog Aufgeteilt in zwei weitere Time-Boxes von jeweils 4 h: Der Product Owner präsentiert dem Team die Product Backlog Items mit der höchsten Priorität und benennt (optional) sein Sprint Goal, mit dem das Team einverstanden sein muß. Gemeinsam bestimmen beide Seiten, welchen Teil des Product Backlogs das Team im kommenden Sprint in ein Increment of Potentially Shippable Functionality verwandeln kann. Das Team verpflichtet sich (engl. „to commit“) auf den besprochenen Lieferumfang, welchen es soeben selbst mitbestimmt hat. Das Team plant autonom (ohne Mitsprache des Product Owners) im Detail, wie es sein gegebenes Versprechen einlösen kann, indem es die betreffenden Requirements in Tasks herunterbricht und letztere zu einem Sprint Backlog konsolidiert.
- Eine Liste von Tasks, welche den Arbeitsumfang des Teams für den Sprint festlegt. Die Liste präzisiert sich während des Sprints und wird täglich von allen Team Members gepflegt, so daß sie immer den aktuellen Bearbeitungsstand reflektiert. Der Sprint Backlog ermöglicht es dem → ScrumMaster, jederzeit zu erkennen, wo das Team steht und ggf. steuernd einzugreifen, damit das → Sprint Goal nicht in Gefahr gerät.
- Time-boxed (4 h) Maximal eine Stunde Vorbereitungszeit pro Person Das Team selbst – nicht irgendein übergeordneter Manager – zeigt dem Product Owner und anderen interessierten Personen live am funktionierenden System, was es innerhalb des Sprints erreicht hat. Wichtig: keine Dummies, kein Powerpoint! Nur fertige Produktfunktionalität (Increment of Potentially Shippable Functionality) darf vorgeführt werden. Feedback seitens Product Owner, Stakeholders u.a. Anwesenden ist erwünscht und fließt in die weitere Arbeit ein. Auf Basis des Gezeigten entscheidet später der Product Owner, ob das Inkrement produktiv gesetzt oder weiter entwickelt werden soll. Diese Möglichkeit hat er nach jedem Sprint. So ist gewährleistet, daß in sich abgeschlossene funktionale Bausteine eines Gesamtsystems möglichst früh einen Nutzen und somit einen Return on Investment - Manager lieben das, und zu Recht - erzeugen.