22 July 2015
In a series of two blog posts, we interview management consultant and coach Johanna Rothman. Her latest book is Agile and Lean Program Management: Scaling Collaboration Across the Organization.
Mingle: You blogged about small world networking and ‘scaling out, not up’: what’s the key element for a feature team to be successful in this context?
Johanna Rothman: Feature teams have to be agile or lean and release often. They need to keep their code clean—technical practices are key in a program. If one feature team incurs technical debt, it will affect the entire program. Continuous and pervasive testing provide the support each team needs to collaborate with other teams.
Feature teams also need to build relationships across the organization. I realize many technical people are introverts. That means they might want to email rather than talk to people in person. That works, and the program manager might have to help these people meet at some point to build better relationships. In a co-located program, you can easily create communities of practice so people can talk about their challenges and resolutions.
Feature teams deliver completed features, manage their work-in-progress, and build relationships across the organization. They need to learn, ‘Who do I talk to about this issue?’
‘Feature teams have to be agile or lean and release often. They need to keep their code clean.’
Mingle: How can program managers help teams to self-organize into small-world networks?
Rothman: We actually organize into small-world networks all the time. I bet on a program, each team has a mailing list. And, there are cross-team mailing lists: by floor, by function, to name just two. How many mailing lists do you belong to? Where do you participate? Where do you monitor?
The places you participate are part of your network. As soon as you participate in more than one place, you are in a small-world network. You can help bridge the knowledge from one team to another.
What the program manager can do is to make sure the collaboration tools that your program needs exist. Do you need mailing lists? A wiki? Some collaboration tool that’s neither email nor wiki? How can you, as a program manager, help the people on the program collaborate and work together when they need to do so?
Mingle: What are the signals that a feature team doesn’t have a healthy status? What should program managers should do to help improve team health?
Rothman: I like seeing a product backlog burnup chart to see that the teams are making progress across the program. You look at the feature set by feature set progress over time. I also like cumulative flow to see the WIP. The teams need to see it at the team level, and the program needs to see it at the program level.
If you see a product backlog burnup chart that’s not increasing to show that the teams complete features, first you ask about the data. Maybe the team didn’t update the chart. Are you making it easy for them to update it? Maybe the team has other obligations. Can you stop the multitasking? Maybe the team didn’t know you wanted to see it. So tell them.
I have found that if you make it easy for people to bring you bad news, they will. If a specific team needs some obstacle removed, you can do that if it’s a program-level obstacle. If not, what do you need to do to facilitate the team problem solving it?
What the program manager can do is to make sure the collaboration tools your program needs exist.
Mingle: What is your advice on how stand-alone feature teams can solve cross-team dependencies?
Rothman There are a couple of ways. The first thing that stand-alone feature teams can do is start to create communities of practice so that they can say, ‘We have an inter-dependency over here. How did you guys solve something like that?’ Communities of practice will help solve problems across the organization, but they won’t solve impediments.
And there will be impediments that the feature teams cannot resolve alone. That’s where the software program team can come into play. You may find an impediment across the program. You might realize you need to do an architectural spike because you don’t have any idea how this is going to work. You might find the team needs a lab, or some other resource. These are things feature teams cannot solve by themselves.
Determining the type of problem is also important: Is it a collaboration problem to complete multiple features with inter-dependencies? Is it a function of knowledge across the organization? Determining the type of problem will help you determine what part of the organization would be most likely to resolve it. For example, if it’s an inter-dependency problem, small world networks could really help. If it’s an impediment, the programming team could help because they solve cross-program problems. Your function is to facilitate the solution, not manufacture it.