Frugal process
After backlog and code, let’s go on with the process. In this article, I’ll refer to the procedures, the methodology, the method, the practices, and not about the program doing stuff in a computer.
A process tells us what to do in a given context. It states pre-conditions for applicability, post-conditions of success, variations, attention points. A process always exist, be it implicit or explicit. A process has multiple nested levels of granularity, to produce, understand production, update the process, manage conflicts, communicate…
Company culture is everything making mandatory or forbidden, encouraging or discouraging, people reactions in some context. We can thus consider a company culture as a process. As behaviors, we can list and modify it (more or less easily is you want the change to stick).
The process is huge. We don’t want to make it more complex by adding arbitrary clauses to it. We need to factorize it, make it as little as possible. If the process becomes too complex, we need some additional process to interpret it. We don’t need that.
A process can accelerate things by:
- Guiding people, so that they don’t need to search for the right way to go.
- Avoiding people to keep wondering the same things again and again.
- Helping people do the things right first time.
A process can also ruin your life when:
- It complicates more than necessary what needs to be done.
- It prevents you from doing what needs to be done, unless you work around it.
An important quality of a process is its adaptability. Situations vary, and evolve. So a process must remain plastic. So we’re back to the same considerations as code: simple things are easier to adapt.
- When the process is a 200-page document, nobody will get back to it to adapt it to the new context.
- When the process requires 200 persons to synchronize in order to update it, nobody will make the effort.
- When the process is implicit, nobody can discuss it.
In addition, the process has to be more or less prescritive, depending on the context. The cynefin model, the more useful I know, helps us understand this, and choose a strategy to handle a situation, depending on its nature:
- In the obvious domain, where you can easily predict consequences from the context, define and follow a list.
- In the complicated domain, you can predict consequences given some analysis. Ask experts to tell you what to do.
- In the complex domain, the systems has too many too dynamic relations to be predictable, and they change when you touch them. State hypotheses, and validate them through experimentation. This domain is the most frequent in software. In the complex domain, you need a more abstract process. This process will give you clues to design experiments, gather feedback, verify you didn’t overlook some perspective.
- In the chaotic domain, it’s fire. Get out of there as quickly as you can.
- To which we add the cliff, from obvious to chaotic, where you violently loose your illusions. You thought your situation was comfortable, and competition shows you a very different reality. Falling to chaos is hard, and you need to get out while you’re still on kodak’s board.
- And the disorder, where you don’t know where you stand. It could deserve a whole series of its own.
The process must take all these domains into account, in a relevant way. Follow ikea instructions in the complex domain, and you will make too many useless errors. Experiment on methods to assemble an ikea furniture, and you’ll waste more than the traditional week-end of family chaos.
Note that lean proposes a very useful tool to handle this: the standard. The standard is the best way we know today to do something. It is the support for continuous improvement, because it documents our current knowledge, and constantly evolves from there. We get back to it as soon as we observe a gap with the objective (i.e. often), in order to understand what can be improved. It documents pre and post conditions, variations, attention points. Standards can be involved in anything, given its level of abstraction corresponds to the task at hand.
In short
- Take the time to understand cynefin. My current level of understanding took me a few minutes of epiphany, and several years of deeper study. Every second was worth it.
- Adapt your procedures to the context.
- Make your procedures explicit.
- Don’t add useless procedures.
AAAgile 
3 comments