In April (April 1st, actually, but it wasn’t an April Fool’s Joke), I wrote a post titled Don’t just change the process if people aren’t following the existing one. That’s a long title, but I didn’t have a cute way to frame the topic in a shorter way.
Recently, the team of the Agile Weekly Podcast, a group of 4 agile folks (which makes for a very dynamic discussion on a podcast), covered the topic on their Episode #61. Although many of you are not necessarily engaged in the specific application of agile and lean software development, I think the 16 minute discussion is still an interesting listen.
Early in the post, I think they got to the heart of my post: it’s not always the process’ fault.
Let me share a very silly example just to make the point. I only come up with this because I minutes ago saw a commercial where this happens (don’t ask me who it was for). Imagine someone walks into a glass door with their coffee and spills their coffee. Is it the process fault? Do we need to put stickers on glass door so it’s not so see-through? That might defeat both the functional and aesthetic purpose? Eliminate doors? Make everyone carry spill proof coffee cups? Or does the person need to look up instead of down?
Sometimes we need to change behavior.
That doesn’t mean retrain every time there is a process failure either, as I’ve already delivered that rant.
When a problem occurs, we should understand the multiple reasons for the failure, and pick the best path to success. We can always make the process easier, but it’s not the only lever we can pull, and it shouldn’t be the only one we ever pull.
Listen to the podcast, and let me know what you think.
Want to get these posts as they are published? Sign up to receive my blog posts by email by entering your email in the subscribe box to the right.