Chapter 11: ‘Just-in-time’ Communication – Agile Productivity Unleashed, 2nd Edition


When was the last time you attended a valuable meeting?

‘I can’t get that proposal to you until tomorrow ... I’m in meetings all day today.’

It is no wonder that meetings have earned a bad reputation in the corporate world. They are often seen as non-productive time-wasters that stop employees from getting their real work done. Which is reasonably due to the fact that, most of the time, meetings are time-wasters.

Figure 3 Richness of communication channel

The meetings themselves are not actually the problem. In fact, the graph from Alistair Cockburn,41 shown in Figure 3, identifies face-to-face discussion as one of the most effective forms of communication.

So, the problem is not with the use of face-to-face communication; it is often due to a combination of why the meeting is held, who attends and how it is conducted.

Organizations generally hold meetings to provide a status update on current and planned activities, to propose and plan for an idea/activity, or to address issues. Often, for convenience sake, meetings become a combination of two or more of these objectives (since ‘we have everyone in the room anyway’). This means that meetings generally include a combination of the people who genuinely need to be there and the ‘incidental’ attendees who are there for convenience sake.

In most circumstances, the person calling the meeting comes in with a formal (or rough) agenda of what needs to be covered in that session. The brave ones even endeavor to allocate times for each agenda item, with the intention of ensuring that this meeting (unlike the last eight meetings) is going to end on time. An organization that is really focused on productive meetings may even hire a professional facilitator to run their meetings. All of these approaches are well intentioned, and all seem to overlook the fact that meetings, by design, are inherently flawed.

Why the meeting is held: Meetings tend to try to cover too many topics in the one session, which often results in a cursory review of the key discussion points and not enough time to deliver conclusive results. Meetings may also be held for the sake of consistency (‘we have our weekly sales update every Thursday afternoon, no matter what’), which is especially important when the meeting is really intended to compensate for not having sufficient day-to-day communication within the organization.

Who attends: Meetings tend to focus on being as inclusive as possible, inviting anyone and everyone who could possibly benefit from (or add value to) the information covered. The people who are often the most valuable contributors in these meetings, however, are the key decision makers, that is the people authorized to make a decision on behalf of the organization, so that actions can progress. Even though key decision makers are often too busy to attend the meeting – or to stay throughout the entire meeting – meetings are likely to go ahead without them.

How it is conducted:

  • Status update meetings are notorious for allocating too much time to cover each topic. Presenters put together extensive slideshows to say in 30 minutes what could have been sufficiently covered in 10 minutes or less. ‘Going around the table’ to get an update from each attendee generally results in an endless sea of unprepared statements and ad-hoc comments, with an occasional point of interest that digresses the meeting for at least 10 minutes.
  • Concept and planning meetings tend to encourage open discussion and brainstorming, which can be beneficial in these circumstances. However, once the initial brainstorming is complete, the remainder of the meeting is rarely contained to a fixed set of topics for discussion, so that decisions can be made and work progressed. Instead, these meetings can result in a white board filled with great ideas and no committed path forward to turn these ideas into reality for the organization.
  • Issue review meetings often go from being a pointed discussion of key items (in order to determine a reasonable path forward), into an interactive free-for-all where attendees digress on topics indefinitely. Meeting facilitators will often try to time-box these discussions (and warn the attendees when the time to discuss an issue is running out), but rarely will they enforce a decision to be made on the next steps required to resolve the issue. It may be cathartic for attendees to have a forum to air their concerns, but it has little value for the organization unless something constructive comes from the discussion.

It is the combination of all of these factors that can make traditional meetings frustrating for attendees, and often less than valuable for the organization overall.

Redefining the corporate meeting

Agile approaches take a different position on corporate meetings, specifically:

  • Meetings are meant to supplement not substitute for day-to-day communication in the organization.
  • Meetings should have one specific area of focus with the success or failure of the meeting being measured solely on whether the area in focus was sufficiently addressed.
  • Meetings should be time-boxed to allow for reasonable levels of discussion around the area of focus, without encouraging attendees to go too far off-topic.
  • Meetings should include all necessary participants, including key decision makers who are able to attend the full duration of the meeting. If key decision makers cannot attend, then attendees will not be in a position to transform the discussion into actionable work. Therefore, the meeting should be rescheduled.

The responsive planning process detailed in Chapter 5: Responsive Planning identified two key meetings that are used in Agile approaches:

1. The iteration planning session.

2. The outcomes review session.

The iteration planning session, held at the start of each iteration, is the meeting where business owners communicate their goals and priorities, and delivery team members advise on what priority work they can reasonably deliver in the forthcoming iteration.

Depending on the nature and complexity of the work, the iteration planning session can take as little as one hour (especially if it is a continuation of previously reviewed requirements) to as much as eight hours (if there are a large number of new requirements that require substantial discussion). In most cases, however, iteration planning sessions will take two to three hours each iteration (i.e. every two to four weeks). It is critical that decision makers attend these sessions to ensure that the delivery team receives clear and decisive direction from the business before the iteration begins.

The outcomes review session, held at the end of each iteration, is where business owners review the work that has been completed by the delivery team in the previous iteration, discuss any questions or concerns, and update the requirements backlog to reflect any changes to the business requirements, based on the result of this review. Like the iteration planning session, the duration of an outcomes review session will vary depending on the scope and complexity of work completed; however, it is reasonable to allow between two and four hours for this session. As with the iteration planning session, outcome review sessions require decision makers to attend, so that feedback received is definitive and work can confidently progress.

It is worth noting that because Agile approaches minimize the time commitment for business owners to less than a day each iteration (e.g. one day every four weeks), it is more likely that key decision makers will be able to commit their time to these sessions. Moreover, the more successful Agile work is within the organization, the more that these decision makers will be encouraged to make time for these meetings in their schedules.

In situations where the business owners and the members of the delivery team are expecting to continue working together in the next iteration, it may be efficient to schedule the iteration planning session to directly follow the outcomes review session. This can reduce the meeting commitment for the Agile team to one business day each iteration (or less). However, this approach may not always work, especially if the outcomes review session results in follow-up work that the business owners need to do off-line, including discussion around re-prioritizing the requirements backlog.

What can you do in five minutes?

For business owners, the iteration planning session and the outcomes review session are the only two formal meetings that they are required to attend in support of the Agile process. For delivery team members, there is one additional type of meeting that they are required to attend: the daily stand-up meeting.

The daily stand-up meeting is a five-minute session that occurs every morning where delivery team members get together to review:

  • The work that they completed the previous day.
  • The work that they are planning to do today.
  • Any hurdles or issues that they have encountered (or expect to encounter) in their work.

The term ‘stand-up meeting’ is inspired by the fact that, in many cases, delivery teams will physically stand up throughout the entire meeting duration, to help ensure that the five-minute timeframe is adhered to. In addition, each attendee is expected to come prepared to address the three bullet points above, both to avoid wasting the other attendees’ time and to minimize the chance of improvised responses resulting in key items being overlooked. Delivery teams can opt to use the delivery backlog as a tool to facilitate these discussions and reduce the amount of redundant information being covered in the little time that is available.

Daily stand-up meetings do not only provide a forum where delivery team members can get real-time updates on the status of their work, they also create an interesting dynamic to inspire team member motivation by:

  • Asking team members to think about (and account for) the work that they do each day.
  • Allowing team members to regularly air their concerns and issues, so that they are not left unaddressed for an indefinite period of time.
  • Encouraging delivery team members to self-manage by knowing what work is scheduled and, where appropriate, negotiating tasks so that the most skilled (and/or most available) resource can take on that work.

The Agile facilitator guides daily stand-up meetings both to ensure that the information addressed achieves the intended objectives and to make certain that the meeting time does not extend to a ‘one hour stand-up meeting’ to address issues that can be handled offline. The Agile facilitator is also responsible for taking ownership of resolving any issues or impediments to delivery that the team identifies. This frees up the delivery team members’ time to focus on their key activities, without being preoccupied with issues and obstacles.

It should also be noted that, in the interest of open communication, business owners are invited to attend daily stand-up meetings as an observer any time they choose, throughout the iteration. To keep to the five-minute timeframe, business owners are encouraged not to attend as advisers (to avoid the potential for the meeting to digress too far into one topic). However, their attendance at these meetings may give them insight into the work that the team is doing (and the hurdles that they are encountering) which, ideally, will inspire them to make themselves more available to the delivery team outside the meeting to address these topics.

Further information on conducting iteration planning sessions and outcomes review sessions is detailed in Chapter 12: Immediate Status Tracking.

Knowledge transfer through pairing, co-location and cross-training

One of the key principles that underpins the Agile approach to meetings is that meetings are meant to supplement not substitute for day-to-day communication in the organization. Throughout each iteration, delivery team members may hold any number of informal discussions with business owners, from ad-hoc telephone calls, to e-mails, to one-on-one detailed reviews of their requirements. In addition, the delivery team itself requires regular, ongoing communication between team members to ensure that their work is consistent, to jointly overcome hurdles and to collectively address the activities in the delivery backlog.

Agile approaches address this need for ongoing communication within the delivery team by encouraging pairing, co-location of delivery team members and cross-training.

Pairing is having two members of the delivery team working together on assigned tasks, even for work that would normally be assigned to only one person on the team. The logic behind pairing is:

  • Increased accountability: delivery team members are more likely to be productive and focused if they are working with someone, even if that person is only acting as an observer.
  • Better quality outputs: having a second person working with a team member encourages communication of ideas, discussion of questions, explanation of decisions and critiquing of work undertaken.
  • Knowledge sharing: pairing of team members allows more than one person on the delivery team to be aware of the work that has been undertaken and the logic behind decisions that are made. This can ensure that the delivery team is not overly dependent on the availability of any one resource for this knowledge.

Having work done jointly by two members of the delivery team is likely to result in an increased upfront resourcing cost to the organization. Although, the level of quality of the resulting work – and the minimized need for rework – often more than compensates for this initial overhead. (see Chapter 14: Constantly Measurable Quality for information on how much low-quality outputs can truly cost an organization.)

Co-location of delivery team members is a strategic way to encourage day-to-day communication, sharing of ideas and real-time awareness of the status of the team’s work. Not only are team members physically near each other, facilitating ad-hoc discussions and face-to-face reviews of work, the resources of the team (e.g. documents, whiteboard diagrams, models) are in a central location, which is immediately available to anyone on the team who requires access to these materials. Logistically, this may not always be possible in an organization, particularly where delivery team members are on different floors, in different offices or even in different countries. However, virtual co-location through videoconferencing, shared workspaces on the intranet, and ‘presence’ tools can provide a reasonable alternative in most situations.

On rare occasions, an organization will be forward-thinking enough to co-locate the business owners with the delivery team for the duration of the iteration. This is the ideal model for ensuring that deliverables align with the business requirements, but it is not always feasible. The alternatives are having the business owners be available to meet with the delivery team at their desks on an ‘as required’ basis, or enlisting the help of a highly qualified business analyst to represent the interests of the business owners on a day-to-day basis.

Cross-training is distributing work across all members of the delivery team (where possible), so that team members have hands-on knowledge in all facets of the work that the team is doing. Like pairing, cross-training also provides cross-fertilization of knowledge to minimize the potential for the delivery team to be overly dependent on the availability of any one resource. It also fosters an environment of knowledge-sharing and multi-disciplinary skills development across team members, which makes them more valuable both to the delivery team and to the organization overall.

Pairing, co-location of delivery team members and cross-training are all designed to create an environment where delivery team members communicate regularly and work together towards a shared goal. They are work practices that negate the need for excessive formal meetings. This means that the only required meetings for the delivery team during the course of iterative work are the five-minute daily stand-up meetings that take less than half an hour of each resource’s time per week.

Documentation is no substitute

Organizations (especially large organizations) love documentation. People’s in-trays are filled with memos, status updates, discussion papers and 200-page doctrines from professional consulting firms. Their e-mail inboxes are overflowing with attachments and embedded document links. There is something about having a large document in one’s hands (or on one’s computer) that feels as though the organization is being productive. It is one of the most deceptive aspects of the corporate world.

Every time a document is created in an organization, there are likely to be a number of related activities that take up the organization’s time, staff and resources in addition to the physical creation of the document, such as:

  • Input from other staff members in the content of the document.
  • Quality review of the document.
  • Physical printing and collation of paper documents.
  • Distribution and storage of the documentation (electronic and paper documents).
  • Time required for other staff members to read through the documentation.
  • Repetition of all of the above activities for each new version of the documentation that is released.

Finding the time to review these documents can be a challenge for most employees – and, when they finally do find the time to read the materials, it is likely that the content will have been superseded by more recent information in the organization.

Chapter 1: Agile in a Nutshell describes the pitfalls that organizations can fall into when they rely too heavily on upfront documentation to communicate their business requirements. Because specifications can take months to produce (and even longer to get approved for release), formal documentation on business requirements almost inevitably reflects outdated information about the state of the organization. In a cutting-edge marketplace, organizations cannot afford to work from old information – or to continually repeat work based on outdated requirements.

Documents do have a place in the corporate world. They provide a record of agreed communication after the fact. Organizations cannot exist without documented contracts and recorded agreements. However, formal documents are not as effective as face-to-face discussions when it comes to communicating business requirements.42

In the Agile world, the key to ‘just-in-time’ communication is a combination of short, targeted meetings and ongoing discussions between Agile team members. These approaches focus on face-to-face communication as the most effective way of reviewing and discussing business requirements. Agile approaches replace the need for extensive documentation with interactive meetings (such as iteration planning sessions) where participants can discuss business requirements in detail, ask targeted questions and provide feedback to refine these requirements.

Requirements backlogs are used to record the high-level details and relative priority of each business requirement. Supporting information (including documents) can be linked to individual entries in the requirements backlog as needed, but business owners are responsible for ensuring that this supporting information reflects the most current requirements details prior to the iteration planning session.

Agile work can be formally documented after the fact to reflect the deliverables. Depending on the requirements of the organization, Agile teams may choose to allocate a day or two in between iterations to capture the work that was completed. This allows documentation to serve as a record of agreed outcomes, instead of a substitute for face-to-face communication.

The most valuable meeting of all

Because there are so few formal meetings in the Agile process, Agile team members are encouraged (and expected) to attend each meeting. However, what if you were an executive who only had time for one meeting a month?

The most valuable meeting in the Agile approach is arguably the outcomes review session at the end of each iteration. This is where business owners see the tangible outputs from the delivery team. It is their hands-on opportunity to review the completed work, critique deliverables and ask targeted questions of the delivery team.

The outcomes review session is where the business owners determine whether the original business requirements have been met, and collectively decide how the organization should move forward. It is where the value of Agile approaches is most evident.


41 Reprinted with permission from Alistair Cockburn:

42 As shown in the ‘Richness of communication channel’ graph at the beginning of this chapter.