When you hear the term “extreme programming”, what do you think of? Coding while skydiving at 15,000 feet? Bug-fixing while scaling the north face of Kilimanjaro? Refactoring while swimming with sharks at the Great Barrier Reef?
For tech nerds like me, we probably think of the wealth of technical practices espoused by this Agile method. These technical practices include stories, pair programming, slack, continuous integration, test-first, and others. Extreme Programming (XP) practices are typically used within a Scrum or Kanban team to help ensure high levels of software quality and continuous integration.
Long Forgotten Values
Did you know XP also describes 5 values and 14 principles? In Kent Beck’s seminal book Extreme Programming Explained – Embrace Change, all of these values and principles are described in detail before even mentioning a single technical practice! Beck makes the point that values are important because, without them, the XP practices are performed for their own sake while lacking purpose and direction.
While values are not necessarily actionable like practices, they provide overall guidelines for our behaviors and actions. Values describe the fundamental beliefs within our team and extend to how we deal with other teams and organizations.
Let’s focus on the 5 Extreme Programming values: communication, simplicity, feedback, courage, and respect. Unfortunately, these values have been largely forgotten by the development community as we pursue excellence in our technical practices. It is now time to reclaim the understanding and overall context these values provide. By paying attention to these values, your team can achieve higher levels of agility and productivity.
Communication is key to any high-performing Agile team. Team awareness and problem resolution are heightened when each team member communicates well. Communication extends well beyond our team into the overall organization and our communities of practice.
I recall a time early in my career where my team and I were surprised to learn that a different team was building the exact same functionality we were building. How many problems and wasted money are caused by this dreaded “lack of communication”? My gut tells me most of them. Beck states “… motion without communication is not progress.” If we are progressing well, are we also communicating well?
As Agilists, we need to err on the side of over-communication. We need to create a culture of high communication and honest transparency about our successes, failures, and plans.
I once had a boss whose favorite saying was “simple is hard.” In my experience, this is so true. Not everyone can do it. As humans, we have a natural proclivity towards over-engineering (guilty as charged) and adding complexity (simply because it can be done). Beck calls simplicity “the most intensely intellectual of the XP values.”
YAGNI: You Aren’t Gonna Need It.
I once had a VP of Product Management for a trip planning system who insisted that our team spend valuable time structuring our software so that it would be “easy to add in trip plan variations–just in case”. Despite my cries of “YAGNI”, he persisted and we added this capability at the expense of other more basic functionality. We also slipped the launch date by 2 months. Guess what? Seven years later and still no new types of trip plans needed.
As Agilists, we need to resist the temptation to structure our work products for the future. There, I said it. Focus on today only. The future will take care of itself. While there is always a healthy balance between simple and well-structured, we should bias our thinking towards the elimination of wasteful complexity. YAGNI is a good thing – embrace it!
For Agile teams, feedback is at the heart of welcoming change and inspecting and adapting. It can come in many different forms such as end-user reaction, stakeholder demo comments, recommendations from other teams, QA opinion, and improvement ideas generated in a Sprint Retrospective.
The tighter the feedback loop the better. This allows us to make agreed-upon changes in shorter amounts of time so that the potential benefit derived over time from the change is maximized. In an environment of innovation and experimentation, feedback is how we determine next course of action–whether to persevere, pivot, or pause.
As Agilists, we must continually ask ourselves “How can we get more feedback?”. Reacting to feedback helps to drive down risk, removes assumptions, and most importantly helps ensure that we are truly building the right product.
Have you ever been in a situation where team members were scared to speak their minds? I have and I’m not proud of it. The result – better ideas not being shared for fear of ridicule or polite dismissal. Forget “wisdom of the crowds”. If team members are not courageous, you will have “wisdom of the anointed few”. This will hurt your team’s’ ability to make the right decisions and also crush the spirit of the non-anointed ones. Who wants to work in this environment? Lack of courage is a hallmark of low-performing teams.
Courage supports all other XP values. Be courageous in speaking the truth, pleasant or unpleasant, as this will increase trustful communication. Discard failing solutions and seek new ones as this will increase simplicity. Instead of saying “we have no access to our end users”, demonstrate the courage to figure out a way to get their feedback.
As agilists, it is our job to help cultivate the safe environment where every team member feels like they can share their thoughts in a family-type setting. I always like to say “we can disagree, but in the end – just like family – we will continue to love and support each other.”
Beck’s second edition book adds Respect as a first-order XP value. Respect lies below the surface of all other XP values. It is an innate belief that every single person is important in their own way. I cannot say it any better than Beck, “Every person whose life is touched by software development has equal value as a human being.”
As Agilists, we need to call out situations where lack of respect occurs. Our underlying assumption should be that everyone is trying their best.
Think about your Agile team and how it stacks up against the Extreme Programming values above. Ask questions such as:
- Do we communicate honestly at all times, or do we tend to hide non-flattering work?
- What complicates our work (processes, code areas, etc.), and how can we simplify?
- Are there opportunities for feedback that we are missing?
- Do we truly allow for courage, or are team members overly careful in speaking their mind?
- Do we always exhibit respect for each other, or do we sometimes make fun of people behind their backs?
As a starting point, consider adopting the XP values. Adjust as you see fit. Have open discussions about the meaning of each value and how the team can improve within each. For extra credit, try mapping your current technical practices back to a specific value.
Values put our principles and practices in context. Don’t forget this important step in your Agile journey!