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
![Page 1: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/1.jpg)
5 Things you’ll love to hate about Agile Development
434 996 5226
![Page 2: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/2.jpg)
Design & Development in Central America
![Page 3: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/3.jpg)
A few that have paid us…
![Page 4: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/4.jpg)
Hey, Look at me! I can talk.
![Page 5: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/5.jpg)
#1: Pair Programming
5 Things you’ll love to hate about Agile Development
![Page 6: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/6.jpg)
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?
![Page 7: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/7.jpg)
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
![Page 8: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/8.jpg)
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
![Page 9: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/9.jpg)
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
![Page 10: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/10.jpg)
#2: Test Driven Development &
Automation
5 Things you’ll love to hate about Agile Development
![Page 11: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/11.jpg)
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?
![Page 12: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/12.jpg)
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/
![Page 13: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/13.jpg)
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
![Page 14: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/14.jpg)
#3: Manual Testing Patterns
5 Things you’ll love to hate about Agile Development
![Page 15: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/15.jpg)
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?
![Page 16: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/16.jpg)
Sprint BusynessTMB
usyn
essT
M
OMG
lolcats
Days of the Sprint
developers
testers
This is what typically happens, but is not “good”.
![Page 17: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/17.jpg)
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…
![Page 18: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/18.jpg)
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
![Page 19: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/19.jpg)
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
![Page 20: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/20.jpg)
#4: Branching & Release Streams
5 Things you’ll love to hate about Agile Development
![Page 21: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/21.jpg)
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?
![Page 22: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/22.jpg)
“Big Bang” Branching
Deploy to Production
master
big_bang
branch
merge
![Page 23: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/23.jpg)
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
![Page 24: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/24.jpg)
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.
![Page 25: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/25.jpg)
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.
![Page 26: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/26.jpg)
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!
![Page 27: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/27.jpg)
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
![Page 28: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/28.jpg)
#5: Iterative Architecture & Design
5 Things you’ll love to hate about Agile Development
![Page 29: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/29.jpg)
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?
![Page 30: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/30.jpg)
Vision and customer research are good things
But details are waste
![Page 31: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/31.jpg)
Defining in pieces
![Page 32: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/32.jpg)
Defining in pieces
![Page 33: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/33.jpg)
Defining in pieces
![Page 34: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/34.jpg)
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
![Page 35: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/35.jpg)
Why you should bother…
5 Things you’ll love to hate about Agile Development
![Page 36: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/36.jpg)
![Page 37: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/37.jpg)
Avoid Big Bang Deployments
“Big release”
Feature A
Feature B
Bug fixDesign Change
Pricing ChangeFeature C
Which was the cause?
meh.
![Page 38: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/38.jpg)
Instead…
![Page 40: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/40.jpg)
Additional Slides we’ll never have time for
5 Things you’ll love to hate about Agile Development
![Page 41: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/41.jpg)
Testing process changes
Which
path?
Common entry point
Standard path
Alternate path
Common conversion
or exit point
Log user behavior
![Page 42: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/42.jpg)
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
![Page 43: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/43.jpg)
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
![Page 44: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/44.jpg)
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.
![Page 45: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/45.jpg)
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.
![Page 46: 5 reasons you'll love to hate Agile Development](https://reader038.vdocuments.us/reader038/viewer/2022103109/540b87368d7f72f36a8b47ee/html5/thumbnails/46.jpg)
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.