Your SlideShare is downloading. ×
0
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

604

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
604
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Are we technocrats? Many of us, probably. Arguably most Agile adoption problems are “societal” in nature. Question: Can they really be addressed by technical solutions? A technical solution in this context can be a “process” as well as a (insert technical acronym here). Both are focused on the need to exhibit (or implement) a behaviour but do not necessarily deal with how people feel about this. Do the technocrat test – what would your if-onlys look like if you weren&apos;t one?
  • Transcript of "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>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×