Re: Re: Summing up and moving on (I hope)

Hi Dale,

Dale Emery wrote:

> > > Yes, that's what I'm asking.  Specific examples.  I think I
> > > understand the cost problem.  I'd like some specific examples of
> > > culture clash.
> >
> > Conversing with business folks in technical language, hygiene,
> > overall appearance, apparent disdain for co-workers ("users"),
> > approach to productivity improvement.  More?
>
> This is helping.  To get closer, I think I'll try a different
> approach:  Tell me a few stories about these things.  Tell me a story
> or two about how some IT folks showed disdain for coworkers.

I've found the pervasive use of the word "user" to be one source of that
perception.  The term has mostly negative connotations in our society since
it's often short-hand for "abuser" as in "drug user."  Another source of the
perception comes from the experience of having a programmer come in, spend
too little time with a domain expert to make them feel comfortable that the
programmer really understands their job and how a piece of software can help
them.  Then not come back until the software was "done" and it wasn't what
the business person really needed.  Another source of the perception of
disdain derives from the dress / hygiene "code" which says to the business
person like "I'm more important than you.  You can tell because you have to
dress nice and I can wear jeans and not wash my hair."

> Tell me
> a story or two about how differing approaches to productivity
> improvement created friction.

With the exception of software development, just about every business
function I can think of has been subject to expectations about productivity
improvement.  Manufacturing in particular, but other areas as well.  Much of
the productivity improvement in these areas is expected to come from
software, of course.  What too often ends up happening is that automation is
introduced which increases efficiency at the expense of flexibility.  The
reduction in flexibility often leads to additional work to manually
work-around special cases which, depending on the situation, may not be that
rare.  The expectation of increased efficiency, of course, often leads to
headcount reductions based on the work the software was designed to
automate, not the special cases.  So the business folks are left with a new
system that they have to learn, fewer co-workers, and a new problem of how
to get the special cases into the system.  Feel their pain.  Now imagine
their reaction to the IT organization's exemption from that same process.

[snipped duplicate question]

> > > One possible way to respond to the gap between supply and demand
> > > is, "Gosh, we love what you IT folks have done for us!  The
> > > tremendous value youve created helps us to see so many
> > > possibilities for how you can help us in the future!  Thank you!"
> > >
> > > Why not that response?  Why friction instead?
> >
> > IT folks began making more, much more, that folks with similar
> > seniority levels.  That breeds resentment in and of itself.
>
> Interesting that people would direct their resentment toward the IT
> folks, and not toward the managers who determine what to pay.

The managers who determine what to pay are IT managers, so the resentment is
directed toward the entire IT organization.

> > Coupled with a perception that IT folks took the position that they
> > deserved it because their work was somehow inherently more valuable
> > (as opposed to being a demand-driven phenomenon) than that done by
> > the folks performing the customer facing work, friction was probably
> > inevitable.
>
> Yes, I can see how that would be a problem.
>
> What I'm seeing underneath all this is that non-IT folks are feeling
> less appreciated than they were, or less appreciated compared to IT
> folks.  Hmmm.  With an outsourced IT department, non-IT folks aren't
> reminded so often of this (im)balance of appreciation.  Hmmm.

I said the following in the posting to the XP list in which I announced the
formation of this list.

If asked to boil my learning down to one sentence,
here is what I'd say.

XP is a response to the eXcessive Pain the traditional
approach to software development all too often causes
*everybody* it touches.

> What if users (and the users' direct managers) had more of a say in
> what the IT folks services were worth to them?  What if IT folks were
> paid by their customers instead of by "the IT department?"

That, in a very real sense, is what outsourcing gives them.

> > > Suppose the business folks isolated themselves from the culture
> > > clash
> > > by inserting consultants between themselves and the IT department.
> > > How would that compare with inserting the consultant between
> > > themselves and an outsoured IT organization?
> >
> > In some cases that happened.  Then the outsourcer pounds on the cost
> > button.
>
> So if you eliminate culture clash as an issue, you still gotta deal
> with cost.  I'm starting to see how XP might help with that.  If XP
> can lower costs enough, perhaps the overhead inherent in outsourcing
> would become more apparent.

I don't think cost will be a huge issue with Customer Intimate and Best
Performance companies.  I'm guessing Agility is more important as long as
the cost differential isn't huge.  To service one of these customers an
offshore producer would have to put people on site, raising the cost to the
customer.  Also, in these types of companies, company specific domain
knowledge becomes very important.  I think XP only needs to be shown to be
more cost effective than BDUF on-shore outsourcing.  An on-shore outsourcer
could, of course, adopt XP but then, given that the culture issue goes away,
what's the benefit to using an outsourcer over taking the IT dept. back in
house?

> > > How do you see XP reducing the culture clash without resorting to
> > > buffer-consultants and outsourcing?
> >
> > The on-site customer gets a chance to develop more than just a
> > passing impression of the developers.  Gets a chance to see them
> > struggle, gets an appreciation of their work.  It creates a
> > situation where it's near impossible not to develop a relationship
> > between the individuals.  That differs greatly from the DUF
> > situation where the analyst comes in, spends a little time with the
> > business person, and then disappears until the software is "done."
>
> I can see how these things would build a healthier "distribution of
> appreciation."  From the on-site customer's point of view, at least.

Think emissary.

> > Customer Intimacy wasn't happening.  To the contrary, it was more
> > like the antonym; Customer Enmity.
>
> Can you see some of the things that XP teams do to directly address
> that problem?  Would your (potential) clients be interested in those
> parts of XP?

On site customer is the biggest thing.

> > BTW, thanks for the use of the CTC terminology.
>
> I think I used "Discipline of Market Leaders" terminology, not CTC.
> Like you, I think DML is helpful here.

Oops.  Typing instead of thinking. :-p

Best regards,
Bill


------------------------ 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/