I struggle with process documentation. Teams start with Anarchy — no one knows how to do anything — but quickly develop tribal knowledge to get by, a set of undocumented processes encoded in habits and unsocialized tools. Your team is in this stage if people only figure out how to do stuff by asking others. And as long as the teams stays small, has gradual turn-over, and knows who’s in charge this is probably sustainable.
But growth begets a tipping point when team members join faster than they are indoctrinated — or a previously sound process doesn’t scale — and the system breaks down. The fix is obvious: put a person in charge of process documentation. Finally, we’re going to get some rigor around here! What happens next is predicted by a /. comment on software specifications and CMMI:
Most “Process People” sit around fantasizing about what process everyone should follow. Then they write it down and tell everyone to follow it. Never mind that they have never actually seen what people are actually doing now. This is precisely the opposite of what is recommended by [the CMMI] meta-processes.
That’s certainly what I’ve seen. Documenting the tribal knowledge of even a couple dozen people is insidiously complex and exacerbated by the meta-task of coming up with templates, processes to control the processes, and training for the old-guard and the n00bs. The result is either blissful ignorance (documented processes that no one knows about), or rebellion (processes that no one follows because things were improved as they were documented).
The antidote sounds simple but was a revelation, and frankly antithetical to my need to optimize (read: change) everything I touch:
Document what everyone is doing. Not what they say they are doing; not what they want to be doing; not what you wish they were doing; what they are actually doing. That’s your process. Compliance? Dead easy. They are already doing it. Documentation? It’s not exactly rocket science. Make sure people put version numbers on documents.
You are right that you should do the very minimum that you can do with ISO and CMMI. Not because it is a waste of time, but because sitting around concocting elaborate plans for a cool process doesn’t align with reality. Neither ISO nor CMMI tells you what you should be doing in your process. It tells you what you should be observing and thinking about. For level 2 you can write down pretty much anything you want for each section.
What a hack: transition from tribal knowledge to compliance without traversing through hell. That’s good advice, what’s next?
But the point is, once you have everything written down you can look at it and say, “Hmmm… we have some inefficiencies here. Bob, if you were to do X before Y it would help out Sally. Would that be OK?” Also, having written everything down it makes it easy for new people to come in and get an idea of the existing culture without having to discover it through trial and error. It allows them to quickly identify areas that they may want to change — “You know guys, in my last company we did X. What do you think”.
Only now can you improve things, by empowering the people who use the process to identify improvements, try them out, and update processes when necessary. Some parting wisdom:
In my time as a process guy I tried to spend 80% of my time documenting what people were doing, identifying things that had changed over time and asking why the changes were made. I spent 10% measuring various things and making pretty graphs for upper management. I spent 10% of my time giving advice for things that teams might want to try to improve their efficiency. I spent 0% of my time enforcing compliance. If people didn’t follow the process, then the process was wrong.