Keine Notizen für die Folie
Task Switching: DeMarco/Lister: Peopleware, Project-Multitasking: Goldratt in Critical Chain
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
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 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
Collaboration over formalisms
short increments over year long mediation
flexibility over planning orgies
Customer involvement over safeguarding
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
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
Beispiel bei Fabasoft
Planung / Sprint Kommitment
- Einfache, sehr effiziente Visualisierung
- Daily Scrum: ca. 10 min täglich
Produktivität auch Team-Entwicklung, Reibungen, Extrem klarer Fokus
Stress: Auch Entlastung von Einzelkämpfern,
A round should not take longer than three minutes
If the requirements are not clear, define the story new (not in the poker game)
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.
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.