|
 Absolutamente ciertas las limitaciones que apunta Bruno Collet en The.project.management.hut
La popularidad de los modelos ágiles hace que de corte hacer cualquier crítica, por miedo a ser tachado como profesionalmente desfasado, pero a la agilidad le pasa lo mismo que a los procesos: no vale para todo.
"Decir software es decir mucho y no decir nada. Que de software es el sistema de guiado de un misil balístico, y de software también el juego de la videoconsola; pero no es razón suficiente para que ambos se tengan que desarrollar con los mismos procesos de ingeniería, o con las mismas prácticas de gestión.
De que en nuestro sector hay empresas como SAP, Google o start-up’s de 5 empleados; y que cada uno anda mejor con zapatos de su talla, diseñados para su terreno, que calzando todos talla y modelo único." Volviendo a las limitacoines de Bruno:
1.- Equipo de estrellas.
Ingenieros de la talla de Martin Fowler, Ron Jeffries o Jeff Sutherland se han visto cómodos trabajando con los métodos que iban diseñando. Si tomamos programadores de cualquier nivel, se les confía auto-organización, diseño de la solución y que trabajen sin procesos de supervisión... ¿cuál puede ser el resultado?. Como apuntaba Ken Schwaber, "Scrum también funciona con idiotas "(Trabajo, talento, procesos y agilidad) 2.- Encaje con la cultura organizacional.
Exacto. No vale con usar técnicas de gestión de proyectos ágil. Si estamos en la empresa dirigida por MBA's de procesos industriales, o peor aún, de amigos del consejo de administración... los gestores ágiles llegarán a su casa todos los días desesperados. Como apunta la visión de Scrum Management , el área de gestión de la organización es también necesaria.
3.- Tamaño del equipo.
Aunque en este punto se puedan plantear scrums de scrums y equipos piramidales, la verdad es que pasando de 5 -6 personas, la eficiencia cae considerablemente.
4.- Ubicación física del equipo.
También se hacen implementaciones en equipos físicamente distribuidos, pero se pierde la interacción y comunicación directa. Es una agilidad al 50% (como mucho).
5.- No hay apoyo de procesos.
También. Según el proyecto y la organización hace falta un nivel menor o mayor de procedimentación para áreas como gestión de la configuración, verificación&validación, etc. (síntesis)
La última debilidad que apunta Bruno, y las dificultades de recompensa a las personas, en realidad es una consecuencia del punto 2: cultura organizacional. La agilidad y la cultura organizacional deben estar alineadas. Debe ser una organización basada en equipos.
 |
RSS de los comentarios
