Flight of the Agile

729 views

Published on

Vi hör om och läser många tips om hur man "ska" göra i ett agilt team, och vad som "måste" vara på plats i omgivningen för att agilt ska "fungera". Men tänk om det inte finns en sanning, ett enda rätt sätt att göra par-rotering på, eller vad en Scrum Master får eller inte får göra? Kan våra ideal vara hinder snarare än hjälp? Finns det något sätt att avgöra vad som är "rätt" sätt just för mig och mitt team?

Talare är Thomas Nilsson från Responsive AB

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Flight of the Agile

  1. 1. The Flight of the Agile Thomas Nilsson UndertitelCoach & Mentor Agile Developer, Agila Sverige 2010-05-11
  2. 2. Stealth-mode Agile Transition
  3. 3. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  4. 4. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  5. 5. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  6. 6. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  7. 7. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  8. 8. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  9. 9. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  10. 10. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  11. 11. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  12. 12. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  13. 13. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  14. 14. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design • Refactoring • Continuous Integration • Small Team • Collective Code Ownership • Small Releases • Planning Game
  15. 15. Stealth-mode Agile Transition • Pair programming • Test Driven Design • Automated Testing • Simple Design ot do ing ou a re n • Refactoring Y can ’t be • Continuous Integration o you Xs • Small Team Ag ile? • Collective Code Ownership • Small Releases • Planning Game
  16. 16. ”There’s no Shu in Agile!”
  17. 17. ”There’s no Shu in Agile!” Ri Ha Shu
  18. 18. ”There’s no Shu in Agile!” Ri Ha Shu
  19. 19. ”There’s no Shu in Agile!” hu fits N oS everyo ne! Ri Ha Shu
  20. 20. Pair Programming Advice
  21. 21. Pair Programming Advice • James Shore et al.: • ”Allow pairs to form naturally” • ”Don’t assign partners” • ”Pair with different people throughout the day”
  22. 22. Pair Programming Advice • James Shore et al.: • ”Allow pairs to form naturally” • ”Don’t assign partners” • ”Pair with different people throughout the day” • Richard Sheridan, CEO of Menlo Innovations: • ”I assign pairs for a week”
  23. 23. Pair Programming Advice • James Shore et al.: • ”Allow pairs to form naturally” • ”Don’t assign partners” • ”Pair with different people throughout the day” • Richard Sheridan, CEO of Menlo Innovations: • ”I assign pairs for a week” • How can they both be right?
  24. 24. Pair Programming Advice (revisited)
  25. 25. Pair Programming Advice (revisited) • When... • People don’t know each other... • There is not enough trust... • Don’t think alike... • Understand the domain or application...
  26. 26. Pair Programming Advice (revisited) • When... • People don’t know each other... • There is not enough trust... • Don’t think alike... • Understand the domain or application... • It depends!
  27. 27. Pair Programming Advice (revisited) • When... • People don’t know each other... • There is not enough trust... • Don’t think alike... • Understand the domain or application... • It depends! e T im the All en c e ly tch n ild e ou s Sw i tat io o bu onfid nta n Tas k d Ro io n t nd c Sp o n ule tat ns a te t eo he d Ro atio ota R ota Sc rel R
  28. 28. Pair Programming Advice (revisited) • When... ere is more • People don’t know each other...gh th A lthou left there • There is no trust... ue on the • Don’t think alike... l va or be v alue • Understand the domain uall y can application... a ct e rig ht... • It depends! alesToe on th im th b uild All h n to nce sly itc tio n ta tio nfide ou kS w ota Ro d co ne R on ta n Tas led ed n nn ns a Sp te o he du Pla atio te ta R ota Ro Sc rel
  29. 29. A Few More Examples
  30. 30. A Few More Examples • Paying back Technical Debt • Never Allow Technical Debt and Refactor Everything Now • On Sight at Fly-by • Stories for Refactoring
  31. 31. A Few More Examples • Paying back Technical Debt • Never Allow Technical Debt and Refactor Everything Now • On Sight at Fly-by • Stories for Refactoring • Automated Acceptance/Functional Testing • Automate Everything Now • Automate Everything New • Automate Some New • Automate One New
  32. 32. A Few More Examples get ting • Paying back Technical Debt rul e of • Never Allow Technical Debt and Refactor Everything Now #1 ole • On Sight at Fly-by is to ut o fah • Stories for Refactoring o igg ing • Automated Acceptance/Functional Testing s top d • Automate Everything Now • Automate Everything New • Automate Some New • Automate One New
  33. 33. A Few More Examples get ting • Paying back Technical Debt rul e of • Never Allow Technical Debt and Refactor Everything Now #1 ole • On Sight at Fly-by is to ut o fah • Stories for Refactoring o i.og at lea gg. n r p di . • Automated Acceptance/Functional Testing sto • Automate Everything Now • Automate Everything New st to • Automate Some New • Automate One New dig slower
  34. 34. ”There is Shu in Agile!” Ri Ha Shu
  35. 35. ”There is Shu in Agile!” Ri Ha Shu
  36. 36. ”There is Shu in Agile!” Agile Ri Ha Shu
  37. 37. Stages of the Agile flight
  38. 38. Stages of the Agile flight • Taxiing - trying to find the runway • Learning, searching, stability, hard rules • Building trust, in you, in your team, from the surrounding organization • Finding any way the techniques can be applied
  39. 39. Stages of the Agile flight • Taxiing - trying to find the runway • Learning, searching, stability, hard rules • Building trust, in you, in your team, from the surrounding organization • Finding any way the techniques can be applied • Take-off - apply full power • Building speed, applying the technique to the max • Helping, focusing according to common,visible, view of priority • Adding techniques and tweaking to get more out of them • Knowing the direction
  40. 40. Stages of the Agile flight • Taxiing - trying to find the runway • Learning, searching, stability, hard rules • Building trust, in you, in your team, from the surrounding organization • Finding any way the techniques can be applied • Take-off - apply full power • Building speed, applying the technique to the max • Helping, focusing according to common,visible, view of priority • Adding techniques and tweaking to get more out of them • Knowing the direction • Climbing - rotate and maintain speed • Using the speed to deliver value • Make sure you don’t lose speed or waste fuel
  41. 41. Stages of the Agile flight • Taxiing - trying to find the runway • Learning, searching, stability, hard rules • Building trust, in you, in your team, from the surrounding organization • Finding any way the techniques can be applied • Take-off - apply full power • Building speed, applying the technique to the max • Helping, focusing according to common,visible, view of priority • Adding techniques and tweaking to get more out of them • Knowing the direction • Climbing - rotate and maintain speed • Using the speed to deliver value • Make sure you don’t lose speed or waste fuel • Cruising • You should never be cruising!
  42. 42. Flight of the Agile! It’s not what you do, but how! Thomas Nilsson thomas.nilsson@responsive.se http://www.responsive.se/thomas

×