Desde que me dedico a dar apoyo a organizaciones y a equipos de desarrollo en sus procesos de transformación ágil, he tenido la oportunidad de facilitar y participar en muchas sesiones de Scrum, siendo en el evento de Sprint Planning donde me he topado una y otra vez con una misma pregunta cuando llega el momento de realizar estimaciones relativas:
¿Cómo puedo estimar el esfuerzo que implica hacer toda una nueva funcionalidad, si yo sólo sé cómo hacer una parte de la misma? Desconozco lo que hay que hacer en las otras partes, por lo tanto solo puedo estimar mi parte.
Siempre que pensamos en sesiones en las que tenemos que realizar estimaciones relativas, nos imaginamos a todos los miembros del equipo aplicando planning poker, estimando el esfuerzo que conlleva entregar una funcionalidad de una forma muy amena y colaborativa independientemente de la experiencia técnica de cada uno de los miembros. Pero la realidad es que esto ocurre en muy pocas ocasiones, y es completamente comprensible, yo diría que es hasta natural. El desarrollo de una funcionalidad implicará realizar tareas de diversas áreas: UI, UX, front, back, BBDD, etc; pretender que todos los miembros del equipo estimen todo este trabajo, es casi como pretender que todos los miembros del equipo sean full stack y sabemos que esto es irreal. Entonces:
- ¿cómo se estima en la vida real?
- ¿todos estiman todo aunque no sea su terreno?
- ¿cada uno estima lo suyo y luego se suma para obtener la estimación total del esfuerzo que conlleva construir una nueva funcionalidad?
En este artículo me gustaría desenmarañar lo que hay detrás de esta disyuntiva y, más importante aún, plasmar según mi experiencia cómo creo que deberíamos abordar esta dificultad para conseguir verdaderos equipos Scrum.
Comencemos por definir qué es un equipo Scrum. Según la guía de Scrum, un equipo Scrum se define como un equipo auto-organizado y multifuncional, es decir que tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.
Y aquí aprovecho la ocasión para aclarar una mal interpretación muy extendida sobre lo que es un equipo multifuncional: un equipo multifuncional no significa que todo el mundo sabe hacer de todo; multifuncional significa que el equipo en su conjunto, uniendo lo que cada persona sabe hacer, posee todas las competencias necesarias para lograr completar el trabajo, sin depender (o dependiendo mínimamente) de otros equipos, áreas, departamentos o roles fuera del mismo.
Entonces, si el propio framework prescribe equipos multidisciplinares: ¿por qué las estimaciones persiguen estimaciones globales a nivel de una funcionalidad específica? Porque el hecho de que el framework prescriba equipos multifuncionales, no significa que promocione el trabajo por silos, significa que es realista en cuanto a cómo somos las personas y los equipos, pero también es realista en cuanto al poder del trabajo en equipo y a que las personas somos mucho más productivos y capaces cuando trabajamos en equipo. Por otro lado, cuando se pide una estimación es sólo eso: una valoración, una aproximación, no un compromiso irrefutable e inamovible escrito sobre piedra. Estimar, sea como sea (días o puntos de historia), es solo una excusa para fomentar el principal objetivo de la estimación, que es: la conversación. Sí la conversación es lo verdaderamente valioso para el equipo, mucho más que el número que obtengamos, porque nos permite:
- Detectar posibles tareas ocultas y posibles obstáculos. La sesión de estimación es una de las primeras oportunidades de detectar riesgos que pueden comenzar a tratarse para que no se conviertan en impedimentos.
- Tener una visión compartida de lo que se viene encima. Si todos conocemos las implicaciones de desarrollar una nueva funcionalidad es mucho más sencillo comprometerte con un plan de trabajo a que si las estimaciones nos vienen «impuestas».
Por todo lo anterior expuesto, lo ideal es que todos estimen el esfuerzo que implica desarrollar una funcionalidad ya que con ello promovemos:
- El sentimiento de equipo, en el que trabajo y la responsabilidad es de todos y no que cada uno hace su parte y se desentiende del resto.
- El conocimiento en T de los miembros del equipo, es decir que cada integrante tenga un conocimiento básico o medio de todo y un conocimiento muy especializado en un área (su especialidad).
- Evitamos el bus factor, favoreciendo que el desarrollo de nuestro software pueda continuar a pesar de la ausencia de alguno de los desarrolladores.
Y ¿cómo se consigue esto? con mucha conversación, colaboración, práctica y con personas que sean virtuosas en práctica de los cinco valores de Scrum: compromiso, coraje, foco, apertura y respeto. Como sabemos, cada equipo es un mundo y la forma de hacerles coaching debe adaptarse a cada uno, por lo que no hay una fórmula única para conseguir llevarlos a la estimación global. Sin embargo, partiendo del principio de que estamos realizando estimaciones relativas, es decir, estimaciones que son relativas a una funcionalidad base que el equipo ya ha implementado o que le es sencillo estimar, propongo dos estrategias que pueden ayudar a los equipos a estimar a nivel de funcionalidades:
- Hacer las cosas bien desde un principio: esto es, ante la pregunta inicial, se explica con argumentos sólidos y claros por qué todos deben estimar todo el esfuerzo y como la experiencia puede ser abrumadora en un principio, pero también como, con el paso del tiempo y a base de mucha conversación sobre lo que implica el trabajo del compañero, todos comenzaremos a comprender más y mejor su competencia, trayendo como consecuencia que nuestras estimaciones sean cada vez más realistas (no más precisas).
- Un paso intermedio antes: esto es, permitimos que se sub-dividan una funcionalidad en sub-tareas técnicas y que se estimen por separado, pero incentivamos de alguna manera el intercambio de conocimientos. Propongo dos técnicas:
- En las conversaciones en la que se discute el trabajo de una tarea de front, por ejemplo, los de back deben estar atentos comprendiendo a groso modo las implicaciones de «su trabajo» y viceversa.
- Otra técnica, es que: dada un tarea de front, pidamos a los especialistas en back que describan lo que ellos consideran que implica llevar a cabo esa tarea, luego pedir a los front que corroboren o confirmen esa aproximación y luego a la inversa con una tarea de back.
Lo importante es motivar que haya un intercambio de papeles logrando con ello reducir el desconocimiento sobre el área de conocimiento del compañero. Finalmente, después de realizar varias sesiones de estimación de esta manera deberíamos cambiar al modelo de estimaciones a nivel de funcionalidades. Hacerlo así permite una evolución paulatina hacia el modelo ideal.
En conclusión, generalmente al principio los equipos serán pocos maduros y muy especializados, por lo que es casi seguro que nos topemos con esta duda o dificultad, pero es nuestro trabajo como promotores del cambio, conseguir una transformación cultural tal, que les permita comenzar a ver el trabajo como una unidad, de la cual todos son responsables y que a pesar de que no todos sepan de todo a bajo nivel, puedan comprender el trabajo del otro lo suficiente como para poder estimar el esfuerzo que cuesta una unidad de trabajo en conjunto. ¿Tú que opinas? ¿Alguna otra experiencia o técnica que nos puedas compartir?
