5 falsas esperanzas de Scrum y cómo solucionarlas

Publicado: 2022-03-11

Al igual que muchos conflictos clásicos e interminables, el debate sobre cómo los equipos de desarrollo deben organizarse y autogobernarse continúa. Actualmente, casi parece que hay más críticos que fanáticos de Scrum. Las tres quejas más comunes son:

  1. El proceso puede ocupar un lugar central sobre el trabajo.
  2. Puede confundirse fácilmente con la microgestión con otro nombre.
  3. El stand-up diario puede sentirse como una reunión donde uno tiene que justificar su existencia.

En otros casos, los roles de Scrum no están representados adecuadamente. A veces, el propietario del producto quiere demasiadas cosas dentro de un sprint o quiere cambiar las prioridades a mitad del sprint: un maestro de Scrum que se enfoca obsesivamente en mantener la velocidad y adoptar cada nueva ceremonia de Scrum que aprende. Después de un tiempo con el marco, parece surgir una pregunta común: "¿Somos nosotros o la metodología?"

Las falsas esperanzas de Scrum

Si bien existen numerosas disfunciones como las descritas anteriormente, una causa raíz simple para la mayoría de ellas es que Scrum no fue diseñado para resolver problemas subyacentes dentro de una organización simplemente siguiendo el proceso. No reconocer esto puede poner en peligro a los nuevos equipos casi tan pronto como comiencen.

Falsa esperanza #1: Scrum hace que los equipos trabajen más rápido

Scrum está asociado con la velocidad

Scrum utiliza una terminología que a un extraño le suena como si fuera a acelerar el proceso sin agregar recursos adicionales. Es fácil atascarse en la terminología como un nuevo equipo de Scrum (p. ej., ¿qué es un maestro de Scrum? ¿Cuál es la diferencia entre un propietario de producto y un gerente de producto? ¿Qué son los puntos de la historia y cómo se asignan?)

Más preocupante es que muchos ven términos como velocidad y sprints y piensan en "velocidad". Sin embargo, el propósito de cualquier metodología Agile, incluido Scrum, es entregar un producto terminado. Eventualmente, a medida que su equipo se vuelva más competente con Scrum, podrá entregar nuevas funciones más rápido. Sin embargo, la velocidad no es necesariamente el objetivo principal. Esta distinción debe ser articulada dentro de su equipo Scrum y también cuando esté creando conciencia dentro de su empresa para apoyar la metodología Scrum.

No estás vendiendo velocidad; usted está vendiendo terminación.

Falsa esperanza n.º 2: la adherencia estricta a Scrum solucionará los problemas de cultura de la empresa

Todo el mundo tiene diferentes estilos de trabajo. A algunas personas les gustan las reuniones. Otros usan frases como “trabaja duro, juega duro”. Es esencial reconocer que cualquiera que sea el estilo de trabajo que valore su empresa, usted acepta tanto sus ventajas como sus desventajas. Es probable que una empresa que valora las reuniones tenga problemas con las reuniones diarias. Los equipos agresivos y orientados a la velocidad van a tener problemas con el avance del alcance dentro de un sprint.

A veces es fácil perder de vista el panorama general, especialmente en los equipos recién formados. Lo que importa es entregar un producto terminado en lugar de seguir hasta el último bit del proceso. En lugar de culpar a la metodología, busque siempre formas de refinar su estilo de trabajo para alcanzar sus objetivos.

Falsa esperanza n.º 3: los colaboradores críticos pueden enviar a sus delegados a las reuniones

Una vez que comience la metodología, es crucial que el equipo original participe en lugar de delegar. Si hay una queja casi universal que veo de los desarrolladores, es que los maestros de Scrum y los propietarios de productos no estaban disponibles cuando se necesitaban y sus delegados no estaban autorizados. A nadie le gusta llegar a una reunión esperando una decisión y luego que le digan que la persona que puede tomar la decisión no está disponible.

La delegación puede ser una práctica común, pero en Scrum, también debe empoderar a los participantes.

Falsa esperanza n.º 4: las reuniones diarias obligarán a todos a concentrarse más

La reunión diaria de pie no debe centrarse únicamente en lo que todos hicieron en las últimas 24 horas. Es mucho más importante dar prioridad a la aparición de obstáculos o nuevos enfoques para resolver un problema.

Scrum requiere que ciertos roles, particularmente el maestro de Scrum, sean asertivos pero no abrumadores. Es importante que el Scrum Master cree un ambiente positivo que conduzca a productos completos.

Falsa esperanza #5: Tendremos éxito en el primer intento

Adoptar Scrum podría no tener éxito en el primer intento

Scrum implica conjeturas, pensamiento deductivo y cometer errores. La gente rara vez lo hace bien en el primer intento. Scrum es iterativo en todos los aspectos: no solo en cómo llega a un producto terminado, sino también en cómo gobierna y opera el proceso. Scrum está diseñado para tener una barrera de entrada baja para que los equipos lo adopten, pero también requiere un compromiso para iterar y mejorar continuamente la participación en el marco.

Cómo arreglar un proceso Scrum roto

Scrum es resistente a la falacia del costo irrecuperable. La naturaleza iterativa de Scrum crea oportunidades para adaptar o descartar procesos ineficaces. Considere algunas de las siguientes sugerencias si su proceso Scrum no es tan efectivo como esperaba.

Refina tus expectativas

Ya sea reduciendo el tiempo de comercialización, creando productos atractivos o ayudando a los equipos a colaborar, el éxito requiere compromiso y tiempo. Para los nuevos equipos, un hito razonable a alcanzar es si después de cada sprint podría introducir código funcional y comprobable en su entorno de producción.

Los equipos avanzados pueden medir el éxito por su capacidad para crear, probar e implementar según demanda. ¿Es capaz de instrumentar y cuantificar las reacciones de los usuarios a las nuevas características? ¿La organización en general está lista para respaldar los cambios que el equipo está realizando en el producto?

Empodere a sus participantes

Es importante asesorar a los miembros del equipo fuera de línea en términos de cómo pueden aumentar su valor para el equipo. Si se les pide que tomen decisiones, aumente su confianza indicándoles cuándo y cómo incluir a otros miembros del equipo. Los gerentes deben estar listos para eliminar los obstáculos y apoyar al equipo cuando sea necesario.

Abordar los problemas de manera proactiva

Scrum no está diseñado para darle un cambio de imagen a su empresa. Si ha dejado que los problemas no se resuelvan, es muy probable que encuentre estos problemas en el proceso de desarrollo de su producto. Los Scrum Masters pueden introducir marcos diseñados para crear una forma positiva para que los miembros del equipo estructuren sus comentarios para reducir la sensación de conflicto.

Marco de entrega de comentarios de Scrum

Un ejemplo de ello es el marco "Deseo, me pregunto, ¿qué pasaría si?". Durante las discusiones del equipo o las retrospectivas, un miembro del equipo puede dar su opinión abriendo su declaración con una de estas tres frases. Por ejemplo, podrían decir: "Me gustaría que las reuniones de pie se enfocaran más en los obstáculos que podría necesitar tener en cuenta ese día". También puede usar su propio abridor como "Me gusta...".

Otra solución de retroalimentación estructurada que puede ser útil durante las reuniones es el método Triage de Holocracy, creado por Brian Robertson y utilizado por empresas como Zappos. Por ejemplo, los participantes construyen una agenda de “tensiones” para discutir. Cada participante describe su problema diciendo “Tengo tensión” y luego enumera las personas y los recursos que necesita para resolverlo. Al alentar a los participantes a abordar directamente los problemas como "tensiones", la Holocracia les permite comunicarse libremente sin crear una atmósfera de conflicto.

Método de triaje de la Holocracia

Use retrospectivas para resolver problemas e iterar en el proceso

En muchas empresas no se presta la debida atención a la retrospectiva. Esto se debe principalmente al temor que muchos tienen de que la retrospectiva sea un lugar para viejas discusiones, conflictos y agravios. Es vital que el equipo desarrolle reglas básicas que reflejen los valores del equipo y la cultura de la empresa.

Las retrospectivas son importantes en Scrum

Igual de importante es la necesidad de evitar invertir en procesos estáticos. Lo que funcionó una vez puede no funcionar para siempre. Muchos equipos luchan con la rotación de participantes. Esto es común en muchas empresas, ya que los participantes son reasignados a otros equipos, son ascendidos o abandonan la empresa por completo. A medida que evoluciona la composición del equipo, es importante no seguir confiando en que todo es iterativo en Scrum. Se producirán errores, pero es de esperar que sean de corta duración a medida que itera.

Scrum funciona mejor cuando los directores están presentes

Al estar en el equipo, tienes que comprometerte a estar presente y disponible. El desarrollo de productos es probablemente el proceso más crucial que su empresa podría emprender para mejorar su crecimiento a largo plazo. Por lo tanto, es importante que el proceso Scrum, como vía principal para el desarrollo de nuevos productos, reciba la atención que merece. En muchos entornos, el equipo de desarrolladores a menudo trabaja separado de las decisiones y debates que impulsan los objetivos de la empresa. Scrum es diferente. Scrum es donde las decisiones, la dirección y el desarrollo se unen como un solo proceso. Es un proceso demasiado importante para enviar delegados o dejar fuera a los miembros del equipo de las reuniones que se llevan a cabo dentro de la metodología Scrum.

Resumen: puede arreglar un proceso de Scrum roto

Debido a su naturaleza iterativa, Scrum ayuda a proteger a la empresa para que no avance demasiado en el camino y se comprometa con lo que puede terminar siendo una mala idea o un proceso mal implementado. Cumplir con este principio puede ayudar a deshacerse de los errores del pasado y mejorar iterativamente el proceso Scrum.

Es importante centrarse en las personas y el equipo que tiene. Los miembros del equipo cambian. Todos los proyectos son diferentes. La adherencia estricta a un proceso no siempre produce los mejores resultados. Lo que invierte en los miembros de su equipo fuera del proceso es tan importante como la forma en que se comporta dentro del proceso.

Scrum puede ser flexible. Si algo no funciona, considere incorporar elementos de otros marcos tanto dentro como fuera de Agile. Identificar y adoptar estilos estructurados de comunicación que discutan confrontacionalmente.

Scrum es beneficioso para el ROI a largo plazo al permitir que los equipos construyan productos completos en respuesta a las necesidades cambiantes de los clientes. Scrum es probablemente la mejor metodología para evitar que se comprometa demasiado con las malas ideas mientras le da a las grandes ideas un espacio para desarrollarse más.