Peter, the Product Owner was frustrated. The team delivered what he asked for, but it took forever and it wasn’t quite what he wanted. He knew he was partly to blame, but he didn’t see how to make the stories smaller. He decided to ask for help at the next retrospective.
“Guys, I’m not getting what I need, when I need it,” he started. “I know you’re all working as hard as you can, but I need more feedback from you and you need more feedback from me.”
Dan, a developer said, “I really wish you’d told me halfway through the iteration that you didn’t like what I had. I would have given you other options.”
Peter said, “I agree. I didn’t realize until all of you worked on that story that it wasn’t an MVP (Minimum Viable Product). It’s much more than that.” He paused. “And, I got it wrong. I didn’t even ask you for what I really wanted. I didn’t know what I wanted until I saw what you had.”
Sally, the project manager said, “Well, it sounds as if we have some data. Do you think we could gain some insights or are you ready to move to deciding what to do?”
Dan said, “You know, I bet there are more problems. How about if we re-look at all our data to see what else could benefit from more feedback? Then, we could generate some ideas and decide what to do.”
Peter nodded. “That’s a great idea.”
Get TestRail FREE for 30 days!
Double-Loop Learning Challenges Our Assumptions
You may know about “Plan-Do-Check-Act” or “Plan-Check-Adjust”, forms of single-loop learning. You may even have heard of “Plan the work and work the plan.”
The problem with single-loop learning is that it doesn’t challenge our assumptions.
Double-loop learning allows us to challenge our assumptions. We still Plan and Check. However as we Check, we can not just adjust the plan, we can adjust our assumptions–about our plan, our process, and what we are working on.
In this situation, Peter’s original assumption was that he understood what he was asking the team to do. He thought the work was an MVP. It was not.
The team had assumptions too–they thought that Peter fully understood his request and without everything, nothing was valuable.
As the team members discussed this particular problem, they realized that the technical team members–the developers and testers–needed to generate more examples with Peter before they started. More examples would help them see the complexity and help Peter see that the story was larger than he expected.
And, Peter wanted to see demonstrable progress every day, so he could learn what the feature looked like. Not the user interface, although he did want to see that. No, this was about how the feature worked with the rest of the system.
The entire team decided to try continual feedback.
Schedule Feedback Once a Day
Continuous integration, CI, means we check all the code and tests into the repository to verify the build still works, at least once a day. (More often, teams who use CI check in multiple times a day and build as often as they check in.) Peter and the team wanted to use continual feedback.
There’s a difference between the words “continuous” and “continual.” Continuous means without interruption. Continual means you repeat the action with a break between the action.
As a team, Peter and the technical team members, were new to this area of the code base. That meant all of them had trouble writing small stories. They didn’t always know what “small” was.
Peter also had the problem that he was new to the company and what the customers wanted. He didn’t have enough access to the Product Manager to learn. He and the team were learning as they proceeded. They needed more feedback.
Everyone decided that once-a-day feedback was what they needed. That might not be “continuous” as in several times a day, but they thought that would work. They decided to try for the feedback right after their 11:45 a.m. standup meeting, at noon.
That worked for a couple of days. Then, the team encountered a problem that they had thought was small. The problem was much larger than they thought it was. They started to discuss it with Peter. They discussed until 12:30 p.m. and people started to get “hangry.” (Hungry and angry.) They decided to go for lunch and reconvene in an hour.
They were able to finish their discussion after another hour.
Everyone agreed it was time to question their assumptions again. Maybe while they were all learning, scheduling a meeting just before lunch wasn’t such a hot idea. They decided to experiment with the time of the meeting. They set several meeting times for the coming week: 11 a.m., 3 p.m., and 5 p.m.
Experiment with Feedback Times
The team learned from their experiments. They had originally thought that their morning and late afternoon times would be best. Those times weren’t the best, because people were still in the middle of their work.
The team often paired and swarmed on their work. They didn’t mob yet, and weren’t ready to try it. Because people worked in various configurations, and not as an entire team, the morning and late afternoons interrupted people. And, some people had to leave during the discussions if the discussion went past 5:30 p.m.
However, the 3 p.m. time worked best. People were often ready for a coffee break, so they could have coffee and discuss their concerns, get feedback from Peter, and resolve their open issues.
At the next retrospective, Peter explained. “I’m a lot less frustrated with the features. That’s great. Now, I need your help making the features small enough, so we can finish them in one day.”
Dan asked, “Why one day? What’s so special about one day features?”
Peter said, “I need to be able to talk to my product manager and a couple of customers every day. When I either show them our progress, or explain it to them, they give me more ideas.” He shook his head. “I don’t always want to take their ideas before we finish what we, as a team, want to finish.
Dan nodded his head. “That makes sense,” he said.
“So, I need a way to either write smaller features, or to show progress, so they stop asking me to change everything before we’re done,” Peter said. “I don’t mind changing things after we finish something. I really mind before we’re done.”
Dan thought for a second. “Well, we all want a better product. I sure would like to finish things enough before we start on something new.”
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Continual Feedback Helps Us See and Challenge Our Assumptions
How are you using single-loop or double-loop learning in your project?
It’s great to have a plan to check and adjust as you continue. When we realize a certain story would be better before a different story, we might adjust the plan.
When you move from single-loop learning to double-loop learning, we check our assumptions. We don’t just work the plan; we can create new plans. We can allow for new plans because we can create new possibilities when we challenge our assumptions.
We might realize that the performance of a particular requirement isn’t sufficient as is. We can then challenge our assumptions about what makes the performance better or worse. We might create experiments to check our assumptions and create new plans for this story or even new plans for the project.
In this situation, Peter and Dan had assumptions about how the team could work. When they challenged those assumptions, they could address the way the team worked and how often they needed feedback.
Your team may have different assumptions about your work and when you might want or need feedback. The more feedback we can get from each other, the more we can feed-forward our new learning. Continual feedback can help us retrospect more often than once an iteration. Instead, we can use continual feedback for continuous improvement.
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.”
