Scrum and UCD

[linda.hellman]

Hi,
I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to find the biggest problems between the two methods and then to integrate Scrum and UCD and create new user-centered Scrum.
My Thesis is based on literature about integrating user-centered design and agile methods. My Thesis is almost ready and at the moment I am starting to introduce my process to one software project where I am the UE designer.

I would like hear from You, what kind of actual troubles and problems You have had when using both Scrum and User-Centered Design?
And what advantages has the use of both methods brought to the project?

Waiting for your opinions,
Linda.

[Mike Dwyer-2]

Linda

There should be little problem if you  understand that Scrum can be used in
both iterative and incremental work.  The real issue is making sure that you
are measuring what you do based on which mode you are in.

In an iterative mode you need to measure the improvement in user clarity as
to what they want.  Here refinement is more important than success as
Bayesian logic dictates that we will never know what is correct but can only
wander towards it through repeated refinements.  Once the UI is accepted
(for the time) then you can move to incremental mode where you measure
movement toward the completion of stories as defined.

 

Now this can and does become muddled because it is common for the product
owner to get feedback from the users that they have changed their mind.  So
make sure that you keep the iterative and incremental modes in your mind and
in your metrics.

 

 

Mike Dwyer
Principal, Agile Coach

BigVisible Solutions
url:    http://www.bigvisible.com <http://www.bigvisible.com/>

cell:   [phone]

email: mdwyer@... <mailto:asingh@...>

 

 

From: linda.hellman [mailto:linda.hellman@...]
Sent: Wednesday, March 04, 2009 7:03 AM
To: agile-usability@...
Subject: [agile-usability] Scrum and UCD

 

Hi,
I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to
find the biggest problems between the two methods and then to integrate
Scrum and UCD and create new user-centered Scrum.
My Thesis is based on literature about integrating user-centered design and
agile methods. My Thesis is almost ready and at the moment I am starting to
introduce my process to one software project where I am the UE designer.

I would like hear from You, what kind of actual troubles and problems You
have had when using both Scrum and User-Centered Design?
And what advantages has the use of both methods brought to the project?

Waiting for your opinions,
Linda.




 
 

[Marjorie H Pries]

Linda,

To clarify, SCRUM is a method for delivering working software, UCD is not
a method but a collection of techniques to determine software requirements
and the human interaction aspects of the design -- unless you're going to
some school that has cooked up some method they call UCD :-)  .

You can do SCRUM with UCD included in the activities as long as you have
stories for the UCD tasks, you plan the stories into each sprint,  and
your UCD people participate in the daily stand-ups and report their
status. The outsomes of the UCD stories become new stories for the
developers in a subsequent iteration / sprint.

Marjorie H. Pries
Lead Consultant / Utility Infielder

ThoughtWorks, Inc.
http://www.thoughtworks.com


"Don't believe everything you think."
     --seen on a bumpersticker



"linda.hellman" <linda.hellman@...>
Sent by: agile-usability@...
03/04/2009 06:03 AM
Please respond to
agile-usability@...


To
agile-usability@...
cc

Subject
[agile-usability] Scrum and UCD









Hi,
I'm writing my Master's Thesis at the moment and in my Thesis I'm trying
to find the biggest problems between the two methods and then to integrate
Scrum and UCD and create new user-centered Scrum.
My Thesis is based on literature about integrating user-centered design
and agile methods. My Thesis is almost ready and at the moment I am
starting to introduce my process to one software project where I am the UE
designer.

I would like hear from You, what kind of actual troubles and problems You
have had when using both Scrum and User-Centered Design?
And what advantages has the use of both methods brought to the project?

Waiting for your opinions,
Linda.



 
 

[Daniel Naumann]

Hi Linda,

One of the bigger issues that I see and read about is the 'How much
up-front design?' issue.  UCD likes a lot of up-front design and
Scrum/Agile only wants the minimum done.  I think it's a semantic
problem around the term 'design'.

I think when Scrum/Agile talk about up-front design they mean
designing an actual solution, ie. sketches, viso, UI code, etc.  But
when UCD talks about up-front design, they really mean 'problem
definition'.  The first stage in UCD is to really work out what
problem you're trying to solve and who you're solving it for.  Once
you have that, then you can start on a solution.  I think Agile call
this analysis rather than design (but I might be wrong on that as I'm
still learning about Agile).

So it's something i see people clash over, but I think it's just a
semantic problem.

Cheers,
Dan.

2009/3/4 linda.hellman <linda.hellman@...>:

> Hi,
> I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to
> find the biggest problems between the two methods and then to integrate
> Scrum and UCD and create new user-centered Scrum.
> My Thesis is based on literature about integrating user-centered design and
> agile methods. My Thesis is almost ready and at the moment I am starting to
> introduce my process to one software project where I am the UE designer.
>
> I would like hear from You, what kind of actual troubles and problems You
> have had when using both Scrum and User-Centered Design?
> And what advantages has the use of both methods brought to the project?
>
> Waiting for your opinions,
> Linda.
>
>

[Robert Biddle-2]

There are a number of ways the UCD-Agile connection is being made, and I
guess Linda
wanted to hear reports of experience in the various approaches.

I haven't actually seen the one that you describe, and I would like to
hear more details.

For example:
* are the UI designers and programmers within the same team but do
different kinds of tasks,
   or do they do both?
* what are the UI stories (or backlog items) like, especially for user
research?
* do the UI stories count as "done", even when no software has been written?

I've love to hear more about what you've seen.

Cheers
Robert Biddle




Marjorie H Pries wrote:

>
>
> Linda,
>
> To clarify, SCRUM is a method for delivering working software, UCD is
> not a method but a collection of techniques to determine software
> requirements and the human interaction aspects of the design -- unless
> you're going to some school that has cooked up some method they call
> UCD :-)  .
>
> You can do SCRUM with UCD included in the activities as long as you
> have stories for the UCD tasks, you plan the stories into each sprint,
>  and your UCD people participate in the daily stand-ups and report
> their status. The outsomes of the UCD stories become new stories for
> the developers in a subsequent iteration / sprint.
>
> Marjorie H. Pries
> Lead Consultant / Utility Infielder
>
> ThoughtWorks, Inc.
> http://www.thoughtw orks.com
>
>
> "Don't believe everything you think."
>     --seen on a bumpersticker
>
>
> *"linda.hellman" <linda.hellman@ yahoo.com>*
> Sent by: agile-usability@ yahoogroups. com
>
> 03/04/2009 06:03 AM
>
> Please respond to
> agile-usability@ yahoogroups. com
>
>
>
> To
> agile-usability@ yahoogroups. com
> cc
>
> Subject
> [agile-usability] Scrum and UCD
>
>
>
>
>
>
>
>
>
>
> Hi,
> I'm writing my Master's Thesis at the moment and in my Thesis I'm
> trying to find the biggest problems between the two methods and then
> to integrate Scrum and UCD and create new user-centered Scrum.
> My Thesis is based on literature about integrating user-centered
> design and agile methods. My Thesis is almost ready and at the moment
> I am starting to introduce my process to one software project where I
> am the UE designer.
>
> I would like hear from You, what kind of actual troubles and problems
> You have had when using both Scrum and User-Centered Design?
> And what advantages has the use of both methods brought to the project?
>
> Waiting for your opinions,
> Linda.
>
>
>

[Sigfrid]

Hi Linda,unfortunately I don't have an answer for you right now. I'm still
trying to figure out the best way to include UCD within the Agile
methodology I use to optimize processes (from my point of view software is
not the goal but the mean).
However I would like to suggest you some interesting websites and articles:

- http://www.uie.com/events/uiconf/2008/seminars/patton/  (on the right
column you can find a good article and the inteview with Jeff Patton about
this topic)
- http://agileproductdesign.com/index.html   (Jeff's website)



Hope this helps.

PS Let us know how your thesis is going on ...



Sig






2009/3/4 linda.hellman <linda.hellman@...>

>   Hi,
> I'm writing my Master's Thesis at the moment and in my Thesis I'm trying to
> find the biggest problems between the two methods and then to integrate
> Scrum and UCD and create new user-centered Scrum.
> My Thesis is based on literature about integrating user-centered design and
> agile methods. My Thesis is almost ready and at the moment I am starting to
> introduce my process to one software project where I am the UE designer.
>
> I would like hear from You, what kind of actual troubles and problems You
> have had when using both Scrum and User-Centered Design?
> And what advantages has the use of both methods brought to the project?
>
> Waiting for your opinions,
> Linda.
>
>  
>

[Marjorie H Pries]

Hi Robert,

Yes, I see.. Thanks for pointing that out. I lost track of the "writing a
Masters thesis" bit and went off on my own tangent because I have a lot of
concern that people trying to "do Agile" will eventually land at an
unhappy place if they don't make a clear distinction between methodologies
and values/ philosophy / tactics.

On our projects at ThoughtWorks, we don't necessarily do by-the-book Scrum
but we do Scrum-like stuff  because we're committed to the Agile
Manifesto.  However, every project is different and we shape it according
to what works for the situation.  Sometimes, there is no UCD involvement
and business analysts and developers just have to make things up based on
what they see as making sense and where the client is coming from (often
these are applications for the clients internal use ). Sometimes there are
projects where the client hired a designer independently of bringing TW in
for the implementation and their design is pretty much a static
requirement in place at the start or delivered part way through (not very
good). And then there are projects where we can have our own UCD person
on-board or the outside design firm is committed to working as part of the
team through the life of the project. That's when it gets good.

Ideally, there is one or more UCD-skilled person(s) involved on the team
through the life of the project. When you have this, the UCD person is
utilizing these skills as they play some combination of roles: product
owner/customer, business analyst / SME, developer.  The business analyst
is the best model for what I'm talking about.

 A business analyst has to be able to understand the business
operationally, grasp the strategic objectives of the stakeholders,
interview stakeholders and customers/users to discover and verify
requirements, be an advocate on the team for the customer/stakeholders, be
an advocate for the strategic objectives (sometimes even stakeholders lose
track of the greater goals), know enough about technology to have an
intelligent conversation with developers so they can advocate back to the
stakeholders when choices get hard, and maybe even sometimes do something
technical themselves plus be able to specify and conduct effective
acceptance tests so everyone can be assured the story is Done when it's
done.

Given that, the UCD member of the team is just another flavor of business
analyst and all of the analysts would collaborate on just-in-time analysis
tasks including user research and usability testing. Programmers also pair
up with analysts as needed to have conversations, investigate technical
issues, or research the business problem.

I'm in danger of dragging this out into a long essay, but I want to touch
on your three questions because they are very good ones that really get at
the heart of how to make agile projects work:
* are the UI designers and programmers within the same team but do
different kinds of tasks, or do they do both?
my answer: UI designers and programmers are just another flavor of
business analyst or programmer and they would collaborate with the other
analysts and programmers on all the tasks that need to be done including
user research and usability testing. For example, a team could have a
person who has skills in UI design and UI programming. That person would
pair up with another analyst to do user research in one iteration, then
pair up with a developer to code the UI part of a story(s) in another
iteration. A team may also have a person who is a UI designer and
experienced in user research but not experienced in UI programming.  That
type of person would stay completely in the analyst / customer proxy role
doing things like user research, product design, acceptance testing,
facilitating showcases with the stakeholders, and also any needed product
documentation. And programmers would also pair up with UCD analysts as
needed to have conversations, investigate solutions to a problem
interface, and conduct or witness research into the user experience.
* what are the UI stories (or backlog items) like, especially for user
research?
my answer: Like the term "methodology" we have to be careful with the term
"story".  "Story" is a thing that developers implement. "Tasks" are things
that have to be done to get stories through the pipeline. Tasks are
activities people do to figure out what the story should be; realize the
story in code;  or verify the story is done. So while you definitely make
the stories visible and track their progress, you may or may not make all
the tasks visible. High-level tasks might be treated "as if" they were
stories so it is easy for the entire team to be aware of overall progress
and activities for the week. In this case, your information radiator /
story wall would likely use color or parallel tracks to distinguish
implementation stories from other activities.  The development track might
show stories 1, 2, and 3 in play and your analysis/UI track might show
that story 4 is out for customer and UI review prior to development,
detailed requirements discovery is starting for story 5, and user research
relevant for backlog stories 6, 8 and 9 is in-progress.
A lot of  tasks are not made visible because it's just too much noise, but
people keep mental checklists and still report in stand-up on any
blockages -- I'm going to be late finalizing the requirements for story 5
because I can't get a meeting with Mr. Y; we need to get the XML spec for
the interface to system G before we can complete story 3; our user
interviews are proceeding on schedule and we have no problems to report.  


* do the UI stories count as "done", even when no software has been
written?
More hairsplitting!  The purpose of saying a story is Done, is to have a
means of measuring the team's velocity -- how much implementation gets
done on average per iteration/ sprint.  Thus, in theory, you only really
care about Done if the story is a coding story.
But you still need some way of determining if the flow of stories out of
the backlog will impede the team's velocity.  Now we're talking lean.  Are
stories getting delivered into the "ready-to-build" backlog fast enough so
that the development team can always pull something off the backlog given
their average velocity?  Or are they going to sit around with nothing to
do because stories aren't ready? Or better yet, can we move one to the
next phase early because we're going to blow through / eliminate all the
stories originally planned for this sprint/phase?
It is important to see the status of those higher-level analysis tasks,
which includes the big UI tasks that precede the coding stories. If UI
work was substantial enough to make visible as a "story" then you have to
be able to say if it is not started, in-progress, or done, and have target
expected completion dates so the team can get some kind of assurance about
how and when the backlog may grow or shrink.
 UI research and the subsequent problem definition and solution finding
(design thinking) will either add new stories, provide details for
existing stories, or remove stories. Where the research provides new
details for existing stories, that information will increase or decrease
the stories's complexity.  Likewise, adding and removing stories changes
the estimated amount of effort in the backlog.  Being able to see when UI
findings are likely to conclude gives the team information about future
events that could shift the backlog and helps everyone roadmap the
project's progress.
But, saying that these UI stories are Done, does not count in the velocity
equation. The only stories that count for velocity are Done coding
stories.   The team needs to be able to see it like this: Our velocity is
V. We have 4xV stories in the backlog so the project should complete in 4
sprints BUT, we still have two UI research tasks to complete and our
experience so far on this project indicates that those tasks could add as
much as 1xV each in changes to the backlog, a total of 2xV potential
increase. Therefore, as of today, our best estimate of finishing is 5
sprints but we may need 6.


Hope you found that useful,

Marjorie H. Pries
Lead Consultant / Utility Infielder





Robert Biddle <robtbiddle@...>
Sent by: agile-usability@...
03/05/2009 06:57 AM
Please respond to
agile-usability@...


To
agile-usability@...
cc

Subject
Re: [agile-usability] Scrum and UCD









There are a number of ways the UCD-Agile connection is being made, and I
guess Linda
wanted to hear reports of experience in the various approaches.

I haven't actually seen the one that you describe, and I would like to
hear more details.

For example:
* are the UI designers and programmers within the same team but do
different kinds of tasks,
or do they do both?
* what are the UI stories (or backlog items) like, especially for user
research?
* do the UI stories count as "done", even when no software has been
written?

I've love to hear more about what you've seen.

Cheers
Robert Biddle

Marjorie H Pries wrote:

>
>
> Linda,
>
> To clarify, SCRUM is a method for delivering working software, UCD is
> not a method but a collection of techniques to determine software
> requirements and the human interaction aspects of the design -- unless
> you're going to some school that has cooked up some method they call
> UCD :-) .
>
> You can do SCRUM with UCD included in the activities as long as you
> have stories for the UCD tasks, you plan the stories into each sprint,
> and your UCD people participate in the daily stand-ups and report
> their status. The outsomes of the UCD stories become new stories for
> the developers in a subsequent iteration / sprint.
>
> Marjorie H. Pries
> Lead Consultant / Utility Infielder
>
> ThoughtWorks, Inc.
> http://www.thoughtw orks.com
>
>
> "Don't believe everything you think."
> --seen on a bumpersticker
>
>
> *"linda.hellman" <linda.hellman@ yahoo.com>*
> Sent by: agile-usability@ yahoogroups. com
>
> 03/04/2009 06:03 AM
>
> Please respond to
> agile-usability@ yahoogroups. com
>
>
>
> To
> agile-usability@ yahoogroups. com
> cc
>
> Subject
> [agile-usability] Scrum and UCD
>
>
>
>
>
>
>
>
>
>
> Hi,
> I'm writing my Master's Thesis at the moment and in my Thesis I'm
> trying to find the biggest problems between the two methods and then
> to integrate Scrum and UCD and create new user-centered Scrum.
> My Thesis is based on literature about integrating user-centered
> design and agile methods. My Thesis is almost ready and at the moment
> I am starting to introduce my process to one software project where I
> am the UE designer.
>
> I would like hear from You, what kind of actual troubles and problems
> You have had when using both Scrum and User-Centered Design?
> And what advantages has the use of both methods brought to the project?
>
> Waiting for your opinions,
> Linda.
>
>
>

 

[Robert Biddle-2]

 > Given that, the UCD member of the team is just another flavor of
 > business analyst and all of the analysts would collaborate on
 > just-in-time analysis tasks including user research and usability
 > testing. Programmers also pair up with analysts as needed to have
 > conversations, investigate technical issues, or research the business
 > problem.

Ok, I understand that. I'm not in complete agreement, but I think we
may be using words differently. For example, I think UI people need
skills and experience that are about human factors and design rather than
business, but you may mean "business" is some more general way. Also,
I'm not quite sure about "just in time": I would imagine some user
research might be done up front, rather than in the context of
specific story.

 > * are the UI designers and programmers within the same team but do
 >   different kinds of tasks, or do they do both?
 >
 > my answer: UI designers and programmers are just another flavor of
 > business analyst or programmer and they would collaborate with the

Ok, similar to above: I think I understand this, though I'm not sure I
agree with it.

 > * what are the UI stories (or backlog items) like, especially for user
 >   research?
 >
 > my answer: Like the term "methodology" we have to be careful with the
 > term "story".  "Story" is a thing that developers implement.

When you say "developer", are you meaning to exclude UI designer?

 "Tasks"

 > High-level tasks might be treated "as if" they were stories so it is
 > easy for the entire team to be aware of overall progress and
 > activities for the week.

Ah, this is the kind of thing I was wondering about. So you have
different kinds of backlog items, some are "stories", which (I think
you are saying) require full functional implemention. Is that right?
And others are different, such as user research, usability testing,
and UI design. Is that right?

* do the UI stories count as "done", even when no software has been
 written?  

 > More hairsplitting!  

Oh? I'm not sure why.

 > The purpose of saying a story is Done, is to have
 > a means of measuring the team's velocity -- how much implementation
 > gets done on average per iteration/ sprint.  Thus, in theory, you only
 > really care about Done if the story is a coding story.

Hmm. I'm not quite understanding this, and it seems different to what
you said above. It seems to me if a task is big enough to be managed
as a story, then they should be some similar equivalent to "done".

I suppose the key thing is that when a story is implemented, there is
nothing more to do, and hence we use the term "done". But this seems a
very programmer-centric perspective. For example, if the software was
beging developed in the context of some broader business product,
there may be more work to do once the software is fully implemented.
So I suspect this is becoming tautological: that the software is done
when the software is done.

 > It is important to see the status of those higher-level analysis
 > tasks, which includes the big UI tasks that precede the coding
 > stories. If UI work was substantial enough to make visible as a
 > "story" then you have to be able to say if it is not started,
 > in-progress, or done, and have target expected completion dates so the
 > team can get some kind of assurance about how and when the backlog may
 > grow or shrink.

Ok, so this is what I was wondering.

 >...
 > But, saying that these UI stories are Done, does not count in the
 > velocity equation.

Hmm, ok, but again this is programming-centric. If, for example, the
programming work was minor compared to UI work or more general
business product work, then we should be careful.

Anyway, thanks so much for writing this up. I have not actually seen a
team working in this way, and will now be on the lookout.

Cheers
Robert

[William Pietri]

linda.hellman wrote:
> I would like hear from You, what kind of actual troubles and problems You have had when using both Scrum and User-Centered Design?
> And what advantages has the use of both methods brought to the project?
>  

Hi, Linda. This may be a slightly more philosophical answer than you
want, but I think one important set of issues can be summed up by
Voltaire's maxim, "The perfect is the enemy of the good."

In my youth, I was very excited by the design of the internals of a
system, what is sometimes called a system's architecture. (Although
that's definitely distinct from the sort of design you're thinking of,
bear with me a bit.) Every time some problem came up in a live system,
the answer to me was obvious. I should have spend more time researching,
put more effort into analyzing, drawn just a few more beautiful diagrams.

For every new system, I'd redouble my efforts. But that never worked,
not like I wanted it to. Every time I'd put my theories into practice,
I'd learn something. Every time we'd try to build something, the world
would change on us. Every time we released something perfect, the world
would show us what we'd missed. I resented that terribly.

Agile methods, though, gave me the ability to make that a source of
strength, not a source of weakness. Now I start rough, and let the world
tell me what it needs. That doesn't mean that I don't put plenty of time
and effort into research and planning, as planning is a great way to
think things through. But it does mean I rarely have to bet heavily on
the perfection of my plans. Instead of a thousand bets being resolved on
one roll of the dice, I get to make my bets a few at a time, following
up on the wins and learning from the losses.

In the end, I get better results with less effort and less stress. I'd
never go back. A lot of software architects feel the same way.


This relates to your question because I think the world of user-facing
design is going through a similar transition that the software
architecture world has spent the last decade or so going through.
Designers face a lot of the same issues that software architects did,
with one added burden: they had to depend on those architects, giving
them even less control over both the process and the outcome.

It's my firm belief that things will turn out similarly. People will
create new approaches, new ways of working, and new techniques that make
short cycles and tight feedback loops a source of great power for
continuous improvement. In fact, they are creating and using them right
now. I've visited quite a number of agile shops over the last few years,
and although I've seen my share of disgruntled designers, I've seen many
more who say they are very happy, and even a few who say weekly releases
are great, but they'd love it to be faster.

William