Re: [agile-usability] help wanted
- Wow this sounds wonderful! I like the job description... shux on the East Coast! ;-)! Good luck to you all.
Cindy Lu <hfe_consulting@...> wrote:Hi! Jeff,Are you still looking for people? If yes, in what location? I am located in New Jersey. I am interesting in positions in NYC.Thanks!- Cindy
Jeff Patton <jpatton@...> wrote:
I hate people advertising things - unless it's useful and targeted to
the list. Hopefully this one is.
As a few might know, I work for a company called ThoughtWorks. Those
familiar with the Agile landscape might have heard of ThoughtWorks
before. But for others, ThoughtWorks is a consultancy that
specializes in delivering projects using agile approaches. Please
look at the website for more information: http://www.thoughtworks.com
Happily for me, I've been somewhat successful raising the importance
of using User Centered Design approaches along with traditional
analysis and requirements elicitation approaches. Unhapplily for me,
there are only a couple of folks in ThoughtWorks US that can do this
sort of work, and now demand exceeds our capacity. We need more
people. We're looking for strong generalists - folks proficient in
working with software requirements using User Centered approaches.
You'd need to be confident working with clients from project
inception - needs identification through user interface prototyping,
then help to guide the day to day development in an agle customer
If you're interested, please contact me off-list at
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
Click here to donate to the Hurricane Katrina relief effort.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
- --- In email@example.com, Cindy Lu
> Hi! Jeff,Yes & no... mostly no.
> Are you still looking for people?
Quite a few people responded to my original post, and I have resumes
for a few very qualified people. When I originally dropped the
message in, we needed people desparately, and I wanted to funnel the
right kind of people into our recruiting engine. Quckly things
changed to having a bit of a surplus of people, so we're in a hiring
holding pattern - likely through the end of the year.
One of the things I quickly had to warn everyone that responded to
the message, and something I should have put into my original post,
was that ThoughtWorks is a consultancy dedicated to Agile
development. One of the tenets of Agile development is face to face
customer collaboration. In short strokes that means all of our work
is on-site with customers. That means plan on working everywhere and
nowhere - plan on travel nearly 100%. [Saturday I'm headed from Salt
Lake City where I live to spend a few weeks in Sydney for a client
I'm responding to this post verbosely because bringing up the role of
a UCD person at ThoughtWorks actually has a lot to do with the role
of a UCD person in any agile context.
In most agile contexts while there's the idea that there's one team,
there's a bifurcation around requirements and planning. Those that
determine what requirements are and what to build first fall on one
side - that side is referred to as the customer team, or simply
the "customer" - customer being a role - not necessarily a guy with
wads of cash in his pocket itching to buy some software. On the
other side are the people who take those requirements and build the
software in short development increments.
UCD people generally fit on the customer side since they help decide
what to build and how it should work.
For those of you doing UCD type of work, you likely know by now that
it's not agile processes that neglect this sort of design work,
it's /all/ software development processes. As a result, many of the
clients we deal with don't usually know what a UCD person is or
does. If the app needs a GUI and they'd like it to look good, often
a UI-person is pulled in late to "make it pretty." So, at
ThoughtWorks, and in many organizations, people who work with
requirements are called "analysts." ThoughtWorks hires business
analysts. Those business analysts work on "customer teams" working
directly with our client's business people and end users to
understand the business process and the software to be built and then
communicate that into development as user stories - little bits of
The work I do within ThoughtWorks is to raise the level of awareness
about the extreme amount of overlap between user centered design work
and requirements gathering. I have hopes that our business analysts
would use a blend of UCD techniques and traditional analysis
techniques. What analyst couldn't benefit from contextual design
style interview and observation skills? - usage-centered design role
and task modeling skills? - or goal directed design's persona
I remembere being at the Agile 2005 conference this year and talking
with Lynn Miller from Alias [who's experience report you /must/ read:
http://www.agile2005.org/XR19.pdf%5d. She mentioned that there were
all these poeple talking about the customer, and that it wasn't till
well into the conference that she figured out that /she/ was the
customer - in her words "they're talking about me!"
So to summarize:
* UCD people, you're "agile customers." Did you know that?
* I believe most people in software development don't know what UCD
people really do, so to them you're "business analysts." Did you
ThoughtWorks always benefits from having good people that can help
that agile customer role. We call them business analysts - cuz
that's what our clients understand. The best people in that role
have user centered design skills - along with a lots of others.