Manifestos are beautiful - and I can't argue with these - but it's the practice and process of any methodology carried out by real people that is all that matters. The communist manifesto was a work of literary art. Stalin killed 50 million people. Manifestos don't always lead to good outcomes in reality.
On Feb 13, 2008 5:38 AM, Jeff White <[EMAIL PROTECTED]> wrote: > I realize I'm the wrong Jeff, but here are the values: > > Manifesto for Agile Software Development > > We are uncovering better ways of developing > software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on > the right, we value the items on the left more. > > http://agilemanifesto.org/ > > On Feb 12, 2008 11:34 PM, David Malouf <[EMAIL PROTECTED]> wrote: > > 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 > > > ________________________________________________________________ > 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 > -- ~ will "No matter how beautiful, no matter how cool your interface, it would be better if there were less of it." Alan Cooper - "Where you innovate, how you innovate, and what you innovate are design problems" ------------------------------------------------------- will evans user experience architect [EMAIL PROTECTED] ------------------------------------------------------- ________________________________________________________________ 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
