We Are Not Doing Xp

I wrote this after being told that were were not going to PairProgram, or write AutomatedAcceptanceTests on the project.

It has become apparent to me this week that we are not "doing ExtremeProgramming" on this Project. I want to bring this to your attention now because I don't want to have blame directed towards the XP process when we do not deliver everything that is expected on the imposed delivery date. I fear that XP will be called a failure when in reality, XP was not being practiced. To be fair to the process, all the practices must be followed to claim to be a true XP Project. Here is a list of the XP Practices along with how we are, or are not, using these practices and how they are affecting the project. This is not just from my mouth, but also based on feedback from others on the team.

1) Whole team (OnsiteCustomer) - The lack of involvement from our customer and adamant resistance to the XP process has made this practice non-existent. Customer involvement is not just an XP Practice but necessary on any development project. Without customer involvement many conversations take place and decisions (guesses) are made without the customer's input. Also, we don't have the entire development team involved in discussions of desired and required project features, nor project status meetings. Unfortunately there is still a great deal of distrust between the customers and the developers. One of the good things that we do is to have all of the project developers in one area.

2) PlanningGame (ReleasePlanning and IterationPlanning) - A Release plan was finally completed several weeks ago. Unfortunately, the results were not amiable to the customer and the XP process was blamed. As a result, we reduced the use of the core practices in an attempt to speed up. Our iteration planning meeting has turned into a demo session for our end customer and they are not involved in the story planning (they leave the conference call when we start the storyboarding). We are not paying attention to our previous estimates (YesterdaysWeather) and consistently take on more than we can complete. Each week we carry over unfinished stories without re-estimating and add them to a list of debt that must be reconciled before weeks end.

3) SmallReleases - For the most part our releases are small and our progress is very visible. I believe there was a bit of overhead in getting a release to the customer after each feature instead of each iteration. However, that has been relieved by the implementation of an automated build.

4) Automated AcceptanceTests - Even though the customer is writing acceptance tests, we are not automating acceptance tests. This has caused developers to begin implementing features without looking at the written acceptance test. The task of running the manual Acceptance Test falls into the hands of the QA team. This is putting us in a Code-Test-Fix Cycle (i.e. long bug list).

5) TestFirst Development - Since the removal of pair programming, the discipline of test first has been left to the discretion of the developer. Many objects are being created without tests, and tests are being removed by commenting them out (to get the system to compile) but are not being re-implemented. This is really being left to the developers' individual style and comfort level with test-first. Some developers want to do "test last" but we are seeing that the tests don't get written later due to time pressures.

6) ReFactoring - With the pressure of a deadline, our under-estimation, and no pair programming, refactoring is rarely occurring.

7) SimpleDesign - The system design started out overly complex and it is becoming more complex. Without refactoring, this will only get worse. It also seems that we are overly complicating tasks and not doing the SimplestThingThatCouldPossiblyWork.

8) PairProgramming - This is only occurring on "complex" tasks. We are starting to see "silos of knowledge" form in the group and some aspects of the code being handled by only one individual. Communication among developers is decreasing since each developer is working on their own. The lack of pairing affects TestFirst, ReFactoring, SimpleDesign, ContinuousIntegration, CodingStandards, and CollectiveCodeOwnership. This one practice directly affects half of the practices in the XP Process.

9) ContinuousIntegration - Integration is becoming more difficult. We should only check in a code change when it compiles and all tests pass. Then we should get the latest version and rebuild and test again. This insures that the version in Source Safe will build and run and that we did not break anything with our change. Too often we are committing changes that don't compile or break a test. This costs other developers time trying to get the build to work and moves the focus from the task at hand. This is more prominent now that developers are not pairing and are working on their own.

10) CodingStandards - Our Naming Standards are not being enforced and each developer is writing code in their own style. In many places inconsistencies are emerging. This makes the code unfamiliar and directly affects Collective Code Ownership.

11) CollectiveCodeOwnership - Our TruckFactor has effectively been reduced to 1. If we lose one member of this team, we will be delayed. This is a direct consequence of not programming in pairs.

12) SystemMetaphor - A General Reservation System was our original metaphor, however our system has evolved to be a bit more than just reservations. I don't think this is a big issue, it is just a tool to simplify communication of a complex system.

13) SustainablePace - Our velocity metrics are a telling tale. We have yet to meet an iteration estimate. We are consistently falling short of our mark. This tells us that we are not getting any better at estimating our stories. It also tells us that we are not going to deliver on time. Sustainable pace is based on a FortyHourWeek. Since our estimates are not accurate, even if we increase the hours, we may still fall short. Also, at our current pace, it is evident that the stress level is greatly increased.

In short, we are really only partially practicing the planning game and doing some test-first, some test-last and somethings are not tested at all.

The resistance to the process has become so great such that the practices are not being followed.

This is contributing directly to the scope creep we are seeing (features are stuffed into stories that are not part of our original estimate) and why our estimates are consistently wrong.

To the original author: I hope you don't mind some of the edits Wiki made. You can get the original from the RecentEditHistory, or if that has expired, I've saved a copy for safe keeping for a short while. -- TheEditor, Mar 7, 2003

This is a great addition to Wiki. But a caution: In many cases, it is risky to use the 'tone' that this piece uses, especially in written form. Most people have an instinctive aversion to dissenting voices, especially if they are your 'superior'. "Who are you to tell me how to do my job?" Now, if you are very familiar with the audience, and on friendly terms, and comfortable speaking frankly with one another, this tone may be okay, and may even work great as a 'wake up call'. But even if this is true, I (personally) would still advise against this. In my opinion (and from personal experience!), there is too much opportunity for this to be misinterpreted as an accusatory letter, especially if it is in written form (which loses the context of tone-of-voice, body language, etc.). If the audience is your boss and it is taken the wrong way, it could easily hurt your career. Discussing it face to face and in a neutral tone might be a safer alternative. On the other hand, you might be planning on finding new employment anyway! For some great advice on how to approach this issue successfully, try the book HowToWinFriendsAndInfluencePeople.

CategoryExtremeProgramming