Re: [AM] Reporting in

All of this reinforces my conviction that performing a bit of "business
modeling" and upfront work along with the customer pays (along w/ neat &
understandable deliverables).

This week I was meeting with a to-be customer. The level of the
representative was just below CEO (the company is quite large) and it was
the marketing manager for the whole of EU.

We are pitching for a new concept and it requires significant IT involvment.

Guess what, the representative just tought that IT was speaking some kind of
alien language and was *afraid* in running into discussions (I wonder
whoever he deals with).

It took a significant chunk of time to overcome that fear on his part.

Link this with the fact that the buying decisions come from that level...
code-centric approaches really do not cut it here.

/Philippe Back
www.highoctane.be


----- Original Message ----- 
From: "Jim Standley" <[email protected]>
To: <[email protected]>
Sent: Monday, 09 February, 2004 00:27
Subject: Re: [AM] Reporting in


Thanks for sharing the outcome of all that. It's good everyone came away
relatively happy. I still view agile software development practices as
highly focused on producing code. I'd say your team's internal practices
are not necessarily less agile than before, but you've run into the
boundary where your processes touch others, and some times others will
require some additional things. Our team tries to run a fairly light weight
operation, but we have to interact with a number of other organizations so
that we wind up producing documentation that doesn't help us deliver
running code but does help others support us. It's just the price you pay
for living in the world.

At 07:55 AM 2/8/04 -0500, you wrote:

>Iâ?Tve been away on site for the past month spreading the gospel as it
>were, and am taking off a week in Key West to unwind, reenergize and
>collect my thoughts some of which Iâ?Td like to share with the Agile
>Cognoscenti assembled herein.  I perceive the typical member of the forum
>is a consultant of some stripe ensconced in a development effort or two
>using or wishing to use an Agile Method.  Perhaps my occasional missives
>from what might be a different perspective of consulting, typically
>dealing with a different level of the corporate hierarchy might serve to
>illuminate some aspects of the Agile Evolution in progress.  For example,
>since the first of the year, Iâ?Tve spent time at an office machine
>manufacturer, two large financial organizations in the Fortune 200 and a
>third in the Fortune 500, all in New York City, a consulting firm that
>deals primarily with State government and health care systems, and last
>week at a Federal Government infosec agency Iâ?Tve been dealing with since
>my days running security for Star Wars.  Many of these organizations are
>interested in, or have experimented with, Agility in their systems
>development process with greater or lesser success rate.  A couple of the
>latter Iâ?Tve brought up in the forum for discussion.  As I was about to
>launch another volley of postings describing situations concerning Agility
>from the trenches of the boardroom (if thatâ?Ts not oxymoronix0 it
>occurred to me that such postings may not be of interest to the general
>forum public, whether success or challenge to the cause of
>Agility.  Unfortunately, to have time to post, I donâ?Tt have time to red
>all 669 unread postings awaiting my review currently in my mailbox from
>the past several weeks of infrequent access to the list.   This may mean
>redundant ideas and rehashed subject matter. For this I apologize in
>advance.  Should the views, resistance and/or support of Corporate America
>(sorry, my scheduled April trip to the UK and France for a client has been
>postponed until later in the year, so itâ?Tll ha[AM] Reporting in.ems
>ve to stay focused on Corporate America although several of the companies
>are foreign-owned) not be of interest here, let me know, and Iâ?Tll
>refrain from regaling you with my Encounters with Agility in the Real
>World.  I try to do so with a light touch and questioning spirit emanating
>perhaps from an older and more philosophical approach.  I may also
>represent one of Scottâ?Ts Specializing Generalists (or is it Generalizing
>Specialists?) rather than one of deep expertise in the art of
>agility.  There were other names for such a beast in the old days, right,
>Pete? ­ and not oft
>
>In any case, with your indulgence, Iâ?Td like to close out the discussion
>started at the beginning of the year concerning Dave and the â?ouninformed
>end-user question�.  As you recall from previous episodes, albeit with
>several weeks in between (kind of like watching 24), an Agile Group of
>some sort made changes to a system without informing down line users of
>the changes causing some consternation, especially with Dave who manages
>the quality aspects of the production line.  New error messages appeared
>without explanation and old processes apparently disappeared.  The
>question on the table was whether it is the responsibility of the Agile
>Team as professionals, the Agile Process as a means to a quality end
>product, or the customer employing the Agile Approach to ensure that
>release notes (or similar mechanism of notification) were generated for
>the down line users.  When we left it, Dave was preparing a Business Case
>to get the information he needed to do his job from the Agile Team.
>
>To summarize the responses, which I did pass on to Dave, there were those
>who adamantly proclaimed that should release notes be necessary it is the
>responsibility of the customer to represent the user community fully and
>the customer should create a User Story requesting a release note to which
>the Agile Team would immediately respond despite their antipathy for
>documentation.  Others felt that Release Notes or other notification
>methods were part of their normal Agile Process and felt it did not make
>them less Agile by producing a public record of changes to be made.  While
>some in the community labeled it a process issue, others blamed the
>practitioners who may either not have acted in a professional manner or
>correctly followed the Agile Process.   Of course, we donâ?Tt know the
>reason, and may never get the real story.  As you recall, Dave was at
>least two-levels removed from the actual coding efforts, so, other than
>knowing the team was using an agile approach, and surmising from what
>little evidence we had at hand that it might be XP, we really canâ?Tt
>access the sources to ascertain the specifics.
>The Rest of the Story.   Dave did indeed submit his Business Case, and it
>was accepted and adopted.  The proper documentation describing the changes
>was created in the detail necessary for him to create his fault trees to
>handle the quality production on the line.  Allâ?Ts well for all.  Except
>that as a result of the Business Case submission, new processes were
>imposed on the fledgling Agile Processes being practiced in the
>company.  Dave mentioned that he recognized from many of the comments I
>forwarded to him much of the language and approach that seemed to be going
>on in the IS department of his company, and had a better understanding of
>what they were doing.  The â?ocompanyâ? now requires that all software
>changes emanating from a team such as this episode should hence forth be
>accompanied by sufficient documentation and/or release note notification
>such that all down line personnel who may come in contact with the changed
>software or in any way be affected by said changed software be fully and
>completely apprised of such changes.  I made up the last sentence = it
>doesnâ?Tt come from the company.  The point is that additional work has
>now been imposed on the Agile Teams in the future, whether this additional
>documentation work is appropriate to the XP (or whatever) process or
>not.  This brings up a discussion point of how processes get created in
>the first place and how the best of lean processes get subverted over
>time, but weâ?Tll leave that for another thread.
>My conclusion is that an apparently agile method that apparently was
>successful in this situation has now become less agile by ULM dictate
>because of
>Failure to enact the process correctly in the first place,
>Misapplication of the process tenets,
>Lack of professionalism and discipline among the participants,
>Trying to stretch the Process to fit a circumstance, for which the Process
>was not meant,
>Blind adherence to an Agile Process (much the way the BDUF are accused of
>doing with the Waterfall and other linear processes)
>Or, simply, the process doesnâ?Tt scale.
>The unfortunate aspect for us on the list is that it not only is a set
>back for Agility in the small, but we still donâ?Tt know the root cause so
>we can make adjustments in our own approaches.  Appropriately ULM did not
>attempt to find and fix blame, but simply solve the problem and set policy
>to prevent the situation from happening again.
>In the end , I have to agree with Dave who wondered why it wouldnâ?Tt have
>been simpler for the Team or some member of the Team to talk to him in the
>first place and save all this from happening.   He drew one conclusion
>from the postings that I did try to disabuse him of: the Agile Team
>focuses primarily if not solely inwardly on those directly involved with
>the production of code.  He found this strange.  â?oI donâ?Tt know why it
>still wouldnâ?Tt be agile to talk to us even if we arenâ?Tt directly
>involved with the development. We are affected,� was one of his
statements.
>
>Thanks for the responses to that issue and very specifically to Paul
>Oldfield who forwarded comments from other lists.  Dave did say that he
>found Paulâ?Ts description of agility, which I had paraphrased in one
>summary, to be the most understandable and applicable.  He thought the
>idea of adaptive process, rather than agile process (as he came to
>understand it) to be appropriate in his circumstance,  So perhaps there is
>a small success, even though it is in the area of Quality Assurance rather
>than software development.  A question that challenged an aspect of
>Paulâ?Ts approach did come up later in the month with another company, but
>WTAIL.  (Weâ?Tll talk about it later).
>-=steve
>
>For more information about AM, visit the Agile Modeling Home Page at
>www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------