IxD in agile environments

12 Feb 2007 - 6:08pm
7 years ago
38 replies
903 reads
Robert Hoekman, Jr.
2005

Anyone doing IxD work in an agile programming environment? If so, what are
you doing to make it work with agile processes? Is it succeeding? What are
the problems you've had?

I know there's been some talk about this before on this list, and it seems a
lot of people are having serious trouble finding ways to adapt and work with
agile methods, but I've formed some ideas about this on my own, because I've
been working like this for a long time and have found ways to make it work
for me, and am wondering what other people have come up with.

Thanks.

-r-

Comments

12 Feb 2007 - 6:21pm
Daniel Williams
2005

I am working in an agile project and think it is great. I hate developing a
full spec then passing it over the fence, I think that there is nothing more
inefficient and a waste of time than that. So in this vein Agile is great, I
work closely with developers to reach a solution and documentation is
minimal.

The hardest thing to let go was the ownership of the business design, this
is now shared across the entire team! However I had the advantage of
starting a sprint ahead of the tech team, so this allowed me to gather the
requirements, understand the users and their needs, create persona's,
develop a product backlog based upon user stories and think about the vision
etc etc.

After the initial sprint 0, the team (BA's, UE, Dev etc) worked on the
features selected for each sprint together. This worked great with the BA/UE
focusing on fleshing out the business requirements (based upon the user
stories being tackled for that sprint) and working with the tech to reach a
mutually agreeable design (one that satisfies the business design and that
is deliverable within the sprint)

Well that is a very high level view anyway

On 2/12/07, Robert Hoekman, Jr. <rhoekmanjr at gmail.com> wrote:
>
> Anyone doing IxD work in an agile programming environment? If so, what are
> you doing to make it work with agile processes? Is it succeeding? What are
> the problems you've had?
>
> I know there's been some talk about this before on this list, and it seems
> a
> lot of people are having serious trouble finding ways to adapt and work
> with
> agile methods, but I've formed some ideas about this on my own, because
> I've
> been working like this for a long time and have found ways to make it work
> for me, and am wondering what other people have come up with.
>
> Thanks.
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

12 Feb 2007 - 6:54pm
Josh
2006

Robert,

We have been using our own "home-brewed" version of Agile development
processes for a while now, and there were some growing pains introducing
design into the works initially. I call it "home-brewed" because the process
changes slightly based on the client/project, and I guess in that sense it
truly is organic. We try to use the best process for the job, as opposed to
trying to find a one-size-fits-all process. Admittedly, We tend to simulate
(read: fake the funk) old school waterfall processes when the client is
equally old school and document greedy.

What we've found is that fluid communication between designers and
developers is key. Our process usually starts with a standard "kick-off"
meeting which quickly turns into a strategy session. Our designers and
developers work in parallel through the entire process. We start the
designers off creating what can be considered global styles/rules as opposed
to pages while the developers focus on development of models/architecture.
We don't usually address the design of specific pages until we get to them.
The benefit is a ton of flexibility, and changes to project scope don't seem
quite as daunting. Lay the foundation then build and refine room-by-room.

We use online writeboards and chat rooms to keep everyone on the same page
during the project as opposed to over-the-walling specs. The process does
force designers and developers to pay attention to what's going on, because
the project is never fully documented until it's complete. The process would
be difficult for a developer or designer who plans on having a lot of
"heads-down" time.

We shy away from creating tons of mock-ups ahead of time, because we've
experienced quite a few projects where mock-ups contain subtle implied
functionality that is not clearly communicated on one page. I guess the best
way to put it would be that we try to solve one problem at a time instead of
trying to plan solutions to all possible problems ahead of time.

The power of the Web is that we can work quickly in an environment that is
built to be changed quickly. Not understanding the nature of the technology
leads many teams to treat the web like it's a shrink-wrapped software
project. Doing so expresses a complete ignorance of the power of the medium,
and makes change very very scary.

To address Dan's comment about the relinquishing the ownership of the
business design. This hasn't been as much of a problem. We front-load the
process with lots of conversation and use a product manager or similar to
manage the global vision. This isn't contrary to Agile development, in that
the focus is on human responsibility and not documentation.

- Josh Viney

12 Feb 2007 - 8:33pm
Allison Beckwith
2006

On Feb 12, 2007, at 3:08 PM, Robert Hoekman, Jr. wrote:

> Anyone doing IxD work in an agile programming environment? If so,
> what are
> you doing to make it work with agile processes? Is it succeeding?
> What are
> the problems you've had?

Like Josh, we have been following our own "home-brewed" version of
Agile development for that past year. We are a young company, so this
was the plan from the beginning.

We work in short (1-2 week) iterations. Deliverables may include task
flows, wireframes, a prototype, and new functionality added to the
working product. The project typically starts with an iteration zero,
where we (usually the designer and project lead) do things like
gather requirements, identify goals, document ideas, and outline the
first "chunk" of functionality (goals, and activities that support
those goals). The next iteration, or series of iterations, is focused
on that particular chunk. I usually try to work 1-2 iterations ahead
of development.

Our team is small, so we all sit in one big room. I interact with the
developers daily, and with clients daily to weekly (depending on the
project). We like to approach projects as a collaborative activity,
and when our clients are local, we have regular in person meetings.

My biggest problem is staying far enough ahead of the development
team to allow enough time for feedback and refinement. Also, because
requirements may change at any time, one small change may impact a
number of design decisions, and I don't always have enough time
available to go back and reevaluate. So yeah, I guess my biggest
problem is timing. The development team may only need a few days to
implement something that took several weeks to design, so finding a
good balance there can be tricky.

My other gripe about Agile is agile developers. ;-) Not all of them
are bad, and most of them are *excellent* developers. It's just that
some of the agile developers that I have worked with are very vocally
against *any* sort of upfront design (see this blog post written by
my business partner: http://www.robbyonrails.com/articles/2006/08/30/
agile-interaction-design), and so find my work to be pointless ("I
could have done that"). My work has been called waterfall one too
many times. :-P

--
Allison Beckwith
Co-Founder & Creative Director

PLANET ARGON, LLC
Ruby on Rails Development, Consulting & Hosting

www.planetargon.com

+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4968 [fax]

12 Feb 2007 - 8:37pm
Daniel Williams
2005

>My biggest problem is staying far enough ahead of the development
>team to allow enough time for feedback and refinement.

I guess purists could argue this isn't agile and is possibly mini waterfall,
but maybe that's another conversation

On 2/13/07, Allison Beckwith <allison at planetargon.com> wrote:
>
> On Feb 12, 2007, at 3:08 PM, Robert Hoekman, Jr. wrote:
>
> > Anyone doing IxD work in an agile programming environment? If so,
> > what are
> > you doing to make it work with agile processes? Is it succeeding?
> > What are
> > the problems you've had?
>
> Like Josh, we have been following our own "home-brewed" version of
> Agile development for that past year. We are a young company, so this
> was the plan from the beginning.
>
> We work in short (1-2 week) iterations. Deliverables may include task
> flows, wireframes, a prototype, and new functionality added to the
> working product. The project typically starts with an iteration zero,
> where we (usually the designer and project lead) do things like
> gather requirements, identify goals, document ideas, and outline the
> first "chunk" of functionality (goals, and activities that support
> those goals). The next iteration, or series of iterations, is focused
> on that particular chunk. I usually try to work 1-2 iterations ahead
> of development.
>
> Our team is small, so we all sit in one big room. I interact with the
> developers daily, and with clients daily to weekly (depending on the
> project). We like to approach projects as a collaborative activity,
> and when our clients are local, we have regular in person meetings.
>
> My biggest problem is staying far enough ahead of the development
> team to allow enough time for feedback and refinement. Also, because
> requirements may change at any time, one small change may impact a
> number of design decisions, and I don't always have enough time
> available to go back and reevaluate. So yeah, I guess my biggest
> problem is timing. The development team may only need a few days to
> implement something that took several weeks to design, so finding a
> good balance there can be tricky.
>
> My other gripe about Agile is agile developers. ;-) Not all of them
> are bad, and most of them are *excellent* developers. It's just that
> some of the agile developers that I have worked with are very vocally
> against *any* sort of upfront design (see this blog post written by
> my business partner: http://www.robbyonrails.com/articles/2006/08/30/
> agile-interaction-design), and so find my work to be pointless ("I
> could have done that"). My work has been called waterfall one too
> many times. :-P
>
>
> --
> Allison Beckwith
> Co-Founder & Creative Director
>
> PLANET ARGON, LLC
> Ruby on Rails Development, Consulting & Hosting
>
> www.planetargon.com
>
> +1 503 445 2457
> +1 877 55 ARGON [toll free]
> +1 815 642 4968 [fax]
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

13 Feb 2007 - 3:16am
niklasw
2005

What is your take on agile programming from a steps-in-a-process pov?
Does it fit within the standard Inititate -> Design -> Build -> Test
-> 'Ship' development project model? Or is that what you would
consider being a classic waterfall?

I'm not sure I've worked in an agile environment but would love to
involve the developers I work with earlier in the process. Is agile
the way to go then? Does anyone have any tips or experiences on
introducing it coming from IxD?

--Niklas

PS
Does anyone remember Concurrent engineering from back in the 90's (or
was it earlier)? I believe the term came from the way Japanese car
manufacturers re-invented the development process of creating new
cars... from waterfall to parallel... Where I worked back then I tried
to coin the expression Concurrent design.
DS

On 2/13/07, Dan Williams <dgwillia at googlemail.com> wrote:
> >My biggest problem is staying far enough ahead of the development
> >team to allow enough time for feedback and refinement.
>
> I guess purists could argue this isn't agile and is possibly mini waterfall,
> but maybe that's another conversation
>
>
> On 2/13/07, Allison Beckwith <allison at planetargon.com> wrote:
> >
> > On Feb 12, 2007, at 3:08 PM, Robert Hoekman, Jr. wrote:
> >
> > > Anyone doing IxD work in an agile programming environment? If so,
> > > what are
> > > you doing to make it work with agile processes? Is it succeeding?
> > > What are
> > > the problems you've had?
> >
> > Like Josh, we have been following our own "home-brewed" version of
> > Agile development for that past year. We are a young company, so this
> > was the plan from the beginning.
> >
> > We work in short (1-2 week) iterations. Deliverables may include task
> > flows, wireframes, a prototype, and new functionality added to the
> > working product. The project typically starts with an iteration zero,
> > where we (usually the designer and project lead) do things like
> > gather requirements, identify goals, document ideas, and outline the
> > first "chunk" of functionality (goals, and activities that support
> > those goals). The next iteration, or series of iterations, is focused
> > on that particular chunk. I usually try to work 1-2 iterations ahead
> > of development.
> >
> > Our team is small, so we all sit in one big room. I interact with the
> > developers daily, and with clients daily to weekly (depending on the
> > project). We like to approach projects as a collaborative activity,
> > and when our clients are local, we have regular in person meetings.
> >
> > My biggest problem is staying far enough ahead of the development
> > team to allow enough time for feedback and refinement. Also, because
> > requirements may change at any time, one small change may impact a
> > number of design decisions, and I don't always have enough time
> > available to go back and reevaluate. So yeah, I guess my biggest
> > problem is timing. The development team may only need a few days to
> > implement something that took several weeks to design, so finding a
> > good balance there can be tricky.
> >
> > My other gripe about Agile is agile developers. ;-) Not all of them
> > are bad, and most of them are *excellent* developers. It's just that
> > some of the agile developers that I have worked with are very vocally
> > against *any* sort of upfront design (see this blog post written by
> > my business partner: http://www.robbyonrails.com/articles/2006/08/30/
> > agile-interaction-design), and so find my work to be pointless ("I
> > could have done that"). My work has been called waterfall one too
> > many times. :-P
> >
> >
> > --
> > Allison Beckwith
> > Co-Founder & Creative Director
> >
> > PLANET ARGON, LLC
> > Ruby on Rails Development, Consulting & Hosting
> >
> > www.planetargon.com
> >
> > +1 503 445 2457
> > +1 877 55 ARGON [toll free]
> > +1 815 642 4968 [fax]
> >
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

13 Feb 2007 - 9:59am
jrrogan
2005

I've worked on several "Agile/XP/Scrum/FDD/{Insert latest greatest Rapid
Iterative Developemnt methodology acronym here}" projects. In all of them
there seem to be common themes which this thread has identified.

After upfront "User/Role/Domain" research, my experience is that "Purist
Agile Anything" has never been done on my projects, (although a few times
the team tried really hard to remain true to this or that Agile Vision).
Also UCD is not well thought out in Agile processes, as Agile seems to be
pretty much a "Development Centric (Only)" methodology, giving engineers
what they need, (or think they need), to get the project done.

Here's my general take on almost all Agile projects I've worked on from a UI
design perspective, I'm curious if others experiences delta off mine, how
and where and to what degree of success:

- Work with Roadmap creation/prioritization,

- Create UI standards - look and feel style guide

- Decide what low fidelity deliverables will be used, (visio flows or visio
flows)

- Decide what high fidelity design deliverables will be used to support
project, (is it a prototype or annotated screen shot? both have their +'s
and -'s)

- Design stays ahead of development,
(if this is mini waterfall, who cares, is design supposed to be behind dev,
then refactored in?)

- Iterate, sort of - with some sort of "user group/advocate/imagine you know
who this user is/etc"
(Seems more to be breaking problem space into descrete parts which can be
developed in short cycles. Wouldn't true iteration involve redesigning these
parts again and again making them better and better with each
iteration? This can happen, ecspecially at the begining of projects, or when
tackling new and differnet functionality. Recooking the same UI
functionality again and again as a technique seems to indicate that the
design team is very novice, or didn't get the style guide right.),
(Let me backtrack, actual project pieces often do have lots of iterations,
mainly because of scope increases or negotiating out functionality due to
the grim prospects of resource reality)

- Voila the project is done and is a great success!

- Oh and QA takes design deliverables, which are constantly iterated upon,
(sometimes for project to pass QA - I never said that ;), and uses them as
test case artifacts, dope this isn't Agile either, but it's the only way
I've seen it done, (sure there's Unit Testing, but has anyone worked with a
large project where a formalized QA process wan't used???

13 Feb 2007 - 12:06pm
Robert Hoekman, Jr.
2005

> Does it fit within the standard Inititate -> Design -> Build -> Test
> -> 'Ship' development project model? Or is that what you would
> consider being a classic waterfall?

>From my understanding, it's only a classic waterfall if each step in the
process has to be completely finished before starting the next one (often
true when different groups handle each step). Agile techniques involve a lot
of overlap and on-the-spot collaboration. They work in iterations - often
2-3 weeks (give or take) and nothing is planned beyond the next iteration,
making the team very flexible to focus on what's really important at any
given moment rather than a grand plan that doesn't allow for changes. The
focus is collaboration over documentation, and flexibility over planning.
It's all about speed as well, hence the term "agile".

-r-

13 Feb 2007 - 12:31pm
.pauric
2006

I've been using what I'm calling an Agile Based web development program with
external vendors for about 8 programs now. Points to note;

I work with a standardised UI that is reused at a styleguide level on the
company's roadmap.
I keep the UI mockup code inhouse and NDA to vendors at the start of new
programs.
New features are iterated within the shelf mockup structure in an Agile
based fashion over the program, existing standardised core functionality is
re-used.

So, the mockup code starts its life on a traditional development path but
once its stable & mature it then goes agile. I feed developers with
rendered wireframes and have them commit to a drop about once a week
depending on the complexity, feedback is either via another wireframe or
text if the change request is small. Conf calls if there's any
misunderstanding.

User testing is done by running the mockup from an inhouse webserver and
having GSO and PQE review. On all of the 8 programs we've only had one user
generated enhancement request after shipdate.

As an aside, if I may blow my own trumpet, I was a finalist for Innovator of
the year with this program, losing out to some seriously funky tech: <
http://www.3com.com/osn/infrastructure_overview.html>

Here's a very high level overview of the workflow
<http://web.mac.com/pauric_ocallaghan/web_design_process.jpg>

Again, its agile -based-, its hard to see a major UI development inside
agile from my perspective.

13 Feb 2007 - 1:15pm
Teresa Torres
2006

I currently work in an Agile environment. I'm fairly new to it, but
am really enjoying it. We work with a 2 week sprint cycle. The
product team (which UED is a part of), has a high-level concept (we
call them themes) of what will be worked on two sprints out and is
defining and writing user stories for one sprint out. As the UED
resource, I try to do UED research for the upcoming themes that are
two sprints out and actual design work for the stories for the next
sprint. By the time engineers start building, the stories are
designed and tested, so engineers can build with confidence.

I have definitely had to learn to work in a compressed product cycle.
I don't have the luxury of spending a couple of weeks to do user
research before a big project starts. Instead I have to figure out
how to do UED research for a day or two for the next couple of weeks
worth of work. I have found that it's a lot easier to get buy-in on
research time when it's in smaller chunks and has immediate impact.
But it is definitely redefining my definition of guerrilla UED tactics.

Since Agile environments force your team to collaborate far more
often then in a waterfall approach, I have found it to be a lot
easier to integrate UED into the whole process. I find that in more
traditional approaches, UED documents get created and ignored or
research gets put off as too time-consuming. I'm sure everyone here
has seen their research or validation time compressed due to a late
project. I am finding this happens far less often in an agile
environment, as long as I am willing to adapt my approach. I find
myself doing more UED work and less evangelism than in any of my
prior positions.

Instead of creating a ton of documentation, I disseminate my
knowledge to the whole team as we build. We do use personas and
scenarios, but we don't use a lot of other traditional UED
deliverables. I rarely create site maps or process flows - they would
just be out of date after two weeks. I haven't written a behavioral
spec since I started here. But I do help write user stories and my
mockups definitely add constraints to existing user stories.

Instead of writing formal usability reports, I maintain a design
library where I include before and after screenshots, list design
notes which include any validation metrics or usability findings that
either influenced the change or supported not making a change. This
is all done on our corporate wiki and is nothing like formal documents.

It's definitely required a lot of flexibility, but I see it paying
off. I'm an integrated part of the product cycle, not just a resource
that allows our company to say we have a user-centered design
process. I'm a big fan so far.

Teresa

13 Feb 2007 - 1:32pm
Robert Hoekman, Jr.
2005

Very nice insights - thanks for the thorough explanation. Oh, and kudos. :)

-r-

On 2/13/07, Teresa Torres <ttorres at stanfordalumni.org> wrote:
>
>
> I currently work in an Agile environment. I'm fairly new to it, but
> am really enjoying it. We work with a 2 week sprint cycle. The
> product team (which UED is a part of), has a high-level concept (we
> call them themes) of what will be worked on two sprints out and is
> defining and writing user stories for one sprint out. As the UED
> resource, I try to do UED research for the upcoming themes that are
> two sprints out and actual design work for the stories for the next
> sprint. By the time engineers start building, the stories are
> designed and tested, so engineers can build with confidence.
>
> I have definitely had to learn to work in a compressed product cycle.
> I don't have the luxury of spending a couple of weeks to do user
> research before a big project starts. Instead I have to figure out
> how to do UED research for a day or two for the next couple of weeks
> worth of work. I have found that it's a lot easier to get buy-in on
> research time when it's in smaller chunks and has immediate impact.
> But it is definitely redefining my definition of guerrilla UED tactics.
>
> Since Agile environments force your team to collaborate far more
> often then in a waterfall approach, I have found it to be a lot
> easier to integrate UED into the whole process. I find that in more
> traditional approaches, UED documents get created and ignored or
> research gets put off as too time-consuming. I'm sure everyone here
> has seen their research or validation time compressed due to a late
> project. I am finding this happens far less often in an agile
> environment, as long as I am willing to adapt my approach. I find
> myself doing more UED work and less evangelism than in any of my
> prior positions.
>
> Instead of creating a ton of documentation, I disseminate my
> knowledge to the whole team as we build. We do use personas and
> scenarios, but we don't use a lot of other traditional UED
> deliverables. I rarely create site maps or process flows - they would
> just be out of date after two weeks. I haven't written a behavioral
> spec since I started here. But I do help write user stories and my
> mockups definitely add constraints to existing user stories.
>
> Instead of writing formal usability reports, I maintain a design
> library where I include before and after screenshots, list design
> notes which include any validation metrics or usability findings that
> either influenced the change or supported not making a change. This
> is all done on our corporate wiki and is nothing like formal documents.
>
> It's definitely required a lot of flexibility, but I see it paying
> off. I'm an integrated part of the product cycle, not just a resource
> that allows our company to say we have a user-centered design
> process. I'm a big fan so far.
>
> Teresa
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

13 Feb 2007 - 1:44pm
John Schrag
2005

Terea Torres wrote:
> I currently work in an Agile environment. I'm fairly new to it, but am
> really enjoying it. We work with a 2 week sprint cycle...

Great explanation, Teresa. When Agile was first rolled out at my
company (Alias, now a part of Autodesk) we had to scramble to figure out
how to make our usability and design practices fit in. And we ended up
with something very similar to what you describe. We've presented on
our process a few times; there's a very short presentation by my boss
Lynn Miller that you can access on-line. It's a concise description of
how we made Agile UCD work at Alias:

<http://www.usabilitycamp.org/WUD2006_UCDandAgile_lmiller.pdf>

Actually, if you just Google "Lynn Miller Agile" you can also find some
other reports from panels and podcasts.

-john

John Schrag
Interaction Designer
Autodesk, Toronto

14 Feb 2007 - 5:46am
Adrian Howard
2005

On 13 Feb 2007, at 08:16, Niklas Wolkert wrote:
[snip]
> PS
> Does anyone remember Concurrent engineering from back in the 90's (or
> was it earlier)? I believe the term came from the way Japanese car
> manufacturers re-invented the development process of creating new
> cars... from waterfall to parallel... Where I worked back then I tried
> to coin the expression Concurrent design.
> DS
[snip]

The CE stuff has a lot in common with Lean Manufacturing and the
Toyota Production System (same focus on continuous improvement, same
focus on communication and collaboration).

There's a great deal in common between lean and agile approaches to
software development. If you're interested I'd recommend taking a
look at the Poppendieck's work <http://www.poppendieck.com/>.

Cheers,

Adrian

14 Feb 2007 - 5:50am
Adrian Howard
2005

On 13 Feb 2007, at 18:44, John Schrag wrote:
[snip]
> Actually, if you just Google "Lynn Miller Agile" you can also find
> some
> other reports from panels and podcasts.
[snip]

Indeed. There's a nice UCD Round Table discussion with Lynn Miller,
Jeff Patton and Rebecca Wirfs-Brock you can listen to on the Agile
Toolkit podcast at <http://agiletoolkit.libsyn.com/index.php?
post_id=15584>

Cheers,

Adrian

14 Feb 2007 - 5:59am
Adrian Howard
2005

On 13 Feb 2007, at 17:06, Robert Hoekman, Jr. wrote:
[snip]
> Agile techniques involve a lot
> of overlap and on-the-spot collaboration. They work in iterations -
> often
> 2-3 weeks (give or take) and nothing is planned beyond the next
> iteration,
[snip]

I think it would be slightly more accurate to say that agile methods
only plan the future in just enough detail to make progress. They
certainly do plan beyond the current iteration :-)

For example in XP you will normally have a release plan that covers
many iterations and will be revised at the start of every iteration.
The estimates for the immediate iterations are likely to be pretty
comprehensive and accurate. The estimates for future iterations are
likely to be very rough.

Cheers,

Adrian

14 Feb 2007 - 6:09am
Adrian Howard
2005

On 13 Feb 2007, at 14:59, Rich Rogan wrote:
[snip]
> After upfront "User/Role/Domain" research, my experience is that
> "Purist
> Agile Anything" has never been done on my projects, (although a few
> times
> the team tried really hard to remain true to this or that Agile
> Vision).
> Also UCD is not well thought out in Agile processes, as Agile seems
> to be
> pretty much a "Development Centric (Only)" methodology, giving
> engineers
> what they need, (or think they need), to get the project done.
[snip]

I haven't found agile methods to be developer centric. More of a case
of rebalancing things so that the developers are involved with the
product development at an appropriate level.

I'd classify the problems I've encountered as more with having a
process that's too "customer" focussed. With the stake holders
driving the process and missing some of the benefits a more user-
centred approach can give.

Cheers,

Adrian

14 Feb 2007 - 11:08am
Jack Skates
2006

Hi Everyone,

Coming out of lurker mode... I wanted to share some thoughts on this.

I think "Agile" like any method should be considered a framework that you
customize based on the constraints and opportunities of the project you're
considering it for.

That said, I recently proposed a method for a project that leverages some
aspects of "Agile", but doesn't follow it to the letter of official defined
process. In our approach we proposed a traditional discovery and definition
phase, then followed it with a sort of "setup" phase where would explore the
overarching IA and interaction patterns that could be applied across
multiple features. This meant things like forms, search, navigation, methods
for tagging, etc... There would also be a traditional graphic design phase
in where you did the explorations, mood boards, comps and then applying the
design across several represented screens.

>From that point, we broke the rest of the design work into 8 stories
(scenarios, high level feature sets, whatever you want to call them). We
then sequenced the 8 stories based on priority and some other factors. Then,
we decided to have 2 teams running simultaneously which included an IA,
Graphic Designer and two developers. One team was focused on re-designing
the core product, while the other team focused on new and significant
changes. This insured that the work of the new and unknown was not slowing
down the work of the baseline features of the product.

Each developed story would be approached through some traditional
wireframing, but with the entire team and mostly on whiteboards. We would
use digital photos of whiteboards as a way of capturing and sharing our work
with the clients. We then would then extend the visual design, the
developers would code the templates for that story and we would test the
actual code with users using some dummy server side code to simulate the
real thing. Any AJAX used would be part of the code and the test. Then we
would iterate based on the findings.

Now of course there's a concern about integration and consistency so we
proposed dealing with that in two ways. First, the entire team would be
working together in one big room and my experience has taught me that
"osmosis" tends to fix a lot of that. The other idea is to have an
integration phase at the end to pull things together.

Some of the big advantages to this method....
- Ability to actually have more time for design since you're handing off
code to backend developers way up front vs. the end of the project
- A lot more opportunity to interact with users and do user testing
- Less time developing prototypes and using that time to build something
more real and usable
- Much more collaborative with the entire team
- Clients get to see real stuff much sooner
- If scope or requirements change along the project (like they do), it's
much easier to react to and accomodate

So far, feedback has been on all sides...

"This is so different than what we're use to... I'm not sure we are set up
to do this"

"There's so many positives that it's worth giving serious consideration"

"It's risky for the firm because there's more hard dates, more often so less
room slowing down and speeding up"

"It's low risk for the client since there's more flexibility and they are
getting tangible deliverables much sooner in the project"

Definitely curious to hear your thoughts. I realize people will have a lot
of questions, but for confidentiality reasons... I can't discuss results yet
and can't go into the specific details of the project... But more than happy
to talk about this at an theoretic/conceptual level.

Jack Skates

-----Original Message-----
From: Adrian Howard [mailto:adrianh at quietstars.com]
Sent: Wednesday, February 14, 2007 3:09 AM
To: discuss Discuss
Subject: Re: [IxDA Discuss] IxD in agile environments

On 13 Feb 2007, at 14:59, Rich Rogan wrote:
[snip]
> After upfront "User/Role/Domain" research, my experience is that
> "Purist Agile Anything" has never been done on my projects, (although
> a few times the team tried really hard to remain true to this or that
> Agile Vision).
> Also UCD is not well thought out in Agile processes, as Agile seems to
> be pretty much a "Development Centric (Only)" methodology, giving
> engineers what they need, (or think they need), to get the project
> done.
[snip]

I haven't found agile methods to be developer centric. More of a case of
rebalancing things so that the developers are involved with the product
development at an appropriate level.

I'd classify the problems I've encountered as more with having a process
that's too "customer" focussed. With the stake holders driving the process
and missing some of the benefits a more user- centred approach can give.

Cheers,

Adrian
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines ............
http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

14 Feb 2007 - 11:32am
Josh
2006

Earlier I mentioned that we use a home-brewed version of Agile development
processes, and I'm not sure if I explained what that actually means. We've
found that Agile works really well with our developers and creative teams,
but that it's not always sufficient for our clients.

They do enjoy the quick turnaround time and the constant progress, but some
clients NEED documentation and waterfall-like processes. In many cases they
prefer the "measure twice cut once" approach as opposed to an iterative
approach where the focus is on communication and engagement not
documentation. Agile development makes managing client expectations and
getting client approval a little bit more difficult. So we dev Agile in
house, but when doing client engagements we tend to break our process into
waterfall-like phases with deliverables for sign off.

Our choice of Ruby on Rails for Web development has played a significant
role. In most of our recent work, the creative has actually taken just as
much or more time than the development. This allows our developers to do
multiple iterations in a similar amount of time it takes for a client to
approve the creative.

- Josh Viney

14 Feb 2007 - 6:48pm
Allison Beckwith
2006

On Feb 14, 2007, at 8:32 AM, Josh Viney wrote:

> They do enjoy the quick turnaround time and the constant progress,
> but some
> clients NEED documentation and waterfall-like processes. In many
> cases they
> prefer the "measure twice cut once" approach as opposed to an
> iterative
> approach where the focus is on communication and engagement not
> documentation. Agile development makes managing client expectations
> and
> getting client approval a little bit more difficult. So we dev
> Agile in
> house, but when doing client engagements we tend to break our
> process into
> waterfall-like phases with deliverables for sign off.

We get a lot of push back from our clients as well, which is where
the dialogue driven development (though I like saying dialogue driven
design too) project came from. You can read more here: http://
www.dialogue-driven.org

>
> Our choice of Ruby on Rails for Web development has played a
> significant
> role. In most of our recent work, the creative has actually taken
> just as
> much or more time than the development. This allows our developers
> to do
> multiple iterations in a similar amount of time it takes for a
> client to
> approve the creative.

We also use Ruby on Rails and I would say the same thing. Design is
taking just as much (or more) time than development, which is why my
biggest problem seems to be timing. If I am only one iteration ahead
of development, and end up needing more time, the dev team may get
held up.

-Allison

--
Allison Beckwith
Co-Founder & Creative Director

PLANET ARGON, LLC
Ruby on Rails Development, Consulting & Hosting

www.planetargon.com

+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4968 [fax]

15 Feb 2007 - 3:08am
stauciuc
2006

Does this mean you also play the role of the Product Owner in Scrum? Or you
together with the BA? Or there is actually another person playing PO but
makes decisions based mostly on your input?

I ask because I'm trying to understand how IxD best fits in Scrum.

On 2/13/07, Dan Williams <dgwillia at googlemail.com> wrote:

>
> The hardest thing to let go was the ownership of the business design, this
> is now shared across the entire team! However I had the advantage of
> starting a sprint ahead of the tech team, so this allowed me to gather the
> requirements, understand the users and their needs, create persona's,
> develop a product backlog based upon user stories and think about the
> vision
> etc etc.
>
>
>

--
Sergiu Sebastian Tauciuc
http://www.sergiutauciuc.ro/en/

15 Feb 2007 - 4:07am
Håkan Reis
2006

I think that much of the problem lies in the assumption that you only
discuss at the interfaces - product owner/developer, product
owner/business analyst, etc. It's a collaborate thing, the product
owner role will not be just interface to interaction designers or
business analys, the product owner has to be a part of the team, get
input from all parts and make decisions regarding priority based on
that interaction.

The main advantage here is that the interaction will have an impact on
what goes in first and (hopefully) what solves the users problem not
the "customer" problem. I even suggest refactoring the agile manifesto
for this focus shift to take place.
(http://blog.reis.se/2006/11/28/refactoring-the-agile-manifesto/)

As for the Dan Williams comment "However I had the advantage of
starting a sprint ahead of the tech team" I think this is one of the
crucial part in getting IxDA into the agile process. You really have
to stay one step ahead of the development team. In that case its still
design up front, but its small design up front, not big...

////
Håkan Reis
Dotway AB
http://blog.reis.se

15 Feb 2007 - 7:37am
Dave Malouf
2005

The way our design team dealt with agile was to use an agile planning
style ourselves.

1. Start ahead of development. - in our case we were able to begin
before development really got engaged because of the nature of the
lifecycles of our products

2. work in parallel with engineering research efforts. This project
was a complete shift in architecture and technology for our
application so there were many upfront things that the engineering
team had to do and that afforded us the opportunity to do research and
design in parallel to their early Proof of Concept, technology
research, education and architecting.

3. Yes, when working with a large scale project like this there are
upfront architectural decisions that engineering had to make. I
realize this is counter to many agile practices, but the alternative
is building a plane while it is flying. There was iteration through
engineering the architecture of the application system which played
off of both engineering POCs and design research.

4. The Design team do their planning and process in iterations as
well. They look something like this. (Iterations are 2 weeks)

i1. create research plan, work with prod mgnt on early sketches to
help them communicate early visiion. These sketches were necessary to
communicate core value ideas to the x-functional team. End result:
approval for plan, selection of outside recruitment resource if deemed
necessary (experience told us it would be); solidify timelines with
other internal resources, book travel).

Dev is researching architectural components such as OS, databases,
development environments and supporting technology specific to our
applications.

i2. sketchup: work through 3-5 different sketch models of the
application. No more than 10 screen types in each sketch model.
Evaluate the sketches, reduce to 2 and present to team to gain
feedback.

Dev in continuing their research takes the sketches as uses them as
"requirements" to build POCs around questionable technologies.

i3. framework: using 2 create a framework and language model.(These
will be used for customer feedback during research sessions).

Dev: Costing and refactoring of technology decisions and more POCs

i4. Research pt. 1 - out in field; visual language development.
(During the research phase a visual design in parallel can begin
thinking about visual language for the application: heirarchy,
iconography, text, brand sketching out 2 examples.

Dev: Works with design in understanding object model, navigation
structure and impact on development. more POCs are looked into

i5 Research pt 2 - out in the field; Research evaluation, Visual
language evaluation

Dev: Begins creating core sections based on priorities of requirements
created by Prod Mngt. using early frameworks as a guide post. These
sections are mostly back-end in nature, but require front-end
components to present to outside world as "working"

i6 Bringing it home: refine the framework by overlaying the visual
language - work with development on final object model of application,
and technical feasibility evaluation through prototyping.

Dev: continuing with backend development

i7-8: Design creates specification (notice this is 2 revs)

Dev: continues with backend development

i9 >: Dev has design specification and works with design to begin
building out front-end components in parallel with back-end components

Design: iterates design at granular level in coordination with
engineering to fit implementation "realities".

Ok this goes on and on and I realize a lot of this only works with a
large scale project. but some of this is real in almost all projecs.
If you can make design happen during engineering planning and
architecture periods, or get out ahead of dev when prod lifecycles
afford it then it all comes together. What helps is actually doign
your project planning in these types of iteration cycles yourself. it
gives you "credibility", but also keeps everyone flowing at a similar
pace. I would even ask PMs to do the same thing with their
requirements and goal documents so that everyone is using a similar
system during the PLC.

is anyone using Agile in a consulting/agency setting? Is anyone using
Agile methods other than iteration. Pair-designing?

-- dave

15 Feb 2007 - 9:25am
Adrian Howard
2005

On 14 Feb 2007, at 16:08, Jack Skates wrote:

> Hi Everyone,
>
> Coming out of lurker mode... I wanted to share some thoughts on this.

Welcome :-)

> I think "Agile" like any method should be considered a framework
> that you
> customize based on the constraints and opportunities of the project
> you're
> considering it for.

Of course you can only customise it so far and it still stay "agile".
Sometimes I think people spend to much effort trying to adapt to
constraints and opportunities, and not enough effort on trying to
adapt the constraints and opportunities to enable them to build a
good product.

> That said, I recently proposed a method for a project that
> leverages some
> aspects of "Agile", but doesn't follow it to the letter of official
> defined
> process. In our approach we proposed a traditional discovery and
> definition
> phase, then followed it with a sort of "setup" phase where would
> explore the
> overarching IA and interaction patterns that could be applied across
> multiple features. This meant things like forms, search,
> navigation, methods
> for tagging, etc... There would also be a traditional graphic
> design phase
> in where you did the explorations, mood boards, comps and then
> applying the
> design across several represented screens.

That's cool. Personally I tend to do the detail graphic design work
later on in the process after we've gone some of the initial
functionality up and running.

> From that point, we broke the rest of the design work into 8 stories
> (scenarios, high level feature sets, whatever you want to call
> them). We
> then sequenced the 8 stories based on priority and some other
> factors. Then,
> we decided to have 2 teams running simultaneously which included an
> IA,
> Graphic Designer and two developers. One team was focused on re-
> designing
> the core product, while the other team focused on new and significant
> changes. This insured that the work of the new and unknown was not
> slowing
> down the work of the baseline features of the product.

Sounds like your stories are pretty high level? (since there are only
eight) or is it quite a simple application?

Personally I tend to take stories down to quite a low level so that a
story would typically take a pair of developers 0.5-1 day to
implement. Interestingly enough stories of this size seem to very
naturally fit into the "sub-task" level of task analysis diagrams,
which gives a handy way to track things.

I find keeping the stories at a smaller scale since it's easier to
track progress in small chunks of story-done/not-done vs. the never
ending "we're 80% finished". Developer estimates for the smaller
chunks of work also tend to be considerably more accurate.

> Each developed story would be approached through some traditional
> wireframing, but with the entire team and mostly on whiteboards. We
> would
> use digital photos of whiteboards as a way of capturing and sharing
> our work
> with the clients.

Ah. Digital camera's and whiteboards - a match made in heaven! Sadly
I think I have more photo's of whiteboards in iPhoto than I do of my
partner :-)

> We then would then extend the visual design, the
> developers would code the templates for that story and we would
> test the
> actual code with users using some dummy server side code to
> simulate the
> real thing. Any AJAX used would be part of the code and the test.
> Then we
> would iterate based on the findings.

Rather than try and produce some dummy code to simulate the real
thing, we try and produce a simple version of the real thing. That we
we can take the code forward rather than spending time throwing
prototypes away. We try and order our stories so that we get
something working end-to-end as quickly as possible and build it up
from there.

> Now of course there's a concern about integration and consistency
> so we
> proposed dealing with that in two ways. First, the entire team
> would be
> working together in one big room and my experience has taught me that
> "osmosis" tends to fix a lot of that. The other idea is to have an
> integration phase at the end to pull things together.

The team room seems to solve most of these problems in my experience.
Brief (10-15m) daily morning meetings of the whole team are also
useful to monitor progress and spot problems before they get serious

> Some of the big advantages to this method....
> - Ability to actually have more time for design since you're
> handing off
> code to backend developers way up front vs. the end of the project
> - A lot more opportunity to interact with users and do user testing
> - Less time developing prototypes and using that time to build
> something
> more real and usable
> - Much more collaborative with the entire team
> - Clients get to see real stuff much sooner
> - If scope or requirements change along the project (like they
> do), it's
> much easier to react to and accomodate

Sounds good.

[snip]
> "It's risky for the firm because there's more hard dates, more
> often so less
> room slowing down and speeding up"
[snip]

That's curious. In my experience people usually see this as an
advantage. Having lots of mini-milestones allows management to get a
much more accurate idea of how the project is progressing.

Of course sometimes the news may be unwelcome (it's running late),
but generally I find people are mature enough to realise that it's
better to get the bad news earlier than later.

> Definitely curious to hear your thoughts.
[snip]

Sounds good :-)

If you've not done so already I'd take a look at Lynn Miller's work
(e.g. <http://www.usabilitycamp.org/
WUD2006_UCDandAgile_lmiller.pdf>). Sound's like you're doing fairly
similar stuff.

Cheers,

Adrian

15 Feb 2007 - 9:43am
Mark Schraad
2006

Jack,

Also check out some of the papers published on the agile alliance web
site - they have been helpful to me in the last few months. Jeff
Patton and Larry Constantine detail their experience attempting it
integrate user experience in the agile process. Some read like
recipes (which is dangerous for the reader) but the detail is
interesting. Both are thin in the information gathering area. Also,
Larry has an interesting take on design and UCD in his 2004 paper.

Mark

On Feb 15, 2007, at 9:25 AM, Adrian Howard wrote:

>
> On 14 Feb 2007, at 16:08, Jack Skates wrote:
>
>> Hi Everyone,
>>
>> Coming out of lurker mode... I wanted to share some thoughts on this.
>
> Welcome :-)
...

...
>
>> Definitely curious to hear your thoughts.
> [snip]
>
> Sounds good :-)
>
> If you've not done so already I'd take a look at Lynn Miller's work
> (e.g. <http://www.usabilitycamp.org/
> WUD2006_UCDandAgile_lmiller.pdf>). Sound's like you're doing fairly
> similar stuff.
>
> Cheers,
>
> Adrian
>

15 Feb 2007 - 9:44am
Adrian Howard
2005

On 14 Feb 2007, at 16:32, Josh Viney wrote:

> Earlier I mentioned that we use a home-brewed version of Agile
> development
> processes, and I'm not sure if I explained what that actually
> means. We've
> found that Agile works really well with our developers and creative
> teams,
> but that it's not always sufficient for our clients.
>
> They do enjoy the quick turnaround time and the constant progress,
> but some
> clients NEED documentation and waterfall-like processes.
[snip]

Just to quick note to quash the myth that agile processes are anti-
documentation. They're not. They're against _unnecessary_
documentation, especially when talking to the person on the desk next
to you is vastly more effective ;-)

If the customer needs or wants documentation, you give them
documentation.

> In many cases they
> prefer the "measure twice cut once" approach as opposed to an
> iterative
> approach where the focus is on communication and engagement not
> documentation. Agile development makes managing client expectations
> and
> getting client approval a little bit more difficult.

Can you say a little on why you find agile makes managing client
expectations more difficult? I find the opposite since they get a
transparent view of the projects progress.

> So we dev Agile in
> house, but when doing client engagements we tend to break our
> process into
> waterfall-like phases with deliverables for sign off.

I think that it's a fairly common practice to have agile processes
hiding behind a waterfall-ish facade. I've certainly done it :-)

However I usually find the extra communication overhead is obvious
enough that we can move them over to a more agile viewpoint by the
end of the project.

> Our choice of Ruby on Rails for Web development has played a
> significant
> role. In most of our recent work, the creative has actually taken
> just as
> much or more time than the development. This allows our developers
> to do
> multiple iterations in a similar amount of time it takes for a
> client to
> approve the creative.

That's been my experience too (although we tend to use Perl based
frameworks rather than Ruby for web apps at the moment).

Cheers,

Adrian

15 Feb 2007 - 9:55am
Adrian Howard
2005

On 15 Feb 2007, at 12:37, David Malouf wrote:
[snip]
> is anyone using Agile in a consulting/agency setting? Is anyone using
> Agile methods other than iteration. Pair-designing?
[snip]

Yup. Seeing this more and more. Especially pairs with different
primary skills (e.g. gfx-ia, usability-developer, usability-support,
etc.)

It's very effective in my experience. For example I once worked with
a gfx designer who managed to spot a problem that was causing a 75%
failure rate on a form just by shifting the underlining of a heading
so it didn't draw the users attention to the wrong part of the form.

I'm sure we'd have figured it out in the end... but..

Cheers,

Adrian

15 Feb 2007 - 10:32am
Jack Skates
2006

Forgot that "reply all" button... Doh!

-----Original Message-----
From: Adrian Howard [mailto:adrianh at quietstars.com]
Sent: Thursday, February 15, 2007 6:26 AM
To: discuss Discuss
Subject: Re: [IxDA Discuss] IxD in agile environments

On 14 Feb 2007, at 16:08, Jack Skates wrote:

> Hi Everyone,
>
> Coming out of lurker mode... I wanted to share some thoughts on this.

Welcome :-)

> I think "Agile" like any method should be considered a framework that
> you customize based on the constraints and opportunities of the
> project you're considering it for.

Of course you can only customise it so far and it still stay "agile".
Sometimes I think people spend to much effort trying to adapt to
constraints and opportunities, and not enough effort on trying to adapt the
constraints and opportunities to enable them to build a good product.

>> Since I work for a firm that services clients... A lot of the constraints
are fixed by the client which make them harder to adapt vs. the process or
approach.

> That said, I recently proposed a method for a project that leverages
> some aspects of "Agile", but doesn't follow it to the letter of
> official defined process. In our approach we proposed a traditional
> discovery and definition phase, then followed it with a sort of
> "setup" phase where would explore the overarching IA and interaction
> patterns that could be applied across multiple features. This meant
> things like forms, search, navigation, methods for tagging, etc...
> There would also be a traditional graphic design phase in where you
> did the explorations, mood boards, comps and then applying the design
> across several represented screens.

That's cool. Personally I tend to do the detail graphic design work later on
in the process after we've gone some of the initial functionality up and
running.

>> I would say we definitely are approaching that as well.. But because
we'll have two teams... It's important for them to have a consistent "kit of
parts" to do the low level design with

> From that point, we broke the rest of the design work into 8 stories
> (scenarios, high level feature sets, whatever you want to call them).
> We then sequenced the 8 stories based on priority and some other
> factors. Then, we decided to have 2 teams running simultaneously which
> included an IA, Graphic Designer and two developers. One team was
> focused on re- designing the core product, while the other team
> focused on new and significant changes. This insured that the work of
> the new and unknown was not slowing down the work of the baseline
> features of the product.

Sounds like your stories are pretty high level? (since there are only
eight) or is it quite a simple application?

Personally I tend to take stories down to quite a low level so that a story
would typically take a pair of developers 0.5-1 day to implement.
Interestingly enough stories of this size seem to very naturally fit into
the "sub-task" level of task analysis diagrams, which gives a handy way to
track things.

I find keeping the stories at a smaller scale since it's easier to track
progress in small chunks of story-done/not-done vs. the never ending "we're
80% finished". Developer estimates for the smaller chunks of work also tend
to be considerably more accurate.

>> Agreed. We are actually at the proposal phase which is why they are high
level right now... I like to think of them more like "scenarios" at this
point in order for us to get in the scope ballpark, once we start the
project I imagine we would take those down to the "use case" level once we
got into the project.

> Each developed story would be approached through some traditional
> wireframing, but with the entire team and mostly on whiteboards. We
> would use digital photos of whiteboards as a way of capturing and
> sharing our work with the clients.

Ah. Digital camera's and whiteboards - a match made in heaven! Sadly I think
I have more photo's of whiteboards in iPhoto than I do of my partner :-)

>> That's too funny... I just looked at my Picasa2 and I'm starting to see
the same trend ;-)

> We then would then extend the visual design, the developers would code
> the templates for that story and we would test the actual code with
> users using some dummy server side code to simulate the real thing.
> Any AJAX used would be part of the code and the test.
> Then we
> would iterate based on the findings.

Rather than try and produce some dummy code to simulate the real thing, we
try and produce a simple version of the real thing. That we we can take the
code forward rather than spending time throwing prototypes away. We try and
order our stories so that we get something working end-to-end as quickly as
possible and build it up from there.

>> Part of our issue is having a backend setup in time... Another issue with
agile-like approaches... Typically the backend team has more time to setup
and acquire dev resources vs. having them ready months sooner. Using dummy
dynamic code in our templates helps us deal with that... But the templates
aren't thrown away... We just replace the dummy server code with actual
variables when it's time to connect it all up.

> Now of course there's a concern about integration and consistency so
> we proposed dealing with that in two ways. First, the entire team
> would be working together in one big room and my experience has taught
> me that "osmosis" tends to fix a lot of that. The other idea is to
> have an integration phase at the end to pull things together.

The team room seems to solve most of these problems in my experience.
Brief (10-15m) daily morning meetings of the whole team are also useful to
monitor progress and spot problems before they get serious

>> Yeah... The whole peripheral vision and overhearing conversations can be
distracting on one hand, but can avoid disconnects on the other.

> Some of the big advantages to this method....
> - Ability to actually have more time for design since you're handing
> off code to backend developers way up front vs. the end of the project
> - A lot more opportunity to interact with users and do user testing
> - Less time developing prototypes and using that time to build
> something more real and usable
> - Much more collaborative with the entire team
> - Clients get to see real stuff much sooner
> - If scope or requirements change along the project (like they do),
> it's much easier to react to and accomodate

Sounds good.

[snip]
> "It's risky for the firm because there's more hard dates, more often
> so less room slowing down and speeding up"
[snip]

That's curious. In my experience people usually see this as an advantage.
Having lots of mini-milestones allows management to get a much more accurate
idea of how the project is progressing.

Of course sometimes the news may be unwelcome (it's running late), but
generally I find people are mature enough to realise that it's better to get
the bad news earlier than later.

>> This is more of the issues surrounding a small design firm and
resourcing. When you're constantly working on projects... Unfortunately they
don't perfectly butt up against each other on the schedule... So sometimes
you cheat a little bit in the overlap. In waterfall, you're able to do
slower starts with harder compressed finishes within the phase. I think of
it as a dirty secret of our business that no one likes to talk about... But
everyone in the business has to deal with it. It's more subtle than it
sounds... But with Agile approaches... You really have to be up and running
on day one. It's something we were aware of, but no this type of approach is
worth trying to manage this particular issue around.

>> Jack

15 Feb 2007 - 10:33am
Jack Skates
2006

"Just to quick note to quash the myth that agile processes are anti-
documentation. They're not. They're against _unnecessary_ documentation,
especially when talking to the person on the desk next to you is vastly more
effective ;-)

If the customer needs or wants documentation, you give them documentation."

>>Amen!

15 Feb 2007 - 10:40am
Dave Malouf
2005

Anyone have to work with a distributed team (i.e. "offshore") using agile
processes?

The reason I ask this is that below Jack talks about reducing "unnecessary"
documentation, but my experience with work in specific offshore environments
is that there is no such thing as too much documentation. You can't specify
enough as upfront enough as possible.

Any thoughts and experiences with Agile in this type of environment?

-- dave

On 2/15/07, Jack Skates <jskates-web at acmedigital.us> wrote:
>
>
> "Just to quick note to quash the myth that agile processes are anti-
> documentation. They're not. They're against _unnecessary_ documentation,
> especially when talking to the person on the desk next to you is vastly
> more
> effective ;-)
>
> If the customer needs or wants documentation, you give them
> documentation."
>
> >>Amen!
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
David Malouf
http://synapticburn.com/

15 Feb 2007 - 11:01am
Mark Schraad
2006

When I first came to AOL: Marketplace I was soo impressed with the lush detailed documentaiotn. Now I am working hard to strip it down to only what is absolutely necessary. In the case of our offshore dev teams I am not sure how much we can take away. That will be evolving over the next few months.
Mark

On Thursday, February 15, 2007, at 10:40AM, "David Malouf" <dave at ixda.org> wrote:
>Anyone have to work with a distributed team (i.e. "offshore") using agile
>processes?
>
>The reason I ask this is that below Jack talks about reducing "unnecessary"
>documentation, but my experience with work in specific offshore environments
>is that there is no such thing as too much documentation. You can't specify
>enough as upfront enough as possible.
>
>Any thoughts and experiences with Agile in this type of environment?
>
>-- dave
>
>On 2/15/07, Jack Skates <jskates-web at acmedigital.us> wrote:
>>
>>
>> "Just to quick note to quash the myth that agile processes are anti-
>> documentation. They're not. They're against _unnecessary_ documentation,
>> especially when talking to the person on the desk next to you is vastly
>> more
>> effective ;-)
>>
>> If the customer needs or wants documentation, you give them
>> documentation."
>>
>> >>Amen!

15 Feb 2007 - 4:58pm
cfmdesigns
2004

>From: Adrian Howard <adrianh at quietstars.com>
>
>On 14 Feb 2007, at 16:32, Josh Viney wrote:
>
>> Earlier I mentioned that we use a home-brewed version of Agile development
>> processes, and I'm not sure if I explained what that actually means. We've
>> found that Agile works really well with our developers and creative teams,
>> but that it's not always sufficient for our clients.
>>
>> They do enjoy the quick turnaround time and the constant progress, but some
>> clients NEED documentation and waterfall-like processes.
>[snip]
>
>Just to quick note to quash the myth that agile processes are anti-
>documentation. They're not. They're against _unnecessary_
>documentation, especially when talking to the person on the desk next
>to you is vastly more effective ;-)

The problem I've found -- and continue to find, on current "Agile-er than before, if not quite really Agile" projects -- is that the definition of "unnecessary" is quite variable. And where it horribly breaks down is when the inevitable project scramble occurs.

You know: Jack and Sue are the Dev and QA on Feature 1, but Jack gets moved on to Feature 2 when Feature 1 is coded, leaving Manesh to do the bug fixes, and then Sue passes the last 25% of the QA on to Frank since she's needed to shore up Feature 3 which has just been added, so now Manesh and Frank are working on something with a spec that has wireframes but no visual treatments and no way to get the interactions details that Jack and Sue had verbally worked out which weren't in the spec from Felice who has since moved on to a completely different project. (gasp! wheeze!) And then Frank trips over a user scenario that wasn't considered by anyone (but he spotted it in the first day).

I don't know just what "unnecessary" documentation actually looks like. The best (waterfall) project I've ever been on also had the fullest documentation.

-- Jim

15 Feb 2007 - 5:39pm
John Schrag
2005

Jim wrote:
> I don't know just what "unnecessary" documentation actually looks
like. The
> best (waterfall) project I've ever been on also had the fullest
documentation.

I could send you binders of it, if you want to see what it looks like
:-)

Unneccesary documentation is the kind you write when you naively believe
that someone will actually read it. And when you find discrepancies
between what you wrote and what gets built, you react by adding more
detail to your documents. This makes them bigger, and even less likely
to be actually read or used by anyone. When they are read, there's too
much detail for a developer to absorb. Years ago, we wrote things this
way, and found afterwards that (darn it) we had to actually talk to
people anyway. In my own experience (yours may vary) I've never found
that more detailed docs lead to better communication or compliance.

Eventually we figured out that if we were going to have to talk to
people anyway, we could get away with really light documentation ---
say, pictures with call-outs --- and spend our time sharing the idea of
what we were building face-to-face, rather than writing stuff that no
one was reading. My personal job satisfaction went up immensely, and we
had less design drift.

As for problems with team shuffle --- pair-programming (an XP practice)
can be applied to design, as well. If your team works collaboratively,
no one person holds any single part of the design in their head. So
when shuffles happen, the knowledge doesn't walk out with your
ex-colleague.

After four years of doing Agile UCD, I occasionally have to work on
non-Agile projects, and I'm always amazed at how much longer it takes to
get anything done, and how much time I waste reworking stuff in
comparison to the Agile projects I've worked on.

-john

15 Feb 2007 - 11:55pm
dszuc
2005

Hi:

Some lessons we have learnt:

* Important for designers and developers to be close by (preferably in the
same room - avoids lag in discussing design possibilities, technical
constraints, opportunities etc)

* Important to get technical feasibility as early as possible on designs
(avoiding rework later)

* More challenging to do iterative Usability Testing b/c of time and
reporting constraints (also depending on what you want to test and access to
users), easier to do rapid Expert Reviews

* Important to have a central online space to log ideas/issues that can be
tracked

* Sketches work for some, powerpoint for others etc (adjust your design &
communications to meet your audience need)

* Take photos of your earlier sketches to capture the design history

... * reaches for a tea and biscuit *

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

The Usability Toolkit - http://www.sitepoint.com/books/usability1/

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Robert
Hoekman, Jr.
Sent: Tuesday, February 13, 2007 7:09 AM
To: discuss
Subject: [IxDA Discuss] IxD in agile environments

Anyone doing IxD work in an agile programming environment? If so, what are
you doing to make it work with agile processes? Is it succeeding? What are
the problems you've had?

I know there's been some talk about this before on this list, and it seems a
lot of people are having serious trouble finding ways to adapt and work with
agile methods, but I've formed some ideas about this on my own, because I've
been working like this for a long time and have found ways to make it work
for me, and am wondering what other people have come up with.

Thanks.

-r- ________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/ (Un)Subscription
Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

18 Feb 2007 - 12:02pm
Adrian Howard
2005

Hi Jack,

On 15 Feb 2007, at 15:32, Jack Skates wrote:

> Forgot that "reply all" button... Doh!

That's usually my trick :-)

>> From: Adrian Howard [mailto:adrianh at quietstars.com]
>>
>> Of course you can only customise it so far and it still stay "agile".
>> Sometimes I think people spend to much effort trying to adapt to
>> constraints and opportunities, and not enough effort on trying to
>> adapt the
>> constraints and opportunities to enable them to build a good product.
>
> Since I work for a firm that services clients... A lot of the
> constraints
> are fixed by the client which make them harder to adapt vs. the
> process or
> approach.

True, and it more a self-observed problem than a comment aimed at you
- honest :-)

I find I'm sometimes a little too eager to work within the process
constraints a client sets - rather than push against them in places
that would help develop a better product. Working with agile methods
has made me more aware of this since so many of them are context
dependent.

[snip]
>> That's cool. Personally I tend to do the detail graphic design
>> work later on
>> in the process after we've gone some of the initial functionality
>> up and
>> running.
>
> I would say we definitely are approaching that as well.. But because
> we'll have two teams... It's important for them to have a
> consistent "kit of
> parts" to do the low level design with
[snip]

I wonder if there's a way to merge those two teams?

>> Sounds like your stories are pretty high level? (since there are only
>> eight) or is it quite a simple application?
[snip]
> Agreed. We are actually at the proposal phase which is why they are
> high
> level right now... I like to think of them more like "scenarios" at
> this
> point in order for us to get in the scope ballpark, once we start the
> project I imagine we would take those down to the "use case" level
> once we
> got into the project.

Just as a suggestion, try dropping down a couple of levels on the
most important stories - the stuff that you'd build first. It'll give
you more accurate estimates for the most valuable work, and it can
act as an useful measuring stick for the future work.

>>> Each developed story would be approached through some traditional
>>> wireframing, but with the entire team and mostly on whiteboards. We
>>> would use digital photos of whiteboards as a way of capturing and
>>> sharing our work with the clients.
>>
>> Ah. Digital camera's and whiteboards - a match made in heaven!
>> Sadly I think
>> I have more photo's of whiteboards in iPhoto than I do of my
>> partner :-)
>>
> That's too funny... I just looked at my Picasa2 and I'm starting to
> see
> the same trend ;-)

Another neat thing you can do with those cameras that are capable is
to take little video recordings of paper-prototypes in action. A
thirty second movie of folk shuffling some index cards around can be
a hugely useful tool to get the intended behaviour across.

[snip]
>> Rather than try and produce some dummy code to simulate the real
>> thing, we
>> try and produce a simple version of the real thing. That we we can
>> take the
>> code forward rather than spending time throwing prototypes away.
>> We try and
>> order our stories so that we get something working end-to-end as
>> quickly as
>> possible and build it up from there.
>>
> Part of our issue is having a backend setup in time... Another
> issue with
> agile-like approaches... Typically the backend team has more time
> to setup
> and acquire dev resources vs. having them ready months sooner.
> Using dummy
> dynamic code in our templates helps us deal with that... But the
> templates
> aren't thrown away... We just replace the dummy server code with
> actual
> variables when it's time to connect it all up.

One solution to this is to start the team small, and then grow it
over time. You then get the advantage of having a core of developers
that are completely up to speed at all times.

>>> Now of course there's a concern about integration and consistency so
>>> we proposed dealing with that in two ways. First, the entire team
>>> would be working together in one big room and my experience has
>>> taught
>>> me that "osmosis" tends to fix a lot of that. The other idea is to
>>> have an integration phase at the end to pull things together.
>>
>> The team room seems to solve most of these problems in my experience.
>> Brief (10-15m) daily morning meetings of the whole team are also
>> useful to
>> monitor progress and spot problems before they get serious
>
> Yeah... The whole peripheral vision and overhearing conversations
> can be
> distracting on one hand, but can avoid disconnects on the other.

It can take a little getting used to, and obviously some tasks are
better handled outside if they're likely to be noisy.

That said, I've found that people finding team rooms distracting is
often a sign that folk are working on different things. People find
irrelevant noise distracting. If relevant stuff gets to the level of
being distracting then people usually want to get involved to fix the
problem.

[snip]
>>> "It's risky for the firm because there's more hard dates, more often
>>> so less room slowing down and speeding up"
>> [snip]
>>
>> That's curious. In my experience people usually see this as an
>> advantage.
>> Having lots of mini-milestones allows management to get a much
>> more accurate
>> idea of how the project is progressing.
>>
>> Of course sometimes the news may be unwelcome (it's running late),
>> but
>> generally I find people are mature enough to realise that it's
>> better to get
>> the bad news earlier than later.
>>
> This is more of the issues surrounding a small design firm and
> resourcing. When you're constantly working on projects...
> Unfortunately they
> don't perfectly butt up against each other on the schedule... So
> sometimes
> you cheat a little bit in the overlap. In waterfall, you're able to do
> slower starts with harder compressed finishes within the phase. I
> think of
> it as a dirty secret of our business that no one likes to talk
> about... But
> everyone in the business has to deal with it. It's more subtle than it
> sounds... But with Agile approaches... You really have to be up and
> running
> on day one. It's something we were aware of, but no this type of
> approach is
> worth trying to manage this particular issue around.

That makes complete sense. I usually treat the first couple of
iterations as "special" myself. There's always time involved in
bringing folk up to speed, and educating the team. I usually find
things have settled down by iteration two/three.

Thanks - all interesting stuff.

Cheers,

Adrian

18 Feb 2007 - 12:17pm
Adrian Howard
2005

On 15 Feb 2007, at 21:58, Jim Drew wrote:
[snip]
> The problem I've found -- and continue to find, on current "Agile-
> er than before, if not quite really Agile" projects -- is that the
> definition of "unnecessary" is quite variable. And where it
> horribly breaks down is when the inevitable project scramble occurs.
>
> You know: Jack and Sue are the Dev and QA on Feature 1, but Jack
> gets moved on to Feature 2 when Feature 1 is coded, leaving Manesh
> to do the bug fixes, and then Sue passes the last 25% of the QA on
> to Frank since she's needed to shore up Feature 3 which has just
> been added, so now Manesh and Frank are working on something with a
> spec that has wireframes but no visual treatments and no way to get
> the interactions details that Jack and Sue had verbally worked out
> which weren't in the spec from Felice who has since moved on to a
> completely different project. (gasp! wheeze!) And then Frank
> trips over a user scenario that wasn't considered by anyone (but he
> spotted it in the first day).
[snip]

Wandering considerably off the topic of IxD now.. but...

The thing I don't like here is the use of the phrase "inevitable"
when it comes to this sort of project scramble :-)

It isn't inevitable. The practices in processes like XP go a long way
towards eliminating these sorts of issue in my experience. If we can
reduce the risk of project scrambles like this then the cost/benefit
of the the extra work that we do to mitigate these risks becomes very
different.

Cheers,

Adrian

18 Feb 2007 - 12:11pm
Adrian Howard
2005

On 15 Feb 2007, at 15:40, David Malouf wrote:

> Anyone have to work with a distributed team (i.e. "offshore") using
> agile
> processes?
>
> The reason I ask this is that below Jack talks about reducing
> "unnecessary"
> documentation, but my experience with work in specific offshore
> environments
> is that there is no such thing as too much documentation. You can't
> specify
> enough as upfront enough as possible.
>
> Any thoughts and experiences with Agile in this type of environment?

Well - if you're in a situation where you're documenting everything
up front - then it doesn't sound like any sort of agile environment
to me...

That said :-)

I've not done any usability work with any different-timezone
distributed teams in the recent past. However with some-timezone
distributed teams I've found that instead of writing lots of
documentation I'm doing things like:
* exchanging digital snapshots of paper/whiteboard sketches
* exchanging movies of little bits of interaction behaviour with
paper prototypes
* having phone calls with developers/users
* spending more time travelling to sites rather that writing docs

I find that the need for documentation is proportional to the time it
takes for features to make their way into the code. The smaller I can
help make that gap, the less time I need to spend producing docs.

Cheers,

Adrian

20 Feb 2007 - 1:29am
cfmdesigns
2004

On Feb 18, 2007, at 9:17 AM, Adrian Howard wrote:

> On 15 Feb 2007, at 21:58, Jim Drew wrote:
> [snip]
>> The problem I've found -- and continue to find, on current "Agile-
>> er than before, if not quite really Agile" projects -- is that the
>> definition of "unnecessary" is quite variable. And where it
>> horribly breaks down is when the inevitable project scramble occurs.
>>
>> You know: Jack and Sue are the Dev and QA on Feature 1, but Jack
>> gets moved on to Feature 2 when Feature 1 is coded, leaving Manesh
>> to do the bug fixes, and then Sue passes the last 25% of the QA on
>> to Frank since she's needed to shore up Feature 3 which has just
>> been added, so now Manesh and Frank are working on something with a
>> spec that has wireframes but no visual treatments and no way to get
>> the interactions details that Jack and Sue had verbally worked out
>> which weren't in the spec from Felice who has since moved on to a
>> completely different project. (gasp! wheeze!) And then Frank
>> trips over a user scenario that wasn't considered by anyone (but he
>> spotted it in the first day).
> [snip]
>
> Wandering considerably off the topic of IxD now.. but...
>
> The thing I don't like here is the use of the phrase "inevitable"
> when it comes to this sort of project scramble :-)

Well, I hope you don't think I like it either!

> It isn't inevitable. The practices in processes like XP go a long way
> towards eliminating these sorts of issue in my experience. If we can
> reduce the risk of project scrambles like this then the cost/benefit
> of the the extra work that we do to mitigate these risks becomes very
> different.

Yeah, it's probably mostly a factor of trying to move a project from
something waterfall-ish to something agile-esque. I'm sure that the
first few iterations can be expected to be bumpy, smoothing out over
time. I hope so, anyway.

-- Jim

21 Feb 2007 - 9:44am
James Melzer
2004

I think the crucial issue here is scale. We are talking about two
different kinds of things.

If you are building a small product with a small team, maybe you don't
need much documentation. You might be able to communicate the design
with a sketch and a conversation. If you are building a big product
with a big team, documentation becomes critical. Yes, on a small team
it makes sense for your requirements person to sit in the same room
with your developer. They can talk as they work, and communicate about
design in real time. But what if the project has 60 developers and 12
requirements analysts from several companies? What if the mix of
companies and personalities changes during the multi-year project
lifecycle?

I think in these cases, documentation is half the value to the
customer because it documents all the hard-won decisions and lessons
of the design process. The valuable part of developers' practice is
solving engineering problems. Once the problem is solved, you document
the solution and build it. Reproducing the 'build it' part isn't
rocket science with good documentation and a smart team. You just put
in the hours and the risk is minimal.

~ James

On 2/20/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
>
> On Feb 18, 2007, at 9:17 AM, Adrian Howard wrote:
>
> > On 15 Feb 2007, at 21:58, Jim Drew wrote:
> > [snip]
> >> The problem I've found -- and continue to find, on current "Agile-
> >> er than before, if not quite really Agile" projects -- is that the
> >> definition of "unnecessary" is quite variable. And where it
> >> horribly breaks down is when the inevitable project scramble occurs.
> >>
> >> You know: Jack and Sue are the Dev and QA on Feature 1, but Jack
> >> gets moved on to Feature 2 when Feature 1 is coded, leaving Manesh
> >> to do the bug fixes, and then Sue passes the last 25% of the QA on
> >> to Frank since she's needed to shore up Feature 3 which has just
> >> been added, so now Manesh and Frank are working on something with a
> >> spec that has wireframes but no visual treatments and no way to get
> >> the interactions details that Jack and Sue had verbally worked out
> >> which weren't in the spec from Felice who has since moved on to a
> >> completely different project. (gasp! wheeze!) And then Frank
> >> trips over a user scenario that wasn't considered by anyone (but he
> >> spotted it in the first day).
> > [snip]
> >
> > Wandering considerably off the topic of IxD now.. but...
> >
> > The thing I don't like here is the use of the phrase "inevitable"
> > when it comes to this sort of project scramble :-)
>
> Well, I hope you don't think I like it either!
>
>
> > It isn't inevitable. The practices in processes like XP go a long way
> > towards eliminating these sorts of issue in my experience. If we can
> > reduce the risk of project scrambles like this then the cost/benefit
> > of the the extra work that we do to mitigate these risks becomes very
> > different.
>
> Yeah, it's probably mostly a factor of trying to move a project from
> something waterfall-ish to something agile-esque. I'm sure that the
> first few iterations can be expected to be bumpy, smoothing out over
> time. I hope so, anyway.
>
> -- Jim
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
James Melzer
http://www.jamesmelzer.com
http://del.icio.us/jamesmelzer

22 Feb 2007 - 5:12am
Adrian Howard
2005

On 21 Feb 2007, at 14:44, James Melzer wrote:
[snip]
> The valuable part of developers' practice is
> solving engineering problems. Once the problem is solved, you document
> the solution and build it. Reproducing the 'build it' part isn't
> rocket science with good documentation and a smart team. You just put
> in the hours and the risk is minimal.
[snip]

It's been my experience that the problem is never "solved" until we
build the product. We always learn things during the building phase
that guides the design...

Adrian

Syndicate content Get the feed