1 Really? Agile is required b/c of the economy? ...

I admire your passion about agile development and you are right about some of the issues that make design and agile uncomfortable (but often required bed fellows), but I have a few disagreements with 1st the core assumption and then more importantly your understanding about what is design and how it works.

Core assumption that Agile is what we need b/c of the economy

Yes, fluidity, agility (lower case “a”), and efficiency are definitely needed, but what “Agile” (upper case “a”) represents is not efficiency but expediency. Agile was first defended in better times as not purely a way to cut costs but to make better software. I haven’t seen this proven yet. I’m not so sure that the case studies show would have actually been better with Agile or without. Cheaper yes, better. Not so sure. But this is a tangent. Your working assumption is that our economy requires Agile more than ever.

Ok, hmm? While Agile may address costs, I’m not so sure it addresses strength of solutions. Example, what is the poster child of software and product design success today? hmm? let’s think about the white chord going down your from your ears to your … oh that’s it, your iPhone or iPod (I’m sure there is one there). NOT done in Agile. Could never have succeeded as Agile. And is the perfect example of what we need to help us during these economic times. We need THOUGHT and Vision and Innovation. NOT Expediency. We need greater investment with less games. We need deeper investments that don’t try to skip important steps. (Derivatives anyone?)

So I really really deeply challenge your primary assumption that sets this whole article in motion.

Now to the real content of your article. Why Design does what design does?

Iteration is not a fools foley. It is purposeful and leads to better design. Artistic creativity is an important part of all levels of a design process. It is the core method of exploration of ideas based on the solid and proven belief that the 1st idea is not the best. Evaluative methods suggested in Agile get the current design right, but they do not actually address making sure you are doing the right design (read Sketching User Experience and see Bill Buxton’s and Alan Cooper’s Interaction08 presentations regarding these issues (interaction08.ixda.org). So to me because you don’t really seem to get the importance of real design methods it would be easy to negate their importance towards creating successful products and services in exchange for expediency.

That is really the most important issue there. But I think I also have to take on your example of using film making as a means of being agile. yes, THAT part of the process in film making is very fluid based on the needs of logistics. “Fluid” is rather a funny term in film making though because it is soooo incredibly planned and documented. I mean first there is a script. Talk about heavy documentation. Then designers (get that, designers!) have to do TONS of prep work on costumes, art direction, audiology, etc. usually using TONS of upfront design methodologies, while actors do RESEARCH on characters to better understand them. THEN the line producers take the scripts and usually using storyboards (more documentation) create schedules which have to be prepared meticulously for lots of logistical contingencies (such as weather or personnel issues) way in advance. This is the furthest thing from Agile I could imagine. So while your small piece looks agile, it only works because a greater whole is in place that enables the type of heavy planning that allows for the fluidity of line production that you’ve observed.

Now am I saying that Agile is capput?
HELL NO!!! Agile is a great down stream process that DOES add value and bring efficiency to the DEVELOPMENT process. But that does not mean that Design and Development need to be married in some layer merging that in the end makes Development the “man” of a husbandry like relationship between the two important facets of a product lifecycle. Basically, Design should do design as it knows best and keep dev out of its processes and let dev do what it does best and keep design out of its processes (Yes, this is an over simplification, but so is Agile Development). In the end, there is so much more to design that Agile gives respect to (just like most developers don’t feel respect from designers). Its important to remember that Design actually has outlived development (software) for some 100 years or so (not counting the several millennia that architecture has been around as a craft and design process. It has gone through horrible economic crises during the last hundred years as well, including a few big wars.

Now are there ways for Designers to find more efficiencies in their processes the same way that developers have tried to do? You betchya!!! Let’s discuss THOSE!!!! But they need to be discussed from a design-method perspective and not a development/engineer perspective. Our total goal is the same, but the ways we deliver our pieces are sometimes worlds apart and for good reason.

posted at 07:39 pm on December 2, 2008 by Dave Malouf

3 Shameless self-promotion…

This time two years ago, I wrote here about applying a modified waterfall process to Web projects: Avoid Edge Cases By Designing Up Front .

Neither this article nor mine demand purity, but both definitely take stands as to how to best run a project.

My beef with pure waterfall process is that the intersection of minutiae and politics is the MAXIMUM PAIN Zone; my beef with pure Agile process is that it’s too accommodating to organizational cultures that support the failure to think before acting.

Both need checks and balances — one to neutralize risk aversion that derails the project, the other to hold people accountable for command management nonsense that forces do-overs.

posted at 09:07 pm on December 2, 2008 by Ben Henick

5 OT: Timestamps

Both Dave and Jeffrey’s timestamps indicate that they posted their comments from, as near as I can tell, somewhere in the mid-Atlantic ocean. Can either of you confirm?

posted at 09:24 pm on December 2, 2008 by Kurt Morris

6 Design is necessary in agile development

There’s lots of nasty agile developer-types out there who don’t have a good understanding of what design is and what designers do. Please don’t let their ignorant voices squash the good thinking that’s starting to gather inside the agile community – including the agile design community.

For my money, agile finally conjoins the design process with the construction process. To over-extend the movie metaphor, finally lets the script writers and storyboard authors work with the actors; finally allows us to show our audience bits of the movie before it’s done to get early feedback so we don’t end up with another GiGli And David’s right in that lots of work is done up front on movies before we start shooting. But I’d submit that has quite a bit to do with the cost of “George Clooney’s“http://www.cinema.com/news/item/441/clooney-drops-salary.phtml time – and all the other people it takes to make a movie. If George charged the same rate as an off-shore developer, the process to make movies might go a bit differently.

Most metaphors break down a bit when talking about software… because software is SOFT – or at least it’s supposed to be. By soft I mean easily changeable. Building software shouldn’t be like constructing buildings, or making movies. It can be sorta like them – but the raw materials we work with just aren’t the same. The process should reflect that important context difference. At least one movie director, Robert Rodriguez, has figured out that movies are softer than others previously thought. Look at one of his 10 minute film schools to see film making. They’re on every one of his movie DVDs.

Process design is sorta like software design in that it’s the context that process fits in that matters – just that as it’s the context the software fits in that has huge bearing on its design. For those reasons agile isn’t a one size fits all process. I’m finding that most design processes were designed to fit in a waterfall context – to fit in their design silo. Smart designers working in an agile context have been successfully adapting a healthy design process to work inside of agile processes. I’m sure it’ll only get better.

Ignore the the agile bozos that dismiss design. They’re ignoring an important part of their context – that design is necessary for successful software.

posted at 09:36 pm on December 2, 2008 by Jeff Patton

8 Agile as the How, Vision and Design as the Why

Timely article and thoughtful response. I see both the advantages and the complaints at work as part of a small development group adapting to the Agile process in the last year (an effort still in progress). As far as Agile vs. Design, I don’t see it as debating either/or as an approach. I think the main thing to remember is that that Agile is an efficient and responsive development process; whereas as a design professional for an ongoing concern, you have to guide your design and proposals towards business goals and vision. I think designers can help the Agile development environment, lending an eye and a hand to help keep the ongoing process on target towards an end product design goal (e.g., what the end user needs); and learn something from it at the same time: to incorporate design changes earlier as more direct user needs are learned from feedback, and how to quickly update design implementation to meet more immediate requirements. It seems to me that somewhere in the middle, Agile will meet design so that the whole will reflect more adaptive and effective strategies to industry changes.

posted at 10:09 pm on December 2, 2008 by Stephanie Marcum

9 Re: Agile as the How, Vision and Design as the Why

We, too, are still trying (after two years) to find how design fits in to the Agile process. We still don’t have a “silver bullet”, but we are getting better. One huge advantage for us is our progress at tearing down the very walls between designers and developers that, for some reason, Mr. Malouf finds counter-productive. Indeed, my take is the exact opposite: By working closely with developers both before and during short-cycle sprints, we as designers have come to better understand the limits and possibilities of the platform, and the developers have come to better understand good design practices.

That’s a win no matter what.

Mr. Malouf is, in my view, correct when he states that Agile hasn’t yet given the design process all the “respect” it deserves, but that only means that we as designers have to educate and evangelize that much more, rather than throw out the proverbial baby with the bathwater.

posted at 11:46 pm on December 2, 2008 by Kurt Morris

10 Designers must let go of perfection

My problem with agile design work is the loss of perfection. Sure, the apps from 37 Signals are useful, but do I appreciate them like I appreciate the design of Apple products? No. I won’t let go of perfection, it’s in my nature as a designer.

‘Good [enough] is the enemy of great’

posted at 01:16 am on December 3, 2008 by Tor Løvskogen Bollingmo