The Agile manifesto was originally created and signed by 17 developers. This group has become legendary in the world of technology, their fame can be likened to that of the founding fathers of American History. These 17 rebels went against the accepted belief of the project management discipline and forever changed the way we as technology professionals do work. One of these developers was named Kent Beck and went on to codify Extreme Programing as one of the leading Agile Frameworks.

Though not as popular as Scrum or Kanban as a full framework, the principles of Extreme Programing (also referred to as Extreme Programing) have found a life of their own. You can see their influence on every other Agile Framework and you will find that they have been adopted as best practices across the entire software development industry.

In this article we are going to take a look at the Values and Rules of the Framework to better understand what makes it stand out from other frameworks.

Extreme Programming Values

Simplicity: 

This is the first value of the framework and is jam packed with insight. The goal of Extreme Programing is to maximize value by reducing waste. This pulls a lesson from the Lean methodology and keeps people focused on building simple and clean solutions instead of rewarding people for complexity, and excess. This can be translated to mean we should simplify everything from complex documentation and project plans, to excess code. 

Accompanying the value of Simplicity though is a statement made by the framework which says “We will create something we are proud of…”. This statement takes the concept of simplicity and demonstrates that there still must be a high level of excellence. This is quite profound as it is true both in software development and in life that the simplest things can actually be the most powerful when designed with intentionality. 

Communication: 

In Extreme Programing everyone works as a self-organized team. The framework says that, “Managers, developers, customers are all part of a single team.” This is critical to understand and is a differentiator from other frameworks where Managers, and Product Owners are not considered team members. It is the goal of the team to facilitate constant communication amongst its members. This does not mean that everyone touches base in the daily standup and then retreats to their cubicles to code independently the rest of the day, Extreme Programing says that constant communication across the team each day is the best way to accomplish a software project.

It also states, “We will work together on everything from requirements to code,” a concept that is difficult for most Agile teams to accept. Other frameworks speak to cross functional teams, but this is often interpreted to mean that there are people from multiple disciplines as part of a single team who can each do the work that aligns with their skill set. Extreme Programing is very specific here that regardless of your strength, everyone works on every aspect of the tasks in front of the team.

Feedback: 

This is a consistent theme across all Agile Frameworks. Feedback loops are key to delivering valuable software to the customer as quickly as possible. To facilitate this there should be ongoing daily communication amongst the team to review the software and discuss needed changes. Since the customer or product manager is part of the team in Extreme Programing, this gives them daily input into the direction the team is going. Outside of the team, the goal is to get regular feedback from other stakeholders on a daily or weekly basis so adjustments can be made in real time to keep the project on track. 

It is interesting to note that Extreme Programing states, “We will talk about the project and adapt our process to it, not the other way around.” This is major and demonstrates one of the main divergences from Waterfall Project Management which is highly focused on process. Many of the other Agile Frameworks such as Scrum also fall into the trap of elevating process, though to a lesser extent than what we see in the Waterfall Methodology. Agile in general focuses on getting work done through collaboration rather than conforming work to a process. Extreme Programing is a clear proponent of this.

Respect: 

One of the most important attributes of a good working environment is mutual respect. This is true across a company, but is paramount inside a team. Extreme Programing teaches that everyone must give respect and in return should feel respected for their contribution, regardless of how big or small it was. 

Two critical relationships inside a team are specifically called out in Extreme Programing that are worth noting. The first is the relationship between the developers and the customer. Both are apart of the team but there exists a tendency for animosity to build because the customer can come off as being demanding and they often pretend as if they are superior on the food chain, while the developer feels as if they do all the work and provide the actual value of the team. This is one of the main reasons for having these two parties on the team full time, working together so they can both see the contribution and understand that they need each other to succeed. The second relationship Extreme Programing specifically calls out is that of the manager to the rest of the team. Note that managers are considered team members, same as everyone else, but they must avoid the tendency to usurp control as the leader and should instead “Respect the teams right to accept responsibility and receive authority over their own work.” In other words, the manager should help the team succeed by letting them self-organize. Shifting the managerial power to the team is tough for many managers, but it is absolutely critical for developing high performing teams. The manager must earn their own place of the team as a mentor, coach, and facilitator rather than a traditional project manager.

Courage: 

Ever heard the term CYA or “Cover your A$$”? The term is often used when people know things are going to go south and they spend their time documenting excuses in hopes that the companies wrath does not fall on them for the failure. This is one of the most prevalent signs of a toxic culture. The best company and team cultures encourage failure rather than punishing it, through failure we often learn our most important lessons, and more importantly, by building a culture that embraces failure you encourage your people to take the necessary risks for success without fearing the possible consequences.

Extreme Programing values courage and teaches the team to speak up, try new things, and collaborate through failure to create a learning culture. 

Extreme Programming Rules

In comparison to the Values, the Extreme Programing Rules are clearly defined activities or principles that make up the actual framework. By implementing all of these Rules you are implementing the Extreme Programing Framework, by adopting only some of them you are utilizing practices of Extreme Programing. Both options are worth considering, and at the very least, adding the understanding of these Rules to your repertoire of skills will make you a truly adaptable Agilist. 

Rules for Planning

Planning Rule 1: User stories are written.

Planning Rule 2: Release planning creates the release schedule.

Planning Rule 3: Make frequent small releases.

Planning Rule 4: The project is divided into iterations.

Planning Rule 5: Iteration planning starts each iteration.

Rules for Managing

Managing Rule 1: Give the team a dedicated open work space.

Managing Rule 2: Set a sustainable pace.

Managing Rule 3: A stand up meeting starts each day.

Managing Rule 4: The Project Velocity is measured.

Managing Rule 5: Move people around.

Managing Rule 6: Fix XP when it breaks.

Rules for Design

Design Rule 1: Simplicity.

Design Rule 2: Choose a system metaphor.

Design Rule 3: Use CRC cards for design sessions.

Design Rule 4: Create spike solutions to reduce risk.

Design Rule 5: No functionality is added early.

Design Rule 6: Refactor whenever and wherever possible.

Rules for Coding

Coding Rule 1: The customer is always available.

Coding Rule 2: Code must be written to agreed standards.

Coding Rule 3: Code the unit test first.

Coding Rule 4: All production code is pair programmed.

Coding Rule 5: Only one pair integrates code at a time.

Coding Rule 6: Integrate often.

Coding Rule 7: Set up a dedicated integration computer.

Coding Rule 8: Use collective ownership.

Rules for Testing

Testing Rule 1: All code must have unit tests.

Testing Rule 2: All code must pass all unit tests before it  can be released.

Testing Rule 3: When a bug is found tests are created.

Testing Rule 4: Acceptance tests are run often and the score is published.

For an in depth explanation of each rule take a look at Extreme Programing’s website

Summary:

Extreme programing can seem extreme to some. With its focus on paired programming and comprehensive unit test coverage, it can also seem expensive. I would argue that the principles of Extreme Programing are extremely powerful and the speed created by the implementation of self-organized teams and customer alignment with the team will offset any additional overhead incurred by the rules. That said, Extreme Programing is not for every project and is most valuable in a highly regulated or critical system development project. Extreme Programing’s approach encourages failure to happen early and often inside of the team to drastically decrease the failure rate of a production system. This makes it ideally suited for specific high risk projects. Regardless of the merits of a full Extreme Programing implementation, many of the framework’s rules can be selectively used to strengthen Agile teams utilizing other frameworks. For instance, paired programming for new hires, or unit test coverage standards can help any team decrease failure rate and increase value delivery. For this reason, understanding Extreme Programing’s rules can be helpful for anyone looking to strengthen team performance.