Flight of the Agile
•Download as KEY, PDF•
0 likes•478 views
The document discusses different stages of transitioning to an agile development process, referred to as the "flight of the agile". It describes an initial "taxiing" stage where teams learn techniques, build trust, and find ways to apply agile practices. Next is the "take-off" stage where teams fully apply techniques to maximize speed and focus on priorities. The third stage is "climbing" where teams use their speed to deliver value while maintaining pace. The document provides advice on practices like pair programming, paying back technical debt, and automated testing.
Recommended
Recommended
More Related Content
Similar to Flight of the Agile
Similar to Flight of the Agile (20)
More from Agila Sverige
More from Agila Sverige (20)
Recently uploaded
Recently uploaded (20)
Flight of the Agile
- 1. The Flight of the Agile Thomas Nilsson UndertitelCoach & Mentor Agile Developer, Agila Sverige 2010-05-11
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
- 16. 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
- 18. ”There’s no Shu in Agile!”
- 19. ”There’s no Shu in Agile!” Ri Ha Shu
- 20. ”There’s no Shu in Agile!” Ri Ha Shu
- 21. ”There’s no Shu in Agile!” hu fits N oS everyo ne! Ri Ha Shu
- 23. Pair Programming Advice • James Shore et al.: • ”Allow pairs to form naturally” • ”Don’t assign partners” • ”Pair with different people throughout the day”
- 24. 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”
- 25. 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?
- 26. Pair Programming Advice (revisited)
- 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...
- 28. 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!
- 29. 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
- 30. 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
- 31. A Few More Examples
- 32. A Few More Examples • Paying back Technical Debt • Never Allow Technical Debt and Refactor Everything Now • On Sight at Fly-by • Stories for Refactoring
- 33. 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
- 34. 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
- 35. 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
- 36. ”There is Shu in Agile!” Ri Ha Shu
- 37. ”There is Shu in Agile!” Ri Ha Shu
- 38. ”There is Shu in Agile!” Agile Ri Ha Shu
- 39. Stages of the Agile flight
- 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
- 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
- 42. 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
- 43. 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!
- 44. Flight of the Agile! It’s not what you do, but how! Thomas Nilsson thomas.nilsson@responsive.se http://www.responsive.se/thomas
Editor's Notes
- Coach, developer, CTO, 90’s
- Inspired by Kent Beck Business advice to startup companies
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- First ”Agile for real”, BA, 4 week => We can’t do that! Gradual introduction of practices as improvements ”You turned us into an Agile team!” Responsive, honest about progress and made it visible, priorities
- Veary of ”You are not doing...:”
- 1 week iterations possibility to deploy weekly daily builds taskboard with sprint and project burndown
- There are many models for maturity and learning, all implying steps.... CMMI comes to mind... Not specific, still WHAT... Shu Ha Ri/Dreyfus, Learning is not staged Big guy said ”There’s no Shu in Agile!” meaning that you can’t be a novice, or follow some rules I think the problem is more fundamental than this... It’s the misconception that each level is about doing some particular practices in some specific order So the rules to be followed at some initial level are not the same if you are agile ”No Shu fits everyone”
- There are many models for maturity and learning, all implying steps.... CMMI comes to mind... Not specific, still WHAT... Shu Ha Ri/Dreyfus, Learning is not staged Big guy said ”There’s no Shu in Agile!” meaning that you can’t be a novice, or follow some rules I think the problem is more fundamental than this... It’s the misconception that each level is about doing some particular practices in some specific order So the rules to be followed at some initial level are not the same if you are agile ”No Shu fits everyone”
- There are many models for maturity and learning, all implying steps.... CMMI comes to mind... Not specific, still WHAT... Shu Ha Ri/Dreyfus, Learning is not staged Big guy said ”There’s no Shu in Agile!” meaning that you can’t be a novice, or follow some rules I think the problem is more fundamental than this... It’s the misconception that each level is about doing some particular practices in some specific order So the rules to be followed at some initial level are not the same if you are agile ”No Shu fits everyone”
- There are many models for maturity and learning, all implying steps.... CMMI comes to mind... Not specific, still WHAT... Shu Ha Ri/Dreyfus, Learning is not staged Big guy said ”There’s no Shu in Agile!” meaning that you can’t be a novice, or follow some rules I think the problem is more fundamental than this... It’s the misconception that each level is about doing some particular practices in some specific order So the rules to be followed at some initial level are not the same if you are agile ”No Shu fits everyone”
- There are many models for maturity and learning, all implying steps.... CMMI comes to mind... Not specific, still WHAT... Shu Ha Ri/Dreyfus, Learning is not staged Big guy said ”There’s no Shu in Agile!” meaning that you can’t be a novice, or follow some rules I think the problem is more fundamental than this... It’s the misconception that each level is about doing some particular practices in some specific order So the rules to be followed at some initial level are not the same if you are agile ”No Shu fits everyone”
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- Why rotate often? increase information and knowledge flow Long run help efficiency, lower mistakes, flexibility Drawbacks? Scale within each technique as a mental model Jumping is dangerous, many failures because of jumping, dogmatic ”Agilists” Walking at a brisk pace!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- You can be Agile on any level It is the journey, and the will to move that is Agility!
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board
- Taxiing: figuring out, finding ways to apply agile techniques, use some, skip some Take-off: apply the techniques to the max, avoiding pit-falls Climbing: maintain speed, add more techniques Cruising: stable state, engrained, never comes up in a retrospective About Generic: Rose RT+java, leeway to WoW, hired for initial TDD Eclipse/Java, simple->multi-class->legacy->code smells->their code Modeling build times, ”They are working on it...” Feature they where in control of, iteration planning, stories, tasks, task board