Customer Bill Of Rights Discussion
Customer Bill Of Rights DiscussionQuoting from CustomerBillOfRights:
You have the right to:
Do you treat your colleagues like that?
Like what?
Like the things they say to you are "noise". You must be a lot of fun to work with, using that attitude.
Well, as I said (and somebody deleted) I am asking a question. All of this Extreme This and Extreme That is a violent departure from the norm when it comes to a development paradigm. What is the impact? We're exploring that here. Please don't DisagreeByDeleting.
[I think your choice of word, "noise", might have drawn some defensiveness, to the point that your question might appear to be trolling.]
Right. Sorry. Okay, let's examine away, shall we? Proceed apace.
Prioritizing the User Story
This seems to be similar to QFD (the Zero Sum Game). The only real way to make "user stories" work with priority is to assign a total value to all stories, then dole out relative values to all stories until their sum is equal to the total. That way there is no interpretation on the part of the development team as to what actual value a customer puts on a specific task sequence. Otherwise Story A may be more valuable than Story B which is of greater value than Story C, but the dev team needs numbers to tell them that A is valued at 6, B at 3, and C at 1. Knowing those relative values puts a whole different spin on things.
What you miss here is one week iterations. The Developers have the overlapping right to know exactly what to work on, this week. Pushing some UserStories into the future is itself a design technique. So you can't have a "zero sum game" if the sum is totally nebulous.
We seem to be confusing the management of scheduling with actual design. Delaying work on a feature set isn't a design technique; it's a schedule management technique. When a product's features are all analyzed in relation to each other then the architect can determine what baseline functionality needs to be created to support all the features in their proper priority.
Thusly, a system can be designed to meet the requirements of real time by sacrificing some user interface responsiveness, for instance, or data security to the detriment of storage capacity. These are real design time considerations, and result in the dev team's focus being placed on certain lines of development before other things are accomplished.
The overall plan and its cost and schedule
Knowing what a plan will cost to implement and how long that plan will take to achieve is more a matter of defining the endpoints rather than working out the details of the plan's execution. Remember that a product must be based on an unchanging architecture to achieve anything. (Architecture is base, irreducible, and immutable.) Setting a plan into place requires that the plan (and its resulting architecture) go through some sort of formal inspection process to know that it is error free. The FaganDefectFreeProcess is one way of insuring that the plan is sound before committing resources to it.
Value every week
This seems to be one of those things that sounds good, has some meaningful arguments to support it, but may not be sustainable in certain product development environments. Much embedded system development is hung up on hardware that takes time to create, so progress that the customer can measure may take more than a week to produce.
The point is that Value exits the programmers' lab, and enters the pipeline, every week. The length of the pipeline might of course be outside of the programmer's control. The programmers and customer must agree on what rates that value, if user acceptance cannot.
Okay, but that value may not be measurable in terms of end user visibility. This week the dev team worked out a client/server exchange that reliably and securely transfers control of a subsystem from one client to a peer client. This control authority is the high level equivalent of a Singleton being passed about. The end user will never know the difference, but it makes all the difference in the world to the systems being utilized. How does the user measure this value?
Proven progress backed up by tests
Yeah, okay. You guys already know how I feel about tests versus inspections. -- MartySchrader
I must have missed the part of "Agile" software development that says you should never inspect. Got a cite? (Besides PairProgramming?)
Well, bunkie, "Agile" isn't the end-all, be-all of software development, now is it? In the only environments where I have been allowed by the client to replace testing with inspection the inspection has expressly saved our bacon prior to the product going up for FDA or other regulatory review. All of the previous testing hadn't caught the bugs that inspection noodled out. You'll never, ever, ever convince me to replace the inspection process with testing, not ever again. -- MartySchrader
Make changes in the requirements
Remember: once an architecture is set, that's it. Architecture will tell you what is base functionality and what is feature-related functionality. Go ahead and let the customer jerk all the features around that he wants. But if he threatens the base functionality of the product then the dev team has got to put its foot down.
Any changes in requirements have still got to go back through inspection for you to know that nobody has injected problems that will come up later. The idea here is to allow the customer a long leash, but to have a hard stop when he runs out of rope.
Know about schedule slip and be able to fix it
You know, if everything in a project is properly inspected before work begins then the whole question of schedule slip should be moot. The reason you go through the hassle of formally inspecting the requirements, specification, architecture, design, and code is so that you know there are no problems. Things do happen, still. The easy way to fix schedule problems is to drop features. If the design was done properly this should be a piece of cake, eh?
Cancel project at any time and still have something that works
I disagree with this in the strongest terms. My projects are based on timetables and payments schedules, so I set a functionality goal and a completion date for a certain level of progress, with a corresponding payment. If the client wants to proceed then away we go on the next step in the timetable. To cancel "at any time" puts me in a nasty, risky position.
The thing is, there are lots of projects that require the dev house to buy unique hardware, software, or training to complete some portion of the project. Even a significant piece of client/server exchange may require a big slug of development time, so either there needs to be some contractual obligation for the client to pay for development time or a substantial retainer up front. I am not willing to depend on the client's largess when he realizes that he's made a significant strategic error in ordering this product to be developed.
See: CustomerBillOfRights
Contributors: MartySchrader
EditText of this page
(last edited January 17, 2011)
or FindPage with title or text search