In today’s fast-paced workplace, software developers and project managers are confronted with a painful paradox. They are faced with continual pressure to accelerate the development process, but this “need for speed” can result in communication failures—and the accompanying project and quality problems.

Business imperatives are unlikely to change any time soon, thus project managers must redouble their efforts to maintain efficient and effective communication.

Agile: Solution or Snake Oil?
One of the first communication issues to address is the meaning of the phrase “agile development.” To some, “agile” refers to a collection of specialized software engineering practices (XP, RAD, SCRUM, rapid prototyping) intended to make conscious choices about trading reduced scope and additional resources for reduced development time. For others, agile is a catch phrase to sell tools, new methodologies, or seminars—each promising to further reduce software development cycle times. Whichever definition you prefer, schedule pressure can lead to disaster as teams cut corners and try to decide what not to do in hope of achieving tight schedule goals.

Cautious Hand-Offs
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. A public sector project my wife recently managed was for a client department that had specialized vocabulary about its business administering claims against the government and administrative hearings to adjudicate those claims. The client purchased an off-the-shelf case management system typically used by law firms. During a design review of workflow customization she discovered that some of the terms used by the client were similar to terms used by lawyers, but different in some critical ways initially misunderstood by the vendor. Extensive and ongoing user involvement was essential to identify and resolve these issues before costly implementation mistakes.

Specialized development processes generally benefit from improved communication between customers and developers. As Ken Pugh, software consultant from Pugh-Killeen Associates in Durham, North Carolina points out, “With agile, the customer needs to be available so that the details of requirements (stories) can be discussed and explained. If technical issues implementing a particular requirement become relevant, the customer and developer can work together to determine the solution.” 

Unfortunately, project sponsors often do not understand the discipline and resource commitments required to execute these processes successfully. Agile is not a cheap way to quickly build systems, but it can decrease development time if executed well. Making sufficient, knowledgeable customers integral members of the development team to facilitate communication exceeds the budget allocated to many projects, and the results are predictable.

The emphasis of agile methods is on timeboxing the work and controlling the scope to fit in the timebox. This 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 timebox. 

The successes attributed to agile methods can often be traced to small teams of developers and customers who are co-located and focused on the effort at hand, which naturally minimizes some of the communication challenges. The speed improvement doesn’t come because programmers type faster, but because each keystroke is more useful and results in fewer errors to correct.

Better, Cheaper, Faster
To many, agile development means tying to deliver software under ever tighter time constraints. Asked to share agile insights, Bent Adsersen, independent Danish project consultant offers the words of Roman emperor Augustus: “Festina lente”—Latin for “Hurry slowly.” Avoiding panic and the chaos it engenders is key. For Adsersen, this involves taking the time to establish sound habits at the start of the project. He encourages taking the time to establish cultural norms from the outset that make solid, frank feedback both acceptable and appreciated.

Compressed time frames strain communication. Graham Oakes, a software consultant in London suggests, “The communication issues [of agile] are all the same, but there's less margin for error and more opportunity for things to go wildly off course in a week. To paraphrase Bent, to move faster you have to move slower—take time for regular, small communication sessions so you can steer.”

Stay the Course
Oakes points out many software development practices that improve the quality and timeliness of communication as well as software work products often are improperly sacrificed for the sake of speed by teams under pressure. “Tailor processes to the circumstances, but don’t simply drop review and other quality assurance processes to save time,” Oakes warns. “Defects cost time.”

Some “Legacy” Work Products Aren’t Foolish
In my experience working on large projects, 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 clearly communicated to others. When schedule pressure results in reduced clarity or content of these work products, misunderstandings are propagated forward and snowball.

While it takes discipline, it is essential to take the time at the outset to get 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.

Deft and Deliberate
Oakes reports the most success when making conscious decisions about communication and planning. To gain an advantage, he advocates:

• Structured work. Daily progress meetings are only effective if they’re reporting progress against well-defined expectations. Weekly status reports should follow well-defined structure so they can be written quickly without forgetting key issues.
• Extreme visibility. Plans, goals, metrics and issues should be highly visible and easily accessible to the team.
• Frequent, brief communication. Conduct daily standup progress meetings—no more than fifteen minutes—in which each member details progress against the micro schedule or backlog.
• 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.

Team Communication
When mistakes are expensive and time consuming, consider some basic guidelines for team formation and management to improve communication:

• Keep teams small. Having 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 thrash and assures that both projects will suffer. Try to get full-time commitment from team members for the duration of their need 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 whenever possible. 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. Virtual teams introduce avoidable communication barriers.

Sponsor and Stakeholder Communications
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 and demonstrable product 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.

Global Speak
International projects add yet another layer of complexity. Oakes’ notes there is huge tension between developing internationally and developing quickly. “Cultural, time zone, infrastructure, language differences—all slow down communication, yet the requirement for speed is fundamentally a requirement for rapid, effective communication. Setting norms, agreeing to structure, etc. is all the more critical. It's paradoxical (maybe) but you need to spend proportionately more time on defining communication protocols on rapid, international projects.” Oakes’ top considerations for communication on international development projects include:

• Assigning integrous modules to geographically co-located teams who speak a common language.
• Co-locating external interface developers with end users and assure that all members of both groups are fluent with the business jargon and national language of the application.
• Kicking off with face-to-face meetings to establish communication norms and common understanding.
• Using multiple modes of communication. Plan weekly conference calls at fixed times and with clearly defined agendas. Back these up with weekly status reports, regular e-mails, informal chats via an instant Internet messenger.
• Basic courtesy and consideration go a long way. For example, a Delhi-London-San Francisco conference call will require someone to work unusual hours. If you’re scheduling regular calls, rotate the times.

Summary
When coping with agile stresses, successful project managers don’t abandon the disciplines of software engineering or effective project management; they devote more thought and rigor to communication, recognizing the communication challenges and addressing them head on. Work as quickly as you can, but no quicker. Make haste slowly.