From SPA Wiki

Jump to: navigation, search

Please do not edit this page. If you want to comment on or discuss the session please use RealWorldXpDiscussion. Cheers!


Outputs from OT2001 session:

Extreme Programming in the Real World

Stephen Hutchinson and Matt Stephenson

Thanks to everyone who attended the session at OT2001 and participated in such an enthusiastic manner. Thanks also to the folks at Royal & Sunalliance for helping us prepare for the session by taking part in the practice sessions.

Apologies to anyone who left me their email address but has not been notified by me about this page... I could not make out all of the addresses and had to guess a bit!

The output from the practice and real sessions is included here.

Please do not edit this page. If you want to comment on or discuss the session please use RealWorldXpDiscussion. Cheers!

Objective of Session

To get the participants to consider the obstacles and challenges that may be encountered when introducing Extreme Programming into a large organisation.

Anti-objective of Session

We did not discuss the vices or virtues of Extreme Programming. We asked that anyone attending the session worked from the basis of us already having made a decision to use XP on this (imaginary) project, rather than consider whether we should use it or not.

There are plenty of other people who will happily have a debate about whether XP is any good or not... We already believe that it is!

Session Format

The main body of the session took the form of two brainstorming sessions followed by group presentations.

The first brainstorm was to consider (in groups) the problems that are likely to be encountered in introducing the XP Method into a large organisation. We gave the participants a scenario that described the imaginary company under consideration, to help trigger the discussion.

We then went around the room asking each group to give us the problems. Stephen put them onto post-it notes and stuck them on a board. When all of the groups had given us all of their problems, each group selected a couple from the board.

The groups then used these problems to brainstorm solutions. At the end of the brainstorm, the groups prepared single-page flipchart presentations, which they then presented. A discussion of each followed...

The Presentations and Discussions


Problem: How to estimate accurately for a new way of working?


Process related

  • Make the processes visible to all concerned.
  • Question and improve estimates over time with experience.
  • Reward good estimates.

Learning related

  • (Small) Practice Projects.
  • Training.
  • Relate to everyday life (find day to day comparisons for the work and use those to estimate.
  • Use pairs to estimate the work.
  • Get "Old Hands" involved.

The discussion revolved around the fact that (as with any new way of working) it is a good idea to try it out on smaller projects. There is less risk to a company and it is less daunting for the developers involved who are being asked to work differently.

Velocity related

  • Collect metrics
  • Use old information (from previous iterations)

This may seem like common sense, but the number of people who do not seem to learn from their previous efforts is frightening. Using actuals to compare alongside of previous estimates is an excellent way of judging your effectiveness at estimating.

Problem: Integration with legacy code that has no test suite.


  • Isolate your new code and treat the legacy stuff as a black box.
  • Write tests for the new code.
  • Ideally write tests for the legacy code, maybe in parallel to the new development.

Ideally, we would write tests for the legacy code, but unfortunately in the real world this is not going to happen. In our real project we made it a rule that if we needed to modify any existing code then we would write tests to ensure that we had not broken anything, but the task of retrospectively writing tests for a huge legacy system is just too onerous for most Programme budgets!

Problem: Distributed Team (Cross Site Working)


  • Reorganise the teams into the same location.
  • Divide the work up so that separate parts can be worked on at different locations.
  • Use technology to achieve remote access (Netmeeting, Phone, etc).
  • A main strategic team does the 'hard stuff' with satellite teams doing smaller discrete pieces of work.

This is potentially a difficult one. The whole cross site working issue can be very emotive, as people feel as though they have to work away from home to get involved in the exciting work. This is probably why the XP method advocates teams of not much more than 15 - 20 people. Interestingly, I spoke to someone at the conference who said they were very successfully running XP with 24 full time developers. They were all on one site though!

Problem: Is the customer really available?


  • Nominated representative of the customer to arbitrate, act as representative of the stakeholders and to champion the requirements.
  • "Paired Customers"

This is often seen as the single most difficult area to get right with XP in a large company. Typically there are so many business areas that need to input to a project that a single customer simply doesn't exist (never mind be available!). Beyond that, once a number of people have been identified who have a vested interest in the system being developed, they may each have their own agenda as to what the system should do. This is where a single "Customer Proxy" becomes invaluable. The Proxy insulates the development team against any customer conflicts and presents a single, consistent message to the developers, so that they can focus on what the need to do, i.e. develop software.

Problem: Policing the Standards


  • Automatic code checks / metrics (use tools?)
  • Peer Pressure should not be underestimated!
  • Have a "swear box" for poor code offenders.
  • Rogues Gallery (for poor code).
  • Hall of Fame (for good code).

Extreme Programming by definition of its techniques gives better automatic policing of standards, but some of the items listed here can help. The last three in the list should be taken as a bit of fun, but can still help to get developers into the mindset of writing good standards of code.

Problem: Workspace and the environment


  • Build a team work area that is devoid of distractions (email, telephones, etc), that developers can go to when they just need to write code.
  • Get convex desks so that paired developers are facing towards each other.
  • Get See-Saw Seats!

The shape of the desks is something that very few people ever think about, but it can have a bearing on the effectiveness of the team. If you are sitting in pairs at a concave desk, the developers will be facing away from each other. At a convex desk they will be facing towards each other (and the screen). The See-Saw seat was a joke! The idea being that you could only sit at the desk if you were in a pair. Stephen and I decided that it wouldn't help us to pair program better because I am about 4 stone heavier than him!

Problem: Lack of experience in development team


  • Get XP consultants in to mentor permanent staff.
  • Make sure the consultants meet everyone involved.
  • Send teams on training courses.

Extreme Programming lends itself very well to getting consultants in for a short period of time. If you do this, you have to make sure that the consultants are always pairing with a permanent member of staff, so that the knowledge transfer is always to your permies. The consultants can go out of the door as soon as the team can stand on its own two feet.

Problem: Large Teams / people reluctant to change / not enough food!


  • Don't involve everyone.
  • Ask for volunteers so that those who are keen get first refusal on being involved.
  • Work in the canteen.


Problem: Customer is not on-site / More than one customer


  • Chunk project to have only one customer per chunk
  • Have a focal person on-site with rapid access to the customers [focal person must have the authority to resolve conflicts between customer groups]
  • Move the developers to be with the customers, or vice versa
  • Plan to have people available 100% [if you have to make do with on offsite customer you still need to have 100% availability]
  • Known role for all, particularly the customer side. (?)

Problem: Selling XP


  • Use reference site(s).
  • Prove through statistics and metrics
  • Explain the benefits to business of quick incremental delivery
  • Pre-empt negatives perceptions of XP
  • Explain the impact XP on people's roles and responsibilities (or define them up front) [answer the question 'What does it mean for me?']
  • Be pragmatic - introduce techniques gradually/incrementaly [but could get left with a horrible hybrid]
  • Hide the anoracks [there is a perception that the people promoting XP are code warriors]

Problem: Part of the project is not using XP (i.e. XP on the front-end but awkward back-enders)


  • Multi-disciplined programmers [in one big team with people doing both front and back-end coding in an XP way]
  • Single disciplined, all XP (sack 'em this was a joke!!) [i.e. get rid of people who don't want to do XP]
  • Constrain interfaces [ i.e. design interfaces between back and front-end up-front (which is not XP), then work (in an XP way) with the defined interface as an external constraint to the XP coders.]
  • Relax non-XP areas [persuade non-XP areas to be more responsive, e.g. to more frequent design changes, so as not to impede XP-style working by others]

[XP is seen as OK for O-O but not for COBOL because the mainframe COBOL development environment cannot be easily adapted to support automated testing or code refactoring. However, COBOL developers do not believe that this is the case.]

Problem: Resistance Among Programmers To Pair Programming

What's Good About It?

  • It's enjoyable
  • It allows you to learn new techniques, systems or languages quickly
  • Collective code ownership means you don't get lumbered with being the expert on a particular piece of the system.

Problem: Buy in from business

How To Get It?

  • Provide case studies of successful XP projects
  • Sell them on being involved throughout the life of the project
  • XP projects are reactive to change so business have control of direction
  • Business get early and continuous delivery delivering business benefit
  • Business can pull out early and still have achieved benefit
  • XP's emphasis on testing, especially regression testing, means business get high quality deliverables.


Problem: Lack of Traditional Dcoumentation Leading to Confusion


New People

  • Pair Programming


  • Good coding Standards
  • Self documanting code

Sponsors want something tangible

  • On-site customer
  • High level documentation (e.g. Use Cases)

Problem: Lack of Undersatnding of XP


  • Get experts (consultants, or train in-house)
  • Pair experts with less experienced (pair programming)
  • Do workshop sessions like this
  • Use reference material

Problem: Loners don't want to Pair Program


  • Sell XP benefits
  • Link PP to personal development milestones
  • Put them on non-XP parts of the project
  • Sack 'em [this joke's wearing a bit thin]

Problem: Cross Site Working


  • Travel
  • Daily rotation
  • Use of technology

[At RSA we've tried pair programming over the phone using ILDM to see the other machine. It's OK for 10 minutes to sort a specific problem, but doesn't support real pair programming.]

Problem: Difficulty of Planning Something You've Never Done Before


  • Visit an XP site
  • Recruit a Guru
  • Trailblaze using a small project
  • Use XP as an excuse for late delivery [I think this is supposed to be a joke, at least I hope it is.]
  • Timebox

Problem: Personal Development Milestones Linked to Deliverables in Existing Methodology


  • Educate performance review personell
  • Re-define development targets to encompass XP tasks
  • Re-map job profile to cater for XP
  • Have a seperate competency profile for XP developers

Problem: Personality Clashes Impair Pair Programming


  • Team building excercises (e.g. alcohol based)
  • Pair friends together (initially)
  • Deodorant and mints
  • rotate pairs on a regular basis

Problem: Integration with Mainframe Systems and Development Style


  • Define SLA's for support teams, DBA's, etc..
  • Use wrappers to introduce OO developmernt to mainframe environment
  • Multiskilling to allow developers to work on both front-end and back-end
  • Involve back-end developers in analysis and design (encourage them to work with the business)
  • Pair front-end person with and back-end person.

Problem: Lack of Buy-in to XP


Business Management

  • Take them to the pub
  • Visit other XP sites
  • Identify differences in approach
  • Sell Benefits:
  • Incremental delivery
  • Earlier delivery
  • Better understanding of requirements
  • Better quality
  • Closer relationship with development team

IS Management

  • Spread of knowledge
  • Rounded, knowledgable flexible team
  • Closer control of speed/ incremental delivery
  • Demonstrates that IS is Change-Oriented and looking to improve
  • Improved quality, e.g. less maintenance and reduced error rate.

Development Team

  • Learning new skills
  • Acess to wider experience in team
  • rewarding becasue you see results more quickly
  • More and wider opportunities
  • Clear links between personal development and project planning
  • More personal responsibility

Business Team

  • Greater influance on deliverables - no surprises
  • Closer working relationships
  • Better understanding of what's delivered
  • More involved with decision making
  • Increased understanding of IS


Feel Good Factor

  • No Isolation
  • Lots of Support
  • Less battling