Why do agile teams focus on frequent communications and their WBS?


The practices used by Agile software development teams focus their daily efforts some of the key project management practices, in particular communications and work breakdown structures. By weaving these two key practices into everyday work patterns, Agile teams keep all of the team members engaged in key project management practices and thereby improve their project outcomes.


When projects require the efforts of more than one person, successful execution is often dependent on how well those project team members can see a common vision of the end product. Inevitably, the forming and maintaining of a commonly understood vision requires communications to occur between those people. One tool for helping to capture and communicate a high-level vision of a project's outcome, along with its constituent details, is the work breakdown structure (WBS). In what might be a surprise to many project managers, Agile software development processes are designed to keep the team focused on the WBS and team communication. Agile is not about setting technologists free from the shackles of project management and letting them roam free—it might even be seen as the opposite. Agile allows project participants to focus on creating value for the customer by weaving a couple of core project management activities into the project team's daily lives.

Communication, Communication, Communication

There are many project management tools that can help gather requirements, plan execution, and diagnose problems; however, if the answers that these tools help us discover cannot be communicated effectively to the people who need them, they will not help our projects succeed. Agile methods rigorously institutionalize strategies to improve communications, even when those strategies are inconvenient or difficult. For example, most Agile methods strongly advocate for co-locating all of the project team members.


Co-location promotes face-to-face communications, and increases the opportunity for unplanned interactions between team members. As difficult as it can be to co-locate a team, this practice is even identified as a good strategy in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute,2008):

Co-location involves placing many or all of the most active team members in the same physical location to enhance their ability to perform as a team. Co-location can be temporary, such as at strategically important times during the project, or for the entire project. Co-location strategies can include a team meeting room, places to post schedules, and other conveniences that enhance communications and a sense of community. While co-location is considered a good strategy, the use of virtual teams is sometimes unavoidable. (p. 234)

Agile teams do not seek to be co-located because it is easy, but instead are willing to expend a great deal of energy in order to co-locate because they believe it improves communications and leads to more successful projects. As Teasley, Covi, Krishman, and Olson (2000) explains:

Companies are experimenting with putting teams into warrooms, hoping for some productivity enhancement. We conducted a field study of six such teams, tracking their activity, attitudes, use of technology and productivity. Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all. (p. 339)

Co-location is not only for the technical team, Agile promotes daily contact between the technical team and its key business stakeholders. Agile proponents argue that face-to-face conversations often convey information more effectively than other communication strategies and therefore should be used as often as possible. While co-location provides a project team with tremendous advantages, simply co-locating the team will not magically address all of a project's communications challenges. Therefore, many other Agile practices, such as daily stand-up eetings and big visible charts, promote and facilitate communications.

Big Visible Charts

All too often, important project documents and communications are stored in a desk drawer and forgotten until a problem or misunderstanding occurs. A simple idea used by many Agile teams is that when some idea or topic is important it should be posted in large print on the walls where it is visible to everyone on a daily basis. This helps bring the idea or topic back to team members' minds on a periodic basis even when they are otherwise distracted.

The whiteboards and flip charts located in the war rooms helped the communication by providing large public workspaces that served as a visible permanent record of group activity and decisions. Teams used the whiteboards to keep the current status of the project plan visible to everyone. “To-do” lists were posted on whiteboards or flipcharts to note when a team member was responsible for an item. The fact that it was visible made it accessible to everyone at a glance. (Teasley et al., 2000, p. 344)

Information that has been captured and documented but is not remembered during daily work is often relegated to evidence when it comes time to assign blame. Agile teams want to keep important information in front of the entire team every day so that it will help them make better decisions and in order to increase their opportunities for a successful project outcome.

Daily Stand-up Meetings

Agile teams take time every day to briefly step away from their assigned tasks and check in with all of their teammates. These meetings are intended to be quick, therefore most Agile teams hold these meetings standing up in a circle (Exhibit 1). These meetings have a specific format and structure. Often teams use a token, or a speaking stick, to facilitate the meeting and ensure that it does not devolve into a discussion. The goal of these daily Stand-up Meetings, or daily Scrums, is to ensure that all team members know what their teammates are working on and to identify any current or future roadblocks that need to be removed. Most teams complete each daily meeting somewhere between 10 and 15 minutes. As a result of these quick daily meetings, team members spend less time (or no time) exchanging e-mails, issues are identified and raised sooner, and the team can often identify ways to help each other even though help was not being sought.

A stand-up meeting

Exhibit 1: A stand-up meeting.

Communication is a Key Enabler

Project Communications Management is one of the nine project management Knowledge Areas outlined in the PMBOK® Guide. While the other eight project management Knowledge Areas can also greatly contribute to the success or failure of a project, any positive impact imparted by the practices from those other areas will quickly be diminished if the project team members fail to effectively communicate with each other.

What Are We Building?

One of the most important things for team members to communicate with each other is their understanding of what the project is intended to produce. A key project management tool for helping to facilitate this conversation at multiple levels of detail is the WBS. It turns out that Agile processes typically have a WBS as their key project management artifact, and most team members interact with it on a daily basis. Sometimes it can be easy to overlook that Agile teams use work breakdown structures, because they might record it on index cards, “story cards,” or use an unfamiliar name such as “backlog.” But a closer examination will often show that a team's story cards or its backlog is actually a set of work packages. These work packages are often grouped into clusters that represent larger blocks of functionality, effectively forming a WBS. For example, if we compare the attributes of a work package with the attributes of an extreme programming storycard we find that they are almost identical.

(PMI, 1998) (Beck, 2001)

Exhibit 2: (PMI, 1998) (Beck, 2001)

On most Agile teams, each team member can tell you on which of the project's work packages they are currently working. Because the work packages are captured and presented in a comfortable format, team members quickly find that their daily activities can all be easily attributed to specific work packages, story cards, or backlog items.

Another interesting observation is that the WBS (as part of the baseline scope) is listed as an input to several project management Knowledge Areas, including: Time Management, Cost Management, Quality Management, Risk Management, and Procurement Management. Whenever Agile teams work on any of these key project management concerns, they always reference the work packages that they have captured as story cards or their backlog.

Why Focus on Communication and Work Breakdown Structures?

It is difficult to imagine a successful team that has done an exemplary job in all areas of project management but has failed to create a detailed definition of the product to be delivered. Likewise, it is difficult to imagine a successful team that has done an exemplary job in all areas of project management but fails to communicate effectively among team members. Agile implements key communication practices in order to assemble a collection of unique individuals into a unified team. Agile practices enable the team to weave the definition of the project's desired outcome, the WBS, into their everyday lives in order to give the team a focus that can lead them to success.

Whenever you are working with a project that is struggling, you should ask yourself if the project would be better served by creating another report or by building an effective team and focusing them on a mission. Agile teaches that project management tools can indeed be powerful, but they are always more powerful when applied to a team—so start by building a team. “Not finance. Not strategy. Not technology. It is teamwork that remains the ultimate competitive advantage, both because it is so power and so rare” (Lencioni, 2002, p. vii).


Beck, K. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.

Beck, K. Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001). Principles behind the Agile manifesto. Retrieved September 2, 2009, from http://agilemanifesto.org/principles.html

Lencioni, J. B. (2002). The five dysfunctions of a team. San Francisco: Jossey-Bass.

Project Management Institute. (1998). PMBOK Q&A. Newtown Square, PA: Author.

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK®)—Fourth Edition. Newtown Square, PA: Author.

Teasley, S., Covi, L., Krishnan, M. S., & Olson, J. S. (2000). How does radical collocation help a team succeed? In W. Kellogg & S. Whittaker (Eds.), Proceedings of the 2000 ACM conference on computer supported cooperative work: Vol. 26. Managing information and technology (pp. 96–100). Philadelphia, PA: ACM

© 2009, Menlo Innovations LLC
Originally published as a part of 2009 PMI Global Congress Proceedings – Orlando, Florida



Related Content