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.
Agile
“Modern software systems are hard to build,
 because we’ve already built the easy ones”

             - Tom DeMarco
Software development
processes are all about risk
Pure Waterfall         Modified Waterfall

   Spiral                          Evolutionary Delivery
               Staged d...
People are risk
management devices
What does this tell us?
We evolved to deal with
risks that change rapidly
Software risks
aren’t like that
Development Risks
         • Feature creep               • Silver bullet syndrome
         • requirements or             •...
Development Risks
          •   unrealistic schedules and budgets   •   failure to manage end user
                       ...
Sources of failure
         • Lack of user           • Lack of planning
             involvement
                         ...
What’s the biggest risk for
      your project?
Process History
http://www.flickr.com/photos/a_mason/11936023/
Waterfall?
1970 - Winston Royce
“Managing the Development
of Large Software Systems”
Adopted for commercial
    development
Worked ok
Biggest risk - cost of delivery
Requirements well defined
  by existing processes
But what did Royce build?
Spacecraft control systems!
Royce’s other advice...
1. Program Design Comes
          First
2. Document the Design
3. Do it Twice
4. Plan, Control and Monitor
           Testing
5. Involve the Customer
We see hints of something
 more than just waterfall
“If the effort runs
  30 months then this early
development of a pilot model
 might be scheduled for 10
           months.”
“In this case a very special kind of broad
    competence is required on the part of the
  personnel involved. They must h...
Fast forward - February 2001
Agile Methods
Scope, Time, Money, Quality
Quality is a highly non-linear
      control variable
Fix Quality!
Our biggest risk is uncertainty
        - embrace it!
Put a stake in the sand
Assume our guesses are
roughly right, but they will
     need to change
Unity and Focus
One application, one team,
        one goal
Delivering the best application
  we can for the time and
       money available
Agile Values
Plenty of subtly different
       alternatives
Transparency
Rapid Feedback
Reduce Waste
 Be Adaptive
Waste
Partially Done   Hand-offs
    Work          Delays
Extra Features    Defects
Task Switching   Relearning
Agile Practices
Some are from Scrum
Some are from Extreme
    Programming
Some are from Feature
 Driven Development
All are consistent with values
I won’t go into them all
Whole Team
Feature Team
Continuously
Deliver Value
Eliminate anything that
 doesn’t deliver value
Make sure
everything relates
    to a need
Epics
User Stories
Acceptance
 Criteria
All Just-In-Time
Deliver Iteratively
and Incrementally
Deliver Working
   Software
It’s not done until it
     does what the
 customer expected
It’s not done until it’s
 ready for production
Keep the cost of
  change low
Automated tests
Unit tests
Functional Tests
High quality
implementation
Design for testability
Pair programming
http://www.flickr.com/photos/adewale_oshineye/310704940
It can be fun
It’s very effective
Be prepared to learn
About the problem
     domain
About the technical
    solution
New skills
Differentiate on
skill and knowledge,
      not on title
Be prepared to step
 outside your role
Feedback on
  technical
performance
Test code coverage
Code quality metrics
Duplication
Builds need to be
      FAST
Rapid testability
 is a constraint,
  not an option
Architectures
     and tools
will need to adapt
        too
Learn TDD
Learn to refactor
Learn to write as
 little as possible
Learn to answer
questions without
    certainty
Share
Standup meetings are
     mandatory
Err on the side of
sharing too much
Big Visible Charts
Value personal
communication
Collaborate
We succeed or fail
   as a team
Reflect
Whole Team
Retrospectives
Change practices
   and tools
Don’t be afraid to
  experiment
But know when
    to stop
Understand what you’re
trying to get better AT
Escalate
Ask politely and
  reasonably
Set expectations
Don’t be afraid
Don’t wait
Change
Not just once,
continuously
Forming                Storming




          Performing              Norming
Will try to keep
 teams intact
“If members of a team don’t care about
each other and what they are doing, XP
             is doomed”

             Kent B...
Deliver a minimal
viable system asap
  then extend it
http://electsp.blogspot.com
http://sites.google.com/site/
        agileplanning/
steve.hayes@cogentconsultin
          g.c...
Question Time
Another Agile Intro
Another Agile Intro
Another Agile Intro
Another Agile Intro
Another Agile Intro
Another Agile Intro
Upcoming SlideShare
Loading in …5
×

Another Agile Intro

763 views

Published on

An introduction to agile presentation that I did for a client in October, 2009

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Another Agile Intro

  1. 1. Agile
  2. 2. “Modern software systems are hard to build, because we’ve already built the easy ones” - Tom DeMarco
  3. 3. Software development processes are all about risk
  4. 4. Pure Waterfall Modified Waterfall Spiral Evolutionary Delivery Staged delivery Evolutionary Prototyping Design-to-schedule Commercial Off The Shelf Code and fix
  5. 5. People are risk management devices
  6. 6. What does this tell us?
  7. 7. We evolved to deal with risks that change rapidly
  8. 8. Software risks aren’t like that
  9. 9. Development Risks • Feature creep • Silver bullet syndrome • requirements or • Research Oriented developer gold plating development • Shortchanged quality • Weak personnel • Overly optimistic • Contractor failure schedules • Friction betwen • Inadequate design developers and customer “Rapid Development”, Steve McConnell
  10. 10. Development Risks • unrealistic schedules and budgets • failure to manage end user expectations • unclear or misunderstood scope/ • inadequate knowledge/skills objectives • misunderstanding the • lack of senior management requriements commitment to the project • continuous requirement changes • subcontracting • developing the wrong software • resource usage and performance functions • introduction of new technology • failure to gain user involvement • gold plating Unknown
  11. 11. Sources of failure • Lack of user • Lack of planning involvement • Absence of need • Lack of resources • Incomplete • Unrealistic expectations requirements • Lack of executive • Changing support requirements Standish CHAOS Report, 1995
  12. 12. What’s the biggest risk for your project?
  13. 13. Process History
  14. 14. http://www.flickr.com/photos/a_mason/11936023/
  15. 15. Waterfall?
  16. 16. 1970 - Winston Royce “Managing the Development of Large Software Systems”
  17. 17. Adopted for commercial development
  18. 18. Worked ok
  19. 19. Biggest risk - cost of delivery
  20. 20. Requirements well defined by existing processes
  21. 21. But what did Royce build?
  22. 22. Spacecraft control systems!
  23. 23. Royce’s other advice...
  24. 24. 1. Program Design Comes First
  25. 25. 2. Document the Design
  26. 26. 3. Do it Twice
  27. 27. 4. Plan, Control and Monitor Testing
  28. 28. 5. Involve the Customer
  29. 29. We see hints of something more than just waterfall
  30. 30. “If the effort runs 30 months then this early development of a pilot model might be scheduled for 10 months.”
  31. 31. “In this case a very special kind of broad competence is required on the part of the personnel involved. They must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren't worth studying at this early point, and finally arrive at an error-free program.”
  32. 32. Fast forward - February 2001
  33. 33. Agile Methods
  34. 34. Scope, Time, Money, Quality
  35. 35. Quality is a highly non-linear control variable
  36. 36. Fix Quality!
  37. 37. Our biggest risk is uncertainty - embrace it!
  38. 38. Put a stake in the sand
  39. 39. Assume our guesses are roughly right, but they will need to change
  40. 40. Unity and Focus
  41. 41. One application, one team, one goal
  42. 42. Delivering the best application we can for the time and money available
  43. 43. Agile Values
  44. 44. Plenty of subtly different alternatives
  45. 45. Transparency Rapid Feedback Reduce Waste Be Adaptive
  46. 46. Waste Partially Done Hand-offs Work Delays Extra Features Defects Task Switching Relearning
  47. 47. Agile Practices
  48. 48. Some are from Scrum
  49. 49. Some are from Extreme Programming
  50. 50. Some are from Feature Driven Development
  51. 51. All are consistent with values
  52. 52. I won’t go into them all
  53. 53. Whole Team
  54. 54. Feature Team
  55. 55. Continuously Deliver Value
  56. 56. Eliminate anything that doesn’t deliver value
  57. 57. Make sure everything relates to a need
  58. 58. Epics
  59. 59. User Stories
  60. 60. Acceptance Criteria
  61. 61. All Just-In-Time
  62. 62. Deliver Iteratively and Incrementally
  63. 63. Deliver Working Software
  64. 64. It’s not done until it does what the customer expected
  65. 65. It’s not done until it’s ready for production
  66. 66. Keep the cost of change low
  67. 67. Automated tests
  68. 68. Unit tests
  69. 69. Functional Tests
  70. 70. High quality implementation
  71. 71. Design for testability
  72. 72. Pair programming
  73. 73. http://www.flickr.com/photos/adewale_oshineye/310704940
  74. 74. It can be fun
  75. 75. It’s very effective
  76. 76. Be prepared to learn
  77. 77. About the problem domain
  78. 78. About the technical solution
  79. 79. New skills
  80. 80. Differentiate on skill and knowledge, not on title
  81. 81. Be prepared to step outside your role
  82. 82. Feedback on technical performance
  83. 83. Test code coverage
  84. 84. Code quality metrics
  85. 85. Duplication
  86. 86. Builds need to be FAST
  87. 87. Rapid testability is a constraint, not an option
  88. 88. Architectures and tools will need to adapt too
  89. 89. Learn TDD
  90. 90. Learn to refactor
  91. 91. Learn to write as little as possible
  92. 92. Learn to answer questions without certainty
  93. 93. Share
  94. 94. Standup meetings are mandatory
  95. 95. Err on the side of sharing too much
  96. 96. Big Visible Charts
  97. 97. Value personal communication
  98. 98. Collaborate
  99. 99. We succeed or fail as a team
  100. 100. Reflect
  101. 101. Whole Team Retrospectives
  102. 102. Change practices and tools
  103. 103. Don’t be afraid to experiment
  104. 104. But know when to stop
  105. 105. Understand what you’re trying to get better AT
  106. 106. Escalate
  107. 107. Ask politely and reasonably
  108. 108. Set expectations
  109. 109. Don’t be afraid
  110. 110. Don’t wait
  111. 111. Change
  112. 112. Not just once, continuously
  113. 113. Forming Storming Performing Norming
  114. 114. Will try to keep teams intact
  115. 115. “If members of a team don’t care about each other and what they are doing, XP is doomed” Kent Beck
  116. 116. Deliver a minimal viable system asap then extend it
  117. 117. http://electsp.blogspot.com http://sites.google.com/site/ agileplanning/ steve.hayes@cogentconsultin g.com.au
  118. 118. Question Time

×