I’ve been struggling a bit to figure out what topic to cover this week as I had quite a flurry of activity over the past couple of weeks. I decided to talk about eXtreme Programming practices from the viewpoint of someone who’s done them. Well, some of them. But I know that many developers are reluctant to try many of the practices and – having been there in the trenches – I hope to provide some guidance.
What Is eXtreme Programming?
eXtreme Programming (or XP) is a set of practices for software engineers. They’re designed to increase the likelihood of successful projects and to improve quality. Kent Beck, the author of the XP model, was one of the signatories to the original Agile Manifesto and much of XP can be found in its values and principles. eXtreme Programming is centered around four principles:
Embodies the value “individuals and interactions over processes and tools”.
This channels the principles “maximizing the amount of work NOT done”.
Feedback cycles – especially short ones – give us valuable insight into the usability and suitability of our product.
Courage helps us make bold stands in development choices and to embrace a philosophy that may not be popular in our organizations.
There are several practices from XP that are both popular and unpopular among developers. Most of the unpopular ones you’ve likely heard about are pair programming and test-driven development. It’s surprising how resistant developers are to the idea of working with another engineer. Part of it, I think, is our early experience in development. Typically we programmed by ourselves rather than as part of a team. As a result, we’re more comfortable working independently. For professional developers, though, there’s nothing better than a good pair-programming environment.
Test-driven development is another point of contention. Most developers just want to write code rather than think about or – horror! – test it. The thought of having to write a test before writing your code is almost as alien as having a tea party on Mars. But we find that if we shift our brains from a traditional test pyramid to an agile test pyramid that automating unit tests is the best way to ensure a quality product.
Some eXtreme Programming Firsts
As an aside, there are a few things that came out of XP that were original and unique. The ubiquitous construct of a user story originated in eXtreme Programming. When I was a developer, our stories were slips of paper attached to the wall of our team space. We had a piece of yarn that designated the release; everything above the line would be released and everything below the line would have to wait. It was a very easy way to visualize our project goals and our expectations for delivery.
Another first (I believe) is the idea that “working code is the primary measure of progress”. It focused the team on delivering the product – not great requirements or design documents. When I was writing software, we cared most about the functionality we were delivering. Thankfully we had a brilliant tech writer who captured all of that perfectly, but it was because the software worked that she was able to do that. Focusing on the product and not the supporting documentation was critical to meeting our goals.
Advice for Adopting eXtreme Programming Techniques
If you are coaching a team and introducing XP techniques, you will encounter resistance. I know this from almost twenty years of agile transformations, both in the trenches and managing those who are. Here are a few tips to help a bit.
One of the main challenges to adopting XP is that of pair programming. As I stated earlier, most developers aren’t used to developing with others. Rather than jumping into pair programming from the get-go, suggest collaborative programming.
One of the main benefits of pair programming is having knowledge sharing and a shared understanding of the code. In collaborative programming, a developer still writes the code by themselves but then talks with another developer about the code when it’s still in development. This helps the other engineer have context for the work but it also gets another pair of eyes looking over the solution. Talking about your code is so worthwhile that some teams use debugging ducks when they run into trouble. My recommendation, though, is instead of a rubber duck, talk to a co-worker. Your co-worker may be a little more judgmental but it’s better for the team. And if we get more people looking at the same code, we’re apt to find refactoring possibilities that one person may not see.
Automation is currently paying the biggest dividends in development. If you want to be productive and stay productive, automating testing is the way to go. Not only does it lead to other cool things – continuous integration, continuous delivery, DevOps, etc. – it also reduces the end-of-project demands on the team. Are your teams frustrated with having to stay late and work weekends to fix bugs? Damn those testers!
You can gently point out that the testers are just finding the bugs that they – the developers – are leaving for them. That’s a good reality check but a better one is pointing out that they can avoid all of that if they try automating. You don’t even need to adopt test-driven development – just start automating code as you write it. There are a number of open-source automation suites out there now, so your team should have no trouble implementing it. And if you bring your testers into your team (you’re doing that, right? RIGHT?!), you can have them working on automation from the first day of the sprint! If your testers and developers are working on automation, you’re going to build a great suite of testing you can run every time code is committed or a build is pushed to a higher environment. And it helps identify hard-to-find integration issues.
Seriously – automating testing is perhaps the biggest bang for your buck out there. Start now!
Another challenge for many developers is the idea of open space. Tearing down cube walls and making a large lab-like area reminds them of college. While developers may think that being alone in a cube is the best way for them to focus and get their work done, fewer walls help teams communicate and collaborate. In most environments I worked as a developer, we had either half-height walls or some kind of team space where all the cubes opened into a communal area.
One thing that convinced me of the benefits was overhearing conversations that our customer team was having (they’re the Product Owner of an XP team). Those conversations invariably led to changes in our story priorities or guided current development. Without that open space model, it would have been challenging to be as responsive as we were – and as we needed to be.
To convince your developers, you may need to talk about introducing the communal team concept – co-locate your team and remove the back walls. It feels a little naked, but the benefits are awesome. And try to find the right team to act as a trailblazer. You may have to shop the idea around to a few teams, but usually, one will try it and act as a guinea pig for the others.
Here at Velocity, we practice a lot of the recommendations of XP. Having a good team space (almost all of our teams are co-located), having open communication, automating testing, and delivering working code every sprint are key components to our success. Toss in some coaching to identify those pain points in the process or the team dynamics and you get a lot of high-performing teams. It’s our people that make it happen for our clients.
Adopting eXtreme Programming practices is a hard road. There are quite a few roadblocks you’ll conquer, but the benefits of good engineering, focused on delivering a high-quality product should be the great motivator for any team. There are times when a team or team member has trouble adapting. That’s where having a good coach – or a good mentor – can help make all the difference. Reach out to your community or – if there’s no one you know or feel comfortable with – reach out to me. You can find me on LinkedIn. I believe in giving back to the community and volunteer and mentor in my free time.
And in the meantime…
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)