Several years ago, a client, Alex, asked me, “What's wrong with this team? They don't want to learn anything.”
I was surprised. I asked him for more information.
“Well, when I ask them to use TDD, they don't want to even learn about it. When I ask them to use CI, they don't want to. I don't know what to do,” he said.
I asked this question, “How much pressure do they feel? People under pressure don't want to learn because all they can do is what they know how to do, to finish the work. It takes time to learn new techniques and ways of working.”
“I only ask them to do what they've always done,” he said. “They're not doing that much overtime.”
Ah. I understood. This team felt the pressure of too much work in too little time.
Alex thought the team was wrong. Nope. Alex was attached to his version of what he though learning meant. And, he hadn't created a reasonable environment where the team could learn.
The Team Isn't “Wrong”
Another client, Belinda, asked about her team's board. “Now that the team works from home, I wanted to check on cycle time, and see where we have delays. And, I think cycle time would help us better for our longer- and short-term estimates. But, the team doesn't really use the board. I can't see the cycle time.”
She explained how the team regularly finished 3-4 larger stories and 5-6 smaller defects and production support issues each two-week iteration. I suggested she already knew the zeroth measures for cycle time: 3-4 days/story, 2 days per small thing. Was that enough information?
It was to start. But what about seeing delays?
I asked if the team felt as if they had delays.
No, they didn't.
We spoke more about the board, and she realized that she didn't have much confidence in any of the columns—especially the column about being ready to deploy. The team didn't find their board all that helpful.
I asked if that was a team problem or a management problem.
She wasn't sure.
I'm not positive, but I think it's more of a management problem. Belinda can't see the work as it flows. The team is fine with how they use their board. Belinda has no insight.
I'm sure there are more problems like this that you've seen. Managers have a problem. The team needs to “change.”
Let's take that apart for a bit.
Manager Problems Differ from Team Problems
Alex and Belinda both have team environment problems. In Alex's case, the pressure on the team created an environment where people stayed heads-down, delivering. (Yes, they felt as if they were a feature factory.)
Belinda's problem was different. The team proceeded well—and she couldn't see their environment to see how she might serve them better.
Alex created his problems—of micromanagement and of asking for overtime.
Belinda has a problem of insufficient visibility into the team's work.
I suspect many newly-remote managers have a similar problem: how to see inside what the team does, with micromanagement? Especially if the team doesn't use their board?
Attached to the Process or the Outcome?
When I think about my management problem solving, I need to check:
Have I already decided on the right answer/right solution?
If so, I'm probably attached to the process, not the outcome.
Alex was attached to the process of team learning, specifically for TDD. And, he didn't realize he needed to change the team's environment to achieve that outcome (or anything like that outcome).
Belinda isn't attached to cycle time, but she would like to see the team consider that as an option.
She's also worried about why the team doesn't use the board.
She's attached to the outcome of achieving more visibility—not any specific method or approach right now.
Influence for Change
If you want a team to change—especially if they're making progress now—you'll need to offer a concrete reason for them to consider a change. (See Influencing with Integrity.)
Belinda could say, “I'm worried that I don't have enough insight into what you're doing. I don't know where I could nudge the environment to be more of what you need and less of what you don't need. Can you help me?”
That might be useful. It's concrete and understandable to the team.
Belinda doesn't yet have a specific outcome. The team needs to help her discover that request.
In my experience, when you ask for help and explain what you need help with, you're more likely to get it. You don't have to know the answer. You do need to know a little about the results you want.
Teams Can Choose Where and When to Improve
I'm a huge fan of TDD and cycle time instead of story points. However, even I know I can't mandate either of those changes for anyone else.
I can create a culture of experimentation (and here). When we experiment, we can see where changes might work.
And, that's what I suggested to Belinda, starting with herself.
What could she do to make her work more visible to the team, so they would see where she was missing data? What was her cycle time—especially for decisions that affected the team?
When I suggested to Alex that he apply TDD to his management, he scoffed at me. Oh well. If he had tried to apply TDD to his management, he would have seen the pressure.
As a manager, make sure you understand the team's reality before designing a solution. You might not know. They might not know what you need. And, watch that you don't become attached to a specific process, instead of an outcome.
Pingback: On Technical Excellence | testkeis