Countless companies are in a purgatory of endless problems. The types of these problems range from optimization to fundamental.
An optimization problem is when you are productive but not at the level you know you could be. A fundamental problem is when you aren't productive or barely are.
It's very common for these companies to slip quickly into believing that any of these problems can be solved with more processes. This belief is particularly strong in western companies, as chinese companies approach processes with a lot more caution (for instance).
The Chinese approach focuses on speed of execution and sees processes as something that slows you down. So before you can adopt another process, you often have to demonstrate that the losses of the implementation are outperformed by other benefits, often by several multiples.
On the other side, western companies tend to embrace process with little to no pitch. That's because processes are put on a pedestal. They make people feel good. There is an almost dogmatic belief that without them, it's just impossible to deliver and if a little is good, more must be better.
This is what I call the process love affair.
The problem with this love affair is that processes don't fix broken teams. If you drop a process on a bad dynamic, the bad results continue regardless.
What processes solve are specific problems with a constrained impact surface by bringing structure and optimize flows.
They structure by creating a sets of rules that are followed when the process is respected. They optimize when the structure is polished to limit duplication, friction and maximizes downstream value from pre-existing information.
A team that lacks good processes often is still very capable of delivering world-class products if their dynamic is strong. It may come at a higher expense though. Higher quality of talent requirement. Higher efforts.
The other problem is that the best processes aren't effective unless designed and deployed correctly. When you see them as a magic bullet to all your problems, you will be tempted to go heavy-handed with them.
When this magic bullet won't deliver the result you are expecting, you will be defaulting to believe you didn't deploy enough of it - only to make it all worse.
Even people who preach deploying the bare minimum can exhibit this heavy hand because they are unaware of their love affair.
When they are designed poorly, they can turn into encrypted treasure maps where the cost of using the process is so ridiculously heavy - yet unchallenged - that it negates all possible benefits.
I'm not advocating for no processes. I'm advocating for self awareness to your relationship with processes, acknowledging the limits of their impact and a carefully crafted plan to deploy them successfully.
1/ Analyze and understand the capacity of the team.
Forcing processes to be respected will likely end up in processes not being followed or a high cognitive cost from the teams to follow said process. In short, the output will suffer instead of improving.
To solve this, you need to figure how much your team can adopt.
This can be very difficult when your teams has had bad habits that overwhelmed them with work. That's because this will drastically limit their bandwidth (time and mental) to adopt anything new. Their reaction is likely to be exaggeratedly strong as they'll try to tell you they are drowning.
So before anything else, you need to understand candidly what the team is capable of absorbing in the current state and in a state where you've carved out more bandwidth for them. (Scope cut, size expansion, etc)
As you do this work to get a range in mind, you want to do this for each team that will directly collaborate with each other. That is because the team with the lowest capacity will dictate what you can do next.
2/ Break down your ideal process into pieces
You can paint the perfect picture for your master process and optimize it to infinity as much as you want. It's not a bad idea to do so.
But the most important part is to break it down into the smallest pieces possible.
The smaller, the better as you can roll out more of these bite size pieces in each new deployment phases. If you deploy too big of a change, you'll be stuck for a much longer period in the next stage, or worse, you'll have to roll back, often with a trust impact.
3/ Deploys one step at a time
The definition of a step is directly linked to the absorption capacity you've identifies in #1. This could be a single piece from #2 or multiple ones. The key element here is that once you have deployed said step, no new deployment happens until the cycle is complete.
If a team is ahead in their adoption and looking at the next step, you'll have to hold them until the adoption is confirmed.
4/ Check on the team's adoption of the process step
The way to confirm that a new process step has been successfully adopted is to observe the team use it.
You do this by having the process owners (often project/program management) attending daily meetings (stand-ups, architecture sync, cross-functional syncs). If the team is no longer asking questions; if the team has adopted the new language; if the team is proactively leveraging the process step being deployed, you are at a level of adoption I call reflex.
5/ If the deployed step became a reflex, jump back to 3/ with the next step
Now that the team has demonstrated that the process step was fully adopted and is a second nature to them, you can move on to the next step to be deployed.
In this stage, it's also a good moment to take a minute (understand at least a sprint cycle) to give the team a break, observe the results of the step deployed and think critically about the next one.
That is because, even though you are going to deploy a new step soon, you may want to change the one you originally had lined up.
In case the step is being difficult to be adopted, you are looking at different scenarios that has to be evaluated with all the nuances of the team's dynamic:
What you don't do is, defend your process against all odds and data, because that means you're blinded by your love affair.