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.
Six Myths about Ontologies: The Basics of Formal Ontology
The Geek Factor: Why They Aren’t Buying Your Agile And How To Make Them Love It
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
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.”
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.”
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
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
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?”
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?
