How work enters an organization or team is almost always a touchy subject. For many, it is the root of the pressure on teams to do more than they are consistently capable of — at least without cutting corners. Many team leads and managers struggle with work entry causing them to ask who is responsible. My knee-jerk reaction would have been to hold up a mirror, and they did bear at least some responsibility. But ownership of the problem has to be placed on the doorstep of the senior leadership. Several factors make it difficult or unsafe not to accept work that is pushed into a team.
- The method that each level of the organization is being incented/paid. Bonuses and other incentives that prioritize output over outcomes lead to the tendency to say yes to as much work as possible and then to cut corners to make it happen. Problems, such as technical debt, are ignored or spun to be someone else’s problem. People will generally do what they think is in their financial best interest.
- The insistence that teams continuously improve, led by leaders who punish experiments that “fail.” Safety to try new ideas is critical for improvement. Punishing failures will lead to playing it safe and reduced innovation which means that teams get more done by cutting corners.
- Someone else will always say yes. I recently overheard a manager tell a team that they were not being “team players” when they indicated they would not have the capacity to do a piece of work for a sprint or two. The manager pointed out that the team of contractors down the hall would be glad to tackle the work, so why did they need this team?.
- Leaders leverage mismatches of power to get to yes. I followed the manager down the hall after the discussion in #3 (above) and listened as they pressured the team of contractors to take the work. The words “I will remember your answer when we renew the contract” were actually uttered to the entire team. Mismatches of power preclude saying no.
When the manager asked who owned work entry problems the answer had to start with senior leadership because they create and own the culture of the organization. Their words and actions need to match. If an organization wants to be agile or have an agile mindset, senior leaders need to foster an environment that makes controlling the flow of work safe. Begin by changing how leaders in your organization are paid and incented. Senior leadership ownership of culture DOES NOT let other leaders off the hook or even the teams themselves. Everyone in the decision chain needs to understand the implication of saying yes and agreeing to a delivery date without understanding other agreements already in the pipeline and what the team can deliver. Remember that Fred Brooks in The Mythical Man-Month proved that adding manpower to a late software project makes it later just because we are using sprints or iterations hasn’t changed Brooks’ message that saying yes to everything is a prescription to disaster. Senior leaders: you own it; fix the culture.
Even a simple definition of work entry is full of implicit and explicit assumptions based on the type of work, team, and organizations involved. Understanding work entry requires grasping four concepts:
- Push versus pull,
- Story-driven versus interrupt-driven,
- Utilization maximization fallacy, and
- Flow.
Pull and push are simple four-letter words (and they are sometimes used as invectives as other more infamous four-letter words are) that are not always understood. In software-centric organizations, a simple operational definition of pull is teams accept new work when they have the capacity to do it and the work has a reasonable chance of progressing to done without interruption. Work is pulled by the people doing the work based on the capacity of the system. I recently heard a configuration specialist in a Scrum team say “I ask the product owner what’s next on the backlog when we have the capacity to do more.” The conversation is a good indication of a pull work entry process. Push is the opposition of pull, reflecting the situation where work is given to people and teams based on the arrival of the work or demand rather than capacity or flow considerations. A number of years ago I worked for a consulting firm that used a push process between sales and delivery. The salespeople sold the work and then pushed the sold work into delivery usually with a promised start and end date.
Story-driven and interrupt-driven teams have to manage their work queues differently. Prioritized backlogs are a feature of story-driven teams. Requirements, while they may be dynamic, reflect market needs. Operational support teams are often interrupt-driven. Work comes to interrupt-driven teams in an unpredictable fashion.] I recently helped a large team supporting a large ERP package that was having fits meeting commitments they were making to their clients. The team would diligently plan a sprint (story-driven work) only to have tickets from incidents (interrupt-driven work) disrupt their plans. We split the team into two components one using a Scrum approach and the other using a kanban-y form of Scrumban.
Many organizations require teams and leaders to plan for maximizing capacity utilization by planning people (often called resources in this scenario) at 100% capacity. This approach pushes work to each step in the process without regard to constraints and bottlenecks yielding lots of work started but less work completed. The focus on planning 100% utilization in software teams is potentially counterproductive because it generates planning errors and compression. All systems (human and/or mechanical) have a capacity. Read Parkinson’s Law and The Myth of 100% Utilization for more on the 100% planning fallacy.
Flow is the amount of value that travels through a process in a specific time. Flow is often measured as a function of pace and consistency. The predictability of the flow is influenced by how much work enters, how well the work is triaged and how well the team exploits the constraint in the process.
Work entry is not an esoteric discussion. Real problems occur when we get it wrong. Herding is an example of poor work entry behavior. Herding is a pattern where an individual or team acts based on the behavior of others. Stated very simply, herding is just like the children’s game follow-the-leader. Last year, I sat in on a discussion in an organization where being perceived as being helpful was a significant attribute for bonuses and promotions. The R&D Group (software development) had recently been asked to implement a significant SaaS package with a due date before Thanksgiving so that the retail portion of the business would not be impacted. The date was absurd. The CIO had gathered a number of teams together to determine if the work was doable. The answer from each team as they went out of the room was no until a single team said they could do it. In quick succession, everyone changed their minds and played follow-the-leader. All of the affected teams exhibited herd behavior. As soon as one team broke from the pack everyone followed. The cascade was exacerbated when the CIO muttered “thank you” after the first two teams said yes. Herding in decision-making effectively took “no” off the table. This type of behavior is response-driven.
Herding is often a response to fear and uncertainty. Animals herd as a protection mechanism; herding makes it more difficult for predators to take advantage of an individual. Herding plays a similar role in decision-making. In our example, until one team broke the pattern everyone had the same answer; everyone was being equally unhelpful. As soon as one team broke ranks and at least one team followed, it became easy to brand teams saying no as not team players. Which increases risk. Following the leader in this circumstance can be viewed as rational economic behavior.
Signaled social influence triggers herding. Humans modify their behavior to adapt to the environment. Peer pressure and socialization are tools to send signals that establish behavioral boundaries. In our example, the CIO’s muttered comment was an explicit signal and application of influence to the other teams to change course. The policies that establish perceived helpfulness as an important input into the organization’s review process generate subconscious guidance for acceptable behavior.
Herding occurs in almost every human endeavor. The behavior is not prima facie good or bad, however, when playing follow-the-leader takes away the ability to control work entry, the flow of work can bottleneck and slow to a crawl. Teams that can’t say no when it makes sense will find it difficult to deliver value consistently.
All teams and programs must have a process for gathering and accepting work. In Scrum, a typical team’s work entry process might be:
- People write stories or requirements of varying quality,
- Those stories are evaluated and cleaned up,
- Updated, well-formed stories are added to the backlog,
- Once on the backlog, stories are prioritized (and re-prioritized), and
- In time, stories are pulled into a sprint.
The product owner owns the backlog and the prioritization process. He or she works with the team to determine when an item is to be done. A very poor work entry process allows anyone to give work to the team at any time, work they tackle based on their perception of value, urgency, and importance. While this sounds crazy, ad-hoc work entry is more common than most leaders know. Just to be clear, when work is pulled into the team in an uncontrolled manner the team will not be able to efficiently or effectively deliver value to the organization. The same issues occur at a program and portfolio level. Disciplined programs and teams fiercely control how work is accepted. No individual, team or organization can support an ad-hoc work entry approach over the long run without having to accept enormous risks. A disciplined approach to work entry evaluates and prioritizes work to ensure that the most important and urgent work is done before other work. At a team level undisciplined work entry has many effects. The top three are:
Disrupted work – Pushing new work into the team after planning is an interruption. Interruptions disrupt the current flow of work and thought within a team. Consider how you are impacted if you are in the middle of a piece of work or concentrating on reading this blog article and someone asks you to do something else. Interruptions reduce effectiveness and efficiency because they require re-work (maybe not re-work in coding or testing in every case), but there is always a disruption in the process of knowledge work (thinking, creating, considering, and collaborating). Interruptions cause knowledge workers to have to remember where they are in diagnosing the problem, how they were thinking about solving the problem, and what they were going to do next. The longer the interruption the bigger the impact.
Everything else is late – When a team is asked to deal with the new piece of work outside of a standard work entry process, other items that are currently being addressed will have to be stopped for some period of time. Just stopping one piece of work often will cause ripple effects unless each developer can perform all of the tasks needed without support or collaboration.
Reduced trust – The worst impact of an undisciplined work entry process is a loss of trust between team members, teams, stakeholders, and leadership. Loss of efficiency and late deliveries on committed work breaks the bond of trust between the team and the rest of the organization. In the long run, this causes huge side effects.
Teams and organizations need to obsess about controlling work entry. Not to be too Pollyanna’ish about just doing the work on the backlog, there will always be urgent and important items that appear on the horizon that need to be dealt with. Unplanned work should be RARE for most development programs or teams. The work entry process needs to be tuned to be able to deal with these types of items without causing undue disruptions to the team with the program.
