In a message dated 1/9/2004 8:39:52 AM Eastern Standard Time,
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
... it appears that you have control over who gets
assigned to your Agile Team from the Business
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.
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.
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
How do one know this? That is, how can we as the agile
team be sure that the person is truly representative (more
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
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
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
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
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
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
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.
...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â
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.
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
This email was sent to: firstname.lastname@example.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: email@example.com
TOPICA - Start your own email discussion group. FREE!