Make haste slowly
Communicating Effectively in Rapid Development Software Projects
BY PAYSON HALL
In today's quick-paced workplace, software developers are confronted with a painful paradox: They face continual pressure to accelerate the development process, yet this need for speed results in communication failures—and the accompanying project and system development troubles. Because business imperatives won't change anytime soon, project managers on rapid development projects must redouble their efforts to communicate efficiently and effectively.
To some, rapid development refers to a collection of specialized software engineering practices—extreme programming (XP), rapid application development (RAD), rapid prototyping—intended to make conscious choices about trading reduced scope and additional resources for shorter development time. For others, rapid development is a catch phrase to sell tools, new methodologies or seminars—each promising to reduce software development cycle times. Whichever definition you prefer, schedule pressure can lead to disaster as teams cut corners and try to decide where to make concessions in hopes of achieving tight schedule goals.
“When I hear rapid development, I immediately think, ‘Here's a development team that's hoping to shortcut the laws of projects by skipping key steps,’” says Dave Ferguson, vice president of e-product development and implementation for DST Output in El Dorado Hills, Calif., USA. His organization's development practices place a strong emphasis on software engineering and project management.
Compressed development schedules and effective communication often seem like mutually exclusive concepts. But they don't have to be.
Asked to share rapid development insights, Bent Adsersen, independent Danish project consultant, offers the words of Roman emperor Augustus: “Festina lente”—Latin for “Make haste slowly.” Avoiding panic and the chaos it engenders is key. This involves taking the time to establish sound habits at the start of the project.
Compressed time frames strain communication. Graham Oakes, director of technology for Sapient Corp, London, U.K., suggests, “The communication issues [of rapid development] are all the same, but there's less margin for error and more opportunity for things to go wildly off course in a week.”
Oakes points out that teams under pressure often improperly sacrifice both processes and software deliverables for the sake of speed. “Tailor processes to the circumstances, but don't simply drop review and other quality assurance processes to save time,” he says. “Defects cost time.”
The baton frequently drops in the hand-off between the users and analysts who capture requirements and the designers and developers who interpret and implement them. “Be thorough when capturing requirements and assure that users are involved in design reviews,” says Mardell Hall, consulting project manager for Catalysis Group Inc., Sacramento, Calif., USA.
Specialized development processes benefit from improved communication between customers and developers. As Ken Pugh, software consultant from Pugh-Killeen Associates in Durham, N.C., USA, points out, “With XP, the customer must be on-site, so that the details of requirements can be explained as needed. If technical issues implementing a particular requirement become relevant, the customer and developer can work together to make tradeoffs in finding a solution.”
Unfortunately many project sponsors do not understand the discipline and resource commitments required to execute these processes successfully. XP is not an inexpensive way to build systems, but it can decrease development time if executed well. Making several knowledgeable customers integral members of the development team to facilitate communication is beyond the budget allocated to most projects—and the results are predictable.
“Many of the rapid methods try to gain speed by isolating the development team,” says Ron Thompson, director of product delivery for govONE Solutions in Englewood, Colo., USA. “The problem is the definition of ‘success.’ If success means delivering a system in the allotted time, many teams are probably successful. If success means delivering a useful system, success is probably spotty at best.”
Thompson suggests that building a common vision with the team is particularly important. “On long projects, it is necessary just to keep people excited. On rapid projects, it serves two purposes. The first is to maintain the morale of the team when they are working long, hard hours under poor working conditions. The second is to effectively keep the team working towards a common understanding of the end product. When people can ‘see’ this vision, it helps them understand how their part contributes (and when it is diverging from the target).”
The communication issues [of rapid development] are all the same, but there's less margin for error and more opportunity for things to go wildly off course in a week.
DIRECTOR OF TECHNOLOGY, SAPIENT CORP., LONDON, U.K.
Some basic guidelines for team formation and management that improve communication include:
■ Keep teams small. Four to five developers working on a well-defined subsystem streamlines communication.
■ Address problem team members promptly. Team members who cannot or will not work well as part of a team quickly become morale issues that cost more than they are worth.
■ Avoid “part-time” team members. Sharing team members with other projects guarantees people will be trying to accomplish too many jobs at once and assures that both projects will suffer. Try to get full-time commitment from team members for the duration you need them on the project.
■ Avoid adding developers to “fix” schedule issues. If the project is not performing to its schedule goals, avoid the quick fix of assigning additional people to an existing team. The overhead required to orient and assimilate a new team member rarely results in any short-term schedule improvement.
■ Co-locate teams. A development team should be located in the same building, on the same floor and in the same general area to facilitate team reviews and questions. A small meeting room for team use is a real plus.
RAD methods are frequently employed when requirements are unclear, and customer involvement also is critical to success in this case. “With RAD development, there isn't time or even sufficient knowledge to create a detailed requirements specification,” says Pugh. “The final product may be based on what is learned or created during the development process. Since the requirements aren't fixed, the developers and customers must work together to create the product.”
Rapid development methods themselves rarely lead to accomplishing work faster, according to Thompson. Instead, the parts of the system that deliver the most value are more efficient. “I think that people are missing the point when they treat rapid development as a technical exercise,” he says. “If you really look under the covers of any of the rapid methods, the emphasis is on time-boxing the work and controlling the scope to fit in the time-box. That can only be done by understanding the bigger picture and how this piece of work fits in and constantly communicating and setting expectations as the work uncovers issues that may threaten the time-box.”
The successes of rapid development methods can be attributed in part to small teams of developers and customers who are located at the same site and focused on the effort at hand—which naturally minimizes some of the communication challenges.
Deft and Deliberate
Work products like requirements specifications, architectural specifications and detailed designs are intended to record complex ideas so they can be reviewed for consistency and clarity, then communicated to others. When schedule pressure results in reduced clarity or content of the work products, misunderstandings snowball.
To avoid rework, resist pressure to get the developers working on the “easy parts” until the big picture is clearly defined, according to Robert Lew, an application development manager for the State of California in Sacramento. Describing a recent project to allow client data submission via the Internet that had a rocky start, Lew says, “Our biggest lesson learned is to take the time up front to develop the architectural specification so that when the system is subsequently partitioned, people are clear about the interactions among the parts.”
GET TO THE DATA POINT
There are so many options for communicating: long or short meetings, detailed or brief reports, daily or weekly get-togethers. With so much interconnected activity going on in unison, it can be challenging to get the right message heard by the team member who truly needs it.
For a “software-friendly” example, look at how technology processes data. On a noisy channel, smaller messages are more likely to get through but, for efficiency, must be balanced with the communications overhead of each transaction. Imagine a block of 100 data bits that must be sent and correctly received on a noisy channel that loses an average of 1 bit in 20.
Assume that sending a bit takes one second, and receiving confirmation takes 10 seconds, if you send the entire block, wait for acknowledgement and then resend if an error occurs, the probability of success for each message is 0.006 percent. The entire message might be sent more than 150 times before successfully received.
However, if you send one bit at a time and wait for confirmation, each message has a 95 percent chance of success. By sending 105 smaller transactions, you'll cut down on communication time.
Tuning data communications for optimum throughput involves adjusting the message size to be a balance between the noise on the channel and the overhead of sending a message. Changing the message size to 5 bits (about 75 percent chance of each packet getting through successfully) improves expected performance to 26 messages sent.
In the human world, this translates into frequent, short, narrowly focused communication.
While it takes discipline, it is essential to take the time at the outset to document agreements on development processes and quality criteria for deliverables and resist the temptation to declare a deliverable “complete” until the quality criteria have unambiguously been achieved.
Sapient's Graham Oakes has had the most rapid development success when making conscious decisions about communication and planning. To gain an advantage, he advocates:
■ Structured Plans. Daily progress meetings work only if they're reporting progress against a well-defined plan. Weekly status reports follow well-defined structure so they can be written quickly without forgetting key issues
■ Extreme Visibility. Sapient employs a project war room with all plans—top-level, mid-level and a day-by-day micro schedule, risk lists, overall project objectives, to-do lists with owners and deadlines and progress metrics—highly visible and easily accessible
■ Frequent, Brief Communication. Sapient uses daily stand-up progress meetings—no more than 15 minutes—in which each member details progress against the micro schedule
■ Clear, Common Goals. People will make a lot of decisions on the fly, but they must know how their piece of the project puzzle ties into the overall objectives. One of the biggest communication challenges is building and sustaining an understanding of the development process among key stakeholders and sponsors. Providing understandable and visible milestones during development is key so that sponsors and stakeholders get a sense of progress. This in turn helps to manage their expectations and facilitates communication about issues and schedules. PM
Payson Hall is a consulting systems engineer and project management consultant from Catalysis Group Inc., Sacramento, Calif., USA. Hall has worked hardware and software systems integration projects in both the public and private sectors throughout North America and Europe during his 20-year career.
When I hear rapid development, I immediately think, ‘Here's a development team that's hoping to shortcut the laws of projects by skipping key steps.’
VICE PRESIDENT OF E-PRODUCT DEVELOPMENT AND IMPLEMENTATION, DST OUTPUT, EL DORADO HILLS, CALIF., USA
PM NETWORK | AUGUST 2002 | www.pmi.org
AUGUST 2002 | PM NETWORK