Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Making Agile Pay

609 views

Published on

Finbarr Joy presents a session on making agile methodologies pay - the business and contractual side of agile projects - how to arrive at the end and keep everyone happy.

Published in: Technology, Business
  • Finbarr has asked me to update the slides with his new emaill address finbarr.joy@gmail.com
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Making Agile Pay

  1. 1. Making Agile Pay Alas! how deeply painful is all PAYMENT! [email_address]
  2. 2. Disclaimer <ul><li>I reserve the right to give you advice which conflicts with the ‘norm’. </li></ul><ul><ul><li>Based on my experiences not set texts! </li></ul></ul><ul><li>I reserve the right to be heretical WRT ‘sacred’ texts’
  3. 3. Culture eats strategy for breakfast </li></ul><ul><ul><li>So pick only those battles you can win.. </li></ul></ul>
  4. 4. Devt. Cost– what’s the big deal? <ul><li>Customer “changes their mind” </li></ul><ul><ul><li>Misinterpretations – requirements </li></ul></ul><ul><li>Takes longer than expected – cascading impacts – badly estimated?
  5. 5. Testing reveals too many problems – cost of rework </li></ul>
  6. 6. There’s a hole in my bucket.. <ul><li>Reduce scope for misinterpretations
  7. 7. Enable / work with / assume change
  8. 8. Improve levels of inspection/ testing
  9. 9. Reduce financial exposure per delivery </li></ul>Agile !!
  10. 10. Impedance mismatch <ul><li>Expectations..?! </li></ul>I don’t have to make commitments I don’t have to document anything I pay less for development I’ll get stuff faster I can change my mind at any time
  11. 11. Impedance mismatch <ul><li>Expectations..?! </li></ul>We can iterate over the requirement We’ll decide at the last possible moment Chaos is looming I must pin them to a plan I don’t know WHAT I’m getting
  12. 12. Fog <ul><li>XP versus scrum versus DSDM versus ..
  13. 13. Terminology
  14. 14. Religion
  15. 15. DSDM </li></ul><ul><ul><li>Common reference
  16. 16. Business – focused terminology
  17. 17. UK culture .. </li></ul></ul>
  18. 18. The road to hell.. <ul><li>Individuals and interactions over processes and tools
  19. 19. Working software over comprehensive documentation
  20. 20. Customer collaboration over contract negotiation
  21. 21. Responding to change over following a plan </li></ul>Agilemanifesto.org
  22. 22. And..? This will only work if: <ul><li>We can prioritise (negotiate!)
  23. 23. You’re available to collaborate
  24. 24. We keep the plan fluid </li></ul>
  25. 25. Don’t burn money <ul><li>Prioritisation – the right to negotiate </li></ul><ul><li>Incremental </li></ul><ul><ul><li>Fixed scope </li></ul></ul>Source: Standish Group : Chaos Chronicles 2000
  26. 26. Prioritisation <ul><li>You can’t have EVERYTHING
  27. 27. If you can’t prioritise then (arguably) you have no business case
  28. 28. Useful: Imagine if... </li></ul>
  29. 29. PM – same as it ever was.. <ul><li>Controlling the project
  30. 30. Planning, estimating, budgeting
  31. 31. Managing change – negotiating priorities
  32. 32. Managing risk
  33. 33. Managing quality. </li></ul>
  34. 34. PM Imperatives: Planning OR
  35. 35. Change Control <ul><li>Agree in/ out of time-box boundaries
  36. 36. Context: renegotiating priorities
  37. 37. Explicit Trade offs
  38. 38. Central log, visible record / history
  39. 39. Assumptions </li></ul><ul><ul><li>Estimates to hand
  40. 40. Velocity is known
  41. 41. Decision is objective </li></ul></ul>
  42. 42. Contract / Agreement <ul><li>Essential: </li></ul><ul><ul><li>Change control – boundaries </li><ul><li>prioritisation </li></ul><li>Deliverables – what paid for
  43. 43. Quality – nature of ‘re-work’ </li></ul></ul>
  44. 44. Contract / Agreement <ul><li>Are the right people in the room? </li></ul><ul><ul><li>Authorised for cost sign off? </li></ul></ul><ul><li>Highlight what WILL be done </li></ul><ul><ul><li>Must haves
  45. 45. Timescales
  46. 46. Preventing over-spends </li></ul></ul>
  47. 47. Making the transition
  48. 48. Caution.. <ul><li>Knee-jerk response ..
  49. 49. Not a panacea – culture?
  50. 50. Complexity?
  51. 51. Skills?
  52. 52. Budgets/Expectations? </li></ul>
  53. 53. Realistic Targets <ul><li>Avoid ‘cultish’ terminology
  54. 54. Use the dictionary not a creed..
  55. 55. Impact of IT organisation business change
  56. 56. Benefits management
  57. 57. Agree benchmark/ targets. </li></ul>
  58. 58. Stakeholder buy-in <ul><li>How much will this cost?
  59. 59. What will be delivered?
  60. 60. How will I know whether you’re on track
  61. 61. How will I know that what you’re building will work. </li></ul>
  62. 62. Roadmap <ul><li>Small projects </li></ul><ul><ul><li>Minimal risk
  63. 63. Piecemeal technique adoption
  64. 64. Perceived wisdom </li></ul></ul><ul><li>Critical projects </li></ul><ul><ul><li>Success better recognised
  65. 65. Easier to get broader support </li></ul></ul>
  66. 66. Implications <ul><li>Collaborative culture </li></ul><ul><ul><li>Stakeholder time!
  67. 67. TRUST </li></ul></ul><ul><li>Decisions ‘at last minute’ rather than up front
  68. 68. Freedom to honour the ‘spirit’ of the contract
  69. 69. Team skill sets </li></ul>
  70. 70. Summary <ul><li>Principles, culture are key
  71. 71. Methods are NOT recipes </li></ul>[email_address]

×