A recent coaching client was concerned about the progress his team was making—or really, the lack of progress his team was making. We spoke about the obstacles he had noticed.
“The team doesn’t have time to write automated tests. As soon as they finish developing or testing a feature, people get yanked to another project.”
“Are people, developers and testers, working together on features?” I wanted to know.
“No, first a developer works on a feature for a few days, then a tester takes it. We don’t have enough testers to pair them with developers. What would a tester do for three or four days, while a developer worked on a story?”
“So, to your managers, it looks as if the testers are hanging around, waiting on developers, right?” I wanted to make sure I understood at least one of his problems.
“Yes, that’s exactly the problem! But the testers aren’t hanging around. They’re still working on test automation for stories we said were done. We have more technical debt than ever.” He actually moaned.
“Would you like some ideas? It sounds as if you are out of ideas here.” I checked with him.
“Yes, I would!” He sounded grateful.
These were the ideas I suggested:
- Don’t mark stories as done, unless they really are done, including all the automated tests. You might need a kanban board instead of a Scrum board, to show your workflow to yourselves, inside the team.
- Work as developer-tester pairs, or even better, developer-developer-tester triads. Or, add even more developers, so you have enough developers to complete a story in a day or so. When the developers are done, they can see if the tester needs help with test automation hooks, before they proceed to another story.
- Make sure the product owner ranks all the stories in an iteration, regardless of which product the stories belong to. That way the team always works together, the entire iteration.
I asked him if he could do these things for the team. He said he was sure he could. I’d been coaching him for a while. He was pretty sure he could coach his team.
Now I asked him the big question. Could he influence the project portfolio work at the level above him? His managers were too involved in who was doing what on the teams, and were not ranking the projects in the project portfolio. He needed to influence the managers to flow work through the team, and not move people like chess pieces. Could he do that?
He and I started to work through how and who he could influence.
Technical leads, first- and middle-managers may find influence more challenging. You have to build rapport and have a relationship before you influence people. Had he done that yet? No, not yet.
You often need to serve your organization at several levels. It doesn’t matter if you are a technical leader, or someone with manager in your title. Rarely can you limit your problem-solving to just your team.
If these challenges sound like yours, you should consider joining Gil Broza and me in the Influential Agile Leader in either San Francisco or London next year. It’s an experiential event, where you bring your concerns. We teach a little, and then help you with guided practice. It’s a way to build your servant leadership and learn how to coach up, down, and sideways. It’s a way to learn who and how to influence. We have more sessions, so you can bring your issues and address them, with us and the other participants.
| Reference: | How Do You Serve Your Organization? from our JCG partner Johanna Rothman at the Managing Product Development blog. |
