the great pyramid of agile

[Luis Motta Campos]

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.