Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Feature Flow Agile Holland
Semelhante a Feature Flow Agile Holland (20)
Último
Último (20)
Feature Flow Agile Holland
- 1. Feature Flow - Enhancing a Scrum team
- 2. Agenda • Introduction • Summary • Timeline: problems & solutions • Final thoughts
- 3. Machiel Groeneveld • 2003: eXtreme Developer • 2005: Scrum Developer • 2007: Scrum Coach & Trainer • 2008: Speaker at Agile 2008 • 2009: Lead Agile Developer • 2009: Speaker at XP Days • 2009: Published in Computable “Agile & Lean”
- 4. THE PROJECT
- 5. STRUGGLING TEAM Velocity Nov Dec Jan Feb
- 6. TEAM WANTS TO IMPROVE PROCESS AND PRODUCT
- 7. DESPITE DOING SCRUM AND PRESSURE, OUTPUT WAS LOW AND BAD
- 9. RESULT: FEATURE FLOW 20 15 10 5 0 #1 #2 #3 #4 #5 #6
- 12. PROBLEM 1 To Do In Progress Done
- 13. SYMPTOM: FEATURE SWITCHING The life of a feature:
- 14. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained
- 15. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting
- 16. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded
- 17. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting
- 18. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested
- 19. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting
- 20. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting 14: Bugfixed
- 21. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting 14: Bugfixed 15: Waiting
- 22. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting 14: Bugfixed 15: Waiting 16: Re-test
- 23. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting 14: Bugfixed 15: Waiting 16: Re-test 17: Small fix & Done
- 25. Causes • Management Pressure • Scrum Pressure • Built in Pressure
- 27. LET GO OF SPRINTS ✔ Solution
- 31. TASK BOARD To Do In Progress Done
- 32. TASK BOARD 8 To Do In Progress Done
- 33. PROBLEM II
- 34. TOO MUCH TIME PER FEATURE
- 35. Causes • Focus on own discipline • No time constraints
- 36. TASK BOARD 6 4 Development Testing ✔ Solution
- 37. REPLACE TIME BOX BY STORY ✔ Solution
- 38. FOCUS ON WORK, NOT PEOPLE ✔ Solution
- 39. TRACK TIME IN PROGRESS ✔ Solution
- 40. PROBLEM 3
- 41. LOST IN FEATURES
- 42. Causes • Single story too small for: • Demo • Focus
- 43. TASK BOARD 5 (2) 6 4 Explained Development Testing ✔ Solution
- 44. THEMES ✔ Solution ☺
- 45. INTAKE FOR OWNERSHIP ✔ Solution ☺
- 46. PROBLEM III
- 48. Causes • No knowledge and status sharing • Specialists • Broken builds only fixable by one person
- 49. ADVANCED BUILD SYSTEM ✔ Solution
- 51. PROBLEM IV
- 52. ARCHITECTURE WASN’T SET UP FOR PRODUCTIVITY
- 53. Causes • Architecture was set for loose coupling • Not for building features quickly • Pressure postponed refactoring
- 54. HOW TO MAKE ONE FEATURE QUICKLY ✔ Solution
- 55. BUILD A FRONT TO BACK BUSINESS PROCESS ✔ Solution
- 56. PROBLEM V
- 58. TASK BOARD 5 (2) 6 4 Explained Development Testing ✔ Solution
- 59. FROM WIP TO TEST-FIRST ✔ Solution
- 60. TASK BOARD 5 (2) 2 4 3 Explained Test prep Development Test ✔ Solution
- 62. USE DEVELOPER ENERGY TO DRIVE PROCESS ✔ Solution ☺
- 64. PROBLEM VI
- 65. THEME END
- 66. Causes • Deminishing work load • Nature of work changes so process also changes
- 68. MILESTONE FLOW #1 #2 #3 ✔ Solution
- 69. FINAL THOUGHTS
- 70. Teamwork Experiment with the Process, you own it
- 71. IT’S NEVER JUST A TOOL Discipline Team work Priorities Speed Product
- 72. Other Agile things we do: Agile & SOA - CIO Workshop, April 2010 Agile & UX - Paper & Workshop @Chi 2010
- 73. Agile Coach, Architect, Developer web : http://machielgroeneveld.nl web : http://approach.nl e-mail : machiel.groeneveld@approach.nl
Notas do Editor
- A complex process needs lots of accounting, a project manager keeping tabs, reworking problems. My story is how I helped a team increase productivity, some things inspired by kanban
- Pharma industry,rebuild application
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- Niet praten met elkaar dag 1: Als ontwikkelaar klaar is naar tester dag 3: tester test dag 4: ontwikkelaar bugs dag 6: nieuwe versie dag 8: testen 20 taken in progress aan het eind van de sprint: oplossing was om minder te beloven in de volgende sprint.
- No planning, no deadline
- measure velocity every few weeks to forecast releases
- step 1: signal problem (like failing builds) step 2: ask team to gather data for a few days step 3: analyze the data and true cause (what caused these events) step 4: decide on 1 or 2 actions that help remove the cause
- 2 weken van 20 naar 8 TODO - IN PROGRESS (8)  - DONE
- developers can spend ages refactoring testers can spend ages testing product owner can spend ages specifying
- pressure is not finish everything next week, but to keep everything moving
- change the standup from ‘what did you do’ to what’s going on with this story?
- regulating pressure is good, but motivation is better
- When only using stories, there is no limit on how goal to constrain discussion
- single stories do not give you a feel of completion themes are something to keep scope limited themes are easy for the user
- just plan to say, large - medium - small purpose is to set the stage for the next few days purpose is to get ownership and identify risky or hard stories - just making that explicit helps
- When only 1 person knows how to fix something and he’s not there, you’re blocked
- It’s not efficient to share knowledge, it’s better that 1 person invests in a particular test or piece of code
- Integration tests, testers could pull in stable versions
- Features would stall for days because only 1 person knew what was going on
- Critical application, better to test twice than too little
- TODO - SPECIFIED (3) -  TEST(4) - IN DEVELOPMENT (4)  - DONE
- In stead of managing the bottleneck, move it up-stream so testing dictates pace
- in stead of the developers drowning the testers, testers are the bottleneck and developers are motivated to help
- Maintenance mode is gebruik maken van variatie in testinspanning, het zand bij de grote stenen. In plaats van het doorpompen van werk dat misschien opnieuw veel testwerk vereist (vertraging x2)
- plm 1 uur
- By now we were doing releases in themes. The theme was like a long sprint, but with no fixed deadline. Still problems, but the old Scrum solution wasn’t diserable
- When you suddenly have to work on 1 features with 5 people, a new hectic process comes to bear
- stress peaks at the end of a sprint retro, demo and planning are hard. Low energy at the end - start of sprints retrospectives become boring and too high level
- releasing when all features are done, but don’t block development the releases are for customers, not developers