¿Qué frase nos da pistas sobre el tipo de Scrum que se hace en las empresas? Empiezas a trabajar en una nueva empresa o con un cliente, y te dice: “aquí tenemos Scrum”. Después, empiezas a investigar y descubres que no era real. Hemos hecho una recopilación de varias frases que solemos escuchar en las empresas y que nos indican que no han interiorizado la mentalidad.
“Hacemos gestión de Proyectos con Scrum”
¡Esta frase es un clásico! Las empresas están organizadas en proyectos y entienden Scrum como un método de gestión. Sin embargo, Scrum es un marco para trabajar en producto, teniendo como objetivo la entrega de valor en entornos complejos ¡Nada que ver con proyectos!
“Al finalizar el Sprint hacemos una Demo”
Uno de los grandes errores de Scrum es confundir la Sprint Review con una Demostración. En la Sprint Review, inspeccionamos y adaptamos nuestro producto para saber si estamos generando valor y, así, poder tomar decisiones al respecto. Una demo es una presentación para justificar un trabajo, orientada al control y, también, a saber si llegamos a una determinada fecha, pero todo ello no garantiza que estemos construyendo el producto correcto.
“En el equipo tenemos Front, Back, QA…”
Otro error bastante habitual en las empresas es hablar de equipos y etiquetas. Dentro de los equipos Scrum tenemos deverlopers, las personas que construyen el producto. Eliminamos las etiquetas para hacer ver que la responsabilidad del éxito/fracaso es compartida. En la práctica, los miembros pueden dedicarse a tareas concretas.
“Usamos el Sprint 0 para saber lo que el cliente quiere”
Esta frase es muy repetida en empresas que apuestan por el Sprint0 como propuesta de trabajo con sus clientes. El problema del Sprint 0 es que, en general, provoca trabajar en modelo waterfall encubierto. Si invertimos mucho tiempo en “saber lo que el cliente quiere” y, después, dedicamos muchos Sprints a desarrollar, estamos corriendo el riesgo de que las necesidades cambien y de no tener margen para adaptarnos.
“Estimamos todo lo que va a entrar en el Sprint”
“Estimar” no es una práctica fake-Scrum de facto. Es cierto que muchos equipos que estiman demuestran que hay detrás un cierto “control” de que el equipo trabaja mucho. Estimar, desde nuestra perspectiva, es desperdicio, ya que utilizando una predicción estadística podemos obtener una mejor predicción y sin gastar tanta energía. Ahora bien, el hecho de querer “llenar el Sprint” demuestra que el equipo vive en una cultura de “trabajar mucho” y no de “trabajar en lo correcto”, y esto sí que huele a fakeScrum.
“La fecha fin ya está decidida”
Esta frase denota, una vez más, que seguimos con la mentalidad de “entrega en fecha”, y que solo buscamos en Scrum un medio para cumplirla ¿Sería un éxito alcanzar una fecha si construimos un producto que nadie quiere? Por eso, Scrum pone el foco en producto, que no obvia las fechas, que formarán parte de la estrategia que quieras mantener.
“No medimos valor”
Esta es, posiblemente, la frase más clara que nos muestra que estamos ante un fakeScrum. Scrum consiste en maximizar valor a través del producto que construímos. Medir valor es la manera de asegurarnos que tomamos las decisiones correctas ¿Gracias al último Sprint hemos aumentado nuestro valor? El valor es dependiente del contexto y del propósito del equipo, pero todo equipo debería tener métricas que validen su trabajo, si no, Scrum pierde mucho sentido.
“Medimos valor en puntos de historia”
De cara a combatir la frase anterior, hay equipos que aseguran medir valor, pero en forma de puntos de historia. Los puntos de historia no son valor, solo son trabajo y ni siquiera sabemos si son el trabajo correcto. Lo importante no es trabajar mucho sino trabajar en aquello que nos rente más y genere mayor impacto en nuestro negocio. Puedo medir el número de casas que construye una cuadrilla de albañiles, pero que estén vacías porque nadie las quiere.
” Sí, hacemos todos los días Daily, el Scrum Master nos dice lo que deberemos hacer durante el día “
Uno de los eventos más pervertidos es la Daily Scrum. Su función es de coordinación, si los developers tienen que autogestionarse para poder entregar y generar incremento, necesitan este evento de inspección y adaptación. El Scrum Master puede estar presente, pero su función es centrarse en que la Daily Scrum salga bien, no en organizar el trabajo ¿Qué tipo de autogestión hay en un equipo cuyo Scrum Master les dice lo que tienen que hacer?
” El Scrum Master, en la Planificación, mete lo que hay que hacer en el Sprint y nos asigna las tareas a cada uno para el Sprint “
Al igual que la frase anterior, el Scrum Master enseña autogestión, pero no se encarga de repartir el trabajo. Un equipo que tenga un Scrum Master para repartir su trabajo es un equipo que sigue trabajando bajo un paraguas tradicional. Es más, en la Sprint Planning, podemos dejar fuera al Scrum Master al crear el Sprint Backlog. Si queremos forzar que el equipo tome las riendas de su trabajo, puede ser un buen comienzo.
“El Scrum Master es tan bueno que Jira siempre está actualizado”
Jira es uno de los software más extendidos en las empresas hoy en día. Jira bien usado puede ayudarnos a organizar el trabajo, pero pocos equipos saben utilizarlo correctamente. Realmente, si es la herramienta que hemos decidido usar, esto no libera a los Developers de mantener, definir y utilizar su Sprint Backlog (en forma de Board). Si el Jira se actualiza porque el Scrum Master se encarga de ello, todo apunta a un fakeScrum donde seguimos teniendo un Scrum Master de control.
El Sprint report ya está listo para la gerencia
En cualquier equipo que pertenezca a una organización es bastante normal hacer reportes para explicar el estado del equipo. Un reporte no es malo en sí mismo. Ahora bien, por encima del reporte, Scrum nos propone que usemos el Sprint Review como momento para inspeccionar y adaptar el estado actual de nuestro producto. Si la gerencia quiere saber el estado de nuestro producto, participar en la Sprint Review suele ser una buena idea. En ella necesitamos feedback y necesitamos saber si vamos por el buen camino.
El Product Owner lo pone el cliente
Esta frase es muy compleja. En un modelo cliente-proveedor, no está claro cómo resolver quién define al Product Owner. Si lo elige el cliente y no tiene experiencia en Product Management, estaremos muy vendidos. Pero también es verdad que, en muchas empresas, si el Product Owner es externo, tiene dificultades para “moverse” a través del cliente para gestionar expectativas, conocer los requisitos o desbloquear impedimentos. Por tanto, puede llevarnos a un fakeScrum, pero puede no ocurrir siempre. Si oyes esta frase, es importante estar atento.
“La Dirección tomó la decisión de Empoderar al Scrum Master y que también sea el Product Owner de las células”
En Scrum, es vital separar la responsabilidad del Scrum Master y del Product Owner. El Product Owner se centra en su producto, que entreguemos valor y que acertemos. El Scrum Master está pendiente del proceso y de que Scrum ayude a inspeccionar y adaptar para conseguir entregar. Muchas veces, se generarán debates entre los Developers (queremos más calidad) y el Product Owner (queremos más cantidad), por lo que se requiere mediación. El Scrum Master es una figura clave para trabajar los impedimentos de la organización y perdemos el foco si tenemos que estar encima del desarrollo del producto.
Más frases
Como dice mi compi Esther Estévez, el lenguaje crea realidades y ciertas frases nos dan pistas sobre la realidad de Scrum en una empresa (y, por tanto, de su capacidad de entregar producto).
¿Qué otras frases has oído en tu trabajo?
Doy las gracias por sus contribuciones a:
