Jeff, can you please lay out these "values" you speak of? The reason I ask is that every agile method I have been acquainted with (and quite a few) have real processes and methods to them, not values. I do realize there are differences among them at a granular level but there are many repeat processes.
1. small iterations 2. don't document Those 2 seem to jump to mind. Almost all have a point where they "consider" users. But then again, I know many design processes that don't do that much. But this is doing design. If you are going to quote Bill, to try to support agile, that is really a leap, don't ya think. Since his talk was fully grounded to talk about "design up front" to the point of getting a green light, considered with collaboration throughout both pre and post-greenlight. Doesn't seem very agile to me? In the end, my problem has always been, one of forced assimilation. Tell me a designer centered agile process and I will rescind what I've been saying. But the values associated with agile all derive from engineering concerns, and in themselves are a protectionist reaction to businesses deep upset with "time to market" (a concept that Alan tried to tell us was flawed). Maybe there is a way to do design centric agile product lifecycles, or better to Jared's point, just holistic agile processes. I have not seen them yet. To be honest, I'm not in a rush. BTW, the end result of both software and hardware is the same. A product. The difference is that one is done with a factory of machines and the other is done with a factory of human beings. A single product is made in either case. I also think that my comment about the fungeability of software has not been addressed. That is to say that software no matter the platform is not really as cheap and quick as we think and this basic flaw is why we need more up front (a whole lot). -- dave On Feb 12, 2008 5:02 PM, Jeff Patton <[EMAIL PROTECTED]> wrote: > All, please excuse the quick message pecked out with my thumbs. > > I'm struggling with the broad generalizations about designers and > agile. Projects and products vary wildly in their goals, users, > number of user goals, and breadth of scope. Teams and companies vary > wildly as well. I'm a proponent of good design and allowing design > thinking to cross into the development process with the ultimate goal > of getting something valuable into the hands of people. > > Agile development isn't a process, it's a value system. That value > system motivates people to construct specific processes - but the > agile manifesto only describes the values. At the ixda conference I > saw a presentation from the dopplr guy. The process he described > himself following any agile person would identify as "agile". He's > working directly with developers, collaborating, and releasing > software regularly. It seems a nice rewarding worklife to strive for. > > Finally, it's difficult to compare the process used to design a > manufactured product like a phone, car, or vacuum cleaner with a > product like software where we make only one. Without knowing much > about the design process of these sorts of products, my guess is they > end with at least one full working product (the prototype) + a > manufacturing process for it. Software just needs to end up with the > full working product. Didn't Alan say everything's a prototype until > it ships? > > Finally, I love Bill's comment on prototype fidelity. "there's only > right and wrong fidelity" the moment you stop learning from paper, > powerpoint, or photoshop, it's time to go to code. Some leap to code > sooner than they should, some designers leap for photoshop when they > should be leaping for a pencil. When all you have is a hammer, > everything looks like a nail. If you're suspicios of hammers, then > when all you have is a hammer, everything looks like a thumb. > > Cool discussion > > Thanks > > Jeff > > > > Sent from my iPhone > > On Feb 12, 2008, at 3:58 PM, "Alan Cooper" <[EMAIL PROTECTED]> wrote: > > > Dave, > > > > You are a very insightful person. > > > > Thanx, > > Alan > > > > __________ > > cooper | Product Design for a Digital World > > Alan Cooper > > [EMAIL PROTECTED] | www.cooper.com > > All information in this message is proprietary & confidential. > > "Kipling was right: leaders and talkers and theorists forget how they > > depend on oily hands and long apprenticeships." -Libby Purves > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > David Malouf > > Sent: Tuesday, February 12, 2008 11:08 AM > > To: IxDA Discuss > > Subject: Re: [IxDA Discuss] Thoughts on Alan Cooper's Keynote > > > > hmmm? > > > > This is actually been shown politically to be the cause of middle east > > conflicts, not the other way around. > > It is b/c we have ignored differentiation among "similar" peoples that > > we > > end up with many many a conflict. > > Acculturation and assimilation, and worse generalization, lead to > > problems > > such as disrespect, devaluation, and erosion. > > > > This is what Bill was alluding to in his little motion graphic bits. > > > > I think the assertion that acknowledging distinctiveness and > > uniqueness > > of > > team members leads to prejudice feels a tad absurd. > > Even if you are on "the same" team. Not all team members own all > > aspects > > of > > the project. There are time contextual roles and responsibilities that > > take > > place fluidly throughout a project and it is through understanding and > > acknowledging these moments or pieces that allows for smoother, more > > appropriate transitions. > > > > This does not in any way counter the other important argument of > > Bill's > > about "not whining". Of course, you have to learn more about your > > other > > team > > members and in so doing you will most likely be creating an > > environment > > where those same team member will want to learn more about you. But > > learning, and melting into are 2 different things. > > > > So I stand by what I said about engineering culture vs. design culture > > and > > how that envalues or devalues agile methods. > > > > Maybe there is a way to integrate true design methods (not research > > methods, > > but design methods) into a software agile methodology, but I haven't > > seen or > > heard of it, nor have I really seen anyone attempt to design such a > > system--one where no single culture dominates the team. > > > > I also think that software agile methods are based on a flawed > > assumption. > > That is to say, it presupposes that software is malleable and > > changeable > > to > > such a degree where "agility" can take place. I don't believe this is > > true > > as much as people would like to think. It was the underlying flaw of > > the > > first bubble, where we thought web=cheaper & faster. We all learned > > that > > wasn't true once you hit a certain level of complexity. To do software > > correctly requires deep strategic and tactical planning with a > > holistic > > and > > deeply forward thinking view. > > > > -- dave > > > > > > > > On Feb 12, 2008 1:37 PM, Christian Crumlish <[EMAIL PROTECTED]> wrote: > > > >> I have to agree with Jared. In fact us vs. them (no matter how > >> informed by experience) treads close to prejudice very easily. One > >> thing I have always loved about this digitally mediated experience > >> space we work in is that it's by its very nature cross-disciplinary. > >> It represents, in fact, a remixing of older guildlike practices. I'm > >> wary of trying to simply redraw the lines as quickly as possible. > >> That's kinda like what the English and French did in the middle east. > >> > >> -xian- > >> > >> > >> On Feb 12, 2008 6:58 AM, Jared M. Spool <[EMAIL PROTECTED]> wrote: > >>> > >>> WHOA! > >>> > >>> Us?!? THEM?!? > >>> > >>> There's a whole lotta us vs. them coming out these days. > >> > >> > >> -- > >> Christian Crumlish http://xianlandia.com > >> Yahoo! pattern detective http://developer.yahoo.com/ypatterns > >> IA Institute director of technology http://iainstitute.org > >> > > > > > > > > -- > > David Malouf > > http://synapticburn.com/ > > http://ixda.org/ > > http://motorola.com/ > > ________________________________________________________________ > > Welcome to the Interaction Design Association (IxDA)! > > To post to this list ....... [EMAIL PROTECTED] > > Unsubscribe ................ http://www.ixda.org/unsubscribe > > List Guidelines ............ http://www.ixda.org/guidelines > > List Help .................. http://www.ixda.org/help > > ________________________________________________________________ > > Welcome to the Interaction Design Association (IxDA)! > > To post to this list ....... [EMAIL PROTECTED] > > Unsubscribe ................ http://www.ixda.org/unsubscribe > > List Guidelines ............ http://www.ixda.org/guidelines > > List Help .................. http://www.ixda.org/help > -- David Malouf http://synapticburn.com/ http://ixda.org/ http://motorola.com/ ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
