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