A todo el mundo le parece que lo más importante o, al menos, que es muy muy importante… aquello que más le gusta hacer. Razonable, lógico, cómo iba a ser de otra manera.
Es decir que, por ejemplo, a la gente de arquitectura le gusta, obviamente, diseñar arquitecturas, implementarlas, etc. Y para ellos dedicarle tiempo, a veces mucho, a la arquitectura es muy (a veces lo más) importante.
Y este mismo ejemplo, lo podemos extrapolar a todos los perfiles que son necesarios para añadir una funcionalidad a un producto (o servicio) que aporte valor a un usuario.
El ejemplo sería valido para la gente de UX, desarrolladores de front, de back, gente de QA, profesionales de Testing, Product Owners, Scrum Master, los de Seguridad, etc.
Hasta aquí todo bien, lógico y normal salvo por dos posibles problemas: que cada uno nos pasemos demasiado tiempo haciendo aquello que nos gusta y consideramos muy importante y/o que por dedicarnos mucho a aquello que nos gusta descuidemos otras cosas que nos gustan menos.
El problema de que cada uno nos pasemos demasiado tiempo haciendo aquello que nos gusta y consideramos muy importante debería ser obvio… hace más lento incrementar la funcionalidad del producto y aportar valor al usuario.
Claro que hay que dedicarle tiempo al diseño, arquitectura, UX, desarrollo, Testing, QA, etc. Pero entre no dedicarle tiempo o dedicarle todo el tiempo del mundo, parece razonable pensar que hay un punto medio que nos hará ser más rápidos, eficientes sería la palabra, en la entrega de valor a negocio.
Pero si no tenemos todos claro y compartimos que, más allá de nuestros objetivos o gustos profesionales, hay un objetivo común superior que nos aúna (sin objetivo común no hay equipo), y que es entregar valor e incrementar funcionalmente el producto… probablemente antepondremos nuestros gustos a las necesidades de negocio.
El segundo posible problema de todo esto viene de que, pudiera pasar que, por dedicarnos mucho a aquello que nos gusta descuidemos otras cosas que nos gustan menos (y que están bajo nuestra responsabilidad).
Un ejemplo (posible ejemplo, por supuesto) son algun@s Scrum Master que, siendo un rol que debe liderar varias dimensiones, el proceso, el crecimiento del equipo y la parte técnica en pro de la eficiencia (como ya hablamos en el post de mi Scrum Master ideal y la más desoladora, terrible y oscura pregunta que puede escuchar un Scrum Master y del que te dejo la imagen de abajo), pues, pudiera pasar, que… se dediquen solo a lo que más les gusta.
Por ejemplo, que si soy Scrum Master y me encanta el desarrollo de equipos pues dedique el 90% de mi tiempo a ello y solo un 10% a mejorar el proceso o detectar mejoras técnicas que pudieran incrementar la eficiencia del equipo. Y esto es un problema.
No tengo una receta final de post para resolver este problema, pero me daría por satisfecho sólo con que se entendiera que más allá de lo que nos gusta, aquello a lo que no nos importa echarle horas y horas, hay un objetivo común de equipo, superior, que debería aunarnos y hacernos reflexionar sobre la justa medida de tiempo a dedicarle a cada tarea… el valor y la eficiencia.
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