Re: Moving on

So said  Glen B. Alleman  on  12/20/2002 --------------------

>>> So the problem is that the C-level folks don't feel the following
>>needs:
>>>
>>> * The need to lower per-customer engagement and support costs
>>
>>[>] we know this to the dollar and have specific goals to reduce this
>>cost
>
>XP says, "I can lower per-customer engagement and support costs by building
>quality in to the product, spending more up front, but less overall."
>
>[GBA] That's an interesting approach. When speaking to my boss, we have
>used
>quality increases and time and budget compliance, but not lower engagement
>costs. What's likely needed for general use is a case study or two for a
>non-trivial deployment that the C-Type can relate to. This will be nearly
>impossible I suspect, so increased quality and on-time delivery are better
>IMO.

Someone could likely get a Master's thesis out of analyzing the cost and potential savings on IBM's WebSphere Commerce Suite product by building simpler, higher-quality, out-of-the-box features that customers want and saving the remaining effort for customized solutions. As it is, that organization tries (or, was trying, as of November 2001) to pile features onto the core solution, makes them too complex and too difficult to use, then spends more money building customized versions of many of the same features for individual clients. Customer feedback is most definitely not being used as effectively as it could be. By concentrating on simpler mainline features and getting them right, they would save a bundle in one area, spend the same amount on engagements and get overall more value. Guaranteed.

>>> * The need to lower development costs by doing more with fewer people
>>
>>[>] our plans include specific reductions here as well as infrastructure
>>and telecommunications.
>
>XP says, "Your team should be smaller and in one room so that communication
>overhead does not begin to significantly eat away at the team's
>productivity."
>
>[GBA] This makes sense for most everyone.

So why doesn't it happen? I agree that One Team in One Room is not for everyone, but why does it seem that the people who'd enjoy it and benefit most from it aren't given the opportunity to do it? If one team in the organization made it work, perhaps others would buy in. Those who work well that way would do it; those who don't would not. How could that not be better?

If the argument is cost, it's obvious that most bullpen setups are less expensive than individual offices or cubes.

>>> * The need to improve customer satisfaction through delivering key
>>> features earlier
>>
>>[>] Actually our goal is "on time" "on budget." If you can start with
>>that, the "mythical" goal of early deliver is then on "option." But get
>>the stuff to show up when you say and what you forecast and many more
>>doors open to talk about process improvement. This is an issue I have
>>with the XP rhetoric, over promising the outcome of a promise before the
>>baseline of trusted delivery, cost control, and quality have been met.
>
>So rather than getting important stuff early, you'd rather get everything
>on
>the last day? That's backwards thinking, to my mind. The only way to get
>"on
>time and on budget" is to seriously pad both. I suppose that we could do
>that
>long enough to train you to think that we need that much time and that much
>money, then as we deliver important stuff quickly, you'll be pleased. What
>do
>you think about that?
>
>[GBA] This is a long standing discussion. I fact our customer would like to
>get what they order on the day we said and for the cost we said. All other
>processes are internal.

Agreed. This is where the use of the term Customer causes problems. Let us replace that term with "Product Advocate" for those cases where ongoin delivery to an outside customer (end user) is not appropriate. I have seen this idea employed successfully at IBM: an individual is responsible for acting on the end user's behalf with one voice. This individual makes decisions about feature priority, usability, and so on. This individual gets help from wherever it is needed, including from the programmers. This individual acts as the XP "Customer".

So what if we delivered the most important stuff to our Product Advocate early so that that person can steer the project, acting on behalf of our Real Customers? That person could have regular meetings with the Real Customers and manage their expectations, needs and desires.

The notion of Proxy Customer is well-explored in the XP community and appears to work, although not as well as dealing with the Real Customer directly.

>>[>] because the current words associated with "agile" are too extreme.
>>"agile" is a term used in manufacturing, finance, petrochem, etc. all
>>the time. But "extremizing" it cuts off those who need to listen. We use
>>"agile" terms all the time on site (de-construction project). But it's
>>in the context of construction and waste disposal. Mention terms like
>>"hair on fire," "balls to the wall," extreme everything and the
>>construction guys leave the room. Mention "agile" work processes that
>>save money, improve quality, deliver on time to spec and they perk right
>>up.
>>
>>It's all in the message, the terms used, etc.
>
>I'm not sure that's true, because I have done it with and without the
>rhetoric
>and neither has worked. Perhaps the managers simply don't have time to see
>what
>I'm doing right, because they're too busy dealing with the folks who are
>underachieving. Perhaps that means that I have to do good work in the
>presence
>of some lucky manager who actually has the chance to notice, ask me how and
>begin to buy in.
>
>[GBA] Good points. The focus on mis-performance and lack of progress is
>likely a managers first job. The next job is process improvement, but since
>poor performance improvement has immediate results, that's just what I'd do
>and have done here. The challenge of an XP-like process is to show
>immediate
>improvement, but the unanswered question is can XP do this with a mediocre
>team that is the source of the poor performance to begin with.
>
>XP does not state how performance can be increased with less the stellar
>developers. Yes there are anecdotes, but I'm always suspect of them. If the
>team is inhibited by external processes but has the native talent to
>perform
>it's clear XP can liberate them. I've consulted with many clients where the
>team is just plan poor and no process was going to add much. XP in those
>cases was just confusing, since the basic development processes were not in
>place - no requirements, no QA, no release process. In those cases ANY
>process would produce improvements IIF the developers could drop their bad
>behaviors.

If managers are trying to perform better with (only) mediocre people, then no process will help. Those people need to learn and improve. XP says that if you get them to pair with more experienced, more skilled people, then there's a much higher change that the mediocre programmer will improve than if left to his own devices. Again, XP provides a *natural* way to promote programmer improvement. It is not overt; rather it is covert; therefore, it tends to be less threatening.

>>> I identify the following problem: the C-level folks don't know that
>>they
>>> could do better. My guess is that they've grown accustomed to a
>>certain
>>> level of achievement and, through experience, don't see a way to reach
>>> above the current plateau. It takes one big organization to outplay
>>the
>>> rest of the field before they wake up and see that they're about to be
>>> left behind.
>>
>>[>] I'm a B-level working for a C and that's simply not true in my
>>experience. Yours may be different. We're constantly on the prowl for
>>new and better ways to close this site. We're constantly revamping our
>>SOP to take advantage of new ways.
>
>If the terms are enough to stop the C-level folks from listening to us,
>then
>I
>disagree with the notion that they are "on the prowl for new and better
>ways..." Someone who truly wants to improve the system will be open-minded
>enough to listen to the zealot -- it may just be crazy enough to work.
>
>[GBA] The C-Level guys are approached everyday with "magic" fixes.
>Marketing
>fixes, project management fixes, quality improvement fixes. If the terms
>don't resonant they don't listen. Please don't fall into the trap of
>assuming the problem is with the listening, it starts with the message.
>That's the foundation of any marketing strategy. If you don't have words
>that resonant, you'll never make it past the front door.

I realize that the onus is on the seller, not the buyer; but I'm not selling XP here. I'm saying, "If you want me to pull your project out of the fire, here is what  I will do. If you want me, you need to understand what you're getting." How can an interviewer sit there and tell me, with a straight face, "You're a smart guy; you obviously know your stuff; you have the attitude we're looking for and you come across as having the right stuff to fix our project; however, that XP stuff will never work." With respect, how the hell does the interviewer think I got this way?!

>You're statement of "they'll listen to the zealot," has not been my
>experience in aerospace, government, petrochemical, manufacturing. They
>simply discount the zealot on first principles - he's a zealot because no
>one is listening, so he has to shout louder.
<snip />

I doubt anyone's first victories were in such staid sectors and industries. No reason to expect that it should be different for XP.


>>> My question is this: where is the company that wants to be ahead of
>>the
>>> curve? I thought that C-level people went in for all that "be
>>proactive"
>>> crap.
>>
>>[>] They're there; maybe you need to look a little harder. Before this
>>position, most of my clients hired us for just that purpose - push the
>>envelope back on productivity and process.
>
>I wouldn't be surprised. After all, I don't have the vast experience that
>others on this list and in the community have. I'm just some poor b5d that
>was
>seduced by the promise of XP, has tried it and loved it, and wants to do
>more.
>I definitely need someone more seasoned in the art of communicating with
>management to create those opportunities for me. I'll buy 'em lunch and
>drinks
>and everything.
>
>[GBA] Maybe here on XC we can come to understand that the C-Types are 2 to
>3
>levels above the folks doing the work. My peers (3 of us) have never
>developed code. Our C-Type was a marketing and finance guy before CIO. I
>was
>a coder in the 70's and 80's when real men wrote in Fortran and Macro-11.
>Until the current crop of Java and XP'ers reach their C-Level positions,
>the
>words used for "agile" need to be tailored to the audience not the other
>way
>around.

Clear enough.

>If the XP'ers continue to demand that the C-Types "listen" to the zealots
>it's going to be tough sledding. Which is really too bad, since there is
>great need if the "marketing story" can resonant with the decision makers.
>It's starting to happen - Jim Highsmith, is one example. But viral
>marketing
>is a serial process.

The tough question is this: where do we find our first victories? It certainly has to be in organizations where the decision makers are "hip enough" to understand what we're talking about. That is where we can build the portfolio, I guess.

I find it sad, though, that large organizations would rather see academic studies than results from smaller commercial ventures. They'd rather see it work in a test-tube than in (a smaller version of) real life. Am I wrong in stating this? It's just a feeling I have.


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/