QCon 2007 - What I learnt about process

A post in a series that summarises what I learnt at QCon 2007.

This post focuses on development processes.

For a mind map version, click here

Inspiration came from the following excellent sessions:

• Agile Leadership Tutorial - Diana Larsen
• Usage-Centered Design Tutorial - Larry Constantine
• Modifiability - Martin Fowler
• Operational Manageability - Dan Prichett, ebay Technical Fellow
• User stories and release planning - Rachel Davies
• Test driven development - Steve Freeman
• Agile PM: The Googley Way - Jeff Sutherland
• The Yawning Crevasse of Doom - Martin Fowler & Dan North

Implementing change

• Have retrospective to establish SWOT's to address
• Prioritise cultural changes each iteration / project
• Do simple things well, then focus on clever/hard things

Agree on principles as early as possible, e.g.

• design
• unit testing

Key success ingredients are

• Encapsulation
• Classes should "keep secrets"
• Tell, don't ask
• Prefer private over public
• Leads to more readble code
• Keep the domain model clean of non-domain code/entities (e.g. UI, DB)

• Do the simplest thing that will work (not the same as doing the easiest thing)
• Making code test driven: lowers cost of change
• Test for required behaviour not implementation
• Refactoring is the second leg of TDD (first being testing)
• Growing better developers is best investment that can be made in a team
  

Use risk maps

Bridges and ferries

• Bridges:
• Promote activities that build bridges between developers and the business
• Encourage activities that have feedback
• Minimise "distance between" developers and the business
• Consider co-locating developers and end-users
• Don't build "ferries", that distance or separate developers from the business

User stories

Less is more

• Tool for collaborative planning, i.e. purpose is to encourage communication between stakeholders
• Facilitates collabrative dynamics, via the 3 C's:
• Card
• Conversation
• Confirmation
• Can exist alongside more formal and comprehensive documents
• Aim is to write less sooner, to minimise cost of change
• Sometimes prior analysis should be done to understand problem domain, before moving onto stories

Why's and how's of a story

• System "commisioner" provides "why's"
• End users can provide "how's"

Format

• As a I need so that .
• e.g. As a book buyer I want to find a book by entering the ISBN number, so I can locate it quickly
• OR simply state user goal
  

Scrum

Minimise "work in progress" - "Done" means system and acceptance tests pass

Minimal process

• Artifacts
• Product backlog
• Spring backlog
• Burndown chart
• Meetings
• Sprint planning
• Daily meeting
• Sprint review
• People
• Product owner
• Scrum master
• Team

Builds

Include rollout script for use by Operations.