The cross-functional agile team playbook

How to avoid waterfall mishaps and build successful product teams

Download white paper

Shape teams to win

No two teams are identical. Products range in complexity, and the nature of the team highly depends on the product type. Experiment to find the perfect blend of roles. For example, a microservices implementation may not require front-end developers—yet does require additional testing engineers to implement high unit test coverage across the product. On the other hand, a mobile banking app needs multiple product designers because the research, testing, and design workloads are much higher.

Let’s briefly cover a target state of the organizational structure. The Chief Product Officer is the key individual responsible for product output from the business. Customer success as well as delivery capabilities all bubble up to the CPO. Directors of Product own specific product lines in the organization. Group Product Managers lead multiple teams of product, design, and engineering professionals.

Working product teams consist of product managers, designers, and engineers. Each member of the team has a local manager for delivery oversight and a disciplined lead responsible for career development, coaching, and evolution of their respective disciplines. Teams are formed using the structure noted earlier for the following reasons: 

  • The more self-managing the teams are, the flatter the organization is. The team takes ownership of the product and operates as an independent, self-managing unit.  

  • The structure is laterally scalable. The more products there are, the more mini-product orgs can be established without unnecessary hierarchies. The more the business grows, the more opportunities open up in the company for people to take on more responsibility. Win-win! 

  • The structure works in a single office just as well as it does for a 100 percent distributed team. 

Cross-functional team members work as partners in the venture and tackle their individual workloads. Members seek out how to maximize their impact on the product and lift the team to the next level of productivity. Team members who lack competence or fail to adopt these values are detected by the team instead of by a detached manager.

Cross-functional product teams are self-governing entities where each contributor takes ownership of the product’s success.

At times, the team takes advantage of outside expertise for support roles. For example, DevOps is typically a support role because there simply isn’t enough work for a DevOps engineer to be dedicated to a single team. A few DevOps engineers may be equipped to serve up to five product teams, for example. Directors of disciplines such as product design, product management, testing, and engineering are also pulled in for ad hoc for highly complex challenges. 

The total product team size varies from six to twelve. Any larger and effectiveness and communication quality start to deteriorate. If the team becomes too large, they ideally split into two, retaining the domain knowledge while expanding the small teams with new members.  

The member count from each practice group varies based on the team and its responsibility within the overall product roadmap. Ideally, there is some overlap and shared understanding—a designer with the knowledge of a front-end skill set, an engineer who is fluent with front-end and server-side technologies. Finally, ensure all team members are 100 percent allocated to a single product.

Product team roles

This section outlines the typical roles in a cross-functional team. The roles depend on the type of product and profile of work for the team. Generally, vertical feature ownership across a front-end, logic layer, and data are recommended instead of lateral distribution. This reduces the number of dependencies and accelerates the complete feature delivery to demos.

Product Manager

A product manager (PM) advocates for the success of the customer (internal or external) while balancing the spend, schedule, and product scope. A PM seeks to maximize the business outcomes while operating within a set of constraints: 

  • The product must ship on time and on budget. 

  • The stakeholders must have buy-in and be aligned with the goals. 

  • The product backlog must be dev-ready to avoid idle time. 

The product manager’s primary responsibility is to break down the customer’s needs and product requirements into digestible user stories for the team. The PM is readily available to address any questions or concerns the team may have as it works its way through these stories. The PM also collaborates with designers and engineers on requirements gathering, backlog refinement, orchestrating sprint rituals, and facilitating retrospectives. Some organizations break out backlog ownership into a separate product owner role.

Business Analyst

Business analysts help break down complexity on products with deep domain complexity or large product builds where a product manager may need to coordinate the wider program while individual teams focus on feature work. In practical terms, this translates into the BA owning backlog refinement.

Engineering Lead

A senior software engineering lead (EL) is responsible for making technical decisions and leading the development effort within the team. This person works with the product manager to delegate individual user stories, making sure that team members are enabled to complete the work they pick up such as routing complex stories to more senior members of the team, coaching, problem solving, and performing technical spikes. The responsibilities vary based on team maturity and selected rituals.

Product Designer

Product designers (PD) help the team build the right things by answering a range of questions:  

  • How will the product be used by the customer?  

  • Why does the customer behave a certain way?  

  • How should the product be designed to maximize effectiveness?  

Designers work to capture user personae, understand their motivations and desires, and design workflows and experiences that make using the product simple, desirable, and valuable. There are different types of designers—some focus more heavily on usability, while others focus more on visual design and research.

Front-End Engineer

Thanks to the evolution of front-end technologies (e.g., HTML5, CSS3, and JavaScript), a separate role has emerged to translate the designs produced by the design team into functioning interfaces. Front-end engineers (FEEs) work purely on the UI of the application (including transitions, animations, responsive frameworks) or perform some lightweight integration to hook the interfaces up to the application code that drives the UI. An understanding of design is necessary because FEEs often have to extend design patterns from a single template mock-up across several interfaces or workflows. Performance optimization is another important area of responsibility for the FEE—making sure products on mobile devices and desktops adhere to best practices established by Google’s RAIL (response, animation, idle, and load) model.

Software Engineer

Software engineering is the backbone of every product build and is the role filled by the highest number of employees. Software engineers (SE) are responsible for the successful, scalable, and maintainable implementation of the product. Their expertise ranges from native mobile development, web application development, and cross-platform engineering to data architecture and performance optimization.

Testing Engineer

A testing engineer (TE) works closely with the PM during the backlog definition to capture and agree upon the acceptance criteria for each user story. We have found that TEs who integrate tightly with business SMEs and start by defining the right way for the product to work is much more successful than testers who simply pound on the application until it breaks. Testing engineers also manage test plans and test cases, capture defects, and recommend product improvements. Test automation engineers write unit tests and other automation scripts that help the product team simplify quality assurance as the product grows in complexity and size.

Supporting roles

Product Design Manager

A product design manager (PDM) is a senior practitioner of the craft who owns a portfolio of products currently being worked on by the team. Each PDM supports a group of product designers (and thus potentially multiple scrum teams), leads design thinking on client engagements, participates in the hiring of new designers, and provides mentorship and coaching to the cross-functional team. PDMs have a deep understanding of the product design practice that includes research, interface design, and interaction design.

Group Product Manager

A group product manager (GPM) leads a group of product managers and is the point of escalation for all delivery-related issues. As seasoned and experienced product managers, the GPMs help the team scale obstacles, hire new PMs, and coach members to be successful long-term.

DevOps Engineer

The DevOps engineer (DOE) enables continuous delivery for the team through the configuration of environments, processes, and tools. This role is typically employed at the beginning of the project as the infrastructure and deployment needs are being configured. The primary responsibility of the DOE is to equip the team with tools and processes that support continuous delivery—or at a minimum continuous integration.

Software Architect

A software architect is a senior engineer in an advisory role who helps the team navigate complex architectural decisions, determine the best application of a technical capability, and introduce emerging technology capabilities (e.g., artificial intelligence and machine learning). Architects typically support multiple scrum teams.

Teams can be isolated or integrated

At Devbridge, we use two team models, both valuable in different scenarios. When isolated, our teams have full ownership of results and can move faster without distractions and outside of enterprise politics. There are times when integrated teams are necessary to help our clients adopt best practices,  transfer application domain­s—as well as facilitate a wider process transformation at the company.

Continue to:Build iteratively