Agile · Bridge · Communication

Know your role

In a well-functioning Agile development team, the members of the team collaborate in multiple ways during a given development cycle or Sprint.  Coders, testers, designers, and product owners work closely with each other to ensure that the most important features and fixes are worked on in the right way at the right time, also bringing in people from other business or development teams to make certain that the full portfolio of products is growing in ways that support the broader business goals of the company.  In my current firm we sometimes refer to these cross-team groups as TeamNets (see the following link from Amazon.com for more on this: http://www.amazon.com/The-TeamNet-Factor-Bringing-Boundary/dp/0471131881).

Working effectively in these cross-functional teams requires not just a commitment to collaborative development; it also necessitates that each team member understand his or her role on that team and trust that other team members will also fulfill their roles.  In Agile development teams (and on TeamNets generally) these roles cannot be rigid; inflexible team structures tend to lead to stagnation and the kinds of ‘repression’ illustrated here:  http://www.youtube.com/watch?v=5Xd_zkMEgkI. Instead teams have to balance a clear understanding of the key aspects of each role on the team with a willingness to be flexible during the process as different team members exercise leadership at different points.  The folks at Silicon Valley Product Group (http://www.svpg.com) regularly publish a great newsletter that touches on these roles along with other topics; Marty Cagan from SVPG has also written an excellent book on Product Development that has very helpful material on the right roles for a strong product development organization (http://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408)

I want to talk briefly about the six key roles that any strong product development team needs to work effectively in an Agile environment.  The people in each of these roles might have many areas of responsibility, but I want to focus on the primary thing needed from each role to ensure effective software development.

  1. Product Manager.  The primary responsibility of Product Managers is bringing market intelligence to the software development process.  Most of the other roles are inward-focused.  This role looks outward, determining that products being developed and enhancements being added are things that meaningful numbers of clients and prospects prioritize as important and are therefore willing to pay for.  Few things undermine the effectiveness and motivation of software developments more than building products and that no one wants or finds worth buying.  Product Managers must know the target market and individual clients well enough to set priorities for the rest of the team.
  2. Product Owner.  The primary responsibility of Product Owners involves translating the market intelligence of the Product Manager into sprint goals for the development team.  Working closely with the Product Manager, the Product Owner helps to craft a roadmap for the planned development of the product, breaking larger enhancements into manageable feature sets for individual sprints.  As I have written earlier, this role involves standing on the bridge between the market and the development team, making sure that the needs, questions, and concerns of each get translated to the other so that the development process moves forward effectively.
  3. Designer.  The chief aim of the designer is to think about what the product should look like and how it will be used by the clients.  The goal isn’t necessarily ‘cool’ but it is a lot higher than simply ‘functional’ or adequate.  Getting the designer involved early in the planning process helps ensure that features get built in ways that will enhance the user experience.  And having the designer participate in regular user acceptance testing means that aspects of a product’s look-and-feel will get a solid review before new features move into production.  Just the Product Manager and Product Owner are thinking about the future enhancements for the product, the Designer should be thinking about keeping the user experience fresh as the product continues to evolve.
  4. Lead Coder.  Obviously developing software requires the involvement of at least one person coding; but the key responsibility of a Lead Coder is to oversee the code base for the software to make sure that enhancements and fixes are strengthening that base rather than muddying it.  This role involves working with the Product Owner to set appropriate goals for individual sprints, balancing the desire for new development with the need to regularly rationalize and refactor existing code to reduce any ‘technical debt’ from past work and to streamline processes that can be improved.  Given these responsibilities it is also valuable for the Lead Coder to be involved early in discussions on planning new features to help set high-level expectations on the potential scope of these enhancements.  I will say more on this below, but the Lead Coder must also work closely with the testers on the team to make sure that code is developed in ways that support easy and thorough testing.
  5. Lead Tester.  Because one of the key goals of the Agile methodology is continuous integration (or the ability to regularly and rapidly deploy developed software to production without breaking existing code), successful teams will have strong involvement from a Lead Tester.  Close partnership between testers and coders is crucial from day one of any sprint; Close partnership here is essential for developing and deploying stable software and so ideally projects have one tester for every two coders.  Just as the Lead Coder provides oversight to the code base, so the Lead Tester ensures adequate test coverage for the product and the ways it interacts with other parts of the company’s software.  Through automated and manual regression testing, regular user acceptance testing, and local testing of new fixes and features before deployment, the Lead Tester confirms that existing components of the product are not broken by new releases and that enhancements function as expected.  The Lead Coder and Lead Tester also work together to establish clear definitions of when a particular feature can be considered ‘done’ and ready for release.
  6. Scrum Master.  An important aspect of Agile software development is the daily Scrum – a meeting of the development team to discuss progress and impediments.  Even in highly collaborative teams that have worked together for long periods of time, these daily meetings work best when someone provides leadership, facilitating the conversation and keeping it on point.   This is a role that may shift during the development cycle, with the Product Owner serving as Scrum Master at some points and another member of the team playing this role at other points.  Whether this role is played by one member of the team consistently or different team members take on the responsibility at different times, someone needs to embrace responsibility for keeping the Scrum meetings focused and making sure all members both prepare for the daily Scrum and follow up any issues raised during it.

On some teams or in some organizations one person may play more than one role.  As product organizations grow there may be multiple teams with these sets of roles, and a broader role for organizing the product development plans for the entire company.  The combination and collaboration of these roles forms a strong and flexible team that can develop high-quality market-tested software in a sustainable and efficient way.  Merely having people slotted into these roles doesn’t guarantee easy development or market success, of course, because in truth it’s not that simple.

Advertisements

One thought on “Know your role

  1. Reblogged this on InTruthItsNotThatSimple and commented:

    I’ve had several discussions recently – both in person and on-line – about the roles and responsibilities of Product Owners and Product Managers in an Agile software development environment. Here’s an old blog post wrestling with just this issue.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s