Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
The Geek Factor: Why They Aren't Buying Your Agile ... and how to make  them love it. Robert Reppel http://robertblogs.wor...
TRUST.
Great Expectations <ul><li>Get all requirements in advance. Document them.
Design the system.
Implement.
Test.
Deploy </li></ul>Works great, if only ...
If Only ... <ul><li>People would be more  diligent  documenting requirements
Designers would  think things through
Developers would  write better code
Testers would be more  thorough
Requirements didn't  change over time </li></ul>
Great Expectations, Take 2 <ul><li>Embrace change
Pull instead of push
Self-organizing teams
Continuous integration
Automated testing
Continuous improvement </li></ul>Works great, if only ...
If Only ... <ul><li>Management would be serious about empowering teams
People would “get” the advantages of (insert Agile technique here)
Developers would learn to (insert technique / tool / architectural principle here)
We wouldn't have all that legacy code </li></ul>
TECHNOCRACY “ Technocrats are individuals with technical training and occupations who perceive many important societal pro...
Agile “if only”, Emotionized Edition http://geeksguides.net/?p=468
Upcoming SlideShare
Loading in …5
×

The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It

790 views

Published on

If Agile works, why isn’t everyone doing it? Or, as Agile has become fashionable of late, why all the lip service without the expected amount of real change? This presentation makes the argument that it comes down to trust and presents tools and examples for building and keeping trust. The focus is on how to project plan and design applications in a way which, wherever possible, avoids putting stakeholders into situations which require trust in the first place.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It

  1. 1. The Geek Factor: Why They Aren't Buying Your Agile ... and how to make them love it. Robert Reppel http://robertblogs.wordpress.com Twitter @robertreppel
  2. 2. TRUST.
  3. 3. Great Expectations <ul><li>Get all requirements in advance. Document them.
  4. 4. Design the system.
  5. 5. Implement.
  6. 6. Test.
  7. 7. Deploy </li></ul>Works great, if only ...
  8. 8. If Only ... <ul><li>People would be more diligent documenting requirements
  9. 9. Designers would think things through
  10. 10. Developers would write better code
  11. 11. Testers would be more thorough
  12. 12. Requirements didn't change over time </li></ul>
  13. 13. Great Expectations, Take 2 <ul><li>Embrace change
  14. 14. Pull instead of push
  15. 15. Self-organizing teams
  16. 16. Continuous integration
  17. 17. Automated testing
  18. 18. Continuous improvement </li></ul>Works great, if only ...
  19. 19. If Only ... <ul><li>Management would be serious about empowering teams
  20. 20. People would “get” the advantages of (insert Agile technique here)
  21. 21. Developers would learn to (insert technique / tool / architectural principle here)
  22. 22. We wouldn't have all that legacy code </li></ul>
  23. 23. TECHNOCRACY “ Technocrats are individuals with technical training and occupations who perceive many important societal problems as being solvable, often while proposing technology-focused solutions.”
  24. 24. Agile “if only”, Emotionized Edition http://geeksguides.net/?p=468
  25. 25. <ul><li>If only .... management would be serious about empowering teams </li></ul>“What does empowering teams make me look like with my boss? My peers? The teams? What if it goes wrong?” “If developers decide, how do I influence the outcomes so we get what we need?” “If it works it'll look like I've done it wrong all these years.”
  26. 26. <ul><li>If only ... people would “get” the advantages of (insert Agile technique here)
  27. 27. Developers would learn to (insert technique / tool / architectural principle here) </li></ul>*http://dhemery.com/articles/resistance_as_a_resource/ “If it works it'll look like I've done it wrong all these years.” “People prefer the familiar over the comfortable.”* “Leave me alone. It's just a job.”
  28. 28. <ul><li>If only ... we wouldn't have all that legacy code ... </li></ul>“Grow up. Legacy code Is a fact of life.”
  29. 29. No-Win Situations
  30. 30. BusMeUp.com <ul><li>“ When's the next bus?”
  31. 31. ... given past GPS tracking data for this time of day & traffic patterns.
  32. 32. Our Customer: </li><ul><li>Transit systems / municipalities </li></ul></ul>
  33. 33. BusMeUp.com Subsystems <ul><li>Mobile app
  34. 34. Web app
  35. 35. Mobile & web app backend
  36. 36. Arrival time estimator
  37. 37. Route & Bus maintenance app
  38. 38. BusBug GPS module sends bus location to server. </li></ul>
  39. 39. BusMeUp.com Teams <ul><li>Boston (Dev)
  40. 40. Bangalore (Dev)
  41. 41. Vancouver (Dev & DBA) </li></ul>
  42. 42. Project Plan Driven Architecture (PPDA?) Busmeup.com Web site BusMeUp.com Mobile Backend BusmeDb BusBug GPS Data Collector Route & Bus Maintenance Site Arrival Time Estimator
  43. 43. Vancouver DBA Team 5 Vancouver Backend Team 4 Boston Dev Team 1 Bangalore Dev Team 3 Boston Dev Team 2 BusMeUp.com Web site BusMeUp.com Mobile Backend BusmeDb BusBug GPS Data Collector Route & Bus Maintenance Site Arrival Time Estimator
  44. 44. BusMeUp Iteration X Project Plan <ul><li>BusMeUp.com Enhancements </li><ul><li>Design & Implement &quot;Favorites&quot; page.
  45. 45. Fix &quot;estimate on website different from mobile site&quot; bug. </li></ul><li>Backend Enhancements </li><ul><li>Design & Implement &quot;Favorites&quot; validation logic.
  46. 46. Implement &quot;Favorites&quot; persistence </li></ul></ul>Boston Dev Team 1 Vancouver Backend Team
  47. 47. BusMeUp Iteration X Project Plan <ul><li>BusMeUp.com Enhancements </li><ul><li>Design & Implement &quot;Favorites&quot; page.
  48. 48. Fix &quot;estimate on website different from mobile site&quot; bug. </li></ul><li>BusMeUp Mobile </li><ul><li>? </li></ul><li>Backend Enhancements </li><ul><li>Design & Implement &quot;Favorites&quot; validation logic.
  49. 49. Implement &quot;Favorites&quot; persistence.
  50. 50. ? </li></ul><li>Arrival Time Estimator </li><ul><li>? </li></ul></ul>Boston Dev Team 1 Boston Dev Team 2 Boston Dev Team 1 Vancouver Backend Team Vancouver DBA Team
  51. 51. Team 2 Team 1 Team 3 Team 4 <ul><li>Messages
  52. 52. Interfaces </li></ul>Team Communication Busmeup.com Web Site View BusMe.com Mobile View Controller/ Model BusBug GPS Data Collector Route & Bus Maintenance Site Transit System Routes- Arrivals- Buses DB
  53. 53. Own What Changes
  54. 54. Own What Changes “We are the ArrivalTimeEstimator team. Are you trying To break up our department?” “Are you saying that ArrivalTimeEstimator team does not communicate well with other stakeholders?”
  55. 55. Define Success <ul><li>“Everything went according to plan.” </li></ul>How fast did you adapt? Was it fast enough for the business? <ul><li>“We learned something new and adapted quickly.” </li></ul>Excuses. Bad planning. You should have seen it coming.
  56. 56. Summary: Trust 101 For Geeks – The Lowest Common Denominator <ul><li>Avoid no-win situations: </li><ul><li>Design processes and applications so you can own your stack: What changes together must be managed and developed together.
  57. 57. Build a shared understanding of what success looks like. </li></ul></ul><ul><li>Look harmless:
  58. 58. Shut up. Listen. Smile. </li></ul>

×