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!

Patrick and me back in 2017

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.

Thanks for reading. Read the other Lessons here!

3 thoughts on “10 Years in Testing, 10 lessons – Lesson 9

  1. Thanks Maaike, this means a lot to me.
    The thing that nags me till today is that I was not able to get another message across. One that should have been rather obvious with the first task given in the workshop. Describe me, as a non-coffee drinker, how to prepare a _good_ cup of coffee. Gil explained to me every step along the way, but he never gave me an answer to my question how he can guarantee that the result is actually good coffee. Following the steps produces coffee, alright, but none of the important parameters were mentioned. Type of bean, degree of grind, water temperature and pressure, and more. (yes, as a non-coffee-drinker I know a lot about making coffee)
    Same was true for the toast lesson. Nobody gave any instructions on the quality of the product, only that a product comes out of it. What kind of bread to start with, thickness of the slices, temperature, time, degree of roasting, and so on.
    And for me that was the important aspect. You can prescribe a process to the letter, but the result might still be crap.

    And thanks for telling me about the lesson you learned. It’s interesting to see the different takeaways.

    Take good care, my fellow grumpster

    1. That’s a great point. Applied to code reviews, it just means “a human with permissions (that isn’t you) needs to push a button”, not that they must have read every line of a change or applied any real thought. Zero guarantees.

      That being said, I still like coffee, toast, and code reviews.

Leave a Reply

Your email address will not be published. Required fields are marked *