the great pyramid of agile
Luis Motta Campos
luismottacampos at yahoo.co.uk
Thu Jun 14 08:17:34 BST 2007
On Jun 13, 2007, at 10:36 PM, Daniel Barlow wrote:
> I have read the article, and I can summarise as it as "dicking about
> with methodologies is not helping us solve the real problem, which is
> that too many developers are crap"
> [snip]
> It's a bit like saying "comfortable chairs are not helping us solve
> the
> real problem, which is that too many developers are crap". Sure,
> but if
> you try putting the department on cafeteria seats you're only adding
> higher staff turnover to whatever problems you had already. (Where
> the
> analogy breaks down is that the cafeteria seats probably make *all*
> the
> staff unhappy, whereas crap methodology probably annoys the good
> developers disproportionately, because the bad ones don't care anyway)
I agree with you about the bad programmers. They're one of the
biggest problems.
But another big source of trouble is that most part of the
management staff also doesn't care about having good methodologies:
no mensurable results will be *quickly* extracted from them, and this
makes the management team reacts "neutral" (and look at "cost/
benefit" ratios for something to manage).
How to convince a manager that just can't even use a standard
office computer properly that methodologies are a Good Thing?
How to point them to short-term mensurable results that will make
them drop the idea that "if the developer is not typing, the project
will be late"?
I still looking for a methodology that teaches me how to make sure
my manager trust me when I say "this is crap and we should throw it
away"(*). Should I stop looking and start choosing better managers to
work with?
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}
(*) Of course, I use to be much more polite with my manager, and
offer a lot more information than just one adjective.
More information about the london.pm
mailing list