Process Should be Reflective, not Prescriptive

One of the more common things I write about is my dislike of common software development processes. There is a commonality to be found in poor process:

They are prescriptive of what to do, rather than reflective of how the work is done.

A prescriptive process attempts to define how work should be done, at all levels of the organization. While not always true they tend to be crafted in seclusion from those that will do the work, have a desire for certitude that is unrealistic, and are dictated from higher up in the organization.

A reflective process is built by those doing the work, who have an understanding of what the desired end-state is, and will add the minimal amount of additional overhead to the actual work to know that things are being accomplished.

A prescriptive process can be effective for operational systems, things that are largely known problems with known solutions. You billing department is a good example, there is no real reason for creative solutions to sending and receiving invoices. I think of prescriptive processes as those that manage an existing and defined value in the world.

But when you want to add more value you will need to deal with some unknowns. This means a process that is more fluid and able to adapt to the evolving reality of the solution. Yes, this means that your ability to report on progress will involve some measure of waving your hands around in the air.

Accept it and own it.