If you want to get ahead, DON’T look busy! 

By Pete Oliver-Krueger 

My First Job 

My first job was at a McDonald’s, like many, and I have a vivid memory of one scene shortly after being hired. There was a slowdown in customers so I was just standing at the register when a manager turned to me and said, “You can’t just stand there. Look busy. Grab a rag and clean something.”

Has this ever happened to you? I’ve since heard similar stories from many others. The philosophy is that if customers see you standing around, any problem they see will be amplified, e.g. “This ______ needs to be cleaned, and the staff is just standing around. Lazy bums!” Instead, if we “looked busy”, they would say, “This isn’t great, but look, they’ve got a lot to do already. What hard workers!”  

My First Computing Job 

My first job out of college was at the Robotics Institute at Carnegie Mellon. I surprisingly received the same advice, though in a new form. I finished my first programming assignment, and took it to my boss. He had a concerned look on his face and asked me to sit down, closing the door. He explained, “Pete, the pace of work in the real world is not the same as in classes.” [Carnegie Mellon computer science classes are intense! Freshman year I spent 40 hours each week just on a single comp sci class, and then still had 4 other classes.] He continued, “I wish someone had told me this… Our graduates work too fast. That job was supposed to take you all week. If you finish too fast, a couple of things might happen. Some people could resent you for making them look bad. Others will take advantage of you and assign you all the work while they sit back.” He continued, “Slow down. Look busy, but take your time.” 

“Look Busy” Has Many Forms 

I was reminded of these pieces of well-meaning advice when I recently worked with a software development team (with internal customers) as part of an Agile Transformation. They had developed a reputation for taking an excruciatingly long time to get work done. A simple piece of work that should have only taken a few days would take multiple sprints to get completed. Their whole project was supposed to have taken 6 months, but was instead in its second year, and the upper management was not happy. Not happy at all. They were ready to shut down the whole project and turned to me as a final attempt to salvage some level of success.  

I uncovered the reason why at their next Sprint Planning event. (Or, more accurately, I found the door that would eventually lead me to the reason.) “What’s ready in the backlog?” I asked. “We have some bugs, but we’ll be finished with those in the first two days of the sprint,” was the reply. Someone else chimed in, “We have a few stories that are almost ready. We can get started on those.” The manager leans in to me and adds, “We have to keep the programmers busy, so we tell them to get a head start on the next sprint.”  

I can appreciate the instinct. It comes from a desire to pull your own weight, to be a contributor. It’s not the same “Look busy” that I encountered before, but a close cousin. And, unfortunately, it covers up the real problem, so I always try to stop the practice when I see it. It always ends up obscuring the problem. Multiple problems, actually. As their coach, I made a recommendation, “I don’t want you to work on anything until it’s formally Ready for Development. Instead let’s use this sprint to groom stories for our next sprint. And while we do that, let’s conduct an extended 5 Whys analysis.” 

The 5 Whys Revelation 

“5 Whys” is a technique from Taichi Ohno, the father of Lean, and the Toyota Production System. Essentially you ask “Why?” 5 times to uncover the reasons behind the reasons, until you find the true, core reason(s).

The first Why was, “Why aren’t these stories ready?” They responded, “We actually thought they were ready last sprint, but when we delivered the code, the other team said that they couldn’t use it.” “Why not?” I asked. “That’s what we’re trying to figure out, but they’re not available for a followup meeting…” Two days later, we finally were able to get everyone together to discuss. The Product Owners for the other team explained that the logic of the code didn’t match the industry standards. “How so?” I asked. After two hours, a bunch of sticky notes, and a lot of whiteboard time, we had mapped out a workflow diagram of the logic of the system, and finally figured out what the code needed to do.  

The next day, the programmers delivered the fixed code to the other team’s developers. One day later we heard back that this wasn’t acceptable either. Three days later we finally scheduled the followup meeting to explain why.  

The second Why was, “Why can’t you accept this code? Does it match the logic diagrammed in the last meeting?” “Yes,” came the reply. “Oh, did we make a mistake in that logic?” “No, the logic is right,” was the response, “but the server only delivers one response at a time. We are always processing this data in batches. To use your code, we’d have to loop through each request, send each one to the server, and then re-combine all the results. That’s a nightmare to code and very inefficient!” This, of course, prompted the inevitable push-back, “But you didn’t tell us that you needed it in batch!!” …After a little calming, and some light conflict-resolution, the programmers were ready to get back to work. 

“No coding yet,” though, was my response. “What will this code look like when you’re done?” The programmers responded, “Like the existing code but inside an array.” “Show me,” I said. “Write it out on this sheet of paper.” After some scribbling, the developer from the other team interjected, “Could we get the date in a different format?” Another hour later and both teams were in complete agreement about format. “Beginning with the end in mind” (to quote the 7 Habits), the programmers went back to their desks and updated the code. The next day, the programmers from the other team integrated the code, and we were on our way! 

The New Definition of Ready 

These two practices, together with their test cases, became the team’s new “Definition of Ready”.    

1.  User Story Workflow 

• We established that every request (that was complex enough) had to have a User Story Workflow Map to describe the logic required, agreed upon and signed off by the Product Owners, the Architect, and the programmers. 

2.  Inputs & Outputs w/ Data Prototypes 

• Every new User Story also had to have Data Prototypes, mockups of what the server requests would look like, and mockups of what the server responses would look like, also signed off on by the application architect, and the programmers of both teams. 

3.  Test Cases 

• Lastly, to ensure that both teams shared the same expectations, all of the test cases for the Acceptance Criteria would be written up front. (Note: Acceptance tests, not Unit tests.) 

“We’re Bored” 

This provided amazing clarity that really helped unlock several of the stories that had become stuck in the backlog. In parallel to all these efforts, however, the programmers still came to management and asked, “Can you lift the ban against working ahead on the next sprint?” This brought us to our Third, “Why?” Their answer was, “We’re bored. We have nothing to work on. Nothing’s ready.” I get it. People want to know that their time is valued. People want to work on meaningful work. Given a choice, the vast majority of people want to work, not goof off. 

“Is there anything you’ve always wanted to work on?” I asked. It had been so long since anyone had asked them this question that it actually took them a little time to compile a list. For each of these items we asked our Fourth Why, “Why do you want to learn these new technologies, or work on these items?” 

The Priority of Work 

So, together with the ScrumMaster, we established a priority order for work: 

1.  Triage 

• Leave padding in every sprint to research any new bugs as they come in. 
• Do they have to be solved right away, or can they wait until the next Sprint Planning? 
• Are there any unknowns that require research, technical or business? 

2.  Committed User Stories & Bugs 

• Complete and deliver for testing any User Stories that are “Ready for Development” 

3.  Grooming for Next Sprint 

• Work with the Product Owners of the other teams on User Workflow Maps or Data Prototypes, to help get User Stories ready for the next sprint. 

4.  Personal Growth (Innovation Time) 

• If there is no committed work, and there is no grooming work, is there anything you’ve always wanted to learn about? Go learn it.  ‘
• Any technical debt that’s always bugged you in the code? Go fix it.  
• An architectural change you think would be helpful? Research it. 

5.  Other Bugs/Quick Wins 

• Is there an obvious bug that’s not high priority, but can easily be fixed? Go ahead and take the quick win. 

6.  Next Sprint Development 

• Only if you have exhausted all of the above options, and only if that work will not be impacted by any outstanding questions with the Product Owners, only then can you consider working on code for the next sprint. 

It took some encouragement, some enforcement, and some time, but eventually everybody started following this priority order. People started completing committed work, bugs were patched, and the clogged backlog gradually started to flow again. Management was happy. People had stuff to work on. And the teams were finally able to close out and deliver their entire backlog from two years ago. This made management even more happy! 

Epilogue: The Fifth Why 

There was a Fifth Why, though, that still needed to be addressed. Going back to the pilot User Story, when all was said and done, they had the skills to solve the problem, but why had it taken so long? The total amount of work done was only days, but it had been weeks to get everybody together, and again it had spilled over into the next sprint. I asked the teams, “Why does it take so long to get a meeting together? Aren’t you all working on the same thing?” It turns out that the Product Owners were actually assigned as Product Owners for 3 other projects. And the architect was assigned to 2 other projects, so finding a time slot that fit everybody’s schedule was nearly impossible, leading to days, and sometimes a week, of idle time. 

When I asked why they were split between so many projects I heard, “They’re very smart people. If we only had them assigned to one product line, then we’d miss out on their expertise in the other product lines!” Sigh. This is another version of “Look busy” that I encounter over and over again. Give people a lot of work on several projects. They feel valued, and everyone has the value of their expertise. BUT only when it fits everybody’s schedule. That’s where this model breaks down. By being available to everybody, they’re actually available to no one. The system was causing delays. 

A month or so later, and multiple conversations later amongst the upper management, people were reassigned. The architects and the product owners were assigned to only one product and taken off the other special projects, leading to more direct conversations between the programmers and the people using their code. This also prompted the Product Owners to eventually take full ownership of both the internal and external team backlogs. 

The results were dramatically different. Our “problem” team became known for fast delivery — they produced more work, in less time, and with less people than they ever had before. In fact, the biggest problem was generating enough work to keep them busy….er, I mean, “…to give them a steady flow of work that was Ready for Development.” They had enough time on their hands that, to fill the void, they spawned a dedicated team whose main focus was creating their own User Stories through innovation and optimization.  

The team that couldn’t get anything done was now ahead of the curve and learning to anticipate their internal customers’ needs. 

It’s (Almost) Never A People Problem 

In all my years as a team leader, then manager, and now as coach, it is (almost) never a problem with the people. It is always a problem with the system. In fact, even in that rare case when there is a problem with a particular person, only part of the problem is with the person, and the rest is with the system. It’s hard to take someone off a product, especially when they’ve put so much time, sweat, and (sometimes) tears into their work. But if the data says that the team isn’t producing, and you try removing someone and the output increases, you have to remove that person, and find them a new home. It’s not a statement about that person. It’s a statement about that system. It’s a corollary that also disproves the “Mythical Man Month”. Sometimes you produce more work with less people. 

In the End 

It makes me wonder what would we have gotten done at that McDonald’s all those years ago if we hadn’t just “looked busy”? What if we didn’t try to avoid angry customers? What if we instead had made ourselves available, not to avoid, but to listen through that anger, and to solve their problems? But that’s a lot to ask of an 18-year-old. It’s not a lot to ask, though, of a knowledge worker.