There was a question on a LinkedIn group earlier this week about a program with teams with interconnected features and how did you know when a feature was done. After all, a feature wasn’t done until all the teams were done with it.
After a few more questions, I realized the teams were architectural teams, say, a GUI team, a middleware team, and a database team. I suggested that the project manager rejigger the teams so that they were feature teams, not architectural teams.
Sometimes the project/program manager is new to agile only realizes what the teams need to do in theory, not in practice. Or the project/program manager wants the teams to do things his/her way. I’ve seen that a lot in my training and consulting. I don’t think that was the issue in the LinkedIn question this week.
Often, the teams don’t realize that they are doing something not quite agile. The organization has cheaped out on training, or the training was insufficient or too long ago, or something. Whatever it was, the training wasn’t enough. The teams don’t realize that what they are doing isn’t quite agile, so they are still working in architectural silos, instead of feature teams.
To return to the problem, how to get to a done feature when the teams are still architectural silos, my suggestion was rejigger the teams. For teams accustomed to architectural silos, this can be a shock. You might have to entice them. Here are some potential enticing ideas:
- Ask them to try to rejigger themselves. “I’ve heard about this slice of cake thing. That’s where we implement a feature from the GUI through the middleware to the DB and back, as thin as it needs to be, but all the way through, end-to-end. Can we try that, make teams to try that?” (I thought Bill Wake used that metaphor. Do any of you readers have the link? I can’t find it.)
- “You folks are the experts. What do we have to do to make this feature done?” Now, you as the project manager, hush. Take notes. Listen. The team is telling you the impediments to agile.
- Challenge the team. “In agile, the idea is that we work features through the architecture. I’m just the project manager. You folks are the experts. Is there any way to do that with our product?” Again, you as the PM stop talking. The team is telling you how they can self-organize.
Note that none of the ideas are “You go here and you go there” team assignments. Why would I do that? Even I, Bigger-Hammer Rothman, know not to do that. People need to see that they have choices. Offer them three choices, as in the Rule of Three, and they will likely generate more choices that are even better than my suggestions.
Don’t expect that you know all the ways to be agile. And, don’t lay down the law and tell people, “We’re agile. Do it my way.” That’s not congruent with agile approaches, and doesn’t work.
Explain the result you want. Engage people in problem solving. Assume you don’t know what the solution is. That’s how you entice a program, team by team, person by person, to move to agile. It’s not foolproof, but nothing is.
