Plan the work, Execute the work

This post was originally published on CIO.com on November 21st, 2019.

Background

We had just acquired the company and I was getting introduced to different members of the engineering staff. I was asking all sorts of questions about how the architecture was laid out, what their workflows looked like, etc. Then I found out that their on-call rotation was a nightmare. “Why don’t you work on improving the stability of the infrastructure?” I asked.
“We’re too busy” came the response. “You’re too busy to stop your life from being a never ending Groundhog Day of fighting fires?”.

I couldn’t believe my ears. But in many organizations, the method for choosing work is to work on whatever is in front of them at the moment. The thought process is “If something new lands in front of me, I work on that.” By doing so, we can keep ourselves very busy, and at the end of the day, we are tired. However, rarely is there a sense of accomplishment, because rarely in those circumstances are we actually productive.

Productivity

The 2019 State of DevOps Report defines productivity as “…the ability to get complex, time-consuming tasks completed with minimal distractions and interruptions.“ According to this definition, there are a number of conditions that must be satisfied for one to be productive:

• A block of time (not just 15 minutes here and there)
• Minimal distractions
• The work needs to be complex

Peter Drucker wrote in The Effective Executive (also talking about knowledge workers) in 1967: “The more he switches from being busy to achieving results, the more will he shift to sustained efforts - efforts which require a fairly big quantum of time to bear fruit.”

Going back to our example of the acquisition above, we don’t find any of these conditions met. The team was being paged constantly, which meant there was no opportunity to work for a block of time. The pages themselves were a constant source of distraction, and were often ignored. The remediations for these items were never complex, it was always the simplest action that could be performed, in order to get past the current alert. When talking to the engineers on this product, they always talked about how much work they had to do, but it was all toil, it was never productive work.

In order to be productive, we need to plan the work and execute the work. If we only work on things directly in front of us, we will never be productive. Productivity will not find us, we need to find productivity. In fact, the only way to get out of the situation above is to be productive.

A block of time

Because we want to work on time-consuming tasks, we need the most important resource of all, time.

Drucker observed: “Effective executives know that time is the limiting factor. . . .Of the other major resources, money is actually quite plentiful. . . People – the third limiting resource – one can hire, though one can rarely hire enough good people. But one cannot rent, hire, buy, or otherwise obtain more time.” If we don’t have the ability to make more time, then we need to be as effective as possible with the time we have.

Agile

One way of doing this is to have structure to our work. I’ve written in the past about Agile meeting schedules and why this structure is essential to being productive. I’ve had people work for me who’ve said that their previous engineering teams would have a meeting once every few weeks. They felt like they were left to figure out what to work on, and every few weeks, they would have an inefficient meandering meeting that was supposed to tell them what to work on next. They did not feel like there was a real plan for the work to be accomplished.

Part of the reason we have so much ceremony in Scrum, is that we are trying to be as predictable as possible about the output of the team. Of this, Sprint Planning is probably the most important for productive work. During this meeting, the team agrees on how much work to take on based on past performance, and what those specific work items should be. This predictable output is by definition, productive output. It is also output that is based on a prioritized backlog, which we discuss below. A high performing Scrum team is a productive team. A team where the velocity is extremely low, or varies wildly from sprint to sprint, is unlikely to be very productive.

20% time

There have been many different takes on Google’s idea of 20% time, but regardless of the implementation at different companies, the idea remains that time can be put aside for the purposes of exploring new ideas. The output of this exploration (i.e. innovation) time is often complex, and whether it leads to a new product or not, it is still productive time. Google has a word for work that is not productive, which we will talk about when we explain complex work.

Minimal distractions

Prioritization

One of the best ways to minimize distraction is to make it clear what the priorities are for our teams. Giving overall approaches to how they should think about their work is good and sets the team in the right mindset. But the work that has to be done in order to be productive must be prioritized in a structured manner if we are to ensure that we are always working on the most important work for the business. This means teams sitting down with a leader (in Scrum this is the Product Owner) who has already groomed the backlog of items for work that are not a priority. It also means discussing and ranking the work.

When teams negotiate a prioritized backlog with their leadership, it is essential that there is never a question as to what is the most valuable work to be done. The work is always planned, and if someone were to work on reactive work, which was not prioritized, the rest of the team would ask why they were not working against the backlog. This also allows us to make long term plans, as we have the ability to break up work into smaller units, and then move those units to the top of the backlog when necessary to achieve the longer term goals.

If we were to try and tackle the problem we discussed at the start, with the team that was getting paged constantly, we could assign some team members for reactive work, and assign other team members dedicated to making that type of work go away, rather than burning out the entire team.

The 4 Flow types

When it comes to allocating the work during prioritization, we can do so according to the 4 different types of flow items as outlined by Dr. Mik Kersten in From Project to Product:

• Feature
• Defect
• Risk
• Debt

Depending on the needs of the business at that time, we can allocate these types of work in different ratios. Are we near the end of the year and want to focus on stability? Perhaps we lean more heavily on Risk and Debt. Are we trying to get a major new release out by the end of September? Perhaps we prioritize Feature delivery. In any case, we want to ensure maximum productivity out of our teams, by keeping the work they perform as highly aligned as possible to the needs of the business. This is being Agile, as opposed to doing Agile.

But, what if there are more things on the backlog then we can get done? What if people are adding items to the backlog faster than we can move them to Done? This is where our focus on productivity can really shine. We will never get through all the items in the backlog. The sooner teams give up on that fantasy, the sooner they will get down to the business of maximizing their productivity with the time they have. If we are always working the most important items, we are always being maximally productive. If the business can see how much work is being accomplished, and there is still a desire for more work to be done in a given amount of time, that is when we can start having discussions about increasing efficiency or headcount.

Complex work

In order to perform complex work, we actually need to be doing complex work. Not spending time on items that do not contribute value to the business.

Toil

If a requirement for being productive is our ability to accomplish “complex, time consuming tasks”, then Google’s Site Reliability Engineering departments have defined what most of us would recognize as the opposite of productivity, toil.

Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. - Vivek Rau

The Google SRE Book has a lengthy discussion about toil. Just like in our discussion of Agile above, we do not want to spend a significant amount of time on toil. With many of my clients, I will use the parts of the business executing the most toil as the starting point for discussions about where we can make improvements. You should recognize by the definition above, that toil is not productive work. We do not need to clear large blocks of time to concentrate on accomplishing toil. Toil tends to be the type of work that winds up “in front of us”, and therefore it’s what we end up working on. Toil is typically not planned, unless it is part of a larger effort to actually eliminate toil, as in our example above about setting aside some members of the team to work on toil, and some members to work on process improvement efforts.

If you recognize the definition above as being most of what you spend your time on during the work day, then you are probably not planning the work to be done, and then executing against that plan.

Time thieves

In addition to toil, we must also be mindful of the “Time Thieves” as described by Dominica Degrandis in her book Making Work Visible when executing complex work. In her book, Ms. Degrandis discusses in depth the problems with:

• Too much work-in-progress (WIP)
• Conflicting priorities
• Unknown dependencies
• Unplanned work
• Neglected work

Each of these “thieves” can keep us from being productive. If we have too much work in progress, we actually accomplish less. Conflicting priorities can leave us oscillating between things that are never completed. You get the idea. Each of these thieves stand in the way of us being able to move items to Done, and work on the next complex task required to keep our businesses moving forward faster, and with more quality, than the competition.

Conclusion

Too often our teams get caught up in the day to day of running the business. They are never idle, so therefore, they feel like they must be getting a lot of work done. However, that is not necessarily what is best for the business. In order to be truly productive, we must approach our work deliberately, not simply using recency as our measure.

By doing so, we can execute major changes to our processes, our culture, and our infrastructure. Being Agile along the way allows us to adjust course as we go, so that we are always working toward the right goals. When we plan the work, and then execute the work, we enable the capacity to do great things.