Alan's talk made the point that iterating only makes sense once you know what you really need to build ("otherwise it just creates waste").
I really support his claim to make better use of interaction designers in the early stages of product development, even though many in the agile community won't hear the message.
Anyway, he's right on that point - whether or not the majority will follow ;-)

This is the most compelling description of an optimal Agile process that I have ever seen.

As a product manager, I think one of the greatest challenges is to ensure that the boundary between engineering and construction is preserved.

Alan, excellent work, i love your descriptions of the development process. It is so very often that the operation is a success but the patient dies. I want to be a proponent for pushing agile the development processes, designing for user goals and being a bridge builder between what the customer wants and what programmers can craft.

First rate argument in a classy package. It's great to see we continue to be pretty much on the same page. In my experience, the agile community is definitely catching on to interaction design and beginning to recognize the need for some up front design, particularly broad architectural issues of presentation and interaction design. Your "build one by agile, then throw it away" will be the hard sell, though, as it has always been.

I'm not very familiar with agile, as I'm not part of a med-large team. I do most of the programming and design for my company of 6 people. But everything Alan says works great for me and my company, even though all our programming is solo. When I follow the discipline of design, engineering, construction, I get much better results. The software actually accomplishes some great stuff, users get excited, and customers are happy.

When I don't follow this, there is a big sense of wasted effort...

As an strong advocate for both agile and Ux, I find this presentation very clear and inspiring, and will probably point lots of folks to it.

One point I would quibble with is that you still see Construction (i.e. programming) as mostly implementing a blueprint exactly as is, without questionning it. But in my experience, you learn a lot about the Right Thing To Build, by trying to build it.

Maybe that's what you mean by "plan to throw one away" (I'm not sure... it seems you are mostly advocating that as a way to learn how to actually build the thing, not an other way to learn more about what the Right Thing To Build is). I would also quibble that modern Agile practices like TDD and Constant Refactoring make it possible to evolve code iteratively without having to rewrite it all from scratch.

As an agency, how do you sell this process to clients?

Read this presentation on the same day I was told to keep out of User Interface issues. There were errors in what was to be presented to the end user, based on a totally false impression of who those users might be. But we have an agile project and changes at this stage would stop it being seen as agile.

I think you have addressed these issue in your presentation, its just that we don't get it, yet!

@DavidS

But we have an agile project and changes at this stage would stop it being seen as agile.

Huh? The whole point of 'agile' is that you can make changes and minimize the cost of same. If you cannot make changes, then the project is not agile!

Alan,

The first 105 pages of your 111 page presentation were golden. The blending of Interaction Design with Agile was spot on. Well done and thank you. The discussion on requirements and how users cannot articulate what they want – perfect and very true, as always.

So, I was going to send the link from your presentation to my programmer friends and requirements-gathering friends, but I stalled on the last 7 pages.

With the words of the prophet still ringing in my ears – something about… “Which is harder to change: a program with 1000 lines of code or a 1000 square foot slab of concrete?” – I can’t send the URL out. They would think me naïve. They would discount the perfect information in the preceding 105 pages.

Can you publish, on your web site, only the first 105 pages of your presentation? I would like everyone to read your important ideas.

Hooray,
Slick display powerful message. Will my management walk away with the message or just want you to do the slides for their next presentation?
Thanks for clarifying a couple of messages that I have repeated time and time again-
1. On delivering successful software - Give the users what they want. Figure out what they need. The trick is to convince them what they need is what they want. Then, you've won.

2. Write down these 100 letters. Time yourself, how long did it take you? That is your schedule. Now look at this crossword puzzle, it has 100 letters. Complete it correctly in the scheduled time. Oh, by the way, you don't know any of the answers.

Welcome to the world of software development ;)

Alan,

It feels like coming home!
You eloquently state what I have always been pushing in our organization. And we have started to become succesfull now only since our top management recognized the truth as well. Now we need to transform the sticky clay layers of 'industiral managers'.

On a side note... Being an interaction designer for a long time (before the term interaction design existed ;) I also recognize that there are similar fads and tantrums in the 'designer world'. And 'we' like the 'engineers' claimed to be the guardians of the truth and sole guarantees to quality.
It has been people like yourself that has designed the schematics for the bridges we were all able to build.
Thanks for that.

I agree with Rick Ragan, what on earth were the pages after 105 about? How could you possibly re-build what may have taken you many months in "as short a time as possible"? That just makes no sense to me.

In slide 104 you mentioned that Agile throws "little pieces" away all the time to get to the right product and the product right. Seems to me that throwing the result of that away would be foolish indeed.

Maybe I don't get it because I didn't hear your presentation in person, but you mentioned that you read the presentation out verbatim from the notes.

Please, please explain.

@Oluf, @Rick; Regarding "really throwing it away", I think a recent talk by Pixar about its design process presents a close analogy. They make each film twice, once in sketchy rough way but still as a film medium, and one last time as the final film you and I get to see. The agile approach of fail often and fail fast is like the animation studio's story board prototype film. Once it is known that the story works, the full blown film is then created quickly.

see: http://www.adaptivepath.com/blog/2008/07/14/conversation-with-michael-b-johnson-of-pixar-part-1/

Did anyone record this presentation? Yes, I know the slides are available with notes... but did anyone actually record it
? If so, please post it to YouTube. I would rather "see" the presentation than actually read slides/notes.

In addition to JP's post, why not provide a link to download the presentation slides with note. Having more varieties is good. Excellent website and projects, keep it up. Thanks.

Gosh, we started in this business in the same year. It was like reading my own writing.

One small observation, related to slide 13: I've always liked to use the craft of cabinet-making as the analogy to software development. Drywall plastering never produces anything as beautiful as an armoire; great software is always that beautiful.

Overall, nice presentation. Thanks!

@Jim, good point, but at times you can see it a little differently. Drywall, like software, is most noticeable when it is done poorly.

When it is done very well, it can result in a very positive response, but often at the subconscious level.

The one point in the presentation that seems out of date or incomplete - at least in my experience - is that the main driving motivation to shorten development schedules is the desire to reduce costs.

I'm guessing for just about any commercial software venture, from small startup to large, publicly traded firm, software development schedules are driven 100% by the need to meet investors' requirements for revenue generation within some arbitrarily specified (generally short-term) timeframe.

The focus is not on minimizing costs, but on limiting development to that "minimum viable" list (to induce customers to upgrade) that can be completed on a given 6 month, 9 month, etc., revenue schedule.

The resultant schedules may or may not have anything to do with the needs/requirements of the development team. Nor is there any actual requirement to maximize customer benefit or the overall "big picture" quality of the software.

Needless to say, this is a major challenge and one that doesn't really get addressed in the "Efficiency/Effectiveness"/ "Qualitylines" sections of the presentation.

You know what made me laugh? After reading 111 pages of fabulous insight into the importance of interaction design, on the very last slide I found myself frustratingly trying to right-click to open the journal link in a new tab, trying to copy the URL to clipboard by selecting it. Grrr... The last thing I thought of doing was left-clicking the links. What an idiot I am, eh? :o)