A successful agile team requires someone on the team to act as the voice of the customer, someone to lead the developers, someone to lead quality assurance, and someone to organize, coordinate, and assure execution. For an agile team to succeed in an enterprise ripe with political resistance to agile, someone has to be the “voice of the team” as well.
You can approach this by classically assigning roles and responsibilities – but that isn’t the only way. Agile teams are most effective when they have specializing generalists who can mutably adapt to the immediate needs.
The Politics of Agile
Barbara Nelson of Pragmatic Marketing has a new article, The Politics of Agile, where she provides a great overview of agile in the enterprise. Barbara shares insights into some of the perspectives and prejudices that we encounter in larger organizations when talking about, exploring, and piloting agile projects. She provides an introduction into a few flavors of agile that product managers run into most often, and leads into the pragmatic approach – what they call XPM (extreme product management).
Pragmatic Marketing’s approach, to oversimplify, is to have a product manager be the voice of the customer, who lives as the interface between an agile execution team and the rest of the organization. As she points out in her article, the political environment in which the team has to operate can make or break the project. She provides several tips for how the product manager can shepherd the team through those political mine fields.
Software Development Roles
Barbara also points out that there are five roles that need to be filled for any successful product team – agile or waterfall. [Links inside the quote are ours]
When building products for a market of customers (as opposed to a single customer), five roles are needed whether you practice agile or waterfall.
- Product manager: messenger for the market; defines what problems need to be solved and for whom
- Product designer: expert in design, defines how the problems will be solved
- Development team lead: liaison to the developers
- Quality assurance lead: assures that the product solves the problems identified by the product manager
- Project manager: manages the schedule and resource allocations
Barbara Nelson
She points out that these five roles don’t have to be filled by five different people – especially when you don’t have five people to staff the team. Where we “agree*” (we agree, but with an asterisk) is where she draws a clear line that the product management role should not be shared with other roles. [Note: Dev team leads can also be free electrons, if you’re lucky!]
Even if there are not five people, these functions need to be performed. If the product manager takes on any of the other roles, it will be at the expense of becoming the market expert and having the right information to be the single voice of priority. Let the developers develop. The product manager identifies what needs to be built, not how to build it. Validate with the market that what the developers are building and how it is being built resonates with buyers and users.Barbara Nelson
On large teams, and waterfall projects, and organizations that “are bureaucratic”, we couldn’t agree more. But for agile teams, it depends. And it depends on the people who are on the particular team. Agile teams intentionally staff with specializing generalists so that they can respond to “whatever is needed right now” within a sprint/release/cycle.
Specializing Generalists
The idea of specializing generalists is easiest to grasp by first saying what it is not. It is not staffing a team with a database expert, a user interface coder, a SOA (service oriented architecture) guru and an architect. With four specialists, each development task has an obvious owner. Database changes and refactoring go to the database expert. Reworking the UI goes into the queue for the AJAX hotshot. The problem is that this approach is only efficient when each team member is equally loaded with work. Since an agile team is continuously reprioritizing their work based on repeated feedback cycles as part of each release, this doesn’t work. The team will never face a situation where the (for example) four most important things to do are one item for each specialist. You can very easily have a release where all of the most important tasks are focused on the user interface. So all of the non-interface-experts are either working on lower-priority tasks, or even worse – they are idle. And you delay the most important work until the specialist can get to it.
By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.
This is very effective for making the “development engine” a black-box. Feed it the highest priority stuff, and it all gets done. We can take that approach to the next level. Designers can implement, project managers can design test plans, and yes, product managers can specify design. Twitch. Back up a sentence and read it again.
Specifying design is not the job of the product manager. True. Very true. Emphatically true. But specifying design can be what a specializing generalist does, even when that person is also responsible for defining market needs.
Wearing Two Hats
Wearing two hats can be incredibly hard – and it can be a disaster for someone who isn’t experienced enough (or good enough, frankly) to know which hat he’s wearing when he does something. And this is why we only almost disagree. We have seen enough examples in the real world of superstar specializing generalists to believe in their value. And we want to make sure that when you have one of these dynamite people on your team, you don’t prevent them from applying all of their skills to make your product great.
How do you know when you have one of these people? There are at least three archetypes who are brilliant at it. There must be more, but these are the ones we’ve seen more than once.
- The Evangelist. A product manager / product designer. A person who is completely attenuated to the needs of the market and who unconsciously and capably designs solutions to meet those needs. Steve Jobs is the example that comes to mind first, probably because he comes to mind first ad nauseum. Edison is another great example – he tapped into market needs and invented solutions. Or the guys who knock on venture capitalist’s doors with “the next great thing” – which is a marriage of need and solution. [As an aside, I think a sign of a market bubble is when companies get funded with only one but not both of these things.] Another way to think about this – combining the voice of the customer with the voice of the user. Some people can say not only “They need to do X” but also say “And doing X this way is ideal.”
- The Innovator. A product designer / development lead. I’ve had the pleasure of working with a (very) few of these folks over the years. They combine a visionary approach to solving a problem with mad skillz at implementation. When you share a problem with a great designer, she comes back the next day with a mock-up of a fantastic solution. When you share the problem with an innovator, she comes back the next day with a working solution. Where a great developer will create an elegant implementation, an innovator will create an elegant solution.
- The Cold Fusion Reactor. The development lead / quality assurance lead. One of the enabling elements of an agile development approach is that you create tests as you go, “protecting” your existing code. This allows you to make invasive changes with minimized risk and effort. This is the secret to refactoring – you aren’t forced to live with the “bad stuff”, because the cost to replace it with “better stuff” is so low. And that, as Kent Beck points out, allows your design to always be “the best design” even with emergent development and an evolving code-base. There are developers out there who are so effective at testing that it takes them less time to implement. They can make bold moves and refactor “good enough for now” solutions into elegant designs on the fly. They can harness that atomic power, because they can rely on their testing “containment field” to keep things safe. And that safety leads to less stress and cooler heads.
When you have these people on your team, the issues of roles and responsibilities become smaller. If you ask someone who isn’t one of these people to play dual roles, you’re asking for trouble. But if you have one of these people on your team, and you limit their role, you are also limiting their value. It is important for product managers to not specify design. It is also important to realize when the person who’s business card says “product manager” is also an evangelist with designer skills.
The way I put it in my most recent blog entry is:
“And in a healthy, productive organization, some people are flexible and play multiple roles.”
Nonetheless, the problem in most organizations is that there is little awareness of the skills necessary to play some of the roles. For example:
“Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don’t even realize how unqualified they are.”
Scott,
As usual, great post.
I “almost agree” with you, too. In a world where you have superheroes, they can do anything. In my 20+ years of experience in the technology arena, I have seen great teams build great stuff, regardless of methodology, regardless of roles being clearly defined. Waterfall, agile, whatever. Great teams have a special chemistry. Superheroes just get stuff done. Brilliantly. And when they solve problems people actually want to pay someone to solve, there is no stopping them. With or without formal product management. (Did I say that?)
The “specializing generalist” concept has merit, particularly for the developers. But in the role of product management where there are a whole bunch of other things to be done that are beyond the development process, it isn’t practical. If the team is 2 guys in a garage, that’s a different story. Or a 20-person start-up. With superheroes on the team.
But those teams and those people aren’t the ones we’re talking about. Superheroes don’t need special methodologies. Being pragmatic, we are looking for repeatable. We are looking for ways to help regular people. We are looking for ways to grow our businesses. My gut tells me that only 5% fit the archetypes you describe. They are born that way. The other 95% might not be brilliant, but they can be successful with focus. Someone on the team keeping the vision of what needs to be built, for whom, where we can all make money. (In a start-up, this is usually a founder, not the product manager.)
I frequently see product managers filling some of the other development roles. BUT, if they are deep into the development process of designing, testing, developing rather than in the market gaining the deep understanding of the market, they will fall back on opinions rather than facts to make decisions. I’m OK with that as long as SOMEONE’s job is market expert. Market expertise does not come from sitting in development.
Happy Friday!
Hey guys, thanks for commenting, and for being active participants here for so long! Personally, it makes the place feel like home, for lack of a better description.
I hope I didn’t dilute the message, Barb – I agree with you that the bigger problem is in companies forcing product managers to stretch too thin. I think I am vamping on one of the coloring arguments that keeps these issue from being black and white. Chalk it up to me trying to be “nuanced.”
And Roger – you’re spot on in your article. As part of a teams trying to drive home the value of user experience expertise, I’ve seen the angst that the truly gifted designers feel when people assume that the job can be done without the skills. It’s a lot like writing – everyone can write, but not everyone can be an author.
Thanks again!
Scott