Light methodologies make the most of team members' time and skill

The trend toward more nimble light methodologies emphasizes the importance of individual team members. First of all, light methodologies stress creativity and self motivation. Clearly, teams that want the kind of quick response that these approaches promise must have members who are open minded and flexible to change.

Developers who work in this fast-changing environment must also be dedicated, motivated, and focused. If you have a history of missing deadlines, poor self-organization skills, or a penchant for complaining, you’ll have a difficult time working in this environment.

I’m not saying that light methodology developers must be brilliant and be able to program circles around all other coders. However, you must be willing to learn and adjust to thrive in this rapid, iterative world.

Work at a pace that can be maintained indefinitely
Many of us have been on the proverbial project from hell—get ready for lots of overtime to make up for poor estimations, bad project management, or unrealistic deadlines. Light methodologies, with their focus on individual team members, don’t have a place for these runaway projects.

Instead, the light processes require you to maintain a steady pace that keeps everyone on the team busy and challenged, but requires only a standard workweek. Balance between work and personal lives is key to the light methodologies. The theory is that heavy overtime quickly reaches the point of diminished returns. Working 50 hours will usually result in more work getting done that in a standard 40-hour week; working 60 hours may result in only a marginal increase in work from what you would accomplish in 50 hours.

Light methodologies recommend a 40 to 45 hour workweek. If you’re on a project that creates iterations on a weekly basis, you should be able to maintain the weekly iteration pace for years. If you have to work extra hours for a short period of time, the goal is to quickly move back to the equilibrium point that you can maintain indefinitely.

Pair programming
One of the most interesting people aspects of light methodologies is that programmers often work in pairs. This is not necessarily a specific feature of all light methodologies, but it is a focus of the Extreme Programming approach. On the surface, this seems counterintuitive to most programmers. After all, isn’t programming the bastion of the lone wolf? The typical programmer receives design specs or business requirements and then sits down at the terminal to code, code, code.

In Extreme Programming, all software is built using programming pairs (or design pairs) who sit side-by-side. One programmer writes code, and the other programmer watches and provides immediate feedback on overall design and accuracy. When one programmer gets fatigued, the other steps in and continues to write, with the first programmer now in the review role. The advantages include the following:

• Coding errors are caught immediately.
• If one programmer has misinterpreted the requirements, the second programmer can catch the error. If the pair can’t agree on what the requirement is, the customer can be brought in immediately for clarification.
• Between the two programmers, coding can continues almost nonstop over the workday.

The overall thinking is that two programmers working in tandem are more productive than two individuals programming independently. This concept is probably the most controversial aspect of Extreme Programming. Initial studies seem to confirm that pair programming does indeed work, although there needs to be much more evidence and exposure before this concept will move into the programming mainstream.

If you are a senior developer, you need to exercise patience if paired with a less experienced colleague. Paired programming provides a great mentoring opportunity. Last but not least, you must be able to trust a developer who codes slightly differently than you do. If you are accustomed to being a lone wolf, this will be a major adjustment.

A matter of trust
One of the basic constructs of light methodologies is that the company takes flexible and motivated people, puts them in an environment where they can be successful, trusts them to get the work done, and then lets them go. This is a large leap of faith for many organizations. In fact, the historically poor success rate of just turning people loose created the more rigorous and disciplines processes in place today in many companies.

This level of trust can be controversial in many organizations. But just because your organization is skeptical does not mean that you should not try light methodologies. Many early adopters of pair programming and steady-paced development have reported initial success. If you try this aspect of light development, make sure that the pilot team has the right skills and open-minded attitude to validate the benefits and weaknesses of the approach in your organization.