title: Méthodologie vs. compétences

>  Moreover, Tim’s initial team were the earliest of early adopters hand-picked by Tim himself. They were the very people that would develop high quality software naturally anyway. The only role the MDD had was in helping the team to gel, and once they had they looked like an impossibly productive team. Tim misidentified the source of this productivity as being the result of his methodology, rather than his competence of himself and his team. 
>
> […]
>
>  Don’t fall in to Tim’s trap. Great developers create great software not because they follow the strictures of some methodology but because they are truly great, gifted artisans. 
> 
> <cite>*[Meditation Driven Development](http://www.ckwop.me.uk/Meditation-driven-development.html)* ([cache](/david/cache/28d1831edaec0fd821959314a0a22644/))</cite>

C’est l’éternel débat entre inné et acquis, don et persévérance,  chance et travail, idée du siècle et *LEAN*. On peut aisément [critiquer une méthode](http://www.merkapt.com/entrepreneuriat/business_model/lechec-des-methodes-dinnovation-8607) ([cache](/david/cache/b6dc2d3aa8435cb4bf82f735c7bf50b6/)) pour les illusions qu’elle donne, mais on a parfois aussi besoin de certaines illusions pour progresser et se mettre en marche puis s’en affranchir.

Les meilleurs joueurs d’échecs sont aujourd’hui des équipes combinant un humain et un ordinateur. *La méthode est un partenaire.*