Monday, 30 April 2007

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 QCon 2007 Process Notes

Inspiration came from the following excellent sessions:

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

risk map

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"


  • 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


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


Include rollout script for use by Operations.

No comments: