Another Agile Intro

642 views
574 views

Published on

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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
642
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

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

    ×