The team was struggling. They were working on an industrial motion control product, porting a legacy code base to a new hardware platform. Parts of the code were decades old, and many of the original developers no longer worked at the company. They kept getting stuck trying to figure out how the code worked and what they needed to do to make it work in the new system. Neither the engineers nor the product manager had visibility into what was taking so long or how to help.
Whether or not you have worked in product development, this situation probably sounds familiar. Whenever a team works on anything, there will be surprises. Unexpected requests, discoveries, or circumstances can cause teams to get stuck and to waste time and energy. When handled poorly, this breakdown in transparency and flow also creates stress for people inside and outside the team. Effective teams realize that the key to dealing with unexpected events is less about planning the work and more about managing it. This is a story about how a team I was on decided to manage their work.
Dealing with Surprises
Around 2010, I was an engineer on the team I mentioned above. Half the team had extensive experience in motion control but little experience with modern software development practices. The other half of the team was the opposite: they knew how to write maintainable software but had little domain-specific knowledge. These factors – plus several others – made it very common for us to get stuck trying to figure out what some of the code did and what was needed to make it work in the new system.
Fortunately, we had a very obvious signal that this was happening. We were using Scrum with a simple visual management system. We had a combination story-and-task board with three columns: Not Started, In Progress, and Done. When we got stuck, the task hung out in the In Progress column. We had a habit of breaking down work during refinement so that tasks were expected to be completed in a day or less. Of course, sometimes we were wrong. Being wrong about it wasn’t a problem, but losing perspective and not asking for help was.
To deal with this, the team adopted a rule: “When we notice that a task has been in In Progress for more than a day, we will have a team conversation about what’s happening and what we can do.” That conversation was a space for curiosity, not blame. The person or people working on the task would explain what they had done so far, what they thought was left, and what they were stuck on. Sometimes they weren’t stuck; things were just taking a little longer than we expected. In this case, the task was usually finished the following day. Sometimes we would split the task into the part that was done – which would get moved to Done – and the part that remained, which stayed in In Progress. When things were stuck, someone on the team would usually join in and help. Bringing in someone with more experience in that area often did the trick.
Taken together, these actions kept us from staying stuck for very long. They also helped our product manager understand the state of the work. Stories and tasks kept flowing across the board at a reasonably predictable pace, which helped us to plan more effectively. The conversations helped us learn more about where surprises were likely to be lurking and what we could do when we encountered them.
Understanding Work Items, Aging, and Policies
The idea behind what we did is called work item aging. It comes from Kanban, but we found it useful in Scrum. It’s a concept with wide application. Most groups and teams have a way of tracking their work and modeling their workflow. This might be a physical board or an electronic tool that models how work moves through the team. The things that move through it – whether they are software features, sales leads, or customer orders – are work items. At some point, a work item enters the workflow, meaning work on it has been started. When it exits the workflow, it is finished. For a work item in the workflow (i.e., one that has been started but not yet finished), its work item age is the amount of time elapsed since it started.
A policy for work item aging is an agreement about how the team will respond when some aging condition is met. These are often of the form, “When we notice X, we will do Y.”
Some examples of aging policies a team might adopt:
- “When we notice that an item has been Waiting for Test for three days, we will not start any new items and instead help to clear the testing backlog.”
- “When we notice that an item has been Blocked on another team for more than two days, we will update the Blocked register and talk to the other team.”
- “When we notice that any item’s age has reached 50% of our Service Level Expectation, we will discuss how to address it.”
These agreements specifically address how the team will respond when something they didn’t expect occurs. They clarify how a team wants to manage surprises, often in a way that improves transparency and flow.
Improving Transparency and Flow
Using work item aging as a signal helps counteract human tendencies to lose perspective and not ask for help when things go wrong. Unexpected events cause the human brain stress and anxiety. In this state, it’s common to turn inward, focusing on the problem. The more stress-inducing the surprise is, the less likely we are to spontaneously share information about it and to ask for help. When we do finally, the problem has likely gone on too long. Having policies around work item aging creates an external trigger for intervention. It reduces the need to notice and admit that we could use help.
A good starting point for creating policies in a team is to ask, “Where do we wish we had raised concerns or gotten help sooner?” The policy that my team adopted came out of a retrospective where we had asked ourselves this very question. We looked over the work we’d done – and the challenges we had with it – in the several months prior. What many of the incidents had in common was that they involved “small tasks” turning into time sinks. We’d usually hear one person saying, “Yeah, it’s complicated; I’m working on it” for weeks at a time. We agreed that way of responding to the situation was understandable and not useful, so we agreed to try doing something different.
Over time, we found this policy profoundly shaped our way of responding to unexpected difficulties. At first, we hit the trigger two or three times a week. Over time, it happened less frequently. This was partly because we got a sense of where we were more likely to encounter problems, and we prepared appropriately. It was also because we got better at recognizing when we were stuck and raising issues sooner. I remember thinking at one point, “Well, I’m going to have to talk about how this is stuck in our standup tomorrow… I wonder if Carol is available to look at this now?”
Getting Unstuck
There is no one-size-fits-all solution for managing unexpected events – context matters. If you want to get unstuck sooner, consider running an experiment to manage work item aging. What policies might be helpful for you and your team? Where does work get stuck or slow down, and how could you raise awareness of that earlier than you do now? Deciding how to manage work item aging is a powerful tool for improving transparency and flow. It’s a handy one for any team to have in its toolkit.
