I always get into conversations about extreme programming practices and how it can be adopted with Scrum and other Agile methodologies. But, I find that most people are not aware that it is a methodology by itself. People like Ron Jefferies, Kent Beck, and Ward Cunningham, have pioneered this methodology. The first eXtreme Programming project traces back to March 6, 1996. It has already been proven to be very successful at many companies of all different sizes and industries worldwide. Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future, this process delivers the software you need as you need it. XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.
I will first set the stage to what the values, roles, plan & manage, and design & development principles are. Then, I will tell you my personal experience from an Agile Coach perspective implementing eXtreme Programming as a methodology followed by my experience, recommendations, and conclusion.
Values
- Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.
- Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.
- Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.
- Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes whenever they happen.
- Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.
Roles
Tracker: Goes around and asks each Programmer how she’s doing, listens to the answer, takes action if things seem to be going off track. Actions include suggesting a CRC session, setting up a meeting with Customer, asking Coach or another Programmer to help.
Customer: Writes User Stories and specifies Functional Tests. Sets priorities, explains stories, views CRC sessions. Has authority to decide questions about the stories.
Programmer (Extreme Programmer): Estimates stories, defines Engineering Tasks from stories, estimates how long stories and tasks will take, implements stories and Unit Tests.
Tester: Implements and runs Functional Tests. Graphs results, makes sure people know when test results decline. (Note: Programmers do their own Unit Tests).
Coach: Can schedule meetings (e.g. Iteration Plan, Commitment Schedule), makes sure the meeting process is followed, records results of meeting for future reporting, passes to Tracker. Does not tell people what to do (Customer and Iteration Plan do that), when to be done (Commitment Schedule), or check to see how they’re doing (Tracker). Mentors team!
Some roles can be combined in the same individual. For example, the same person could have the Coach and Tracker role. Some roles probably should not be combined. Programmer-Tracker, Programmer-Tester, Customer-Programmer, Coach-Tracker are examples. Coach probably shouldn’t combine with anything except Tracker.
Plan & Manage
Release Plan: A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each iteration.
Iteration Plan: An iteration planning meeting happens in the beginning of each iteration to produce that iteration's plan of programming tasks. Each iteration is 1 week as best practice. User stories are chosen for this iteration by the customer from the release plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected. The customer selects user stories with estimates that total up to the project velocity from the last iteration.
Each iteration essentially should look like the illustration below:
Manage: Management should give the team a dedicated open work space, set a sustainable pace. The team should have a stand up meeting to start each day. The Project Velocity is measured at the end of each iteration and fix the XP practices when it breaks.
Design and Development
The team should strive for simplicity, use system metaphors to describe the implementation and CRC cards for design sessions. They create spike solutions to reduce risk and don’t add functionality early. The team refactors whenever and wherever possible and implement test driven development strategies (TDD), automated testing framework, pair programming, and continuous integration and deployment.
My Experience
For a client in Silicon Valley, we worked with the customer to first create the product vision and the prioritized program backlog by business value. Then we roped in representatives from the different agile development teams to provide initial input on the user stories. This lead to re-prioritization of epics and user stories based on dependencies, added technical stories (e.g. architecture), followed by the roadmap creation. The customer working with the team representatives were able to initially agree on dissemination of user stories to the respective team backlogs and initial release milestones. We then held a two day release planning event where each team discussed and groomed their stories in the backlog for the upcoming release. The XP teams used Class Responsibility Collaboration (CRC) cards to brainstorm initial design concepts, metaphors to clarify the acceptance criteria with the customer, and created spikes for proof of concepts/research. At the end of release planning, each team did a read out of the features they would be working on for the release and if there were any unknowns, risks, or missed dependencies. Then, they did the fist of five to confirm their commitment to the release based on their backlog. After all teams did the read out and were confident on their commitments, then the release moved to execution.
Each Release Planning event was followed by iteration 0 (1 week long). The team used this time to setup continuous integration and deployment servers, do more Class Responsibility Collaboration (CRC) cards, setup pair programming stations and automated unit testing(AUT) frameworks, define their Definition of Done (DoD), choose their agile methodology (e.g. eXtreme Programming), design their development iterations, setup tools for managing their work, and basically anything that was needed to get the team started with development and implementation.
eXtreme Programming worked very well for us. For example, continuous integration with automated tests reduced common issues found with merging of code. This ensured more success for deploying at the end of every week (iteration) to the staging server, which then allowed the customer to play with the build, and update and re-prioritize the backlog based on what they found.
The biggest advantage the customer liked about eXtreme Programming in this case was the flexibility to change the prioritization and stories within the Iteration. Scrum for the most is in-flexible on this front. By letting the customer have the flexibility greatly reduced their stress from planning the perfect iteration.
From the team’s perspective, the biggest advantage was the reduction of time for planning. Again, in Scrum, the planning meetings can go for an entire day if you are planning a four week iteration. But, since the iterations in Extreme Programming are much shorter and flexible, the planning is fairly quick – less than 45 minutes in this case.
Recommendations and Guidelines for XP Teams
- Team size should be 5 or less people. This is important because the smaller the team the less communication channels, and thus more focus on getting the work done.
- Iterations are one week long. Iterations are one week long because you want to constantly get feedback and interact with your customer. With a tightly coupled team, this is possible.
- The Planning Game is a meeting at the beginning of each iteration to prioritize the work and get technical estimates – meant to be quick and dirty meeting as the plan can change if needed. Since the iterations are one week long and priorities can change within the iteration, you don’t want to spend too much time planning your commitment.
- Look to release after every iteration if possible if your team is not apart of a group of teams tracking towards a common release. Like Scrum, you want every Sprint to be potential shippable code.
- The scope within each iteration is flexible as long as the work has not been started. You want to give your customer the most amount of flexibility within reason. So, planned work that has not been started in an iteration should be flexible to change in priority or scope. This may require a conversation with customer mid iteration.
- The team works in a strict priority order. Features to be developed are prioritized by the customer. Just like Scrum, we want to focus on business value (biggest bang for the buck) not scope and budget.
- XP incorporates engineering practices, particularly things like test-driven development, automated testing, pair programming, simple design, refactoring, and so on. eXtreme Programming is all about being efficient and effective. Automation is key in achieving this. The more you can automate, without creating extra overhead, will improve the overall quality and make the team more efficient and effective in meeting their iteration commitments.
- Have Daily 15 minute standups. Like Scrum, it’s the only time where tam can formally sync up to discuss their progress. A good stand up is not a status meeting but more a conversation about the progress made towards the iteration commitments.
- Avoid having more than 40 hour work weeks. Statistics show that beyond insane number of hours is counterproductive as developers and QA alike will start to make mistakes and create more work.
- As stories get completed, show your work to the customer to get them accepted and committed to the official code base. Just like Scrum, its all about customer satisfaction. The sooner they can see your progress, the sooner they can give feedback.
- Have a Retrospective with your team at least once every three iterations. There will always be opportunities to improve. At the same time, you don’t want your teams to buried with meetings since the iterations are very short. So, keeping on every three weeks will not suffocate your team and they will see the value in doing a Retrospective.
Conclusion
Remember that Extreme Programming is an agile software-development methodology. XP helps you remain light on your feet by avoiding unnecessary baggage and by incorporating feedback continuously. Changing requirements are an expected and acceptable risk, because the customer sees the system being developed in real-time. Mistakes are immediately visible and are corrected while the feature’s implementation is fresh and pliable, much like a potter reworks clay.
Programmers work and rework the code in eXtreme Programming projects. The customer sees a system grow from layer upon layer of detail. The software is only as effective as the details it embodies. Details do matter, and eXtreme Programming reflect back to the customer in the only way that matters: working code.
Below is a holistic summary of eXtreme Programming by Ron Jefferies:
About the Author
Dr. Raman has over a decade of project management, agile transformation and implementation, coaching, and training experience. Some of his clients have included Nike, Intel, PayPal, Millennial Media, AOL, Bristol Myers Squibb, Biogen Idec, Center for Medicare and Medicaid Services, L'Oreal, Galderma, Chimes, Johns Hopkins, RWD, just to name a few. Dr. Raman has four academic degrees, which includes two undergraduate degrees in Biomedical Science Research and Laboratory Science and two graduate degrees in Information Technology from University of Maryland, Towson University, and George Mason University respectively. Dr. Raman is well versed in several methodologies/frameworks for managing projects like Scrum, Waterfall, V-model, Kanban, SAFe, etc.
