Long ago and far away I worked with a financial software product company with European customers whose purchasing requirements included ISO certification. The company jumped through all the hoops to become certified, which included documenting processes, etc., etc., etc. [Note: ISO certification may have gotten out of hand as there are now 24,000 different ones.]
This company’s staff quickly learned that following their own newly minted processes and documentation standards slowed development work considerably, so they, of course, created “work around” practices (often undocumented and “hidden” from executive management. Auditors would write up deficiency reports, which took staff (particularly project and first line managers) time to respond to. The auditors would write deficiency reports that basically said, “don’t do that again,” and the company staff would reply “we won’t do that again,” which of course they did as soon as the auditors left. The company could have updated their processes to correspond to actual practices, but that would require a lengthy certification update that they didn’t want to go through. As time went on, the divide between process and practice increased and staff continued to ride the marry-go-round of process and practice, which nobody—from programmers to managers—liked, or derived any benefit from. This story points out the basic differences (see the picture) between processes and practices:
- There is always a discrepancy between process standards and practical practices.
- The larger the discrepancy, the more time gets wasted.
- The larger the discrepancy, the larger the negative impact on staff morale.
- The larger the discrepancy, the more tension arises between management and development staff. The managers admonish staff to follow the process standards plus deliver on time, etc. so staff, to meet delivery expectations, have too increasingly “fudge the processes.” Which they resent.
Others have written about the practice-process divide, for example Michelle Morrison: “Change management is not about writing a bunch of policies about process; it’s deep design work to establish new operating practices for our teams.”
Maybe a portion of the criticism of agile today come from failing to recognize the difference between practices, which reflect the spirit of agility, and process, which do not.
©2023 Jim Highsmith
Morrison: https://dropbox.design/article/process-vs-practice