Chapter 9: Immovable Deadlines – Agile Productivity Unleashed, 2nd Edition

CHAPTER 9: IMMOVABLE DEADLINES

Why you should never move a deadline

New Year’s Eve celebrations provide a fascinating study in human perseverance. Every year, cities prepare for these events months (sometimes years) in advance of the December 31st deadline. They know that it is a fixed, timeframe, a deadline that cannot change.

In most cases, the New Year’s Eve event coordinators aim to present something even more spectacular than the year before – despite inevitable increases in the costs of materials, equipment and security. It is a daunting challenge for them to accomplish in a relatively limited timeframe. So, they hold planning sessions, allocate tasks to teams, acquire sub-contractors (e.g. fireworks technicians) and map out all of the activities that will be required for the New Year’s Eve celebrations to be a success.

Inevitably, no matter how well they prepare, there are always last minute changes, mishaps and unforeseen delays. (No amount of planning can avoid the unexpected.) Yet, by the night of December 31st, the celebration commences with cheering crowds and news cameras rolling, despite all of the hurdles that were encountered. The coordinators know that there is no choice – the event must go ahead on the scheduled date – and somehow, it always does.

It is the immovable nature of New Year’s Eve celebrations that forces the organizers to do whatever they have to in order to meet this timeframe. In some cases, this means scoping down the preparation work in order to make it achievable, especially as the deadline gets closer. In other cases, it means supplementing the staff with other resources who can assist when the work gets overwhelming. Everyone involved in the process knows that the timeframe cannot be changed, so they do whatever else is needed to ensure that they are ready to go on the scheduled date. That is the power of the immovable deadline.

Organizations regularly deal with immovable deadlines in the form of compliance due dates (e.g. tax returns), publicized product launch dates and staff departure dates. These deadlines represent commitments for the organization that, in many cases, are (or become) beyond the organization’s control. This means that staff members must do everything within their power to ensure that the work required to meet these organizational commitments is completed by the deadline.

What about ongoing business activities that are not tied to a fixed date commitment, such as promotional activities, customer service initiatives and continuous improvement work? How do you prevent these activities from being postponed indefinitely in favor of work that staff members consider to be more urgent? You create accountability by replacing ‘flexible’ work with fixed time commitments for all critical organizational activities, and you ensure that staff members truly see these fixed time commitments as immovable deadlines.

Immovable deadlines bring a sense of urgency to work that flexible deadlines lack. It is human nature for people to focus on work that has a committed timeframe over work that can be completed ‘when time allows.’ Staff members quickly learn to differentiate between truly urgent work (immovable deadlines) and somewhat urgent work (movable deadlines). This includes timeframes that were originally defined as immovable deadlines, but were able to be changed over time to accommodate other competing resource commitments. Once staff members realize that deadlines – even ‘immovable’ deadlines – are flexible, these activities will be relegated to roughly the same category as ‘when time allows’ work. This means that these deadlines become, in effect, ‘toothless tigers’ in the corporate environment.

Project management literature would classify the immovable deadline as a fixed constraint in the classic ‘project management triangle’ of scope, time and costs/resources. They would argue that immovable deadlines force the duration of work to be fixed, therefore, if a project is in jeopardy, the only options available to the team are:

  • Decreasing the project scope, or
  • Increasing the project budget/resources.

in order to meet the required timeframe.39

What these project management texts generally fail to recognize is that immovable deadlines often have an incredibly powerful emotional impact on a delivery team, more than budget or scope constraints. Team members can disassociate themselves from a fixed budget by rationalizing it as a ‘management’ issue. They can even disassociate themselves from a fixed scope by reasoning that, in a worst-case scenario, activities can be cut down or improvised. In contrast, fixed timeframes are non-negotiable; you cannot change the calendar.

This is why immovable deadlines can have an extraordinarily unifying effect on a delivery team (not dissimilar to having a shared enemy). Passing time presents a constant reminder of what work has (and has not yet) been completed. Looming deadlines allow everyone on the team to be continually focused on a shared goal. Moreover, because of the team’s unified focus, management can be reasonably assured that something of value will be delivered by the team in the agreed timeframe.

The power of immovable deadlines is why Agile approaches structure work to be undertaken and delivered in fixed time iterations with immovable review sessions at the end of each iteration. These immovable deadlines can ensure that activities do not get put on the back burner in favor of work that is perceived by staff to be more urgent. They are equally designed to ensure that the outcomes review session at the end of each iteration is not a movable feast that can be continually postponed in favor of other priorities. In the Agile world, immovable deadlines create a continuous reminder for the delivery team and a sense of urgency that flexible (i.e. movable) deadlines do not provide.

For the customer service example described in Chapter 5: Responsive Planning the immovable deadline of the four-week iteration meant that the delivery team could not – and did not – spend infinite amounts of time analyzing options for improving customer service. Knowing that they had a commitment to deliver results in four weeks forced the delivery team to organize themselves quickly. They understood that any new or changed initiatives proposed would need to be in a production setting for at least a week before the outcomes review session, in order for statistical information to be gathered. Having this fixed commitment prevented the organization from entering the endless spiral of meetings and discussions to weigh options. The ‘Apply, Inspect, Adapt’ nature of Agile approaches also meant that other stakeholders in the organization (such as the customer service team) were more compelled to participate in this work, instead of continually rescheduling in favor of other activities.

It is important to note that the Agile approach of enforcing immovable deadlines in iterations does not mean that delivery teams perceive their work to take absolute precedence over other activities in the organization. In fact, Agile approaches are able to accommodate any higher priority requirements of the organization that may arise during an iteration – even if it means that the entire delivery team needs to be temporarily reallocated to other work. (See When priorities change in Chapter 6: Business-value-driven Work for further details on the options available for Agile teams to accommodate higher priority work in the organization.)

In those rare circumstances where some (or all) of the delivery team members have to be reallocated to more urgent work during the course of an iteration, the outcomes review session and next iteration planning work always take place as scheduled. No matter how much (or how little) work is achieved in an iteration, it is important to hold these sessions in order to maintain the ongoing momentum of the team.

From a distance, the enforcement of immovable deadlines in an organization may appear to create a rigid and unyielding environment for employees. Surprisingly, however, people generally appreciate the structure of delivering outcomes within fixed timeframes far more than managing endless ‘when time allows’ commitments. Immovable deadlines create an environment where staff members are compelled to deliver valuable outputs regularly. This gives them an ongoing sense of satisfaction in seeing meaningful results from the work that they do. It also creates a sense of purpose that can motivate people to continue delivering results. see Chapter 10: Management by Self-motivation for further information on creating organizational environments that encourage employee productivity.

The power of imminent timeframes

Agile approaches not only enforce immovable deadlines, they deliberately structure these deadlines to be in two- to four-week iterations. This creates a working environment where the next deadline for required work is never more than a month away. Not only does this encourage staff members to deliver regular ongoing value to the organization, it creates a sense of urgency for the work that they do by establishing imminent timeframes for delivery.

Long-term deadlines are easy for people to ignore. They create a climate where work can be easily postponed, or rescheduled in favor of more urgent activities. Imminent timeframes, on the other hand, compel people to take action. It is the basic psychological principle that underlies ‘limited time offers’ in marketing campaigns. It is why (most) people organize to send out their Christmas cards by December 21st – and continue shopping for presents until December 24th. Imminent timeframes create an urgency in people’s minds that keeps commitments at the forefront of their thoughts. The imminent timeframes in Agile approaches are strategically designed to ensure that required work is either actively addressed – or deliberately delayed in favor of more critical priorities in the organization – but never ignored.

More important than staying prominent in people’s minds, however, is the fact that imminent timeframes leave no time to waste in order to achieve the required outcomes. As explained in the customer service example, short-term deadlines mean that delivery team members do not have the luxury of endless weeks to contemplate what should (or should not) be done. Everything about the shortened timeframe encourages:

  • Business owners and delivery team members to propose achievable solutions at the iteration planning session.
  • Delivery team members to meet directly after the iteration planning session to determine what specific tasks are needed in order for the required work to be achieved in the few weeks available for the iteration.
  • Delivery team members to break down tasks that cannot reasonably be achieved in the iteration timeframe into smaller sub-tasks that can be achieved. For example, it may not be realistic for the delivery team to undertake comprehensive testing of the new sales report in the time available, but basic quality checks can be done.
  • Delivery team members to hold five-minute ‘stand-up meetings’ every day to quickly review required work and address any hurdles (see Chapter 11: ‘Just-in-time’ Communication for further information on stand-up meetings).

The combination of imminent timeframes and immovable deadlines in Agile approaches means that delivery teams can prepare themselves for the workload; they can pace themselves to meet the agreed timeframe; they know what to expect when they come in to the office each day; and they are generally able to self-manage to ensure that work is achieved without requiring excessive overtime or weekend work.

Interestingly, it also means that delivery team members are somewhat insulated from the pressure of the ‘fire-fighting’ activities and last-minute deadlines that plague most organizations. The same commitment that has delivery team members organizing themselves to deliver regular value to the organization each iteration, also binds the organization to avoid distracting these employees from their work unless it is absolutely necessary.

If imminent timeframes are so powerful, why not complete iterations and hold outcomes review sessions on a weekly basis? Agile approaches appreciate that delivery teams need sufficient time to accomplish required work before they can be in a position to bring valuable results to outcomes review sessions. For most activities in an organization, a week would not provide the delivery team with enough time to organize key stakeholders, take action on their input and measure their results.

Could your organization design a new sales report; gather, manipulate and populate the required information in the report; test the information in the report for accuracy; review the new report with key stakeholders (e.g. sales executives); and present the outcomes of this work in a five-day period? If so, your organization is either extraordinarily efficient or lucky enough to have exceptional corporate reporting systems. For most organizations, however, these activities would take at least two to three weeks – and more – even with the most dedicated and focused delivery team. That is why Agile approaches deliberately discourage meetings that are too frequent for attendees to be able to provide (or receive) valuable input (see Chapter 11: ‘Just-in-time’ Communication for further differentiation between valuable meetings and time-wasting meetings).

It should be noted that some organizations prefer to structure their Agile work in two-week iterations. This preference could be due to:

  • The nature of the industry (e.g. if quicker turnaround times are needed to retain a competitive advantage).
  • The nature of the work (e.g. requiring more frequent approvals from business owners for work to progress).
  • The organizational climate, particularly where Agile approaches are relatively new to the organization, and management wants to confirm whether or not they are effective.

Structuring Agile work in two-week iterations is a perfectly valid option for organizations, as long as they understand the limitations of what a delivery team can reasonably achieve in such a short timeframe. Expecting four weeks’ worth of business value in a two-week timeframe is both unrealistic for the organization and unfair to employees. Imminent timeframes are intended to encourage employees to self-organize and work towards a shared goal; not to burn out from the pressure and resign.

Early delivery means early payback

In Chapter 7: Hands-on Business Outputs, the distinction was made between prototyping and functional deliverables. Prototypes are mock-ups of deliverables that are designed to give customers a feel for what they might look like (and how they might behave). Functional deliverables are actual products and services (such as a sales report with real production information) that can often be used by the organization immediately after the outcomes review session for real day-to-day work.

One significant benefit to having regular immovable deadlines is that organizations that use Agile approaches can often immediately utilize the functional deliverables that result from each fixed time iteration. This means that the organization is regularly in a position to realize the return on their investment sooner than business activities would normally deliver (e.g. business-value outputs every month versus every six months). Additionally, the imperative of meeting an immovable deadline means that this business value is not postponed indefinitely in favor of other competing activities.

The regular delivery of production-ready outputs through Agile approaches provides another significant benefit for the organization. Even if Agile work is postponed or cancelled after a few iterations, the organization can continue to get business value from the functional deliverables that were produced in the initial iterations.

Let’s consider, for example, that an Agile team is put together to develop 12 new reports that will assist the executive office in analyzing corporate productivity. In the first four-week iteration, the team delivers two complete reports that contain actual statistics comparing the productivity levels of each department against agreed organizational KPIs. The executives immediately add these reports to their regular monthly updates.

In the next four-week iteration, the Agile team expands on their previous work by delivering three new reports that include comparative information against the productivity levels of like organizations in the industry. Again, the executives are in a position to immediately include these reports in their regular monthly updates.

The following week, however, the marketing department advises that they need the delivery team to undertake some urgent market analysis in time for a scheduled product launch. The executive office agrees to postpone the development of the seven remaining reports, so that the delivery team can focus on the more urgent requirement.

In a traditional business environment, stopping an initiative after two months generally means that the work undertaken up to that point is filed away until a future time when the work is resurrected (if ever). In many cases, this half-completed work sits indefinitely on a network drive (or in a filing cabinet) until it is moved into an archive. Worse still, by the time the initiative is resurrected, the amount of time that has passed may make the work obsolete.

In an Agile environment, stopping an initiative after two months means that the organization gets eight weeks’ worth of valuable deliverables. This means that the executive office gets five fully functional reports that they can continue to use, even if the reporting initiative is never resumed. It may not be the full set of reports that the executives originally envisioned, but five fully functional reports are far better than twelve report mock-ups (or a scoping paper that analyzes how this work might be done, along with a detailed project plan).

The final benefit to having regular immovable deadlines is that business owners are in a position to stop work that is not delivering sufficient business value before significant revenue is expended. Frequent checkpoints enable Agile work to be regularly self-correcting, instead of allowing non-valuable work to continue indefinitely without accountability.

Setting the next deadline

As indicated, the iterations in an Agile approach can be scheduled in two-, three- or four-week cycles. It is up to each organization (and, in some cases, each Agile team) to determine the optimal duration for their iterative work.

To assist in the selection of optimal delivery timeframes, Agile teams need to consider two primary factors:

  1. The rate of productivity for the delivery team.
  2. The complexity of the work being undertaken, including both the nature of the work itself and the availability of key stakeholders.

Determining the rate of productivity for a delivery team is based on a combination of two key measurements in the Agile world: Yesterday’s weather and velocity.

Yesterday’s weather is a record of the historical rate of productivity for the same delivery team doing work with an equivalent level of complexity. For example, a delivery team that was previously able to create a print-ready marketing brochure in three weeks can reasonably assume that it will take them approximately the same amount of time to create the next marketing brochure of an equivalent size.

It should be noted that the measurement of yesterday’s weather is not a precise science; just an approximation of the degree of productivity that the organization can reasonably expect from this team in the equivalent circumstances. If external factors change, such as reducing the number of people on the delivery team – or even replacing someone who has been working on the team with a new resource – the yesterday’s weather measurements need to be adjusted to include these changing circumstances in the calculations. Yesterday’s weather is the primary measurement for determining a delivery team’s historical velocity.

Velocity measures the rate of productivity for a delivery team by tracking how much of the work for an iteration has been completed, and how much work is outstanding. This becomes both a tool for teams to monitor and measure their own levels of productivity, as well as an indication of their ideal delivery pace for scheduling future iterations. Like yesterday’s weather, a delivery team’s velocity will vary depending on a number of factors, including the nature and complexity of the work required, and the availability of stakeholders when needed. Chapter 12: Immediate Status Tracking provides further detail on the use of velocity as a measurement for delivery teams; Section 4: Making Agile Work in Your Organization provides tools that can be used to track the velocity of the delivery team’s work in an iteration.

Determining the relative complexity of the work being undertaken (as compared with equivalent historical work) can be a more difficult undertaking. External factors, such as stakeholder availability, can significantly vary depending on their other commitments, their scheduled vacation leave, even their level of interest in the deliverables. This is why determining the potential rate of productivity for a delivery team is usually only a reasonable estimation. The actual rate of productivity for a delivery team is best measured by a combination of their velocity and their daily updates (see Chapter 11: ‘Just-in-time’ Communication for details on how delivery teams use daily stand-up meetings to track and progress their work).

Using yesterday’s weather and velocity measurements enables each Agile team to base their selection of the optimal iteration timeframe on their delivery track record. Factoring in the complexity of the work being undertaken allows the team to reasonably adjust the duration where planned work is much more (or less) time-consuming. In some cases, Agile teams may vary the duration of each iteration as part of the Outcomes review and the Next iteration steps of the ACTION plan.

For example, an Agile team that normally schedules iterations every four weeks may jointly decide that the highest-priority work required for the next iteration should not require more than two weeks to be completed. In this circumstance, the Agile team may agree to either reduce the forthcoming iteration to a two-week duration, or to add more priority work to that iteration in order to maintain consistency and the team’s optimal delivery pace in a four-week iteration. At any point in time in these sessions, it is at the Agile team’s discretion to determine how long it will reasonably take the delivery team to produce outputs that will provide genuine business value to the organization.

_________________

39 It should be noted that some project management texts recognize quality as a fourth constraint, i.e. teams can opt to keep the same scope and budget with the same deadline, but produce a lower quality result.