SB01: Flirting with Extreme Programming
Three hacks you can employ tomorrow that substantially change team culture.
Many conversations about XP revolve around its dogmatism: if you follow all its principles, you and your team will transcend to a higher consciousness. While that can be true in many cases, it can also be challenging for enterprises looking to dip their toes in without massive disruption.
So, instead of approaching this article as an XP purist, I’ll play a far more helpful part: XP pitchman.
I’m looking to enable disruptors on your team—engineers who are looking for a better way but perhaps lack the tools or structural support required for radical change.
I’ll pitch you three straightforward things you can do tomorrow to see your teams immediately improve their happiness, cohesion, and product quality.
Part-time pairing:
Let’s start with the most controversial principle first: pair programming. That will get some Substack subscriptions!
While I’m at my happiest pairing on code all day, others (most) are not. But what if I told you that pairing only two hours daily can have substantial benefits?
What is pair programming?
Pair programming is the act of joining two teammates together on one task. Between two engineers, it can look like two smart folks building something neither thought possible while soloing. Between an engineer and PM, a PM can more effectively evaluate technical feasibility in backlog prioritization, add more technical color to story writing, or more efficiently estimate. Between an engineer and design, it takes the form of design refinement, where (typically rough) UI/UX work becomes polished and elegant.
Even with a quarter of your workday being paired, say two hours before lunch, you’ll notice measurable decreases in siloed knowledge, better alignment on product vision between product and engineering, more efficient new hire onboardings, more distributed incident management, less pull request bottlenecks, and more team camaraderie.
Of course, by reducing pairing down to two hours daily, you’ll have to get clever about what you’re pairing on, but here’s a cheat sheet:
Brand new features (ideally with user stories attached) prevent siloed context and tech debt accumulation. New features are also more fun, so combining fun work with a changing process is a slam dunk for adoption.
Brand new technologies: Watch your teammates become completely rejuvenated by digging into some Rust, Android, or [insert trendy framework here].
Test backfilling, bootstrapping, or pipelining: This will spread around the most vital skills needed for keeping your product running successfully now and in the future. Do it enough; you’ll start shipping fewer bugs and release faster. Tack on continuous deployment, and you’re flying.
Architecture discussions or early story ideating: Teaching a junior engineer how to think as a staff member can only happen by putting them in the same room as a staff engineer brainstorming on a product or feature. Plus, every experienced engineer gets stuck or needs a sounding board. There are no downsides, only unwilling teammates.
Fun and games: Even if you use pairing for nothing other than team bonding, it’s still a win! Try playing online games like Codewords, Skribbl.io, HaxBall, or spring for something fancier, like Jackbox. There is no better way to build teamwork as a core competency than by creating low-stress situations for cooperation. (This one is best served as a 10-20 minute break during other pairing sessions)
I didn’t say: pair on everything, watch a senior work all day, or hawkishly watch your junior to save them from getting lost. Instead, I advocated for pairing on the most essential FUNDAMENTALS. You'll at least see moderate success if you build the base and start ‘em off right. And foundations can’t be taught as efficiently as experienced. Again, there’s no substitute for practice and experience, especially early in an engineering career.
Spend Two Weeks Improving Test Coverage & Confidence:
Yes, Extreme Programming typically requires its practitioners to write tests first. Writing tests first typically produces simpler, more testable, and modular code. Over time, this becomes a higher quality, more maintainable product that can be easily modified.
But unless you’re building a greenfield, brand-new product, you’ll have to iterate your codebase toward coverage and confidence.
You can’t decree a test-driven policy without explaining (often to stakeholders) the zero-velocity days of “figuring out how to test something”, talking as a team about release confidence, or learning something similar to SOLID code design.
But you CAN evolve into it.
Start with back-filling. If your code has no tests, and bootstrapping is less valuable than replacing the product (Working Effectively With Legacy Code), invert the testing pyramid (as seen below).
Blanket the product with as many end-to-end/ automated UI/top-level tests as possible, covering the broadest swath of product and workflow behavior.
If you’re somewhere between, carve out time to bootstrap and/or fix your existing tests. If you’ve got suites of ignored tests you struggle to fix, throw them away and start over.
Invest a few weeks in increasing your test coverage. That’s the first step.
Advocate for two weeks to show a better path toward future maintainability. Sincerely do it, and even better, involve the whole team. Have one pair/person work on integrations, another end-to-end, and have two or three work on unit tests. The more tests you get working, the better.
After two weeks, take stock and gather feedback. How many tests are running? Are you testing behavior properly? Maybe even throw in a code coverage metric that’s tracked. Maybe opt for DORA metrics. Decide if you need another two weeks or if you’re ready for part 2: Test coverage as a story/task requirement.
Once you’ve built a test foundation, you will require all new features and bug fixes to commit tests on top of it.
That’s it! I’ve not forced you to start over, do TDD on every task, or even chastised you for not wanting to add tests to dead/legacy code.
That’s because you already know which products are essential and what testing brings to the table. I’m advocating for a starting place and a new policy to get you rolling. Come back for more in-depth advice.
Retros:
Retros? Really? Talking about feelings is a top-level hack? Yes. There is no better way to peer under your team’s metaphorical hood than by conducting open, psychologically safe retrospectives (preferably weekly).
Even if you follow no other agile principles, retros allow your team to tell itself, and ideally its leaders, what’s working and what’s not. There is no substitute for introspection. There’s also no shortcut for it.
Spend one hour a week, 1/40th of your work week, to open a massive feedback channel.
These problems exist and will likely continue to exist whether or not you talk about them. New or compounding issues will crop up if you ignore them. So don’t.
Be upfront, make it safe, and let your team tell you what’s wrong.
The most basic 3-column retro is a great start for anyone looking to lean in, and there are many other great retro templates, but I’d like to focus on just two critical pieces of every good retro:
Is the team feeling safe enough to generate praise AND critical feedback?
If the answer is yes, are you sure? Check one more time. If you’re unsure, conduct a “questions only” retro, where the team populates nothing but questions around things they’re confused with.
If you get a lot, and they demonstrate vulnerability, chances are they feel safe.
If your team rallies around a common external or unfixable complaint, such as the upcoming roadmap or upcoming feature work that’s not feasible–while not critiquing themselves or others–they may lack sufficient psychological safety to introspect effectively.
Roadmap and feasibility issues are still valuable to fix, and we should shoot for more empowerment over them, but also recognize this as a signal. This group may not yet have enough skills and/or safety to investigate the inner-workings of their team process.
Focus on developing that first.
Are you generating experiments/tweaks/action items and then checking in on them each week?
If you’re not cultivating ways to improve your team with every retro and trying them out with explicit plans to include feedback in next week’s retro, then you’re only fake listening. Listen, and have fun!
The experiments that result from retros are usually the most rewarding, fun, and marketable moments of entire jobs.
If your team tells you what to fix, listen.
Conclusion
And that’s it. If you’ve tried one or all three of these hacks and measured their impact on your team (maybe in a retro?), you’ll probably want more because something feels different. The gears are turning better; the machinery is smoother.
Come back in a fortnight for more hacks!
References:
https://dev.to/documatic/pair-programming-best-practices-and-tools-154j \
https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design
https://www.linkedin.com/pulse/inverting-test-pyramid-joel-masset/
https://martinfowler.com/articles/practical-test-pyramid.html
https://docs.gitlab.com/ee/user/analytics/dora_metrics.html
🙌