Alan's keynote at Agile 2008

I was asked by the leadership of the Agile 2008 Conference to give the closing keynote address at their annual conference in Toronto. The audience at Agile08 consisted of about 1500 programmers, engineers, product managers, and others involved in the creation and deployment of software primarily using Agile methods.

My belief in the value of detailed written design has often led enthusiasts of Agile to assume that I am an adherent of the obsolete, and justly maligned, waterfall method of software construction. I was pleased to have this opportunity to state my position with clarity and precision, not to mention making the case for effective collaboration between interaction designers and Agile programmers.

Here are the slides and accompanying speaker's notes for my talk. Some in the audience noticed that I was reading from my notes during the presentation. If you're interested in why I chose to do this, read this Journal entry.

If you would like to discuss this presentation with me, either post a comment to the Cooper Journal blog or email me directly at


Christoph Steindl
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 ;-)
Dan Schmidt
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.
Larry Constantine
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.
Len Schultz
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...
Alain Désilets
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!
Rick Ragan
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 ;)
Paul Neervoort
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.
Henry Chen
@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:
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.
Muslim A. Mahmood
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.
Jim Hudson
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!
Dave Cronin
@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)
Nick Trendov
Think about building Personae backwards from the mask with stories and processes to the person. This avoids the problems you describe with waterfall and how I describe as constraining Personae to people. Taking this approach I have been able to replace the product or service that is linked to Personae with expertise to provide a unique tool to identify expertise gaps and support training at companies where M&A, business model change is a cause of stress. Innovation is another beneficiary of this backward approach as there is a breakdown between the harvesting of creative ideas to their manifestation. The gap is lack of process support and integration. Building a Personae with a decent mix of stories and processes helps identify expertise needed and when compared to people how training may be applied. I've outlined it at where it is not slick but should be understandable enough. Cheers, Nick
Jason Anderson
@ those who don't understand the "re-write at the final stage"... What Alan's suggesting, and what I've seen work in many, many projects, is using all of the knowledge and code-base that was built in the agile phase and then -quickly and accurately- re-packaging this in an efficient and effective manner to produce a Gold-source ready for distribution. No matter how good your agile method is, you will often end up with bits of code that are not as efficient or neat as they could be and this can lead to issues later in the product's life. This final "quick re-write" is really aimed at taking what you've already written and polishing it up into a "new" code deliverable. It's not about re-writing every line of code from scratch.
Stephen Cornelius
This is an excellent presentation. However I'm not sure that it is always reasonable to "Tell managers you want to work to a standard of quality, not time." [slide 60]. Realistically companies have to keep costs under control. At this stage many are still struggling to figure out viable online business models, and it is quite possible to make a beautifully designed product which users love, but which never succeeds in making any money. The CEO of my former employer told us that he 'just wanted to try things', and I in this situation it seems reasonable to say you can only risk $X. I think agile can be a great approach for such limited-liability development, because in theory you can trim and adjust to guarantee something shippable by a certain point. However it is quite difficult to do, requiring strong product management and some hard reasoning about priorities. Unfortunately my former employer lost faith in agile, threw the baby out with the bathwater, and switched to fix-bid contracts from an offshore supplier with predictable consequences for quality and innovation. FWIW I've written an article about this here:
Jason Anderson
I'm wondering if anyone has real-world experience of this precise process that is being recommended? How has it worked in practice? What had to be changed, dropped, cut up or otherwise morphed? Was there a metrics way to measure the change in quality/happiness?
Smil Ochs
I am a 76 old engineer in an undedevelpped country (Brazil), trying 1 - to convince oldtimers in the Company the read written instruction insted of clinging to spoken ones 2 - to make managers to sak what they need instead of telling them what to do. I hope your brilliant presentation may helt.
Can you post the keynote presentation please? The link opens a window, but nothing shows up. thanks.
Leo Frishberg
Help! The link to the preso is broken. I use it frequently to help my cohort understand the value of Agile and the value of UX. Thanks!
Talking about this keynote, I heard some people say that they got the impression that Alan advocated going back to a waterfall-like sequential process?

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment