This is a presentation that Arin Sime of AgilityFeat gave at the 2013 Innovate Virginia conference, on 5 reasons why you will love to hate agile development. He presents 5 different areas that as an agile coach he has often seen teams struggle with when moving to agile methods. For each area, Arin discussed why you should try it anyways and suggested strategies for tackling the problems head on.
5. 5 Things you’ll love to hate about Agile Development
#1: Pair Programming
6. Pair Programming
2 developers working together on
the same story, using the same
computer and keyboard. One
Driver and one Navigator, and
they must switch roles regularly.
What’s the Beef?
Manager: Why pay for two
developers to only do one
thing?
Developer: But he smells,
and I don’t like to share!
7. Independent
Developers
Developers Pair
Programming
Building Feature “A”
Building Feature “A”
Test
Rework
Test
Redo
Also fewer
expensive
post-release
defects
Pairs are 15% slower, but
produce half as many bugs
Williams study showed error free code went from 70% to
85%, cutting the error rate in half.
Study by Laurie Williams of the University of Utah, as
quoted in the Economist:
http://www.economist.com/node/779429?Story_ID=779429
8. Reasons to pair program:
Lower Defect Rates
Constant Peer Review
Cross Training
Cleaner Solutions
Pairs are 15% slower, but
produce half as many bugs
Williams study showed error free code went from 70% to
85%, cutting the error rate in half.
Study by Laurie Williams of the University of Utah, as
quoted in the Economist:
http://www.economist.com/node/779429?Story_ID=779429
9. Painless Pair
Programming Ideas
Require two people to sign
up for every user story
Or only require pairing on
certain user stories
Allow “me time” daily
Enforce pair programming
most strictly on difficult or
risky changes and with new
team members
Use a sign up sheet and
rotate pairs daily or on
stories
10. 5 Things you’ll love to hate about Agile Development
#2: Test Driven
Development &
Automation
11. Test Driven
Development
Build the automated tests for each
story prior to coding the solution.
Result: Automated Test Suite &
High Quality!
Write a new
test
What’s the Beef?
Manager: Isn’t this going
to take longer?
Green (Test
Passes)
Red (Failing
Test)
Developer: How will I
maintain all these old
tests?
Refactor
Code
Write Code
Tester: You can’t automate
me! I am a human being!
Green (Test
Passes)
12. Automation frees
you to do more
exploratory testing!
Acceptance Test
Driven Development
(ATDD)
Test Driven
Development
(TDD)
http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/
13. Painless TDD Ideas
Write a new
test
Green (Test
Passes)
Start with “Manual” TDD –
write acceptance criteria
Leave legacy code behind
Red (Failing
Test)
“Cover and Modify”
Focus on unit tests first
Refactor
Code
Write Code
Green (Test
Passes)
GUI level automation
should focus on just a few
paths that cover large sets
of functionality
14. 5 Things you’ll love to hate about Agile Development
#3: Manual Testing
Patterns
15. Manual Testing
Automation is great, but
exploratory testing is still
recommended. Manual testing in
agile teams should be done within
the sprint, and is part of that
sprint’s “Definition of Done.”
What’s the Beef?
Tester: How will I have
time to do quality testing
in each sprint? What about
regression testing?
Developer: So I have to be
done 2 days early now?
Then what do I do?
18. A Typical 2-week Cadence
Sprint 2
Sprint 1
Monday
Tuesday
Wednesday
S1
Planning
Thursday
The last stories
should have made
it to testing
The first stories
should be in
testing by now
S2
Planning
Monday of the new sprint
is a good time for testers
to regression test
Friday
S1 Demo
& Retro
Developers work
ahead, help test,
maybe refactor
S2 Demo
& Retro
19. Painless Testing Ideas
Enforce small user stories!
Developers deliver highest
value stories first in the sprint
In-sprint testing focuses only
on the stories at hand
Use the beginning of the next
sprint to regression test
before deploying the current
sprint
In sprint bugs are
communicated, not tracked
20. 5 Things you’ll love to hate about Agile Development
#4: Branching & Release
Streams
21. Release Streams
Agile teams work in small chunks,
and deployments happen on
cadences like this:
Scrum – deploy at end of sprint
What’s the Beef?
Developer: I have to work
in multiple branches every
day!?!?
Kanban – deploy story by story
This means frequent deployments,
and multiple branches to keep
code independently testable and
deployable.
Release Engineer: I hate
merging, and now I hate U.
Tester: How do I know
what codebase I am
testing?
23. Branching Challenges
for Agile teams
Deploy frequently
Work on very small stories
Work towards big goals, aka
“epics”
Balance production fixes
with ongoing work
Keep the testing
environments straight
26. Hot fixes to production
epic
sprint_x
sprint_x+1
sprint_x+2
master
hf_issue
testing
production
Hot fixes to production should be rare …
use the sprints instead when ever possible!
27. 5 Things you’ll love to hate about Agile Development
#5: Iterative Architecture
& Design
28. Iterative Design &
Architecture
Vision is good, but detailed design
documents are bad. Remember
that whole “working software over
comprehensive documentation”
thing?
Agile teams work in small chunks,
and architectural and UX/visual
design tasks should be done at the
last responsible moment.
What’s the Beef?
Architect: No more design
documents? I can’t decide
whether to kiss you or
punch you right now.
Visual Designer: I’m an
artist, don’t oppress me!
Developer: FR33D0M!!!
39. 5 Things you’ll love to hate about Agile Development
Additional Slides
40. A Typical 2-week Cadence
Sprint 2
Sprint 1
Monday
UX has wireframes
approved by the
team or list of S1
revisions
Planning
Tuesday
Wednesday
UX now knows
what wireframes
Thursday
to focus on…
Friday
S2
Prioritization
Team now has approved
S2
S2
3 Amigos wireframes and possibly
Estimation
mockups too
S1 Demo
& Retro
S2
Planning
S3
Prioritization
S3
3 Amigos
S3
UX starts
Estimationworking ahead
on next sprint
S2 Demo
& Retro
41. Prioritization Meeting
Purpose: Review the backlog,
and adjust the priorities of
upcoming stories as necessary.
Product Owner can make
projections of when stories will
be worked on based on
historical velocity, but they
cannot commit the team.
Required Attendees:
Product Owner, Scrummaster, UX
Optional Attendees: Other
stakeholders that the Product Owner
reports to
Time: 1 hour
Look out for: Any fixed constraints or new issues from
stakeholders may require changing priorities
Outcomes: Product Owner and UX knows what stories to prepare
for the 3 Amigos meeting
42. 3 Amigos Meeting
Purpose: Review the upcoming
stories for the next sprint. This
is a chance for the team to
verify that the “Definition of
Ready” criteria are all met and
the team has a shared
understanding of the story to
be developed.
Required Attendees:
Product Owner, Scrummaster, UX,
Developers, Testers. Some teams
prefer to rotate which developers and
testers attend. It’s usually best to start
with the whole team until comfortable
with the process though.
Time: 1 hour (time boxed)
Look out for: Missing Acceptance Criteria, dependencies on external
resources or architects, edge cases that need to be considered.
Outcomes: The team agrees that this story can be estimated and can be
considered for the next sprint’s planning session.
43. Estimation Meeting
Purpose: Go through all the
candidate stories for the next
sprint. These stories should
have already been approved in
a 3 Amigos meeting, or
adjustments made based on
feedback from that meeting.
Stories are estimated by the full
team using story points.
Required Attendees:
Product Owner, Scrummaster, UX,
Developers, Testers. All developers
and testers should be present, not just
representatives in this case.
Time: 1 hour (time boxed)
Look out for: Major team disagreements on what a story means.
If stories are too big to be comfortably completed in the sprint,
they should be broken up.
Outcomes: 1-2 Sprint’s worth of User Stories are ready for
planning.
44. Planning Meeting
Purpose: The hard work has
already been done. Now the
team is just going to compare
the list of prioritized, estimated
stories to historical velocity and
decide how many to commit to
in this sprint.
Required Attendees:
Product Owner, Scrummaster, UX,
Developers, Testers. All developers
and testers should be present, not just
representatives in this case.
Time: 30 minutes - 1 hour
Look out for: It’s ok for the Product Owner to add stories at the
last minute on occasion, just prioritize and estimate them quickly
at the beginning of the meeting prior to the planning.
Outcomes: A completed Sprint that the team is comfortable
committing to and tackles the Product Owner’s highest priorities.
Notas do Editor
Add in that you do need some high level customer research is needed up front
Lean UX is about doing this iteratively – take one bite at a timehttp://upload.wikimedia.org/wikipedia/commons/0/01/Leafcutter_ants_transporting_leaves.jpg