3 Surprising lessons you can adopt from Extreme Programming
Even if you are using something else: Scrum, Kanban, your custom™ process.
The Customer grounds you in reality, not judge how you spend the budget
Reversibility is your fuel: invest into design, refactoring and substitutability
Right-size release batches: Scoping is efficient only if done during planning
“You want a better way to develop software, you want better relationships with your customers, you want happier, more stable, more productive programmers.”
If you are new, welcome to 🔮 Crafting Tech Teams. I publish to you every week on how to become a better engineering leader. As a subscriber you will receive these posts straight to your favorite inbox.
Free subscribers get access to about half of each paid post and the free content related to the book club and 🏔 Our Tech Journey.
Whenever you’d like to become a paid subscriber you will receive full access to all content including early previews of books and coaching I offer.
i. The Customer
The Customer leads the ensemble of engineers like an orchestra. Grounds them in reality and synchronises their movements. Release cadence, scope, compromises. The Customer is part of the team.
The Customer is not the end user. The Customer is the person who has economics interest in the product succeeding. It may be…
a key stakeholder in your company
an agency client
a B2B business partner
a different product team
An engineering leader’s role in an XP team is to make sure the Customer gets the attention she deserves, including going to great length to ensure the team has been setup to a high level of integration with the Customer. They need to be part of the team to guarantee the best chance of success.
Without the Customer engineers do not know the value or impact of their work. How can they then make judgement on time investment, ROI regarding refactoring and rework? Engineers cannot be merely driven by a deadline. Scope is the most impactful accelerator. More on scope in the next chapter on Reversibility.
Recall the example from the video. The orchestra can play without the conductor… right? After a while. But would you risk it? For an expensive concert? Who has the most to lose?
ii. Reversibility
The biggest risk you are facing is having to change something expensive late into the project. The cost is a factor of difficulty of change, scope of change and disruption caused because of it.
Products that are rigidly built per-spec that was defined at the beginning of a project or too long “increment cycle” are doomed by enforcing a wait period for changes to happen. After launch. After the milestone. After this update.
XP teams do not work that way. They understand the economics and the risk. Your team can too. But it requires a level of humility and courage to speak up and claim “we might be wrong about this.” If we are, how are we going to change it? How difficult will it be.
Critics often mistake Reversibility for over-abstracting for substitutions that are extremely unlikely (ie. replacing MySQL db for Oracle). That is not the target. The target is to ensure critical changes—bold changes!—mid-project regarding architecture and key features.
Not to cater to the developers. To ensure that the change happens when most of the budget and time scope are still available.
iii. Right-sizing
On the matter of scope, XP teams follow what is known as a Release Plan. This is not a series of JIRA tickets. It is a go-to-market strategy, or rather a go-to-production strategy. How large will the increments be? In what ways can we split the product into releasable, smaller chunks.
These conversations happen before any engineering. They need to happen at the product capability planning level with the customer. Of course with Customer. How else will you do it?
In different Agile methodologies like Scrum or SAFe engineers are often asked to take a ticket which is a “whole” and split it up into smaller releases… how? When the product was planned for the unit to be atomic.
Right sizing can be a challenge because it requires wide knowledge. Which is why it is challenging to perform without some form of ensembling where technical and non-technical team members (yes, including the Customer) meet. This is a great opportunity to overlap with other modalities like Value Stream Mapping, Domain-Driven Design, Event Modeling.
I am expanding my company-focused engineering leadership coaching to the MentorCruise platform. I am a Top Mentor on MentorCruise rubbing shoulders with engineering leaders, mentors and coaches from the largest tech corporations.
Courage
Extreme Programming is considered one of the more rigid agile implementations. It is bold. It is direct. It faces risk head on and manages it, maximising the successful outcome of the product.
To quote the book “Extreme Programming Explained”
If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
If architecture is important, everybody will work defining and refining the architecture all the time (metaphor).
If integration testing is important, then we'll integrate and test several times a day (continuous integration).
If short iterations are good, we'll make the iterations really, really short—seconds and minutes and hours, not weeks and months and years (the Planning Game).
It takes courage to be vulnerable and make mistakes in front of your team. To code in a pair, let alone an ensemble.
It takes courage to have the Customer see the really tiny mistakes happening every day and being open with them.
It takes courage to listen to the Customer regularly and be prepared to rock the boat and make bold course corrections.
It takes courage to push Say No to features in favor of having more tests and a better process.
Early in my career I was terrified of people. Making eye contact. Shaking hands. Speaking up and being controversial. Listening actively, especially to constructive but negative feedback. What I was good at was boldly projecting quality and architecture plans. But that had to change. Because those qualities alone do not guarantee a successful product. The right product. At the right time. For the right cost.
Courage is not gained by reading books or by asking your higher-ups for an all-access permission slip. Courage is gained by knowing what the right thing is. And doing it. Without asking for permission. Instead, to generate data, releases, or otherwise useful. Even if the plan was wrong.
Summary
I took the lessons from XP to heart over the two decades in tech. I didn’t seek Extreme Programming. Extreme Programming found me. It occurred to me that most of the best-business practices like Continuous Integration, Test-driven Development, Stories and Release Planning are being advocated by XP practitioners.
Remember:
Be bold and seek commitment from your Customer. They don’t need to be there full time. But they need to feel like they are a part of the team.
Plan for change, not completeness. Your ability to refactor is your highest economic lever. Do not waste it. It is the most costly decision to revert.
Scope and batch in the earliest stages. Don’t plan all features and then cut them apart afterwards. Start with the slices and put them together. Make them smaller till you reach the limit of sensibility. This is your most impactful accelerator.
XP kept things simple for me. No certifications. No religion. No sales-y training and titles. Results. Results and dealing with your resistance. Coaching and guiding. Like a conductor in an orchestra.
I believe in fair exchanges. If you use the referral button below, you’ll have an opportunity to earn free access to the premium and paid content. Just three referrals will earn a free month!