Feature Flow Agile Holland

563 views

Published on

Transforming a Scrum team to increase performance and team work

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
563
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide


  • 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







  • Feature Flow Agile Holland

    1. 1. Feature Flow - Enhancing a Scrum team
    2. 2. Agenda • Introduction • Summary • Timeline: problems & solutions • Final thoughts
    3. 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. 4. THE PROJECT
    5. 5. STRUGGLING TEAM Velocity Nov Dec Jan Feb
    6. 6. TEAM WANTS TO IMPROVE PROCESS AND PRODUCT
    7. 7. DESPITE DOING SCRUM AND PRESSURE, OUTPUT WAS LOW AND BAD
    8. 8. SOLUTION FLOW & TEAMWORK
    9. 9. RESULT: FEATURE FLOW 20 15 10 5 0 #1 #2 #3 #4 #5 #6
    10. 10. PROBLEMS & SOLUTIONS
    11. 11. PROBLEM 1 To Do In Progress Done
    12. 12. SYMPTOM: FEATURE SWITCHING The life of a feature:
    13. 13. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained
    14. 14. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting
    15. 15. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded
    16. 16. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting
    17. 17. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested
    18. 18. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting
    19. 19. SYMPTOM: FEATURE SWITCHING The life of a feature: 01: Explained 02-09: Waiting 10: Coded 11: Waiting 12: Tested 13: Waiting 14: Bugfixed
    20. 20. 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
    21. 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 16: Re-test
    22. 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 17: Small fix & Done
    23. 23. SYMPTOM: FEATURE SWITCHING Work Wait
    24. 24. Causes • Management Pressure • Scrum Pressure • Built in Pressure
    25. 25. REGULATE PRESSURE
    26. 26. LET GO OF SPRINTS ✔ Solution
    27. 27. USE VELOCITY ✔ Solution
    28. 28. JIT RETRO ✔ Solution
    29. 29. REDUCE WIP ✔ Solution
    30. 30. TASK BOARD To Do In Progress Done
    31. 31. TASK BOARD 8 To Do In Progress Done
    32. 32. PROBLEM II
    33. 33. TOO MUCH TIME PER FEATURE
    34. 34. Causes • Focus on own discipline • No time constraints
    35. 35. TASK BOARD 6 4 Development Testing ✔ Solution
    36. 36. REPLACE TIME BOX BY STORY ✔ Solution
    37. 37. FOCUS ON WORK, NOT PEOPLE ✔ Solution
    38. 38. TRACK TIME IN PROGRESS ✔ Solution
    39. 39. PROBLEM 3
    40. 40. LOST IN FEATURES
    41. 41. Causes • Single story too small for: • Demo • Focus
    42. 42. TASK BOARD 5 (2) 6 4 Explained Development Testing ✔ Solution
    43. 43. THEMES ✔ Solution ☺
    44. 44. INTAKE FOR OWNERSHIP ✔ Solution ☺
    45. 45. PROBLEM III
    46. 46. FEATURES GETTING STUCK
    47. 47. Causes • No knowledge and status sharing • Specialists • Broken builds only fixable by one person
    48. 48. ADVANCED BUILD SYSTEM ✔ Solution
    49. 49. PAIR PROGRAMMING ✔ Solution
    50. 50. PROBLEM IV
    51. 51. ARCHITECTURE WASN’T SET UP FOR PRODUCTIVITY
    52. 52. Causes • Architecture was set for loose coupling • Not for building features quickly • Pressure postponed refactoring
    53. 53. HOW TO MAKE ONE FEATURE QUICKLY ✔ Solution
    54. 54. BUILD A FRONT TO BACK BUSINESS PROCESS ✔ Solution
    55. 55. PROBLEM V
    56. 56. TESTING = BOTTLENECK
    57. 57. TASK BOARD 5 (2) 6 4 Explained Development Testing ✔ Solution
    58. 58. FROM WIP TO TEST-FIRST ✔ Solution
    59. 59. TASK BOARD 5 (2) 2 4 3 Explained Test prep Development Test ✔ Solution
    60. 60. FITNESSE ✔ Solution
    61. 61. USE DEVELOPER ENERGY TO DRIVE PROCESS ✔ Solution ☺
    62. 62. MAINTENANCE MODE ✔ Solution
    63. 63. PROBLEM VI
    64. 64. THEME END
    65. 65. Causes • Deminishing work load • Nature of work changes so process also changes
    66. 66. NO SCRUM CRUNCHING
    67. 67. MILESTONE FLOW #1 #2 #3 ✔ Solution
    68. 68. FINAL THOUGHTS
    69. 69. Teamwork Experiment with the Process, you own it
    70. 70. IT’S NEVER JUST A TOOL Discipline Team work Priorities Speed Product
    71. 71. Other Agile things we do: Agile & SOA - CIO Workshop, April 2010 Agile & UX - Paper & Workshop @Chi 2010
    72. 72. Agile Coach, Architect, Developer web : http://machielgroeneveld.nl web : http://approach.nl e-mail : machiel.groeneveld@approach.nl

    ×