Agile intro-90min (2007)

Hinweis der Redaktion

• #5: Task Switching: DeMarco/Lister: Peopleware, Project-Multitasking: Goldratt in Critical Chain
• #9: Individuals and interaction without the right people who have the right technical and behavioral skills, all the process and tools in the world won‘t produce results. People often tied down with procedures and forms BPR proponents thought that structured processes would somehow make up for mediocre individual capabilities No process can overcome the lack of good engineers, product managers, customers, suppliers and executives Good process should support the team rather than dictate it actions APM supports creators, not stewards Working results a characteristic of serial development is delivering documentation artifacts large, front-end loaded projects spend months, and even years gathering and documenting requirements, proposing architectures and designing products are prone to errors Documents do not work. Products do. stress the delivery of versions of the product (or effective simulations and models) this delivery verifies that something tangible to the customer is being built working features provide dependable feedback into the development process, in a way, a document cannot. Documentation is not unimportant, it is just less important than a working version Documentation is not a substitute for interaction and collaboration In traditional forms, a document often has become a substitute (customer & product owner send a requirements document to development), and thus barricade to progress (no knowledge is transferred) Customer collaboration customer team and development team form a partnership with specific roles, responsibilities and accountabilities the customer is the individual or group who uses the created product to generate business value Customers define value Other stakeholders define constraints (we must not confuse these roles) Customers define requirements (features) that provide value and the business objective (schedule, cost) that assist in quantifying that value today value arises from implemented features that meet the requirements tomorrow‘s benefits (once a product is delivered) is a function of how quickly and cost effectively the product can be adapted.  Deliver today, adapt tomorrow Responding to change every project has to balance planning and change exploration style projects are characterized by a process that emphasizes envisioning and then exploring into that vision rather than detailed planning and relatively strict execution of tasks Cost of exploration, experimenting = cost of an iteration. Low cost iterations enable adaptive style of development „conforming to plan“ falls very short in a turbulent economy. The old mantra „plan the work“ and then „work the plan“ Highsmith 2004, pp. 8ff Mike Cohn 2006, pp. 21f J. Coldewey: Collaboration over formalisms short increments over year long mediation flexibility over planning orgies Customer involvement over safeguarding
• #14: Klassisches Vorgehen also Plan/Execute = Ziel anvisieren, Abschießen einer „unguided Missile“ Nur: eigentlich immer ein bewegliches Ziel (Anforderungen, Technologie, …) Agile Methoden verwenden ein iterativ inkrementelles Vorgehen Iterativ heißt „in Iterationen“ Fixe Länge, zB 2 Wo klarem Fokus auf das Ziel Feedback: früh & häufig Ähnlich Navigationssystem im Auto In jeder Iteration Entscheidungsräume
• #15: 100% Fertig = Getestet Wesentliche Unterscheidung zur klassischen Entwicklung Typ. Release zB. Ein Jahr, mehrere MS, a, b, Release, HotFix klassisch: spät testen, spät integrieren, spät dokumentieren iterativ: von Beginn weg testen, integrieren, dokumentieren Workload und Stress ausnivellieren Qualität konstant hoch halten Geschwindigkeit nicht ohne Qualität möglich Regelmäßige Shipments möglich, da Inkremente auslieferbar sind
• #22: Beispiel bei Fabasoft Planung / Sprint Kommitment - Einfache, sehr effiziente Visualisierung - Daily Scrum: ca. 10 min täglich
• #24: Produktivität auch Team-Entwicklung, Reibungen, Extrem klarer Fokus Stress: Auch Entlastung von Einzelkämpfern, Belohnungseffekt, positiv
• #30: A round should not take longer than three minutes If the requirements are not clear, define the story new (not in the poker game)
• #37: The team was not able to finish the committed work. It looks like it had an issue in progress on day 3-4 and the second week. It seems, that they spent more than once much more time on finishing tasks in significant more time than planned. The team was faster than expected and finished more work than planned. The velocity was higher than planned. The PO put in another story and the team seemed to delivered it.
• #44: The material in this document is protected by copyright law. Some contents in this presentation have been included from their original authors with permission, these are: Ken Schwaber’s Version 5 Certified ScrumMaster Course and CSM course materials Mike Cohn’s Redistributable Intro to Scrum Ken Schwaber’s and Mike Cohn’s CSPO course materials Roman Pichler’s CSM course materials No part of this publication may be reproduced or transmitted in any form or for any purpose without prior express permission of Objectbay. The information contained herein may be changed without prior notice. Some software products marketed by Objectbay and its distributors contain proprietary software components of other software vendors. Objectbay is a trademark or registered trademark of Objectbay Software & Consulting GmbH in Austria and/or the European Union and in several other countries all over the world. All other products and names mentioned are trademarks or registered trademarks of their respective companies.