Lifecycle of an XP Project 🙃

As one of the last blog posts on extreme programming, there is so much to unpack about the underlying philosophies behind this methodology. I stand by my previous statement, about how extreme programming strikes me as sensible and human-focused. (Did anyone else find the appendix extremely interesting?).

To focus less on its controversy and criticism, which is quite abundant on its Wikipedia page, I wanted to recap Kent Beck’s outline of the various stages comprising an XP project. It’s a useful guideline (equipped with emojis) for future projects and will provide you with a sense of your project’s current stage.

1. Exploration (Few Weeks — Few Months)

Overview:

• The pre-production stage should not be a “comfortable” or “natural” state. After all, you’re not making money!
• To go into production, you have to have enough confidence in your tools and the ability to run the code everyday
• Team members need to trust each other 👯
• Team members need to have or must learn the skills needed 🔨

Activity:

• Spend a week or two building a system like what will be eventually built, but in 3–4 different ways. Pairs can try the system in different ways and compare.
• Experiment with the performance limits of a technology
• Experiment with architectural ideas
• Customer is writing stories (and expect to give feedback!)

You’re know when you’re done when the customer is confident there are enough stories to make a good first release and developers are confident they can’t estimate any better.

2. Planning (2–6 Months)

The purpose of the planning phase is for the customers and programmers to confidently agree on a date by which the smallest, most valuable set of stories will be done.

3. Iterations Leading Up to First Release

• Schedule should be broken into 1 to 4 week iterations (customer/client will produce a set of functional test cases)
• First few stories for the first iteration will require building a skeletal form of the system
• Customer gets to decide stories for subsequent iterations
• Detect deviations from the plan and add/remove stories or change the scope

4. Production

• Conduct one-week iterations
• Do daily standups
• Create a process for certifying the software is ready to go into production
• Apply parallel testing
• Throw a party when the software goes into production 🎉

5. Maintenance (Forever, Almost)

This should be seen as the “normal” state of an XP project, where you’re working to support new functionality, keep the system running, and handle any incoming/outgoing staff transition.

• Major refactoring, new technology, migrate to newer versions, experiment with architectural ideas, new stories altogether
• Requires more caution given live data and production interruption
• Rotate programmers through various positions to deal with production
• With new team members, 2 to 3 iterations should be dedicated to asking questions, acting as a pairing partner, and reading tests and code before allowing them to take responsibility for a few programming tasks

6. Death

• Customer is happy and does not plan on any new feature 😀
• System is not delivering; customer needs features and they can’t be added economically 😫
• Should be handled with transparency, as in the current team should be aware of the economics of the situation
• End with a fond farewell. Throw a party for everyone who has been involved in the project 🎉