RE: Re: Sticking point

Bill,

> Perhaps we have differing understandings of "customering."  For me, it
> includes everything outside the technical team and their decisions re: a
> project / product.  "Customering," for me, specifically includes those
> managerial decisions about practices that have behavioral / cultural
> implications for the organization and the people who work there that, in
> turn, have implications for the adoption of agile methods in
> general and XP in particular.

Perhaps this way of defining is a source of some of my difficulty in
catching on to this point of view. It's a negative: "everything outside..."

I'd like to describe my personal mental model, which I have been trying
to reconcile with the one you give above. Maybe it will be helpful. I
find it more useful to look at three pieces:
* The definition of value - what I originally took customering to mean
* The production of value
* The management of the combined process

Value definition is primarily but not entirely non-technical - in some
domains it can get pretty close to an even split. Lots of people in
an organization get to define value. Some of them are upper managers who
provide broad goals for others to meet. Some of them are middle managers
who translate those goals into things like releasing a new product version
in the third quarter. Some of them are in the Customer role, filling in
the details of the value to be created. And some of them are even
programmers, providing feedback to the Customers, who provide feedback
to their managers, etc.  Some people talk about the higher-level parts
of this as management. I find it useful to separate out this function
of defining value.

Value production is primarily but not entirely technical - for example,
deciding the order of producing pieces of the end product has both aspects.
There are some high level parts of value production as well: most large
organizations have established architectures, installed software bases,
legacy data and policies about how individual projects should fit in
with these things and procedures for making exceptions. At the lower
level, we try to make it so that the value-producing team - consisting
of people who are called programmers, customers and even managers - is
able to ignore - or mostly ignore - the existence of the higher level.

Management is both technical and non-technical, but performed at a higher
level of abstraction and sometimes at a "meta" level when discussion of
process is involved. It's also divided into varying levels of abstraction,
usually mapped to the organization hierarchy. For example above a certain
level, the actual process of producing value becomes irrelevant. But there
are also some managers whose primary job it is to install an appropriate
process.

My point here is that the simple division between technical and
non-technical
isn't really sufficient. Things are more complicated than that. I'm not
arguing for my own personal model to be use, but simply pointing out
that some such model is needed to structure discussion. Defining the
topic by what _isn't_ in it seems like a smell to me and I've been
trying in some recent posts to articulate why. Hope this helps.

I'm not quite sure how we got here from the topic of daily exercise though.
;-)

Charlie Poole
[email protected]
www.pooleconsulting.com
www.charliepoole.org






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