RE: [scrumdevelopment] Getting the REAL Customer - was Re: More n ewbie questions...
- All good points.
Ken's story could also be interpretted as delivering what the customer
really needed in the short term even though it was contrary to the overall,
long-term corporate plan. This is yet another corporate political pitfall,
where it is unclear as to whether IT should be enforcing the corporate 5
year plan or the customer should be responsible for knowing the direction
the company wants to move it and taking responsibility for the compliance
I have seen the same kinds of issues occur when IT is given the
responsibility to create architectural standards and enforcement them. In
many cases where this happens, corporate customers end up developing their
own low-quality, point solutions to avoid the hassles, costs, and time
delays that working with IT imposes in this kind of climate.
I doubt any development methodology can fix these kinds of political
From: Deb [mailto:deborah@...]
Sent: Sun 8/3/2003 7:30 AM
Subject: [scrumdevelopment] Getting the REAL Customer - was Re: More
--- In email@example.com, "Ken Schwaber"
> I worked with a one-year fixed budget project. The department headwas
> delighted with the functionality. The IT management felt that shehad
> unwisely spent the money on short term enhancements and not derivedthe best
> value. The question is, who is right. The customer? or the auditor?Ah yes. The "who is the Customer?" question.
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?
If we deliver the requirements of group A as software to group B, we
become political pawns... this happened in a large crown corporation
where our requirements came from HR for a system that would move HR
work out onto the corporation's department heads... as an analyst
(and a consultant), I had no idea that HR was not mandated by the
receiving parties to define requirements... the resulting system was
unintelligible to the end users. I realised too late that we'd been
made the agent of a significant organisational change, imposed on the
receiving managers in the guise of a new system. Sigh.
We must also be prepared to live with the organisational flak if we
deliver to the real customer exactly what they want, but other parts
of the organisation disagree - it sound like Ken's story above is one
We deliver software to Customers, that's what we do. Organisational
priorities and politics probably are best left outside the project,
if we can.
Does anyone have any success stories about getting the real customer?
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service