I located a job as an Agile Coach working at Yahoo! headquarters in Sunnyvale, CA.  I worked with a group of internal coaches, offering both training and coaching for the nearly 500 teams that were experimenting with the Scrum framework inside the organization. My directive there was to observe teams in action and offer help when asked.

Observing Team Behavior

Pretty soon I was invited by a Product Owner to observe his team’s stand-up. This team sensed that something wasn’t right with their Scrum implementation and he was seeking advice. They had also recently lost their ScrumMaster and people were wondering what might happen to replace him.

Walking through the buildings from where I worked, I arrived a little early to the meeting and soon about 20 people filled the conference room. When everyone got there we quickly went around the room and everyone said something about what they were doing.

The tone most people used sounded like a status report. I couldn’t detect a common thread woven through what people talked about. I looked around and did not see a Sprint task board anywhere. The meeting lasted for only 15 minutes and then everyone immediately exited the room.

Investigating the Situation

Asking around afterwards I found that the information stored electronically was out of date, having been maintained by the ScrumMaster who had left. Nobody was really thrilled with the electronic tool, something swiftly put together internally to support one of the first Scrum teams. Although many teams used the free tool it was no longer supported nor maintained by anyone.

The Product Owner, a couple of managers, two leads and myself discussed an approach. We concluded that it would be best for me to embed as ScrumMaster for a while, perhaps a couple Sprints or more. This would allow me close inspection of what was going on. It would give the team some time to find a replacement and for me to hopefully work with that person.

Observing a couple more stand-ups I found it very difficult to discern what the expected outcome was of all this work that the team was doing. I spoke with people about how many tasks they currently worked on, and what those tasks were.

Most people worked on more than one Product Backlog item at a time. Some people worked on several items concurrently. Nothing had been deployed to production for over a quarter now. There were around 600 open bugs, and technical debt mounted with more being opened than closed.

Exposing the Work

After discovering all of this, I arrived at a stand-up with a pile of sticky notes. I passed them out and asked people to write down what they were working on, one task per sticky note, and to put how many hours remained. I then asked people to initial their sticky notes and place them on the white board. We clustered tasks together and wrote down what Product Backlog Items they belonged to. The resulting sticky notes covered two 4’x8’ whiteboards on one wall and one more board on the opposite side of the room.

There was a shared concern that the team worked on too many items. Seeing it hanging on the wall all around them convinced everyone. The team decided not to take on any more work until the current work in progress diminished significantly. The Product Owner prioritized the list and provided focus for the team as most people had tasks for more than one item.

The Effect of Work Limits

We calculated how many items finished weekly. Looking at this number along with team size helped us establish a limit for how many items could be in flight at any time. Before long, the team finished one Product Backlog Item every two to three days and deployed two to three features per week. Hours were no longer tracked. The bug count went from close to 600 to several dozen and eventually down to zero bugs open by the end of a Sprint.

The highly visible task board continued to be modified by us and now fit on a wheeled 3’x5’whiteboard and stood where people worked. The Product Owner was happy with what he saw and I caught him once hugging the board. Having the work visible resulted in better preparation and understanding by the team of the flow of features desired.