Xpdaytuning

DELIVERING THE RIGHT INFORMATION TO THE RIGHT PEOPLE AT THE RIGHT TIME

Rachel Davies & Tim Mackinnon

Tuning XP

© Connextra 2001: delivering the right information to the right people at the right time © Connextra 2001: delivering the right information to the right people at the right time

Who are we?

•  Connextra, a product company using XP –  2.5 years continuous XP development –  Delivering contextual Java web applications –  10 developers in our team –  5 person marketing team as Customer

•  XP Developer, XTC and organizers of XP Day •  Mock Objects


Why this session?

You’ve heard about XP but how do you fit the practises to your unique project situation?

In our experience :- •  Regular tuning of the way we work helps us

get better at what we do •  Use a simple process •  Track what’s useful, Agile Metrics •  Retire Metrics which are not used


Quick Review of XP Practices

•  Whole Team •  Small Releases •  Planning Game •  Customer Tests •  Sustainable Pace •  Metaphor

•  Collective Ownership •  Continuous Integration •  Simple Design •  Test-first Development •  Refactoring •  Pair Programming •  Coding Standards


Balancing Practises


Metrics

What do we use metrics for in an XP team? •  To tune our process

–  Is there a problem? Measure it to find out

•  To meet functional requirements –  Build automated tests for measuring performance

(scalability, reliability, response times)


Tuning

•  When do we make adjustments? –  After each iteration

•  How? –  Measure –  Review –  Make adjustments (Repeat this cycle)


Iterate

•  Compare like with like –  keep iterations the same length –  between 1 to 4 weeks

•  Find the length of iteration to fit your project –  Too long and you may lose focus –  Too short and you may neglect refactoring, which

can slow you down later


Tracking

•  You need to track your Velocity •  What else do you track?

–  Decide this with your team after each iteration •  What are your concerns? •  What can you track to monitor them?

–  There are common things that crop up •  Eg, worried about pair rotation, ask pairs to record who

signed up for tasks for an iteration


Using a Wiki

Track using something simple:

•  Page per iteration •  Summary page •  Wiki documentation

–  team uses wiki as a place to put notes, instead of documentation

–  But the executing code should communicate


Make it visible!

•  Visible iteration/release plan –  Cards on a Planning Board

with progress indicators

•  Stand-up meetings –  around Planning Board

•  Visible chart ideas –  Production code bulk –  Bug density –  System performance –  Number of tests –  Code Coverage


Standups

•  Standup “Checkov” –  What happened

yesterday? –  Any new cards? –  Any customer meetings? –  Who’s “exposed”? –  Who’s pairing with who?

•  If you can’t keep it under 15 mins use a kitchen timer!


Cost of Change

•  What happens if your Velocity goes down? –  Symptoms in practices –  Process Smells –  Sniff out the cause and

fix it


Design Improvement

Velocity can go down if… •  Not enough Refactoring? •  Whiffs are:

–  Many classes must be touched for one story –  Code bulk (are you deleting things) –  Overlapping tests

•  Aim for ‘Once and Only Once’


Writing Stories

Velocity can go down if… •  Stories are Vague

–  Did you have the conversation ? –  After they are estimated, Stories are tokens for a

conversation between Customer and Dev

•  Before they are estimated some details help –  A title, author, date of writing, (see example)

•  Avoid implementation details –  As <role> I want … so that …


Customer Tests

Velocity can go down if… •  Customer expands the

story after you estimated

•  Get tests defined by your Customer upfront, then you know when you’re done

Action Result

Visit the Arsenal home page

The sports service displays links for players on that page


Continuous Integration

Velocity can go down if… •  It’s difficult to release

–  “Nightly builds are for wimps”

•  You need: –  A release machine for

your baseline –  To release with

confidence automated tests must pass

–  Moo!


Task Breakdown

•  Visble progress on story was bad –  Take the time to break a

story down into equal sized tasks

–  Tasks should be as independent as possible

–  Do a CRC session to get a rough idea

–  Don’t be afraid to work in parallel


Process Smells

•  Something doesn’t feel right –  Standups too long

•  Too much to talk about

–  Scheduling adjustments •  Woolly Acceptance tests

–  Pairs not swapping daily •  Tasks are too big

–  Silent Pairs, not engaged •  Not doing test first


Test Smells

•  Tests taking a long time to run •  Tolerating failing tests •  A simple change breaks lots of tests •  Failures due to frameworks

•  Keep trying to Automate and prove

correctness


Things We’ve Learned

Connextra supplements XP with: •  Collective Ownership of process •  Gold Cards •  Retrospectives •  Web Testing •  Hiring Practises


Collective Ownership

Extend Collective Ownership to your process Use the team as: •  Coach •  Tracker But don’t get carried away….

–  Beware the Borg!

•  People need to own something, –  Gold Cards with Show & Tell helps


Gold Cards

•  Card with a gold star on it! •  Entitles 1 day of work on anything •  2 cards per month •  Developer chooses when to use them •  Topics with business value

–  create new opportunities –  increase efficiency –  reduce risk


Retrospectives

Use team as a Barometer for last iteration: •  What did we do well? •  What could we improve? •  What puzzles us? Results in … •  Stories to be submitted to the Planning

Game •  Lone Ranger Tasks •  Tracking


Web Testing

•  Keep trying to Automate it, it’s hard •  How do you do this for:

–  Multiple platforms –  Multiple browsers –  Design appearance

•  Some solutions we have found…


Hiring Practices

•  Hire people who are XP compatible –  Very expensive mistake to correct

•  In interview ask them how they would feel/deal with: –  No comments in code –  Collective ownership –  Iterative design

•  Ask Candidate to work for half a day –  Pair program with them –  Rotate partners –  Don’t be afraid of everyday issues, new candidates see how

the team reacts –  Everyone has a stake in new hires


Conclusion

•  Keep working at it •  The process should not stagnate •  There is always room for improvement •  Have a regular health check

Xpdaytuning

Technology

right people

right information

right time connextra

right time metrics

right time tuning

iteration connextra

cycle connextra

response times connextra