10 Years in Testing, 10 lessons - Lesson 9
Let me tell ya, I’ve participated in many workshops over the course of the last 10 years. But there’s one workshop that I will always remember and I’ve told the facilitator many times how valuable this workshop was. He always brushes me off and tells me it was not that great, I don’t know why he does that. Yes, I’m talking about you Patrick Prill, Principal Grumpster (go follow this good man on Twitter). I have thought about his workshop, Context Eats Process for Breakfast, so often that it warrants its own lesson. Hah!
Lesson 9 – Context Eats Process for Breakfast
Okay I’ll be the first to admit that I have a strong dislike for process. It’s not that I don’t want to use any process at all, but not more than I need. I also strongly believe that any process is just a heuristic and will yield different results depending on each person doing their best to follow said process. This way of thinking has gotten me in clashes with many people over the years, as you can imagine. I always thought Agile was my ally in this, but Agile no longer means what we think it means, as so many agile coaches shove “one way of working” bullshit down your throat, it’s not even funny anymore. I’ve come to the conclusion that many people just looooove processes and seem to think that many IT tasks fit into rigid processes, even in so called agile environments.
Here’s one funny story of how a process went too far and then we’ll get to the point of this lesson (or skip this paragraph, dear reader). You know how you can put all sorts of rules in your CI/CD process, right? Such as: you can’t deploy in Jenkins without a JIRA-issue number. Yeah, that one can easily be avoided by using JIRA-666 as ticket number. Ok. Then there’s the setting that you cannot merge a PR unless certain people give their checkmark of approval (because only they own the code or some bullshit?). Imagine having a problem in the weekend that requires immediate fixing but you cannot just push code to master. You HAVE to create a branch and you HAVE to get the PR merged, but those required people are off, enjoying their well-earned weekend so good luck with your fucking problem. Yeah, that’s why I hate plastering processes all over the place out of some idea that a developer might accidentally do something wrong, security amirite. Gotta prevent all mistakes! Imagine trusting the people you hire and accepting the fact that mistakes can happen. CRAZY! Ughhhhhh.
The point of this lesson is that in his workshop, Patrick finally gave me a way to get back to the people who are more than happy to increase the amount of processes or the level of detail in already existing processes. In the workshop, we had to draw the process of toasting a slice of bread. Turns out, it is impossible to draw exactly each step you have to do to get toasted bread. There’s always something you forget. Lesson: every process, no matter how detailed, requires implicit knowledge and/or implicit steps. No matter how detailed the process is described, it can be done differently by different individuals. A process is a guideline, not a guarantee. Context matters more. And because you are becoming more rigid the more you double down on processes it can open you up to all sorts of unintended side-effects. The biggest side-effect, that happens so often it’s almost a law, is this: “People will find a way to work around a process when the process doesn’t serve their needs”.
I can imagine you don’t really get how this can happen. Watch this hilarious YouTube video to get a feel of what “drawing the process of toasting a slice of bread” feels like.
Armed with the new intel Patrick gave me, I finally had a way to show people how processes can often do more harm than good. So yeah, context eats process for breakfast. The Agile manifesto is in line with this too, but the manifesto seems to become a myth more and more compared to daily “agile practices” at large companies. Sad.
Comments ()