5 preguntas para la implementación de Scrum
Las organizaciones no se vuelven ágiles de la noche a la mañana por arte de magia. Es un proceso de transformación significativo en el que cada persona debe revisar y adaptar su rol. Y todo comienza con que la alta dirección debe responder algunas preguntas bastante complicadas.
Debido a los desafíos que enfrentan las organizaciones modernas, Agile resulta extremadamente tentador. ¿Quién no querría tener releases más frecuentes? ¿Quién no querría adaptarse mejor a un entorno empresarial en constante cambio? Sin embargo, demasiados directivos consideran Scrum y comienzan una transformación ágil sin comprender las implicaciones que Scrum puede tener en su organización, su carrera y sus objetivos.
Scrum no es algo que deba implementarse a la ligera en una organización, y los directivos deberían hacerse algunas preguntas complicadas. Scrum no es solo asunto de los equipos de desarrollo. No puede limitarse a un solo equipo. La implementación de Scrum representa un cambio sistémico en una organización y se describe regularmente como difícil y disruptivo. Pero, ¿qué significa eso realmente? ¿Cuáles son las posibles implicaciones de Scrum?
Aquí hay cinco preguntas que deberían responderse para prepararse para una implementación exitosa y productiva de Scrum.
1) ¿Cómo reacciono ante cambios que afectan a mi rol?
Esta pregunta debe ser respondida por todas las personas de una organización y no solo por los equipos que van a trabajar con Scrum. Scrum tiene el impacto más directo en los equipos, pero no se detiene ahí. ¿Qué pasa con los supervisores? ¿Y cómo reaccionarás cuando tu rol de liderazgo se vea afectado?
Ejemplo: Scrum y el management intermedio
Estaba desayunando con mi amigo John (nombre cambiado). John era gerente de desarrollo en una gran empresa de servicios financieros, donde se había implementado Scrum en los últimos años.
Estaba preocupado por cómo se percibía su rol en la empresa. Le pregunté por qué estaba preocupado, y respondió: „al principio todo iba bien. Los equipos progresaron rápidamente y un entorno de trabajo basado en equipos es mejor para las personas que un modelo de servicios compartidos. Pero ahora tenemos equipos que resuelven la mayoría de sus problemas por sí mismos y supervisan su propio rendimiento.”
Quería saber cuál era su rol en este nuevo entorno autoorganizado.
La función de los mandos intermedios en empresas basadas en el modelo de „Scientific Management” (Taylorismo) se centra principalmente en el rendimiento y la eficiencia de los empleados. Al Taylorismo se le atribuye gran parte del aumento de productividad del siglo XX. Sin embargo, es menos adecuado para la creación de productos modernos basados en el conocimiento.
¿Cómo cambia entonces el rol del management intermedio con la implementación de Scrum?
Después de una breve discusión, John decidió que podía contribuir actuando como mentor y comunicador para sus equipos, mostrándoles lo que se necesita desde el lado empresarial y demostrando a la empresa que sus equipos pueden satisfacer esas necesidades.
2) ¿Cómo gestionas a tus mejores empleados si no quieren unirse a este viaje?
No todo el mundo quiere trabajar con Scrum. A muchas personas les gusta Scrum porque les permite crear un producto en el que tienen influencia directa, y eso puede sentirse muy bien. Pero no todos se sentirán así.
Ejemplo: La estrella enfadada
Jack era la estrella de su equipo y se aseguraba de que todos lo supieran. Cuando el equipo se acercaba a una fecha límite, Jack a menudo trabajaba 80 horas por semana para que el equipo alcanzara su objetivo. A menudo estaba en la oficina hasta las 22:00 e incluso enviaba correos electrónicos a la dirección los fines de semana. ¡La dirección lo adoraba!
Sin embargo, la calidad de su trabajo era cuestionable. Producía mucho código que no funcionaba y requería una revisión considerable. Después de otra noche en vela en la oficina, los demás miembros del equipo pasaban días depurando e integrando su código.
Intentaron explicarle a Jack que su comportamiento afectaba a todo el equipo, pero él no quería escuchar y dijo: „aclaradlo con la dirección”.
La situación cambió cuando se implementó Scrum en ese equipo. El progreso y la transparencia en el equipo se discutían cada día durante el Daily Scrum – el progreso diario era medido permanentemente por el equipo. Gracias a que el equipo podía decidir por sí mismo cuánto trabajo completarían en una iteración, pudieron trabajar a un ritmo más sostenible durante todo el proyecto.
Durante una retrospectiva, el equipo cuestionó la creación de código no completamente probado que le costaba tiempo a todo el equipo.
Jack no tomó bien la implementación de Scrum. La buena transparencia en el Daily Scrum dejó muy claro que Jack no entregaba código regularmente, sino que posponía el trabajo hasta el último día del Sprint. Cuando el equipo ofreció sugerencias para resolver el problema, Jack se quejó de micromanagement.
No podía trabajar a un ritmo constante y sostenible, y en lugar de enfocarse en el mayor valor para el cliente, se quejaba de que su trabajo era „aburrido” o „sin desafío”.
Cuando el equipo se comprometió durante una Retrospectiva a mejorar la calidad del código mediante pruebas regulares, Jack amenazó con dejar el equipo e incluso la empresa. Cinco Sprints después de la implementación de Scrum, Jack dejó la empresa voluntariamente. El rendimiento del equipo mejoró constantemente y tres años después seguían produciendo un producto de alta calidad.
Al implementar Agile, las empresas deben considerar qué sucederá si sus mejores empleados no quieren trabajar en un equipo Scrum. ¿Los dejarías ir? ¿O deberían quedarse en la empresa y posiblemente perturbar a otros equipos Scrum? Si estás dispuesto a dejarlos ir, ¿cómo justificas esa decisión?
3) ¿Qué mecanismos utilizarás para provocar cambios de comportamiento?
Scrum requiere cambios de comportamiento; esto incluye autoorganización, mayor colaboración y transparencia. Cambiar comportamientos es extremadamente difícil, especialmente para empleados veteranos que han sido entrenados para comportarse de cierta manera. Ahora que se requiere un cambio, ¿cómo te aseguras de que realmente ocurra?
La formación continua juega aquí un papel importante.
Como líder en la dirección, puedes apoyar a los empleados con formación, coaching y conferencias y ayudarles a comprender y aplicar los métodos modernos de desarrollo de software. Y al mostrar compromiso con los empleados, la moral y la satisfacción tanto de los empleados como de la empresa pueden mejorar.
Una parte esencial de este cambio de comportamiento tiene que ver con la confianza en el equipo. Si trabajo con alguien y esa persona entiende mi trabajo, ¿es eso un riesgo para mi evaluación de rendimiento? ¿Es un riesgo para mi puesto? ¿Cómo se construye confianza si alguna de estas dos preguntas puede responderse con „sí”?
Un enfoque común es cambiar las responsabilidades y los indicadores por los que se evalúa a los empleados. Para fomentar el comportamiento cooperativo, se da más peso al trabajo en equipo que al rendimiento individual. Esto puede hacerse con feedback basado en equipo o feedback 360°.
Dar menos valor al rendimiento individual cuestiona las responsabilidades individuales. Nadie quiere ser responsable de un área específica si se le evalúa por el rendimiento de todo el equipo. Por eso, los miembros de los equipos Scrum naturalmente deben recibir responsabilidad sobre diferentes áreas. Esto significa que deberían entregar una parte de un producto potencialmente entregable en cada Sprint.
Esto puede parecer insignificante, pero tiene grandes implicaciones en cómo opera una empresa. ¿Cómo afecta a tu estructura organizacional si los equipos son responsables de trabajar en múltiples áreas temáticas diferentes?
4) ¿Qué pensará el departamento de soporte sobre los cambios provocados por Scrum?
Scrum se implementa en la mayoría de los casos a través de equipos de desarrollo de software. Rara vez se piensa de antemano en los equipos de soporte y arquitectura. Esto se debe a que muchas organizaciones asumen que „Scrum es algo que hacen los desarrolladores”.
Pero la realidad es que Scrum definitivamente también afecta a otros equipos. ¿Cómo reaccionarán los equipos de soporte, por ejemplo, cuando haya fricciones con los equipos Scrum? ¿Cómo se resolverán estos problemas?
Ejemplo: Desacuerdos entre diferentes departamentos
Sarah era una arquitecta líder de Java Messaging Service (JMS) y responsable de la visión corporativa de un Enterprise Service Bus (ESB). Se sentía cada vez más frustrada porque los equipos Scrum „igoraban las directrices de la empresa al saltarse el ESB o añadir nuevas funcionalidades que no estaban alineadas con la estrategia empresarial”.
Cuando le preguntaron por qué los equipos se comportaban así, dijo que los equipos necesitaban más disciplina y mejor formación sobre la estrategia ESB. Y luego añadió: „quizás no estamos cubriendo sus necesidades”.
Después de una mayor deliberación, Sarah decidió que lo mejor sería unirse a un equipo Scrum para comprender sus desafíos y ayudarles a entender mejor los objetivos empresariales.
5) ¿Cuánto está dispuesta la empresa a invertir en esta transformación? ¿Y qué valor se obtiene por ese esfuerzo?
Pocas empresas tienen de antemano una idea clara de cuánto van a ganar aproximadamente con Agile. Hay poca información sobre cuántos ingresos se pueden esperar. Sin embargo, hay evidencia constante de que con Scrum se pueden lograr releases más frecuentes, mejor calidad de producto y contacto más directo con los clientes.
Una buena solución para esto es un presupuesto anual fijo para formación y coaching permanente de los empleados. Sin embargo, esto se vuelve problemático cuando la implementación de Scrum avanza más rápido de lo que el presupuesto permite. También es difícil de justificar cuando no se puede decir claramente cuántos ingresos genera.
Una solución mejor sería medir algunos indicadores clave, como por ejemplo:
- Ingresos por empleado
- Satisfacción del cliente
- Satisfacción de los empleados
Si los directivos observan si estos indicadores mejoran con Scrum, pueden ver cuán efectiva es la implementación de Scrum y si hay que cambiar algo.
Hay, sin embargo, algunas cosas interesantes en este enfoque que vale la pena destacar:
Primero, este método es independiente del framework utilizado y podría medir también el rendimiento de una empresa que no trabaja con Agile. Segundo, podrías descubrir que Scrum no es el mejor enfoque para tu empresa o que hay frameworks más efectivos que Scrum. Eso ocurre raramente, pero naturalmente es posible.
Precisamente este enfoque de medición ha sido recogido recientemente por Ken Schwaber en su „Evidence-Based Management” (gestión basada en evidencia). Aún es demasiado pronto para decir qué impacto tendrá este enfoque en el desarrollo de software, pero es una solución muy interesante y tiene el potencial de proporcionar a las empresas evidencia concreta de su mejora.
La conclusión
Implementar Scrum no es algo que deba hacerse a la ligera. Existe un riesgo tanto para la organización como para las personas individuales. Cuando comprendes las preguntas que la gente hace, podrás entender mejor sus motivaciones, miedos y dudas. Y con ese conocimiento puedes formar un enfoque mucho más integral que atienda las necesidades de la empresa y de los empleados.
„La capacidad de pensar lógicamente es una de las cosas que nos define como seres humanos. En un mundo de información omnipresente y herramientas de análisis sofisticadas, la lógica por sí sola no es suficiente. Lo que destacará a las personas exitosas es su capacidad para ponerse en el lugar de los demás, construir relaciones y preocuparse por otros.”
– Daniel H. Pink, autor bestseller de Drive
(Nota: Este es un artículo invitado de Kane Mar, Scrum Trainer y Coach, fundador de Scrumology.com y Scrum101.com.) Este texto proviene del blog de Openview y fue traducido por nosotros al alemán.
