Until You Get It Right (Part I)
A two-part story about team behavior change told by Douglas Foster. Edited by Michelle Pauk.
“Don’t practice until you get it right. Practice until you can’t get it wrong.”
Agile coach Douglas Foster walks into an organization to help stand up three agile teams. After training the teams in Scrum, Douglas notices some command-and-control behavior from the teams’ Assistant Vice President. So he begins working with the AVP, doing one-on-one coaching every two weeks. As Douglas builds relationships with the team and their leader, he notices things are starting to sink in, but some behaviors still need to be shifted.
One day Douglas tells the AVP, “You can’t go to the developers anymore. You’ve got to go to the Product Owner.” She agrees, but they both recognize it’s going to be difficult for the team to learn to push back against requests from senior leaders. Some had been with the company for years and were seen as “go-to” people by their stakeholders. Unwinding patterns of behavior established through long-standing working relationships would be no simple task. Together, Douglas and the AVP design a rather unorthodox experiment.
At the next Daily Scrum, Douglas says to the team, “Look, we just had the company-wide employee survey results come in. They've asked the coaching office to take this data and aggregate it because the company that we hired to do the survey isn’t going to. It's more cost effective to do it in-house since you guys know Tableau. Can somebody pony up two to three hours over the next couple of days to help me consolidate this data and create some reports?”
One developer raises his hand and says, “Yeah, yeah, I’ll do it.”
What he didn’t expect was Douglas’s reply: “No, no! Do not accept work from anyone other than your Product Owner. You make commitments to the PO!”
Of course, Douglas had let the Product Owner and Scrum Master in on the secret, and they burst out laughing. Pretty soon, the whole team is laughing. The lesson is clear.
Two weeks later, Douglas is sitting in a one-on-one meeting with the Assistant Vice President. “Hey, will you do me a favor?,” he asks. “Would you be willing to go to the team during one of their Daily Scrums? Once they're through, would you ask them to go do something for you? I’d like for us to test them and see how they respond.” She agrees.
A couple of days go by. The AVP is finally available to go to the team’s Daily Scrum. They walk through their updates while she listens. At the end, she says, “Hey, team, this just came down from the Executive Vice President. I need help doing this. Can somebody step up and help me?”
Crickets. No one raises their hand.
Douglas had prepped the Product Owner and the Scrum Master in advance. They don’t intervene. The team is still quiet.
Finally Douglas prods them: “Guys, this is an Assistant Vice President asking you. What's the problem?” One developer reluctantly says, “We don't know if this is real or if this is another test!”
“Great job,” says the AVP, smiling. “This was a test and you passed.”
A few months later, Douglas asks the AVP, “Just be honest with me. Tell me what your thoughts are about this agile stuff that I've been preaching.”
“Douglas, seriously,” she says, “I have been able to focus more on strategy and gotten out of the day-to-day. It has been liberating. It has been liberating not to have to worry about those things because now I trust the team.”
