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
