Cross-Team Product Development & Delivery Process Guide (Part 1)

Are you always behind schedule, missing documentation, briefs, specifications, or marketing materials? Are people confused at your cross-team meetups, not knowing what is going on?

The list of similar situations is huge and highly specific to each business. You may be one of the luckiest people in the world if you have never faced these scenarios. Also, while you can sidestep a lot of these problems by outsourcing custom software development, there are still several factors you need to stay on top of. This is especially true if you’re working with multiple outsourced partners.

So, if you are contending with issues like this, don’t worry. This is quite a common challenge for nearly all high-growth companies where team sizes outpace the ability to establish proper cross-team functioning rules.

Luckily, it is never too late to revisit the processes!

In this series of posts, six in all, I’ll try to bring a bit of clarity on how the product development and delivery process may be handled, how you can start applying it in your area, and what the benefits are. And, I will outline the consequences of ignoring the proper setup of these processes from a long-term perspective.

NOTE: The strategic planning of product development is intentionally sacrificed in order to focus on the operations and execution level. Strategic planning itself is almost an entirely separate topic in describing it from a C-Level executive's perspective. I’ll concentrate more on the duties of department leads and heads of whole directions (product, development, testing, etc.).

The Definition of the Problem

The whole mess that often happens in product delivery has its roots in the fact that domain knowledge is often highly segmented - by department, team, and even individual developer when you really get down to it. This issue is often referred to as knowledge siloing.

Product managers are taught their own processes, project managers mostly refer to PMBOK guides, and engineering leads are using SDLC processes… well, I guess you get the point.

The methodologies used in product development and delivery process often concentrate on a specific area of operations, like the product definition, project and team management, software engineering lifecycle, quality assurance, releases, and so on. It is fine, in general, as each area needs its own standard.

But the more the company grows, the more things are crafted at the intersection between the teams and departments. Isolated domains inevitably become shared ones, and you need to handle them appropriately.

Naturally, small businesses often use simplified processes and direct communication between the parties to move forward. This approach has proven its efficiency, but it works only to a certain extent.

When the team starts to scale, communication gaps start popping up like mushrooms after a heavy rain, and isolation or siloing between departments becomes a huge pain. It may lead to a slowdown in velocity with longer cycle times stemming from inefficiency, slower and less-informed decisions, missing or ambiguous requirements, more defects, and ultimately, result in poor product release.

So, how should the organization support its team scaling and avoid this disaster?

Possible Out-of-the-Box Solutions

Before jumping into details, I would like to mention that there are various industry standards and methodologies, of course, that aim to handle the knowledge siloing. For example:

There are others, to be sure, but I’ll mostly refer to SAFe and LeSS. But it is important to understand that they are all pretty vague and designed as methodologies based on Scrum, which means that there is a large room for different interpretations upon the actual implementation of the latter. That’s not to mention that Scrum itself is not a silver bullet and there are companies that don’t use it.

SAFe was designed to cover the needs of enterprise businesses in the first place and is still one of the most popular frameworks. However, the important thing is that it is used for organization-wide migration to Agile methodology, which might not always be a great fit for a specific business.

Looks terrifying, huh?

LeSS is a very lightweight methodology compared to SAFe and describes the process of scaling existing scrum methodology to multiple teams. Again, this does not cover the whole development and delivery process. (Quite an arguable assumption, but you’ll see what I mean shortly).

Simple and natural scaling of existing processes

Both are great, and I would definitely advise starting with LeSS first, as it provides a quite obvious and natural way of scaling processes across fast-growing departments.

Integration of Different Processes is The Key

The intent of this guide though is to show how all the industry-wide theories and methodologies are integrated into the product development and delivery process in practice.

Down the road, you will discover how the Project Management Body of Knowledge (PMBOK Guide) published by the Project Management Institute helps us to:

Structure the whole process,
Identify how product discovery techniques improve the quality of the definition of your software requirements,
How iterative Agile methodology comes into play at the intersection of product and development departments,
How the SDLC takes shape after emerging from complete chaos.

I will take the LeSS framework as a foundation (or as a concept), but won’t limit the process to it. This way you can still apply it even if you’re not using Agile methodology. Then, we will also take a deeper dive into certain areas to unveil important details that supplement the product development and delivery process.

Context

Let’s assume that you have a company that’s creating an SaaS platform, which includes different small sub-products (or sub-systems) under the same hood. Your hypothetical company consists of the following departments, with multiple teams in each:

C-Level office (CTO with the internal team, CEO, CMO, etc.)
Product management department
Software engineering department (QA, DevOps, Software Developers)
Sales & Marketing department

The organization is simultaneously working on several subsystems to form a single platform that serves your clients. So, the platform itself is a product we will be talking about, while each independent piece of it will be called a sub-product. The sub-product is developed through definitions of scope, called initiatives.

The key actors in the process are the following:

A stakeholder. A person who initiates the context of work and is perceived as a target audience of the future feature release. Clients, C-level executives, and product managers are the ones who in most cases could be stakeholders of a specific feature. Their responsibility is to provide the description of a potential problem or opportunity to the underlying parties who will kick off the discovery and development process.
Product manager. An individual who is assigned to the initiative and who takes a responsibility for the overall delivery of the latter. They are responsible for gathering initial requirements, scope definition, and success metrics, as well as acting as a source of knowledge for the initiative.
Project manager. This person is responsible for the correct execution of the development and delivery process of the initiative as a whole.
Development Lead. A person who is responsible for the technical implementation of the initiative. Depending on the type of initiative, this could be the head of the engineering department, an architect, or a software development team lead.
Quality Assurance Lead. This individual is responsible for designing and executing testing plans for the upcoming initiative. Usually, this is the head of the QA unit or the team lead.
Product Marketing Manager. This manager is responsible for the go-to-market execution for the specific initiative.
Release Manager. Lastly, for our purposes, we have someone who is responsible for the release planning and execution when the initiative is ready to be delivered to the stakeholder. Though it is not necessary to hold a separate person for this role, I would still separate the responsibility for the implementation and release of the initiative. This helps the development lead to focus on product quality.

Depending on the size of the company, the roles above may overlap. This is a common practice when people execute several roles at once, for example, the product and project management roles or the release management and development leadership roles. Also, some companies establish a Product Owner role, which is a mix of product, project, and even marketing roles.

Obviously, the list is incomplete without the craftsmanship roles, the people who make implementation and release possible — UI/UX designer, software engineer, quality assurance person, development operations engineer, etc. I have intentionally skipped the latter as these roles as they are usually not key players in the cross-team process setup. Still, you have to value all of the engineers and designers as they’re doing all the magic for features to happen and come to life. :-)

The Game Plan

Now, let’s say someone comes up with a new market opportunity! How should the setup look like to turn their idea into something with added value for the business that can be delivered to end-users?

Let’s start with common sense and outline a high-level pipeline of the process:

The high-level pipeline of development and delivery process

You may find similarities with the definition of the phases and phase gates from the PMBOK Guide. Although we do not treat the process as project delivery management, I find it useful to link some terminology from different methodologies here.

This is a good starting point. At least, we now have some sort of sequential pipeline that can serve the development and delivery process. Plus it sheds light on the responsibilities and expected outcomes from each phase.

But it is still isolated within each department’s area of responsibility, so we need to improve the pipeline with interconnected activities between the parties. Also, the phase-gate artifacts are not clear: neither the purpose of it nor the specific amount and types of the ones.

What’s next?

In the next part of this series, we will define the shared activities between the departments within the presented pipeline and outline the key process qualitative parameters and components needed to make it efficient.

Check Part 3 in the series here and Part 4 here.