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.

1. 5 Things you’ll love to hate about
Agile Development
@ArinSime
Arin@AgilityFeat.com
434 996 5226

2. Design & Development in
Central America

3. A few that have paid us…

4. Hey, Look at me! I can talk.

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?

16. Sprint BusynessTM
BusynessTM
O
M
G
developers
This is what
typically happens,
but is not “good”.
testers
lolcats
Days of the Sprint

17. Sprint BusynessTM
developers
BusynessTM
O
M
G
testers
lolcats
Instead, let’s make
sure stories are
small and delivered
frequently to
testing…
Days of the Sprint

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?

22. “Big Bang” Branching
big_bang
master
branch
merge
Deploy to
Production

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

24. Branching by features
feature_1
feature_4
feature_2
feature_3
master
branch
merge
Deploy to
Production
Deploy to
Production
Deploy to
Production
Works great with very independent features
and a kanban style system. May be too fluid
for scrum teams and large epics.

25. Sprint Branching Strategy
epic
sprint_x
sprint_x+1
sprint_x+2
master
testing
production
A little complicated … but the value created here is balancing short
term and long term work while still delivering frequent releases.

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

29. Vision and customer research are good things
But details
are waste

30. Defining in pieces

31. Defining in pieces

32. Defining in pieces

33. 5 Things you’ll love to hate about Agile Development
Why you should bother…

35. Avoid Big Bang Deployments
“Big release”
Feature B
Feature A
Design
Change
Feature C
Bug fix
Pricing
Change
Which was the cause?
meh.

36. Instead…
Define
Biz Test
Code it!
Test the
code
Deploy!
Measure
results
Learn!

37. @ArinSime
Arin@AgilityFeat.com
434 996 5226

38. Testing process changes
Standard
path
Common
entry
point
Common
conversion or
exit point
Which
path?
Alternate
path
Log user behavior

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.