The majority of work entry problems are caused by eight problems. The eight problems often occur in clusters and are a reflection of organizational culture.  The eight are:

Differences in goals – Goal conflict is the single reason that explains most work entry problems. Teams want to complete work in an orderly, engineering-like manner, and someone else wants a piece of work done now for what they perceive as a perfectly rational reason, whether planned, ad-hoc, based on promise or contract, emergency, or evolutionary change. No one is acting irrationally based on their business goals. The problem is the goals conflict.  Scrum, for example, requires at least a tacit agreement that the sprint backlog, once set, will stay the same until the next planning event.

Questions to shine a light on goal synchronization problems are: 

• Do team members or organizations value different time horizons?
• Are there different perspectives on what market the product is serving?
• When goal conflict occurs, is there an incentive to compromise or adopt a middle ground?
• Is there trust between team members or teams?

Are disagreements and arguments about approaches common? The goals of people, teams, and organizations have a huge impact on their behavior. Identifying differences or potential differences in goals is one of the missions of all leaders.

Need outstrips supply – There are two versions of this problem. The first occurs when the asks chronically outweigh the ability to deliver, but not by enough to be obvious.  In this scenario, the backlog is growing faster than work is being completed. The metaphor that is often used is slowly raising the temperature of the water up to boiling when cooking frogs (or lobsters) — they don’t notice until too late (I am neither a frog nor lobster and therefore have no standing to know if this is true). As this phenomenon develops, stakeholders slowly develop a feeling that the software delivery group is letting them down by being lazy or inefficient and begin to grumble. A common reaction is for the software team to try to address the problem by over-committing and trying to over-perform in order to get back into good graces. This approach might work in the short run. However, in the longer term, the stress on the team and stakeholders will reduce effectiveness and drive up quality problems, turnover, and cost.

The second version of this scenario is where the supply/need imbalance is recognized and then leveraged to generate a sense of fear and stress.  The same attempt to over commit and over perform occurs, generating the same sort of issues as the unrecognized imbalance but with deeper and fiercer reactions by all those involved.

Questions to use when evaluating need/supply mismatches are: 

• Does the amount of work being added to the backlog more or less equal the work that is being delivered?
• Do people complain more (or more loudly) about the ability to deliver value in a timely manner?

Recognized or unrecognized supply/need mismatches are easy to diagnose.  This is a measurement problem unless you are allergic to measurement. Note need will always outstrip demand to some extent. The size of the gap and the reactions to the perceived gap are what generate behavioral problems.

Pay practices – How leaders are paid is a specialized version of goal differences. Many organizations leverage performance pay structures that are tied to short-term outcomes (hitting sales goals or reducing outstanding change requests) that are outside the boundaries of sustainable performance — often couched as stretch goals.  Short-term thinking will often conflict with long-term plans, causing leaders to ignore guardrails that keep them from interrupting the agreed-upon flow of work.

Questions to use when evaluating pay practice issues are: 

• Is there an over-focus on short-term requirements?  
• Are mid or long-term technical architecture needs being addressed in a timely manner?
• When you ask about pay practices, are there significant short-term bonuses? (Asking directly about how people are paid is often difficult.)  

The impact of pay practices on work entry is the hardest category to explicitly diagnose, but is often easy to infer retrospectively. For example, I have worked for several firms that had large sales quotas, early in the last quarter of the year the pressure to slip in enhancements and tweaks went up as salespeople tried to make sales. 

Product v Project – Holding a project versus a product perspective can give stakeholders the impression that they have to get everything done at once. Project stakeholders are taught that they only get one bite at the apple. Therefore, everything has to be the top priority, even if unplanned.

Questions to use when product and project collisions are: 

• Do people call all or a majority of work projects?
• Does running a project confer special authority and responsibilities compared to other work? 
• Is work driven from a fixed requirements document or backlog?
• Are individual initiatives funded?

A project perspective is easily diagnosed based on the vocabulary people use and funding approach used for work.  

Urgency/importance dichotomy – Urgency is often defined as the person who yells the loudest while importance is defined as the impact on or the amount of business value delivered. Those you who yell the loudest generally trump those touting value until businesses fail.

Problems are one area where importance and urgency often intersect. When production is down or clients are screaming, saying that we will get to the problem in the next iteration is usually career-limiting. While important, this type of interruption has all of the same negative side effects. However, the value of fixing high-priority problems generally trumps the problems caused –  at least in the short run.

Questions to use when evaluating whether urgency trumps importance are: 

• Are there criteria for prioritizing work?
• Are standard criteria for prioritizing work used consistently?
• Is there an operational definition of value in use?

No criteria for prioritization or teams that jump when someone raises their voice are reflections of teams that react to the urgent at the expense of what is important.

Class of services – Sorting work by priority and then immediately reacting when a higher priority piece appears causes interruption problems.  For example, when expedited work interrupts planned work, it causes ripples of stoppage or slowdowns for planned and committed work.

Questions to evaluate is using classes of service is causing work entry problems are:

• Does the team’s or program’s board have identified classes of service?
• Is work being accepted into the iteration or flow of work outside of normal planning practices that cause other work to be delayed?
• Do team members or stakeholders ask for work to be expedited just to get it started?

Diagnosing whether classes of service exist is usually as simple as looking at the program “board”.  Less explicit implementations of a class of service approach are harder to diagnose.

Control – Leaders and stakeholders that force teams to take work when it is apparent that they can not absorb it should be vanquished to one of Dante’s nastier levels of hell. This type of behavior makes work late, reduces quality, and causes turnover or, worse, creates demoralized developers that stay and poison the well.

Questions to leverage to determine if there are control issues are:

• What do the interactions between leaders, stakeholders, and team members say about the leadership tactics being used?
• Are people or teams told what to do and how to do it consistently?
• Is there only one leader in all situations?

Micromanagement or command and control approaches can be exhibited by leaders of all types.  The long-term use of these approaches can have deleterious effects on teams and team members.

Yes – The single word yes is at the root of most work entry problems. Because leaders or teams want to please their clients and other stakeholders, perhaps a better way to think of this problem is as the inability to say no. Whether due to an overriding need to please or a lack of power, if yes is the only answer you feel qualified to give, your backlog will be overrun. You will start everything and finish very little. No one will be happy.

Questions to help identify if yes should be rebranded as a 4-letter word are:

• Is yes the only answer is that the team will get right on it (or other variations of yes)?
• Does saying work will be placed on the backlog guarantee it will be done (and soon)?
• When was the last piece of work canceled after it was begun?
• Does the team or organization measure cycle time? 
• Is cycle time important?

Diagnosing Yes’itus requires listening to the transactions occurring at the work entry interface (wherever it is occurring).  

The eight primary causes of work entry problems are so common that many organizations and leaders think that this is the way work should be done. Simply put, accepting one of these problems will cause very predictable nasty results in the long run.  Treating more than one of these problems as acceptable creates a hot mess that is often solved only by hitting the reset button.

Steps Toward Addressing Work Entry Problems

The eight problems that cause work entry problems are diagnosable if you are willing to expend a bit of shoe leather talk with team members and stakeholders or just observe. Knowing that there is a problem is important, however, the hard part starts when you try to fix the problem or problems. Work entry problems often occur in clusters because they are a reflection of the way the organization is structured, how work is funded, methodologies, and/or organizational culture. These four general categories are addressable by different types of work entry fixes.

1. Staffing Levels – The right number of people is a solution only for the scenario where needs outstrip supply.  That said, having enough people can mask all sorts of problems for a period of time. More people are not a long-term fix if a team or organization is using the wrong method to develop code or any deliverable.  Nor is adding people a good idea if “yes” is the only answer to the question will you do it. Finally, while you can add people to cover something that is urgent in the short run, if the culture favors urgent over important innovation will suffer.  
2. Alignment – Alignment can be an easy fix if the culture allows transparency. Create a set of shared goals that are required to be obtained for the team, program, or organization to be deemed successful. In cases where multiple different organizations work together, they must contractually agree on the shared goals. Define success so that “All for One and One for All” is not just a line from The Three Musketeers.
3. Change Methods of Working – Breaking the classic project management approach to fund, monitor, deliver work requires changing how to support departments deal with work as it flows through the value stream. For example, funding and value delivery need to be tied together without an explicit funding expiration date. Backlogs need to be built and prioritized based on value and then funded until the features on the backlog no longer meet the organizational hurdle rate (required rate of return) or doing something else will deliver more value than what the team is delivering. If long-term backlogs can’t be funded, implement a portfolio-level kanban approach where features are prioritized and funded with full transparency (an internal shark tank). The competition will focus each story or requirement in the work entry queue on delivering value.
4. Culture – Culture is the beliefs, behaviors, and shared experiences that shape how team members or a company’s employees interact. Pay practices, whether interruptions are tolerated or work is defined as important or urgent, and most importantly how people that challenge the status quo are treated are all governed by culture. Because culture change is a reflection of teams and organizations building new habits and memories, implement the change and push people to hold the line until a new habit/guardrails begin to form. For example, if teams have yes’itus, implement a policy where all work has to be placed on the backlog and then prioritized by the team before it can be started.

Tackling work entry problems can be easy but most of the problems boil down to culture. Change requires drawing hard lines and then holding to lines until the new behavior becomes second nature. This might sound draconian, but the risk to the business is just too high to let work hit the team haphazardly.