Moving to the “agile paradigm”: questions from a neophyte

[Reflections after listening and reading about two approaches to product development]

One of the most interesting insights from our visit to the edenspiekermann design studios in Berlin was their emphasis on agile methods as the backbone of their design activity and the relationship with their clients. Born out of the software development community, agile refers to an approach where product development occurs incrementally, in a series of relatively quick (e.g. less than one month, frequently two- or one-week long) iterative cycles called sprints or increments. These are characterized by (i) permanent testing with end users (starting with a “minimum viable product” produced in the very first sprint!) and (ii) continued flexible adaptation to changing requirements, in intense collaboration with the client.

Agile is frequently presented in contrast with the waterfall approach, where product development occurs sequentially, following a predetermined series of stages that are presented to and agreed with the client at the beginning of the process (the arguably more ‘traditional’, and at least formerly most widespread approach to product development).

After reading more about agile vs. waterfall (here’s the leanest and clearest presentation of agile that I could find, and here’s a blog entry with an excellent discussion of the pros and cons of each of the two approaches, both from the perspective of software developers), I’ve realized that the contrast and trade-offs between these two approaches would arise in any case in which a client hires a provider to develop a product designed to address users’ (the client’s customers) needs and constraints — in ways that maximize value. As a neophyte to this distinction, I’m left with a series of questions that I’d like to put up for discussion:

  1. How can clients be persuaded to buy into an agile methodology if they really have no idea what to expect at the end of the process? It’s easier to persuade clients to believe in agile when one has built a reputation of success (like edenspiekermann), but how does one begin?
  2. Permanent collaboration with the client is essential in each of the sprints — edenspiekermann explained that an appointed representative from their clients spent one entire day or more in each two-week sprint at their offices, and that they organized frequent workshops and events to adapt the product to the changes derived from iterative testing. Given that human capital is easily one of the most valuable assets for organizations today, how can one as provider convince a client to “give away” a person from its staff with such frequency?
  3. Do the users involved in testing change in each sprint? Or can the same users test the same product in different sprints? How are the pros and cons of each case?
  4. How does one determine that “one more sprint” isn’t necessary? When is a project deemed completed under agile?
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.