Discussion:
[AM] Crack customers
(too old to reply)
s***@aol.com
2004-01-07 23:52:14 UTC
Permalink
J. B. Rainsberger said:

I struck it rich. My customer said, on hearing me describe XP/Agile,
"That just sounds like how good software is made." He has been very
supportive, involved and realistic. A gift from the gods, it would seem.
--
OK. I've been waiting a while to ask this question partially because there were other questions I wanted to get answered, and mostly because I couldn't find the posting I wanted to reference. But this is a good place to start.

Paul, a while back you said in a posting that Principle #1 was getting a CRACK customer. You then followed up with the meaning of the acronym CRACK. I couldn't find the posting (I do still have it) to ask in more detail, but in general my question is
What do you do if your customer is not CRACK?

As J.B. says above, this particular good customer was a "gift from the Gods". I've had them all, and am in a postition in life and my career to literally walk away from situations i don't particularly like or circumstances I don't think will be challenging enough or are doomed for failure. Its a nice situation, so I'm not asking for myself. I'm asking for several Deep Carpet (Mahogany Row) types who voiced their objection to Agile not on the basis of the technical side, but because
they were afraid their users would hijack the process to create and better their lives without regard to the overall benefits to the organization, or
they didn't want to lose the productivity of the users that would be required to sit with the developers for long periods of time focusing on developing a new system instead of doing the work they were paid to do (one even factored in this extra cost and said with it any new features would then become too costly), or
they didn't trust their users (my bottom-line analysis from discussions with them), or
they flat out didn't think their users were qualified to describe the mission-critical organization wide projects they had in mind, and they (the ULM) were certainly not going to spend their valuable time trying to talk to propeller-heads. (somehow in that interchange, being a registerd propeller-head -and parrot-head as well - I managed to retain my demeanor).

So, I've actually developed two questions:

1. What do you do when the customer assigned to your Agile Team isn't CRACK? (a condition I found all too often in the past)

2. What words can I say to the ULM who have fears about their own people working on the business end of an Agile Team?

Steve



For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
Paul Oldfield
2004-01-08 10:25:49 UTC
Permalink
(responding to Steve)
Post by s***@aol.com
Paul, a while back you said in a posting that Principle #1
was getting a CRACK customer. You then followed up
with the meaning of the acronym CRACK. I couldn't find
the posting (I do still have it) to ask in more detail, but in
general my question is
What do you do if your customer is not CRACK?
Collaborative, Representative, Authorised, Committed,
Knowledgeable. Sorry, I don't know who deserves credit
for the acronym. I guess each missing quality will have
its own remedy. No doubt these will need to be
tailored to the situation - I'll give some suggestions,
though.

Collaborative - If this person just won't work with you, you
need someone else. No doubt there will be borderline
cases where careful 'politicking' may make the person
more amenable to collaboration.

Representative - if the person does not represent the
views of all users, then you need to get these views by
other means. If you start by JAD sessions, you can get
an idea of what views there are. it may be that you need
to work with different customer representatives at
different times. It may be that 'your' customer just needs
to go back and canvas opinions occasionally, to enable
him to be representative.

Authorised - If your customer cannot make decisions,
either because he is not authorised or does not have the
confidence, then the frequent referring back to other
people who *can* make the decision will slow things down.
If possible, get hold of one of the people who can decide.
otherwise, work round the problem by thinking ahead.
Before now, I've made progress by taking the best guess,
and re-worked where I found the guess was wrong.
Otherwise, do all you can to ensure the communication path
to the person wh can make the decision is as short as
possible, and that providing authorised answers is this
person's top priority.

Committed - the person's work needs to be of a good
standard. If they don't have the commitment to do this,
then you need to find someone that does. You need good
quality requirements. If the quality is okay, but they're
putting this work as a low priority, then you need to find
some way to cope with this. Finding someone more
committed may not be possible; in this case try and up the
priority in this person's mind, and use what time you get
as effectively as possible. Even one hour a week with
the customer is a lot better than none.

Knowledgeable - Sometimes the customer doesn't know
the answer to a question, and will need to ask somebody
that does. I guess we need to live with this, but if it happens
a lot, this will slow things down. In such a case, consider
blagging some time off a domain expert to do some
domain modelling; a better understanding of the domain
will help.
Post by s***@aol.com
they were afraid their users would hijack the process to
create and better their lives without regard to the overall
benefits to the organization, or
That's a reasonable fear, that's why we ask our 'customer'
to be representative - of *all* the stakeholders.
Post by s***@aol.com
they didn't want to lose the productivity of the users that
would be required to sit with the developers for long periods
of time focusing on developing a new system instead of
doing the work they were paid to do (one even factored in
this extra cost and said with it any new features would then
become too costly), or
I believe my suggestion last time this fear arose was to beat
them about the heads with the (tightly rolled) business case.
How much do they want this system? How much time of their
users can they spare? How can we use this time to best effect?
Find a way to work with what you get. If that is just not
sufficient, say so, and ask whether there is a business case for
releasing more of the user's time, because otherwise the system
will cost more to build.
Post by s***@aol.com
they didn't trust their users (my bottom-line analysis from
discussions with them), or
Other than as in your first point? Hmm... Well, I guess you could
offer to let them (i.e. Mahogany Row) sit in... I think this is a
problem they are going to have to live with. Surely the users
are expected to be the ones with expertise in their own jobs.
If not, why not? Offering early delivery of functionality should
help; the suits can then see how the software helps the work.
Post by s***@aol.com
they flat out didn't think their users were qualified to describe
the mission-critical organization wide projects they had in mind,
and they (the ULM) were certainly not going to spend their
valuable time trying to talk to propeller-heads. (somehow in
that interchange, being a registerd propeller-head -and
parrot-head as well - I managed to retain my demeanor).
Again, this is a question of getting representative people.
If it helps, suggest that they write a short Vision statement, to
help keep everybody's eye on the ball.
Post by s***@aol.com
1. What do you do when the customer assigned to your Agile
Team isn't CRACK? (a condition I found all too often in the past)
See above for some pointers.
Post by s***@aol.com
2. What words can I say to the ULM who have fears about their
own people working on the business end of an Agile Team?
You could try asking if they have a better alternative that would
get you the information you need when you need it; make sure
you can explain the difficulties with each alternative they can
come up with. You may find you have to go along with one of
them so be prepared to negotiate for the best available
option. The likelihood is that you will end up with a user not
authorised to make decisions, be prepared; argue for as much
authorisation as possible, and immediate responses where
calls for decisions need to be referred back.

Well, that gives you a flavour of the problems and solutions,
but each situation is different, which is why we need to be
agile.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
s***@aol.com
2004-01-09 05:01:56 UTC
Permalink
In a message dated 1/8/2004 5:25:49 AM Eastern Standard Time, Paul Oldfield <***@compuserve.com> writes:

First of all thanks for the concise and exact definition. I didn't realize fully what some of the words in the acronym meant in this context. I have some individual and detailed concerns below. In general though, it appears that you have control over who gets assigned to your Agile Team from the Business Community (BC). I would guess that if you worked for a company for a while, you would know who in the BC fits the bill and could ask for him/her specifically. What I see, particularly coming from the outside into companies, is that we get what we get despite contracts, agreements, and any and all efforts to elicit the best from the BC, we are at the mercy, whim, disgression of whoever signed the contract. At least from the outside, we have faith that if the guy is going to put up the big bucks to have us solve his problem, he isn't going to give us someone to help who will effectively sabotage the effort. However, working internally is another story as I am seeing coming in from the outside to solve these internal process problems.
Maybe you haven't had the instance, but i've been part of, victem of, and observed (even now) the internal shenanegans of a business with IT as the whipping boy.
At my age and position, I am in the perhaps enviable position of being able to walk away from a contract for as simple a reason as the person assigned to assist the team as the purported CRACK customer is not capable or desirous to fulfill that role. Internal IT staff and others may not have that luxury.
Let me restate the situation of these 'suits'. They are already getting their work done for them as it has been for thirty years. There are some behind schedule projects, and some over budget projects, but then those exist outside the IT world. Perhaps IT has its bigger share, but I'm not totally certain of it, nor do I care. We are suggesting a better way of developing systems, and they are expressing fears. To get them to attempt it, to have faith, to leap into the breech, we need to remove some fears. The fears AFAICT are in the three areas: the quality and commitment of the BC representative; dependence on the individual agilist, or on the agile team or contractor (due to lack of documentation to pass on to a new contractor); and the perceived too-narrow focus of the agile teams (especially XP as demonstrated by the disaster referenced earlier).
We can talk amongst ourselves here on this group, and reassure ourselves that this is the best way, and gripe about how bad waterfall and structured and BDUF is, but it doesn't win us a single new contract, nor get major footholds in the financial business world to allow more agilists to get out there, practice their stuff and spread the Gospel.
I am talking to the suits and CIOs and Training Directors, and mahogany rows and deep carpets and all the rest, and I need ammunition. I read the long and quite good thread on "trust me, I'm agile" from the middle of last year, and agree with the idea that more is needed than to quote Kent and Scott and Jim Highsmith and Ron Jeffries.
The intent of my questions is to gain some good words to allay the fears of these gentlemen (at this time unfortunately for the industry all of these guys are indeed male) so that they will take the flyer and try something that will make their lots in life better. Remember, they are only slightly uncomfortable with their current processes, many have opted for CMM, not necessarily to fix anything in their processes, but because it seems like good insurance to counter the fears of dependence on individuals, incompetent business community personnel and leaving something out during development of a new system or enhancement. These are also people who must deal with auditors, regulators, Sarbanne-Oxley, HIPPA, all of which demand that you prove with documentation that certain things happened a certain way, etc. If they can't do that, they may go lose their mahogany row office, their jobs, or even go to jail.
There is a lot of fear in the corporate stratosphere, regardless of the face they show to the public. They will buy into a new approach, but not on anecdotal evidence. I have convinced smaller organizations to be agile, or more agile, but I've also not encountered these objections. I always knew there was mistrust across the chasm between the Business and IT, but it never occurred to me that the business side would mistrust its own. There may be more to it than that, but my reading and analysis comes to the conclusion that mistrust is at the bottom of all their points.
Post by Paul Oldfield
Collaborative, Representative, Authorised, Committed,
Knowledgeable.  Sorry, I don't know who deserves credit
for the acronym.  I guess each missing quality will have
its own remedy.  No doubt these will need to be
tailored to the situation - I'll give some suggestions,
though.
Collaborative - If this person just won't work with you, you
need someone else.  No doubt there will be borderline
cases where careful 'politicking' may make the person
more amenable to collaboration.
What is the option if the person is assigned to you by the business as the person the business believes is the most knowledgable in this area, but his personality is such that cooperation is a foreign word?
Post by Paul Oldfield
Representative - if the person does not represent the
views of all users, then you need to get these views by
other means.  
How do one know this? That is, how can we as the agile team be sure that the person is truly representative (more below)

If you start by JAD sessions, you can get
Post by Paul Oldfield
an idea of what views there are.  it may be that you need
to work with different customer representatives at
different times.  
Since the purpose of JAD is to create a Design up front, isn't it antithetical to agility based on previous discussions in this forum? I'm referring to the Joint Application Design as espoused originally by IBM, not the Joint Application Development that was spawned elsewhere.

It may be that 'your' customer just needs
Post by Paul Oldfield
to go back and canvas opinions occasionally, to enable
him to be representative.
Problem I've encountered several times: the person assigned assumes she has all the knowledge and fully represents the entire user community and therefore does not need to consult them. We, assuming she had the right answers continued to march. This was a phone company billing system for Canada, adn the Business Analyst was fairly new to the company, but had spent 15 years at AT&T and knew the business. Only thing, she didn't know this company's business and gave us wrong information because she answered questions based on her absolute knowledge and didn't go back and check.
Post by Paul Oldfield
Authorised - If your customer cannot make decisions,
either because he is not authorised or does not have the
confidence, then the frequent referring back to other
people who *can* make the decision will slow things down.
If possible, get hold of one of the people who can decide.
otherwise, work round the problem by thinking ahead.
Before now, I've made progress by taking the best guess,
and re-worked where I found the guess was wrong.
Otherwise, do all you can to ensure the communication path
to the person wh can make the decision is as short as
possible, and that providing authorised answers is this
person's top priority.
The ones who can decide are the ones I talk to nowadays, and they don't have time to deal with the details of the work done by agile teams. They are only interested in results and if the results are wrong someone's head is off. It's not really that bad, but the problem is that many mid-level managers will not take the authority for fear they will make the wrong decision.
Post by Paul Oldfield
Committed - the person's work needs to be of a good
standard.  If they don't have the commitment to do this,
then you need to find someone that does.  You need good
quality requirements.  If the quality is okay, but they're
putting this work as a low priority, then you need to find
some way to cope with this.  Finding someone more
committed may not be possible; in this case try and up the
priority in this person's mind, and use what time you get
as effectively as possible.  Even one hour a week with
the customer is a lot better than none.
The Execs find this a problem, but I don't, and I've got enough ammunition to fight this battle. We use the Champion concept to overcome lack of commitment in the lower ranks, and that works well.
Post by Paul Oldfield
Knowledgeable - Sometimes the customer doesn't know
the answer to a question, and will need to ask somebody
that does.  I guess we need to live with this, but if it happens
a lot, this will slow things down.  In such a case, consider
blagging some time off a domain expert to do some
domain modelling; a better understanding of the domain
will help.
OK. King's English issue. What is "blagging"?
What does one do when the expert is not available? Maybe you get the top people to work with, but even in our most successful endeavors, we had to work with mid-level personnel. We rarely if ever got to talk to the high-producers or top salesmen or most experienced personnel. We had our pick of the guys who were hired last week, and the ones who are retiring next month or the ones who are so unproductive they can be spared from the production line. But we were successful anyway. It actually never occurred to me that our plaint about lack of knowledgeable people would be shared and expressed in the Board Room. because I've always been on the receiving end and worked around it i am at a loss to say to the Execs - O, well, the guys will just make it work. Its true, but not a good sales slogan.
Post by Paul Oldfield
    they were afraid their users would hijack the process to
create and better their lives without regard to the overall
benefits to the organization, or
That's a reasonable fear, that's why we ask our 'customer'
to be representative - of *all* the stakeholders.
    they didn't want to lose the productivity of the users that
would be required to sit with the developers for long periods
of time focusing on developing a new system instead of
doing the work they were paid to do (one even factored in
this extra cost and said with it any new features would then
become too costly), or
I believe my suggestion last time this fear arose was to beat
them about the heads with the (tightly rolled) business case.
How much do they want this system?  How much time of their
users can they spare?  How can we use this time to best effect?
Remember Paul we're working at two different levels (at least). The senior management who wants the project done, and mid-level mgt who really don't care, or who might resist a new project as threatening (as any change) or troublesome, or more work. The people being assigned to work on the teams are being assigned by mid-level mgt. I've suggested to the fellow who raised this objection (in as tactful a way as a recovering nerd can do) that this is his problem to resolve by directing the subordinate managers to appoint the good people. But even as I made my suggestion I realized it was no good: teh senior mgr has no idea who the good people are,and is at the mercy of the mid-mgr in that regard. Again it came down to lack of trust. Unfortunately the fear and lack of trust are not isolated, else i wouldn't bother bringing it up here.
Post by Paul Oldfield
Find a way to work with what you get.  If that is just not
sufficient, say so, and ask whether there is a business case for
releasing more of the user's time,  because otherwise the system
will cost more to build.
In my calculations of cost of building the system the old way versus the new, I never calculated the cost of the business personnel and the loss of their productivity, only the costs to IT. Agility usually came out in front. Looking back, I wonder what the real costs were. If you used a mid-to-senior manager from a mid-sized organization full time for six months you cost the company an extra $200,000 over the cost of the development itself, plus whatever costs were necessary to do her job in her absence, say another $75000. In a given six month effort will the agile approach save more than $275,000 over the same system built using a more traditional approach where that person spends perhaps 20-30 hours over the course of the six month period? I haven't an answer to that point.
Post by Paul Oldfield
    they didn't trust their users (my bottom-line analysis from
discussions with them), or
Other than as in your first point?  Hmm...  Well, I guess you could
offer to let them (i.e. Mahogany Row) sit in...  I think this is a
problem they are going to have to live with.  Surely the users
are expected to be the ones with expertise in their own jobs.
If not, why not?  Offering early delivery of functionality should
help; the suits can then see how the software helps the work.
As I said up topside, they are more than willing to live with things the way they are. They have been listening to us, but we haven't offered answers to their fears. Telling them what they might get that is better than what they have only goes so far if they still have unaddressed fears.
Post by Paul Oldfield
   they flat out didn't think their users were qualified to describe
the mission-critical organization wide projects they had in mind,
and they (the ULM) were certainly not going to spend their
valuable time trying to talk to propeller-heads.  (somehow in
that interchange, being a registerd propeller-head -and
parrot-head as well - I managed to retain my demeanor).  
Again, this is a question of getting representative people.
If it helps, suggest that they write a short Vision statement, to
help keep everybody's eye on the ball.
As mostly always, I agree fully with you (and have throughout this well-thought-out response), and a vision is something I work with always. I think that it might be counterproductive to our cause to suggest that they not only try this new thing, but to help make it work they have to become more involved and put in actual effort (other than on the golf course) when right now they don't have to do anything, and systems still get written and put into operation successfully. We have to face the uphill battle - the financial systems of the world were developed using non-agile methods, before the term was coined, before Kent Beck, Jim Highsmith, Alistair Cockburn and all discovered a new and better way of doing things, and 70-80% of the financial and business systems of the world still operate quite well written in COBOL. Now this is good for people like Pete and I, but not for those who want to spread the word of Agility.
Post by Paul Oldfield
1.  What do you do when the customer assigned to your Agile
Team isn't CRACK? (a condition I found all too often in the past)
See above for some pointers.
2. What words can I say to the ULM who have fears about their
own people working on the business end of an Agile Team?
You could try asking if they have a better alternative that would
get you the information you need when you need it; make sure
you can explain the difficulties with each alternative they can
come up with.  You may find you have to go along with one of
them so be prepared to negotiate for the best available
option.  The likelihood is that you will end up with a user not
authorised to make decisions, be prepared; argue for as much
authorisation as possible, and immediate responses where
calls for decisions need to be referred back.
As I said, my option now if I don't get the best representative on the business side and the project doesn't have a good chance at success is to simply walk away. I've done my years of windmill tilting and white horse charging and while they were great learning experiences and paid the rent at the time, I don't have a lot to show for them but the battle scars and a tougher hide. So I can demand certain things as apparently you can. In the recent past I've had two different VPs on two different projects act as the "customer". Both projects were successful. But then, with direct VP support they probably would have been successful if we hadn't done them agilely.
My concern is for those who can't negotiate those things, who can't walk away if the CRACK customer isn't available, who have to play with the hands they are given, and still do the Agile job. From the perspective of the higher levels, with the fear and distrust, Process makes more sense. In real life Agility makes more sense. The problem is convincing the higher levels, removing their fear, and reinstilling their trust. How do we do that?
-steve
Post by Paul Oldfield
Well, that gives you a flavour of the problems and solutions,
but each situation is different, which is why we need to be
agile.
I truly appreciate the long thoughtful responses. I know its taking a lot of your time. Perhaps the next time I'm in the UK I can treat you to some bangers and ale. :-)
Post by Paul Oldfield
Paul Oldfield
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com
any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
Paul Oldfield
2004-01-09 13:27:59 UTC
Permalink
(responding to Steve)

...snipped to keep the volume down, hope I don't
remove too much context... Warning, it's still a
long reply.
(Steve)
... it appears that you have control over who gets
assigned to your Agile Team from the Business
Community (BC)...
Control? Probably not, but the agile team would have
needs, and should be able to state them clearly and
communicate where these needs aren't being met.
'Influence' would probably be a better word.
...[w.r.t. who we get] we are at the mercy, whim,
disgression of whoever signed the contract...
Having a CRACK person is an ideal. Getting all
this in a single person would be good for the BC
too, because then only 1 person needs to be
assigned to work with the dev team. Often, the
best you can do is work round the problems you have
when who you get doesn't measure up to your needs.
Perhaps the business would accept paying more to fill
your needs where an alternate approach would be
better for the BC.
Maybe you haven't had the instance, but i've been
part of, victem of, and observed (even now) the internal
shenanegans of a business with IT as the whipping boy.
I think anyone who hasn't seen examples of that or
similar, up close, doesn't really understand the business
yet... IMHO, of course ;-) As a person brought in. I can
find myself on the receiving end. I usually don't argue
blame, but point out or work on the solution.
At my age and position, I am in the perhaps enviable
position of being able to walk away from a contract for
as simple a reason as the person assigned to assist the
team as the purported CRACK customer is not capable
or desirous to fulfill that role. Internal IT staff and others
may not have that luxury.
While I *could* walk away, I wouldn't; not for that reason.
Clearly, these people need help, and I can help them.
I'd be up front about telling them what I'd expect to happen,
why, and what might be done to mitigate the risk. (see
later for more on this 'not desirous' angle).
... To get them to attempt it, to have faith, to leap into the
breech, we need to remove some fears. The fears AFAICT
are in the three areas: the quality and commitment of the BC
representative; dependence on the individual agilist, or on
the agile team or contractor (due to lack of documentation
to pass on to a new contractor); and the perceived too-narrow
focus of the agile teams (especially XP as demonstrated
by the disaster referenced earlier).
In that case, your goals should include ways of showing them
that the approach is working, soon and frequently, until their
fears are allayed. Manage their expectations, so that what
happens is what you have told them should happen - both
good and bad. We expect difficulties to occur, but to be
resolved rapidly and flexibly. Let them see it happening.
Or let them see it has happened, if they don't want to watch.
Probably most important - aim for something you are
pretty sure you *can* deliver, before going on to tougher
problems with a 'battle-hardened' team.
The intent of my questions is to gain some good words to
allay the fears of these gentlemen ... so that they will take
the flyer and try something that will make their lots in life
better. Remember, they are only slightly uncomfortable
with their current processes, many have opted for CMM,
not necessarily to fix anything in their processes, but because
it seems like good insurance to counter the fears of
dependence on individuals, incompetent business community
personnel and leaving something out during development
of a new system or enhancement.
I think one of the problems with 'agile' is that it depends so
much on the abilities of the people. No matter what words
you use, it's the team that deliver the results, and it all
comes down to whether or not they can do it. The 'current
processes' you are up against have tried to remove this
dependence on the abilities of the team. If you're going to
be telling the truth, then results speak louder than words.
Yet by all means, tell them about the process, how it works,
what it will do for them, what it needs; answer their questions,
get them to understand what you are doing and why, or
failing that, get them to understand that you understand
what you are doing.
These are also people who must deal with auditors, regulators,
Sarbanne-Oxley, HIPPA, all of which demand that you prove
with documentation that certain things happened a certain
way, etc. If they can't do that, they may go lose their
mahogany row office, their jobs, or even go to jail.
These are constraints on what can be done. People have
managed to get agile processes through CMM audits, but
safety-critical work *will* require added rigour, and this
sort of situation we need to live with. Some of the leading
agilists are pushing the boundaries of what can be done
in these respects; I advise to wait until they have given us
a path to follow. Follow it when you understand what they
did and why it worked.
Post by Paul Oldfield
Collaborative - If this person just won't work with you, you
need someone else.  No doubt there will be borderline
cases where careful 'politicking' may make the person
more amenable to collaboration.
What is the option if the person is assigned to you by the
business as the person the business believes is the most
knowledgable in this area, but his personality is such that
cooperation is a foreign word?
If yu can't work with this person, you can't. Explain the
problem, and see what alternative approaches are available.
One possibility where CRACK people are not available
is to send in a BA to become as close to CRACK as
possible. This would delay the start of the project while
the BA gets enough knowledge to be of use. Similarly,
when dealing with many customers, the 'CRACK customer'
may well be somebody from Marketing.
Post by Paul Oldfield
Representative - if the person does not represent the
views of all users, then you need to get these views by
other means.  
How do one know this? That is, how can we as the agile
team be sure that the person is truly representative (more
below)
Post by Paul Oldfield
If you start by JAD sessions, you can get
an idea of what views there are.  it may be that you need
to work with different customer representatives at
different times.  
Since the purpose of JAD is to create a Design up front,
isn't it antithetical to agility based on previous discussions
in this forum? I'm referring to the Joint Application Design
as espoused originally by IBM, not the Joint Application
Development that was spawned elsewhere.
There are now many forms and varieties of things that go
under the JAD label. The key purpose is to get all
intrerested parties in a room together so that differences
of opinions over needs can be detected and hopefully
resolved. Start with this idea, and tailor it to your purpose.

Who is representative? All stakeholders need to be
represented. A stakeholder is in effect anybody who
could cause the project to fail. I don't think there are any
hard and fast heuristics to make sure you've identified
all stakeholders, but identifying them is the first step to
representing their needs adequately.
Problem I've encountered several times: the person
assigned assumes she has all the knowledge and fully
represents the entire user community and therefore does
not need to consult them. We, assuming she had the
right answers continued to march. This was a phone
company billing system for Canada, adn the Business
Analyst was fairly new to the company, but had spent 15
years at AT&T and knew the business. Only thing, she
didn't know this company's business and gave us wrong
information because she answered questions based on
her absolute knowledge and didn't go back and check.
Ah, that's the distinction between domain knowledge and
business knowledge - the domain knowledge *would*
have been the same. I would hope that a BA would
understand the distinction. Feedback is always advisable.
Let the stakeholders know what sort of decisions are
being made, let them know who is representing their
interests. Once they get confidence in the person who
should be representing their interests, the level of feedback
they want should decrease. Whether this should be
regarded as an IT problem or not is moot - you don't
want the project failing when it could have been saved.
It may be sufficient just to establish with the stakeholder
that this BA is representing his interests, could he ensure
she does it effectively, please.
Post by Paul Oldfield
Authorised - ....
The ones who can decide are the ones I talk to nowadays,
and they don't have time to deal with the details of the work
done by agile teams. They are only interested in results
and if the results are wrong someone's head is off. It's
not really that bad, but the problem is that many mid-level
managers will not take the authority for fear they will make
the wrong decision.
If they want to make the decisions and delegate somebody
to fill in the details, that should work. Okay, details are
low-level decisions, but if they don't want to put in the
effort themselves, they should be able to delegate.
Manage the expectations - working this way may not get
the application exactly as the big decision maker wants,
but any detail changes that need to be made will be
fairly cheap - a necessary side effect of delegating the
decisions then second-guessing them.
Post by Paul Oldfield
Committed - ...
The Execs find this a problem, but I don't, and I've got
enough ammunition to fight this battle. We use the
Champion concept to overcome lack of commitment in
the lower ranks, and that works well.
Good - if you can get hold of one, your project is on a lot
safer ground.
Post by Paul Oldfield
Knowledgeable - ...
... blagging some time off a domain expert ....
OK. King's English issue. What is "blagging"?
Don't know whether I could come up with a precise definition,
but it usually implies persuading somebody by fast talk or
other means to give you something they would be entitled
to refuse.
What does one do when the expert is not available? Maybe
you get the top people to work with, but even in our most
successful endeavors, we had to work with mid-level
personnel. We rarely if ever got to talk to the high-producers
or top salesmen or most experienced personnel. We had
our pick of the guys who were hired last week, and the ones
who are retiring next month or the ones who are so
unproductive they can be spared from the production line.
Apart from the guy who was hired last week, any of these
might do. It just takes more skill and effort to elicit the
information if they haven't spent time trying to organise
and rationalise their knowledge.
... O, well, the guys will just make it work. Its true, but not a
good sales slogan....
No? I'd think that was what the executives would like to
have; "We tell you what we want, you go away and make
it work". Getting them to believe that's what they've got
would be the tricky bit.
Post by Paul Oldfield
I believe my suggestion last time this fear arose was to beat
them about the heads with the (tightly rolled) business case.
How much do they want this system?  How much time of their
users can they spare?  How can we use this time to best effect?
...l we're working at two different levels (at least). The senior
management who wants the project done, and mid-level mg
t who really don't care, or who might resist a new project as
threatening (as any change) or troublesome, or more work.
The people being assigned to work on the teams are being
assigned by mid-level mgt. ... Again it came down to lack of trust.
Unfortunately the fear and lack of trust are not isolated, else i
wouldn't bother bringing it up here.
(I take it this is the 'not desirous' situation from above).
Hmm, it seems like the senior management might be right to
lack trust in their middle management - I don't know whether
we can cure that for them. Yet it impacts the project. The
important thing here is that the middle management is *also*
a stakeholder, they / he can cause the project to fail. If they
have more incentive for the project to fail than to succeed,
we have a problem that needs to be referred back up to senior
management. If they have an incentive for the project to
succeed, then we need to identify *their* needs and see
how the project can help in filling them, within the bounds
of the remit of the project. It would be nice if we didn't have to
do this level of politicking, but it comes along with some jobs.
Post by Paul Oldfield
Find a way to work with what you get.  If that is just not
sufficient, say so, and ask whether there is a business case for
releasing more of the user's time,  because otherwise the system
will cost more to build.
In my calculations of cost of building the system the old way
versus the new, I never calculated the cost of the business
personnel and the loss of their productivity, only the costs
to IT. Agility usually came out in front. Looking back, I
wonder what the real costs were. If you used a mid-to-senior
manager from a mid-sized organization full time for six months
you cost the company an extra $200,000 over the cost of the
development itself, plus whatever costs were necessary to
do her job in her absence, say another $75000. In a given
six month effort will the agile approach save more than $275,000
over the same system built using a more traditional approach
where that person spends perhaps 20-30 hours over the
course of the six month period? I haven't an answer to that point.
Yet the traditional approach needs the same information.
Would that cost more or less to produce? My guess is it
would take considerably more effort, but with lower ranking
people.
As I said up topside, they are more than willing to live with
things the way they are. They have been listening to us,
but we haven't offered answers to their fears. Telling them
what they might get that is better than what they have only
goes so far if they still have unaddressed fears.
What's more worrying is that their fears may be justified,
and I don't think it's a situation IT could address. I would
be inclined to suggest they considered adopting 'Lean'
practices on the business side, but that's really going
outside my area of expertise. How can the senior management
get their staff to *want* to be trustworthy?
Post by Paul Oldfield
Again, this is a question of getting representative people.
If it helps, suggest that they write a short Vision statement, to
help keep everybody's eye on the ball.
.... I think that it might be counterproductive
to our cause to suggest that ... to help make it work they
have to become more involved and put in actual effort (other
than on the golf course)...
Point the staff in the right direction and trust them to get on
with it; be prepared to handle any problems that are referred
back up. Keep an occasional eye on the situation to see it
isn't falling apart. That's more or less how it should go at
that level. There's this question of 'trust' though.
...My concern is for those who can't negotiate those things,
who can't walk away if the CRACK customer isn't available,
who have to play with the hands they are given, and still do
the Agile job. From the perspective of the higher levels, with
the fear and distrust, Process makes more sense. In real
life Agility makes more sense. The problem is convincing
the higher levels, removing their fear, and reinstilling their
trust. How do we do that?
Trust flows both ways, or not, as the case may be. Once
you build up a lack of trust, it's a big job to rebuild trust.
I always act like I assume everyone is trustworthy, though
not necessarily infallible. I find that it makes people
*want* to be trustworthy - even the die-hard self-seekers
seem to respond better. Yet some management hierarchies
seem to reward untrustworthy behaviour. Until I understand
that, I don't feel qualified to comment.

One other comment on the topic, though. For a good
many years, the IT market has been growing so fast
that one needed to staff projects with a high proportion
of juniors, and experienced people tended to get
pulled out into management. Defined process makes
more sense in these sort of conditions. If and when
the market slows down, there will be more people
available with more experience. Under these
conditions, a more agile process makes sense.
So, tongue-in-cheek, you can say they weren't wrong
not to be agile, but maybe it's time to change?
I truly appreciate the long thoughtful responses. I know its
taking a lot of your time. Perhaps the next time I'm in the
UK I can treat you to some bangers and ale. :-)
Sounds good. These days I spend about half the year
in Scotland, but with the upturn in the market, I might be
down South a lot more.


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
s***@aol.com
2004-01-10 22:36:03 UTC
Permalink
In a message dated 1/9/2004 8:39:52 AM Eastern Standard Time,
***@compuserve.com writes:

More discussion and questions (its a heavy issue):
(responding to Steve)

...snipped to keep the volume down, hope I don't
remove too much context... Warning, it's still a
long reply.
(Steve)
... it appears that you have control over who gets
assigned to your Agile Team from the Business
Community (BC)...
Control? Probably not, but the agile team would have
needs, and should be able to state them clearly and
communicate where these needs aren't being met.
'Influence' would probably be a better word.

Yes, I can buy that provided the Team does have influence, or at least knows
how to exert influence properly. I’ve found that the mere fact that we are
building a product that will ensure the company’s future, or save it’s behind
does not necessarily grant the team or its members any special influence in the
organization we’re saving. We’re still nerds in their eyes.
...[w.r.t. who we get] we are at the mercy, whim,
disgression of whoever signed the contract...
Having a CRACK person is an ideal. Getting all
this in a single person would be good for the BC
too, because then only 1 person needs to be
assigned to work with the dev team. Often, the
best you can do is work round the problems you have
when who you get doesn't measure up to your needs.
Perhaps the business would accept paying more to fill
your needs where an alternate approach would be
better for the BC.

Understood.
Maybe you haven't had the instance, but i've been
part of, victem of, and observed (even now) the internal
shenanegans of a business with IT as the whipping boy.
I think anyone who hasn't seen examples of that or
similar, up close, doesn't really understand the business
yet... IMHO, of course ;-) As a person brought in. I can
find myself on the receiving end. I usually don't argue
blame, but point out or work on the solution.

Exactly
At my age and position, I am in the perhaps enviable
position of being able to walk away from a contract for
as simple a reason as the person assigned to assist the
team as the purported CRACK customer is not capable
or desirous to fulfill that role. Internal IT staff and others
may not have that luxury.
While I *could* walk away, I wouldn't; not for that reason.
Clearly, these people need help, and I can help them.
I'd be up front about telling them what I'd expect to happen,
why, and what might be done to mitigate the risk. (see
later for more on this 'not desirous' angle).
... To get them to attempt it, to have faith, to leap into the
breech, we need to remove some fears. The fears AFAICT
are in the three areas: the quality and commitment of the BC
representative; dependence on the individual agilist, or on
the agile team or contractor (due to lack of documentation
to pass on to a new contractor); and the perceived too-narrow
focus of the agile teams (especially XP as demonstrated
by the disaster referenced earlier).
In that case, your goals should include ways of showing them
that the approach is working, soon and frequently, until their
fears are allayed. Manage their expectations, so that what
happens is what you have told them should happen - both
good and bad. We expect difficulties to occur, but to be
resolved rapidly and flexibly. Let them see it happening.
Or let them see it has happened, if they don't want to watch.
Probably most important - aim for something you are
pretty sure you *can* deliver, before going on to tougher
problems with a 'battle-hardened' team.

Good words all. It’s the getting to the point of showing them it will work
that is the difficult part right now. Granted, at this point I just happen to
be dealing with the most conservative of industries, a factor which, of course,
bleeds into the IS arena of these companies, so the situation may be more
unique than I think.
The intent of my questions is to gain some good words to
allay the fears of these gentlemen ... so that they will take
the flyer and try something that will make their lots in life
better. Remember, they are only slightly uncomfortable
with their current processes, many have opted for CMM,
not necessarily to fix anything in their processes, but because
it seems like good insurance to counter the fears of
dependence on individuals, incompetent business community
personnel and leaving something out during development
of a new system or enhancement.
I think one of the problems with 'agile' is that it depends so
much on the abilities of the people. No matter what words
you use, it's the team that deliver the results, and it all
comes down to whether or not they can do it. The 'current
processes' you are up against have tried to remove this
dependence on the abilities of the team. If you're going to
be telling the truth, then results speak louder than words.
Yet by all means, tell them about the process, how it works,
what it will do for them, what it needs; answer their questions,
get them to understand what you are doing and why, or
failing that, get them to understand that you understand
what you are doing.

Magic words: “tell them about the process”. Maybe you can explain why the
Agilists have created a different language and a manifesto and all. The only
explanation I can give (with tongue planted firmly in cheek) is that it is the
only way they can sell new books. I quickly add that I say that with envy
since I can’t think of new words and acronyms enough to fill a book of my own. J
Perhaps part of the fear is enhanced by the newness of the language which,
to those of us with ancient ears sounds like old hat with new bandana on it.
These are also people who must deal with auditors, regulators,
Sarbanne-Oxley, HIPPA, all of which demand that you prove
with documentation that certain things happened a certain
way, etc. If they can't do that, they may go lose their
mahogany row office, their jobs, or even go to jail.
These are constraints on what can be done. People have
managed to get agile processes through CMM audits, but
safety-critical work *will* require added rigour, and this
sort of situation we need to live with. Some of the leading
agilists are pushing the boundaries of what can be done
in these respects; I advise to wait until they have given us
a path to follow. Follow it when you understand what they
did and why it worked.

Do I understand you to be suggesting that Agile isn’t quite there yet? This
is a serious question not challenging the credibility or effectiveness of the
approach. IOW, perhaps I am ahead of the game? I wouldn’t be surprised.
Like Pete I’ve also been doing stuff that was “invented” years afterwards. I
did the Y2K crisis in 1992. J
Post by Paul Oldfield
Collaborative - If this person just won't work with you, you
need someone else. No doubt there will be borderline
cases where careful 'politicking' may make the person
more amenable to collaboration.
What is the option if the person is assigned to you by the
business as the person the business believes is the most
knowledgable in this area, but his personality is such that
cooperation is a foreign word?
If yu can't work with this person, you can't. Explain the
problem, and see what alternative approaches are available.
One possibility where CRACK people are not available
is to send in a BA to become as close to CRACK as
possible. This would delay the start of the project while
the BA gets enough knowledge to be of use. Similarly,
when dealing with many customers, the 'CRACK customer'
may well be somebody from Marketing.

Good words. Realistic and pragmatic.
Post by Paul Oldfield
Representative - if the person does not represent the
views of all users, then you need to get these views by
other means.
How do one know this? That is, how can we as the agile
team be sure that the person is truly representative (more
below)
Post by Paul Oldfield
If you start by JAD sessions, you can get
an idea of what views there are. it may be that you need
to work with different customer representatives at
different times.
Since the purpose of JAD is to create a Design up front,
isn't it antithetical to agility based on previous discussions
in this forum? I'm referring to the Joint Application Design
as espoused originally by IBM, not the Joint Application
Development that was spawned elsewhere.
There are now many forms and varieties of things that go
under the JAD label. The key purpose is to get all
intrerested parties in a room together so that differences
of opinions over needs can be detected and hopefully
resolved. Start with this idea, and tailor it to your purpose.

Who is representative? All stakeholders need to be
represented. A stakeholder is in effect anybody who
could cause the project to fail. I don't think there are any
hard and fast heuristics to make sure you've identified
all stakeholders, but identifying them is the first step to
representing their needs adequately.

Good definition of Stakeholder – a kind of defensive driving viewpoint –
mind if I use it? I’ve always fallen back on the “one who touches or is touched
by the problem or solution” chestnut. This is all upfront work, maybe with a
little business modeling to gain perspective to ensure we have the proper
picture of the problem domain so we can tell who is inhabiting it? Might
consider some design artifacts to get familiar with the business environment? All,
of course, if one does not work directly in that environment with those people.
Problem I've encountered several times: the person
assigned assumes she has all the knowledge and fully
represents the entire user community and therefore does
not need to consult them. We, assuming she had the
right answers continued to march. This was a phone
company billing system for Canada, adn the Business
Analyst was fairly new to the company, but had spent 15
years at AT&T and knew the business. Only thing, she
didn't know this company's business and gave us wrong
information because she answered questions based on
her absolute knowledge and didn't go back and check.
Ah, that's the distinction between domain knowledge and
business knowledge - the domain knowledge *would*
have been the same. I would hope that a BA would
understand the distinction. Feedback is always advisable.
Let the stakeholders know what sort of decisions are
being made, let them know who is representing their
interests. Once they get confidence in the person who
should be representing their interests, the level of feedback
they want should decrease. Whether this should be
regarded as an IT problem or not is moot - you don't
want the project failing when it could have been saved.
It may be sufficient just to establish with the stakeholder
that this BA is representing his interests, could he ensure
she does it effectively, please.

OK. Let me make sure I understand your differentiation between domain
knowledge and business knowledge. Domain encompasses that which is done by all
businesses who do this thing, e.g. in this case LATAs, RATAs, Port City
assignments, Area Codes, etc. Business is that Domain information that applies to this
specific business, such as Friend & Lovers Calling Circle special discounts,
etc. Or do I have it backwards or totally incorrect? Unfortunately, I didn’t
get to the posts you guys did earlier on the subject in time and my ISP
deleted them ingloriously.

There is a generic issue here, but let me stay with the example a few more
sentences. This person had the title BA and represented the entire UC – all
stakeholders. This particular company, like many nowadays, and the number is
growing, inhibit interaction between the users and developers except through the
BA. Since the BA was designated by Management, we, the developers, have to
assume that s/he is capable, knowledgeable (and the knowledge is accurate and
correct), has full faith and confidence of the stakeholders, will do due
diligence in the pursuit of answers to questions, has appropriate influence, is
committed to the project and product, etc. etc. Any other belief will stop
progress. We can’t (particularly being contractors, and more particularly being
nerds) challenge the appointment and ask for our own interview process before
accepting this person as our Stakeholder intermediary. Basically, for all the
good and bad reasons and results, we’re stuck with what management gives us.
The irony of this is that over 50% of my current contracts and 40% of my
revenue is being derived from working directly with BAs in newly formed BA groups
in these old organizations. J
Post by Paul Oldfield
Authorised - ....
The ones who can decide are the ones I talk to nowadays,
and they don't have time to deal with the details of the work
done by agile teams. They are only interested in results
and if the results are wrong someone's head is off. It's
not really that bad, but the problem is that many mid-level
managers will not take the authority for fear they will make
the wrong decision.
If they want to make the decisions and delegate somebody
to fill in the details, that should work. Okay, details are
low-level decisions, but if they don't want to put in the
effort themselves, they should be able to delegate.
Manage the expectations - working this way may not get
the application exactly as the big decision maker wants,
but any detail changes that need to be made will be
fairly cheap - a necessary side effect of delegating the
decisions then second-guessing them.

Absolutely agree. But the BIG HUMP is in convincing them that the changes
will be cheaper. The reaction almost immediately is “why can’t you get it
right the first time?” Of course they react that way because we in IS (formerly
MIS) have taught them that we get it right the first time, and that change will
cost a fortune. Over here in the Washington DC area the order of the day
among the Beltway Bandits is to do the initial job cheap and then make a fortune
in the change orders. With that mentality among the contractors and general
IS community, is it any wonder management reacts as it does? Anyway, if
management considers that we have failed if we have to change what we did because we
didn’t do it right (not because They had changes to make), how do we get over
that HUMP?
Post by Paul Oldfield
Committed - ...
The Execs find this a problem, but I don't, and I've got
enough ammunition to fight this battle. We use the
Champion concept to overcome lack of commitment in
the lower ranks, and that works well.
Good - if you can get hold of one, your project is on a lot
safer ground.
Post by Paul Oldfield
Knowledgeable - ...
... blagging some time off a domain expert ....
OK. King's English issue. What is "blagging"?
Don't know whether I could come up with a precise definition,
but it usually implies persuading somebody by fast talk or
other means to give you something they would be entitled
to refuse.

Ah. I like it provided I understand it. Is this Sammy Glicking or
manipulating or both?
What does one do when the expert is not available? Maybe
you get the top people to work with, but even in our most
successful endeavors, we had to work with mid-level
personnel. We rarely if ever got to talk to the high-producers
or top salesmen or most experienced personnel. We had
our pick of the guys who were hired last week, and the ones
who are retiring next month or the ones who are so
unproductive they can be spared from the production line.
Apart from the guy who was hired last week, any of these
might do. It just takes more skill and effort to elicit the
information if they haven't spent time trying to organise
and rationalise their knowledge.
... O, well, the guys will just make it work. Its true, but not a
good sales slogan....
No? I'd think that was what the executives would like to
have; "We tell you what we want, you go away and make
it work". Getting them to believe that's what they've got
would be the tricky bit.

I’m an ardent believer in “tell me what you want and then leave me alone to
make it for you.” It’s the song of the registered nerd. And it would work
fine with management, except that with agile you need all this extra stuff from
them: quality people on the teams, a special work area with special
arrangement of furniture, a business expert on hand full time, an environment that can
withstand perturbation. The old ways don’t need all that stuff because they
already have what they need which they’ve acquired over the years (individual
cubicles, email access to business expertise, a couple of Terabyte’s worth of
CASE and modeling software and collaboration devices, printing white boards and
the rest), so the structured IS dept can take the Business Case, go away, and
come back with it done, for better or worse. They are also skillful at
producing the appropriately business-termed rationales for why it needs another
release to be ready, or an extra couple of months, or a few thousand more to
finish. IOW, the structured, entrenched methods are better equipped in Upper
Level Management’s eyes to deliver without disruption than the agilists are. This
is the wall I’m up against almost daily over the past year or so.
Post by Paul Oldfield
I believe my suggestion last time this fear arose was to beat
them about the heads with the (tightly rolled) business case.
How much do they want this system? How much time of their
users can they spare? How can we use this time to best effect?
...l we're working at two different levels (at least). The senior
management who wants the project done, and mid-level mg
t who really don't care, or who might resist a new project as
threatening (as any change) or troublesome, or more work.
The people being assigned to work on the teams are being
assigned by mid-level mgt. ... Again it came down to lack of trust.
Unfortunately the fear and lack of trust are not isolated, else i
wouldn't bother bringing it up here.
(I take it this is the 'not desirous' situation from above).
Hmm, it seems like the senior management might be right to
lack trust in their middle management - I don't know whether
we can cure that for them. Yet it impacts the project. The
important thing here is that the middle management is *also*
a stakeholder, they / he can cause the project to fail. If they
have more incentive for the project to fail than to succeed,
we have a problem that needs to be referred back up to senior
management. If they have an incentive for the project to
succeed, then we need to identify *their* needs and see
how the project can help in filling them, within the bounds
of the remit of the project. It would be nice if we didn't have to
do this level of politicking, but it comes along with some jobs.

My sentiments exactly. But in the reread of this I am seeing a pattern of “if
” statements and such that indicate a model might be in order. Recognizing
that this would be a model without resulting code, it still could be an Agile
Model, no? Is it possible to model the upfront considerations necessary for
successful implementation of agile development methods in an organization?
Post by Paul Oldfield
Find a way to work with what you get. If that is just not
sufficient, say so, and ask whether there is a business case for
releasing more of the user's time, because otherwise the system
will cost more to build.
In my calculations of cost of building the system the old way
versus the new, I never calculated the cost of the business
personnel and the loss of their productivity, only the costs
to IT. Agility usually came out in front. Looking back, I
wonder what the real costs were. If you used a mid-to-senior
manager from a mid-sized organization full time for six months
you cost the company an extra $200,000 over the cost of the
development itself, plus whatever costs were necessary to
do her job in her absence, say another $75000. In a given
six month effort will the agile approach save more than $275,000
over the same system built using a more traditional approach
where that person spends perhaps 20-30 hours over the
course of the six month period? I haven't an answer to that point.
Yet the traditional approach needs the same information.
Would that cost more or less to produce? My guess is it
would take considerably more effort, but with lower ranking
people.

Point of clarification. Our prototyping method (which is agile in
development, but uses upfront design) depends on the User in the room with the
developers, and the User is defined as one who is a dedicated user of the system we are
replacing and/or creating. The stakeholders I have been referring to are
these Users who are typically at the lowest level of the corporate food chain
because it is the lowest level who are doing the actual work. We, in fact, won’t
let managers or supervisors be in the prototyping sessions unless they are
the ones who have fingers on the keyboards all day. Even when we have worked
with the BAs and such, they are only upfront defining and providing Domain or
Business information. When the coding is done we only deal with those people
who will be using the results of our code day-in-day-out. Now, your last
sentence leads me to believe that your vision of Stakeholder, the one who will be in
the room, as a higher paid, higher level in the organization. If so, some of
what we’ve been discussing may hinge on that misunderstanding of who is in
the room with the coders.

Second point of clarification. The reason I point out the cost is that in
traditional methods, the users only devote a part of their time providing
information, and the loss of productivity is spread over a large number of users and
stakeholders (typically) so that the costs are negligible in terms of loss of
productivity – about equal in management’s eyes to an extra couple of coffee
breaks or a longer lunch hour one day. I’ve actually observed that the time
the users have spent with us comes out of their time since they are still
expected to finish their daily quota, so they may work late or through lunch to
make up for the time spent with us, and mid-management is well aware of this.
Cost – negligible. But my understanding of what you and others are saying is
that in agile you have at least one full-time devoted representative from the
business community – stakeholder – in the room with the team. That is a
tangible, measurable cost. Is my take on this wrong?
As I said up topside, they are more than willing to live with
things the way they are. They have been listening to us,
but we haven't offered answers to their fears. Telling them
what they might get that is better than what they have only
goes so far if they still have unaddressed fears.
What's more worrying is that their fears may be justified,
and I don't think it's a situation IT could address. I would
be inclined to suggest they considered adopting 'Lean'
practices on the business side, but that's really going
outside my area of expertise. How can the senior management
get their staff to *want* to be trustworthy?

Now we get back to something I brought up before: Agile Modeling without
code. IT can certainly use its expertise in problem solving to move business to
leaner practices. We are doing just that at GM. The efforts are being led by
IT, in terms of BPR and other IT practices all emanating out of IS&S (The name
of their MIS department). So can we talk about Agile Modeling as it applies
to solving business problems that may not include code, or is AM wrapped
inextricably around the code? Wasn’t Mary Poppendieck the one pushing Lean
manufacturing? Isn’t she the same one that writes about Agile Methods and sits on
the XP 2004 committee or something like that? I have to believe there is a tie
in with Agility and solving business problems in general. If we can get to
that, there will be no problem getting Agile Development into the Corporate
Board Room. We simply use Agile Modeling methods to solve their business problems
and let them suggest we do the same thing with software development. We will
then tell them it’s a wonderful idea they had, and we understand fully how
they got to be a CxO.
Post by Paul Oldfield
Again, this is a question of getting representative people.
If it helps, suggest that they write a short Vision statement, to
help keep everybody's eye on the ball.
.... I think that it might be counterproductive
to our cause to suggest that ... to help make it work they
have to become more involved and put in actual effort (other
than on the golf course)...
Point the staff in the right direction and trust them to get on
with it; be prepared to handle any problems that are referred
back up. Keep an occasional eye on the situation to see it
isn't falling apart. That's more or less how it should go at
that level. There's this question of 'trust' though.

Yes.
...My concern is for those who can't negotiate those things,
who can't walk away if the CRACK customer isn't available,
who have to play with the hands they are given, and still do
the Agile job. From the perspective of the higher levels, with
the fear and distrust, Process makes more sense. In real
life Agility makes more sense. The problem is convincing
the higher levels, removing their fear, and reinstilling their
trust. How do we do that?
Trust flows both ways, or not, as the case may be. Once
you build up a lack of trust, it's a big job to rebuild trust.
I always act like I assume everyone is trustworthy, though
not necessarily infallible. I find that it makes people
*want* to be trustworthy - even the die-hard self-seekers
seem to respond better. Yet some management hierarchies
seem to reward untrustworthy behaviour. Until I understand
that, I don't feel qualified to comment.

We have a bit more of that than you apparently do over there. In addition to
Enron and MCI and Tyson and the others we have an Attorney General who is
making a career out of busting businesses in New York City. I’m in the Big Apple
for this month and from talking to a couple of mid-level friends, the fear I
talk about appears to be coming from the outside. Penthouse Suites are
suddenly in jeopardy. But, the distrust is palpable, even more so that my previous
engagements here, and it seems to be growing. But as you said, its hard to
deal with it if you don’t understand it. I always like to have a paranoid
associate with me to make sure I lock my car door and watch my credit card and
remind me to speak real softly in restaurants and give me a good reading on the
Upper Level Management we talk to. Like you, I trust everyone until they have
proved to be untrustworthy at least twice.

One other comment on the topic, though. For a good
many years, the IT market has been growing so fast
that one needed to staff projects with a high proportion
of juniors, and experienced people tended to get
pulled out into management. Defined process makes
more sense in these sort of conditions. If and when
the market slows down, there will be more people
available with more experience. Under these
conditions, a more agile process makes sense.
So, tongue-in-cheek, you can say they weren't wrong
not to be agile, but maybe it's time to change?

Excellent point! Natural progression of things. I always like that – it’s
no one’s fault, it just gravitated there over time. That’s not sarcastic. I
truly believe most of where we are we got to without anyone steering the
vehicle, it just followed natural turns in the road. Brook’s ‘one day at a time”
axiom.
I truly appreciate the long thoughtful responses. I know its
taking a lot of your time. Perhaps the next time I'm in the
UK I can treat you to some bangers and ale. :-)
Sounds good. These days I spend about half the year
in Scotland, but with the upturn in the market, I might be
down South a lot more.
Never been up there. My lineage is Scottish, though. Several clans, but the
only one I remember is Kirk. My mother tells me we are descendents of
Scottish Kings. I was boasting about it one time in a bar, and a Scotsman told me
that everyone of Scottish descent has a Scottish King in their ancestry. Never
mentioned it since til now.

Paul Oldfield

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
Paul Oldfield
2004-01-11 18:35:58 UTC
Permalink
(responding to Steve)
(Paul)
Control? Probably not, but ... 'Influence' would
probably be a better word.
(Steve)
Yes, I can buy that provided the Team does have
influence, or at least knows how to exert influence
properly....
Knowing what you need, being able to say why you need
it, and what it would cost if you don't get it, all help - if
addressed at the right people (assuming there *are* any).
I think one of the problems with 'agile' is that it depends so
much on the abilities of the people. No matter what words
you use, it's the team that deliver the results...
Yet by all means, tell them about the process, how it works,
what it will do for them, what it needs; answer their questions,
get them to understand what you are doing and why, or
failing that, get them to understand that you understand
what you are doing.
Magic words: "tell them about the process". Maybe you
can explain why the Agilists have created a different
language and a manifesto and all. The only explanation I
can give (with tongue planted firmly in cheek) is that it is the
only way they can sell new books.
How should I put this? In some ways process is *more*
important in an agile world, because everyone needs
to make decisions about process. They make them 'just in
time', just before enacting the process they've decided
upon. An agile methodology will start with a few rules, a few
points of stability, but the people decide the rest as they go.
This means the people are important, what they decide to
do is important, the *pre-defined* process is less important.
It needs to be carefully chosen so it doesn't prevent the
people from doing the right thing.

As to writing books, people will do that anyway, because
other people want to learn about these ideas. Certainly the
idea that pre-defined process is causing problems is an
idea that needs a new way of thinking to be installed, and
there is a language growing out of that new way of thinking
(that might be an old idea re-visited). Anyway, if we don't
invent a new language, how are we to recognise the 'true
believers'? ;-)
These are constraints on what can be done. People have
managed to get agile processes through CMM audits, but
safety-critical work *will* require added rigour, and this
sort of situation we need to live with. Some of the leading
agilists are pushing the boundaries of what can be done
in these respects; I advise to wait until they have given us
a path to follow. Follow it when you understand what they
did and why it worked.
Do I understand you to be suggesting that Agile isn't quite
there yet? This is a serious question not challenging the
credibility or effectiveness of the approach. IOW, perhaps
I am ahead of the game? I wouldn't be surprised. Like Pete
I've also been doing stuff that was 'invented' years afterwards
I did the Y2K crisis in 1992. J
DSDM, Appropriate Process, Crystal, and Boehm and Turner
all have variants on a theme, ways of measuring how suitable
a project would be for an Agile approach. Where all
relevant criteria map near the agile end of the scale, any
competent agile team should manage well. Where there are
more criteria toward the middle of the scale, experienced
teams may find themselves in difficulties. Toward the
more rigorous end of the scale, the top experts are pushing
the limits, one criterion at a time.
Who is representative? All stakeholders need to be
represented. A stakeholder is in effect anybody who
could cause the project to fail. I don't think there are any
hard and fast heuristics to make sure you've identified
all stakeholders, but identifying them is the first step to
representing their needs adequately.
Good definition of Stakeholder; a kind of defensive driving
viewpoint; mind if I use it?
It's not mine originally; it came from the RUP domain I think.
Either from the RUP documentation itself or somebody
writing on RUP Forum. I've made free with it, the idea's
now in the public domain. It might even have been Scott
Ambler's originally? I don't know.
.... This is all upfront work, maybe with a little business
modeling to gain perspective to ensure we have the proper
picture of the problem domain so we can tell who is
inhabiting it? Might consider some design artifacts to
get familiar with the business environment? All, of course,
if one does not work directly in that environment with those
people.
I think the key issue here is that *somebody* needs to have
the relevant understanding of the business, and feed this
information to the team. That implies *somebody* needs
to know what information would be relevant. I think at least
this last point should be covered by the dev team.
... assumes she has all the knowledge and fully
represents the entire user community and therefore does
not need to consult them...
Ah, that's the distinction between domain knowledge and
business knowledge - the domain knowledge *would*
have been the same. I would hope that a BA would
understand the distinction....
OK. Let me make sure I understand your differentiation
between domain knowledge and business knowledge.
Domain encompasses that which is done by all
businesses who do this thing, e.g. in this case LATAs
RATAs, Port City assignments, Area Codes, etc.
That's probably the domain with an American flavour;
there are probably universal aspects lying underneath
these. I only suggest this 'cos I don't recognise *any* of
the terms or acronyms. In this case, the distinction is moot,
but at other times, I might debate the finer points... :-)
Business is that Domain information that applies to this
specific business, such as Friend & Lovers Calling Circle
special discounts, etc. Or do I have it backwards or totally
incorrect?
If the business can choose to do whatever it is differently,
then the decision to do it *this* way must be business-
specific, not domain specific. Anyone who has spent time with
several businesses in a domain will get to know what changes
and what doesn't. Without this change in context, they may
assume all businesses do things the way they are familiar
with.
Unfortunately, I didn't get to the posts you guys did earlier
on the subject in time and my ISP deleted them ingloriously.
Luckily, they're all available online at Topica, when you have
a few free months... ;-)
This person had the title BA and represented the entire UC;
all stakeholders. This particular company... inhibit interaction
between the users and developers except through the BA.
Since the BA was designated by Management, we, the
developers, have to assume that s/he is capable,
knowledgeable (and the knowledge is accurate and correct),
has full faith and confidence of the stakeholders...
Agreed, it's a problem. Yet even if you got the info direct
from the 'real' people, some will be wrong... What you
lose on the swings you gain on the roundabouts. You
have a coherent picture, at the risk of being less correct.

To deal with this, deliver early and get feedback. Do
this regularly, though not to the point of boredom or the
quality of feedback will suffer.
If they want to make the decisions and delegate
somebody to fill in the details, that should work...
Absolutely agree. But the BIG HUMP is in convincing
them that the changes will be cheaper. The reaction
almost immediately is "why can't you get it right the first
time?"
One of the criteria I mentioned earlier w.r.t. suitability for
an agile approach is 'rate of change of requirements'.
Where this is sufficiently low, there is a hypothetical
possibility of "getting it right first time". Even so, the degree
of rigour needed to achieve this is not justified outside of
safety-critical projects. If we look at the costs of the
alternative approaches, there will be a 'sweet spot'
of minimum cost where if we spent any less on getting
it right first time, it would cost us more in correcting the
things we got wrong, but if we spent any *more* on
getting it right first time, it would be more than we'd save
by reducing the things that we got wrong.

The real question should be "Why don't you want to
get it right first time?" and the answer is, of course we *do*,
but at some point we have to stop spending money doing
that, because it isn't saving us as much money as we're
spending.
... Anyway, if management considers that we have failed
if we have to change what we did because we didn't do
it right (not because They had changes to make), how do
we get over that HUMP?
Consider telling them you'll be producing functional
prototypes every few weeks to get feedback on your
understanding of their needs?
Ah. I like it provided I understand it. Is this Sammy
Glicking or manipulating or both?
Err, what's that in King's English? ;-) ... probably.
Whatever works.
I'm an ardent believer in "tell me what you want and
then leave me alone to make it for you." .... IOW, the
structured, entrenched methods are better equipped
in Upper Level Management's eyes to deliver without
disruption than the agilists are. This is the wall I'm up
against almost daily over the past year or so.
Well, what problems *do* they perceive with the old
guard? Is it too long before delivery? Do changes cost
too much? Are there things they couldn't do because
they are too complex? Some places will not change
until the alternative is unacceptable. Change involves risk.
In such places, you may need to start small, going with
the argument that the capacity to change would be
useful, in case it's ever needed.
... But in the reread of this I am seeing a pattern of "if"
statements and such that indicate a model might be in
order. Recognizing that this would be a model without
resulting code, it still could be an Agile Model, no? Is
it possible to model the upfront considerations necessary
for successful implementation of agile development
methods in an organization?
Hmm... that would be a pretty complex model. It would
be a lot simpler for any particular organisation. Yet a
truly agile person would do just enough modelling up
front...
Yet the traditional approach needs the same information.
Would that cost more or less to produce? My guess is it
would take considerably more effort, but with lower
ranking people.
Point of clarification. Our prototyping method (which is
agile in development, but uses upfront design) depends on
the User in the room with the developers, and the User is
defined as one who is a dedicated user of the system we
are replacing and/or creating. The stakeholders I have
been referring to are these Users who are typically at the
lowest level of the corporate food chain because it is the
lowest level who are doing the actual work. We, in fact, won't
let managers or supervisors be in the prototyping sessions
unless they are the ones who have fingers on the keyboards
all day. Even when we have worked with the BAs and such,
they are only upfront defining and providing Domain or
Business information. When the coding is done we only
deal with those people who will be using the results of our
code day-in-day-out. Now, your last sentence leads me to
believe that your vision of Stakeholder, the one who will be in
the room, as a higher paid, higher level in the organization.
If so, some of what we've been discussing may hinge on
that misunderstanding of who is in the room with the coders.
Possibly. You need requirements from all classes of people
that have a stake in the system. The users are going to be
pretty central to this. However, if you don't include the
maintainers and operators, you get problems like the ones
we discussed earlier. I would assume that if you get a
representative who is Representative (of all stakeholders),
Authorised (to make decisions that will cost money, will
save money, possibly thousands of dollars per minute...)
and Knowledgeable (about the whole business context)
then this person would probably be pretty valuable to the
business. Yet you don't need all of these qualities all of the
time, as long as the sum of what you get adds up to what you
need. However, if you don't have such a person available
all the time, you may make decisions based on less than
ideal information, leaving more problems to be caught
as teh system is released to gather feedback. Would the
savings in re-work cover the expense? Received wisdom
is that they probably would. Remind me, who was expecting
you to "get it right first time"?
Second point of clarification. The reason I point out the
cost is that in traditional methods, the users only devote
a part of their time providing information, and the loss of
productivity is spread over a large number of users and
stakeholders (typically) so that the costs are negligible
in terms of loss of productivity; about equal in management's
eyes to an extra couple of coffee breaks or a longer lunch
hour one day. I've actually observed that the time the
users have spent with us comes out of their time since
they are still expected to finish their daily quota, so they
may work late or through lunch to make up for the time
spent with us, and mid-management is well aware of this.
Cost; negligible. But my understanding of what you and
others are saying is that in agile you have at least one
full-time devoted representative from the business
community - stakeholder - in the room with the team.
That is a tangible, measurable cost. Is my take on
this wrong?
Gahh... Commitment? Do these people understand the
meaning of the word? If they are prepared to spend
money to develop a system, why aren't they prepared to
invest a bit of money to provide it with a good quality
source of requirements? It's no wonder they keep getting
fleeced for vast sums in change requests. Do they have
shares in these Beltway Bandits? If not, why not?
... So can we talk about Agile Modeling as it applies
to solving business problems that may not include code,
or is AM wrapped inextricably around the code?
Sure you can do agile modeling for business models.
You'd probably end up with a different pattern of what
sort of things get modelled 'agilely' because of the
different nature of what 'product' gets turned out, but
the ideas of AM all apply.
Wasn't Mary Poppendieck the one pushing Lean
manufacturing? Isn't she the same one that writes about
Agile Methods and sits on the XP 2004 committee or
something like that? I have to believe there is a tie
in with Agility and solving business problems in general.
If we can get to that, there will be no problem getting
Agile Development into the Corporate Board Room.
We simply use Agile Modeling methods to solve their
business problems and let them suggest we do the
same thing with software development. We will then
tell them it's a wonderful idea they had, and we understand
fully how they got to be a CxO.
There are cases where the business is already 'agile',
and they are pushing for the IT dept to go agile. Yes,
Mary has a book out on "Lean Software Development"
and does committees, etc.
... These days I spend about half the year in Scotland,
but with the upturn in the market, I might be down South
a lot more.
Never been up there. My lineage is Scottish, though.
Several clans, but the only one I remember is Kirk. My
mother tells me we are descendents of Scottish Kings.
I was boasting about it one time in a bar, and a Scotsman
told me that everyone of Scottish descent has a Scottish
King in their ancestry. Never mentioned it since til now.
That's probably near enough true. I can only trace back
direct ancestry to English kings (unfortunately including
Edward Longshanks - remember the bad guy in Braveheart?)
but one of those I know was also great grandaddy of Queen
Anne, last of the Stuart line of kings. But think of all those
possible lines that can't be traced...


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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