Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Doomed to Fail

Doomed to Fail

Doomed to Fail: Why the Enterprise Needs to Stop Writing Checks that Can’t Be Cashed

Presented at #Agile2014

From the marketing materials:
Departments and teams are told what to deliver and when it will be done. They are there to meet the expectations set upon them (including those they haven’t yet been told about). Unfortunately, they often miss their deliverables and it’s getting in the way of expanding agile across the enterprise. Is it any wonder why some agile implementations struggle? The existing culture sets us up for failure!

It does not have to be this way. The problem isn’t your lack of control over other work groups, it is how they are treated. There are big differences between what a group promises to deliver and when they are voluntold to deliver. Every one is committed at some level, so stop treating other groups like chickens.

Using interactive exercises, we will demonstrate common situations and discuss how these problems look from multiple sides. Additionally, we will discuss the tools needed to deal with others who have a low reputation and what it takes to improve your own track-record.

Come to “Doomed to Fail” and learn how to recognize critical difference between prescriptive processes and managing promises between different groups in an organization. Learn how to ask for explicit promises so you can navigate through the enterprise maze to success.

Aside... If you're really curious, I am taking the concept of [Promise Theory](http://en.wikipedia.org/wiki/Promise_theory) and applying it to anti-patterns for enterprise-wide agile.



July 30, 2014


  1. Doomed to Fail Why  the  Enterprise   Needs  to  Stop

      Wri1ng  Checks  that   Can’t  Be  Cashed  
  2. Scene #1  Imagine  this…  

  3. Are we Doomed to Fail?

  4. @JeffreyGoodReq   goodrequirements.com  

  5. Problem !=  Employees  

  6. Problem Culture  

  7. Problems Independence  

  8. Problems Common   understanding  

  9. Problems Trust    

  10. Problems Poor   expecta1ons  

  11. Problems Bad   agreements  

  12. What’s a promise?

  13. Promise I  am   autonomous  

  14. Promise Specific  

  15. Promise Understood  

  16. 2 Parties Promise   Maker   Promise   Holder  

  17. Promise Holder Accept   Ignore  

  18. Scene #2  Re-­‐imagine…  

  19. Before the promise

  20. Promise Maker

  21. Promise Maker Capability  

  22. Promise Maker Capacity  

  23. Promise Maker Sphere  of   control  

  24. Promise Maker Desires  

  25. Promise Maker Important  

  26. Promise Maker Burden  

  27. Promise Maker Explicit  

  28. Promise Maker Publish?  

  29. Promise Maker Reputa1on     &  value  

  30. Promise Holder    

  31. Promise Holder Safe  

  32. Promise Holder Sphere  of   control  

  33. Promise Holder !=  Voluntold  

  34. Promise Holder Explicit  

  35. Promise Holder Wri1ng?  

  36. After the promise

  37. Promise Maker

  38. Promise Maker Understand   expecta1ons  

  39. Promise Maker Over-­‐ communicate  

  40. Promise Maker Deliver  

  41. Promise Maker Withdraw  

  42. Promise Holder

  43. Promise Holder Verify  

  44. Promise Holder Consider   reputa1on  

  45. Promise Holder Plan   con1ngencies  

  46. Promise Holder Determine  if   promise  kept  

  47. Promise Holder Invoke   con1ngencies  

  48. Practice Your  turn  

  49. Practice Weak   Broken   Malicious   Unknown   Ignored

  50. In real life . . .

  51. None
  52. •  Mark  Burgess,  In  Search  of  Certainty     • 

    Kent  McDonald,  beyondrequirements.com     •  Jeff  Sussna,  blog.ingineeringit.com     Resources  are  gathered  at:   •  h[p://goodrequirements.com/pt   References
  53. Doomed to Fail