Agile Program Titles

I’ve been working with and discussing agile program management with a bunch of people.  One of the big issues is: what do we call certain people at the program level?

We need a program manager, someone who sets/explains the program’s vision, develops program-wide release criteria with sponsors, has a way to articulate program status, someone who solves risk issues or facilitates solving risk issues. In some organizations, that person also does some financial work, watching the run rate of the program. We’ve had the program manager title for a long time. In the agile program, that person does not take a command-and-control approach, but the responsibilities are the same and the same title is useful.

An agile program also needs someone who serves the program architecture: someone who takes the responsibility of ongoing creation and assessment of the business value of the architecture, who facilitates the growth of that architecture, who explains the architecture to others, such as the program manager, and looks after the business value of the architecture with other people, such as other architects. In an agile program, that person does not work alone. (He or she should not work alone even in a non-agile program, but certainly not in an agile program.)

We also need another person to define and manage the program backlog. At the program level, we may decide to use several technical teams to work on a particular feature set until it’s done, because that particular feature set is critical to the program’s success. Or, we may need to explore the architecture more at the beginning (or in the middle) to see where we want to take the program, because the product could go in several different directions. Remember, this is the program backlog, not the backlog for the teams. The program backlog drives the teams’ backlogs.

Other folks have been calling that architect and product owner “chief architect” and “chief product owner.”

The “chief” part of their titles made me uncomfortable, and I just understood why. When you name someone a “chief” of something, there is an implied hierarchy. But that’s not how an agile architect for a program works. That agile architect may well be senior. But that architect’s responsibility is to assess and improve the business value of the program’s architecture over the program, along with whomever else that architect works. The product owner is responsible for the program business value of the program backlog. This architect and this product owner serve the program. The program and the people do not serve them.

So I’m calling these people “program architect” and “program product owner.” Yes. there is still an implication of high-level work–which is correct. For me, there is less implication of hierarchy.

Chief titles are good for some efforts. They don’t fit so well for agile. Not if we really want self-managing teams, teams who will work for the better of the product, not for other people.

Tags: , , ,
Previous/Next Posts
« »

1 Comment

  1. Sam

    They are some savage titles you got there, I think the best way to keep everyone happy is to call them all chief 🙂
    Since I don’t come from a background of working in big multinational company’s I have always been uneasy with getting or giving titles. Titles do strange things to people I find.

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *