5 Things you’ll love to hate about
Agile Development

@ArinSime
Arin@AgilityFeat.com
434 996 5226
Design & Development in
Central America
A few that have paid us…
Hey, Look at me! I can talk.
5 Things you’ll love to hate about Agile Development

#1: Pair Programming
Pair Programming
2 developers working together on
the same story, using the same
computer and keyboard. One
Driver and one...
Independent
Developers
Developers Pair
Programming

Building Feature “A”

Building Feature “A”

Test

Rework

Test

Redo

...
Reasons to pair program:
Lower Defect Rates
Constant Peer Review
Cross Training
Cleaner Solutions

Pairs are 15% slower, b...
Painless Pair
Programming Ideas

 Require two people to sign
up for every user story
 Or only require pairing on
certain...
5 Things you’ll love to hate about Agile Development

#2: Test Driven
Development &
Automation
Test Driven
Development
Build the automated tests for each
story prior to coding the solution.
Result: Automated Test Suit...
Automation frees
you to do more
exploratory testing!
Acceptance Test
Driven Development
(ATDD)
Test Driven
Development
(TD...
Painless TDD Ideas
Write a new
test
Green (Test
Passes)

 Start with “Manual” TDD –
write acceptance criteria
 Leave leg...
5 Things you’ll love to hate about Agile Development

#3: Manual Testing
Patterns
Manual Testing
Automation is great, but
exploratory testing is still
recommended. Manual testing in
agile teams should be ...
Sprint BusynessTM

BusynessTM

O
M
G

developers
This is what
typically happens,
but is not “good”.

testers

lolcats
Days...
Sprint BusynessTM
developers

BusynessTM

O
M
G

testers

lolcats

Instead, let’s make
sure stories are
small and delivere...
A Typical 2-week Cadence

Sprint 2

Sprint 1

Monday

Tuesday

Wednesday

S1
Planning

Thursday

The last stories
should h...
Painless Testing Ideas

 Enforce small user stories!
 Developers deliver highest
value stories first in the sprint
 In-...
5 Things you’ll love to hate about Agile Development

#4: Branching & Release
Streams
Release Streams
Agile teams work in small chunks,
and deployments happen on
cadences like this:
Scrum – deploy at end of s...
“Big Bang” Branching
big_bang

master

branch
merge

Deploy to
Production
Branching Challenges
for Agile teams
 Deploy frequently

 Work on very small stories
 Work towards big goals, aka
“epic...
Branching by features
feature_1

feature_4

feature_2

feature_3

master

branch
merge

Deploy to
Production

Deploy to
Pr...
Sprint Branching Strategy
epic

sprint_x

sprint_x+1

sprint_x+2

master
testing

production
A little complicated … but th...
Hot fixes to production
epic

sprint_x

sprint_x+1

sprint_x+2

master
hf_issue
testing

production
Hot fixes to productio...
5 Things you’ll love to hate about Agile Development

#5: Iterative Architecture
& Design
Iterative Design &
Architecture
Vision is good, but detailed design
documents are bad. Remember
that whole “working softwa...
Vision and customer research are good things
But details
are waste
Defining in pieces
Defining in pieces
Defining in pieces
5 Things you’ll love to hate about Agile Development

Why you should bother…
Avoid Big Bang Deployments
“Big release”
Feature B
Feature A
Design
Change
Feature C

Bug fix
Pricing
Change

Which was th...
Instead…

Define
Biz Test

Code it!

Test the
code

Deploy!

Measure
results

Learn!
@ArinSime
Arin@AgilityFeat.com
434 996 5226
Testing process changes
Standard
path
Common
entry
point

Common
conversion or
exit point

Which
path?

Alternate
path

Lo...
5 Things you’ll love to hate about Agile Development

Additional Slides
A Typical 2-week Cadence

Sprint 2

Sprint 1

Monday
UX has wireframes
approved by the
team or list of S1
revisions
Planni...
Prioritization Meeting
 Purpose: Review the backlog,
and adjust the priorities of
upcoming stories as necessary.
Product ...
3 Amigos Meeting
 Purpose: Review the upcoming
stories for the next sprint. This
is a chance for the team to
verify that ...
Estimation Meeting
 Purpose: Go through all the
candidate stories for the next
sprint. These stories should
have already ...
Planning Meeting
 Purpose: The hard work has
already been done. Now the
team is just going to compare
the list of priorit...
5 reasons you'll love to hate Agile Development
5 reasons you'll love to hate Agile Development
5 reasons you'll love to hate Agile Development
Upcoming SlideShare
Loading in...5
×

5 reasons you'll love to hate Agile Development

1,476

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,476
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 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
  • 5 reasons you'll love to hate Agile Development

    1. 1. 5 Things you’ll love to hate about Agile Development @ArinSime Arin@AgilityFeat.com 434 996 5226
    2. 2. Design & Development in Central America
    3. 3. A few that have paid us…
    4. 4. Hey, Look at me! I can talk.
    5. 5. 5 Things you’ll love to hate about Agile Development #1: Pair Programming
    6. 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. 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. 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. 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. 10. 5 Things you’ll love to hate about Agile Development #2: Test Driven Development & Automation
    11. 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. 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. 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. 14. 5 Things you’ll love to hate about Agile Development #3: Manual Testing Patterns
    15. 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. 16. Sprint BusynessTM BusynessTM O M G developers This is what typically happens, but is not “good”. testers lolcats Days of the Sprint
    17. 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. 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. 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. 20. 5 Things you’ll love to hate about Agile Development #4: Branching & Release Streams
    21. 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. 22. “Big Bang” Branching big_bang master branch merge Deploy to Production
    23. 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. 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. 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. 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. 27. 5 Things you’ll love to hate about Agile Development #5: Iterative Architecture & Design
    28. 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. 29. Vision and customer research are good things But details are waste
    30. 30. Defining in pieces
    31. 31. Defining in pieces
    32. 32. Defining in pieces
    33. 33. 5 Things you’ll love to hate about Agile Development Why you should bother…
    34. 34. Avoid Big Bang Deployments “Big release” Feature B Feature A Design Change Feature C Bug fix Pricing Change Which was the cause? meh.
    35. 35. Instead… Define Biz Test Code it! Test the code Deploy! Measure results Learn!
    36. 36. @ArinSime Arin@AgilityFeat.com 434 996 5226
    37. 37. Testing process changes Standard path Common entry point Common conversion or exit point Which path? Alternate path Log user behavior
    38. 38. 5 Things you’ll love to hate about Agile Development Additional Slides
    39. 39. 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
    40. 40. 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
    41. 41. 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.
    42. 42. 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.
    43. 43. 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.
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×