Hi, I’m Adil Wali. I became a Microsoft certified professional at age 14 and started my first web development company. That led to a career as a serial entrepreneur, advisor, and startup investor. I got my first “real job” at 33, and I’m now a FinTech executive with a passion for the markets.
So, I have been fortunate enough to be part of a lot of conversations with a lot of smart people recently. A good number of them have been centered around one topic: agile design. For me, it’s sort of funny that this topic has come more and more into the spotlight over the last year. The first time I started talking about ‘Agile Design’ was in 2008, when ModCloth was just starting to build out it’s design and development competencies. Back then, I think people mostly thought I was crazy. The feedback was plain and simple: “agile doesn’t make any sense in design. Developers don’t understand our world. Our process has to be ‘creative.'”
Today, I think folks are slowly but surely coming around. If I had to guess why, I would say that it has to do with the environmental factors mostly. Agile methodologies have grown in popularity, considerably so in the world of software development. A lot of folks have been evangelizing their specific brand of agile over the years, and I feel like it’s really hitting a tipping point. (Or more likely, it has already hit the tipping point.) So people are realizing that agile is really here to stay, and that means that it’s really hard to ignore in the design world. The most compelling reason, of course, is that one of the core principles of agility is empowering the team. So if the software developers are empowered to start envisioning the software — when do the designers get involved? Well, in some companies I know, the designers are mostly charged with making stuff ‘look pretty.’ How fulfilling is that?
Ok, so agile is here to stay. And it creates a weird situation for designers (and others) in organizations where only the software developers are practicing agile methodologies. And now days, people are starting to throw around this phrase ‘agile design,’ even though what it means is is not clear to anyone. So, let’s figure it out:
The core principles of agility are simple, in my words:
- Chaos: Agility is all about unpredictable processes. The primary goal is to be able to respond to change as opposed to following a plan explicitly.
- Bravery: Unless you are brave enough to make mistakes or get feedback before things are ‘perfect’ in your mind, you are always going to lean towards waterfall.
- Get real: The idea is to build stuff instead of creating comprehensive documentation that tells you what to built.
- People over process: It’s about getting smart people together and figuring out the solutions as opposed to being too prescriptive about following rigid processes.
- Collaboration: If everyone is on the same team, everything gets done faster.
- Iteration: Don’t try to build towards a ‘grand unveiling’ — that never works. Instead, build iteratively and get feedback along the way.
Because I can’t live with myself without sketching out a quick visual of how these principals drive one another:
So, before we do anything else, let’s ask ourselves this: do the principles above apply to design? My gut tells me the answer is yes. Chaos is a reality of nearly any organization. You cannot clearly predict the future, so you have to be ready for change, and you have to be ready for your vision to evolve. And the same bravery that would enable a developer to show someone their code or their half-complete feature is the very same bravery needed by a designer to show someone a design before they think it’s 100% ready, no? And the principles of iterative work and collaboration also still apply to design, no?
So can you engage in agile design? The answer appears to be yes. Is it exactly the same as agile software development? Of course not. It’s safe to say that both software development and design are creative processes. But they are not exactly the same in terms of how they are accomplished (or how long they take to get accomplished.)
But there is more to this topic than meets the eye. If your organization is going to buy-into the idea of agile in the realms of both design and development, how are you going to enable both of them to get together? That seems to be the core question. I’ll followup with some thoughts on that soon!