Re: Scrum and UCD

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: