ot2004

How to fail at XP

March 30, 2004 10:14:15.267

This one comes from Keith Braithwaite of WDS Global and Steve Freeman of ThoughtWorks UK.

We are going to

  • Seed some stories
  • Break into groups and share stories
  • Each group to discuss their stories and extract 3 anti-patterns
  • Each group will present their anti-patterns
  • Pick top 3, discuss

Dissenters should be tolerated as long as possible, but no longer:

  • Some people take time to convert, give them time
  • One "Professional Skeptic" can bring everything to a halt
  • Special treatment for the squeaky wheel can cause resentment amongst the rest - possible on a non-XP team, virtually impossible on one

Proxy customers must remember their place

  • Very few people saying they are doing XP are - most have a proxy customer, not a real one (Product Manager?)
    • Knowing the solution domain well does not imply knowing the business domain well
    • Having a proxy available when the real customer is not available can help
      • Can blow up if they forget that they are not, in fact, the customer - end product will then answer the wrong question(s)

Must be prepared to pay the cost of fixing the mess

  • Decent engineering is expensive to retro-fit
  • Customers will not see any progress from this - they will start to think you are "wasting time". Unclear how to do this well. Only real solution is constant checking, or deal with catostrophes as they occur
  • Probably won't like the extra discipline... they don't feel the pain

You need to be doing other good stuff beyond XP. There's not a lot to XP - it's light. What's not part of XP that is necessary?

  • Small design up front doesn't hurt, and will definitely help. Not BDUF....
  • Many people do not absorb the rigor required - especially if they have only "read the books" and not discussed it
  • Version control - surprising number of teams don't
  • Test/Code/Refactor is necessary but not sufficient. Have to have skill, it's not a silver bullet. There are process/interpersonal issues as well. You can run down refactoring rabbit holes, for instance....

Don't frighten the customer

  • Most orgs adopting XP have other, non-XP projects. Don't be a full-time evangelist
  • Over emphasizing it can be dangerous, and get you labelled as a "religious fanatic"

Stand up to the Customer

  • Customers drive the project
    • Doesn't mean they are always right or know what they always want
    • Developers can be frightened of customer, and not question them, even when they "know" they are wrong
    • This can end up delivering the wrong solution to the wrong problem

Step up to the customer role

  • The "Real" customer is unavailable
    • lack of feedback and direction increases risk - recall the "remember your place" in the proxy customer role
    • Someone in that role is better than no one...

The exercise - come up with a few anti-patterns and proposed solutions. We came up with:

Create a Customer

  • There is no customer
  • Without a customer, rat holes abound
  • Some projects - such as vendor products - lack a single definable customer

Get a new Bo peep

  • Need a working team
  • Coach leaves
  • Lost Sheep after coach leaves

Hire experienced people

  • The blind leading the blind
  • They fall off the clock
  • There's no substitute for an experienced coach

Other examples

Timely shutdown

  • No customer - shut down the project (don't let marketing run wild
  • Seeing the Forest and the trees - Lots of apparent chaos - step back, find the ball
  • Right Rewards - Align incentives and development goals with reality and actual business goals

Personal Space

  • 24 hour pair programming
  • Not accomodating the individual
  • Cabin fever - learning needs

Single Voice

  • You have multiple customers
  • You cannot serve two masters

Escape from refactoring

  • Refactoring paralysis
  • Stalled/No progress
  • "The perfect is the enemy of the good enough"

Quarantine

  • Small XP team in large company experiencing growth
  • XP Team absorbed back into "mainstream" - XP practices lost
  • Protect the team, keep it separate

Others I didn't quite get down - "Stealth XP" and "Explicit XP"

So we have a vote to determine the top three:

  • Timely shutdown
  • Personal Space
  • See forest and trees

The voting results came back differently than at the Benelux conference - they all came back with issues surrounding customer relations, whereas we came back with technologist/team issues. Likely because this group is a technologist, but not necessarily doing XP. The Benelux conference was an explicitly XP Conference.

Comments

Great Notes

[Ryan Lowe] March 31, 2004 11:18:54.517

These are some great notes. :) Lots of good points. I wonder, if you pay to go to a conference (not sure if you did), do they care if you blog the content? Or do the presenters see it as a "leak" and a loss of potential income? I guess nothing can replace actually interacting at the conference ...

Re: How to fail at XP

[James Robertson] March 31, 2004 13:53:30.898

Comment on How to fail at XP by James Robertson

I paid to attend - and actually, the organizers are likely going to make sure that all sessions get blogged next year :)

Untitled

[Ewan Milne] April 1, 2004 10:26:13.487

The Ot conference culture is very open - the site hosts a wiki (www.ot2004.org/cgi-bin/wiki.pl), on which both speakers and delegates are encouraged to freely share the outputs of sessions, experiences, etc....