Grace Under Pressure

Fear causes uncertainty and stifles communication, breeding distrust and inefficiency—a disastrous combination. Savvy survival skills replace fear with team spirit and productivity.

By Ulla Merz

At the software start-up company where I served as project manager, the push to achieve the impossible was a given. Competitors were breathing down our necks, a key customer was in close range, the product team kept defining more and more features—and the developers had just three months to complete the project.

Stuffing the Suitcase
The high-pressure schedule made me feel like I was trying to close an overstuffed suitcase with broken buckles as I attempted to accomplish all the work necessary. Although I pointed out bottlenecks in the schedule and noted the many components that required interfaces and integration, my words went unheeded. I recommended packing light—or buying a bigger suitcase with sturdy buckles that could accommodate a longer journey. Instead, the suitcase was stuffed full and taped precariously shut—the project received the green light to embark on its aggressive schedule.

As a project manager working on many breakneck projects throughout the past few years, I've seen the gap between goal and reality widen: Of late, a deadline-driven culture that dictates product requirements without any compromises has emerged, resulting in extreme schedule pressure that can sometimes seem unbearable.

Overtime Isn't the Answer
Although a degree of schedule pressure can serve as a stimulus to project development, at its extreme, it can lead to chaos. The typical response, "Circle the wagons and work gobs of overtime," can actually cause the slowdown it aims to avert. Despite weekend and late-night hours, workers still repeatedly fail to complete assignments as expected. Project team managers and members alike report that excessive, enforced overtime brings out the worst in people: In the office, communication breaks down, becoming abrupt, tense or overbearing; work gets sloppy; and morale plummets. The team dynamic can disintegrate, with workers taking on the role of solo fighters focusing on individual survival rather than the project goal. On a personal level, family time is compromised. And, paradoxically, I've heard software professionals say that "things slow down as a whole" when the project is in crunch mode.

Seeking Solutions
Let's face it: Extreme schedule pressure is here to stay, and you're wasting your time looking for a silver bullet. But managers can help their teams survive and even increase productivity without resorting to enforced overtime.

From my shared experiences with other project managers, software engineers and testers, I've developed these four stress survival strategies:

• Develop and follow humane principles for maintaining perspective, team unity and project momentum under pressure.
• Try pair programming.
• Facilitate consistent decision-making throughout the project team.
• Practice disciplined testing.

Each strategy can provide a practical "How-To" for coping with extreme schedule pressure—and surviving.

Attitude Is Everything
Extreme schedule stress can create crippling fear: fear of not being in control; not knowing the road map; not being able to handle the demands; not being respected for personal decisions. But the adage "Attitude is everything" has more than an element of truth. Even in the pressure cooker, a manager can instill a positive attitude by giving team members confidence in their abilities. Repeated reminders of past accomplishments, what can be done and the goals that need to be achieved can diminish a team's stress and increase confidence, causing the team to gel instead of splinter.

Celebrating ongoing individual and team achievements can help to engender a positive attitude throughout the project, spurring the team to greater speed and efficiency. The celebration may be an afternoon at "Laser Storm" with the team, a day off or a dinner for two. However brief, any activity that recognizes accomplishments and employs an element of play can lend a relaxed, productive tone to an otherwise stressful schedule.

Dynamic Duos
No one would deny that a positive attitude encourages efficiency, but some may wonder whether pair programming can improve the productivity of the engineering team, especially when they're working under schedule pressure.

Pair programming doesn't mean that one engineer programs while the other twiddles his thumbs. Rather, the engineer who isn't coding complements the other developer by thinking at a different level of abstraction, keeping the big picture in mind and preventing syntactical errors from creeping in.

Programming is an exhausting intellectual activity that requires intense concentration, which most people simply can't sustain at an optimal level for eight hours at a time. By switching duties and working in pairs, people can get more done. As Kent Beck notes in his book, Extreme Programming Explained (Addison-Wesley, 1999), pair programming offers the following benefits:

• Fewer bugs at the unit level.
• Reduced likelihood of integration bugs.
• Reduced risks due to fewer single points of knowledge failure.
• Cleaner code (due to the "performance factor").
• Greater mentoring and learning.
• Uniformity of coding style.
• Increased likelihood of reuse of existing components.
• A culture of shared responsibility.

I've experienced excellent results when pairing engineers with different skill levels. This is especially true when the senior engineer not only contributes technical knowledge, but also imparts a positive attitude and an interactive, Socratic teaching style of questioning and guidance.

Pair programming can go far to mitigate common problems that arise from extreme schedule pressure, such as miscommunication and rework. And, because pair programming can weed defects from the product in the early stages of development, it relieves schedule pressure from downstream activities, such as integration testing and functional testing.

Consistent Decision-Making
Under extreme schedule pressure, daily work goals are vastly accelerated. As a result, each team member must make more decisions, more frequently. Sometimes the only decision-making guidance that team members receive is the flat statement: "Development speed is the primary goal." The particular interpretation is left up to each team member.

The following strategies can give team members a wider perspective to help them make decisions that are consistent with the project's goal, its scope and management priorities:

• Create and follow guidelines for the development process.
• Use top-down communication to get the message out.
• Use bottom-up communication to validate that the message arrived.
• Get assistance with issues and questions.

If team members follow an official or de facto development process that defines deliverables, the sequence of activities, and roles and responsibilities, these guidelines can help them interpret management priorities and directives. Development guidelines (such as checklists and procedures for delivering source code to the source code base) reduce the number of decisions that must be made.

Getting the message out is not a one-time event; rather, it's a "top-down" process, as each message must be tailored to each recipient's perspective in order to ensure effective communication among all team members. For example, to reach a common understanding of the project's requirements, team members must conduct many meetings in which the requirements will be clarified, refined and annotated—and new requirements will surface. Follow-up communication is facilitated with documents, further project meetings, e-mail, information shared on the project Web site and one-on-one problem-solving sessions.

As schedule pressure increases, it becomes increasingly important to maintain effective communication. "Bottom-up" strategies to make sure that all participants are on the same page include engaging team members one-on-one with open-ended questions, such as "How is the test environment working for you?", "How is the Java conversion effort going for you?" or "How does this feature fit into the priorities?"

Even with effective top-down and bottom-up communication, team members will have ongoing questions about issues such as design, work priorities and the interpretation of requirements. Anticipate these questions and provide assistance—or at least make sure your team has access to those who do know the answers. For example, individual decisions will be more consistent if a chief architect is available to discuss and review design issues. A product manager or change control board will guarantee consistency by clarifying and approving requirements. A project manager will ensure that the ongoing work is consistent with the project's goals and its scope.

Testing Under Pressure
If the schedule is aggressive for the developers, it will be even more aggressive for the testing organization. Unfortunately, a delay in development rarely results in an extension of the project's completion date.

The role of testing is not only to test the product, but, more importantly, to ascertain and communicate the product's status under development. Testing is the first time that accurate statements can be made about the completion status of a software system, based on the reports of which functions are ready to be tested, which functions work according to the requirements—and which ones don't.

Under schedule pressure, it's crucial that testers communicate every piece of information they know about the system. They need to describe what they did and what they saw, and to clearly communicate their testing plans to the development team and their managers. After all, reported defects drive both project development and management decisions.

Though testers often sacrifice testing thoroughness (both coverage and depth) under schedule pressure, the importance of repeatable tests increases under schedule pressure. Producing written test procedures, applying configuration management to data files, configuration files and environment variables, and practicing configuration management of source code become crucial elements in an accelerated project schedule. Repeatable tests identify defects and verify that they have been repaired. They also make it possible to justify adding more personnel to the testing effort.

Getting help from the development department expands testing resources. Developers generally don't require any start-up training and learn easily from examples.

Time for Quality
One of the engineers with whom I discussed this topic noted my focus on aggressive deadlines and raised an interesting question: "How about aggressive quality goals?" What if meeting the deadline isn't the only success factor—what if quality is part of the measure of success? What would happen if companies used their own software products in their daily operations and were their own beta customers for the new product release?

With a focus on quality rather than mere completion, I'm convinced that the economic considerations that govern software product releases would change. Time and effort devoted to testing would not be slighted, and developers would have more time to review design and source code. Holding those who dictate aggressive deadlines accountable for quality measures, such as defects found in the field, staff turnover rate and scheduled rework incurred in the following release, would provide the checks and balances necessary to foster an environment that encourages superior software development.

Strategies, Not Silver Bullets
After barely avoiding chaos, we looked for ways to pack the suitcase more productively. Continual top-down and bottom-up communication gave us improved schedule adherence. Pair programming brought several benefits: First and foremost, working in pairs made the engineers dive deeper into problems and notice early warning signals about technically tough issues. Engineers were also less likely to head in the wrong direction, so less rework was needed. Two minds are more likely than one to raise questions and resolve unknowns with the rest of the team.

Until corporate focus shifts from speed to quality, accelerated schedule pressure will persist. Unfortunately, common suggestions such as walking away from the project, renegotiating the schedule or educating management are not always feasible or effective responses to extreme schedule pressure. You may not get that larger suitcase you asked for, but you can make sure that the duct tape holds. With discipline and commitment to the work strategies noted above, you can build team spirit, maintain momentum and increase productivity, even under extreme schedule pressure.

Pressure Principles How to stay cool when the heat's on Do it the right way the first time. Settling for less will probably cause rework, slowing the schedule's momentum and delaying the project. Doing it right later is sometimes not an option. Use known processes and procedures. In the face of time pressure, it's better to rely on what people know rather than introducing something new, even if the innovation may appear to be a better option. However, without a process in place or past experience to rely on, a new process is better than none. Eliminate negative influences quickly. Don't let someone's bad attitude spoil a positive ambience. Set the bar high. Appeal to people to stretch beyond their comfort zone; their reward will be professional growth and accomplishment. Let technical leaders define processes and mentor others. Relying heavily on the senior engineers alone to carry the torch places an undue burden on them, leading to burnout. Foster trust; encourage team members to help each other. Remember that the development process is expedited and enhanced by the collective synergy of a dynamic team.

---