No importa, pasan los años y, como en aquella gran película de «el día de la marmota», hay cosas que se siguen repitiendo, y repitiendo, en un sitio y otro (o será que yo tengo muy mala suerte y me los encuentro todos) en el mundo de la agilidad flácida o la pseudoagilidad. Un mundo que usa frameworks como Scrum pero que, a la vez… está repleto de prácticas oscuras y poca cultura ágil.
Muchas veces esas prácticas oscuras se usan de manera inconsciente, por herencia, por desconocimiento, sin mala fe. Y en aquella inconsciencia, muchos equipos se preguntan «por qué no me funciona el cambio», “por que la agilidad no nos sale”. Algunos creo que nunca llegarán a saber la razón.
De entre todas esas posibles prácticas oscuras, una de las que yo más me encuentro, quizá la más arraigada, una de las más difíciles de hacer ver, una de las que más impacto tienen es… gestionarse por proyectos… en vez de por equipos. Lo tenemos ahí, metido en el cerebro, lo llevamos en la cultura y por eso es tan difícil erradicarlo. Un tema al que le he dedicado, sin excesivo éxito, muchos post e incluso hasta un vídeo (lo dejo, de nuevo, abajo).
Por si aún puedo ayudar a la Galaxia a salir del imperio de los proyectos que la asola, para que reflexiones si estas sufriendo en silencio un caso de dolencia por proyectos, y si por eso “no te sale la agilidad”, te voy a dejar algunos síntomas típicos que te pueden hacer sospechar y sobre los que yo me andaría alerta y con cuidado.
Tener Sprints iniciales y finales
«Grandes» frases… «en el sprint inicial», «en el sprint final». Frases que, claramente, suenan a la fecha inicial y final de los proyectos de toda la vida. Algo característico de los proyectos, que no necesariamente de los equipos. Los proyectos tienen fin (supuestamente), los equipos y los productos o servicios no (o no se presupone una fecha estimada de finalización). No hay un Sprint de fin prefijado.
Pensar en fecha fin es peligroso para soluciones, servicios, software, etc. No me extiendo aquí, que para eso ya le dediqué un post… Aclarando qué significa “fecha fin” y, de nuevo, ojo, con los peligros de los proyectos. Pero recuerda, una cosa es fecha fin y otra fecha de entrega.
Si trabajas con Sprints iniciales y finales, tengo serias dudas de ese modelo ágil y, peor aún, de que te gestiones por equipos “por encima de” proyectos.
Fijar horas de dedicación de las personas del «equipo»
Otro de los grandes, que puedes observar en frases del tipo a… «es que Anakin (o quién sea), durante el Sprint, está media jornada en esta aplicación, o proyecto, y la otra media en el otro». Que mal suena eso ¿no? ¿no te parece que suena mal?
De la anterior frase hay tantas cosas que se pueden sospechar que darían para un post dedicado. Menuda auto-organización tiene un “equipo” así ¿no? Y que extraña priorización del Backlog debe ser esa. Curiosas deben ser las reuniones de planificación.
Si no tienes más opción, y un equipo debe trabajar en varios proyectos o productos, valora la opción de que en un backlog mínimo, y priorizado, pueden entrar items de esos diferentes proyectos o productos, combinadas, de muy diferentes maneras, según las circunstancias, y sin la rigidez, poca adaptación, poca auto-organización, poca optimización, etc., de fijar horas – persona dedicadas a algo concreto y cerrado.
Montar, y desmontar, equipos según proyectos
Curiosamente, esto, lo de hacer y deshacer equipos, en algunos lugares (y me parece un error estratégico muy grande y en algunos sitios se está haciendo a gran escala), se asume como súper-ágil, frente a la idea, verdaderamente ágil, del equipo estable (post).
Un equipo de alto rendimiento necesita tiempo (puedes mirar el modelo de Tuckman sobre este tema), si, cada dos por tres haces y deshaces los equipos quizá que, en vez de equipos, tengas “gente junta”.
De nuevo, síntoma de que, muy probablemente, te estés guiando por proyectos en vez de equipos.
Terminando
Hay muchos más síntomas que te pueden hacer sospechar, pero estos 3 son un clásico. Si te pasa algunos de los anteriores “háztelo mirar” y piensa sobre ello. A un post no le podemos pedir más, ni es un médico.
Si te pasa alguno de los anteriores analiza profundamente porque ese puede no ser el modelo más optimo de trabajo.
- Quieres que tus equipos cambien, pero pasan de ti + Nuevo video OKRs con IA + Cumplo 24 años de Doctor en Informática #LaNewsletterdeJavierGarzas - 26 septiembre, 2024
- Amazon: la IA nos ahorra 4.500 años de programación + 3 familias de ESTIMACIÓN + Video creando Videojuegos con Hija e IA #LaNewsletterdeJavierGarzas - 19 septiembre, 2024
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
Excelente post Javer, gracias..
Pero olvidaste dejar el link al video que prometiste en el tercer parrafo.
Gracias, ya he puesto el vídeo. Saludos!
Hola Javier,
Me gustaria tener contigo una asesoria, ahora en la empresa donde estoy se van a implementar los procesos y me gustaria tener una charla para hacerlo bien.
Hola, escríbeme a jgarzas@gmail.com y lo vemos ok?