Stop Starting and Start Finishing: Getting to Done by Focusing on Work in Process

Continuing the “Principles of Done” series, this post explores the difference between being effective, efficient, and busy. (See Parts 1, 2, and 3.)

A story I like to tell is about working with a group at Microsoft. One of the PMs I collaborated with had a team that was faced with an ever-changing environment and specialty-based team members. During a standup, it was brought to the team’s attention that a story was blocked because the specialty team member was busy setting up his test environment. The team asked if he had to be the one to set up the environment. The answer was no, he did not have to be the one to set up his test environment and that, in fact, another team member could accomplish that task while he unblocked the team by working on the story.

Agile definition of doneWas it efficient for him to set up his own environment? Probably. Was it effective? Absolutely not. This is a story about focusing on the work and not the team member, and reaching the most effective way in which to complete the work. Teams have work and people to complete work. Adding to the complexity, teams sometimes have multiple types of work to perform.

Focus on the most important work and then focus on the most effective means by which to complete that work. This may mean examining a buildup of work in front of an activity and understanding why that buildup exists. It may mean changing how you do work or who does the work, or removing your title and focusing on getting work done. It may mean pairing team members to advance the team’s collective knowledge around a technical domain, a business domain, or both.

When I was at Premera Blue Cross as an internal business process consultant and later an IT leader, I was fortunate to be asked to participate in the Lean leadership program that the company had instituted. I learned many things in that program. Chief among them was how the operations leadership team approached maximizing the effectiveness of paying claims. The operations teams had a large visible matrix of activity and people (the activity title on one axis and team member name on the other). This simple tool allowed leadership to examine at a glance the progress they were making to get team members cross-trained in all areas of the claims model line value stream, so that when a claim came in the door it could be handled by one person (or as few as necessary). This was so that the claim could be paid as quickly as possible without having to hand it off into another queue of work and sit idle wasting precious cycle time.

Use this same principle. Work should not have to sit idle or experience a diminished value for lack of effective approaches to make the work flow.

In a recent coaching engagement, I heard about a team leveraging the efficiency of their software engineers — they were more expensive and the team wanted to handle the cost more efficiently. I asked what was more important. Was it more important to optimize on a title or the product? My advice to them was to think of it economically from the perspective of the product. Sunk cost already exists: You know you must have a certain type of software engineer, for example, so that cost is already incurred. The next order of business is to invest in delivering product effectively vs. using a resource efficiently just because they are paid more. You pay them more because you must pay them more based on market demand. The next economic factor is producing product with the people you have in the most efficient manner possible. It is a choice to be effective at the product level instead of being busy. You can optimize the title or you can optimize the product delivery or a combination thereof. Optimizing on someone’s title is at the expense of the product. Optimizing the product or a blend thereof is NOT at the expense of someone’s title. It may be a matter of pride, but the real goal is for a team effort to ship the product.

It is not more efficient or less expensive to optimize a resource if it means the product is late in shipping, because you incur opportunity costs and miss out on the increased cash flow that shipping would have provided.

Your individual contributor may be happy in the short term at the expense of the long-term goal of the product and that of the company. Given this, it is a wise use of a developer’s time to focus on other activity (such as testing, for example) in order to get the product to a shippable state more quickly.

When you do this, you end up managing the work-in-process to stop starting things and focus on finishing things. Getting to done means focusing on the right activity at the right time to deliver and be done.

In a future post, I will discuss other factors that contribute to not getting done. These include:

  • “Carry-over” stories
  • Defining acceptance criteria
  • Planning for support with project work
  • Unclear direction

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.