... people ... I think we (IT) need to stop TELLING customers what they want, and actively engage them in telling us what *they* want. We need to becomeMessage 1 of 33 , Aug 3, 2003View Source--- In email@example.com, Boris Gloger <boris@g...>
> How do you change the organization in a way that the businesspeople
> accept that we (IT) questions their view.I think we (IT) need to stop TELLING customers what they want, and
> > I think the Agile movement is trying to redefine
> > what successful development looks like. Success in development =
> > demonstrable value for the Customer.
> > Who decides what this is?
actively engage them in telling us what *they* want. We need to
become excellent "askers of questions". Perhaps this is another
important shift Scrum requires: that we have the humility to become
the student rather than always the teacher. Within our own domain is
one thing - but in the Customer's domain, we must let them drive. If
they don't know how to drive, we must find the talent within IT to
teach them to drive.
> > As evaluated BY THE CUSTOMER
> > (hence, active stakeholder participation). That's it! (Remembering
> > that ease of maintenance is also of value to the Customer - and we
> > must educate them in this).
> Your are right, but you can not educate someone who does not want
> learn.True. That's why I'm reading on Leadership these days. I'm convinced
that we must become leaders, whom others want to emulate and follow -
and more importantly, we must over time teach all members of the team
to take leadership when appropriate (including Customers). I've seen
this done, and it's awesome - it develops the true meaning
of "empowerment" (a word much maligned these days because it's been
hijacked or abused by those with other agendas).
... Christian: But in Scrum we also show what is done every day. Remember, Daily Build and Daily Scrum are basic Scrum patterns. A while ago JeffMessage 33 of 33 , Aug 12, 2003View Source
> 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.