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

1. Agile

2. “Modern software systems are hard to build,
because we’ve already built the easy ones”
- Tom DeMarco

3. Software development
processes are all about risk

4. Pure Waterfall Modified Waterfall
Spiral Evolutionary Delivery
Staged delivery
Evolutionary Prototyping
Design-to-schedule
Commercial Off The Shelf
Code and fix

5. People are risk
management devices

7. What does this tell us?

8. We evolved to deal with
risks that change rapidly

9. Software risks
aren’t like that

10. 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

11. 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

12. 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

13. What’s the biggest risk for
your project?

14. Process History

15. http://www.flickr.com/photos/a_mason/11936023/

16. Waterfall?

17. 1970 - Winston Royce
“Managing the Development
of Large Software Systems”

19. Adopted for commercial
development

20. Worked ok

21. Biggest risk - cost of delivery

22. Requirements well defined
by existing processes

23. But what did Royce build?

24. Spacecraft control systems!

27. Royce’s other advice...

28. 1. Program Design Comes
First

29. 2. Document the Design

30. 3. Do it Twice

31. 4. Plan, Control and Monitor
Testing

32. 5. Involve the Customer

33. We see hints of something
more than just waterfall

34. “If the effort runs
30 months then this early
development of a pilot model
might be scheduled for 10
months.”

35. “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.”

36. Fast forward - February 2001

39. Agile Methods

40. Scope, Time, Money, Quality

41. Quality is a highly non-linear
control variable

42. Fix Quality!

43. Our biggest risk is uncertainty
- embrace it!

44. Put a stake in the sand

45. Assume our guesses are
roughly right, but they will
need to change

46. Unity and Focus

47. One application, one team,
one goal

48. Delivering the best application
we can for the time and
money available

49. Agile Values

50. Plenty of subtly different
alternatives

51. Transparency
Rapid Feedback
Reduce Waste
Be Adaptive

52. Waste
Partially Done Hand-offs
Work Delays
Extra Features Defects
Task Switching Relearning

53. Agile Practices

54. Some are from Scrum

55. Some are from Extreme
Programming

56. Some are from Feature
Driven Development

57. All are consistent with values

58. I won’t go into them all

59. Whole Team

60. Feature Team

61. Continuously
Deliver Value

62. Eliminate anything that
doesn’t deliver value

63. Make sure
everything relates
to a need

64. Epics

65. User Stories

66. Acceptance
Criteria

67. All Just-In-Time

68. Deliver Iteratively
and Incrementally

69. Deliver Working
Software

70. It’s not done until it
does what the
customer expected

71. It’s not done until it’s
ready for production

72. Keep the cost of
change low

73. Automated tests

74. Unit tests

75. Functional Tests

76. High quality
implementation

77. Design for testability

78. Pair programming

79. http://www.flickr.com/photos/adewale_oshineye/310704940

80. It can be fun

81. It’s very effective

82. Be prepared to learn

83. About the problem
domain

84. About the technical
solution

85. New skills

86. Differentiate on
skill and knowledge,
not on title

87. Be prepared to step
outside your role

88. Feedback on
technical
performance

89. Test code coverage

90. Code quality metrics

91. Duplication

92. Builds need to be
FAST

93. Rapid testability
is a constraint,
not an option

94. Architectures
and tools
will need to adapt
too

95. Learn TDD

96. Learn to refactor

97. Learn to write as
little as possible

98. Learn to answer
questions without
certainty

99. Share

100. Standup meetings are
mandatory

101. Err on the side of
sharing too much

102. Big Visible Charts

103. Value personal
communication

104. Collaborate

105. We succeed or fail
as a team

106. Reflect

107. Whole Team
Retrospectives

108. Change practices
and tools

109. Don’t be afraid to
experiment

110. But know when
to stop

111. Understand what you’re
trying to get better AT

112. Escalate

113. Ask politely and
reasonably

114. Set expectations

115. Don’t be afraid

116. Don’t wait

117. Change

118. Not just once,
continuously

119. Forming Storming
Performing Norming

120. Will try to keep
teams intact

121. “If members of a team don’t care about
each other and what they are doing, XP
is doomed”
Kent Beck

122. Deliver a minimal
viable system asap
then extend it

123. http://electsp.blogspot.com
http://sites.google.com/site/
agileplanning/
steve.hayes@cogentconsultin
g.com.au

124. Question Time