5 reasons you'll love to hate agile development
DESCRIPTION
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.TRANSCRIPT
5 Things you’ll love to hate about Agile Development
434 996 5226
Design & Development in Central America
A few that have paid us…
Hey, Look at me! I can talk.
#1: Pair Programming
5 Things you’ll love to hate about Agile Development
Pair Programming
Manager: Why pay for two developers to only do one thing?
Developer: But he smells, and I don’t like to share!
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?
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
Building Feature “A”
Building Feature “A”
Test Rework
Test
Re-do
Independent Developers
Developers Pair
ProgrammingAlso 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
Reasons to pair program:
Lower Defect RatesConstant Peer
ReviewCross Training
Cleaner Solutions
Commando Tips for Pair
Programming 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
#2: Test Driven Development &
Automation
5 Things you’ll love to hate about Agile Development
Test Driven Development
Manager: Isn’t this going to take longer?
Developer: How will I maintain all these old tests?
Tester: You can’t automate me! I am a human being!
Build the automated tests for each story prior to coding the solution. Result: Automated Test Suite & High Quality!
What’s the Beef?
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/
Commando Tips for Test Automation
Start with “Manual” TDD – write acceptance criteria
Leave legacy code behind
“Cover and Modify”
Focus on unit tests first
GUI level automation should focus on just a few paths that cover large sets of functionality
#3: Manual Testing Patterns
5 Things you’ll love to hate about Agile Development
Manual Testing
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?
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?
Sprint BusynessTMB
usyn
essT
M
OMG
lolcats
Days of the Sprint
developers
testers
This is what typically happens, but is not “good”.
Sprint BusynessTMB
usyn
essT
M
OMG
lolcats
Days of the Sprint
developers
testers
Instead, let’s make sure stories are small and delivered frequently to testing…
A Typical 2-week Cadence
Monday Tuesday Wednesday Thursday Friday
Spr
int
1
S1 Planning
S1 Demo & Retro
Spr
int
2
S2 Planning
S2 Demo & Retro
The first stories should be in testing
by now
The last stories should have made it to
testing
1st day of the new sprint is a good time
for testers to regression testing
Developers work ahead,
help test, maybe refactor
Commando Tips for Manual
Testing Patterns 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
#4: Branching & Release Streams
5 Things you’ll love to hate about Agile Development
Release Streams
Developer: I have to work in multiple branches every day!?!?
Release Engineer: I hate merging, and now I hate U.
Tester: How do I know what codebase I am testing?
Agile teams work in small chunks, and deployments happen on cadences like this:
Scrum – deploy at end of sprint
Kanban – deploy story by story
This means frequent deployments, and multiple branches to keep code independently testable and deployable.
What’s the Beef?
“Big Bang” Branching
Deploy to Production
master
big_bang
branch
merge
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
Branching by features
master
feature_1
branch
merge
Deploy to Production
feature_4
Deploy to Production
feature_2
Deploy to Production
feature_3
Works great with very independent features and a kanban style system. May be too fluid for scrum teams and large epics.
Sprint Branching Strategy
master
epic
sprint_x sprint_x+1 sprint_x+2
testing
RC
_x
RC
_x+1
RC
_x+2
production
release
release
release
A little complicated … but the value created here is balancing short term and long term work while still delivering frequent releases.
Hot fixes to production
master
epic
sprint_x sprint_x+1 sprint_x+2
testing
RC
_x
RC
_x+1
RC
_x+2
production
release
release
release
hf_issue
Hot fixes to production should be rare … use the sprints instead when ever possible!
Commando Tips for
Branching Sprint and Hotfix branches
should have a short lifespan
Epic branches should be merged into regularly to stay up to date with latest sprint work
Set clear policies for where branches are merged from
Use demo’s as a checkpoint to agree that a sprint branch is ready to send down the release path, and rotate who will handle merging tasks
#5: Iterative Architecture & Design
5 Things you’ll love to hate about Agile Development
Iterative Design &
Architecture
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!!!
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?
Vision and customer research are good things
But details are waste
Defining in pieces
Defining in pieces
Defining in pieces
Commando Tips for Iterative
DesignWrite all documentation
“just in time”
UX/Visual design can work a sprint or two ahead at most
Design documents should start as whiteboard photographs, and stay there until needs require more.
Use pair programming to enforce coding standards
Why you should bother…
5 Things you’ll love to hate about Agile Development
Avoid Big Bang Deployments
“Big release”
Feature A
Feature B
Bug fixDesign Change
Pricing ChangeFeature C
Which was the cause?
meh.
Instead…
Additional Slides we’ll never have time for
5 Things you’ll love to hate about Agile Development
Testing process changes
Which
path?
Common entry point
Standard path
Alternate path
Common conversion
or exit point
Log user behavior
A Typical 2-week Cadence
Monday Tuesday Wednesday Thursday Friday
Spr
int
1
S1 Planning
S1 Demo & Retro
Spr
int
2
S2 Planning
S2 Demo & Retro
S2 Estimation
S2 3 Amigos
S2 Prioritization
S3 Estimation
S33 Amigos
S3 Prioritization
UX now knows what
wireframes to focus on…
UX has wireframes
approved by the team or list
of revisions
Team now has approved wireframes
and possibly mockups too
UX starts working
ahead on next sprint
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
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. Wireframes approved or revised.
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.
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.