The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 746 views
Uploaded 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......

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.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
746
On Slideshare
746
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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't one?

Transcript

  • 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. TRUST.
  • 3. Great Expectations
    • Get all requirements in advance. Document them.
    • 4. Design the system.
    • 5. Implement.
    • 6. Test.
    • 7. Deploy
    Works great, if only ...
  • 8. If Only ...
    • People would be more diligent documenting requirements
    • 9. Designers would think things through
    • 10. Developers would write better code
    • 11. Testers would be more thorough
    • 12. Requirements didn't change over time
  • 13. Great Expectations, Take 2
    • Embrace change
    • 14. Pull instead of push
    • 15. Self-organizing teams
    • 16. Continuous integration
    • 17. Automated testing
    • 18. Continuous improvement
    Works great, if only ...
  • 19. If Only ...
    • Management would be serious about empowering teams
    • 20. People would “get” the advantages of (insert Agile technique here)
    • 21. Developers would learn to (insert technique / tool / architectural principle here)
    • 22. We wouldn't have all that legacy code
  • 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. Agile “if only”, Emotionized Edition http://geeksguides.net/?p=468
  • 25.
    • If only .... management would be serious about empowering teams
    “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.
    • If only ... people would “get” the advantages of (insert Agile technique here)
    • 27. Developers would learn to (insert technique / tool / architectural principle here)
    *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.
    • If only ... we wouldn't have all that legacy code ...
    “Grow up. Legacy code Is a fact of life.”
  • 29. No-Win Situations
  • 30. BusMeUp.com
    • “ When's the next bus?”
    • 31. ... given past GPS tracking data for this time of day & traffic patterns.
    • 32. Our Customer:
      • Transit systems / municipalities
  • 33. BusMeUp.com Subsystems
    • Mobile app
    • 34. Web app
    • 35. Mobile & web app backend
    • 36. Arrival time estimator
    • 37. Route & Bus maintenance app
    • 38. BusBug GPS module sends bus location to server.
  • 39. BusMeUp.com Teams
    • Boston (Dev)
    • 40. Bangalore (Dev)
    • 41. Vancouver (Dev & DBA)
  • 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. 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. BusMeUp Iteration X Project Plan
    • BusMeUp.com Enhancements
      • Design & Implement "Favorites" page.
      • 45. Fix "estimate on website different from mobile site" bug.
    • Backend Enhancements
      • Design & Implement "Favorites" validation logic.
      • 46. Implement "Favorites" persistence
    Boston Dev Team 1 Vancouver Backend Team
  • 47. BusMeUp Iteration X Project Plan
    • BusMeUp.com Enhancements
      • Design & Implement "Favorites" page.
      • 48. Fix "estimate on website different from mobile site" bug.
    • BusMeUp Mobile
      • ?
    • Backend Enhancements
      • Design & Implement "Favorites" validation logic.
      • 49. Implement "Favorites" persistence.
      • 50. ?
    • Arrival Time Estimator
      • ?
    Boston Dev Team 1 Boston Dev Team 2 Boston Dev Team 1 Vancouver Backend Team Vancouver DBA Team
  • 51. Team 2 Team 1 Team 3 Team 4 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. Own What Changes
  • 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. Define Success
    • “Everything went according to plan.”
    How fast did you adapt? Was it fast enough for the business?
    • “We learned something new and adapted quickly.”
    Excuses. Bad planning. You should have seen it coming.
  • 56. Summary: Trust 101 For Geeks – The Lowest Common Denominator
    • Avoid no-win situations:
      • Design processes and applications so you can own your stack: What changes together must be managed and developed together.
      • 57. Build a shared understanding of what success looks like.
    • Look harmless:
    • 58. Shut up. Listen. Smile.