By Nick Butler
Tags: Agile , Development
Wondering what it’s like to be a product leader on an XP project? Find out how to succeed in the Extreme Programming customer role. You’ll learn what makes XP distinctive, where the framework came from and how its values, principles and practices feed into the work of product leaders.
Extreme Programming is an Agile framework for software development that emphasises programming practices as much as project management techniques.
Also known as XP, eXtreme Programming takes effective software development practices to extremes. For example, having programmers review each other’s code works well, so XP takes this to the next level by doing code reviews in real time via pair programming.
This focus on technical practices can make it harder for non-technical product leaders to get to grips with XP. And the fact that it takes these practices to extremes can make some of them seem counter-intuitive.
What follows is an explanation of what Extreme Programming means for product leaders, through the lens of the XP Values, Principles and Practices.
If you’re already working in an Agile way, some of this will be familiar. That’s because XP is one of the frameworks that fed into the Agile manifesto. Plus, elements of the framework have become best practice in software development and have been adopted by other methodologies.
In fact, pure XP projects are quite rare these days, as the chart below shows.
Unlike Scrum, with its Scrum Guide, there is no single description of XP.
According to Martin Fowler, one of XP’s early contributors, “the definitive description of Extreme Programming is Kent’s white book”, Extreme Programming Explained: Embrace Change. Even in that one book though, there is plenty of variation between the first and second editions.
While Beck is widely regarded as the father of XP, a number of people were there for the birth, and have offered their own descriptions. These include Ron Jeffries’ What is Extreme Programming? and Don Wells’ Extreme Programming: A Gentle Introduction.
This can mean it’s tricky for product leaders to work out where they fit in.
In XP, the customer is the main expression of the product leader role.
“The customer provides the requirements, sets the priorities, and steers the project,” says Ron Jeffries.
The Extreme Programming customer is:
Sometimes the customer and the product manager are seen as one and the same.
“You will need to assign a customer or product manager to work with your team full time. You need that close daily connection to the business to produce the best product you can,” says Don Wells.
Sometimes they are seen as separate roles that work together, much as the Scrum Product Owner works with users.
“Product managers encourage communication between customers and programmers, making sure the most important customer concerns are heard and acted on by the team,” says Kent Beck. “Product managers write stories, pick themes and stories in the quarterly cycle, pick stories in the weekly cycle, and answer questions as implementation uncovers under-specified areas of stories.”
In this post, we use the term Extreme Programming customer to wrap up both sides of the product leader role:
So how does this role fit with the values, principles and practices of XP?
Let’s look at how Don Wells sums up the values, along with what the value means for product leaders. Don, in line with most XPonents, gives five values:
“We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal.”
Because specifying the work starts with the customer, simplicity starts with the customer too. You’re always aiming to identify the smallest, simplest chunks of work possible.
“Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code.”
The customer is a key conduit for communication, channeling user needs and organisational priorities to the project.
“We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. And we will talk about the project and adapt our process to it, not the other way around.”
Valuing feedback means the customer is valued in XP. That’s because the customer provides the crucial feedback on whether what’s being built meets the needs of the end-users and the business.
“Everyone gives and feels the respect they deserve as a valued team member…Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.”
If you’re new to XP, one of the ways you can demonstrate this value is by respecting XP’s extremes. Some of the practices may seem over the top, but give them a go. It’s the only way you’ll know if they’ll work for your team and your project.
“We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. And we don’t fear anything because no one ever works alone. We will adapt to changes when ever they happen.”
The XP customer needs to have the courage to prioritise ruthlessly. Keep the team focussed on the work that will bring the most benefits, soonest.
The principles of XP make the values more concrete. They’ve been expressed in different ways at different times. You can get a good overview of the principles from the 5 fundamental principles Kent Beck described in the first edition of Extreme Programming Explained:
Here’s what these mean for Extreme Programming customers and their product leadership work.
XP wants feedback early and often.
Weekly iterations which deliver working software mean that, as the extreme programming customer, you’re constantly testing the latest improvements and giving feedback. You might be doing this personally, if you’re an end-user yourself. Or you might be getting the latest improvements in front of the customers you look after as a product manager. Or both.
You can also get feedback from the market, by deploying the latest features or through beta testing.
A good XP customer is one who gives fast feedback. You’ll respond quickly, when, for example a story is up for acceptance or a developer has a question. A good XP customer also communicates feedback clearly too, because that means it can be implemented quickly.
Think of the simplest version of a feature that could deliver value to end-users. Assume that this will actually deliver the value needed. Then write a user story for that feature. You can always add more later.
As an Extreme Programming customer, you’re always trying to come up with the simplest, smallest user stories possible. The same goes for the other other aspects of the product leader role, like planning and working with stakeholders.
Identify your top priority problem or user need. Specify the simplest solution. Check that it solves the problem or it meets the need. Repeat.
Product leaders need plans and strategies, and need to embrace the fact that these will change. You’re actively looking for changes. You’re keeping tabs on evolving user needs, organisational priorities, solution options and what’s happening in the marketplace.
As the Extreme Programming customer, you can help build a high-performing team who are proud of the work they do. Part of your job is to assess the value your product is delivering your customers. You can help the rest of your team feel proud by sharing what you learn about the benefits the product is bringing. Share customer feedback, stories from user testing, metrics, and all the other ways that you track value.
Following the principle of incremental change, these practices are a bag of tricks you can dip into. You don’t need to implement them all in one go.
Again, there is no single canonical set of practices. Even Kent Beck has a couple of lists. In the second edition of his book, Beck expanded his original 12 practices to 13 primary practices and 11 corollary practices (ones that stem from the primaries).
Here’s what Beck’s 13 primary practices mean for Extreme Programming customers.
“Develop in an open space big enough for the whole team. Meet the need for privacy and “owned” space by having small private spaces nearby or by limiting work hours so team members can get their privacy needs met elsewhere.”
Having the customer sit with the developers makes it easier to live up to the values of communication and feedback. You can do it face-to-face, which is faster and more effective.
“Include on the team people with all the skills and perspectives necessary for the project to succeed. This is really nothing more than the old idea of cross-functional teams.”
Beck argues that this leads to one of his corollary practices: Real customer involvement.
“Make people whose lives and business are affected by your system part of the team,” he says. “The point of customer involvement is to reduce wasted effort by putting the people with the needs in direct contact with the people who can fill those needs.
“No customer at all, or a “proxy” for a real customer, leads to waste as you develop features that aren’t used, specify tests that don’t reflect the real acceptance criteria, and lose the chance to build real relationships between the people with the most diverse perspectives of the project.”
“Make your workspace about your work. An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds.”
Beck recommends making the work of the team transparent through big visible charts. These project boards give you a focus for face-to-face communication. They make it easy for the customer to keep tabs on how your priority stories are coming. And they are a great tool for communicating progress to your stakeholders.
“Work only as many hours as you can be productive and only as many hours as you can sustain.”
As the bridge between the business and the developers, Extreme Programming customers have multiple demands on their time. You’re constantly called on to make decisions. There will always be more you could do, so watch out for diminishing returns. A tired customer is more likely to make the wrong decision.
“Write all production programs with two people sitting at one machine…Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.”
Pair programming is the principle of rapid feedback taken to the extreme, through instant real-time code review (among other things).
When first encountering the practice, many product leaders and executives think it must cost a fortune. Surely you’ll need twice as many developers to do the same amount of work. In practice, there is research that suggests that the increased cost is small, and can be outweighed by the improved quality of code.
“Plan using units of customer-visible functionality. As soon as a story is written, try to estimate the development effort necessary to implement it.”
A user story is a short description of something your users will do when using your software. It usually includes:
As an Extreme Programming customer, you decide which are the top priority stories for that week’s iteration. You work with the developers to write a story that is valuable, simple, clear, testable and that the whole team understands.
Estimating the size of the story early means the customer gets to clarify what’s involved with the developers. And identifying the size helps the customer prioritise. A bigger story needs to offer more value to be worth doing.
Learn more about user stories and acceptance criteria.
“Plan work a week at a time. Have a meeting at the beginning of every week. During this meeting: 1. Review progress to date, including how actual progress for the previous week matched expected progress. 2. Have the customers pick a week’s worth of stories to implement this week. 3. Break the stories into tasks. Team members sign up for tasks and estimate them.”
The weekly cycle, along with the quarterly cycle, are part of what’s been called the XP planning game: how work gets planned, estimated, picked up and tracked.
For the customer, the process starts before the meeting, when you identify the stories that will deliver the most value.
“Plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.”
During quarterly planning, Kent Beck advises that teams:
Much of this work, especially planning, prioritising and presenting the big picture, starts with the customer. However the ideas and input of the developers are crucial too.
The customer can reiterate the vision for the project, the benefits it will bring to the organisation and to the end-users, and present a roadmap for the work ahead. This gives the developers both direction and motivation for the quarter ahead.
“In any plan, include some minor tasks that can be dropped if you get behind.”
Slack is work that is useful but not essential to delivering what you’ve projected. It helps customers keep stakeholders happy by consistently meeting your forecasts.
“Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback.”
A build involves compiling all the code, files and suchlike into a usable form.
Customers can help with this practice by prioritising the optimisation work needed for the build to:
“Integrate and test changes after no more than a couple of hours.”
Continuous integration in XP means that each pair of developers regularly merge the code changes they’ve made into a shared repository.
Frequent integration keeps code changes small and simple, limiting the number of moving parts that need to fit together. More moving parts make it harder to find and fix problems.
Is integration commonly causing problems or becoming less frequent? As the customer, you could prioritise stories to resolve the integration issues. A small investment now can save bigger headaches later.
“Write a failing automated test before changing any code.”
A test is a description of what the code is supposed to do which you can check the code against.
This is another practice that can cause the uninitiated to scratch their heads. Why, as a customer, would you invest in having an automated test suite? Why would you write the tests first?
The benefit of this upfront effort is that developers:
“Invest in the design of the system every day. Strive to make the design of the system an excellent fit for the needs of the system that day…XP teams are confident in their ability to adapt the design to future requirements.”
This doesn’t refer to visual design but rather to the technical design of the system, the building blocks and relationships within the code.
One of the results of this approach is that yesterday’s simplest design doesn’t always meet today’s needs. This often means developers want to spend time refactoring: improving the code without changing its observable behaviour. They may want to make it easier to understand or cheaper to modify for example. Sometimes this can seem like a cost without immediate benefit. But the XP value of respect suggests that you take their advice on board. They know the pain points that hurt productivity.
As we’ve seen from looking at XP’s values, principles and practices, the customer is a fundamental part of the framework.
The Extreme Programming customer:
Extreme Programming combines a pragmatic focus on technical excellence with a commitment to empowering and supporting the team. Done well, it can lead to a highly productive, highly enjoyable working environment, with the customer as its compass and guide. Does that sound like the role for you?
Extreme Programming Explained: Embrace Change – Kent Beck
