Scale large software product development teams without tipping the scale.
When kicking off a new engagement, it is easy to get caught up in the magnitude of the scope and potential of the project. Stakeholders get excited that their goals and plans are finally coming to fruition. While a long-term vision is essential to understanding the direction and strategy of why you're about to set off on this journey, it's also crucial for the team to understand what they can accomplish in the short-term to create a foundation to build upon. Once you (aka product managers) have created the foundation and start to scale to a larger team, you'll notice times when inefficiencies creep in, and processes that worked for one team no longer work at a larger scale. Below are six tips to help product managers grow and build products with large-scale product teams successfully.
1. Build alignment around shared goals using an incremental approach.
A critical first step when kicking off a project is to get buy-in from stakeholders around taking an incremental approach and focusing the development effort. After running a Lean Requirements workshop, everyone (i.e., product managers, designers, engineers, and stakeholders) should agree on the set of functionality that will add value and be used as a meaningful milestone for the business. It is important to involve all stakeholders when deciding what the team will work on first so the entire team walks away from the workshop with a shared understanding of the approach.
Phase 1: Delivering the initial scope of work
After the initial workshop, a critical next step is to align the group around naming conventions. This may seem relatively trivial. However, if stakeholders have PTSD from the term "MVP" or think "POC" or "Prototype" mean throwaway work and not real software, it's critical to settle on a name that creates alignment. I recommend using "Phase 1" as this is generally safe and does not come with as much baggage. The name provides clarity that this is the first phase, and there will be more than one phase of work.
The length of time and actual scope completed during Phase 1 will vary by project. I recommend something around 3-4 months as this is enough time to deliver something of value but not too long that you lose momentum post-workshop or go without delivering something tangible. Once the initial phase is complete (ideally with one development/scrum team), all stakeholders should be buying into the process and wowed by what the team accomplished in Phase 1. As a result, stakeholders often want more, and they want it fast.
Phase 2: Scaling production with cross-functional teams, across multiple workstreams
A natural follow up to Phase 1 is to facilitate another workshop to scope the additional workload associated with Phase 2. After the workshop, ask the engineering team to review the workload and dictate which areas can be broken down into parallel work streams, so there is a clear division of labor. This helps inform how many teams you could realistically scale to and prevent teams from committing to an unrealistic timeline due to dependencies across the application.
Then allocate dedicated cross-functional resources (across all disciplines) to each scrum team, and practice agile ceremonies. The team members assigned to a specific scrum team all work on the same features. As a result, the team members develop domain expertise in their areas of focus. The product manager writes better backlog, and the designers create better design assets as their knowledge and understanding grows.
2. Face dependencies and conflict head-on.
When working on a larger project, inevitably dependencies and conflicts across teams arise. To mitigate issues, create a Feature Ownership Matrix aka a 3 column table with headers labeled, "Feature/functionality/epic," "Owner," and "Additional info" to clearly document who owns elements in production. Have engineering team leads identify a dedicated resource to act as the resident expert/owner of corresponding features. Ensure that the domain expert is then consulted when a related feature is being built.
While teams try to create autonomous, parallel workstreams, overlap still happens. For example, implementing new functionality to an online editor would impact features such as Import/Export, and they would need to be retested. Test engineers are critical to ensuring that regression testing and other test practices include ways to uncover these overlaps and ensure code does not break with new commits.
3. Ensure each discipline across all project teams meet regularly about best practices.
Uniting each discipline on a project helps provide continuity and a consistent approach to building software and, more importantly, a look ahead at what's coming next. Schedule consistent meetings to keep the team aligned.
Add in a daily Scrum of Scrums for the engineering team leads to discuss risks, project-level concerns, and dependencies—as well as support cross-team collaboration.
Schedule a weekly product owner sync with all product managers and business analysts to provide insight into upcoming sprint plans. Ensure related stories are linked in JIRA (or Azure DevOps/VSTS) and that the acceptance criteria (AC) is aligned across the project.
Be proactive in identifying dependencies across teams to spot potential risks and mitigate them. Task PMs with modifying upcoming sprint plans so that stories can be played sequentially as needed or further broken down to spot the root cause of a development setback. Adapt sprint ceremonies based on each team’s needs. Do not feel constricted by what might be considered “standard” ceremonies.
For example, one team I worked on went through several iterations of visual design reviews to define the best process. We landed on first having the designers across teams meet to review their designs and ensure they were using consistent design patterns and elements across the platform. Next, the designers met with the product managers to review the designs and get feedback or uncover questions before the client can ask them. After minor revisions were made, the designers then met with the engineers on the scrum team to review the designs and discuss technical feasibility. It was imperative to show the designs to the engineering team before the client, so they could provide input and rule out anything that added unnecessary time/effort. Lastly, there was an all-team client design review for stakeholders to provide feedback on what was scheduled to be developed in the upcoming sprint. This helped ensure we were building the right thing and getting the go-ahead from the client before spending time developing something they would want to change later.
4. Run ongoing requirements gathering and discovery sessions to set clear acceptance criteria.
Stop re-work and indecision from preventing successful, on-time delivery. Involve stakeholders in ongoing requirements gathering/discovery sessions, so the team is confident about the AC they are developing. We run these ones to three times a week for each scrum team, depending on the complexity of the scope or the depth of the domain knowledge needed to craft user stories. These can be thought of as mini-workshops. The goal is to dive more deeply into the desired functionality, but at a smaller scale (for an upcoming sprint vs. for an entire next phase of work).
If your team is fortunate enough to have Business Analysts, they can be great assets during these sessions. They can help prepare and review agendas. They can work closely with the development team to discuss the technical design and come up with different options for stakeholders. Business Analysts are also very valuable for refining AC in stories and thinking about the requirements from a more technical standpoint. This ensures that the full team has the correct understanding of an individual user story and any related work that other teams are working on or upcoming future improvements to this feature.
5. Gather actionable feedback from stakeholders and users.
Another way to validate the direction is to gather feedback from stakeholders (and ideally from end users). Collecting feedback should be a constant throughout the project and begin after the very first sprint. Of course, ceremonies such as design reviews and demos provide stakeholders with opportunities to provide input and direction. However, it's essential they have access to and are testing the software themselves. Seeing a design and interacting with it are often two different experiences.
Establish a process of UAT at the end of each sprint to involve stakeholders (and users) in the process. This can be as simple as sending them a JIRA query or a list of all the user stories that were completed in the previous sprint. Then have them log onto the staging/demo site to verify each story and document findings. Collect feedback incrementally without waiting until the end of the project or right before a major release when it would be too late to act upon it.
Use each new phase or milestone as an opportunity to conduct user research. Ideally, the design/research team conducts initial user research as part of the project kick-off to understand the end user’s pain points and help inform the focus of Phase 1. After that, use each transition from one phase to the next as a natural stopping point to validate what has been built so far and look ahead towards what’s on tap to build in the upcoming phase. Remind stakeholders that the team needs to allocate time to respond to user feedback in upcoming phases to retain agility and the ability to quickly re-prioritize features.
6. Set realistic expectations with stakeholders throughout production.
Prioritization is an exercise that comes up again and again. In order to feel confident about reaching deadlines, after each workshop or discovery session, ask the client/stakeholders to prioritize the work you just discussed and delineate between the absolute "must-haves" necessary for delivering the next phase of work vs. the features that are “nice to have” but not mandatory to accomplish the main user jobs or tasks with the upcoming release. It may come across as a difficult exercise, and of course, stakeholders are always going to want more. However, this is where consultants need to ask the hard questions and frame these conversations from the very beginning as an integral part of software development and a way to mitigate risk if timelines start to be pushed back.
Transitioning to the next phase of work is also a good opportunity to revisit expectations with stakeholders. Agile ceremonies can lose their value if they are held too often, so use them as a tool when they are most meaningful. Use retrospectives as an opportunity to reflect on the effectiveness of the ceremonies themselves. During a client retro, prioritize how to improve communication/collaboration coupled with ways for the team to work better together to understand and execute the requirements.
Before transitioning from one phase to the next phase, revisit the go-to-market strategy. How is what the team is building going to impact the client’s larger business goals and help build a case for additional funding? Who will be the first users of the application? Will there be a focused pilot/beta? Identifying these goals and working backward to ensure the scope of the upcoming phase is on course to accomplish the goals outlined in the time allotted is the only way you will be able to continue a project for the long-term.
Set large-scale product teams up for success.
This is certainly not all-encompassing of everything that goes into managing a large multi-team project. The content above is meant to offer product managers and teams actions they can take to set teams up for success from the beginning of an engagement.
Partner with engineers and designers to put processes in place for identifying dependencies across teams to ensure team members are not blocked. Bring the right people together on the client-side to ensure there is shared understanding, a precedent for continuous feedback and that the team has the answers they need to move forward, especially when working with larger organizations where decisions are often made by committee. Use transitions between phases of work or when adding new scrum teams as opportunities to reflect on what the team has accomplished, to conduct user research, and to re-align with stakeholders on how the next phase will help them reach their business goals and users. Each engagement is unique, and the most important way to succeed is to be agile in the truest sense of the word and empower teams to grow and strive for continuous improvement.
