Just a few cents, in a quick scribble

From experience: Don is absolutely right. In a stage-gate model, we as designers have had the privilege of being able to do a great deal of research before actual coding starts. I was an interaction designer in a smart-phone development project 10 years ago, that was run as an agile project. The experience from that was that I had to work in full-duplex parallel with sketching for the application and user/design research; the application should be executable every second week. That was good, because I always had a running prototype of the application to tinker with and show/test with users. But it put a lot of performance pressure on results from design research and design action. So it felt more like Agility (dogs) or Trial (motorbike).

On development thinking and design thinking: In my current work as a design educator we are setting up courses where the students are supposed to learn to design, as well as to plan and structure a project. There always is a struggle for the student to handel the friction between the designerly iterative emergent way of working, and the structure of deliverables, milestones and gate decisions. Usually I try to explain that behind these there are two different rationalities: 1) the iterative/emergent is based in an individual way of working or a need for emergent adaptation (which is not specific for designers), and the linear/structured is based in a need for an organization to keep track of resources and results. In some organizations merging the two can be possible, as Don says.

On Terry's question: From my point of view some of the basic values founding "agile" is similar to ones that are foundational for design methods. Such as "solutions first strategies": using suggested solutions as a means to understand what the underlying "problem" might be. This does not necessarily mean it is a design method. Precisely these values is in friction with the management rationale behind stage-gate development models.
On the other hand some of the drivers resulting from "agile" are similar to drivers in development methods. Such as "integration driven development": where the aim is to direct the development based on the process of final integration and testing of the whole system. But, this does not mean it is a development method.
So, I would lean towards describing it as a method of development using some values that designers recognize as designerly.

All the best
/Stefan Holmlid


PS: And then, uncommented: there is the interesting difference between technology development (such as developing cyclone technology), and product development (such as developing the vacuum cleaner).


-----Original Message-----
Subject: Re: Agile design and development

Let me add a comment or two about Agile to Peter's excellent description.

Agile has a number of major benefits. It speeds up the development cycle, provides for "late binding," that is, postponing some design decisions until as late as possible which allows for some early results to modify the design (something traditional stage gate (waterfall) techniques do not allow). It reduces wasted time in meetings and reviews, and the time wasted in preparing for them (in large projects several months can be wasted in this way).

BUT: It is really difficult to integrate design research and planning into their hectic cycle. The methods were designed by and for programming teams who wish to start coding immediately, on day one.

Designers would like to start by understanding what problem is to be solved and by collecting some data (observations) on the real issues. Although it is possible to accommodate good design principles into agile methods, it is only a slightly unfair generalization to say that Agile teams are both resistant to doing so and antagonistic to anything that delays the the developers from getting immediately to work.

Agile, therefore, presents a real challenge to the design community. When Terry asks whether it is a development method or a design method, I would reply that it is a development method that has the danger of precluding good design methods.

Note too: Agile has been very successfully deployed in small projects, ones where the total team size is 5-30 people and the total time is a few months.  With large projects, with hundreds or even thousands of developers who work for many years,  stage gate is the only method that works. Agile completely fails (people keep  telling me they know of a success or two, but i have never been able to verify this).

Why does stage gate work even though many people hate it?  (My automobile friends hate it because the need for reviews at each stage (each review is a "gate") slows up work, wastes enormous time, and once a gate has been passed, it is very difficult to go back and change anything that was developed at an earlier gate. They hate stage gate but they use it and enforce it.  Agile is intended to overcome these problems.  (Modern stage gate methods have tried to incorporate Agile principles inside of each
stage.)

But good design is of special importance in large projects. Moreover the hardest part in a large project is management: coordinating the work of the many teams, managing changes in personnel, goals, and methods, and keeping things going smoothly. With hundreds or thousands of workers over a period of time, people and goals are continually shifting. People quit, or are fired, or promoted. Executives change (or new politicians are elected), and the new people decide to change the target, or the budget, or the timetable. Management issues dominate.  Agile fails here.

(Actually, many large projects fail. Most go over budget and time. It doesn't matter whether the project is software, a transportation system, or a large structure.  Large projects often fail.)

editorial Comment: Design methods do not pay sufficient attention to the practical problems of development, whether large or small projects. That is one reason there is often a conflict between the way development teams like to work and the way designers wish to work. Projects are invariably late and over budget on the day they are started.  This fact alone is a huge impediment to the use of good design methods.

Don

Don Norman
Nielsen Norman Group, IDEO Fellow
[log in to unmask]   www.jnd.org http://www.core77.com/blog/columns/
Latest book: "Living with Complexity <http://www.jnd.org/books.html#608>"