Where Has XP Gone?
... and can we have it back?
Notes from the Open Space at XP Days 2009, London:
There doesn't seem to be much mention of XP this year at XP Days. This begs a few questions:
- Why are we not hearing about it?
- Are people still doing it?
- Is there something wrong with the way its evangelised?
XP not mentioned much. Lots of people seem to talk about "agile" - but it's only a broad, umbrella term for lots of different things.
"We couldn't implement all of scrum in our start-up" - pretty depressing. Where else are you going to find such a great opportunity to implement XP? Green field site, no established procedures or rules, need for minimalism/efficiency... so why aren't people adopting it?
- fear?
- don't know how to do the practices because you can't learn them from a book?...
Why aren't people doing it?#
- cherry-picking practices
- Scrum addresses a broader range of concerns (business, infrastructure people, project management) - but doesn't address core technical practices
- Scrum left XP practices out to make it possible to adopt in 2 days rather than 6 months of training
- Perception by XPers that Scrum trainers can seem very patronising - since XPers already have the overwhelming majority of the scrum practices embedded in XP.
- Perhaps Scrum Trainers meet lots of people that are totally new to agile - easy to assume that people don't know/haven't experienced agile development.
- Difficult to take being patronised by non-tech scrum trainers: - "Yes, big deal. We've been doing all that for ages - and a bunch of highly technical, rigorous things that are essential that you can't do."
- Misconception: "We're doing scrum so we don't need to (pair|TDD|refactor|...)" Minimal scrum requirements as a licence not to do some or all of the XP practices.
- philosophy behind XP hasn't spread with the practices
- resistance to certain practices e.g. pairing, TDD, collective code ownership, continuous integration, building end-to-end workable chunks, not layers at a time)
- discussion: not doing pair programming makes it difficult to have collective code ownership
- discussion: people adopted continuous integration tools but didn't use CI tools for actual integration - they just used it as a test runner.
- people want more documentation
- people misunderstanding XP ideas as "we don't need to write docs" rather than the "we're not going to carry unnecessary, copious documentation"
- exposing cost of documentation - it is part of the product and not a free thing
- who is the document for? - it must have an intended audience if there's to be any hope of usefulness
How do we explain the XP ideas?#
- encourage people to rediscover the XP ideas themselves
- use another name - "extreme" may frighten people. (Bankers may hear "extreme" and think "risky"/"flaky".)
- Discussion in the early years of XP about the name - Kent Beck: "If they're put off by the name, this isn't for them..." (paraphrasing...)
- Getting people to see the importance and benefit of interactivity
- Learning from interactive code - e.g. Smalltalk, Ruby, Python - just can't do this with long builds - too slow for interactive "listening to the code"
- supposed to be easier to try things out rather than to discuss them at length
- Difficulties of explaining EvolutionaryDesign
- perception of anxiety from some developers in the face of uncertainty & ambiguity
- they want to decide up front to resolve the uncertainty & ambiguity be resolved
- discussion: about speculative force-fitting patterns rather than "listening to the code"
- suggestion: maybe it's worth trying to explain evolutionary design with a concrete example
- consider different learning styles - textual/visual/...
- explaining YAGNI - developers wanting to gold-plate things
- need to make Scrum masters aware of the need for appropriate engineering practices - minimum scrum requirements not enough
- Jeff Sutherland's talk - says he hasn't seen any high-productivity scrum team that isn't doing all the XP practices.
What's missing#
- focussed too much on (technical) practices
- XP lead is only a technical lead - other issues need addressing e.g. business and infrastructure
- Scrum master has a wider remit - but how will non-technical scrum masters know that specific tech practices need fixing?
|
