I’m running two sessions at the Agile 2009 conference.

I will be running my workshop again, titled: Climbing the Dreyfus Ladder of Agile Practices. Contrary to the printed program, Liz Keogh (who knows a lot about coaching and the Dreyfus Model) will not be co-presenting this session with me though she’ll definitely be around to chat about it. The PDFed version of the presentations is available here with a slideshow version here.

In addition to this, my great colleague Alistair Jones and I will also be co-presenting an experience report, Top ten secret weapons for performance testing in an agile environment. Hope you can make it to one of these. I’m really excited to be sharing some lessons I’ve learned along the way. A PDFed version of the slides we used can be found here, and then the slideshow equivalent here.

Alistair and I will be presenting Top ten secret weapons for performance testing in an agile environment on Tuesday in the Grand Ballroom D North at 11:00am. The other session will also be running at 11:00 but on Thursday morning in room Crystal A.

Results

The following are the pictures and transcribed sticky notes from the results of the five groups working on building up practices and classifying them according to their own thoughts. I’d promised to post them so here they are. The first results of mapping our Participating in Retrospectives can be downloaded here.

Agile Estimation

Expert

• Lean/kanban SLA
• Estimating at correct level of granularity based on time horizon
• Understands limitations of estimation
• Motivate team to be enthusiastic about estimation
• Avoid dominance of senior person influencing estimates
• Trusting blink! reactions
• Adapt estimation method to tasks/group/…

Proficient

• Shopping basket exercise
• Uses scenarios to explore scope
• Consider different skill levels
• Use yesterday’s weather for hard to estimate items
• Recognises the wise crowd
• Use fist of five when consensus not happenning naturally
• Discuss risks as part of estimating

Competent

• Explores alternative strategies for solution
• Avoids overly precise estimates
• Identify dependencies
• Courage to be different
• Identify too complex
• Including all parts of done in tasking (like TDD and refactoring)
• Identify need for more information

Advanced Beginner

• Using fibonnaci numbers
• Everyone showing estimate at the same time
• Normalise team multiple estimates
• Creating similar sized stories
• Avoids star trek estimation

Novice

• Use consistent units
• Estimate goat.com (I’m guessing via Mike Cohn style)
• Splits up epics

Test Driven Development

Expert

• Find good metrics to measure effectiveness of tests
• Build patterns for testing legacy code
• The team takes collective ownership of the test, keeping them running

Proficient

• People understand/proficient w/the tools needed for TDD
• The team refactors their test
• BA’s participate in writing behavioural tests
• Use tests to design code
• Refactors tests -> treat as valuable assets
• Seeking out + enabling + effective tools for TDD and CI
• Pair programming
• The team paris when writing TDD code
• Revisit and rework tests as much as code
• Write test to fit requirements religiously *before* design
• Every team member demonstrates an appreciation for tests (no “I gotta – don’t wannah”)

Competent

• The team has CI set up for their project
• Openly discuss TDD w/group to bring others into fold
• Code passes test(s) without extra functionality
• Express intention through tests
• The team understands the importants of taking small steps
• Sell importance upward (e.g. done = coverage) not just demo’ed
• Treat broken tests as backlog and prioritise

Advanced Beginner

• The team is good at refactoring
• People understand the value TDD brings to the team
• Run often
• The team keeps the tests at a unit or class level (not functional tests)
• Confirming acceptance criteria before beginning

Novice

• Write test
• Run tests
• Refactor
• Make test pass
• Write test cases before you code
• No code is written before a failing test exists

Writing User Stories

Expert

• Feature injection: Value ‘pulls’ the story creation process

Proficient

• BA/Tester pairing on story creation
• Use acceptance tests to drive out lower level stories

Competent

• Create high level stories
• Create low level stories
• Breakdown high level to low level
• Using user personas/roles
• Consistent use of domain language
• Validate storeis with target persona
• Don’t ignore non functionals
• Test ideas
• Can be completed in a sprint

Advanced Beginner

• Evolving
• Good user roles/personas
• Pop why stack to get to tangible benefit
• Marketable features
• Not too detailed
• Acceptance criteria
• (Uses) INVEST

Novice

• Ask developers for size
• Ask customer for priority
• Use language of user
• Follow story format template with all clauses filled
• Create story when asked
• Stories from user perspective

Story Wall/Using Big Visible Charts

Expert

• Tell a story
• Create chart to change behaviour
• Recognising patterns

Proficient

• Simplify message
• Improving charts
• Showing blockages/impediments prominently
• Research alternative displays to better convey information
• Creating new spaces to place charts
• Making wall virtual for distributed teams
• Remove useless charts

Competent

• Suggest new changes – new items to track
• Track the effectiveness of your solutions
• Every team member updates their story when there are any changes
• Real time updates (automated)

Advanced Beginner

• Identify bottlenecks
• Placing charts in a visible area
• 1 person updates charts daily
• Prioritising

Novice

• Adding stories
• Follow colour convention/standards
• Knowhing which task to start next

Release Planning

Expert

• Team members produce visible release “parking lot”

Proficient

• Plan is used as a tool to inspect and adapt
• Stories with automatable acceptance criteria
• Stories with consistent pointing
• Setting expectaitons with the business around nature of overall *time* plan
• Team intuitively understands the right level granulartiy of discussion
• Plans account for firming sprints
• Team members able to speak of personas
• Using personas to help guide planning
• Having an explicity “change bucket” ~25%

Competent

• Have prioritised product backlog by business value/by the business owner
• Product roadmap
• Setting goals for the release
• Validating overall plan with the team
• Backlog items within consistent magnitude
• Stories that cross all the layers
• Identify atypical planning context – distributed – complex daomin
• Team estimates considered in prioritisation
• Understand team velocity
• Including the team in arriving at planning velocoty

Advanced Beginner

• Ability to assess relative size
• Ability to reach team agreements
• Stories with high variance in priority
• Value driven and/or high risk features are scheduled early in the release
• Plan is visible to all
• Stories with a consistent definition of done
• Recognise release scope will change
• Plan is published but revisited/used at sprint closing

Novice

• Track velocity but not adapting release plan accordingly
• Available product owner to discuss backlog
• Determining planning velocity
• Have prioritised product backlog
• Team produces release plan for Product Owner
• Stories without a consistent definition of done
• Stories based on infrastructure