Sync vs. Async Processes in Product Development [2/100]

I’m writing 100 posts about product development and product management. For this challenge I take weekly cadence, so you can expect a new post every week (or less). This is post #2.

I don’t really like any Scaled Agile process. I don’t like LeSS and especially SAFe. There are many issues with these processes, they are complicated and not elegant. But one issue is deep and it’s about synchronous versus asynchronous product development processes. In this post, I want to explore them. Let’s go.

⏰ Sync: Team Iterations

Many companies use iterations for product development. The idea is very simple, let’s impose some cadence on a team (a week, two weeks, a month) and do the whole product development cycle (plan/implement/test/release) in every iteration. Iteration synchronizes people in a team perfectly. It always has a scope, a deadline, and sometimes it has a goal. Looks good.

Unified business context and deadlines are usually very helpful. Development team can work without deadlines, but it demands incredible self-discipline and professionalism 🇯🇵. Most programmers need external constraints to deliver something good in a reasonable timeframe. Otherwise, there are tendencies to deliver something great in an unreasonable timeframe (or even something poor in an unreasonable timeframe).

Deadlines help us to evaluate technical debt and decide what level is OK for us right now. Deadlines help us to minimize the costs of bad decisions (If the decision is bad, why spend much time on it? We will re-do it later anyway).

Iterations do have problems for sure:

1. They don’t really work for the fluid external context. If you must do something new right now (a blocking bug, a very important prototype for a very important demo for a very important customer), iterations are not helpful at all. Many companies operate in the fluid context: early-stage startups, companies in the evolving markets.

2. Iterations are questionable for the very complex tasks that demand deep research and experiments. You can always try to squeeze a research task into an iteration, but its duration is unpredictable. You will box it, but you can’t predict how many iterations it will actually take.

3. Iterations are repetitive and the product team can get bored. You can add some pepper into the process, like creative breaks between iterations, special iterations for technical debt, etc.

All these problems can be solved, so team iterations are good enough and helpful. However, what about larger structures?

🐌 Sync: Meta-iterations

SAFe stretches iterations from a single team to dozens of teams and hundreds of people. This meta-iteration is called Program Increment, it takes two days to plan (weeks to prepare) and up to 150 people participate.

All teams inside this meta-iteration should work in sync using the same schedule. It means if you have 11 teams, all these teams start iteration on Wednesday and finish iteration in two weeks on Tuesday.

What’s the point? Program Increment gives teams a chance to discover and manage dependencies. In fact, this is a useful practice, some dependencies are hard to discover and they can change plans enormously. Imagine you have a core team and in the middle of an iteration, you got a few unexpected requests to provide some end-points for feature-teams. Most likely you will reject their requests and the teams’ plans will be violated. With two-day PI planning there are good chances that these dependencies will be discovered up-front and reacted accordingly.

The second cool thing about PI is shared business context. Execs share vision and features to fulfill this vision, so there are some chances that teams will get it and understand why they exist.

Dependencies management and shared business context are valuable things to have. But can we get these things without so many meetings? (my calculations show that people spend 20% of their time on meetings in SAFe). Synchronization is expensive. What if we can have all the benefits with just-in-time interactions? I think we can.

🧬 Async: Features dependency management

Dependency management is the second hardest thing in product management (the hardest is prioritization). It’s a complex area that should be addressed by organizational structure.

The worst-case scenario is when you have 11 equal teams and dependencies can be everywhere. This is hell. The best-case scenario is when there are no dependencies at all. This is heaven. Heaven is unreachable, but at least we should avoid hell. Here are some ideas:

1. Cross-functional product teams (must have). In functional teams, you can’t remove dependencies by design. In cross-functional teams, you have chances to remove dependencies between some teams at least.
2. Specialized area units to set dependencies direction. Imagine you have a Platform unit (P) with several teams that work on the platform, and several Feature-units (F) that focus on some functional areas in the product. In this case, Feature-units will depend on the Platform, but not vice versa. It is also possible to design Feature-units to minimize dependencies between them. For example, some units can be responsible for Search, while another unit for Account management.
3. Just-in-time communication about planned features start. Feature unit can broadcast the information about upcoming Feature X start in few weeks and Platform unit can check, read, think and discuss possible dependencies. It will give Platform unit enough time to react and plan its work, but the process will be async without 2-days meetings. In some cases, meeting will not be required at all, or a brief discussion will be enough.

This is just one possible product development process. The main idea is that it is possible to minimize dependencies using organizational design and async processes.

📣 Async: Unified business context

Can we unify business context async? Do we really need sync meetings every 3 months? The major goal of the product manager is to generate the product vision field that guides teams-particles. This field can’t be just turned on for two days every three months, it should be on all the time overall. But this is hard to achieve.

A product manager should write posts, explain, answer questions, remind and discuss vision and goals every day. The vision should present everywhere explicitly. Shared business context is a continuous process that consists of many small interactions.

No matter what, some teams will resist the field, and some teams will even move in a different direction. It’s life.

—

Sync product development processes are easier to start and run, but async processes are more performant (if done right). Ask programmers!