1. Agile Development

2. We want to build software,
but how do we go about doing that?

3. Waterfall Development

4. Waterfall Development
• This is the way industrial engineers built
concrete items. It works great.
• We want to build software, and this is a
terrible idea.

5. Waterfall Development
{side story about the USPS}

6. The average software project fails; therefore,
we must strive for excellence.*

7. The average software project fails; therefore,
we must strive for excellence.*
-paraphrased from Chef Gordon Ramsay talking about restaurants

8. What is Agile?
Agile manifesto
Proposed by Kent Beck, Martin Fowler, et al.

9. What is Agile?
Agile manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

10. What is Agile?
Agile manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
There is value in the items on the right, but
more value in the item on the left.

11. What is Agile?
Various methodologies:
• Scrum
• eXtreme Programming (XP)
• Lean

14. Customer satisfaction by rapid delivery of useful
software

15. Customer satisfaction by rapid delivery of useful
software
Rapid delivery means weeks – not months.
Useful software means a noticeable difference.

16. Welcome changing requirements, even late in
development.

17. Welcome changing requirements, even late in
development.

18. Welcome changing requirements, even late in
development
Requirements change b/c:
Business needs change
Understanding changes (yours & theirs)
Problems solve themselves or require a new approach
Competitors pop-up

19. Welcome changing requirements, even late in
development
When requirements or understanding
changes, you are free to re-estimate time
restraints and put the feature off for another
iteration.

20. Working software is delivered frequently (weeks
rather than months)

21. Working software is delivered frequently (weeks
rather than months)
Notice the word “working.” If you rollout
weekly, you’ll quickly learn to test early and
often rather than putting it off.

22. Working software is delivered frequently (weeks
rather than months)
In order to achieve weekly releases, you must
break large problems into smaller problems.
You also focus on the really important problems.

23. Working software is the principal measure of
progress

25. Working software is the principal measure of
progress.
Users can see and understand working software.
They can also see what isn’t working. There is
no better metric.

26. Working software is the principal measure of
progress.
“Almost done” is useless for the customer.

27. Sustainable development, able to maintain a
constant pace.

28. Sustainable development, able to maintain a
constant pace.
Burnout is a real concern amongst developers.
Limit overtime work.

29. Close, daily cooperation between business
people and developers.

30. Close, daily cooperation between business
people and developers.
Even if it’s just 5 minutes, daily talks are critical.
You don’t want to build excess software.

31. Face-to-face conversation is the best form of
communication (co-location).

32. Face-to-face conversation is the best form of
communication (co-location).
Let’s face it, face-to-face is best. You can read
mannerisms and tone of voice. You need the
feedback.

33. Projects are built around motivated
individuals, who should be trusted.

34. Projects are built around motivated individuals,
who should be trusted.
If you can’t trust them, they shouldn’t be
working with you.

35. Projects are built around motivated
individuals, who should be trusted.
“Oh, Larry is working on it? You’ll have to make
him do it.”

36. Continuous attention to technical excellence and
good design.

37. Continuous attention to technical excellence and
good design.
Shortcuts will destroy you. I spent 3 weeks
building a “shortcut” that should have taken 3
days. Now I have bad software that took longer
to deliver.

38. Continuous attention to technical excellence and
good design.
Use design patterns (where appropriate), take
advantage of the language’s features, etc.

39. Simplicity—the art of maximizing the amount of
work not done—is essential

40. Simplicity—the art of maximizing the amount of
work not done—is essential.
Plans change, understanding changes, and
simple things are easier to test.
Quit building things that you won’t need.

41. Self-organizing teams

42. Self-organizing teams
A “team” isn’t just a group of people with a
common assignment. They should have a
common spirit and exercise individuals’
strengths.
A good team “jells” well.
-Peopleware

43. Self-organizing teams
A self-organized team requires no job titles. Job
functions overlap, and everyone just falls into
place.

44. Self-organizing teams
A self-organized team requires no job titles. Job
functions overlap, and everyone just falls into
place.
They look for work rather than wait for it to be
assigned.

45. Regular adaptation to changing circumstances.

46. Regular adaptation to changing circumstances.
Things will change:
requirements
team members
leadership/direction
funding

47. How do I start implementing agile?
Agile development should make things easier.
Slowly implement techniques starting with your
own work. Then move it out to the team.

48. How do I start implementing agile?
• Get “buy-in” from the user (customer, another
department, whoever).
• Testing (TDD).
• Version control (git, subversion).
• Break the large problems into small problems
and rank let the customer rank them with
priority.

49. How do I start implementing agile?
Get “buy-in” from the user
Meet with the a user, pick a small
feature, implement it in a week or two. Do it
again.

50. How do I start implementing agile?
Test:
unit tests
regression tests
acceptance tests

51. How do I start implementing agile?
Version control:
Use git, mercurial, subversion, etc.

52. How do I start implementing agile?
Break the large problems into small problems
and rank them with priority.
Sit with the user and break feature requests into
smaller requests, make time estimates, and let
the user rank them with priority.

53. Wrap Up

54. Books on Agile

55. Thanks!
Name: David Haskins
Connect with me on LinkedIn: davidhaskins@ieee.org