RE: Customer involvement and process improvement

>[>] snip
>> But what if advanced delivery is a step on the way to on time on
>budget?
>> What if advanced delivery helps us practice "on time on budget" every
>two
>> weeks? Practice makes perfect.
> 
>[>] No doubt advanced delivery is a value process. What needs to be made
>clear (and often isn't) is "who is the target of the advanced delivery?"
>Most of the XP literature assumes that the target is the "customer"
>without every considering if the "customer" can absorb these rapidly
>evolving releases. So I no objection to rapid (release cycles, that
>would be foolish) - just need to ask and answer "how will the value be
>felt and who will fell it?" before getting too enthusiastic about a
>concept with no domain or context.

One of the goals of frequent/small releases is to get feedback on the appropriateness and correctness of the currently-running software. It is assumed that the customer will provide that feedback, whether directly or indirectly, because they are the expert when it comes to answering the question, "Is this the feature we need?" This is another case where we are confident that they would benefit from even a little more effort, but where they tend (for whatever reason) to underestimate that benefit. So if we had more feedback: (1) the programmers would feel the benefit by having increased confidence that they are doing the right thing and correctly; (2) the customers would feel the benefit by being better able to steer the project; (3) the company would feel the benefit by minimizing time spent building the wrong thing, or building the unimportant thing, even if it is built well.

Another goal of frequent/small releases is for the programmers to get periodic feedback on the accuracy of their estimates, through iteration retrospection and iteration planning. It has been shown that estimating smaller units of work more often leads to more accurate estimation on the whole: sporadic errors tend to cancel out and systematic errors tend to be uncovered more quickly. The risk of not knowing our real progress is mitigated by computing our velocity often. We need to release the software in order to do this, otherwise there is no (external) motivation to ensure that features are 100% correct. This avoids the all-too-common "90% syndrome", where every feature is 90% complete and nothing really works. So the programmers feel benefit by finishing features completely along the way, rather than tying up many loose ends near the end -- something they won't be good at, since they'll have forgot the details of what the feature needed to do. The project planners feel ben
 efit by having more information earlier about the progress of the project *and* that information will be empirical, not depending on some programmer's hunch. I have learned to trust the numbers, even if I think I can go faster.

>> >(3) The presence of an XP customer is part of the XP success. XP has
>> little
>> >to say (getting better) about how to transform a customer into an XP
>> >customer.
>> 
>> From what I've read, XP says that a customer is already an XP customer
>--
>> that no transformation is required. I understand that others have
>horror
>> stories on this front. I claim that no transformation is required, but
>> that the customer needs to know up front what's expected, and either
>> they're willing to commit (we can do XP) or they are not (we can't).
>We
>> admit that without a customer*, the project is dead in the water, XP
>or
>> not.
>
>[>] Oh I'm not sure this is the case. If XP requires a fully cognizant
>XP customer, the population is now very small for the XP practices. What
>about customer that move in and out of XP? Have needs not supported by
>XP? Etc.

I don't understand how a customer moves in and out of XP -- can you clarify what you mean here?

As for needs not supported by XP, can you name a few of those needs? The XP practices largely deal with managing the programming aspect of a software project as well as building the software itself. For "other needs" not directly related to these aspects programming team, the XP practices were not intended to handle those needs, anyhow. Still, XP is more than the practices -- it's a philosophy, an approach that can be used in daily life, let alone to address those needs you mention.

>> >(4) Understanding, tailoring, and focusing the "marketing message" is
>a
>> >sign
>> >of a maturing process. This happened with TQM, Six Sig, BSC, "Change"
>> >processes, etc. All started as zealot processes and matured to broad
>> based
>> >processes by transforming "their" message not transforming the
>listeners.
>> 
>> I recognize the need to change our message to make it sweeter to the
>ears
>> of our intended audience. I don't know how to do that. Will you help
>me do
>> that for one of these aspects of XP that I'm trying to market?
>> Arbitrarily, I select "Ongoing Customer Feedback". Are you willing to
>> start that discussion on this group right now?
>
>[>] Sure. First I'd start with asking and answering some questions. 
>
>For the ongoing feedback to have value, we'll need to define the
>improvement goal. Schedule, budget, requirements, quality, other
>intangible attributes. For what purpose is the feedback being provided
>and solicited?

See my comments above. There is more, but we can explore that as we go.

>How will we know when the ongoing feedback is producing
>results?

One way to know is to compare the XP project's progress to historical results. I won't claim that this will indicate that ongoing feedback *alone* is responsible, but we recognize that it's generally impossible to attribute improvement to such an individual aspect of the team's operation, so we don't worry about that too much.

>What results are we after?

We would like to minimize the time it takes for a requested feature to be available to deliver into production, concentrating on making *valuable* features (as defined by the business) available more quickly.

>Once the results goal is defined,
>how will we plan each cycle of the feedback process to move us forward?

Every two or three weeks, we will give the business an opportunity to do two things: evaluate how well the programmers implemented and delivered the recently-requested features and decide which features are the most important ones to implement next. We'll meet for half a day, demonstrate the features we have completed, provide a working copy for the business to evaluate on their own time, then review the remaining features, estimate their cost and let the business use that information to decide what to do next.

>How will we engage individuals, groups, amorphous blobs of
>organizations, the various stakeholders?

I don't think I know what you're looking for here. Can you clarify the question?

>How well we package the message
>for each of these groups, confirm they are hearing the message, and
>alter our communication processes to match theirs once we determine the
>message is getting or not getting through?

If I knew how to do that, I wouldn't need your help, Glen. :)

<snip />
>[>] In our Balanced Scorecard we have a role called "performance
>advocate." This person is assigned to be the advocate of the process
>improvement portion of the BSC. This may be the approach that could work
>for you. 
>
>I would suggest though (as we have learned) that the "problem" be
>defined before the solution is provided. XP looking for problems is no
>different than a hammer looking for nails to hit.

"XP" does not do that. XP is a response to felt needs. XP solves problems so engrained in the software development industry, that I fear that the community has got used to the problems and no longer regards them as problems. In that case, what can we do?

>So type of "gap"
>analysis for the "product" may be the starting point. Getting by-in that
>a gap analysis is needed is the first step in isolating the "felt need."

So you need to convince other people that you have a problem instead of just saying, "I have a problem?" Oy. Maybe I misunderstand.

>Once the gaps have been identified, "owning" those gaps is necessary. We
>have that problem all the time and rightly reject improvement for
>improvement sake. "I know that process suck, but it'll continue to do
>that because there is not bookable savings to fix it..."

So because you don't know exactly how much you'll gain from changing how you do things, you don't stop doing actively and obviously stupid things? That just sounds silly. It's the kind of thing that immediately sounds wrong.

>Once the "bookable savings" or "measurable improvements" are identified,
>THEN a process improvement process can start.

I get the feeling that this approach assumes that those on the front line aren't capable of making good decisions about how to improve the process at the lower levels. It looks like a centralized decision-making approach that is, I think quite plainly, doomed to failure, because the decision makers don't understand the problems.

Alistair Cockburn's talk about the importance of microtechniques applies here. Most process improvements are not overhauls, but a longer series of small changes that try to take advantage of short- and medium-term trends to maximize effectiveness. In this case, it is impossible to calculate bookable savings, although improvements are easily noticed without being measurable. Are you saying that we shouldn't improve things because the Big Bosses can't be sure exactly how much a different it makes? Unless they join the front line, they'll never, ever know, because it all depends so much on "here and now".

>Now if you in a situation where these types of business processes are of
>use or if the messenger thinks the home work doesn't need to be done
>(and I'm confident you're not in that category), then this is where the
>gap opens up between XP developers and C-types...but we al know that I
>hope.

I didn't understand this sentence. Thanks.


J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603
All correspondence (c) 2002 Diaspar Software Services.
If you want to use it, just ask; don't steal.




------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/