5 Lessons from Transitioning to eXtreme Programming

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.




  • Software for control

  • Software programming

  • Control architectures

  • Open standards

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.


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.



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.



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.



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.



: 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


The planning game




Short releases






Simple design












Pair programming



Collective code ownership



Continuous integration



40-hour week



On-site customer



Coding standards



Impact totals



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

No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Controller programming; Safety networks; Enclosure design; Power quality; Safety integrity levels; Increasing process efficiency
Additive manufacturing benefits; HMI and sensor tips; System integrator advice; Innovations from the industry
Robotic safety, collaboration, standards; DCS migration tips; IT/OT convergence; 2017 Control Engineering Salary and Career Survey
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
This article collection contains several articles on how automation and controls are helping human-machine interface (HMI) hardware and software advance.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Infrastructure for natural gas expansion; Artificial lift methods; Disruptive technology and fugitive gas emissions
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Jose S. Vasquez, Jr.
Fire & Life Safety Engineer; Technip USA Inc.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me