Desmintiendo cinco mitos de Scrum

Muchas organizaciones adoptan un enfoque ágil por diferentes razones. Algunas esperan aumentar su productividad y reducir el tiempo necesario para lanzar sus productos al mercado (time-to-market). Otras esperan tener productos más exitosos. Incluso, otras adoptan Scrum para incrementar la colaboración entre los desarrolladores y las personas de negocio, incrementar la calidad o incrementar la satisfacción de los miembros del equipo de su trabajo.

Y, por supuesto, adoptar Scrum en la espera de llegar a obtener una combinación de estos beneficios.

Pero, así como podemos tener muchos beneficios al implementar Scrum, parecen haber tantas falacias. En este artículo me gustaría desmentir cinco mitos de Scrum.

Mito #1 ¿Es cierto que los administradores (managers) no tienen rol en Scrum?

Creo que este mito persiste porque muchos administradores (managers) usan mucho tiempo en hacer cosas que no deberían estar haciendo, independientemente de ser ágil o no.

Por ejemplo, los administradores (managers) muchas veces trabajan a un nivel suficientemente bajo como para poder asignar tareas a los individuos. Cuando ellos aprenden en Scrum que no deben de realizar este trabajo, sienten como que parte de sus atribuciones se les ha sido removido.

No – parte de sus atribuciones no se les han sido removidas. Cosas como asignar tareas nunca debieron ser parte de su trabajo.

Los administradores (managers) debieron estar enfocados en crear el ambiente y cultura que el equipo necesita para prosperar. Su tiempo no debería de estar consumido por minucias como quién debe hacer qué tarea.

Peter Drucker era uno de los líderes en la teoría de administración del siglo 20. Él es probablemente mejor conocido por la idea de la administración por objetivos (y creador del el acrónimo SMART) para fijar metas en las cuales estos son: Específicos, Medibles, Realistas y a un plazo de tiempo concreto. Drucker dijo que los administradores tienen cinco trabajos:

• Fijar Objetivos
• Organizar gente y trabajo
• Motivar y comunicar
• Medir
• Desarrollar personas

Seguro, en algunas organizaciones, algunas de estas responsabilidades pueden ser disminuidas. Pero otras –como desarrollar personas— se vuelven más importantes. 

En todos los años que llevo trabajando con Scrum y organizaciones ágiles, ninguna ha decidido despedir a todos los administradores. Si, algunos managers han sido movidos a roles de ScrumMaster y Product Owner, pero sigue habiendo trabajo de administración en Scrum.

Mito #2: ¿No pueden los interesados introducir cambios cuando ellos quieran?

Sin sorpresas, este mito de que los interesados pueden introducir cambios en cualquier momento es la creencia más común que los interesados suelen creer.

Los Developers entienden que introducir un cambio en el momento no adecuado viene acompañado de un costo.   

Consideren hacer el orden de una comida en un restaurante. Usted le dice al mesero que quiere el pollo. Después inmediatamente le dice “No, mejor deme el salmón”.

No hay un costo en este cambio.

Sin embargo, habrá un costo si cambia de opinión más tarde. Si usted le pide al mesero el cambio de orden de pollo a salmón una vez la cocina ya empezó a preparar el pollo, habrá un costo de desperdicio de comida (incluso, puede que el restaurante le cobre por esto).

El costo se hace más obvio si usted ya se comió la mitad del pollo antes de decirle al mesero que ahora prefiere ordenar el salmón. 

Un interesado introduciendo un cambio en una iteración es como cambiar de orden del pollo al salmón. Si el cambio es introducido a tiempo puede que haya poco o incluso ningún costo. Introducirlo en mal momento, sin embargo, tendrá un costo.

Siendo ágiles no podemos eliminar el costo de introducir cambios. No obstante, buenos equipos de Scrum pueden reducir estos costos sin importar cuándo estos cambios sean introducidos. Algunas formas comunes de hacer esto son:

• Iteraciones cortas
• Elementos del Product Backlogpequeños
• Terminar cada elemento del Product Backlog lo antes posible, usualmente minimizando el número de ítems que se trabaja concurrentemente.

Nada de esto significa que los equipos no deben aceptar cambios apropiados. Algunas peticiones de los interesados pueden ser muy importantes. Pero, el beneficio de hacer estos cambios necesita ser comparado con el costo de hacer el cambio, que no siempre es cero.

Mito #3: ¿Todos los miembros del equipo de Scrum deben de ser generalistas?

Por alguna razón, un mito muy popular en Scrum es que todos los miembros del equipo deben de ser capaces de hacer de todo. 

Este mito implica que si usted contrata al mejor administrador de bases de datos de Oracle, él debe de ser también un gran desarrollador de JavaScript. Y que su experto en JavaScript debe de ser eficiente en testing y seguridad por si no hay mucho trabajo de JavaScript en una iteración.

Esto es enteramente falso.

Los equipos de Scrum no necesitan que todos tengan todas las habilidades. En lugar de esto, lo que los equipos de Scrum necesitan es valorar individuos especialistas en diferentes disciplinas que poseen las habilidades necesarias.

Para entender la falacia de este mito, consideren un restaurante de lujo que funciona impecablemente. Después de ver muchos programas de televisión de cocina, he aprendido que este tipo de restaurantes deberían tener un chef pastelero. Este tiene habilidades para hacer pasteles, pan y otros postres horneados.  

Esto suena como un rol altamente especializado. Otro rol especializado en la cocina puede ser el chef de salsas, quien prepara salsas, estofados y otros ítems similares. 

En una cocina que funciona correctamente, el chef pastelero podría ayudar al chef de salsas a hacer alguna salsa, tal vez picando cebollas si hay alguna urgencia. Pero, ninguno de ellos (ni el chef de salsas, ni el chef pastelero) espera que sea totalmente capaz de hacer enteramente el trabajo del otro.

Actualmente en este mundo de tecnologías complejas, no es realista esperar un equipo con miembros que sean proficientes en todas las habilidades necesarias. En cambio, un buen equipo de Scrum aprende a valorar equipos multifuncionales (de individuos con habilidades específicas).

Tener algunos miembros con múltiples habilidades pueden ayudar a balancear el trabajo por hacer. Por ejemplo, el equipo puede necesitar tener más capacidad de testing en cierto momento. Tener uno o dos miembros que puedan apoyar a otros puede ser increíblemente útil.

Pero esto puede ser realizado en la mayoría de equipos, incluso si algunos miembros del equipo son especialistas en una sola disciplina.

Mito #4: He escuchado que los equipos de scrum no deben (o no pueden) planear.

La mayoría de buenos equipos de Scrum sí planean. Pero este plan es seguido menos visible que en proyectos tradicionales porque los equipos de Scrum no tienen una fase de planeación antes de comenzar a construir el producto.

En vez de esto, los buenos equipos de Scrum conducen la planeación como una serie de actividades recurrentes más pequeñas que aseguran que el plan siempre reflecte la realidad de la situación actual.

En esta forma, los equipos desarrollan planes del mismo modo que desarrollan productos: inspeccionando y adaptando. 

Para cualquier equipo de Scrum, sus planes no deberían proyectarse más adelante en el futuro que lo absolutamente necesario para tomar decisiones importantes. Pero la mayoría de organizaciones y equipos tienen un plan para aproximar lo que viene y cuándo viene.

De hecho, no obstante este mito, los equipos de Scrum tienen una forma más fácil de crear planes confiables porque los equipos de Scrum tienen información temprana de qué tan rápido están produciendo software. 

Considere un equipo tradicional con las fases de análisis, diseño, desarrollo de código y testing. Con suerte, el equipo puede retrasar el compromiso de un plan hasta el fin de la fase de diseño. Pero a este punto, el equipo no tiene idea de qué tan rápido son para desarrollar y testear – no han hecho estas actividades aún.

En contraste, un equipo de Scrum gira el volante del proceso entero de desarrollo cada iteración. Cada iteración incluye un poco de análisis, diseño, desarrollo y testing. Esto le da al equipo de Scrum más información de una forma más temprana de cómo pueden convertir las ideas en nuevas funcionalidades.

Mito #5: ¿Los equipos de Scrum crean productos sin un plan de arquitectura? 

Es hora de desmentir nuestro mito final: El mito de que los equipos de Scrum no arquitecturan ni diseñan sus productos.

Los equipos de Scrum definitivamente diseñan sus productos. Pero, en la misma forma en la que ellos planean de forma incremental, los equipos de Scrum hacen arquitectura y diseño incrementalmente. Esto permite que inspeccionen y adapten sus arquitecturas y diseños para así volverlas lo mejor posible.

Esto significa que no existe una fase previa durante la cual todas las decisiones de arquitectura estén hechas. En lugar de esto, la arquitectura de los productos van emergiendo con el tiempo.

Esto lo hacen los miembros del equipo técnico, enfocándose en todos los aspectos del producto que puedan considerar arriesgados. Por ejemplo, si ir entregando un producto con el ritmo necesario es desafiante, los Developers y el Product Owner pueden elegir trabajar en funcionalidades que reduzcan este riesgo.

De esta forma, la arquitectura emergente de un producto de Scrum es también intencional. La arquitectura no aparece simplemente un día. Va emergiendo gradualmente guiada por las intenciones de los miembros del equipo técnico.

Esto significa que los productos construidos con Scrum poseen una arquitectura subyacente. Pero las decisiones sobre la arquitectura son hechas conforme son necesitadas sobre el curso del proyecto más que hacerlas completamente en una fase al comienzo del proyecto.

Usted encontrará más mitos que estos. 

Mientras usted trabaje para introducir u optimizar Scrum en su organización, sin duda alguna encontrará otros mitos o creencias equivocadas que las personas tienen sobre Scrum. Esperamos que los mitos que desmentimos aquí le ayude a desmentir otros mitos sobre Scrum en su Organización.