Core Values in Extreme Programming

Season 7 Epsiode 2
A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter

5 Essential Values in Extreme Programing
Extreme Programing By Kent Beck - Chapters 2,3 and 4

Chapter 2 - Learning to Drive
frequent, small corrections
don't wait to find out if you are going in the wrong direction
Chapter 3 - Values, Principles, and Practices
values are the roots of things we like and don't like in a situation.
Making values explicit is important because without values, practices quickly become rote (habitual repetition), activities performed for their own sake buck lacking any purpose or direction.

practices are evidence of values
Practices are clear. Everyone knows if I've attended the morning standup meetings. Whether I really valuecommunication is fuzzy. Whether I maintain practices that enhance communication is concrete.

principles bridge the gap between values and practices
START HERE
Chapter 4 - Values
Chapters 2 and 3 are small introductory sections, here is the TLDR:

Software, teams, and requirements change. We need to be able to adapt
to such change. The next 3 sections will be about values, practices,
and principles of Extreme Programming
Chapter 4 is about values

Everyone who touches software has a sense of what matters. One person might think what really matters is carefully thinking through all conceivable design decisions before implementing. Another might think what really matters is not having any restrictions on his own personal freedom.

What actually matters is not how any given person behaves as much as how the individuals behave as part of a team and as part of an organization.

Sometimes it's easy to bikeshed over things like code style. Arrow functions vs function declaration, inline functions vs methods, etc
XP embraces 5 values to guide development

1. Communication
2. Simplicity
3. Feedback
4. Courage
5. Respect
6. Communication
   When you encounter a problem, ask yourselves if the problem was caused by a lack of communication. What communication do you need now to address the problem? What communication do you need to keep yourself out of this trouble in the future?

JP: Retro feedback and postmortem feedback often includes communication - both good and bad
2. Simplicity
To make a system simple enough to gracefully solve only today's problems is hard work.

"What is the simplest thing that could possible work?"

JP: Emphasis on "today's problems" - how can we provide value to the customer without compromising on theirexperience and without overengineering a solution?

JS: Stakeholder communicatinon, actively work to include everyone in at the key touchpoints, initial concept, mokcup, prototype, final review.

JS: Have something to look at / talk about. Somebody make a mockup, somebody write some pseudocode

3. Feedback
   Being satisfied with improvement rather than expecting instant perfection, we use feedback to get closer and closer to our goals. Feedback comes in many forms.

opinions about an idea, yours or your teammates

how the code looks when you implement the idea

whether the tests were easy to write

whether the tests run

how the idea works once it has been deployed

JP: Be agile! Look to build an MVP. Get analytics on things and make decisions from there. It's hard to invest in an idea entirely and then end up ditching the whole thing. Everyone feels burned.

JS: Again, think through key touchpoints, (99%, 50%, 1%)[https://medium.com/the-mission/how-to-scale-yourself-the-99-50-1-framework-7798518f36e1]

4. Courage
   Courage as a primary value without counterbalancing values is dangerous. Doing something without regard for the consequences is not effective teamwork. [...] The courage to speak truths, pleasant or unpleasant, fosters communication and trust. The courage to discard failing solutions and seek new ones encourages simplicity. The courage to seak real, concrete answers creates feedback.

JP: Being able to speak up when you disagree with people's ideas and being able to listen and exercising patience.
JS: Being honest with yourslef and stakeholders about timelines, replytimes, scope.
JS: Having the courage to set boundries. - "I need this by tomorrow" - I'm sorry, I can't make that happen for you.
5. Respect
If members of a team don't care about each other and what they're doing, XP won't work. If members of a team don't care about a project, nothing can save it. Every person whose life is touched by software development has equal value as a human being. No one is intrinsically worth more than anyone else.

JP: It's much easier when everyone respects each other.
JS: Reconize there's rarely a "wrong" approach, avoid letting pesonal preference becoming the "right" way.
JS: Reconize positives, "what I like about this is... however" Try to keep things in a positive context.
6. Other
This list isn't exhaustive. The important thing is that your team should align on core values.
Other Values: safety, security, predictability, and quality-of-life <- I feel like these need an episode!
Chapter conclusion:
Values don't provide concrete advice about what to do in software development. Because of the distance between values and practices, we need a way to bridge the gap between them. Principles are the tool we need.

Picks
JP: Pair code review sessions
JS: the (99/50/1 framework)[https://medium.com/the-mission/how-to-scale-yourself-the-99-50-1-framework-7798518f36e1]
JS: Basecamp's new book - (Shape Up)[https://basecamp.com/shapeup]