Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Making Agile Pay

626 visualizaciones

Publicado el

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.

Publicado en: Tecnología, Empresariales
  • Inicia sesión para ver los comentarios

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]

×