The Weaknesses of XP

Many of the weaknesses of XP stem from the fact that it is often presented in a semi-religious, almost cult-like way. This is the view that in order to practice XP, you need to utilize all the practices and stick with them to the letter, with no alternative if you can't use them or want to add to them. There are some in the XP community who recognize this problem, so hopefully this view will moderate over time.

XP is also subject to problems of interpretation. People who read the XP books or speak to XP teams can easily misinterpret the practices, overzealously apply them, and then decide that since one or two of the practices don't work, therefore XP doesn't, when in fact the XP mindset does work, and the XP practices around test-first development, refactoring, and simple design in particular are absolutely brilliant. People who dismiss XP as a whole are missing out on some valuable practices. Unfortunately, you don't have to look too hard on the Internet to find articles that reflect the failed XP experience.

XP Targets Software Developers, and Nobody Else

XP is too narrowly targeted at software developers. Successful software products are developed by teams, and this is stating the obvious, but teams include more than just software developers. Documentation, business people, Quality Assurance (QA), and usability are glaring omissions. Often, these other functions use practices that are incompatible with XP and then struggle with experimental practices, or because there is so much emphasis on the software these other functions are minimized [md] to the possible peril of the project.

The role of the manager is particularly abused in XP. I know quite a few managers who have read Extreme Programming Explained [Beck 2004] and been turned off on the whole thing because managers are cast in the role of the bad guy. While it can't be disputed that some managers are the bad guys, I believe that most managers want success and are a part of that success, not a hindrance to it. Perhaps the label manager is the problem. XP disdains bureaucrats (who tell what to do, when, and how) and while it is true that bureaucrats are not desired, leaders who know how to set up a collaborative, empowering environment are definitely required. Some people call this role the coach, and while that does capture the essence of this style of leadership, I believe that coaching is just one attribute of a successful leader.

Project Management

XP describes a project planning paradigm that is useful for a small team of software developers. Given XP's focus on software developers, this shouldn't be a surprise, nor should it be viewed as particularly bad because the practices are useful for some teams. However, the lack of a more rigorous attention on project management has led agile practitioners to propose hybrid agile techniques such as Scrum with XP [Schwaber and Beedle 2001] or ASD with XP [Highsmith 1999] and why Jim Highsmith, for example, wrote his excellent book Agile Project Management [Highsmith 2004a].

Scalability

XP was developed for the C3 project for Chrysler. It featured a small project team with a single customer. The XP practices alone are hard to scale to larger teams because (among many things) they do not offer any solutions to collaboration between teams, or as mentioned above, do not address any of the issues faced by non-software developers in the team.

Another aspect of scalability is a result of the fact that XP is primarily targeted at software developers. Because XP typically starts in software teams, change is attempted in a purely bottom-up way that can be transferred to other software teams but not through an entire organization without extra practices.

Pair Programming

Pair programming is presented as something that software developers absolutely must do. Yet, pair programming is hard: Either you are typing or you are watching someone else type, often poorly or slowly. The reader of the XP books is left with the impression that developers should pair program all day, every day. While pair programming can be very useful and productive, its use should be limited to what the people on the team are comfortable with. It certainly shouldn't be mandated.

What gets lost in the pair programming debate is that the intent of pair programming is to encourage collaboration between developers and to ensure that problems are caught as the code is typed. Essentially, by forcing pair programming, you force developers to collaborate with each other with the goal of building a team that collaborates by default, and in person not through e-mail or some other contrived means. There are other ways to achieve this same level of collaboration, and it's much healthier to encourage a range of collaborative practices than to mandate a single one.

The 40-Hour Week

The other practice that is often overzealously applied is the 40-hour workweek. I have read articles where XP teams were criticized because, instead of pushing to get a product out the door, they have insisted on working no overtime, and hence lack any sense of urgency. I also have spoken to people who claim to be using XP but work 80-hour weeks on a regular basis, which also isn't good.

The purpose of the 40-hour workweek is to get teams to work hours that allow them to stay sane and have a life outside work over the long term, measured in many months to years. This sense of balance is important to maintain a sustainable pace of development. The reality is that extra hours are going to be required on occasion, so the emphasis should be on the work/life balance over the mid to long term with a rational average number of hours per week worked. Reasonable working hours and avoiding burnout are a result of the focus on sustainable development, not the focus. Thus, sustainable development requires principles and practices that target sustainability and increasing capability over time.

The On-Site Customer

On-site customers are great if you can get them, or if you can work on your customer site where your customer is readily available. But what if your product has thousands of customers? Tens of thousands? Hundreds of thousands? What if your product sells to customers in many diverse vertical market segments, where each market has unique requirements? The bottom line is that in many cases it is impossible to have a true on-site customer. Many teams who try XP fail because they are unable to get over this hurdle, because XP and all the agile development techniques work best when there is a timely feedback loop between the customer and development team. Unfortunately, this is a rich enough topic for another book, but there are alternatives that are different from having an on-site customer but equally as useful. Just so you aren't left hanging, here are a few ideas:

• Learn about the field of usability or, even better, hire a usability expert or team. Usability professionals have a rich and diverse number of ways to test software with users and get the required feedback that agile teams need.

• Use the Internet to ship your software on a regular basis (daily or weekly) and get feedback from your customers so they can provide you with instant feedback and you can solve their problems in an optimal time. More on this in Chapter 4 on Working Software.

• Have a customer representative on your team. This person is a user of the product who spends a great deal of his or her time talking to and working with customers on real problems. These representatives funnel the feedback from customers into the team and give team members the feedback they need when they need it.

Self-Organization and Leadership

Many teams get carried away with self-organization and forget that there are often situations where people with specific roles are required. For example, it almost always makes sense to have a project leader to deal with the daily coordination and management of the project. Good project leaders (or coaches) are able to nudge teams forward, while helping them to make the right decisions and know the right decision when they see it. Pure democracy doesn't always work, and sometimes somebody needs to step forward and make a tough decision where there is no clear consensus, simply in the interest of keeping the project moving forward.

A related topic is that there is a general trend to shy away from the term leadership in XP. As explained in Chapter 8, leadership is a critical success factor in successful projects and is required at all levels of an organization. Leadership is not a top-down thing. It is required at all levels, and effective leaders lead their peers and their bosses, too.