5 reasons you'll love to hate agile development

5 Things you’ll love to hate about Agile Development

@ArinSimeArin@AgilityFeat.com

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…

@ArinSimeArin@AgilityFeat.com

434 996 5226

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.