5 Lessons from Transitioning to eXtreme Programming

KEY WORDS

Software for control

Software programming

Control architectures

Open standards

SIDEBAR: How XPs 12 practices impact human and technical issues

It may be a software development method that many people haven’t encountered before, but Citect, located in Gordon, Australia, a suburb of Sydney, recently succeeded in implementing eXtreme Programming (XP).

Observing the current activity in Citect’s software development area yields some unusual impressions about XP. Initially, the activity seems open and noisy. Six programmers may stand at one of many whiteboards, discussing a design issue, and adding ideas and input. Then they will break into pairs to work at computers with large monitors. One person, called the driver, takes a turn writing code, while the other person, called the navigator, watches, makes notes, and sometimes interrupts his or her friend to suggest a change, or even a whole new approach, to the module on which they are working.

Chaotic, but effective

This type of paired programming isn’t the norm in the programming field. However, in an XP environment, switching between driver and navigator can take place every hour. This may not seem like an effective way to develop software, but Citect has found that the XP method can help develop programs robust enough to cope with some of the world’s largest real-time, supervisory control and data acquisition (SCADA) sites.

As a published method, XP and its practices can be traced back to 1999. Historically, XP is a software development method within the Agile Development group of methods, and it focuses on quality, responsiveness to change, and speed to market. XP is based on four values: communication, simplicity, feedback, and courage. In addition, XP promotes a set of 12 development practices (see table).

One team at Citect started XP as a trial in late 2001, and the method was expanded across Citect’s Product Development Group in April 2002. The change was massive, fundamental, and sometimes painful, but the group and Citect emerged as an agile software development organization. In the transition process, Citect developed some lessons learned about XP that had a significant positive impact.

LESSON

1: XP is a philosophy, not a religion

Programming begins with a ”story,” defined in the language of XP as a functional requirement. Though brief, these stories are part of how XP works by having the customer omnipresent. As a result, details get filled in along the way with tight interactions between the customer and developers.

XP programmers then use then use 12 development practices to design and implement useful solutions. For example, one of the most important practices is #4, Simple design, which answers the question, ”What is the simplest thing that could possibly work?” Another is #6, Refactoring, which sorts out revisions later in the XP process.

However, because it can be easy to get carried away in a religion of methodology, XP encourages participants to retain common sense. In XP, ”simple” means not designing for requirements that may never arise, but if you already know the need, then a few hours of extra design now could save several days of rework later.

LESSON

2:
Philosophy doesn’t replace good management

Because XP is so agile and able to change to meet customer needs, the rate of change can be high. This should not mean a hands-off approach; it does require increasing change-management efforts. Sound project management practices may need a little bending and adapting, but they are still required to keep stakeholders from getting too nervous; to keep change from becoming uncontrolled; to maintain focus on the end game; and help to manage risk, cost, quality, and scheduling.

LESSON

3:
One size does not fit all

XP methodology also includes daily meetings held while participants are standing up. These end with a round of hand clapping, which may or may not transpose neatly across cultures. Some developers take to the idea, while some resist such an emotional display.

LESSON

4:
Human issues dominate the choice of XP change agent

If you decide to adopt XP, understand there will be pain, mostly centered on people, rather than technology. While XP is mostly driven by senior technical people, implementation should be supported by a human resources (HR) expert because many of XP’s key change-management issues include team skills, consensus decision-making, assertiveness, and other soft issues.

LESSON

5:
: Creating collective code ownership

In the past, programmers on a development team had no ownership of the code. Anyone could change code at any time. While this allowed flexibility, it also created unstable code. Moving to individual code ownership resulted in more stable code, but lengthened development schedules and added bureaucracy.

XP promotes Collective Ownership. The team owns the entire code base, and any pair of programmers is encouraged to improve any code if it makes their life easier now. Given that we have a pair making the change-and that communication is open and fast-quality, agility, and stability can be attained.

XP benefits for Citect

Citect embarked on the XP path as an early adopter, and found that its key benefits include:

Communication levels within and across teams are fast, effective, and responsive to changing customer needs.

Cost of ‘quality lines of code’ is reduced. Given the high cost of paired programming, this seems counterintuitive, but the pair keeps each programmer’s code honest, which means code quality is improved; they maintain a cracking pace, which means output is improved enough to justify the pair’s doubled overhead; and the process aids fast decision-making for improved effectiveness.

Team empowerment, and associated consensus decision-making, reduces rework caused by myopic design decisions.

The test-first code development is hugely worthwhile, even if you don’t implement other XP practices. Confidence in functional and system reliability improves dramatically.

If your customers find it hard to say what they want until they see something working; if you are concerned about quality levels; or if you need to develop a more customer-focused development group, then XP and Agile Methods in general are worth investigating to see how they might work in your culture.

-Comments? E-mail jmontague@reedbusiness.com .

For more about XP, visit www.extremeprogramming.org/index.html . For more about Citect, visit www.citect.com .

How XP’s 12 Practices Impact Human and Technical Issues

XP practice
Human impact
Technical impact

1.
The planning game
X
X

2.
Short releases
X

3.
Metaphor
X

4.
Simple design
X
X

5.
Testing
X
X

6.
Refactoring
X
X

7.
Pair programming
X

8.
Collective code ownership
X

9.
Continuous integration

X

10.
40-hour week
X

11.
On-site customer
X

12.
Coding standards
X
X

Impact totals
11
X

Source: Control Engineering, with information from Citect

The 12 practices of eXtreme Programming affect an organization’s human and technical arenas, but most practices have an impact on human issues

Author Information

John McMahon, CPA, PMP, general manager, Citect Product Development Group

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.