Blackwater Falls

A waterfall precedes and follows rapids

Agile teams living in a waterfall organization can have a tough road to travel. The degree of difficulty is often a reflection of the team’s sphere of control.  As noted in An Agile Team In A Waterfall World,  there are four areas that need to be addressed if an Agile team is going to thrive in a waterfall environment.  They are:

  1. Prioritizing Work Entry (discussed in An Agile Team In A Waterfall World)
  2. Postponing Commitment
  3. Engaging Executives On Agile Values
  4. Value Chain Analysis

The ability to postpone commitment at the most basic level means that a person, team, or organization can say “not now” when presented with a piece of work. The phrase, “not now” infers that the piece of work will be put into the queue, prioritized, and be done at a more appropriate time.  Not now is more powerful than no because it accepts the piece of work has merit but needs to be weighed against other options. Postponing work creates an environment where multitasking is minimized, stress on the team is reduced, and the flow of value is maximized. The ability to postpone commitment works hand in glove with the concept of work entry (work entry is a process and postponing commitment is a type of decision).  

In the LinkedIn (see earlier article) question that was the genesis of this theme, part of the context was that the team was “bogged down with commitments made to the waterfall side of the house.” A bit more context was exposed in further discussion. The commitments that were bogging the team down were primarily product features defined by a corporate group that had been shared outside the organization as part of a marketing roadmap. If we assume the timing of these features is past the point of negotiation, the team will need to defend its ability to postpone commitment more aggressively on work that is not part of the corporate commitment.  

Considerations when discussing postponing commitment:

  1. Do you have a rule for when you need to postpone commitment?
    Kanban uses the idea of a “replenishment signal” as a rule for knowing when to postpone commitment. The signal, for instance using a Scrum or Kanban board with visible WIP limits, allows all parties to recognize whether work could start. If not now, then when becomes a prioritization discussion. Daniel Doiron, suggests that the signal be automated, “Whenever we are asked to integrate a lot of data, we fail.”
  2. Have you established trust between the organization and stakeholders (true for teams and organizations also)?
    Following your rule and then meeting commitments when you make them are requirements for trust. Sometimes emergencies happen. I once was part of a team that did feature work and production support (it was a small organization).  When production went down, it was all hands on deck and everything else went on-hold until production was fixed. While that is an easy decision, what was harder were the times another manager or product manager would ask for us to jump on a ticket out of order (or they tried to jump the queue). If no trust exists, the person asking for the work will find other ways to get it done. 
  3. Are you transparent about the status of decisions and the flow of work?
    Visualizing the flow of work is just as important for your stakeholders as it is for the team. Stakeholders need to have a way to know where their work is in the queue and where it is in the workflow once started. Going back to my earlier example, when the rules weren’t followed there was a lot of pressure to give everyone the same treatment. My predecessor had found it easier to hide decisions and do the work but not show it on the team board (no transparency). When discovered (trust me, it always will be) the hidden work game destroyed trust between the team and its stakeholders

Self-organizing and managing teams have to be able to make decisions about their capacity to deliver the work that is in their backlog. The ability to postpone commitment so that a team can match capacity with capabilities is critical. In a perfect world, a team (or organization) would not have commitments being made outside their sphere of control. In imperfect worlds, the product owner (as part of the team) needs to incorporate the commitments into the prioritization process and let stakeholders know when the team needs to postpone commitment and then keep them informed.