tag:old.nabble.com,2006:forum-14361Nabble - Agile Development2009-12-05T09:42:39Ztag:old.nabble.com,2006:post-26657626Re: Agile vs. Creativity2009-12-05T09:42:39Z2009-12-05T09:42:39Zmark schraad-2Here is the thing Ron.
<br><br>If you are lucky enough to have an interaction design or information
<br>architect on your staff... (statistically, there is one to every
<br>hundred or two code writers) they are likely educated from one of a
<br>dozen of so schools that specialize in that place between humans and
<br>computers. The masters programs these days are pretty damn sgood. They
<br>have three things going for them... a closeness to how user behave and
<br>expect things to work, an intimacy with the product that few can claim
<br>- at least on the product side(or as I think you call them
<br>"customers'), and a passion for doing great work. You would think this
<br>would provide some respect and regard.
<br><br>In the 30 years that I have been working and consulting with designers
<br>in corporate environment and code shops, I have found it
<br>extraordinarily rare to find designers working in an environment of
<br>respect. They are seen as purely tactical when in fact design is an
<br>incredibly effective tool at the strategic level (need I really trot
<br>out the list of companies that succeed using design as a tactical
<br>advantage?).... but I digress. Unlike a strategy and tactical
<br>implementation of C++, everyone has an opinion about design and the
<br>interactions of software because we all have a singular experience
<br>perspective to draw from. If your domain of expertise was similarly
<br>exposed to pedestrian expertise and institutional disregard, I dare
<br>say you might work in isolation and expose your supreme solution in a
<br>magic show ah ah sort of fashion as well.
<br><br>Or maybe you'd wonder off to some remote spot and reinvent the entire
<br>process and terminology.
<br><br>This is simple human nature... which surely at some point in your
<br>career you can identify with. Is it appropriate of designers to hide
<br>the process and act like spoiled babies when there ideas are
<br>scrutinized and disregarded? Absolutely not. Designers need to
<br>consider the misunderstandings and pseudo expertise that surrounds
<br>them as part of the design constraints. They need to spend much more
<br>time laying the ground work for their premise, providing evidence for
<br>their conclusions and selling the best solution against the provided
<br>criteria. There are lots of designers working on this level, but they
<br>likely have reached a point in their careers where they no longer feel
<br>compelled to tolerate the hostile environments of those who have yet
<br>to embrace their practice and the benefits forthcoming. Or, maybe they
<br>are off somewhere conspiring to drive the entire process.
<br><br>respectfully,
<br><br>Mark
<br><br><br><br><br>On Dec 5, 2009, at 11:07 AM, Ron Jeffries wrote:
<br><br>> Few of us want to be presented with a fait accompli. Yet it seems,
<br>> so often, as if designers want to go off in their holes, design
<br>> something, bring it back and have everyone go "bravo". Yet so often
<br>> it doesn't happen.
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26657349Re: Agile vs. Creativity2009-12-05T09:07:19Z2009-12-05T09:07:19ZRon Jeffries-3Hello, Larry. On Saturday, December 5, 2009, at 10:23:36 AM, you
<br>wrote:
<br><br>> Absolutely brilliant blogtoon-the real life of designers captured. It can get even worse
<br>> working with a large company where every manager gets their fingers into the pie. And when
<br>> it's interaction design as well as graphic design that get diddled with, the results can
<br>> be utter and unmitigated disaster.
<br><br>It is certainly true that everyone has opinions about design, and
<br>not even wrong. It is also the case that some people are better at
<br>it than others.
<br><br>What strikes me now and has for the years this list has been in
<br>existence, is the strange assumption that a designer can give
<br>someone something that they want, need, and will accept, without
<br>effectively communicating with them right along.
<br><br>Few of us want to be presented with a fait accompli. Yet it seems,
<br>so often, as if designers want to go off in their holes, design
<br>something, bring it back and have everyone go "bravo". Yet so often
<br>it doesn't happen.
<br><br>What might this be telling us? One possibility is that the 99.5
<br>percent of us who are not designers are wrong ...
<br><br>Ron Jeffries
<br>www.XProgramming.com
<br>www.xprogramming.com/blog
<br>You don't need to see my identification.
<br>These aren't the ideas you're looking for. Move along.
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26656536RE: Agile vs. Creativity2009-12-05T07:22:40Z2009-12-05T07:22:40ZLarry ConstantineJared wrote:
<br><br>
<br><br>> All this discussion brought this cartoon to mind:
<br><br>> <a href="http://theoatmeal" target="_top" rel="nofollow">http://theoatmeal</a>. <<a href="http://theoatmeal.com/comics/design_hell" target="_top" rel="nofollow">http://theoatmeal.com/comics/design_hell</a>> com/comics/design_hell
<br><br>
<br><br>Absolutely brilliant blogtoon-the real life of designers captured. It can get even worse
<br>working with a large company where every manager gets their fingers into the pie. And when
<br>it's interaction design as well as graphic design that get diddled with, the results can
<br>be utter and unmitigated disaster.
<br><br>--Larry Constantine, IDSA, ACM Fellow
<br> Professor | University of Madeira | Funchal, Portugal
<br> Director | Laboratory for Usage-centered Software Engineering | www.LabUSE.org
<br> Chief Scientist, Constantine & Lockwood Ltd
<br><br> _____
<br><br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26656536&i=0" target="_top" rel="nofollow">agile-usability@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26656536&i=1" target="_top" rel="nofollow">agile-usability@...</a>] On Behalf
<br>Of Jared Spool
<br>Sent: Friday, December 04, 2009 11:30 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26656536&i=2" target="_top" rel="nofollow">agile-usability@...</a>
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br><br>
<br><br>
<br><br>On Dec 4, 2009, at 8:34 PM, Hugh Beyer wrote:
<br><br><br><br><br><br>> > Your comment gives me a vison of the PO sitting down next to the visual
<br>> > designer and saying "move that a little to the left, no, no it's too
<br>> > big, can you punch up that yellow, oh, now it's too bright etc etc, hey
<br>> > just for kicks lets try comic sans as the body copy font, whaddya say?"
<br>> > I don't think this can be what you mean, because no one in their right
<br>> > mind would wish something like this on any team, but that is what your
<br>> > comment suggests to me. (Chris)
<br><br>
<br><br>All this discussion brought this cartoon to mind:
<br><br>
<br><br><a href="http://theoatmeal" target="_top" rel="nofollow">http://theoatmeal</a>. <<a href="http://theoatmeal.com/comics/design_hell" target="_top" rel="nofollow">http://theoatmeal.com/comics/design_hell</a>> com/comics/design_hell
<br><br>
<br><br>Jared
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26655513Re: Agile vs. Creativity2009-12-05T05:09:59Z2009-12-05T05:09:59ZJon KernFrankly (as if I am ever not that), i was stunned by the subject line.
<br><br>Why the heck is there a "versus" in between Agile and Creativity?
<br><br>Would there not be in a subject line like, oh, I don't know: "Waterfall
<br>and Creativity?"
<br><br>Then I started to scroll down to see if I could catch up.
<br><br>I scrolled...
<br><br>I scrolled...
<br><br>I read a good comment by the ever astute Ron Jeffries.
<br><br>I scrolled...
<br><br>Then, I said, heck with it... nothing else could possibly be said about
<br>this subject with so many posts.
<br><br>Then I clicked on the link Jared supplied. *Awesome*!
<br><br>I gave $10 to the Oatmeal's Coffee Fund :-)
<br><br>jon
<br>blog: <a href="http://technicaldebt.wetpaint.com" target="_top" rel="nofollow">http://technicaldebt.wetpaint.com</a><br>twitter: <a href="http://twitter.com/JonKernPA" target="_top" rel="nofollow">http://twitter.com/JonKernPA</a><br><br><br><br>Jared Spool said the following on 12/4/09 11:30 PM:
<div class='shrinkable-quote'><br>>
<br>>
<br>> On Dec 4, 2009, at 8:34 PM, Hugh Beyer wrote:
<br>>
<br>>> > > Your comment gives me a vison of the PO sitting down next to the
<br>>> visual
<br>>> > > designer and saying "move that a little to the left, no, no it's too
<br>>> > > big, can you punch up that yellow, oh, now it's too bright etc
<br>>> etc, hey
<br>>> > > just for kicks lets try comic sans as the body copy font, whaddya
<br>>> say?"
<br>>> > > I don't think this can be what you mean, because no one in their
<br>>> right
<br>>> > > mind would wish something like this on any team, but that is what
<br>>> your
<br>>> > > comment suggests to me. (Chris)
<br>>
<br>> All this discussion brought this cartoon to mind:
<br>>
<br>> <a href="http://theoatmeal.com/comics/design_hell" target="_top" rel="nofollow">http://theoatmeal.com/comics/design_hell</a>
<br>> <<a href="http://theoatmeal.com/comics/design_hell" target="_top" rel="nofollow">http://theoatmeal.com/comics/design_hell</a>>
<br>>
<br>> Jared
<br>>
</div><br><br>------------------------------------
<br><br>Yahoo! Groups Links
<br><br><*> To visit your group on the web, go to:
<br> <a href="http://groups.yahoo.com/group/agile-usability/" target="_top" rel="nofollow">http://groups.yahoo.com/group/agile-usability/</a><br><br><*> Your email settings:
<br> Individual Email | Traditional
<br><br><*> To change settings online go to:
<br> <a href="http://groups.yahoo.com/group/agile-usability/join" target="_top" rel="nofollow">http://groups.yahoo.com/group/agile-usability/join</a><br> (Yahoo! ID required)
<br><br><*> To change settings via email:
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26655513&i=0" target="_top" rel="nofollow">agile-usability-digest@...</a>
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26655513&i=1" target="_top" rel="nofollow">agile-usability-fullfeatured@...</a>
<br><br><*> To unsubscribe from this group, send an email to:
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26655513&i=2" target="_top" rel="nofollow">agile-usability-unsubscribe@...</a>
<br><br><*> Your use of Yahoo! Groups is subject to:
<br> <a href="http://docs.yahoo.com/info/terms/" target="_top" rel="nofollow">http://docs.yahoo.com/info/terms/</a><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26652930Re: Agile vs. Creativity2009-12-04T20:30:00Z2009-12-04T20:30:00ZJared Spool<br>On Dec 4, 2009, at 8:34 PM, Hugh Beyer wrote:
<br><div class='shrinkable-quote'><br>> > > Your comment gives me a vison of the PO sitting down next to the
<br>> visual
<br>> > > designer and saying "move that a little to the left, no, no it's
<br>> too
<br>> > > big, can you punch up that yellow, oh, now it's too bright etc
<br>> etc, hey
<br>> > > just for kicks lets try comic sans as the body copy font,
<br>> whaddya say?"
<br>> > > I don't think this can be what you mean, because no one in their
<br>> right
<br>> > > mind would wish something like this on any team, but that is
<br>> what your
<br>> > > comment suggests to me. (Chris)
</div><br>All this discussion brought this cartoon to mind:
<br><br><a href="http://theoatmeal.com/comics/design_hell" target="_top" rel="nofollow">http://theoatmeal.com/comics/design_hell</a><br><br>Jared<p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26652381Re: Agile vs. Creativity2009-12-04T18:22:23Z2009-12-04T18:22:23Zmark schraad-2What Chris is describing is not a partnership at all. It is one person
<br>treating the other as their wrist. This might be something a business
<br>owner or product manager might be willing to do (because they
<br>typically know everything) but not something even a descent art
<br>director would do to a designer. It pure and simple micro management
<br>and throwing any qualifications the individual might have right out
<br>the window.
<br><br>And by the way... there is no such thing as graphics design... it is
<br>called graphic design.
<br><br><br>On Dec 4, 2009, at 7:34 PM, Hugh Beyer wrote:
<br><div class='shrinkable-quote'><br>> <image001.gif>
<br>>
<br>> Coming very late to the party, I think there’s some danger of
<br>> assuming that what works well for code will work as well for other
<br>> disciplines. This:
<br>>
<br>>
<br>>
<br>> > > Your comment gives me a vison of the PO sitting down next to the
<br>> visual
<br>> > > designer and saying "move that a little to the left, no, no it's
<br>> too
<br>> > > big, can you punch up that yellow, oh, now it's too bright etc
<br>> etc, hey
<br>> > > just for kicks lets try comic sans as the body copy font,
<br>> whaddya say?"
<br>> > > I don't think this can be what you mean, because no one in their
<br>> right
<br>> > > mind would wish something like this on any team, but that is
<br>> what your
<br>> > > comment suggests to me. (Chris)
<br>> >
<br>> > Interesting! You just suggested that I'm not in my right mind.
<br>> (George)
<br>>
<br>> Sounds like pair programming applied to graphic design. Yet code is
<br>> invisible except in its effects; it must be right or it produces
<br>> unacceptable behavior; and it’s hard to be sure that you’ve
<br>> triggered all such behavior in your testing. The graphics of a UI
<br>> are completely visible, have no side effects, and all behavior is
<br>> consistent and transparent. The only unexpected behavior possible is
<br>> that of the end user responding to the UI, and you can’t get a cross
<br>> check on that from the Product Owner. So it’s entirely unclear why
<br>> this should be an effective technique for graphics design.
<br>>
<br>>
<br>>
<br>> As we integrate other disciplines into Agile development, I think we
<br>> need to be careful of the unique characteristics of those disciplines.
<br>>
<br>>
<br>>
<br>> Hugh
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> Hugh R. Beyer, CTO
<br>> InContext
<br>> Ph: 603 966-7188
<br>> Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652381&i=0" target="_top" rel="nofollow">beyer@...</a>
<br>>
<br>>
<br>>
<br>>
<br>>
</div><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26652093Re: Agile vs. Creativity2009-12-04T17:34:40Z2009-12-04T17:34:40Zhughrbeyer<br>Coming very late to the party, I think there's some danger of assuming that what works well for code will work as well for other disciplines. This:
<br><br>> > Your comment gives me a vison of the PO sitting down next to the visual
<br>> > designer and saying "move that a little to the left, no, no it's too
<br>> > big, can you punch up that yellow, oh, now it's too bright etc etc, hey
<br>> > just for kicks lets try comic sans as the body copy font, whaddya say?"
<br>> > I don't think this can be what you mean, because no one in their right
<br>> > mind would wish something like this on any team, but that is what your
<br>> > comment suggests to me. (Chris)
<br>>
<br>> Interesting! You just suggested that I'm not in my right mind. (George)
<br><br>Sounds like pair programming applied to graphic design. Yet code is invisible except in its effects; it must be right or it produces unacceptable behavior; and it's hard to be sure that you've triggered all such behavior in your testing. The graphics of a UI are completely visible, have no side effects, and all behavior is consistent and transparent. The only unexpected behavior possible is that of the end user responding to the UI, and you can't get a cross check on that from the Product Owner. So it's entirely unclear why this should be an effective technique for graphics design.
<br><br>As we integrate other disciplines into Agile development, I think we need to be careful of the unique characteristics of those disciplines.
<br><br>Hugh
<br><br><br>Hugh R. Beyer, CTO
<br>InContext
<br>Ph: 603 966-7188
<br>Email: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26652093&i=0" target="_top" rel="nofollow">beyer@...</a>
<br><br><br> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>image001.gif</strong> (128 bytes) <a href="http://old.nabble.com/attachment/26652093/0/image001.gif" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26531993Re: Agile and Academia2009-11-26T05:23:33Z2009-11-26T05:23:33Zrasmus4200Hi Anders,
<br><br>Very interesting article. I agree with the premise of what you are saying but I would add it goes even much deeper than that.
<br><br>Our institutions have been separating roles and responsibilities for many many years. BA, QA, developer, PM, UX etc has been the traditional way projects have been developed for decades.
<br><br>And every time we form agile teams in large organizations we come up against that baked in calcification of roles and responsiblities (I am responsible for these, they do that).
<br><br>The evidence comment is interesting because it very hard to prove anything when it comes to productivity and software. All we have is anecdotal evidence. My experience against yours. And I actually kind of find it refreshing for someone to say waterfall has worked for them because in my experience is completely the opposite, and this is the first person I have heard in a long time say they like waterfall.
<br><br>But I agree with your original assertion, and I am encourage that institutions like Carnegie Mellon are working towards more cross functional disciplines.
<br><br>Thanks for sharing. That was a great post.
<br><br>Cheers - Jonathan
<br><br>--- In <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26531993&i=0" target="_top" rel="nofollow">agile-usability@...</a>, Anders Ramsay <andersr@...> wrote:
<div class='shrinkable-quote'><br>>
<br>> Hi,
<br>>
<br>> I recently posted a blog entry on why I think one key source for much
<br>> of the Us/Them mentality between UX designers and agile software
<br>> developers (at least what I have experienced) can be traced back to
<br>> how we are separated during our formative years in educational
<br>> institutions, with those studying computer science not having much
<br>> contact with those studying graphic design, or more recently
<br>> interaction design. Many of them have never actually worked with
<br>> those from the other discipline until after graduating and find
<br>> themselves thrown into project teams with people who may be looking at
<br>> the craft of software development from a completely different
<br>> perspective. The full post is at <a href="http://is.gd/516fE" target="_top" rel="nofollow">http://is.gd/516fE</a><br>>
<br>> Is this an accurate assessment? Am I making too much out of this
<br>> separation? Are there educational institutions that have take steps to
<br>> better integrate the various disciplines the eventually will need to
<br>> collaborate in the workplace?
<br>>
<br>> I also received an interesting comment to my posting, and would love
<br>> to hear what people on this list have to say about the following:
<br>>
<br>> [In response to me proposing is that educational programs incorporate
<br>> pairing across disciplines.]
<br>> Commenter: "Your whole article assumes a truism that I'm not sure has
<br>> been proven, especially at the academic level, which is that pairing
<br>> is more efficient (same or cross-disciplinary)."
<br>>
<br>> Commenter: "In my experience a solid waterfall approach has been
<br>> infinitely more successful cross-disciplinarily than any type of good
<br>> or bad Agile I have worked with (and I've been forced to work with
<br>> many). Statistically or through any other empirical measure (and I
<br>> don't have anything but anecdotal evidence myself) no one has PROVEN
<br>> that Agile is better than non-agile."
<br>>
<br>> -Anders
<br>>
</div><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26502908Re: Re: Agile in digital agencies2009-11-24T11:04:19Z2009-11-24T11:04:19ZflaviogruposHello Kevin!
<br><br>How was your experience? Did you delivered full sections (wireframes,
<br>layouts, front-end and back-end) each iteration?
<br><br>Thanks!
<br>_____________________
<br>Flavio Steffens de Castro
<br><a href="http://www.agileway.com.br" target="_top" rel="nofollow">http://www.agileway.com.br</a><br>A filosofia agile no dia-a-dia
<br><br><br>On Tue, Nov 24, 2009 at 6:58 AM, Kevin Rapley <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26502908&i=0" target="_top" rel="nofollow">kevin.rapley@...</a>
<br>> wrote:
<br><div class='shrinkable-quote'><br>>
<br>>
<br>> Hi Flavio,
<br>> Yes, we are using SCRUM and Agile for creating websites and
<br>> applications. I am yet to experience an Agile run project myself but
<br>> will be brought on to a project very soon. This is why I have joined
<br>> the Agile Usability Group to learn from others and share experiences
<br>> too. I will be watching this thread closely and will divulge any
<br>> insights as and when the time occurs.
<br>>
<br>> Regards
<br>>
<br>> --
<br>> Kevin Rapley - User Experience Designer
<br>> TechnoPhobia Limited
<br>> The Workstation
<br>> 15 Paternoster Row
<br>> SHEFFIELD
<br>> England
<br>> S1 2BX
<br>> t: +44 (0)114 2212123
<br>> f: +44 (0)114 2212124
<br>> e: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26502908&i=1" target="_top" rel="nofollow">Kevin.rapley@...</a> <Kevin.rapley%40technophobia.com>
<br>> w: <a href="http://www.technophobia.com" target="_top" rel="nofollow">http://www.technophobia.com</a><br>>
<br>> Registered in England and Wales Company No. 3063669
<br>> VAT registration No. 598 7858 42
<br>> ISO 9001:2000 Accredited Company No. 21227
<br>> ISO 14001:2004 Accredited Company No. E997
<br>> ISO 27001:2005 (BS7799) Accredited Company No. IS 508906
<br>> Investor in People Certified No. 101507
<br>>
<br>> The contents of this email are confidential to the addressee
<br>> and are intended solely for the recipients use. If you are not
<br>> the addressee, you have received this email in error.
<br>> Any disclosure, copying, distribution or action taken in
<br>> reliance on it is prohibited and may be unlawful.
<br>>
<br>> Any opinions expressed in this email are those of the author
<br>> personally and not TechnoPhobia Limited who do not accept
<br>> responsibility for the contents of the message.
<br>>
<br>> All email communications, in and out of TechnoPhobia,
<br>> are recorded for monitoring purposes.
<br>>
<br>>
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26495688Re: Agile in digital agencies2009-11-24T00:58:38Z2009-11-24T00:58:38ZKevin RapleyHi Flavio,
<br>Yes, we are using SCRUM and Agile for creating websites and
<br>applications. I am yet to experience an Agile run project myself but
<br>will be brought on to a project very soon. This is why I have joined
<br>the Agile Usability Group to learn from others and share experiences
<br>too. I will be watching this thread closely and will divulge any
<br>insights as and when the time occurs.
<br><br>Regards
<br><br>--
<br>Kevin Rapley - User Experience Designer
<br>TechnoPhobia Limited
<br>The Workstation
<br>15 Paternoster Row
<br>SHEFFIELD
<br>England
<br>S1 2BX
<br>t: +44 (0)114 2212123
<br>f: +44 (0)114 2212124
<br>e: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26495688&i=0" target="_top" rel="nofollow">Kevin.rapley@...</a>
<br>w: <a href="http://www.technophobia.com" target="_top" rel="nofollow">http://www.technophobia.com</a><br><br>Registered in England and Wales Company No. 3063669
<br>VAT registration No. 598 7858 42
<br>ISO 9001:2000 Accredited Company No. 21227
<br>ISO 14001:2004 Accredited Company No. E997
<br>ISO 27001:2005 (BS7799) Accredited Company No. IS 508906
<br>Investor in People Certified No. 101507
<br><br>The contents of this email are confidential to the addressee
<br>and are intended solely for the recipients use. If you are not
<br>the addressee, you have received this email in error.
<br>Any disclosure, copying, distribution or action taken in
<br>reliance on it is prohibited and may be unlawful.
<br><br>Any opinions expressed in this email are those of the author
<br>personally and not TechnoPhobia Limited who do not accept
<br>responsibility for the contents of the message.
<br><br>All email communications, in and out of TechnoPhobia,
<br>are recorded for monitoring purposes.
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26491509Agile in digital agencies2009-11-23T14:15:55Z2009-11-23T14:15:55ZflaviogruposHello people,
<br><br>is there anyone here that already use scrum/xp/lean/agile in digital
<br>agencies? Like creating websites, online marketing, etc.
<br><br>I will like to share experiences. :)
<br><br>Regards
<br>_____________________
<br>Flavio Steffens de Castro
<br><a href="http://www.agileway.com.br" target="_top" rel="nofollow">http://www.agileway.com.br</a><br>A filosofia agile no dia-a-dia
<br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26484630Design Values: Validated Data over Expert Opinion2009-11-23T11:42:47Z2009-11-23T11:42:47ZLynn Miller-2I've written a post for my company's external design blog, that might be of interest to this list. It's a follow-up to John Schrag's post on "Values in Software Design Practice" which was discussed on this forum earlier.
<br><br>The original post described the values my team believes contribute to a healthy software design practice. This post looks deeper into why we value "Quality of Data" over "Ease of Data Collection".
<br><br>The full post is here: <a href="http://dux.typepad.com" target="_top" rel="nofollow">http://dux.typepad.com</a>
<br>Feel free to comment.
<br><br>Lynn Miller
<br>Autodesk
<br><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26478354Re: Agile and Academia2009-11-23T05:45:48Z2009-11-23T05:45:48ZAnders RamsayWilliam, Vince, and Larry - thanks all for your great feedback. I love this
<br>list!
<br><br>-Anders
<br><br>On Sun, Nov 22, 2009 at 10:18 PM, Larry Constantine <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26478354&i=0" target="_top" rel="nofollow">lconstantine@...</a>
<br>> wrote:
<br><div class='shrinkable-quote'><br>>
<br>>
<br>> Anders,
<br>>
<br>> I hope I'm not getting too repetitive on this forum, but the Carnegie
<br>> Mellon University
<br>> Master in Human-Computer Interaction and the dual-degree MHCI run jointly
<br>> between the
<br>> University of Madeira and Carnegie Mellon (<a href="http://www.labuse.org/mhci/" target="_top" rel="nofollow">http://www.labuse.org/mhci/</a>)
<br>> are both
<br>> completely organized around cross-disciplinary teamwork. By the time our
<br>> students graduate
<br>> they have extensive experience in teams that involve at least one person
<br>> from
<br>> graphics/design, one from the social sciences, and one or more from
<br>> software
<br>> engineering/computer science. That experience includes a 9-month project in
<br>> business and
<br>> industry producing real results. The newly formed Madeira Interactive
<br>> Technologies
<br>> Institute is also centered on interdisciplinary perspectives and
<br>> collaboration.
<br>>
<br>> So, the future may be brighter for some graduates.
<br>>
<br>> --Larry Constantine, IDSA, ACM Fellow
<br>> Professor | University of Madeira | Funchal, Portugal
<br>> Director | Laboratory for Usage-centered Software Engineering |
<br>> www.LabUSE.org
<br>> Chief Scientist, Constantine & Lockwood Ltd
<br>>
<br>>
<br>>
<br></div><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26472235RE: Agile and Academia2009-11-22T19:17:55Z2009-11-22T19:17:55ZLarry ConstantineAnders,
<br><br>I hope I'm not getting too repetitive on this forum, but the Carnegie Mellon University
<br>Master in Human-Computer Interaction and the dual-degree MHCI run jointly between the
<br>University of Madeira and Carnegie Mellon (<a href="http://www.labuse.org/mhci/" target="_top" rel="nofollow">http://www.labuse.org/mhci/</a>) are both
<br>completely organized around cross-disciplinary teamwork. By the time our students graduate
<br>they have extensive experience in teams that involve at least one person from
<br>graphics/design, one from the social sciences, and one or more from software
<br>engineering/computer science. That experience includes a 9-month project in business and
<br>industry producing real results. The newly formed Madeira Interactive Technologies
<br>Institute is also centered on interdisciplinary perspectives and collaboration.
<br><br>So, the future may be brighter for some graduates.
<br><br>--Larry Constantine, IDSA, ACM Fellow
<br> Professor | University of Madeira | Funchal, Portugal
<br> Director | Laboratory for Usage-centered Software Engineering | www.LabUSE.org
<br> Chief Scientist, Constantine & Lockwood Ltd
<br><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26471164Re: Agile and Academia2009-11-22T16:37:41Z2009-11-22T16:37:41ZvasonsonHi Anders -
<br><br>Check out the Human Computer Interaction program at Iowa State University:
<br><a href="http://www.hci.iastate.edu/" target="_top" rel="nofollow">http://www.hci.iastate.edu/</a>
<br><br>It is a fantastic interdisciplinary program that develops in its students the breadth of perspective you suggest.
<br><br>Best,
<br>Vince
<br><br>--- On Sun, 11/22/09, Anders Ramsay <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471164&i=0" target="_top" rel="nofollow">andersr@...</a>> wrote:
<br><br>From: Anders Ramsay <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471164&i=1" target="_top" rel="nofollow">andersr@...</a>>
<br>Subject: [agile-usability] Agile and Academia
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26471164&i=2" target="_top" rel="nofollow">agile-usability@...</a>
<br>Date: Sunday, November 22, 2009, 3:50 PM
<br><br>Hi,
<br><br>I recently posted a blog entry on why I think one key source for much
<br>of the Us/Them mentality between UX designers and agile software
<br>developers (at least what I have experienced) can be traced back to
<br>how we are separated during our formative years in educational
<br>institutions, with those studying computer science not having much
<br>contact with those studying graphic design, or more recently
<br>interaction design. Many of them have never actually worked with
<br>those from the other discipline until after graduating and find
<br>themselves thrown into project teams with people who may be looking at
<br>the craft of software development from a completely different
<br>perspective. The full post is at <a href="http://is.gd/516fE" target="_top" rel="nofollow">http://is.gd/516fE</a><br><br>Is this an accurate assessment? Am I making too much out of this
<br>separation? Are there educational institutions that have take steps to
<br>better integrate the various disciplines the eventually will need to
<br>collaborate in the workplace?
<br><br>I also received an interesting comment to my posting, and would love
<br>to hear what people on this list have to say about the following:
<br><br>[In response to me proposing is that educational programs incorporate
<br>pairing across disciplines.]
<br>Commenter: "Your whole article assumes a truism that I’m not sure has
<br>been proven, especially at the academic level, which is that pairing
<br>is more efficient (same or cross-disciplinary)."
<br><br>Commenter: "In my experience a solid waterfall approach has been
<br>infinitely more successful cross-disciplinarily than any type of good
<br>or bad Agile I have worked with (and I’ve been forced to work with
<br>many). Statistically or through any other empirical measure (and I
<br>don’t have anything but anecdotal evidence myself) no one has PROVEN
<br>that Agile is better than non-agile."
<br><br>-Anders
<br><br><br>------------------------------------
<br><br>Yahoo! Groups Links
<br><br><br><br><br><br><br> <p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26470386Re: Agile and Academia2009-11-22T14:43:20Z2009-11-22T14:43:20ZWilliam PietriHi, Anders! Interesting!
<br><br>Anders Ramsay wrote:
<br>> I also received an interesting comment to my posting, and would love
<br>> to hear what people on this list have to say about the following:
<br>>
<br>> [In response to me proposing is that educational programs incorporate
<br>> pairing across disciplines.]
<br>> Commenter: "Your whole article assumes a truism that I’m not sure has
<br>> been proven, especially at the academic level, which is that pairing
<br>> is more efficient (same or cross-disciplinary)."
<br>>
<br><br>I would be a little surprised that nobody has academically proven the
<br>value of people with different skill sets closely collaborating to
<br>achieve a shared goal, which is all that cross-disciplinary pairing is.
<br>I'd start looking in Surowiecki's bibliography, but for me it's in the
<br>"duh" category.
<br><br>It's true that nobody has fully proven the value of pair programming,
<br>although they have managed to get evidence that undermines the common
<br>negative reaction that work would take twice as much time, and they have
<br>demonstrated short-term quality improvements, too.
<br><br>But I think the real benefits come from long-term sustainability through
<br>deep shared understanding, and you're never going to prove anything
<br>either way on the dozen-freshmen-for-a-semester studies that I've seen.
<br>If somebody would like to fund proper studies on pairing, please let me
<br>know. I'm sure I could do it for less than bringing a single drug to
<br>market. :-)
<br><br>> Commenter: "In my experience a solid waterfall approach has been
<br>> infinitely more successful cross-disciplinarily than any type of good
<br>> or bad Agile I have worked with (and I’ve been forced to work with
<br>> many). Statistically or through any other empirical measure (and I
<br>> don’t have anything but anecdotal evidence myself) no one has PROVEN
<br>> that Agile is better than non-agile."
<br>>
<br><br>Nobody will ever prove it as some sort of universal. First: there is no
<br>Agile method. Saying you're "doing Agile" is like saying you're from
<br>North America. It may be true, but it's not very informative. Second:
<br>teams, projects, companies, and workloads vary too much. Third: like
<br>Lean Manufacturing, mastering an Agile approach requires pervasive
<br>change in culture and philosophy as well as project behaviors. Agile vs
<br>non-Agile is too simple a question to study. And so on.
<br><br>But equally, nobody has ever "PROVEN", in the academic sense, that any
<br>development process is "better". We're not doing science here, and -- as
<br>often happens in this debate -- holding one just option to a
<br>double-blind standard of proof is faintly ridiculous.
<br><br>However, if you are the sort of person who values the scientific method,
<br>then I'd suggest Agile approach fits better with that. All the good
<br>Agile teams I know are continually experimenting with their process,
<br>their product, their tools, and their techniques. Short-cycle iterative
<br>processes let you do that in ways that are impossible in waterfall-like
<br>processes.
<br><br><br>Turning to that commenter's broader point, that their experience leads
<br>them another way: ok, fine. Their experience doesn't match my
<br>experience, and I have theoretical reasons why I think their implied
<br>conclusion is bunk, but I'm not the boss of them, so they should do what
<br>they think best.
<br><br>If they can find somewhere to work that way, that is. Classic waterfall,
<br>with it's necessarily higher capital costs and risk profiles, is an
<br>endangered species here in the Silicon Valley region. Barring perhaps a
<br>few old-growth companies, I expect it will be extinct here for software
<br>in another 10-15 years.
<br><br>William
<br><br><br>------------------------------------
<br><br>Yahoo! Groups Links
<br><br><*> To visit your group on the web, go to:
<br> <a href="http://groups.yahoo.com/group/agile-usability/" target="_top" rel="nofollow">http://groups.yahoo.com/group/agile-usability/</a><br><br><*> Your email settings:
<br> Individual Email | Traditional
<br><br><*> To change settings online go to:
<br> <a href="http://groups.yahoo.com/group/agile-usability/join" target="_top" rel="nofollow">http://groups.yahoo.com/group/agile-usability/join</a><br> (Yahoo! ID required)
<br><br><*> To change settings via email:
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470386&i=0" target="_top" rel="nofollow">agile-usability-digest@...</a>
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470386&i=1" target="_top" rel="nofollow">agile-usability-fullfeatured@...</a>
<br><br><*> To unsubscribe from this group, send an email to:
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26470386&i=2" target="_top" rel="nofollow">agile-usability-unsubscribe@...</a>
<br><br><*> Your use of Yahoo! Groups is subject to:
<br> <a href="http://docs.yahoo.com/info/terms/" target="_top" rel="nofollow">http://docs.yahoo.com/info/terms/</a><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26469327Agile and Academia2009-11-22T12:50:03Z2009-11-22T12:50:03ZAnders RamsayHi,
<br><br>I recently posted a blog entry on why I think one key source for much
<br>of the Us/Them mentality between UX designers and agile software
<br>developers (at least what I have experienced) can be traced back to
<br>how we are separated during our formative years in educational
<br>institutions, with those studying computer science not having much
<br>contact with those studying graphic design, or more recently
<br>interaction design. Many of them have never actually worked with
<br>those from the other discipline until after graduating and find
<br>themselves thrown into project teams with people who may be looking at
<br>the craft of software development from a completely different
<br>perspective. The full post is at <a href="http://is.gd/516fE" target="_top" rel="nofollow">http://is.gd/516fE</a><br><br>Is this an accurate assessment? Am I making too much out of this
<br>separation? Are there educational institutions that have take steps to
<br>better integrate the various disciplines the eventually will need to
<br>collaborate in the workplace?
<br><br>I also received an interesting comment to my posting, and would love
<br>to hear what people on this list have to say about the following:
<br><br>[In response to me proposing is that educational programs incorporate
<br>pairing across disciplines.]
<br>Commenter: "Your whole article assumes a truism that I’m not sure has
<br>been proven, especially at the academic level, which is that pairing
<br>is more efficient (same or cross-disciplinary)."
<br><br>Commenter: "In my experience a solid waterfall approach has been
<br>infinitely more successful cross-disciplinarily than any type of good
<br>or bad Agile I have worked with (and I’ve been forced to work with
<br>many). Statistically or through any other empirical measure (and I
<br>don’t have anything but anecdotal evidence myself) no one has PROVEN
<br>that Agile is better than non-agile."
<br><br>-Anders
<br><br><br>------------------------------------
<br><br>Yahoo! Groups Links
<br><br><*> To visit your group on the web, go to:
<br> <a href="http://groups.yahoo.com/group/agile-usability/" target="_top" rel="nofollow">http://groups.yahoo.com/group/agile-usability/</a><br><br><*> Your email settings:
<br> Individual Email | Traditional
<br><br><*> To change settings online go to:
<br> <a href="http://groups.yahoo.com/group/agile-usability/join" target="_top" rel="nofollow">http://groups.yahoo.com/group/agile-usability/join</a><br> (Yahoo! ID required)
<br><br><*> To change settings via email:
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26469327&i=0" target="_top" rel="nofollow">agile-usability-digest@...</a>
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26469327&i=1" target="_top" rel="nofollow">agile-usability-fullfeatured@...</a>
<br><br><*> To unsubscribe from this group, send an email to:
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26469327&i=2" target="_top" rel="nofollow">agile-usability-unsubscribe@...</a>
<br><br><*> Your use of Yahoo! Groups is subject to:
<br> <a href="http://docs.yahoo.com/info/terms/" target="_top" rel="nofollow">http://docs.yahoo.com/info/terms/</a><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26420608Re: Agile vs. Creativity2009-11-18T21:25:42Z2009-11-18T21:25:42ZWilliam PietriScott Preece wrote:
<br>>
<br>> My understanding was that the normal model was that the PO prioritizes
<br>> stories, engages in conversations as needed, and provides feedback on
<br>> iteration deliveries, but doesn't get involved in the "inside" of the
<br>> work.
<br><br>The model I teach involves as much engagement as possible. That includes
<br>enough feedback during construction that any sort of end-of-iteration
<br>feedback is a formality. If a pair of developers regularly goes more
<br>than a few hours without showing something to a product manager, I
<br>normally consider that a bad sign.
<br><br>As to visual design, some of my clients pair designers and developers
<br>together for extended periods as the visual aspects of a given feature
<br>are hammered out. If the product managers had detailed opinions on
<br>visual design, I'm sure they'd participate at that stage, but generally,
<br>they don't. They leave visual design to the local experts in that. They
<br>buy in at an earlier stage, where they see interface sketches and style
<br>samples. Even there, though, I don't see much back-seat designing.
<br><br>William
<br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26424028RE: New to Agile Usability2009-11-18T15:07:27Z2009-11-18T15:07:27ZMouneerThe start could be with roles listings:
<br><br>"Usability expert"
<br><br>UX designer
<br><br>UI developer
<br><br>Interactive designer
<br><br>
<br><br>In Agile teams general specialists are becoming the norm and they are the
<br>champions; in our talk here they are the UX/UI/Interactive
<br>designer/developer; someone who has the skill to work understand the tell
<br>the story with the product owner/customer using low-fidelity medium and
<br>gradually work their way thru in a "UX design studio".
<br><br>For an agile team, specialization in the UX/UI/Usability domain did not
<br>really help. What I see working is a UX person with knowledge and experience
<br>on usability heuristics and standards, usability low-fi tools, information
<br>structure, and user-centric experience; this person is capable of telling
<br>the story based o persona/user role needs, verifying the quick low-cost
<br>design models (example www.balsamiq.com) , designing the general theme and
<br>look & feel, iteratively adding higher fidelity designs by feature (or
<br>story, or MMF) , implementing UI elements in different technologies (JS,
<br>JQuery, Flash, Sliverlight etc..), working closely with developers,
<br>processing feedback and usability test results, and analyzing the
<br>post-release usability stats.
<br><br>
<br><br>A specialist usability person sounds like a software architect who no longer
<br>code; nevertheless, this specialization may be useful in places that
<br>provides usability assessment as a service on its own. But in an agile
<br>software development, a UX Knight is a key role for success.
<br><br>
<br><br>I completely support cross functional teams yet I see "meta teams" of
<br>developers, another of UX persons, and another of product owners as a great
<br>venue for knowledge sharing and continuous improvement on the organizational
<br>level.
<br><br>
<br><br>Hope this answers part of the questions.
<br><br>
<br><br>Thanks,
<br><br>Mouneer
<br><br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26424028&i=0" target="_top" rel="nofollow">agile-usability@...</a>
<br>[mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26424028&i=1" target="_top" rel="nofollow">agile-usability@...</a>] On Behalf Of Elmohanned Ahmed
<br>Sent: Tuesday, November 10, 2009 10:49 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26424028&i=2" target="_top" rel="nofollow">agile-usability@...</a>
<br>Subject: [agile-usability] New to Agile Usability
<br><br>
<br><br>
<br><br>Hi All,
<br><br>We are an organization that started the move to agile about a year ago. Our
<br>usability team is quiet perplexed. We basically work in intranet web
<br>applications. Can anybody update on the typical role of a usability guy in a
<br>project? What does he do? When? Any details are welcome.
<br><br>
<br><br>Thanks,
<br><br>ElMohanned
<br><br>
<br><br>Inspection to prevent defects is absolutely required for any process.
<br>Inspection to find defects is waste.
<br><br>Shigeo Shingo, Study of Toyota Production system
<br><br>
<br><br>
<br><br>Disclaimer: NOTICE The information contained in this message is confidential
<br>and is intended for the addressee(s) only. If you have received this message
<br>in error or there are any problems please notify the originator immediately.
<br>The unauthorized use, disclosure, copying or alteration of this message is
<br>strictly forbidden. Raya will not be liable for direct, special, indirect or
<br>consequential damages arising from alteration of the contents of this
<br>message by a third party or as a result of any malicious code or virus being
<br>passed on. Views expressed in this communication are not necessarily those
<br>of Raya.If you have received this message in error, please notify the sender
<br>immediately by email, facsimile or telephone and return and/or destroy the
<br>original message.
<br><br><br><br><br>
<br> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>image001.jpg</strong> (494 bytes) <a href="http://old.nabble.com/attachment/26424028/0/image001.jpg" target="_top">Download Attachment</a><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>image002.jpg</strong> (456 bytes) <a href="http://old.nabble.com/attachment/26424028/1/image002.jpg" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26411610Re: Agile UX SIG London: pub meetup2009-11-18T09:03:24Z2009-11-18T09:03:24ZAdrian Howard<br>On 13 Nov 2009, at 22:42, joko_1.rm wrote:
<br><div class='shrinkable-quote'><br>> Hello folks in London, Brighton, and on the rest of the island!
<br>>
<br>> I have discussed the idea of an agile UX SIG with several people (Una Walsh, Adrian Howard, Stuart Cruickshank, just to name a few). We all agreed that we would like to make it happen! Aim is to bring people together who are interested in agile & user experience - ux people, designers, developers, scrum masters, product owners, project managers, etc.
<br>>
<br>> The first event will be an informal pub meetup, to see who is interested and to discuss ideas for the future (such as a conference-style agile ux event, an agile retreat, or workshops).
<br>>
<br>> We haven't decided on a location yet, but will probably go for a venue near london bridge (convenient for trains). Any suggestions highly welcome! Of course, if you feel like offering to sponsor this event (e.g. by hosting it), get in touch.
<br>>
<br>> Please register here: <a href="http://agileuxsig.eventbrite.com/" target="_top" rel="nofollow">http://agileuxsig.eventbrite.com/</a><br>>
<br>> And please do spread the word - the more diversity, the better.
</div><br>A rather belated "bloody good idea".
<br><br>I'm going. Hope to see others from this list there too :-)
<br><br>Cheers,
<br><br>Adrian
<br>--
<br><a href="http://quietstars.com" target="_top" rel="nofollow">http://quietstars.com</a> - twitter.com/adrianh - delicious.com/adrianh
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26411792Re: Agile UX and Digital Marketing2009-11-18T08:49:31Z2009-11-18T08:49:31ZflaviogruposHello,
<br><br>I think that we can adapt most of the practices of Agile (XP, Scrum, TDD, etc.)
<br><br>The creative area (as IA, Design, Usability) are much cognitive than a software. In my opinion, that happens because when we build a software we constantly focus on FUNCTIONALITY. When we think about Agencies/MKT/Websites the focus is on DESIGN/CREATIVITY.
<br><br>Also, we have a team that have different skills (designers, architects, programmers, flashers...) and doing a "pair programming" with a designer and a programmer sounds goofy :)
<br><br>But I think that we can adapt the Scrum process, for example. The Kanban/Taskboard is usable in 99,9% of the cases, I believe. The iteration process could work fine, also.
<br><br>Imagine that your first sprint is to deliver a design of the HOME website. So, you will have IA and designers working a lot, and programmers working less. But, the programmers are very important here, because they will give insights and also will start thinking about the funcions of the website.
<br><br>Who dont have the problem where all the IA and design are approved, but when the programming start, they found a lot of problems there?
<br><br>The "cross-function" teams are great, but that dont means that they need to pair programming all the time. But track all the project from the beginning to the end.
<br><br>Well, what do you think? Sounds a little crazy yet, or helped? :)
<br><br>Thanks
<br>Flavio
<br>www.agileway.com.br
<br><br>I think that we could adapt, for example, the SCRUM process.
<br><br>--- In <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26411792&i=0" target="_top" rel="nofollow">agile-usability@...</a>, chris chandler <chris.chandler@...> wrote:
<div class='shrinkable-quote'><br>>
<br>> Good question Christine, I've been wondering about this myself for a long
<br>> time. A lot of valuable discussion on this list has been about how to
<br>> join/marry User Centered Design or UX, with Agile methods, but very little
<br>> time has been spent discussing the actual visual appeal of a consumer facing
<br>> web site or application.
<br>>
<br>> On the UX side (and by this I mean Information Architecture, Interaction
<br>> Design and Usability) there seems to be a consistent discussion about the
<br>> need for what Larry Constantine recently described of a "coherent UI
<br>> architecture, worked out in advance."
<br>>
<br>> Are there any major, or at least successful creative agencies that have
<br>> adopted "Agile Creative" as an approach? I'd love to hear about them...
<br>>
<br>> -cc
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> On Tue, Nov 10, 2009 at 3:04 PM, Christine <christinemvelez@...>wrote:
<br>>
<br>> >
<br>> >
<br>> > A lot of posts I come across seems to limit the discussion of agile UX to
<br>> > the development of software. Or the good experiences I read about are with
<br>> > software development projects. I worked at a digital marketing agency and
<br>> > have found that, so far, the agile process hasn't allowed us to build our
<br>> > best work. That is, work that is a good user experience, well developed, and
<br>> > thoughtfully creative. However, we rarely used the agile process, so I
<br>> > imagine inexperience with the process has impacted its effectiveness. The
<br>> > projects that we have used them on appear to be good candidates (i.e., tech
<br>> > focused, small teams) but creative and UX always are a factor in our
<br>> > projects.
<br>> >
<br>> > Does anyone have tips or even good experiences to share regarding agile UX
<br>> > in the digital marketing arena?
<br>> >
<br>> > CV
<br>> >
<br>> >
<br>>
</div><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26402548Re: Agile vs. Creativity2009-11-17T20:56:08Z2009-11-17T20:56:08ZGeorge DinwiddieHi, Scott,
<br><br>Scott Preece wrote:
<br>> So, do you (and others on this list) think it would be common practice
<br>> for the PO to be sitting with developers while they're writing code?
<br><br>I couldn't tell you how common it is, but I've seen it. And it was a
<br>good thing. Not only did they reach a resolution on differences in a
<br>relatively short period of time, but each got more respect for the job
<br>the other was doing.
<br><br>> It just means that each increment is done (deliverable) before
<br>> it's delivered for PO review.
<br><br>I've always found it better when the PO is more involved than that.
<br>Sure, there are some pains at the start, but as those subside the team
<br>(which includes the PO) works much more fluidly.
<br><br> - George
<br><br>--
<br> ----------------------------------------------------------------------
<br> * George Dinwiddie * <a href="http://blog.gdinwiddie.com" target="_top" rel="nofollow">http://blog.gdinwiddie.com</a><br> Software Development <a href="http://www.idiacomputing.com" target="_top" rel="nofollow">http://www.idiacomputing.com</a><br> Consultant and Coach <a href="http://www.agilemaryland.org" target="_top" rel="nofollow">http://www.agilemaryland.org</a><br> ----------------------------------------------------------------------
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26401507Re: Agile vs. Creativity2009-11-17T18:34:53Z2009-11-17T18:34:53ZCindy Lu-3Sorry for the late reply. I don't have access to my personal emails at work and my evening is very short.
<br><br>See the my other post to John Schrag about stakeholders.
<br><br>Stakeholders: Usually customers and/or internal senior managers.
<br><br>Some examples:
<br>- looks too old style - not web 2.0 look
<br>- color scheme
<br>- too flat - no interesting interactions
<br>- too crowded
<br>...
<br><br>- Cindy
<br><br><br><br>________________________________
<br>From: George Dinwiddie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401507&i=0" target="_top" rel="nofollow">lists@...</a>>
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401507&i=1" target="_top" rel="nofollow">agile-usability@...</a>
<br>Sent: Tue, November 17, 2009 8:05:34 AM
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br>Cindy,
<br><br>You say "sometimes the result was still not satisfying." It would help
<br>me if you would elaborate on this a little. Not satisfying to whom?
<br>Not satisfying in what way? What did you see and hear that leads you to
<br>say it was not satisfying?
<br><br>- George
<br><br>Cindy Lu wrote:
<div class='shrinkable-quote'><br>>
<br>>
<br>> Tim,
<br>>
<br>> I was thinking the visual design is part of the architecture work.
<br>>
<br>> Anyway, the symptom we have is a lot of discussions on visual designs,
<br>> sometimes the result was still not satisfying. I tried to figure our a
<br>> way to make it better.
<br>>
<br>> - Cindy
<br>>
<br>> ------------ --------- --------- --------- --------- --------- -
<br>> *From:* Tim Wright <sambo.shacklock@ gmail.com>
<br>> *To:* agile-usability@ yahoogroups. com
<br>> *Sent:* Sun, November 15, 2009 4:56:02 PM
<br>> *Subject:* Re: [agile-usability] Agile vs. Creativity
<br>>
<br>>
<br>>
<br>>
<br>> Larry Constantine wrote something a week or so ago on a different
<br>> conversation in this mailing list (about Neilson's agile user experiance
<br>> alertbox):
<br>>
<br>> > I had looked at the earlier report, and the follow-up nicely
<br>> reinforces and refines the
<br>> > findings. It is gratifying to find Jakob concluding what Lucy and I
<br>> have been preaching
<br>> > for the last 7-8 years, particularly about the importance of a
<br>> coherent UI architecture
<br>> > worked out in advance.
<br>>
<br>> Perhaps what Cindy is noticing here is a symptom of not doing the
<br>> upfront architectural work?
<br>>
<br>> Tim
<br>> On Mon, Nov 16, 2009 at 10:46 AM, George Dinwiddie <lists@idiacomputin g
<br>> .com <mailto:lists@idiacomputing .com>> wrote:
<br>>
<br>>
<br>>
<br>> Hi, Cindy,
<br>>
<br>> I remember what you wrote the first time. That doesn't answer my
<br>> questions, though. Should I repeat them?
<br>>
<br>>
<br>>
<br>> Is it the designer who's making the decision as to what's a better
<br>> design? Or is it the stakeholder? Or do each of these people think
<br>> /they/ are the one?
<br>>
<br>> It sounds to me like the designer wants to create a final work before
<br>> getting the opinion of the stakeholder. Doesn't that disenfranchise the
<br>> stakeholder?
<br>>
<br>> By the way, when I said, "What would happen if a designer and a
<br>> stakeholder sat down together, so they could discuss what's liked, and
<br>> not liked, about a design /as it's being sketched/?" I really meant
<br>> that. Not "putting key points on the paper and review them with
<br>> stakeholders. " I mean sitting down together and working on it together.
<br>>
<br>> - George
<br>>
<br>>
<br>> Cindy Lu wrote:
<br>> >
<br>> >
<br>> > Hi! John and Gorge,
<br>> >
<br>> > I would like to go back to the original issues we started with:
<br>> >
<br>> > We found two issues for some design projects:
<br>> > 1. The number of iterations becomes endless (almost)
<br>> > 2. At the end, the final design is still not very satisfying
<br>> >
<br>> > I would like to understand if you have similar problems or in
<br>> your team,
<br>> > quick iterations work very well in the graphic design area.
<br>> >
<br>> > My observation is that some creative people need some time alone
<br>> to do
<br>> > the creation. For some people, this time period maybe longer.
<br>> >
<br>> > - Cindy
<br>> >
<br>> > ------------ --------- --------- --------- --------- --------- -
<br>> > *From:* John Schrag <john@schrag. ca <mailto:john% 40schrag. ca>>
<br>> > *To:* agile-usability@ yahoogroups. com
<br>> <mailto:agile- usability% 40yahoogroups. com>
<br>> > *Sent:* Sat, November 14, 2009 6:58:11 PM
<br>> > *Subject:* Re: [agile-usability] Agile vs. Creativity
<br>> >
<br>> >
<br>> >
<br>> > It wasn't clear from your note --- Are goals set at the beginning
<br>> of the
<br>> > design process? Because I think any design (interaction or
<br>> graphic) can
<br>> > be tweaked and refined until the end of time, unless you set
<br>> yourself
<br>> > some ending conditions. I'm not qualified to speak for graphic
<br>> design,
<br>> > but for interaction design we try to set specific measurable
<br>> goals (the
<br>> > user can find the feature in X amount of time without consulting the
<br>> > help; she can use it successfully to achieve her goals, etc) and we
<br>> > stop refining once the design has hit those goals. There is a
<br>> > temptation to keep improving the design, but time you spend doing
<br>> that
<br>> > is time you are taking away from other things that need your
<br>> attention.
<br>> >
<br>> > I think having a design brief implies having goals, so it is a
<br>> good thing.
<br>> >
<br>> > In many disciplines, the design process starts with ideation --
<br>> > generating lots of ideas very quickly but not developing them --
<br>> then
<br>> > moves on to winnow the ideas down to a few good ones, and develop
<br>> the
<br>> > few good ones further. I think this is valid for interface design as
<br>> > well. The only question then is your time budget for each of these
<br>> > activities. I will generally spend an hour or two coming up with a
<br>> > dozen or so quick interface skeches for a new feature, before
<br>> picking
<br>> > the most likely one and developing it into something more complete.
<br>> > Another trick is having a good review process, with the review
<br>> > focussing on the right level of critique. If you are presenting
<br>> the UI
<br>> > general layout, and someone is complaining about the fonts and
<br>> colours,
<br>> > then they need some coaching on being in a design review.
<br>>
</div><br>--
<br>------------ --------- --------- --------- --------- --------- -
<br>* George Dinwiddie * <a href="http://blog" target="_top" rel="nofollow">http://blog</a>. gdinwiddie. com
<br>Software Development <a href="http://www.idiacomputing.com" target="_top" rel="nofollow">http://www.idiacomputing.com</a><br>Consultant and Coach <a href="http://www.agilemaryland.org" target="_top" rel="nofollow">http://www.agilemaryland.org</a><br>------------ --------- --------- --------- --------- --------- -
<br><br><br>
<br><br><br> <p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26401469RE: Agile vs. Creativity2009-11-17T18:31:10Z2009-11-17T18:31:10ZMike Dwyer-2It might be interesting to find out what the iteration strategy was and how it was changed as well as what the new designer did that was different. Then, compare the two approaches to the third instance you mentioned.
<br><br>
<br><br>Mike Dwyer
<br>Principal Agile Consultant
<br><br>BigVisible Solutions
<br>url: <<a href="http://www.bigvisible.com/" target="_top" rel="nofollow">http://www.bigvisible.com/</a>> <a href="http://www.bigvisible.com" target="_top" rel="nofollow">http://www.bigvisible.com</a><br><br>cell: (978) 376-4422
<br><br>email: <mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=0" target="_top" rel="nofollow">mdwyer@...</a>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=1" target="_top" rel="nofollow">mdwyer@...</a>
<br><br>
<br><br>
<br><br>
<br><br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=2" target="_top" rel="nofollow">agile-usability@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=3" target="_top" rel="nofollow">agile-usability@...</a>] On Behalf Of Cindy Lu
<br>Sent: Tuesday, November 17, 2009 8:56 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=4" target="_top" rel="nofollow">agile-usability@...</a>
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br><br>
<br><br>John,
<br><br>
<br><br>In one project, the client was not happy with the final design after many frequent iterations. For the same client and another project, we changed a designer and iteration strategy. The design was finalized after 3 iterations. The client was very happy with the end result. In another project, a key stakeholder was not happy.
<br><br>
<br><br>- Cindy
<br><br>
<br><br> _____
<br><br>From: John Schrag <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=5" target="_top" rel="nofollow">john@...</a>>
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401469&i=6" target="_top" rel="nofollow">agile-usability@...</a>
<br>Sent: Mon, November 16, 2009 8:06:39 AM
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br><br>The thing that struck me in the original note was Cindy's description
<br>of the designs as being "not satisfying". Does this mean not
<br>satisfying the goals (assuming there were any) or does it mean that
<br>one person on the team (the owner?) is not satisfied? It made me
<br>wonder if this is actually a case of micromanagement.
<br><br>I also find it odd that some notes on this thread seem to imply that
<br>asking for two or three days to work through a design task is somehow
<br>un-agile. That's not a long time, unless your sprint length is
<br>really, really short.
<br><br>-john
<br><br>
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26401300Re: Agile vs. Creativity2009-11-17T18:07:56Z2009-11-17T18:07:56ZRon Jeffries-3Hello, Cindy. On Tuesday, November 17, 2009, at 8:47:08 PM, you
<br>wrote:
<br><br>>>How is more time away from the team going to get the idea any
<br>>> better, its expression to the team any better, or the team's
<br>>> willingness to do more changes and better?
<br><br>> 1) to absorb the requirement/feedback session to make sure the
<br>> problems and requirements are well understood
<br>> 2) to generate some ideas and try them
<br>> 3) consult a peer for their opinions
<br>> 4) to think through how to present the design
<br><br>Those MIGHT produce a better idea. I don't see that it will improve
<br>the idea's fit with the team's ideas, that it will make it easier to
<br>sell to the team, or that the team will become more willing to
<br>listen.
<br><br>But again, of course, you should do as you think is best.
<br><br>Ron Jeffries
<br>www.XProgramming.com
<br>www.xprogramming.com/blog
<br>Design is the thinking one does before, during, and after
<br>implementation. It works best for me with a little up front, most of
<br>it during implementation, and very little after it's too late.
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26401272Re: Agile vs. Creativity2009-11-17T18:04:29Z2009-11-17T18:04:29ZRon Jeffries-3Hello, Cindy. On Tuesday, November 17, 2009, at 8:16:11 PM, you
<br>wrote:
<br><br>> The stakholder(s) usually have very limited time. So when we
<br>> present to them, we want to make sure the idea is well thought
<br>> out. It does not mean the design is final. The designer felt if
<br>> he is left alone for 2-3 days, he can create several options from
<br>> different angles instead of focusing on one less than half based
<br>> idea. Sometimes, a good idea is easily killed if it is not well thought through.
<br><br>> I think visual design work is different from other types of
<br>> creation work in system design. In addition, people are different how best they can produce.
<br><br>Of course you should do as you feel is best. I've noticed, however,
<br>that every specialty thinks that theirs is the one that needs to be
<br>handled differently in Agile. My experience suggests that this is
<br>not the case.
<br><br>Ron Jeffries
<br>www.XProgramming.com
<br>www.xprogramming.com/blog
<br>Without practice, no emergence. -- Dougen Zenji
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26401196Re: Agile vs. Creativity2009-11-17T17:56:25Z2009-11-17T17:56:25ZCindy Lu-3John,
<br><br>In one project, the client was not happy with the final design after many frequent iterations. For the same client and another project, we changed a designer and iteration strategy. The design was finalized after 3 iterations. The client was very happy with the end result. In another project, a key stakeholder was not happy.
<br><br>- Cindy
<br><br><br><br>________________________________
<br>From: John Schrag <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401196&i=0" target="_top" rel="nofollow">john@...</a>>
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401196&i=1" target="_top" rel="nofollow">agile-usability@...</a>
<br>Sent: Mon, November 16, 2009 8:06:39 AM
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br>The thing that struck me in the original note was Cindy's description
<br>of the designs as being "not satisfying". Does this mean not
<br>satisfying the goals (assuming there were any) or does it mean that
<br>one person on the team (the owner?) is not satisfied? It made me
<br>wonder if this is actually a case of micromanagement.
<br><br>I also find it odd that some notes on this thread seem to imply that
<br>asking for two or three days to work through a design task is somehow
<br>un-agile. That's not a long time, unless your sprint length is
<br>really, really short.
<br><br>-john
<br><br><br>
<br><br><br> <p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26401123Re: Agile vs. Creativity2009-11-17T17:47:08Z2009-11-17T17:47:08ZCindy Lu-3Hi! Ron,
<br><br>Thanks for sharing your thought.
<br><br>>How is more time away from the team going to get the idea any
<br>better, its expression to the team any better, or the team's
<br>willingness to do more changes and better?
<br><br>1) to absorb the requirement/feedback session to make sure the problems and requirements are well understood
<br>2) to generate some ideas and try them
<br>3) consult a peer for their opinions
<br>4) to think through how to present the design
<br><br>- Cindy
<br><br><br>________________________________
<br>From: Ron Jeffries <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401123&i=0" target="_top" rel="nofollow">ronjeffries@...</a>>
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26401123&i=1" target="_top" rel="nofollow">agile-usability@...</a>
<br>Sent: Mon, November 16, 2009 6:01:18 AM
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br>Hello, chris. On Sunday, November 15, 2009, at 6:39:01 PM, you
<br>wrote:
<br><br>> If that isn't done, then I can imagine it leading to the situation from the
<br>> original post -- you get approval on an idea with a bunch of changes, and
<br>> those changes beget more changes, and after a couple of rounds, it's hard to
<br>> see that progress is being made (eg, get the colors right and the font may
<br>> need adjustment, get the font right and scaling of images could look wrong,
<br>> etc etc)
<br><br>How is more time away from the team going to get the idea any
<br>better, its expression to the team any better, or the team's
<br>willingness to do more changes and better?
<br><br>Ron Jeffries
<br>www.XProgramming. com
<br>www.xprogramming. com/blog
<br>One test is worth a thousand expert opinions.
<br>-- Bill Nye (The Science Guy)
<br><br><br>
<br><br><br> <p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26400983Re: Agile vs. Creativity2009-11-17T17:32:36Z2009-11-17T17:32:36ZCindy Lu-3William wrote:
<br><br>>Cindy, could it be that the endless-iteration projects are ones where they're working serially, rather than starting with (or introducing) wide variations?
<br><br>We always started with 2-3 design options. Sometimes, none of them are satisfying so the designer started all over again. For a most recent project, after several iterations that lasted several weeks, none of them were chosen.
<br><br>I put all the designs in one deck, printed them all out and sat with the stakeholders. I asked them only focus on elements they liked and they thought that met the design brief we agreed. I also asked additional requirements in their mind. I documented them in one page. After that session, the designer created one more design. The key stakeholder said "This is it".
<br><br>- Cindy
<br><br><br><br><br><br>
<br><br><br> <p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26400865Re: Agile vs. Creativity2009-11-17T17:16:11Z2009-11-17T17:16:11ZCindy Lu-3The stakholder(s) usually have very limited time. So when we present to them, we want to make sure the idea is well thought out. It does not mean the design is final. The designer felt if he is left alone for 2-3 days, he can create several options from different angles instead of focusing on one less than half based idea. Sometimes, a good idea is easily killed if it is not well thought through.
<br><br>I think visual design work is different from other types of creation work in system design. In addition, people are different how best they can produce.
<br><br>I would like to try the idea for the next project to see how it goes.
<br><br>- Cindy
<br><br><br>________________________________
<br>From: George Dinwiddie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26400865&i=0" target="_top" rel="nofollow">lists@...</a>>
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26400865&i=1" target="_top" rel="nofollow">agile-usability@...</a>
<br>Sent: Sun, November 15, 2009 8:11:04 PM
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br>I'm not quite sure what Larry means by "a coherent UI architecture
<br>worked out in advance." Perhaps he'll elaborate.
<br><br>Cindy mentioned, "the quality of the visual design, e.g. contrast,
<br>balance, cohesiveness of the theme, if sample text presented, no
<br>spelling errors, etc." It seems to me that the designer and the
<br>stakeholder can sit together and play with these parameters, and others,
<br>discussing them in both design terms and business terms, and coming to
<br>some sort of agreement. I wonder why the designer feels the need to do
<br>this work without feedback and then present it all at once for approval.
<br>That seems like a good recipe for the "almost endless" number of
<br>iterations.
<br><br>- George
<br><br>Tim Wright wrote:
<div class='shrinkable-quote'><br>>
<br>>
<br>>
<br>> Hmm. Given the sheer number of IT architects we have at work, I could
<br>> well mean neither :)
<br>>
<br>> I meant: "a coherent UI architecture worked out in advance" (from Larry :).
<br>> Tim
<br>> On Mon, Nov 16, 2009 at 11:40 AM, Ron Jeffries <ronjeffries@ acm.org
<br>> <mailto:ronjeffries@ acm.org>> wrote:
<br>>
<br>>
<br>>
<br>> Hello, Tim. On Sunday, November 15, 2009, at 4:56:02 PM, you
<br>> wrote:
<br>>
<br>>
<br>>
<br>> > Perhaps what Cindy is noticing here is a symptom of not doing the
<br>> upfront
<br>> > architectural work?
<br>>
<br>> If you really mean architectural work, it turns out that
<br>> surprisingly little is needed up front. Architecture evolution works
<br>> just fine.
<br>>
<br>> If you mean UX design work, it is my expectation that this, too,
<br>> could be made to evolve, but I grant that I am not expert in the
<br>> area so could conceivably be wrong.
<br>>
<br>> Ron Jeffries
<br>> www.XProgramming. com <<a href="http://www.xprogramming.com/" target="_top" rel="nofollow">http://www.xprogramming.com/</a>>
<br>> www.xprogramming. com/blog <<a href="http://www.xprogramming.com/blog" target="_top" rel="nofollow">http://www.xprogramming.com/blog</a>>
<br>> In times of stress, I like to turn to the wisdom of my Portuguese
<br>> waitress,
<br>> who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
<br>> -- after Mark Vaughn, Autoweek.
<br>>
</div><br>--
<br>------------ --------- --------- --------- --------- --------- -
<br>* George Dinwiddie * <a href="http://blog" target="_top" rel="nofollow">http://blog</a>. gdinwiddie. com
<br>Software Development <a href="http://www.idiacomputing.com" target="_top" rel="nofollow">http://www.idiacomputing.com</a><br>Consultant and Coach <a href="http://www.agilemaryland.org" target="_top" rel="nofollow">http://www.agilemaryland.org</a><br>------------ --------- --------- --------- --------- --------- -
<br><br><br>
<br><br><br> <p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26393111Re: Agile vs. Creativity2009-11-17T08:37:28Z2009-11-17T08:37:28ZScott Preece-2So, do you (and others on this list) think it would be common practice for the PO to be sitting with developers while they're writing code?
<br><br>My understanding was that the normal model was that the PO prioritizes stories, engages in conversations as needed, and provides feedback on iteration deliveries, but doesn't get involved in the "inside" of the work. I don't see why that would be different for design work than for code - the designer should have the time needed to get the work to a reviewable state before presenting it for feedback.
<br><br>I think the problem is that designs, being visual, always have a current state that someone can respond to and therefore seems to be "reviewable", where functionality stories don't have a visible state until an increment of work has been finished. You need to treat the designer the same way you would a coder - the work should be done in increments, but each increment should be finished before it's reviewed. This doesn't mean there isn't collaboration going on - the designer should get feedback from other designers while the increment is being created. It just means that each increment is done (deliverable) before it's delivered for PO review.
<br><br>regards,
<br>scott
<br><br><br><br><div class='shrinkable-quote'><br>>
<br>>From: George Dinwiddie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26393111&i=0" target="_top" rel="nofollow">lists@...</a>>
<br>>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26393111&i=1" target="_top" rel="nofollow">agile-usability@...</a>
<br>>Sent: Tue, November 17, 2009 7:22:42 AM
<br>>Subject: Re: [agile-usability] Agile vs. Creativity
<br>>
<br>> >
<br>>>
<br>>
<br>>chris chandler wrote:
<br>>>> You say they should collaborate over sketches, I went to great length to
<br>>>> discuss how a visual designer works (in photoshop). At this point I'm
<br>>>> sure I don't understand what you are suggesting -- how would the
<br>>>> conversation go in your world??
<br>>
<br>>>Chris,
<br>>
<br>>>I don't want to dive down the rabbit-hole of the hypothetical. Cindy is
<br>>>describing a real situation. I'm trying to base my statements on her
<br>>>observations. I'm not trying to describe a way for everyone to work all
<br>>>the time. Mostly people can work out effective ways of working
<br>>>together. We notice the times when it's not so effective.
<br>>
<br>>>Cindy has noticed that this situation is not so effective. Her team has
<br>>>discussed this (perhaps without the stakeholder or PO or whoever is
<br>>>filling the "other side" of the situation), and decided that they'd be
<br>>>better off left alone more, so they can do the work they know how to do.
<br>>> This is a very tempting path, I know from experience.
<br>>
<br>>>I also know from experience, that even if they're really great at what
<br>>>they do, going off and working alone to present a more-complete version
<br>>>to the PO (or whomever) is not likely to generate a closer understanding
<br>>>between the PO and the designer such that the concerns of both are well
<br>>>satisfied.
<br>>
<br>>>I also know from experience, that even people who think they're a good
<br>>>judge of something they don't know how to do themselves, gain a greater
<br>>>appreciation of the skill and nuance when they work together with
<br>>>someone who can communicate while exploring the alternatives with them.
<br>>> And this is fractal, in that it's quite similar at various levels of
<br>>>detail.
<br>>
<br>>>I also know from experience, that two people trying to work together in
<br>>>this fashion often have to learn how to work together in this fashion in
<br>>>order to do so. And even if they've worked in this fashion before, they
<br>>>both have to learn how to work in this fashion with these two particular
<br>>>people. "How the conversation goes" depends entirely on these two
<br>>>people and their context.
<br>>
<br>>>I'm not saying it's easy. And there are many possible dysfunctions,
<br>>>ranging from the know-it-all PO and the prima donna designer to the
<br>>>simple difficulty of verbalizing intangibles. We don't have to solve
<br>>>all of these possible dysfunctions, though. We just need to help this
<br>>>one particular case.
<br>>
<br>>>- George
<br>>
<br>>>--
<br>>> ------------ --------- --------- --------- --------- --------- -
<br>>> * George Dinwiddie * <a href="http://blog" target="_top" rel="nofollow">http://blog</a>. gdinwiddie. com
<br>>> Software Development <a href="http://www.idiacomputing.com" target="_top" rel="nofollow">http://www.idiacomputing.com</a><br>>> Consultant and Coach <a href="http://www.agilemaryland.org" target="_top" rel="nofollow">http://www.agilemaryland.org</a><br>>> ------------ --------- --------- --------- --------- --------- -
<br>>
<br>>
<br>> </div><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26392289RE: Agile vs. Creativity2009-11-17T07:48:12Z2009-11-17T07:48:12ZMike Dwyer-2William
<br><br>Your citing the Dunning-Kruger effect highlights a core change that Agile
<br>and Scrum brings about. The Dunning-Kruger effect is an example of the
<br>emotional muscle memory conventional work practices have built in most of
<br>us. These practices stress individual superiority over others; the
<br>profession you are in; the organization you are part of; the people you feel
<br>will be impressed enough to reward you. The Dunning-Kruger effect feeds on
<br>the silly notion that each one of us is capable of doing anything by
<br>ourselves. What a crock. Name one thing you have done with no one else
<br>involved. It is an impossibility, unless you actually carved out each part
<br>of the computer you are working on, formed each gate of the ALU (computer
<br>chip) and then created each pixel of light and dark you need to see this on
<br>the screen.
<br><br>The Dunning-Kruger effect exists because we try to live up to this
<br>fabrication of living.
<br><br>
<br><br>Agile tosses a wrench into that notion and sits down and asks the other poor
<br>bloke across the way what they think, what they are doing and can we be of
<br>assistance in what they are doing a long phrase for collaboration. We
<br>admit that we cannot do it all and from that we form hardy bands of people
<br>who get things done because we know that individually we are great a very
<br>few things, OK at some and for the most part are barely average to awful.
<br>That may not be you but it is, for many of us, what we use to find and form
<br>complimentary cross functional teams. We also recognize that the product
<br>owner is the most exposed of any member of the team. Yes, I did say they are
<br>part of the team.
<br><br>
<br><br>So why shouldnt they show the Dunning-Kruger effect more than others? What
<br>have you done to provide empirical evidence that the Dunning-Kruger effect
<br>is not the way it is but a façade? Look the Product Owner is the most
<br>exposed, vulnerable, and least ready to answer the three terrifying
<br>questions any of us face. How is it going?; Are we on budget?; Will we
<br>have everything we want in the product as of today?
<br><br>
<br><br>The challenge we face in this nebulous cloud of usability or any other cloud
<br>of emerging solutions is the same. If we dont band together, we are all
<br>going to suffer alone. Agile is the both the grease that loosens the knot
<br>of muscle memory and the glue that can make collaboration stick.
<br><br>
<br><br>Mike Dwyer
<br>Principal Agile Consultant
<br><br>BigVisible Solutions
<br>url: <<a href="http://www.bigvisible.com/" target="_top" rel="nofollow">http://www.bigvisible.com/</a>> <a href="http://www.bigvisible.com" target="_top" rel="nofollow">http://www.bigvisible.com</a><br><br>cell: (978) 376-4422
<br><br>email: <mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26392289&i=0" target="_top" rel="nofollow">mdwyer@...</a>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26392289&i=1" target="_top" rel="nofollow">mdwyer@...</a>
<br><br>
<br><br>
<br><br>
<br><br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26392289&i=2" target="_top" rel="nofollow">agile-usability@...</a>
<br>[mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26392289&i=3" target="_top" rel="nofollow">agile-usability@...</a>] On Behalf Of William Pietri
<br>Sent: Monday, November 16, 2009 10:06 PM
<br>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26392289&i=4" target="_top" rel="nofollow">agile-usability@...</a>
<br>Subject: Re: [agile-usability] Agile vs. Creativity
<br><br>
<br><br>
<br><br>George Dinwiddie wrote:
<br>> Why would you imagine the graphic designer being just a pair of hands on
<br>> the computer while the PO creates the graphic design? Do you really
<br>> think so little of Product Owners? Do you really think so little of
<br>> graphic designers?
<br>>
<br><br>To be fair, a lot of novice product owners do mistake themselves for
<br>bosses, so back-seat driving is regrettably common. And visual design is
<br>one of those areas where quite a lot of people think their opinion is
<br>just as good as a professional's.[1] So Chris may be imagining that
<br>relationship because that's mainly what he sees.
<br><br>Personally, when there are big differences of opinion, I like to see
<br>visual designs evaluated a) by other visual design experts, and b) via
<br>actual data. And similarly for almost any other field of expertise. But
<br>generally, I think Agile teams work best when people trust each other to
<br>handle their fields.
<br><br>William
<br><br>[1] Due, I think, to the Dunning-Kruger effect:
<br><a href="http://en.wikipedia.org/wiki/Dunning-Kruger_effect" target="_top" rel="nofollow">http://en.wikipedia.org/wiki/Dunning-Kruger_effect</a><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26391337Re: Agile vs. Creativity2009-11-17T06:56:25Z2009-11-17T06:56:25ZScott Preece-2This may not be an easy thing to describe. I suspect more people would say that, viewed as an object, the iPhone is more "satisfying" than the Google/Motorola DROID. How would you describe what makes it so?
<br><br>scott
<br><br><br><div class='shrinkable-quote'><br>>
<br>>From: George Dinwiddie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26391337&i=0" target="_top" rel="nofollow">lists@...</a>>
<br>>To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26391337&i=1" target="_top" rel="nofollow">agile-usability@...</a>
<br>>Sent: Tue, November 17, 2009 7:05:34 AM
<br>>Subject: Re: [agile-usability] Agile vs. Creativity
<br>>
<br>> >
<br>>>
<br>>
<br>>Cindy,
<br>>
<br>>>You say "sometimes the result was still not satisfying." It would help
<br>>>me if you would elaborate on this a little. Not satisfying to whom?
<br>>>Not satisfying in what way? What did you see and hear that leads you to
<br>>>say it was not satisfying?
<br>>
<br>>>- George
<br>>
<br>>>Cindy Lu wrote:
<br>>>>
<br>>>>
<br>>>> Tim,
<br>>>>
<br>>>> I was thinking the visual design is part of the architecture work.
<br>>>>
<br>>>> Anyway, the symptom we have is a lot of discussions on visual designs,
<br>>>> sometimes the result was still not satisfying. I tried to figure our a
<br>>>> way to make it better.
<br>>>>
<br>>>> - Cindy
<br>>>>
<br>>>> ------------ --------- --------- --------- --------- --------- -
<br>>>> *From:* Tim Wright <sambo.shacklock@ gmail.com>
<br>>>> *To:* agile-usability@ yahoogroups. com
<br>>>> *Sent:* Sun, November 15, 2009 4:56:02 PM
<br>>>> *Subject:* Re: [agile-usability] Agile vs. Creativity
<br>>>>
<br>>>>
<br>>>>
<br>>>>
<br>>>> Larry Constantine wrote something a week or so ago on a different
<br>>>> conversation in this mailing list (about Neilson's agile user experiance
<br>>>> alertbox):
<br>>>>
<br>>>> > I had looked at the earlier report, and the follow-up nicely
<br>>>> reinforces and refines the
<br>>>> > findings. It is gratifying to find Jakob concluding what Lucy and I
<br>>>> have been preaching
<br>>>> > for the last 7-8 years, particularly about the importance of a
<br>>>> coherent UI architecture
<br>>>> > worked out in advance.
<br>>>>
<br>>>> Perhaps what Cindy is noticing here is a symptom of not doing the
<br>>>> upfront architectural work?
<br>>>>
<br>>>> Tim
<br>>>> On Mon, Nov 16, 2009 at 10:46 AM, George Dinwiddie <lists@idiacomputin g
<br>>>> .com <mailto:lists@idiacomputing .com>> wrote:
<br>>>>
<br>>>>
<br>>>>
<br>>>> Hi, Cindy,
<br>>>>
<br>>>> I remember what you wrote the first time. That doesn't answer my
<br>>>> questions, though. Should I repeat them?
<br>>>>
<br>>>>
<br>>>>
<br>>>> Is it the designer who's making the decision as to what's a better
<br>>>> design? Or is it the stakeholder? Or do each of these people think
<br>>>> /they/ are the one?
<br>>>>
<br>>>> It sounds to me like the designer wants to create a final work before
<br>>>> getting the opinion of the stakeholder. Doesn't that disenfranchise the
<br>>>> stakeholder?
<br>>>>
<br>>>> By the way, when I said, "What would happen if a designer and a
<br>>>> stakeholder sat down together, so they could discuss what's liked, and
<br>>>> not liked, about a design /as it's being sketched/?" I really meant
<br>>>> that. Not "putting key points on the paper and review them with
<br>>>> stakeholders. " I mean sitting down together and working on it together.
<br>>>>
<br>>>> - George
<br>>>>
<br>>>>
<br>>>> Cindy Lu wrote:
<br>>>> >
<br>>>> >
<br>>>> > Hi! John and Gorge,
<br>>>> >
<br>>>> > I would like to go back to the original issues we started with:
<br>>>> >
<br>>>> > We found two issues for some design projects:
<br>>>> > 1. The number of iterations becomes endless (almost)
<br>>>> > 2. At the end, the final design is still not very satisfying
<br>>>> >
<br>>>> > I would like to understand if you have similar problems or in
<br>>>> your team,
<br>>>> > quick iterations work very well in the graphic design area.
<br>>>> >
<br>>>> > My observation is that some creative people need some time alone
<br>>>> to do
<br>>>> > the creation. For some people, this time period maybe longer.
<br>>>> >
<br>>>> > - Cindy
<br>>>> >
<br>>>> > ------------ --------- --------- --------- --------- --------- -
<br>>>> > *From:* John Schrag <john@schrag. ca <mailto:john% 40schrag. ca>>
<br>>>> > *To:* agile-usability@ yahoogroups. com
<br>>>> <mailto:agile- usability% 40yahoogroups. com>
<br>>>> > *Sent:* Sat, November 14, 2009 6:58:11 PM
<br>>>> > *Subject:* Re: [agile-usability] Agile vs. Creativity
<br>>>> >
<br>>>> >
<br>>>> >
<br>>>> > It wasn't clear from your note --- Are goals set at the beginning
<br>>>> of the
<br>>>> > design process? Because I think any design (interaction or
<br>>>> graphic) can
<br>>>> > be tweaked and refined until the end of time, unless you set
<br>>>> yourself
<br>>>> > some ending conditions. I'm not qualified to speak for graphic
<br>>>> design,
<br>>>> > but for interaction design we try to set specific measurable
<br>>>> goals (the
<br>>>> > user can find the feature in X amount of time without consulting the
<br>>>> > help; she can use it successfully to achieve her goals, etc) and we
<br>>>> > stop refining once the design has hit those goals. There is a
<br>>>> > temptation to keep improving the design, but time you spend doing
<br>>>> that
<br>>>> > is time you are taking away from other things that need your
<br>>>> attention.
<br>>>> >
<br>>>> > I think having a design brief implies having goals, so it is a
<br>>>> good thing.
<br>>>> >
<br>>>> > In many disciplines, the design process starts with ideation --
<br>>>> > generating lots of ideas very quickly but not developing them --
<br>>>> then
<br>>>> > moves on to winnow the ideas down to a few good ones, and develop
<br>>>> the
<br>>>> > few good ones further. I think this is valid for interface design as
<br>>>> > well. The only question then is your time budget for each of these
<br>>>> > activities. I will generally spend an hour or two coming up with a
<br>>>> > dozen or so quick interface skeches for a new feature, before
<br>>>> picking
<br>>>> > the most likely one and developing it into something more complete.
<br>>>> > Another trick is having a good review process, with the review
<br>>>> > focussing on the right level of critique. If you are presenting
<br>>>> the UI
<br>>>> > general layout, and someone is complaining about the fonts and
<br>>>> colours,
<br>>>> > then they need some coaching on being in a design review.
<br>>>>
<br>>
<br>>>--
<br>>> ------------ --------- --------- --------- --------- --------- -
<br>>> * George Dinwiddie * <a href="http://blog" target="_top" rel="nofollow">http://blog</a>. gdinwiddie. com
<br>>> Software Development <a href="http://www.idiacomputing.com" target="_top" rel="nofollow">http://www.idiacomputing.com</a><br>>> Consultant and Coach <a href="http://www.agilemaryland.org" target="_top" rel="nofollow">http://www.agilemaryland.org</a><br>>> ------------ --------- --------- --------- --------- --------- -
<br>>
<br>>
<br>> </div><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26390562Re: Agile vs. Creativity2009-11-17T06:08:57Z2009-11-17T06:08:57ZPascal RoySomething struck me while reading the last few posts....
<br><br>On usability issues, there's this fear that because the Product Owner
<br>is in a position of power, he will disregard the contributions of the
<br>designers. This might and is probably true in the experience of many.
<br>As much as I don't believe the Product Owner should be able to force
<br>the programmer to do shoddy work, he should also not be allowed to
<br>force designers to do shoddy work. Remember the XP developer bill of
<br>rights? You have the right to do quality work... I think this is
<br>fundamental to building any good team!!!
<br><br>Watch out, quality and scope is not the same. There's tons of ways of
<br>implementing a login in terms of scope (users/password hardcoded, in a
<br>file, bypassing by retrieving the OS login, using some network
<br>authentication....). From the simple to the most complex, they can all
<br>be designed and coded at top quality... The product owner gets to
<br>choose the scope according to the value and cost. The quality of of
<br>design and implementation should not be negotiable. I think in the
<br>case of visual designs, there could be multiple valid variations which
<br>could have the same or different business value with varying
<br>implementation costs. As professionals, designers should offer
<br>different options but should always be of top quality. Any suggested
<br>modifications to the design, coming from any team member including the
<br>PO, should always be validated and approved by the designer for quality.
<br><br>So in summary:
<br><br>1) I do think we agree that having a Product Owner trump the designer
<br>on design issues is clearly a team dysfunction. If a PO thinks a
<br>design does not work, he should ask the designer for other possible
<br>options by stating his objections and giving useful comments. He
<br>should also be be ready to pay for it, nothing is free. The product
<br>owner owns scope, the designer owns the quality of the proposed
<br>designs. Clearly, in real life, Product Owners will probably meddle. I
<br>believe that as s a professional designer, you are responsible to
<br>state your objection to any forced modification you disagree with. In
<br>some cases, as is stated in the code of conduct of may professions,
<br>you might actually refuse to do the work (in civil engineering for
<br>example, lives might be at stake). In other cases where consequences
<br>might not be so terrible, you might go on and hope to continue
<br>influencing the team. If it happens all the time, then it might be
<br>another problem, see point#3.
<br>2) Everybody can contribute to the UI design. A designer who does not
<br>listen to team members is clearly a team dysfunction.
<br>3) Either the team thrusts that the designer is knowledgeable and
<br>should be listened to, or the team should get another designer. Again,
<br>no thrust in the designer is also a team dysfunction. As the
<br>designer, you might want to think about how you are presenting your
<br>knowledge to the team. It's a question of respect, and it usually
<br>needs to be earned in some way. Being cocky or just banking on the
<br>title is typically not a winning strategy IMHO. A sign that this
<br>problem exists in your team is if you actually need to enforce the
<br>Designer title officially!!!
<br><br>Anyway, that's my two cents on the subject... YMMV.
<br><br>Pascal Roy, ing./P.Eng., PMP
<br>Vice-Président/Vice President
<br>Elapse Technologies inc.
<br><br>[url] www.elapsetech.com
<br>[email]] <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26390562&i=0" target="_top" rel="nofollow">pascal.roy@...</a>
<br>[cell] 514-862-6836
<br><br><br>Le 2009-11-16 à 22:05, William Pietri a écrit :
<br><div class='shrinkable-quote'><br>> George Dinwiddie wrote:
<br>> > Why would you imagine the graphic designer being just a pair of
<br>> hands on
<br>> > the computer while the PO creates the graphic design? Do you really
<br>> > think so little of Product Owners? Do you really think so little of
<br>> > graphic designers?
<br>> >
<br>>
<br>> To be fair, a lot of novice product owners do mistake themselves for
<br>> bosses, so back-seat driving is regrettably common. And visual
<br>> design is
<br>> one of those areas where quite a lot of people think their opinion is
<br>> just as good as a professional's.[1] So Chris may be imagining that
<br>> relationship because that's mainly what he sees.
<br>>
<br>> Personally, when there are big differences of opinion, I like to see
<br>> visual designs evaluated a) by other visual design experts, and b) via
<br>> actual data. And similarly for almost any other field of expertise.
<br>> But
<br>> generally, I think Agile teams work best when people trust each
<br>> other to
<br>> handle their fields.
<br>>
<br>> William
<br>>
<br>> [1] Due, I think, to the Dunning-Kruger effect:
<br>> <a href="http://en.wikipedia.org/wiki/Dunning-Kruger_effect" target="_top" rel="nofollow">http://en.wikipedia.org/wiki/Dunning-Kruger_effect</a><br>>
</div><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>tag:old.nabble.com,2006:post-26389845Re: Agile vs. Creativity2009-11-17T05:22:42Z2009-11-17T05:22:42ZGeorge Dinwiddiechris chandler wrote:
<br>> You say they should collaborate over sketches, I went to great length to
<br>> discuss how a visual designer works (in photoshop). At this point I'm
<br>> sure I don't understand what you are suggesting -- how would the
<br>> conversation go in your world??
<br><br>Chris,
<br><br>I don't want to dive down the rabbit-hole of the hypothetical. Cindy is
<br>describing a real situation. I'm trying to base my statements on her
<br>observations. I'm not trying to describe a way for everyone to work all
<br>the time. Mostly people can work out effective ways of working
<br>together. We notice the times when it's not so effective.
<br><br>Cindy has noticed that this situation is not so effective. Her team has
<br>discussed this (perhaps without the stakeholder or PO or whoever is
<br>filling the "other side" of the situation), and decided that they'd be
<br>better off left alone more, so they can do the work they know how to do.
<br> This is a very tempting path, I know from experience.
<br><br>I also know from experience, that even if they're really great at what
<br>they do, going off and working alone to present a more-complete version
<br>to the PO (or whomever) is not likely to generate a closer understanding
<br>between the PO and the designer such that the concerns of both are well
<br>satisfied.
<br><br>I also know from experience, that even people who think they're a good
<br>judge of something they don't know how to do themselves, gain a greater
<br>appreciation of the skill and nuance when they work together with
<br>someone who can communicate while exploring the alternatives with them.
<br> And this is fractal, in that it's quite similar at various levels of
<br>detail.
<br><br>I also know from experience, that two people trying to work together in
<br>this fashion often have to learn how to work together in this fashion in
<br>order to do so. And even if they've worked in this fashion before, they
<br>both have to learn how to work in this fashion with these two particular
<br>people. "How the conversation goes" depends entirely on these two
<br>people and their context.
<br><br>I'm not saying it's easy. And there are many possible dysfunctions,
<br>ranging from the know-it-all PO and the prima donna designer to the
<br>simple difficulty of verbalizing intangibles. We don't have to solve
<br>all of these possible dysfunctions, though. We just need to help this
<br>one particular case.
<br><br> - George
<br><br>--
<br> ----------------------------------------------------------------------
<br> * George Dinwiddie * <a href="http://blog.gdinwiddie.com" target="_top" rel="nofollow">http://blog.gdinwiddie.com</a><br> Software Development <a href="http://www.idiacomputing.com" target="_top" rel="nofollow">http://www.idiacomputing.com</a><br> Consultant and Coach <a href="http://www.agilemaryland.org" target="_top" rel="nofollow">http://www.agilemaryland.org</a><br> ----------------------------------------------------------------------
<br><br><p>From forum: <a href="http://old.nabble.com/Agile-Usability-f14363.html" embed="fixTarget[14363]" target="_top" >Agile Usability</a></p>