“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

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.

A little background about myself. I’m a capoeirista. What does that mean? I play (or more accurately have played) the afro-brazilian martial art known as capoeira. Why is this important? Because any movement artist, athlete, dancer, martial-artist, etc. will tell you that there is a HUGE difference between agility and speed. Speed, quickness, increased velocity, ability to move fast, etc. while usually requires some sense of agility, by itself is not agility. Agility requires balance as a core component for its description.

Agility is the ability to change the body’s direction efficiently, and this requires a combination of balance, coordination, speed, and strength.

Agile is a great word to describe the point of Agile Methods. We need to be able to change direction easily and quickly in response to new information. This is only practical. But agility as noted in the above definition is not just speed. I think anyone who has gone to the gym a few times knows that speed by itself only leads to badness–pulls, sprains, or worse.

And it is here that many Agile Methods fall. Why? Because any dancer or martial-artist will tell you that to be balanced you have to have a stong base from which to move. Now a strong base does not mean it has to be huge. It just needs to be strong and possibly needs to be deep to make up for size. And when I say the methods fall, I don’t necessarily think that the methods themselves are bad. Not at all. I just think they are either in complete in and of themselves or for the sake of being “expediant” (more on this puppy later) we don’t build the strong deep base needed in order to support ourselves while we twist, turn, flip and move through the rain of change that comes at us.

And it isn’t that they fall completely. They attempt to add in communication and paired-coding practices which are a good start, but they don’t go far enough to deal with the full range of balancing act needs that are necessary.

As a designer I won’t even go into the places where they fall short on user centered design. Yes, they have “user stories” but these stories are not derived from real ethnography or other qualitative research metods, so the whole thing is sorta made up. But there is just so much more here as there is no validation on usability in Agile processes. Yes, we stop to reflect, but not a single Agile method I have come across takes their interfaces back into the lab space. Not that they can’t, but they don’t account for it.

And this is where I feel the whole idea of expediancy vs. efficiency comes in. There is a an important balancing act here when working in the recent upsurge of the “time to market” economy. We have become focused on time as the only factor in agility and efficiency and we have forgotten that quality and strategy are also important aspects to this. Agile methods are not grounded in strategic, nor innovative thinking. If you take Agile Methods at their core there is no time alotted within them for strategic or innovation thinking. Nothing up front means well no time for probably the most important aspects of design and development: problem definition (deconstruction) and creativity in innovative thinking.

Upfront time is required to do these two things. Which is why we need to better contextualize agile methods as a mainly tactical process whose primary purpose is to execute on pre-defined items. What they want to do is get to the doing as quickly as possible. This “as possible” point is probably where a product is made or lost.

What design practice offers instead is just as agile and just as “doing” oriented, but it uses its processes as a means of getting at strategy and innovation WHILE leading towards execution. It assumes a safe phase where production and design are separate from each other, but where definition periods are constantly modeling (aka prototyping). Models for reflection not tied to production are important, because when people think their code is for production purposes they concentrate too much on “what can I do now” and never get to “what can I do”, or more importantly, “what should I do”. Designers are the engine of innovation because they push past these points of reality and are best at creating new realities.

Now that being said, I definitely believe that developers have offered tons of innovation through the open and agile processes they have used.

Most of my cautions though come from the enterprise side. Where the moving pieces are many, and it is hard to jump right in when there are so many interlocking interdependencies. Without clear definitions it is difficult to just jump forward. In the cases where this has been attempted we find that big holes are created and like making a mistake in an Ikea piece where you didn’t follow the directions right, you have to begin by deconstructing all that work done previously to get to skinning the onion where the initial error was made.

So as we move deeper and deeper into agile methods I want to push designers to hold out that agility requires balance and coordination and that sometimes a well defined lay of the land is the best base on which to balance agile development methods.

Be Sociable, Share!


The archives run deep. Feel free to search older content using topic keywords.