Better, faster, cheaper.  Lean and agile approaches to IT development <ul><li>Marc McNeill, ThoughtWorks </li></ul>
IT doesn’t have a track record
“Two thirds of (IT) projects are challenged.”. Source: The Standish Group CHAOS Reports
  Over budget by  189% . Source: The Standish Group CHAOS Reports
  Over schedule by  220% . Source: The Standish Group CHAOS Reports
  Only  61%  of features delivered. Source: The Standish Group CHAOS Reports
66%  of projects fail or are ‘marginal’. Source: The Standish Group CHAOS Reports
$3.45 billion tax-credit overpayment UK Inland Revenue $2.6 billion spent system cancelled US Federal Aviation Administrat...
Poor Quality Slow to Deliver Expensive
Better Faster Cheaper
What if…
Lean
Agile
but first...
Context just a little
 
A Company with a purpose
To be the home for the best knowledge workers in the world
To revolutionise the way software is delivered  to make a positive difference to business and to society
Consultancy Global Delivery Training Products 1000+ employees 6 countries 15 years
A story
The business has an idea Increase revenue Decrease costs Regulatory pressures Cartoons courtesy of http://designcomics.org/
The idea is analysed High level design Detailed design
This takes time
The business sign off on the requirements
(Lots of requirements)
Developers start writing code
It gets tested
Then deployed
But it doesn’t always work like this
Long feedback cycles
The business  changes
Dates slip, scope gets cut, effort wasted
Value is not delivered <ul><li>High project failure rate </li></ul><ul><li>High cost of change </li></ul><ul><li>Permanent...
A  different  story?
01.  Agile
http://agilemanifesto.org/
02.  Lean
Scientific management “ It is only through  enforced  standardization of methods,  enforced  adoption of the best implemen...
Lean Just in time “ All we are doing is looking at the time line, from the point the customer gives us an order to the poi...
Just in time Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems vis...
The story revisited
(v) Value-Added Time (e) Elapsed Time (c) Cumulative Elapsed Time Adapted from http://www.thoughtworks.com/pdfs/lean-qtb-j...
Requirements Gathering & Analysis Review & Approve Req. Spec. Solution Design Review & Approve Tech. Spec. (v) 1 Week (e) ...
Requirements Gathering & Analysis Review & Approve Req. Spec. Solution Design Review & Approve Tech. Spec. (v) 1 Week (e) ...
The lean and agile way
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Collaborative workshops
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Visioning
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Shared understanding
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Lo-fi prototyping
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Collaborative prioritisation
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Group estimation
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Lightweight documentation
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Just in time B...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Just in time B...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Just in time B...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quali...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e...
Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e...
Lower cost of change Cost of Change Time <ul><li>More defects prevented and fixed </li></ul><ul><li>Continuous testing </l...
Adaptive planning Scope Time Release
Adaptive planning Scope Time Release
So who does this?
http://www.thoughtworks.com/our-clients/case-studies/case-studies.html
“Too  risky  for my mission critical applications”
http://www.thoughtworks.com/our-clients/case-studies/case-studies.html
Marc McNeill Hong Kong Practice Lead [email_address]
Upcoming SlideShare
Loading in...5
×

Better, faster, cheaper. Lean and agile approaches to IT development

9,887

Published on

Introduction to the benefits of lean and agile software development.

Published in: Technology, Business
1 Comment
83 Likes
Statistics
Notes
  • greate
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
9,887
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
1
Likes
83
Embeds 0
No embeds

No notes for slide
  • Transcript of "Better, faster, cheaper. Lean and agile approaches to IT development"

    1. 1. Better, faster, cheaper. Lean and agile approaches to IT development <ul><li>Marc McNeill, ThoughtWorks </li></ul>
    2. 2. IT doesn’t have a track record
    3. 3. “Two thirds of (IT) projects are challenged.”. Source: The Standish Group CHAOS Reports
    4. 4. Over budget by 189% . Source: The Standish Group CHAOS Reports
    5. 5. Over schedule by 220% . Source: The Standish Group CHAOS Reports
    6. 6. Only 61% of features delivered. Source: The Standish Group CHAOS Reports
    7. 7. 66% of projects fail or are ‘marginal’. Source: The Standish Group CHAOS Reports
    8. 8. $3.45 billion tax-credit overpayment UK Inland Revenue $2.6 billion spent system cancelled US Federal Aviation Administration $160 million lost because of ERP system problems Hewlett-Packard $527 million written off supply chain system abandoned J Sainsbury plc
    9. 9. Poor Quality Slow to Deliver Expensive
    10. 10. Better Faster Cheaper
    11. 11. What if…
    12. 12. Lean
    13. 13. Agile
    14. 14. but first...
    15. 15. Context just a little
    16. 17. A Company with a purpose
    17. 18. To be the home for the best knowledge workers in the world
    18. 19. To revolutionise the way software is delivered to make a positive difference to business and to society
    19. 20. Consultancy Global Delivery Training Products 1000+ employees 6 countries 15 years
    20. 21. A story
    21. 22. The business has an idea Increase revenue Decrease costs Regulatory pressures Cartoons courtesy of http://designcomics.org/
    22. 23. The idea is analysed High level design Detailed design
    23. 24. This takes time
    24. 25. The business sign off on the requirements
    25. 26. (Lots of requirements)
    26. 27. Developers start writing code
    27. 28. It gets tested
    28. 29. Then deployed
    29. 30. But it doesn’t always work like this
    30. 31. Long feedback cycles
    31. 32. The business changes
    32. 33. Dates slip, scope gets cut, effort wasted
    33. 34. Value is not delivered <ul><li>High project failure rate </li></ul><ul><li>High cost of change </li></ul><ul><li>Permanent state of maintenance </li></ul><ul><li>Little innovation </li></ul><ul><li>Unhappy stakeholders </li></ul><ul><li>Poor customer experience </li></ul>
    34. 35. A different story?
    35. 36. 01. Agile
    36. 37. http://agilemanifesto.org/
    37. 38. 02. Lean
    38. 39. Scientific management “ It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standards and enforcing this cooperation rests with management alone.” Frederick Winslow Taylor Any colour so long as it is black
    39. 40. Lean Just in time “ All we are doing is looking at the time line, from the point the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value added wastes.” Taiichi Ohno
    40. 41. Just in time Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement
    41. 42. The story revisited
    42. 43. (v) Value-Added Time (e) Elapsed Time (c) Cumulative Elapsed Time Adapted from http://www.thoughtworks.com/pdfs/lean-qtb-jun08.pdf Requirements Gathering & Analysis (v) 1 Week (e) 4 Weeks (c) 4 Weeks Review & Approve Req. Spec. (v) 1 Day (e) 2 Weeks (c) 6 Weeks Solution Design (v) 2 Weeks (e) 6 Weeks (c) 12 Weeks Review & Approve Tech. Spec. (v) 1 Day (e) 2 Weeks (c) 14 Weeks Build Solution (Coding) (v) 8 Weeks (e) 14 Weeks (c) 28 Weeks System testing (v) 3 Weeks (e) 3 Weeks (c) 31 Weeks User Acceptance Testing (UAT) (v) 3 Weeks (e) 3 Weeks (c) 34 Weeks Deploy (v) 1 Week (e) 2 Weeks (c) 36 Weeks
    43. 44. Requirements Gathering & Analysis Review & Approve Req. Spec. Solution Design Review & Approve Tech. Spec. (v) 1 Week (e) 4 Weeks (c) 4 Weeks (v) 1 Day (e) 2 Weeks (c) 6 Weeks (v) 2 Weeks (e) 6 Weeks (c) 12 Weeks (v) 1 Day (e) 2 Weeks (c) 14 Weeks Deploy User Acceptance Testing (UAT) System testing Build Solution (Coding) (v) 1 Week (e) 2 Weeks (c) 36 Weeks (v) 3 Weeks (e) 3 Weeks (c) 34 Weeks (v) 3 Weeks (e) 3 Weeks (c) 31 Weeks (v) 8 Weeks (e) 14 Weeks (c) 28 Weeks <ul><li>Total Elapsed Time = 36 Weeks </li></ul><ul><li>Estimated Project Cost (at $50k per week) = $1.8M </li></ul><ul><li>Cycle Time Efficiency = 53% </li></ul><ul><li>Systemic Faults: </li></ul><ul><ul><li>Inefficient </li></ul></ul><ul><ul><li>Slow, expensive & poor quality </li></ul></ul><ul><ul><li>Inflexible </li></ul></ul><ul><ul><li>System often fails </li></ul></ul>
    44. 45. Requirements Gathering & Analysis Review & Approve Req. Spec. Solution Design Review & Approve Tech. Spec. (v) 1 Week (e) 4 Weeks (c) 4 Weeks (v) 1 Day (e) 2 Weeks (c) 6 Weeks (v) 2 Weeks (e) 6 Weeks (c) 12 Weeks (v) 1 Day (e) 2 Weeks (c) 14 Weeks Deploy User Acceptance Testing (UAT) System testing Build Solution (Coding) (v) 1 Week (e) 2 Weeks (c) 36 Weeks (v) 3 Weeks (e) 3 Weeks (c) 34 Weeks (v) 3 Weeks (e) 3 Weeks (c) 31 Weeks (v) 8 Weeks (e) 14 Weeks (c) 28 Weeks Extra Features Defects Defects Waiting (v) Value-Added Time (e) Elapsed Time (c) Cumulative Elapsed Time Movement Waiting Excess Inventory Movement Waiting Excess Inventory
    45. 46. The lean and agile way
    46. 47. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks
    47. 48. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Collaborative workshops
    48. 49. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Visioning
    49. 50. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Shared understanding
    50. 51. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Lo-fi prototyping
    51. 52. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Collaborative prioritisation
    52. 53. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Group estimation
    53. 54. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Lightweight documentation
    54. 55. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks
    55. 56. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance
    56. 57. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Just in time
    57. 58. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Just in time Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement User stories
    58. 59. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Just in time Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Adaptive planning
    59. 60. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Just in time Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Spike to solve hard technical problems through real experiments
    60. 61. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Test driven development Just in time Build in quality
    61. 62. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Continuous integration Just in time Build in quality
    62. 63. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Paired programming Just in time Build in quality
    63. 64. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement The right documentation Just in time
    64. 65. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Reduce waste Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Continuous feedback - showcases Just in time
    65. 66. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Collective ownership Just in time Reduce waste
    66. 67. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality People and teamwork Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Stand-ups Just in time Reduce waste
    67. 68. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Time boxed increments Just in time Reduce waste People and teamwork
    68. 69. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Sustainable pace Just in time Reduce waste People and teamwork
    69. 70. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Patterns, standards and ubiquitous language Just in time Reduce waste People and teamwork
    70. 71. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance Build in quality Regular cadence Stabilise and standardise Make problems visible Better quality Lower cost Shorter lead times Higher morale Continuous improvement Information radiators Just in time Reduce waste People and teamwork
    71. 72. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e) 10 Weeks (c) 14 Weeks (v) Value-Added Time (e) Elapsed Time (c) Cumulative Elapsed Time
    72. 73. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e) 10 Weeks (c) 14 Weeks (v) Value-Added Time (e) Elapsed Time (c) Cumulative Elapsed Time Deploy User Acceptance Testing (UAT) System testing (v) 1 Week (e) 2 Weeks (c) 18 Weeks (v) 1 Week (e) 1 Week (c) 16 Weeks (v) 1 Week (e) 1 Week (c15 Weeks
    73. 74. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e) 10 Weeks (c) 14 Weeks Deploy User Acceptance Testing (UAT) System testing (v) 1 Week (e) 2 Weeks (c) 18 Weeks (v) 1 Week (e) 1 Week (c) 16 Weeks (v) 1 Week (e) 1 Week (c15 Weeks (v) Value-Added Time (e) Elapsed Time (c) Cumulative Elapsed Time
    74. 75. Requirements Gathering & Analysis (v) 3 Week (e) 4 Weeks (c) 4 Weeks Testing Design & Build User Acceptance (v) 8 Weeks (e) 10 Weeks (c) 14 Weeks Deploy User Acceptance Testing (UAT) System testing (v) 1 Week (e) 2 Weeks (c) 18 Weeks (v) 1 Week (e) 1 Week (c) 16 Weeks (v) 1 Week (e) 1 Week (c15 Weeks <ul><li>Total Elapsed Time = 18 Weeks (from 36 weeks) </li></ul><ul><li>Estimated Project Cost = $900,000 (from $1.8M) </li></ul><ul><li>Cycle Time Efficiency = 78% (from 53%) </li></ul><ul><li>Lean Concepts Applied: </li></ul><ul><ul><li>Eliminate Waste </li></ul></ul><ul><ul><li>Build Quality In </li></ul></ul><ul><ul><li>Defer decision making and adaptively plan </li></ul></ul>
    75. 76. Lower cost of change Cost of Change Time <ul><li>More defects prevented and fixed </li></ul><ul><li>Continuous testing </li></ul><ul><li>Fast feedback </li></ul><ul><li>Adaptive planning </li></ul>Traditional Project Agile Project
    76. 77. Adaptive planning Scope Time Release
    77. 78. Adaptive planning Scope Time Release
    78. 79. So who does this?
    79. 80. http://www.thoughtworks.com/our-clients/case-studies/case-studies.html
    80. 81. “Too risky for my mission critical applications”
    81. 82. http://www.thoughtworks.com/our-clients/case-studies/case-studies.html
    82. 83. Marc McNeill Hong Kong Practice Lead [email_address]

    ×