WTF are your employees doing all day? Are you really ready to move to Agile?

How many hours are a day are your employees in front of a computer? On their smart phone doing work?

Are they working on planned work or unplanned work?

Urgent work or non-urgent work?

Are they waiting on others? Fixing defects? Working too hard for something that should be easier? Producing extra output that is not needed? Attending meetings they do not need to be in? Reading emails they should not have received?

Reassigning work they should be doing? Not delegating work they should NOT be doing?

Most likely, your employees are wasting time on work activities. Unfortunately, you don't know HOW much time they are wasting. And, your employees likely do not know what work is wasteful. They may not be empowered to fix it.

We see a lot of companies struggle with the transition to Agile. Before changing how your employees work tomorrow, you need to know how they are working today. You need to make your employees aware of what they are doing today, the inspire the desire to change, and give them the knowledge how to change.

Blue collar waste is easy to see - if you are looking

Before computers, it was easier to see wasted time. It is still easier to see wasted work in blue collar work or physical activities.

I grew up in the Panhandle of Oklahoma. Heart of the Dust Bowl. Home of the Fukawi. No geographic feature between the Gulf of Mexico and the Artic. Very few trees. Skies for miles. It wasn't the end of world, but you could see it from there.

It was easy to see where the bottlenecks were during wheat, corn, and milo harvest. I wasn't a farmer. But I mowed a lot of grass and weeds as a teenager. I used tractors, riding mower, push mowers. I even had a manual mower (non-electric). I had the time, while I was working, to understand the different types of TIMWOOD waste:

• Transportation - moving the mower
• Inventory - grass that needed mowing
• Motion - taking a route through the field that I already cut
• Waiting - waiting for supplies or the grass to dry
• Over Processing - having to slow down in heavy grass
• Over Production - cutting grass sections that were too short
• Defects - looking back and finding a section I missed

It was hard to multi-task on a mower in the 1980s. It was hard to even listen to music. You had to focus on a single job for a good chunk of time. You had time to think about what you could do better, faster, or cheaper. I'm still upset that I didn't think of this solution.

White collar waste is harder to see

In the white collar age, employees look busy because they are in front of a screen typing. Or scrolling. Or sitting on a video call trying not to look distracted. But they trying to work on multiple tasks when they are on conference calls. Checking emails. Responding to texts. Trying to avoid Slack and Teams notifications.

Employees can get into autopilot mode and crank through work. They may even be experts for a lot of work and can do most of the work without thinking too hard. This is the System 1 part of your brain from Daniel Kahneman's Thinking Fast and Slow.

Employees and employers seldom step back and think about what work they should be doing. What work is wasteful. What work is valuable. What work is urgent vs non-urgent. This requires the System 2 part of your brain.

In the white collar world, identifying what is waste is more difficult than my mowing example. White collar workers shift jobs.

Using the mowing example, a white collar worker is more like a gardener. He or she could be mowing, planting seeds, pulling weeds, spraying for bugs, talking to friends/family, trimming bushes, etc. All in the same day. Sometimes the same hour.

Context switching is difficult. Imaging working in your yard, spending 10 minutes mowing, then 10 minutes pulling weeds, then killing bugs. Then repeating that process in a different order. That is more like white collar work today. System 1 thinking makes it worse.

Agile is based on Lean principles. Lean focuses on eliminating waste.

We recently taught several Agile/Scrum workshops to one of our clients. This client has a SaaS solution for enterprise customers. But the product and engineering teams were not making progress against their backlog.

One of exercises we have attendees do is a Waste Walk. We have attendees identify waste in their Software Development Lifecycle (SDLC). As you may expect, attendees were able to identify various types of waste at each (every) step of the SDLC. They were able to quickly identify the waste because they were able to focus on each step of their SDLC.

Identifying waste is MUCH easier if you have your processes documented visually. The SDLC waste exercise was pretty easy for attendees because we spelled it out. And Waterfall SDLC's are pretty linear. And old ones are pretty wasteful.

Agile does not eliminate all waste for product or engineering work

If you have fully dedicated engineers only cranking out code with zero errors in a CI-CD pipeline, you can eliminate a lot of waste. But you can't completely eliminate some forms of waste. That is OK. But you should be aware of it.

To have a chance at implementing Agile, teams needs to know what types of work they are doing today. They need to know what techniques and tools are most effective for each type of work. They need to know what they need to STOP doing. The days are NOT getting longer.

The client that I mentioned earlier had a very, very large backlog. The engineering team wasn't making progress to the satisfaction of the product managers. The backlog was getting longer and longer. Friction was forming between the engineering and product teams.

On one hand, it was good that the team could see all of the work in one place. On the other hand, it was demoralizing. Product, Customer Support, and Professional Services were filling the queue. They were putting "20 lbs of stuff into a 10 lb bag".

Filling the 10 lb Bag with Good Stuff

To deal with more work than you can do in a given amount of time, we have our clients think about 5 general types of work:

• Projects
• Programs
• On Demand Requests
• Emergencies
• Products

These types of work apply beyond product and engineering teams. But these two teams usually have to deal with all 5 types of work. As an aside, we want our clients to avoid any walls between these 2 organizations.

We believe organizations and most of their employees need to have awareness of these 5 types of work. We also believe some leaders need to be experts in each of these 5 types of work. Each type of work has different, but somewhat similar, tools and techniques for mastery. We see too many clients using the wrong mix of tools and techniques. They inevitably start filling up 10 lbs bags with 20 lbs of stuff.

5 Types of Work - Tips and Techniques

Here are some quick descriptions of each type of work:

Projects - a project typically has requirements, a design phase, a build phase, and a testing phase. It frequently requires different experts. It typically follows a linear progression. Mastery requires understanding the order, duration, and variability of tasks. It only works well with well defined requirements that are easily understood by engineers. Advanced project management skills are needed here. Those that can do MonteCarlo simulations are signs of an expert here. Even in an Agile organization, certain types of work still need traditional project management tools and techniques.

Programs - are similar to projects because they have tasks and dependencies. But they are well rehearsed. Variability can be reduced. You typically know the critical path. The first time you do it feels like a Project. It should be easier and easier to get better and more accurate. Mastery here is the discipline of process mapping. Identifying and eliminating waste and bottlenecks is a key skill. You know when these types of work occur, so you can ramp up resources or ramp them down.

On Demand Service Requests - these are typically repeatable. Some are ad-hoc. Bug requests and small incidents fall in this category. Create an environment or provision a server fall in this category. Kanban is a good technique here. As is process mapping.

Emergencies - this is drop everything. All necessary hands on deck. Get your experts on the call to mitigate the damage and restore service. Then make sure it never happens again. Practice, particularly real life ones are the best skills here.

Products - a product or service is trying to solve a market fit. The more that you can iterate on what works and doesn't is a priority. It requires dedicated teams. It is VERY different from a project. However, many companies treat products like projects. Agile techniques, and Scrum in particular, are very effective for eliminating waste for Software Product teams.

Before easing or jumping into Agile, be cognizant of how you are managing the 5 types of work.

Always be aware of WIP or Work in Progress. What types of work are you and your teams working on daily? Weekly or monthly? Don't overburden your team. Try to reduce the types of work for each individual.

For the recent Agile workshop we did, the majority of attendees were doing 3 or more types of work in a single day! They were using a single tool and queue to manage all 5 types of work. They had 100 lbs of stuff for 20 lbs bag.

The quick win was to pull out a good chunk and use Kanban to crank through a backlog of quality issues. We had everyone focus on 20 lbs of stuff.

The longer term solution was to reorganize the teams by product rather than function. That is, each product team had a Product Owner, 1 or more engineers, 1 or more QA, and 1 UX. We split the remaining 80 lbs into four 20 lbs bags.

We recommend small, autonomous teams organized by product. Proper application of Conway's Law avoids large, costly hierarchies, delays, and politics. Cross functional and durable teams that have gone through Tuckman's stages are typically the most productive for creating products valued by the market.