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.

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.

4. Design the system.

5. Implement.

6. Test.

7. Deploy Works great, if only ...

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

14. Pull instead of push

15. Self-organizing teams

16. Continuous integration

17. Automated testing

18. Continuous improvement Works great, if only ...

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

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.”

29. No-Win Situations

31. ... given past GPS tracking data for this time of day & traffic patterns.

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.

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

46. Implement "Favorites" persistence Boston Dev Team 1 Vancouver Backend Team

49. Implement "Favorites" persistence.

52. Interfaces 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?”

58. Shut up. Listen. Smile.