I’ve seen several cases of process standardization recently. Those processes don’t translate to the current context. The processes don’t have sufficient agility to deliver the necessary results. Yet, people who want to use agile approaches don’t want to apply agile thinking to their processes.
Some clients want to create their custom agile process— and then standardize it across the organization. When I speak, I often encounter a “standard” process, which applies to all speakers regardless of the talk (lightning talk, talk, panel, etc.) I speak for some places that require all speakers use a standard slide template. (Which has terrible fonts and not enough room for pictures. Don’t get me started.)
These processes make life easier for the managers or the people who define the process. These same standardizations make life more difficult for the people who use the processes.
When other people define one-size-fits-all processes, those processes stifle the creativity we need—especially if we want to create change.
My Processes and My Agility
I use several processes to guide my daily, weekly, monthly, and yearly work:
- My modified personal kanban to manage my daily work.
- Rolling wave planning to achieve my longer deliverables.
- Checklists to finish, so I don’t get to 90% done, or worse, 98% done.
I’ve evolved these approaches over the years, and I continue to evolve them with double-loop learning.
Once I went to all virtual client work, I changed how I manage my calendar. I’m in the midst of reworking my online workshops.
I need process agility because my context changed.
I want to achieve different and better outcomes, especially given the different context. I’m experimenting and learning. I use double-loop learning.
What Prevents Your Process Agility?
When I see “baked-in” processes, I wonder how they got that way. Often, the people experimented until they discovered the first thing that worked. I’ve experimented with my processes for years, and I am sure I will continue to experiment.
My experiments don’t always lead to the outcome I want. That means I need to recover quickly so I can deliver the outcome I want. (One of the reasons I use very short deliverables for my work.)
I suspect that when we think of a “standard” process, we’ll achieve a certain result. That might be true—in a given context. When the context changes, we need to change our processes.
I suspect that seeing the changed context might challenge most of us. For example, work from home is not the same as remote work. (Yes, I’ll explore that in a future post.)
A defined process does not guarantee a successful outcome—especially when the context changes.
I bet we would all agree more on process agility if we could see when our context changes.
Let’s see if we can make our processes more agile, and create more possibilities for better outcomes. Especially when the outcomes matter more than the process.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Process Agility: An Impossibility? Opinions expressed by Java Code Geeks contributors are their own. |
