Manager e eXtreme Programming

13 March, 2007 (00:54) | agile, extreme, programming, xp

Cito da un blog che seguo abitualmente

I honestly thought that project managers and myself as a functional manager needed to be there to identify where improvements needed to be made and make the team implement those improvements (whether or not they truly understand the improvements). As a result, the team became dependent on management to make things better. Those dependencies became bottlenecks, because we would try to implement big changes instead of a lot of little changes. I also thought it was management’s job to help assign tasks to people and make sure those people stayed on task. Again, this caused more bottlenecks. Here, the role of management was to REMOVE bottlenecks, yet we were BECOMING the bottleneck. All because of this notion that developers needed management to do these things for them. What developers really needed was practices that provided them the focus, direction, feedback and autonomy to do their work well. They are in the best place to know how to do their jobs well, so shouldn’t they be the ones who figure out how best to accomplish that? When management backs off and the teams realize that it is their responsibility to improve things, they will do so. Plus, in the process they will feel better about themselves, their role in the company and their feelings about management.


Non avrei potuto dirlo in maniera migliore, i nostri manager si devono dare una svegliata, la logica taylorista del command and control non funziona e non ha mai funzionato in un settore dove la produzione è basata sulla collaborazione e sulla creatività delle persone coinvolte. Lasciatemelo sottolineare di nuovo

What developers really needed was practices that provided them the focus, direction, feedback and autonomy to do their work well

E’ tutta colpa loro! E’ tutta colpa loro! Dagli, dagli all’untore!“… No, non è così, la maggior parte dei manager che ho conosciuto sono stati buttati nella mischia con l’obiettivo di “gestire” situazioni impossibili senza che gli fossero stati dati gli strumenti minimi per potercela fare, strumenti: metodologici, economici e politici

E’ finita! E’ finita! Scappiamo tutti!“… No, c’è speranza, anzi è proprio il fatto che siamo messi così male che mi fa ben sperare. Quando vengo chiamato per migliorare la produttività di un team, dico subito ai ragazzi che l’obiettivo è quello di trovare i nostri errori più grossolani perchè è li che si trovano le migliori opportunità di miglioramento, è vero, ci vuole coraggio per ammettere le proprie debolezze, ma una volta superato questo scoglio saremo un team migliore sotto tutti i punti di vista

… quindi?“… L’errore più grossolano in questo caso è quello della mancanza di un team. La prima volta che ho sentito parlare di Project Comunity è stato leggendo un articolo di Joshua Kerievsky e ne sono subito rimasto colpito, perchè il concetto di team deve fermarsi agli sviluppatori? Perchè non possiamo essere una squadra dove ognuno gioca secondo le proprie competenze e le proprie attitudini? Perchè non possiamo essere una squadra che si supporta a vicenda verso un obiettivo comune? E’ solo una questione di fiducia e coraggio… basterebbe poco per migliorare molto…

Write a comment