expediancy vs. efficiency | speed vs. agility
These pairs of pairs are really related to a problem facing the design and software engineering communities right now. They are all too often used as synonyms when in fact they are far from it. I find as I write an article like this, I am not saying anything new, but for some reason, it feels like a semantic understanding is missing from the current discourse around Agile methodologies.
First, let me say that I am a big fan of the spirit of Agile methods in many forms and through the push that my current employer has given me, I really see a lot of value, and have seen things work really well when Agile methods is taken to be a philosophy of running an organization through a product lifecycle. I like it. I like how it keeps me on my toes, how I feel like my mind is always engaged. It’s like I’m working for a consultancy again, but with all the benefits of being in house for a product company.
That being said, this semantic confusion that I’d like to discuss happens at my company as much as it does anywhere else in the world. This is a problem because the current discourse of Agile Methods is undercutting a very big part of product development: quality.
Notice I didn’t say design. “Design” is a feefdom at best and is not the goal of product development. Quality to me is an important goal in product development and it is effected by and leads to many different things way beyond the scope of what I can do here in a short blog article.
Let’s go deeper now and see what I’m talking about.
