Getting the work you commit to getting done in an iteration or sprint is not constrained to a conversation about Scrum or Scrumban. Timeboxing is common in almost all work to some extent. For example, the act of a person or a team saying what they will do to meet a need and when it will be done establishes a timebox and an expectation of performance. This expectation of performance is at the very heart of every technique, method, framework, and methodology. This expectation is often violated. Teams that chronically do not complete work they committed to in a sprint the third usual suspects is work hitting roadblocks before being shippable.
Nassim Nicholas Taleb popularized the metaphor of a black swan as an event that appears without warning and disrupts planned events. However, most seemingly random events can be foreseen but people rationalize failure after the fact. Many common roadblocks are self-inflicted.
- Workflow Issues. All work follows a pattern, a workflow. All workflows have a constraint that limits the capacity of the process. A highway near my house inexplicably narrows from a four-lane road to a two-lane road then expands back to a four-lane road. During rush hour traffic grinds to a halt in front of the constraint in the highway. Processes inside a business are no different. Steve Tendon and Daniel Doiron make this point forcefully in their book Tame your Work Flow. In many circumstances, constraints or abuse of the constraint are self-inflicted events. Several years ago I worked for a firm that was in acquisition mode. In one fateful period of time we acquired two firms that delivered similar services to our core business and immediately “saved” money by making the sales force of the acquired firms redundant. Even though we had sales capacity, we had an unrecognized constraint in the flow that nearly killed the entire organization. In software maintenance and development flows the constraint could be testing, user acceptance, or security — unless you understand the flow of work through your value stream, any event could be a black swan.
Potential Solutions:- Define value streams and process flows then measure the throughput and cycle time of the major components.
- Understand where the process and workflow constraints are (they move as you adapt so you need to keep your eye on the constraints). Knowing where the constraint is and its capacity (that is why you want to know throughput and cycle time) will allow you to maximize flow and to judge the impact on the constraint when a team commits to doing a piece of work.
- Consistency of Purpose: Without a clear vision what an organization or team is driving toward will fall prey to the “shiny object syndrome.” W.Edwards Deming’s classic 14 Point For Management begins with:
“Create constancy of purpose toward improvement of product and service, with the aim to become competitive, stay in business and to provide jobs.”
As a product owner and team decide on a piece of work they need to understand whether completing that piece of work will advance the goals of staying competitive, staying in business, and providing jobs, In agile the burden for answering this question falls mainly on the product owner’s shoulders, but once accepted the whole team is responsible for determining how to deliver and then committing to deliver. When a business has constancy of purpose, there are many implicit agreements between management and teams, such as not interrupting the team unless absolutely necessary for the business. Constancy of purpose is a reflection of how leaders behave. A variant of vision du jour occurs when there are multiple leaders influencing a team (or organization) that are trying to control the team’s capabilities (think about people that jump the queue in the grocery store). This causes teams to thrash and fail to live up to commitments.
Potentials Solutions:
In highly dynamic environments shorten the period of commitment. Call centers or other interrupt-driven processes should use continuous flow models such as Kanban (or a Kanbany form of Scrumban). Most software teams can and should have longer commit cycles.
Educate managers and leaders on the impact of interruptions and exploiting work. The education needs to be hands-on. Use teaching games (an example is the online Kanban game TWIG) where the flow of work can be experimented with and the consequences seen – just talking about what will happen rarely makes the point. A more radical approach is to carve out a team whose goal is to explore new ideas or to tackle new initiatives, which allows leaders to insulate the organization’s value stream(s) from having to react to changes in direction until necessary.
