Post de esta serie:
- Tipologías de equipos software (I). El equipo “Control y Mando”
- Tipologías de equipos software (II). El equipo cirujano
- Tipologías de equipos software (III). Patrones y buenas prácticas para organizar un equipo
Como podías esperar, y yo te suelo recordar por aquí, no hay una definición única sobre qué es un equipo ágil (más aún teniendo en cuenta que no hay una única y precisa definición de lo que significa agilidad), cosa que suele ocurrir con frecuencia en el mundo de la gestión e ingeniería del software. Sí, sí, ya, el “equipo ágil” debe seguir el “manifiesto ágil” para ser “ágil”, etc., pero está lo suficientemente abierto como para darse a varias interpretaciones o “grados” de agilidad.
No obstante, si que hay ciertas características, comúnmente aceptadas y típicas, en un equipo considerado “ágil”. Como también te suelo comentar, esas buenas prácticas, realmente, son la adaptación de buenas prácticas de hace años, que en su momento no fueron tan populares y que el movimiento ágil ha sabido rescatar y adaptar a nuestros tiempos.
Ejemplo de estas buenas prácticas son los equipos multifuncionales (que ya mencionó Brooks en los 70), muchas ideas del Peopleware (de los 80, DeMarco, etc.), trabajar con equipos pequeños (de Putnam en los 80), etc.
En cualquier caso, vamos a resumir qué, de manera más destacada (la lista podría ampliarse), caracterizaría a un equipo ágil:
1 – Auto-Organizado
Característica de las más mencionadas al hablar de agilidad, así como de las más malinterpretadas y peligrosas cuando mal entiende (en un futuro le dedicaré un post a las razones de por qué te digo esto de peligroso). En síntesis, un equipo auto-organizado tiene tres características principales:
Autónomo: No existe un único centro de toma de decisiones o de autoridad. El control se distribuye conjuntamente por todo el equipo.
Adaptable: El equipo se ajusta dinámicamente según sea necesario, con el fin de resolver sus propios problemas y mejorar su propio desempeño.
Responsable: El equipo comparte colectivamente la responsabilidad de los resultados.
En el post de qué va eso de “equipo ágil auto-organizado”, que verás que no es nada fácil de lograr, tienes más detalles sobre este punto.
Si vienes del mundo tradicional, una de las preguntas típicas en este punto es, -“Si no hay un único centro o persona para la toma de decisiones… ¿Quién es el jefe de proyecto en un proyecto ágil – Scrum?“-.
Puedes revisar el anterior post para más detalles, si bien te comento que en Scrum, el papel tradicional del jefe de proyecto no existe como tal, está realmente dividido en dos roles: las funciones del Product Owner (si no conoces el término aquí tienes una buena recopilación sobre el rol de product owner) y las del Scrum Master (te dejo más información sobre el Scrum Master en este post).
2 – Pequeño en número
Más que tratado en este blog este punto, recuerda aquello de por qué los equipos con mucha gente (más de 7) son menos productivos. O por qué tener equipos pequeños es una buena práctica (ágil, además). Tema popularizado por Putnam, que revisó 500 proyectos software y los clasificó en los que tenían equipos de entre 1,5 y 3 personas, de 3 a 5, de 5 a 7 y de 15 a 20.
Los resultados de Putnam evidenciaron que cuando el tamaño del equipo crecía el esfuerzo, lógicamente, al haber más gente, aumentaba pero el tiempo de proyecto no se reducía. Las razones:
– La coordinación mayor que requerían esos equipos grandes, las mayores y más numerosas actividades de gestión.
– El incremento de las rutas de comunicación entre sus miembros, lo cual crea más errores. A más personas, más líneas de comunicación aparecen.
Así que si tienes mucho más de 10 personas en tu empresa, lo ideal es que las organices en equipos de 10, lo que suele tratarse en estrategias para escalar Scrum en las empresas
3 – Multifuncional
Un equipo multifuncional (puedes ampliar información en los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad) es aquel equipo que posee todas las competencias necesarias para lograr completar el trabajo, sin depender (o dependiendo mínimamente) de otros equipos, áreas, o roles fuera del mismo.
No significa que todo el mundo dentro del equipo sepa hacer de todo, significa que el equipo en su conjunto es autosuficiente y tiene el conocimiento y habilidades necesarias para construir la parte del producto que le toca y que la especialidad de cada miembro puede ser complementada por algún otro miembro del equipo.
Más…
Todo lo anterior es, en mi opinión, lo más destacado, importante y característico. Luego cada casa amplia lo anterior con multitud de prácticas, que yo creo que ya dependen más de situaciones concretas, como los temas de motivación, Propiedad Colectiva, etc.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024