RE: [scrumdevelopment] Getting the REAL Customer - was Re: More newbie questions...
- I agree Bryan,Deb, maybe if you went after the real end USER audience (there might be multiple) you might have discovered the political scene in time to keep everyone happy or at least be cognizant of who you were going to please and who would be alienated. If HR would have walked you over to the desks of the people they expected to foist the system onto and left you there to chat with them unmoderated you would have learned what you needed to.As a rule of thumb, whenever business analysts categorize groups of users as audiences and attempt to define their needs it can be very productive to speak directly to members of each audience, especially if you think the business analysts are not doing so or are patronizing them.Mike.-----Original Message-----
From: Bryan Zarnett [mailto:bzarnett@...]
Sent: Sunday, August 03, 2003 11:06 AM
Subject: Re: [scrumdevelopment] Getting the REAL Customer - was Re: More newbie questions...
On Sunday, August 3, 2003, at 11:00 AM, Bryan Zarnett wrote:
I feel customer is a poorly chosen word because the customer can have such a wide definition. In a Online-banking System who is the customer? I personally am the customer for the banking system created by TD/Canada Trust according to the banking representative. The business analyst is my customer in the development of the product. The customer of the BA is a series of mysterious product owners associated to the bank? Which one is the real customer? Who is the customer? In this circumstance though, the BA is the business advocate.
On Sunday, August 3, 2003, at 10:30 AM, Deb wrote:
I wonder if this is not one of the biggest roadblocks to Scrum
success - not talking to (not being allowed to talk to) the "real"
customer. If we don't get access to the right Customer
representatives, don't we risk building more shelfware?
> 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.