Reading Notes presented by BookClub.dev

Our journey through Extreme Programming Explained: Embrace Change is nearly at its end.

This week we look at Beck's pragmatism and how that has helped other methodologies to adopt parts of XP.

We also look at what drives a company to outsource development teams.

I hope you'll join us this Thursday at 7 pm eastern as we discuss these topics live. You can watch the stream by going to bookclub.dev/live.

This week we talk about applying XP.

Beck identifies 2 keys that are required for any team to make rapid change, pain and a shared vision.

We'll be talking more about these ideas this Thursday at 7 pm Eastern. You can join the conversation by going to bookclub.dev/live

Resources

• Westrum's model of organizational culture

This week we look at how to Scale XP.

We are reading chapter 15 and 16 of Extreme Programming Explained: Embrace Change 2nd edition by Kent Beck.

I reference a great interview between Gene Kim and Michael Nygard. There are three of them the first is Architecture as the Organizing Logic for Components and the Means for their Construction.

Beck gives his three steps for breaking down a large task into a small task. It's great because it scales to solve any challenge.

1. Turn the problem into smaller problems
2. Apply simple solutions
3. Apply complex solutions if any problem is left

We also see the importance of having executive sponsorship when starting any initiative.

I hope you'll join us as we discuss scaling practices from one to many, this Thursday at 7pm eastern. You can join the discussion by going to bookclub.dev/live.

This week we look at three chapters from Extreme Programming Explained 2nd Edition by Kent Beck.

Chapter 12 Planning: Managing Scope
Chapter 13 Testing: Early, Often, and Automated
Chapter 14 Designing: The value of time

The common thread I see running through these chapters is that these ideas have gone mainstream.

So what is the new extreme version? Or are these the fundamentals that we now need to master?

Join the discussion this Thursday at 7 pm eastern by going to bookclub.dev/live.

I hope to see you there!

This week we continue our journey through Extreme Programming Explained 2nd edition by Kent Beck.

I'm trying something a little different though. This week I cover chapter 11 The Theory of Constraints, chapter 18 Taylorism and Software, and chapter 19 Toyota Production System.

All three of these are ideas that come from the world of manufacturing and have been applied to creating and deploying software.

Taylorism or Scientific Management has fallen out of style, but is still influential in many areas, even if it's no longer called that.

The Toyota Production System (TPS) is the inspiration for Lean and focuses on reducing waste.

The Theory of Constraints (TOC) works off the premise that there is one step in a process that determines the throughput for the entire process.

Beck gives a very relatable example to illustrate this... Laundry.

Washing 45 minutes
Drying 90 minutes
Folding 15 minutes

Try some thought experiments with this system.

How long does it take to process two loads of laundry?
What if washing only took 15 minutes?
What if folding only took 5 minutes?
What if drying only took 60 minutes?
What if you did four loads of laundry?

Resources:

• Team of Teams (Amazon)
• The Goal (Amazon)
• The Phoenix Project (Amazon)
• The Critical Chain (Amazon)

Happy reading

This week we look at Chapter 10, The Whole XP Team from Extreme Programming Explained 2nd Edition by Kent Beck (Amazon).

I discuss:

• Conway's Law and the Inverse Conway Maneuver
• The roles on an XP Team
• The two metrics Beck uses to measure the health of an XP Team

We'll dive into all this and more Thursday, July 15th at 7 pm eastern on Twitch. You can join by going to bookclub.dev/live.

Also if you are interested in more deep dives into concepts like Conway's Law and the Inverse Conway Maneuver drop me a line [email protected].

Conway's Law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

This comes from Mel Conway's 1967 paper "How Do Committees Invent?"

Roles on an XP Team

• Testers
• Interaction Designers
• Architects
• Project Managers
• Product Managers
• Executives
• Technical Writers
• Users
• Programmers
• Human Resources

Two Metrics for XP Team health

• The defect rate
• Length of time from idea to it generating revenue

Resources

• Extreme Programming Explained 2nd Edition (Amazon)
• How Do Committees Invent?
• Inverse Conway Maneuver
• The Unicorn Project (Amazon)
• The Phoenix Project (Amazon)

This week we look at chapter 9 of Extreme Programming Explained 2nd edition by Kent Beck and reflect on the exercise from chapter 8, Getting Started, that we did live last Thursday on Twitch.

After doing the exercise, I recommend the following format. Spend 5 minutes brainstorming on each of the three questions. After that, go back and refine what you came up with; this should take 10-5 minutes for a total of 20 minutes per practice.

The three questions to answer are

Why do you want to do the practice?
What are the things that lead towards doing the practice well?
What are the signs that you are moving in the wrong direction?

In this chapter, Beck described 11 corollary practices for XP. These are more advanced than the original 14 primary practices.

• Real Cusomter Involvment
• Incremental Deployment
• Team Continuity
• Shrinking Teams
• Root-Cause Analysis
• Shared Code
• Code and Tests
• Single Codebase
• Daily Deployment
• Negotiated Scope Contract
• Pay-Per-Use

We will discuss these practices live on Twitch this Thursday at 7 pm eastern You can join the discussion by going to bookclub.dev/live.

This week we look at chapter 8, Getting Started of Extreme Programing Explained 2nd Edition by Kent Beck (amazon)

The beauty of Extreme Programming (XP) is that you can start where ever you are right now. Therefore, it's not necessary to adopt all the practices at once. In fact, it's even recommended not to try and do them all at once.

The question is, where to start? For that, Beck gives us a mapping exercise to help us describe each practice of XP. From these maps, we can find where we are and how to move towards where we want to go.

Thursday, July 1st, I'll be going through this mapping exercise live on Twitch at 7 pm eastern. But I won't be doing it alone! You can join in by going to bookclub.dev/live

This week we look at the primary practices of Extreme Programming (XP) from chapter 6 Practices and chapter 7 primary Practices of our current book, Extreme Programming Explained 2nd edition by Kent Beck.

The 13 primary practices are

• Sit together
• Whole team
• Informative workspace
• Energized Work
• Pair Programming
• Stories
• Weekly Cycle
• Quarterly Cycle
• Slack
• Ten-Minute Builds
• Continuous Integration
• Test-First Programming
• Incremental Design

Join the live discussion this Thursday at 7 pm eastern as we discuss these practices and how we can use them in our daily work. You can join the conversation by going to bookclub.dev/live

This week we look beyond the 14 principles of Extreme Programming (XP) and how they follow the iterative paradigm of learning instead of the entity paradigm of learning.

To continue the conversation about these paradigms and the 14 principles of XP check out the live stream Thursday at 7 pm eastern at bookclub.dev/live.

I discovered those two paradigms of learning from Josh Waitzkin's book The Art of Learning (Amazon)

The 14 Principles of XP are

• Humanity
• Economics
• Mutual Benefit
• Self-Similarity
• Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby Steps
• Accepted responsibility