Enterprise Architecture: From Incite comes Insight...

>
> Scott - I now regret mentioning you on my weblog. But since you
have
> chosen to respond instead of just letting it pass, I guess we have
have
> let this play out. Hopefully I won't lose too many subscribers.
I'm not
> going to let this thread continue beyond a few posts.

Charles, you'll only lose subscribers if they feel that you're
wasting their time.

When you attack someone publicly, you shouldn't be surprised when
they respond. One of your existing subscribers was concerned that
you had chosen to attack me, and was kind enough to let me know that
it had happened.

>
> 1. I read your whole article. I stand by my quote. It was fair. I
> wasn't reviewing your whole site. I don't agree that a weblog
author
> needs to inform the subjects of their postings.

It's common courtesy to do so.

>
> 2. You didn't mention ITIL in that specific article. You made a
blanket,
> misleading statement to your audience in that article, including
people
> unfamiliar with your other work, who might well take that
statement at
> bald face value - "there's nothing out there, folks!" The longer
version
> you provided below is equally misleading.

Charles, you chose, in your arrogant manner, to imply that I needed
to read about ITIL. Had you chosen to do your homework, perhaps
something as simple as Googling my name with those terms, you would
have very quickly discovered that I have gone out of my way to
promote ITIL. If you have egg on your face now, it's clearly not my
fault.

As others have pointed out to you, COBIT is not very well accepted
within the community. ITIL, in my opinion, is much better accepted
although still struggles to become mainstream.


>
> There IS a large body of work and knowledge on IT governance,
extending
> even beyond ITIL, COBIT, and CMM. We just don't have the
controlling
> professional organization to rationalize and "accept" it like the
> accountants do (although ISO 20000 is a start). And no framework
ever
> claims to be one size fits all - they all need context-specific
> interpretation and tailoring.

Agreed. And it's doubtful we'll ever have such an organization
within our lifetimes and it's even more doubtful that it will come
from the command and control crowd.

>
> 3. Popularity has nothing to do with using COBIT vs. Agile. That's
a
> ludicrous apples and oranges comparison. COBIT is not incompatible
with
> Agile, and ITIL is equally capable of generating paper pushing.

Popularity is important. If COBIT isn't on people's radar scopes,
then it is very likely not a viable option for most development
shops. Considering that COBIT has been around for a long time, I
wouldn't hold out much hope for it.


>
> 4. The heart of the matter: You still have to answer for your
advocacy
> that project teams can/should bypass IT governance ("blocking") if
it
> suits them. Do you disavow this unethical article:
>
http://www.sdmagazine.com/documents/s=8269/sdm0307h/sdm0703h.html ?

Thank you for misrepresenting me once again, although I appreciate
that you at least shared the URL with people. In that article, I
clearly state that blocking should be considered a last option only
when the bureaucrats around you prove to be too inflexible to work
with you effectively. To quote, from the middle of the article:
"First, you need to find a way to work with these folks. An agile
team should have stakeholders from all involved areas, so everyone
involved will need to be flexible—including you. You must listen to
their concerns and questions, and find ways to gain their trust and
interest in the project. They must be willing to try working in an
agile manner—which means an evolutionary approach. "

The folks that it refers to were described in the previous
paragraph, data administration, quality assurance and enterprise
architecture groups (that isn't meant to be an extensive list).

Later in the article, I advise: "So what do you do if other people
aren't flexible enough to evolve their approach into a more agile
one—even after you've tried education and communication? The answer
is simple—you block them. "


At the end, to quote again:
" Remember, if you're using a blocker or intend to do so, your
organization clearly has a big problem. Though blocking can serve as
an effective stopgap measure to get a project past the goal line, in
the larger sense, it's like applying a Band-Aid to an injury that
requires major surgery. Subterfuge should be a last resort, but if
you've failed all other attempts (education and communication
foremost among them) to combine an agile team with a rigid power
structure, blocking may be your only alternative to maintain the
agility necessary to reach your goal. Use a blocker if you need to
get through the project, but after that, step back, evaluate the
situation and consider rethinking your approach to software
development. "

So, where is the ethics problem? I very clearly identify a common
problem, suggest that people try to do the right thing and work with
these other groups constructively, but only as a last resort block
them in order to get the job done. The mission of software
development teams is to build high-quality working software which
meets the changing needs of the project stakeholders. If they're
being prevented from doing so by these other groups of people, then
they need to find a way to get the job done. The real ethical
problem is why are these dyfunctional enterprise groups even being
tolerated, because in my experience if one team is blocking them
then more than likely many teams are.

Futhermore, in the article I also point out that blocking appears to
be quite a common practice. To quote: "Lately, I've been talking
about blockers at conferences. When I ask people if they're doing it
now or if they've done it in the past, I see a lot of hands held
high. When I ask if they've been caught, only a few hands remain
aloft. The coin flips both ways, too: If you're not working directly
on a project team, but instead are "supporting" one or more teams,
you may want to ask yourself whether you're being blocked. "

What's your real issue Charles, afraid you're being blocked but
can't tell if it's happening? Or worse yet, are you being blocked,
know it, but can't do anything about it?


>
> Until you formally retract this, in print, we will continue to have
> major differences - and I will continue to view you as a person
with
> little standing to discuss questions of IT governance (my basic
> motivation for criticizing your article). Previous discussion,
never
> resolved:
>
> http://groups.yahoo.com/group/dm-discuss/message/8830
> http://groups.yahoo.com/group/dm-discuss/message/8853
> http://groups.yahoo.com/group/dm-discuss/message/8856
> http://groups.yahoo.com/group/dm-discuss/message/8858
> http://groups.yahoo.com/group/dm-discuss/message/8860
>

Charles, bottom line is that I appear to have fairly decent standing
within the practical subset of the IT community.

I'll let others be the judge on this list. What do you think about
my February column, or about the need for blocking once all other
avenues have failed project teams which are trying to get the job
done?


>

> 5. IT professionals deal with "useless bureaucrats" every day in IT
> finance, HR, quality assurance, PMO, and yes, data admin. Get a
broader
> perspective on what the control process is trying to achieve and
apply
> process improvement techniques to wring out all true non-value-add
> activities - don't just trash the people who have the misfortune
to be
> the enforcers.

I have a spectacularly broad perspective on software process. I
(co)-wrote the first CMM-Level 5 compliant process for OO
development (the two Process Patterns books), the first major
extension to the RUP (the EUP book and earlier the UP series from
CMP books), in addition to several books on agile techniques.

I've had the opportunity to work in a wide range of organizations,
and I've seen the results of a wide range of techniques.

Frankly, if you think that your role is to "enforce" a process then
you've already lost the battle.

>
> 5. I have never misrepresented anything you have said or wrote.
You just
> go out on a limb sometimes and make irresponsible statements, and
you're
> too influential to not get called on it.

Please. You clearly misrepresented me in your initial post.

Don't assume that you can attack me and not get called on it.

- Scott