Here’s the second article in our series on optimizing the cross-team product development and delivery process. You can check out Part 1 here. There, I defined the problem, provided some out-of-the-box solutions, and how to integrate different processes. I also added some context for all the different stakeholders involved along with a diagram (below) of a gameplan that we can follow.
Functionally, we defined a high-level overview of the sequential development and delivery pipeline. Now, how do we know it works as expected?
Key Indicators
Every process you build should be based on a set of metrics and indicators that represent its efficacy. The one we are crafting here is not an exception to the rule. So let’s think of a couple of qualitative parameters that define the process:
- Ease of communication
- Transparency
- Bidirectional information flow
- Clear exit criteria and the definition of done
- Existence of a single source of truth
- Strict separation of responsibility
What is important to understand is that all the indicators above can be applied both to a process as a whole and to each phase separately. Let’s take a closer look at each indicator and see how it can be evaluated.
NOTE: You may automatically start thinking of such parameters as performance, velocity, integrity, added value, and so on. Although it might make sense to include these as well, I do believe that they are just a side effect of the quality of the development and delivery pipeline. If you take care of the indicators mentioned in this post, the rest of the supplemental parameters will automatically improve.
Ease of Communication
Communication is the key, basically, to everything. But it has to be efficient. This means setting just enough recurrent meetings, producing a meaningful agenda, and closing meetups with written outcomes and next steps.
But not only. You also have to establish and support communication channels in collaboration tools like Microsoft Teams, JIRA, or other project management software you are using. The written form is easier to track in case of any confusion in the future and, of course, easier to share across the parties involved.
Some key communication points to consider:
- Initiation context. Make sure the stakeholder can dedicate enough time to iterative collaboration with a product manager assigned to the initiative.
- Discovery. Critical communication point — here product, project, and development lead to discussion and planning of the future implementation plan.
- Development. Constant reporting and status updates are required, as nearly all change requests appear here. There are tons of materials available online on how to establish proper communication during the development phase.
- Go to market. Make sure that the product marketing manager is aligned with key KPIs, metrics, and capabilities of the system and produces the correct marketing materials. Otherwise, you’ll end up rushing to fulfill promises given to the end-user, but never intended to be delivered at that time.
- Release. Make sure that changelogs are clearly shared with all departments. It’s also very important to share how the expected metrics align with the actual performance after the release.
Additionally, you have to make sure that each department lead is joining the conversation at the right time. You might wonder, but this is still an issue with many companies.
Summary:
- Definition: Being able to collaborate with key stakeholders of the process in a shared environment.
- How to track: By receiving feedback from key players. You have to ensure that they don’t have any issues with communication in cross-functional meetups.
- Dependencies: Communication is entirely up to the professional attitude of each player, as well as the proper configuration of the communication plan.
- Outcome: Improves everything. Simple as it is.
Transparency
What does it mean for the process to be transparent? And how does it affect the overall success of the product development?
Every key player in the process should be able to answer three questions at any time:
- What are we building?
- Why are we building it?
- How are we building it?
If the product manager or development lead cannot answer any of the above questions — how can you expect the desired outcome to be produced?
The key to establishing good transparency, of course, lies in efficient communication between departments and easy access to all of the produced artifacts such as exit criteria at each phase.
Summary:
- Definition: Being able to answer ‘what’, ‘why’, and ‘how’ at any given time.
- How to track: By controlling and minimizing the number of redundant discussions and meetings. Also, ensure that the exit criteria from each phase are fulfilled. Or just ask people the questions above :)
- Dependencies: Ease of communication, and access to produced artifacts.
- Outcome: Increased engagement level, interchangeability, performance, and velocity.
Bidirectional information flow
This is a key indicator of proper change management. Each department delivers its own statements on estimates, costs, and expectations for the product being developed. But they are rarely correct right off the bat and will often require a few revisions before settling down to an acceptable level.
The process of shipping a product always comes with some level of uncertainty, so the more flexible the team is, the better you will conform to new challenges along the road.
However, to do so, you need the information to move back and forth between teams and departments - contrary to the usual top-down flow that is commonly practiced in many companies.
The person, who oversees the whole process, has to ensure that there is constant feedback being provided from all departments and that the information is shared with all key stakeholders. The classic way of doing so — is the so-called, roll-up meetups, established once or twice a week, and keeping a single source of truth of the process always up to date.
Summary:
- Definition: Channels to declare the state of the product at any given point.
- How to track: Roll-up meetups, written summary status updates, making sure that ‘yes’ or ‘rubber stamp’ culture is not taking its place around the process and that people are giving honest feedback.
- Dependencies: Ease of communication, and transparency.
- Outcome: Increased flexibility and faster response time to any changes.
Clear exit criteria and the definition of done
Each phase of the process should result in producing either tangible or intangible artifacts. Basically, this is the whole point of having a process, right? You don’t want just to gather a ton of people in a cross-team meet-up just for a nice talk, then do some work and produce nothing.
Having a strict definition of the exit criteria is a must. Let's take a look at a couple of examples:
- Initiation context. This phase should end up with a product manager being able to present the potential solution to a problem or an opportunity to all the parties involved. Consider something like a high-level presentation with key success metrics and the purpose of the work to be done.
- Discovery. A lot of work goes on here. Designers draw wireframes, the project manager establishes a team structure, the product manager deals with requirements definition, architects depict possible solutions, and so on.
- Development. Well, that is just all about building a working product, yes? And documentation (APIs, configurations, etc.).
- Go to Market. The result of the following phase directly corresponds to a number of marketing materials produced to reach out, engage, teach and sell the product to the target audience.
- Release. Think of reporting materials and changelogs, KPI measurement results, and so on.
If that seems too vague to you, don’t worry, we’ll cover the exit criteria for each phase in the subsequent posts. For now, I just want to make sure you get a sense of the importance and inevitability of producing artifacts during the process.
Summary:
- Definition: A list of tangible or intangible artifacts for each phase.
- How to track: Set up a minimum required list of artifacts to be produced after a phase is completed. But also remember, that overcomplication will lead to increased bureaucracy and a slowdown in delivery. Find the right balance.
- Dependencies: Ease of communication. People need to understand what are the expectations for the exit stage.
- Outcome: Improved clarity of the process and transparency. Also, clear expectations of the outcome will keep people focused on the desired results, which will in its own turn lead to a much faster development process.
Existence of a single source of truth
This indicator is aimed to avoid errors due to misinterpretations at any stage of the development and delivery. There should be always a record to refer to in case any details were lost during the discussion or development iterations. The record should be treated accordingly, meaning kept up-to-date all the time and aligned with the concerns of the parties involved in the development.
Take JIRA as an example. It can be a single source of truth for all the requirements and constraints defined for a specific feature. You can expand the usage of JIRA to reflect the whole product state.
If you’re not a big fan of JIRA (who is, really?) — think of any other project management tool. Trello, Asana, and so on. It doesn’t matter.
Each phase of the product development and delivery process can possibly have its own source of truth tied to the context in which it’s operating. The engineering department certainly should produce Software Requirement Specifications (SRS), work breakdown structure documents, design diagrams, etc. It doesn’t have to be 100-page presentation, just sufficient to keep product managers, stakeholders, and engineers aligned on the expectations of the outcome of the development phase.
We’ll take a look at specific artifacts in detail in upcoming posts in this series.
Summary:
- Definition: A place to refer whenever any uncertainty or miscommunication arises. People have different interpretations of verbal messages, don’t fall into this trap.
- How to track: Pretty much the same as with exit criteria. Make sure each department has an agreeable list of documents that they should create and refer to during the development.
- Dependencies: Exit criteria, separation of responsibility, ease of communication, transparency.
- Outcome: Improved velocity of the development & delivery process, better quality results.
Strict separation of responsibility
You have to assign a separate person to be responsible for each phase. And let that person do the job. But somehow, you can often see that a product manager becomes responsible for the whole delivery, and then starts micromanaging each phase, leaving less space for department leads to… actually, lead. That is a direct route into a disaster.
Development leads should define the solution and provide their own estimates. Product managers should be busy with the product definition and upcoming changes. The marketing manager should produce their own set of artifacts. They each have to take responsibility and power to do it in the most efficient way. Otherwise, don’t call them leaders - they’re your subordinates.
So, by assigning people to be responsible for something, you can delegate the context to them and concentrate on controlling and monitoring the process. Identify gaps, and miscommunications, provide feedback on produced artifacts, mitigate risks and keep the whole thing in a good shape in general.
Summary:
- Definition: Each department lead should have enough power and responsibility to handle the corresponding phase.
- How to track: Keep the environment shared only to a certain extent. Provide clear instructions on who is responsible for what. Don’t let product managers or stakeholders dictate the rules for other departments. They have other things to do.
- Dependencies: Ease of communication, transparency, clear exit criteria.
- Outcome: True leadership-driven environment that produces a lot of great side effects: people are engaged, motivated, and able to take the initiative when something goes wrong.
What’s next?
That covered quite a few points! But now we have the pipeline supplemented with the qualitative expectations from it.
In the next part, we’ll start breaking down the process and dive deeper into each phase. We need to understand how key players interact with each other inside a specific phase, what processes they can use to manage the “getting things done” routine, and what are the expectations and requirements of the exit criteria of each phase.
Check Part 1 in the series here, Part 3 here, and Part 4 here.
