Agile Zone is brought to you in partnership with:

Johanna Rothman helps managers and teams solve problems and deliver products. Her most recent book is Manage your Project Portfolio: Increase Your Capacity and Finish More Projects. You can read her blogs and other writings at jrothman.com Johanna is a DZone MVB and is not an employee of DZone and has posted 126 posts at DZone. You can read more from them at their website. View Full User Profile

Enticing a Program to Move to Agile

02.14.2013
| 1760 views |
  • submit to reddit
There was a question on a LinkedIn group earlier this week about a program with teams with interconnected features and about how you knew 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:

  1. 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.)
  2. “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.
  3. 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.

Published at DZone with permission of Johanna Rothman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)