This post examines the agile method called Extreme Programming (XP). XP is uniquely designed to streamline the software development process – but it can be leveraged and used in other pursuits!
This post looks at the XP life cycle, core values, team roles, and core practices, then turns to application for strategy and project management.
Is the Extreme Programming Life Cycle Unique?
On the surface the Extreme Programming (XP) life cycle appears to be a unique approach to managing software development projects. However, that’s really only partially true.
Much of what makes up XP was derived from other approaches. For example, much about XP can be mapped right back to the 4 values and 12 principles of the agile manifesto.
For example, looking at just the 4 values:
- Individuals and interactions over processes and tools – XP emphasizes communication and collaboration among all programmers and testers.
- Working software over comprehensive documentation – XP aims to produce output – Minimum Viable Product (MVP) – and barely mentions documentation.
- Customer collaboration over contract negotiation – Requirements and work product specifications are derived through a fluid but well-defined relationship between the team and the customer. It is anchored by deliverables and feedback, not formal agreements.
- Responding to change over following a plan – That’s the ‘fluid’ part – embracing change and adjustments.
Let’s explore the specific values of XP, then move on to key roles and core practices before looking at implications for strategy and project management.
Extreme Programming Core Values
The following are the documented and commonly accepted XP core values, with a short explanation:
- Simplicity – It comes down to Minimum Viable Product (MVP). What is the smallest bit of functionality that we know is required, can develop well, and deliver fully? Assumptions are eliminated. Certainty is emphasized. Clarity and elimination of waste are practiced with no exceptions.
- Communication – XP emphasizes team, and that means transparency and sharing. In XP, that means face to face, in the same room. Knowledge transfer is a requirement, and it involves everyone. Visual communication – ie. white boarding – is as important as verbal.
- Feedback – A cornerstone value is to give the customer what the customer wants. Feedback enables that. It also enables the team to learn about how it can function better and continuously improve.
- Courage – Courage is required to confront issues. There may be an immediate setback to productivity, letting go of ideas that once had promise, and fortitude to push in a different direction.
- Respect – There is no effective communication – or simplicity, feedback, or courage – with mutual respect across the team. Care needs to be taken to resolve issues immediately as they arise to build and maintain a respectful team.
These are all admirable values and all point back to something in the Agile Manifesto.
Let’s now turn to the key roles defined for XP.
Extreme Programming Team Roles
While roles are similar across different approaches to agile, they do have their own XP-specific formal names and definitions.
Here are the ‘formal’ team roles in XP:
- Coach – ‘Coach’ is similar to, and almost interchangeable with, the role of a scrum master. The emphasis is on facilitation to help the team to be self-managing.
- Customer – Similar to the product owner in scrum, the ‘Customer’ role is responsible for the requirements and priorities. It is the pipeline between the users and stakeholders, who provide feedback on work. This role also makes business decisions for the team.
- Programmers – These team members develop the functionality.
- Testers – These team members test the functionality.
It seems that the programmers and testers can be one and the same; individuals can switch back and forth between the roles. That would seem to align with the core practices in the next section.
The primary observation here is that the team roles in XP have unique names, but they are very similar to the roles in scrum.
Extreme Programming Core Practices
The following are brief explanations for many of the core practices that are part of XP:
High level:
- Whole team – Team members within roles are interchangeable, regardless of what they are working on. There is no specialization, and knowledge is shared across the team. It may seem inefficient at times, but it ensures that everyone is ‘in the know’ and that no one is ever idle.
- Planning games – These ‘games’ are ceremonial meetings for release planning and iteration or sprint planning. Release planning involves everything required to get the functionality into the users’ hands. Iteration or sprint planning involves committing to complete specific functionality, development and test, within a short, usually 2 week, period.
- Small releases – Frequent deliverables provide the opportunity for user feedback as well as a chance to build credibility by creating value.
- Customer tests – As a different twist on requirements, customers provide test scenarios or criteria they will use to determine if the functionality is acceptable.
Mid-level:
- Collective code ownership – Consistent with the ‘whole team’ core practice, any programmer can work on the code. This increases the likelihood that errors in the code will be caught and that it will emerge ‘clean’. It also enables cross training and cross pollination, strengthening the team and making all programmers generalists and interchangeable.
- Code standards – A consistent approach to coding needs to be taken. This avoids the possibility of programmers bring unique but unproductive approaches to the code.
- Sustainable pace – It is a goal to set a work pace that can be maintained over time. Shorter term deliverables and agreement on work package commitments helps keep the work within limits.
- Metaphor – This allows for simple explanations describing functionality. The goal is to create a shared vision, vocabulary, and understanding across the team.
- Continuous integration – This means that every time a programmer checks in code to the repository, automated integration testing occurs to reveal errors rapidly.
Inner level:
- Test-driven development – As with customer tests, testers write the tests before development occurs. This helps to clarify the requirements and spells out what is required in clear terms.
- Refactoring – Consistent with collective code ownership, programmers value and put effort into ‘cleaning up’ the code.Refactoring removes duplicated code, maintaining exactly the existing functionality, eliminating unneeded connections, and creating a clean ‘atomic’ coding structure.
- Simple design – Consistent with the concept of Minimum Viable Product (MVP), XP aspires to build the simplest chunk of functionality possible.
- Pair programming – Aligned with the whole team and collective code ownership practices, code is written at once by two developers. Typically, one is writing the code while the other is observing and providing input. The two frequently change roles.
There are 13 core XP practices. That’s a lot to swallow! The question is how might this be beneficially implemented from both a strategy and implementation perspective?
Extreme Programming and Strategy
What are the key strategic levers in the business or organization? This is not just a broad, high level question, but one to apply pretty far down in the organization. XP is a ‘low level’, deep implementation approach. You probably need to go deep to earn the benefits.
—————————————-
I recommend these strategy resources (paid link):
—————————————-
The Internet of Things (IoT) is the evolution of physical products into products that contain an important value added information component. Moving in an IoT-focused direction is a strategic choice and decision. Here are some frameworks that can help in formulating or implementing such a strategy:
- Plan-Do-Check-Act (PDCA) – This approach aligns well with the XP approach of MVP, testing plans, continuous integration testing, and frequent releases.
- Low code, no code – This growing, evolving approach can enhance or expand the scope of a product’s effectiveness.
- Logic tree diagrams – Diagramming at any level can help you to think through the options and make the best choice.
- Prioritization – Take a strategic approach to prioritization.
- BCG growth share matrix – Re position toward growth opportunities by leveraging XP.
- Experience curve – Build experience with your own version of XP to build competitive advantage.
XP can enhance the viability of any strategy based on information technology.
Extreme Programming and Project Management
Be agile about applying XP values and practices. Think Minimum Viable Product (MVP) when it comes to XP! What is the smallest chunk of XP that we are confident could help us on the project?
—————————————-
I recommend these PM templates (paid link):
—————————————-
There are 13 core practices for XP! That does not mean you need to consciously implement something related to all 13 at one time! Pick out one or a few – such:
- Whole team – Erring on the side of cross training, cross pollination, and transparently sharing seems like a good idea. While specialization also has its benefits, it can conflict with the whole team concept. Try it out in some area.
- Collective code ownership – Bringing the whole team approach down to the code level, see what happens when everyone owns the code. This may be a cultural adjustment.
- Test-driven development – I talked before about having people switch or rotate roles between coding and testing. Turn the process upside down to break down the disconnect between requirements and implemented solutions.
- Paired programming – Try pairing two programmers on a user story. See what happens, adjust, and do it again!
Agile itself – and XP – is not a methodology. It is not to be applied as a whole, but rather practiced and learned from.
You and your team can practice and share a lot – I recommend using the Lucidchart tool with Extreme Programming process example (paid link) as part of your process.
Put some limited agile XP practices into action to address the most pressing problems and opportunities, watch closely, and adjust accordingly.
Conclusion
XP, like any other approach, need not be utilized to the letter to gain benefit. And it need not be applied only to software development. This post provided the XP framework – but it can apply more broadly.
Have you applied any pieces of the XP framework on a project? What were your results?
Here’s an excellent video that not only explains the intricacies of XP but compares and contrasts it with scrum: