Home > Articles > Software Development & Management

Extreme Programming Practices in Action

Stewart Baird
  • PrintPrint
  • Share ThisShare This
  • DiscussDiscuss
Extreme Programming (XP) is built on 12 key practices. This lesson describes how XP takes best practices and combines them to achieve quality results.

40-Hour Work Week

In XP, development is high in communication and boasts impressive speed. Developers are working in an environment where the stress of change is ever present. Working on XP projects means consistently driving quality and performance throughout the life of the project. How do you maintain quality with overtime-heavy teams? The answer is you can't; defect rates begin to climb, tempers flare, and communication deteriorates. Remembering that an XP core principle is that quality of work can never be compromised, we're going to have to control how many hours developers clock and still maintain high standards.

In the IT industry, workers are increasingly busy and the important is being squeezed out by the urgent. How much of your average day is spent on trivial issues, wading through broadcast emails, and interminable meetings? If energy could be directed exclusively toward the project for eight hours per day, ignoring anything outside of the project, 40-hour work weeks could be successful.

Sustainable Working Hours

The idea of the 40-hour week is that team members should work the hours that they can sustain quality. Sustainable workload could be 40 hours or thereabouts. Each country or culture has differing acceptance of reasonable working hours. The important thing is to recognize what a reasonable work week should be, and then come to an agreement with the team on that number. Tremendous power comes from committing to this up-front and then having the integrity to follow through during crunch time.

Exposing the Overtime Black Market

Establishing a policy of sustainable hours also removes the "black market" in project time. This refers to the very dubious practice of price-fixing the contract (effectively locking the team into charging no more than eight hours per day) while still allowing management to lean on the team to work extended, unpaid hours. For those employees paid on a salary, they are losing personal time for no reward.

Long Term or Short Term

Studies have shown that productivity can actually improve when working between 60–80 hours per week. Younger team members can sometimes be more easily encouraged to work excessive overtime. Youth and enthusiasm enables them to survive this extra work in the short-term and management can view them as expendable. Working after hours with similar die-hard colleagues also lends to the general atmosphere of life on the edge. Senior players who've seen it all before have probably gone home while these volunteer overtime workers continue development. The next day is often spent in rework and recovery from the previous late night. Figure 6.2 shows the increased productivity with increased overtime.

Figure 6.2 Productivity increases over time.

So, short-term gains are possible from working teams harder, but what are the longer-term impacts? Longer working hours over a prolonged period is going to result in staff turnover and poor quality. Exhaustion in an XP team breeds crankiness and irritability, and keeping communication open and positive with your customer will become impossible. If we are using the other XP practices and spending our day on what we know is important and solving problems simply, why would we need more than eight hours per day?

  • Share ThisShare This
  • Your Account

Discussions

Make a New Comment

You must log in in order to post a comment.

Related Resources

Danny KalevMinutes from the October 2009 Meeting
By Danny Kalev on November 19, 2009 No Comments

The minutes from the Santa Cruz (October 2009) meeting are available here. Even if you're not a language layer at heart, I encourage you to read them.

Danny KalevA Reader's Opinion on Attributes
By Danny Kalev on October 20, 2009 No Comments

In August I dedicated a series to the debate about C++0x attributes. I believe that it covered the subject in a balanced and detailed way, but I keep getting complaints from C++ users who don't like attributes for various reasons. Here's a recent email I received from a Polish C++ programmer. While it  doesn't represent my opinion about attributes -- I'm rather neutral about this feature and consider it a "solution waiting for a problem" -- but it suggests that attributes are still a highly controversial issue that will haunt C++ for a long time. The email is quoted here with minor edits that and as usual, with all private details removed.

Danny KalevFollowup: The Web 2.0 Guy I Ain't
By Danny Kalev on October 16, 2009 1 Comment

Almost a year ago, I posted here The Web 2.0 Guy I Ain't. People wonder whether I still resist all those Web 2.0 features and technologies at the end of 2009.

See All Related Blogs

Informit Network