Notes on XP and teams

See AutreachIT ASK project and ASK: The development team for information about the project that these notes have been prepared for.

Contents of this page

About XP teams  

The following extracts are taken from The XP Team and Is XP Right for Us? in The Art of Agile Development [1]

The full text can be read online. There are comments on these extracts by ASK team members which can be read by signing in to this page.

The minimum team

“XP teams can be as small as one experienced programmer and one product manager ...”

Product Manager

“The product manager only has one job on an XP project, but it’s a doozy. That job is to maintain and promote the product vision. In practice, that means documenting the vision, sharing it with stakeholders, incorporating feedback, generating features and stories, setting priorities for release planning, providing direction for the team’s on-site customers, reviewing work in progress, leading iteration demos, involving real customers, and dealing with organizational politics.”

If Your Product Manager is Inexperienced…
“This may be okay as long as she has a more experienced colleague she turns to for advice.”

If You Can’t Get a Product Manager At All…
“Although good product managers are in high demand, the absence of a product manager is a big danger sign. The right person for the job may not have the title of “product manager” (see Real Customer Involvement in Chapter 6), but XP requires that somebody with business expertise take responsibility for determining and prioritizing features. ... If you can’t find a product manager, someone from the development team can play the part. However, this may be a dangerous approach, because this person is unlikely to have the business expertise to deliver an organizational success.”

Programmers

[XP calls all developers programmers.]

“Programmers rely on customers for information about the software to build. Rather than guessing when they have a question, they ask one of the on-site customers. To enable these conversations, programmers build their software to use a ubiquitous language. They assist in customer testing by automating the customers’ examples.”

If Your Team is Smaller Than Four Programmers…
“Most of the XP practices are still appropriate for you, ... In this situation, it’s best if your team members are conscientious programmers who are passionate about producing high-quality code. ...
You may have trouble getting on-site customers to sit with you full-time. Instead, sit close to them so that you can get their attention when you need it.”

If You Have Many Developers Working Solo…
“Some organizations—particularly IT organisations— … structure their work to assign one programmer to each project. Although this approach has the advantage of connecting programmers directly with projects [there are risks and challenges] ...”

On-Site Customers

“On-site customers—often just called customers—are responsible for defining the software the team builds. The rest of the team can and should contribute suggestions and ideas, but the customers are ultimately responsible for determining what stakeholders will find valuable.”

“On-site customers may or may not be real customers, depending on the type of project. Regardless, customers are responsible for refining their plans by soliciting feedback from real customers and other stakeholders.”

“As long as somebody is playing the on-site customer role, you can use XP. However, the less expertise your on-site customers have, the more risk there is to the value of your software.”

This quote is from Fooling Around with XP, an article by Michele Sliger, a professional software project manager who became an XPM [XP Product Manager] and is the author of The Software Project Manager’s Bridge to Agility [2]

“Maybe the hardest change to accept is that, for an XPM , the focus is on the business client and not on the developers. On a daily basis, 80 percent of my time was spent with clients—teaching them the fundamentals of XP, showing them how to write user stories, reminding them of our iteration agreements and prioritizing (and removing) work accordingly, and facilitating their discussions with the development staff.
The programmers, on the other hand, didn’t need me to assist them … they needed only gentle reminders of our ultimate goal versus our iteration goal, and daily assistance with the corporate red tape. I didn’t fill out a Gantt chart … I didn’t assign resources to tasks … I didn’t type up weekly status reports … “

Team Empowerment at www.extremeprogramming.org discusses leadership and management and the different responsibilities of customers/ product owners/ team members in agile teams compared with traditional development teams.

From Agile Projects: Managing with a Light Touch :

“Most project managers work in companies that have some form of hierarchical organization. Organizational hierarchies extend into our project teams as well, along with modern, subtle forms of command and control. For example, in many of our organizations, team members are still required to perform tasks specifically assigned to them by their project managers without advance consultation. In the more egalitarian of these organizations, team members may be consulted by the project manager; but in the end, the assignment of work still happens in a top-down fashion. In other organizations, the hierarchical control lies with someone other than the project manager—perhaps a line of business manager. In this case, the project manager’s responsibilities are reduced to the administration of the project schedule and lots of coordination among multiple groups, but these responsibilities come with very little influence over the teams they are supposed to be managing. Top-down decisions are still made, but by the line of business manager, not the project manager or the team. [an alternative is] the organic complex adaptive systems (CAS) model as the preferred alternative for agile teams with highly skilled members whose primary charter is to deliver customer value. ... But the question of control remains unanswered—how are agile managers supposed to control their teams that are organized according to the organic CAS model?
The objective of the Light Touch practice is to manage agile teams with a style that allows team autonomy and flexibility and a customer value focus without sacrificing control. The activities associated with this practice carry the following implications for agile managers:

  • Establishing decentralized control that defers decision making for frequently occurring, less critical events to the team
  • Managing the flow of customer value from one creative stage to another
  • Recognizing team members as whole-persons and treating them accordingly
  • Focusing on strengths rather than weaknesses to leverage people’s uniqueness

These quotes are from Extreme Programming Explained [3], chapter 4 (much abbreviated). For another short statement of the values see The Values of Extreme Programming at www.extremeprogramming.org

Communication

What matters most in team software development is communication. ...

Communication is important for creating a sense of team and effective cooperation. Communication, though, is not all you need for effective software development…

Simplicity

Simplicity is the most intensely intellectual of the XP values. To make a system simple enough to gracefully solve only today’s problem is hard work. ...

The values are intended to balance and support each other. Improving communication helps achieve simplicity by eliminating unneeded or deferrable requirements from today’s concerns. Achieving simplicity gives you that much less to communicate about.

Feedback

No fixed direction remains valid for long; ... Directions set in advance of experience have an especially short half-life. Change is inevitable, but change creates the need for feedback. ...

Feedback is a critical part of communication. ...Feedback also contributes to simplicity. ... the simpler the system, the easier it is to get feedback about it.

Courage

... Courage as a primary value without counterbalancing values is dangerous. Doing something without regard for the consequences is not effective teamwork. ...

If courage alone is dangerous, in concert with the other values it is powerful. The courage to speak truths, pleasant or unpleasant, fosters communication and trust. The courage to discard failing solutions and seek new ones encourages simplicity. The courage to seek real, concrete answers creates feedback.

Respect

The previous four values point to one that lies below the surface of the other four: respect. If members of a team don’t care about each other and what they are doing, XP won’t work. If members of a team don’t care about a project, nothing can save it.

Every person whose life is touched by software development has equal value as a human being. No one is intrinsically worth more than anyone else. For software development to simultaneously improve in humanity and productivity, the contributions of each person on the team need to be respected. I am important and so are you.

Primary Practices (Extreme Programming Explained [3], chapter 7)

  • Sit Together
  • Whole Team
  • Informative Workspace
  • Energized Work
  • Pair Programming
  • Stories
  • Weekly Cycle
  • Quarterly Cycle
  • Slack
  • Ten-Minute Build
  • Continuous Integration
  • Test-First Programming
  • Incremental Design

References  

1 The Art of Agile Development James Shore and Shane Warden, 2007

2 The Software Project Manager’s Bridge to Agility Michele Sliger and Stacia Broderick, 2008

3 Extreme Programming Explained, 2nd edition, Kent Beck with Cynthia Andres, 2005