This is a guest post by Johanna Rothman.
One of the best things about an agile approach is fast feedback. Agile approaches encourage fast feedback between developers and testers, fast feedback between the product owner and the team, and fast feedback with the customer when the team can deploy fast.
Ann, a new test manager, had been in the organization for about a week. She’d just finished her one-on-ones with all the testers. She was a little worried about what she heard. She wasn’t sure the teams worked as agile teams. She thought some of the product owners created stories that were too large for fast feedback. And, one team seemed to have a huge number of interrupting defects.
In addition, her boss had told her that morning that the testers weren’t “fast enough.” When she asked how fast “fast” was, he answered, “Faster than they are now!” and walked away. That didn’t tell her anything.
Ann decided to take a systemic view of the teams, not just the testers, to see the various delays.
Separate Iterations Created Delays
Two of the testers worked with the Reports team. The entire team used staggered iterations—the programmers started to create reports in one iteration. The testers tested the results in the following iteration.
The Reports team wasn’t a true cross-functional team. They hadn’t changed their culture. As a result, everything they did took longer than they expected. Their average cycle time—the time it took for them to finish a story—took close to three weeks. That was the total programming plus testing time.
Ann mapped the value stream for the Reports team. She asked to have a brief meeting to show them the value stream and get their feedback.
Once they saw the value stream map, they realized what they’d done. They’d tried to “go faster” on the programming. But, that created a large queue of work for the testers. Instead of going “faster” as one part of the team, they decided to collaborate as a team and finish what they thought might be less work in a given iteration.
They decided to experiment for two weeks and see what happened. They discovered that when they worked together, everything took less time.
Large Stories Created Product Owner Delayed Feedback
While the Reports team experimented with working as a team, the Mail team experienced a different set of delays. The Mail team worked as a collaborative team. However, they couldn’t finish more than two stories in a given iteration. Because the stories were so large, Peter, the Product Owner, was not available when the team had questions.
Peter was a product manager. He was in meetings most of the days—with salespeople, with other managers in the organizations, and with customers. He needed to collaborate with all those people. The problem was that he wasn’t collaborating with his team.
He wasn’t always unavailable. He was mostly unavailable. But, the team couldn’t depend on when he would be available to answer their questions.
Because they were doing something brand new for the product, the team needed much more interaction with Peter, especially when it came to slicing stories.
Ann offered to facilitate a story-writing workshop for the entire team and Peter. While she didn’t know that much about the product, she understood story mapping and story slicing. Peter and the team worked for an hour on what Peter had originally thought was two stories. At the end of an hour, they had twelve smaller stories. The team thought these stories would take a day or two each.
Peter committed 30 minutes to the team each morning and each afternoon, at specific times. The team could ask him questions or he would offer feedback on the stories then. In addition, he decided to hire a full-time product owner for the Mail team.
Interruptions Created Delays
The Labels team customized various labels for their customers. Each label was relatively easy to customize, as long as the Labels team had the information and customer feedback. Their problem was getting customer feedback fast enough.
At first, Ann thought the problem was that the customers didn’t offer feedback fast enough. But, she dug into the problem more.
The Labels team couldn’t deploy on their own. They had to ask the Ops team to deploy for them. That’s because the Ops team wrote the procedures to change over the various printing machines and inks.
The company had a limited number of printers. Each printer took different varieties of labels. The Ops team managed the testing in preparation for shipping the custom label software to the customers. But, Ops couldn’t test anything in any order. They needed to sequence their work for a day at a time.
That meant that the customizations might stay in Ops for weeks. Then, some sales person would raise a ruckus, or a customer would call a senior manager, and Ops would rearrange their schedule.
Or, worse, Ops would release the customization without testing it at all.
One customer waited almost six weeks for their customization. The Labels team had only spent three days on their work. The customization waited in Ops for more than five weeks. Then, the customer called the Sales VP. The Sales VP ordered Ops to deploy even though Ops hadn’t tested the code.
The customer started to use the new labels and the customer found a problem. They yelled at the Sales VP, who yelled at the Labels team. The Labels team interrupted their other work to add this change to their Urgent queue.
When Ann looked at their board, the Labels team had seven items in their Urgent queue. The Labels team suffered from interruptions that delayed their regularly scheduled work. And, because they felt pressure, the team didn’t always fix the labels correctly.
Ann asked several questions, primarily about the availability of the printers and the packaging that Ops did. She calculated the Cost of Delay and learned what three new printers would cost.
Between the Ops delays and the Labels team’s delays and interruptions, the organization could have bought an additional six printers—one for each person on the team—and eliminated the delays.
The Ops team would no longer have to change over printers and inks. The Ops team might need to package release notes, but the Labels team already wrote the initial release notes.
Ann lobbied to buy six more printers. The organization bought three.
She measured the Cost of Delay after the team had the printers for three weeks. They had fewer delays, but they still had several items on the Urgent queue. She lobbied for the additional printers and got permission to buy them.
Now, the Labels team was fully independent of the Ops team. The entire system relaxed. The Labels team and the Ops team were happier. They didn’t have emergencies. The customers were happier because they received their customizations on time and they worked.
Long Feedback Loops are a System Problem
This article was written by Johanna Rothman. Johanna, known as the “Pragmatic Manager,” provides frank advice for your tough problems. Her most recent book is “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”
