Making Agile Pay

559 views
505 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
1 Comment
1 Like
Statistics
Notes
  • 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
No Downloads
Views
Total views
559
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • Lord byron
  • 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]

    ×