Getting the REAL Customer - was Re: More newbie questions...
- --- In email@example.com, Bryan Zarnett
> I feel customer is a poorly chosen word because the customer can
> such a wide definition. In a Online-banking System who is thecustomer?
> I personally am the customer for the banking system created bybusiness
> TD/Canada Trust according to the banking representative. The
> analyst is my customer in the development of the product.Actually, this is exactly the problem I ran into on another project -
the BA standing in for some "general public" led us to create all
kinds of stuff that real users didn't really need. It bloated the
product, pushed the timelines out, and the customer cancelled before
getting their most important features. This was because the BAs
understood the business, but not the *priorities* of our customers.
I'm not sure this was the fault of the BAs themselves... it was a
failing of the company in general to not recognise the risk in this
I think we need to be very wary of "surrogate" customers (like BAs),
and first try to get the best possible (most real) customer we can.
After that, I agree that it falls to IT to educate and assist them,
in the interest of making the product meet their needs.
As a BA in my current position, my career goal is to work myself out
of a job. I will educate and facilitate, set up intelligent systems
for maintenance of minimal "living" documentation needed by IT for
the software lifecycle, and teach the Agile values and practises
using Scrum. When some time has passed, if I do these things well, I
hope that both developers and key users should be very capable of
working together without me "translating". Perhaps I will still
facilitate Sprints - maybe I'll become a PM or move over to another
team to coach Scrum... but if my position still looks like it does
today, in 2 years, I will have failed.
(PS: Ron, if you're out there... If I'm lucky, I'll get some pair-
programming time and become a developer again :-)
> From: "Christian Knott" <chrisknott@...>Christian:
> With Scrum, we get to show what's been done every 30 days. That means
> that the "alignment smell" gets to be put on view once a month
> instead of, well, never in many other cases.
But in Scrum we also show what is done every day. Remember,
"Daily Build" and "Daily Scrum" are basic Scrum patterns.
A while ago Jeff Sutherland pointed to an article written by
Martin Fowler about continuous integration. All good and dandy.
It is great to have things like Anthill produce automatic builds
and run batches of unit tests. But it is also important for
the Customer to interact with stable versions of the application
and give feedback from hands-on experience on a daily basis.
Also, there are things like Fit and Fitnesse that attempt to
Automate "acceptance testing". Our style is to do this
through "human interaction" -- there are some things that
we feel are best leaving non-automated i.e. where we want humans
In our development we have perhaps hundreds if not thousands
of builds every day, and thousands of check ins and updates,
but we advertise at least one stable build daily for the customers
to play with.
> For the specific problem of fuzzily defined requirements for reports,done.
> I'm with Ron, pretty much. My difference: do something. Anything.
> Guestimate what the report should be, do it quickly, then mark it
Well, "mark it done" might be pushing your luck.
Some customers take it very offensively to "mark things done"
if they are not done. But certainly, getting a report out
for someone to see will start the feedback loops. (Don't forget
to update your daily estimate to completion after some work
and feedback are produced :-)
> The donors/owners will soon start griping, and you can convertTrue.
> their gripes into requirements that go on the product backlog.