El cambio suele generar miedo en las personas; es algo nuevo y, por lo tanto, no sabemos lo que está involucrado. Somos naturalmente escépticos de lo desconocido y, por supuesto, siempre existe la posibilidad de que no seamos muy buenos (o incluso peor, que nos veamos tontos intentando algo nuevo). Aunque un equipo puede entender algo tan simple y efectivo como Scrum rápidamente, todos los cambios asociados que surgen pueden causar varias preocupaciones. Hay algunos temas comunes que aparecen al adoptar Scrum en una organización, y varios otros detalles que inevitablemente van a a surgir en algún momento.
En este artículo vamos a compartir los temas más importantes para poder estar preparados o, quizás, no sentirnos tan mal cuando los experimentemos nosotros mismos.
Así no es como hacemos las cosas acá
"El cambio es como el Cielo: todos quieren llegar ahí, pero nadie quiere morirse" - Carly Fiorina
Carly Fiorina acompaña esta frase con una oración: cuando las personas piensan en el cambio, creen que todos los demás necesitan cambiar para parecerse un poquito más a ellos. Cuando Scrum se usa adecuadamente en una organización, se necesita que todos cambien la forma de trabajar.
Hay muchas oportunidades en los proyectos en cascada, y eso puede resultar atractivo. La buena noticia es que, desde la perspectiva del negocio, no interesa tanto lo que contribuye cada individuo sino más bien la efectividad del equipo.
El equipo estará naturalmente interesado en los aportes de cada individuo. Yo esperaba encontrar una tendencia estilo "Survivor", en donde los equipos van "descartando" a los miembros más débiles para que el equipo no se retrase. En cambio, estos 10 años de experiencia me soprendieron gratamente. La amplia mayoría de los equipos de Scrum que vi usaron un enfoque de apoyo para ayudar a los miembros más débiles del equipo, en vez de alejarlos. Por supuesto, si hay otras agendas presentes esto tendrá una influencia importante en el equipo.
Los "super-especialistas" suelen tener un miedo común: estos "desarrolladores héroes" suelen tener miedo de Scrum porque es mucho más importante que el equipo tenga éxito en vez del éxito individual. Los equipos Scrum se dan cuenta que los super-especialistas de cualquier disciplina incrementan el riesgo del proyecto y, a largo plazo, afectan la organización. En Scrum, preferimos entregar algo que el negocio y el cliente necesitan en vez de lo que las personas y capacidades nos permiten entregar.
Sin embargo, esto no significa que todos los miembros de un equipo Scrum son recursos homogeneos e intercambiables (una forma terrible de describir a las personas, por cierto); todo lo contrario. Queremos que las personas sigan sus pasiones y desarrollen sus intereses y capacidades; la diferencia es que queremos a especialistas más generalizados que nos permitan ser multidisciplinarios. Cuando las personas se dan cuenta de esto, la mayoría aprovecha la oportunidad para ampliar sus conocimientos.
El área de Recursos Humanos tiene que estar involucrado desde el principio, porque pueden asistir en re-estructurar políticas para apoyar mejor al cambio. Recursos Humanos también tiene que involucrarse en ayudar a los equipos durante el cambio, a superar el miedo y problemas de comunicación, feedback e interacción. A menudo las personas no recibieron capacitación en temas tan básicos como dar y recibir feedback o enfrentar conflictos - ambos son ingredientes esenciales para los equipos auto-gestionados de alto rendimiento.
Desde la perspectiva del Dueño del Producto, Scrum hace que tengan que tomar decisiones frecuentes y dificiles sobre las prioridades - ¿qué elementos del Backlog del Producto deberíamos hacer ahora y cuáles después?. En un proyecto tradicional estas decisiones pueden postergarse hasta muy tarde, ya que sólo tienen sentido cerca del final del proyecto. En Scrum, el Dueño del Producto tiene que tomar estas decisiones en cada Sprint, lo cual puede resultar atemorizante pero, en la práctica, hace que todo resulta más facil porque lo peor que puede ocurrir es tomar una mala decisión por un Sprint - ¡puede cambiarlo en dos semanas!
Por otro lado, son pocas las personas que tienen miedo de ser Scrum Masters, a pesar de ser un rol que combina mucha responsabilidad sin ninguna autoridad.
¿Y qué pasa con los líderes de proyecto?
Esta pregunta aparece una y otra vez - ¿cómo funciona Scrum sin un líder de proyecto? Alguien que se haga cargo, que mire al todo, que actué como enlace con el negocio. Es cierto que en Scrum no existe el rol del líder del proyecto; sin embargo, esto no significa que no exista la gestión del proyecto. Las responsabilidades tradicionales del líder de proyecto están repartidas entre los tres roles de Scrum (y alguna de estas responsabilidades dejan de ser necesarias). Las empresas manejan este tema de muchas formas distintas; en los extremos encontramos:
- Llamar "Scrum Master" a todos los líderes de proyecto.
- Despedir todos los líderes de proyecto.
No recomiendo ninguno de estos extremos. Por supuesto, muchos líderes de proyecto se convertirán en excelentes Scrum Masters, y también muchos serán malos Scrum Masters. Aquellos que no puedan abondonar la ilusión del control sobre el equipo no van a dejar que el equipo crezca y alcance todo su potencial. Sin embargo, aunque es probable que algunas personas renuncien a una organización con Scrum, los líderes de proyecto son valiosos en la mayoría de las organizaciones ya que son excelentes agentes de cambio y gestores de impedimentos. Incluso algunos pueden ser buenos Dueños de Producto. Aunque es comprensible, los líderes de proyecto no deberían tener miedo de Scrum. De hecho, cuando yo mismo cambié mi rol de Líder de Proyecto a Scrum Master, lo primero que sentí es que ya no me necesitaban. No era el caso, el equipo me necesitaba pero de una forma completamente distinta. Recomiendo ampliamente que cualquier líder de proyecto intente crear un equipo de Scrum auto-gestionado para aprender.
¿Y qué pasa con mi planificación?
"El miedo tiene una larga sombra, pero el miedo en si mismo es pequeño" - Ruth Gendler
Otra barrera que deben superar los equipos que hacen la transición a Ágil es la ausencia de un plan predecible en donde planificamos toda la incertidumbre del proyecto, trazamos un camino, determinamos la fecha de finalización, establecemos el costo y luego producimos esos lindos reportes a medida que avanzamos. Lo gracioso es que cuando pregunto "¿y esos planes terminan siendo correctos?" la respuesta es siempre negativa. Y sin embargo depositamos tanta fe en estos planes, porque sería muy atemorizante avanzar si un plan.
La buena noticias es que Scrum permite tener una idea sobre cuánto costará el proyecto y cuándo es probable que se termine. La única diferencia es que somos muy explícitos desde el inicio diciendo que esta predicción es incorrecta, y que la iremos mejorando a medida que avanzamos. Ocurre una agradable sensación de bienestar cuando nos empezamos a sentir cómodos con la incertidumbre. También podemos evitar los éxitos técnicos del pasado - un proyecto que "cumplió con los requerimientos" pero que no hace lo que necesitamos - porque, en vez de seguir ciegamente un plan pre-definido, adaptamos el proyecto a las condiciones cambiantes.
Los informes de avance son mucho más facil en un proyecto Scrum porque podemos ver, tangiblemente, lo que producimos en cada Sprint.
Pedir ayuda
Puede ser de ayuda contratar a alguien con experiencia, porque alguien que ya haya pasado por esta transición puede evitarnos cometer algunos errores costosos y además sirve para darle seguridad a los equipos - de pronto deja de ser tan atemorizante. Un buen coach se irá del lugar lo antes aposible, ni bien transmita su conocimiento y ayude a las personas a aprender de sus propios errores y experiencias. A veces existe el temor de no querer mostrar nuestros errores a otras personas (especialmente a alguien ajeno a la organización), pero la verdad es que sirve pedir ayuda. Además, es probable que el coach haya cometido los mismos errores que nosotros estamos cometiendo ahora.
Darse tiempo
Aunque no existe una ventana de tiempo definitiva para adoptar Scrum y depende del tamaño de la organización, es probable que lleve varios años (de en serio... ¡años!). Hay que prepararse a darnos tiempo. Se necesita dedicación para adoptar un cambio tan prolongado en el tiempo, ya que es facil perder la iniciativa y el entusiasmo. Hay que celebrar los pequeños triunfos y ponernos nuevos desafíos, indicando explícitamente los beneficios de superarlos. Esta es la mejor forma de ir avanzando.
A la vez debemos ir planificando un sucesor. La gerencia que inicialmente fue sponsor del cambio a Scrum seguramente no estará más o tenga un rol distinto en algún momento, por lo que nos servirá planificar la sucesión antes de que sea necesaria (y evitar así perder el impulso).
Resumen
"La clave del cambio es abandonar al miedo" - Rosanne Cash
Scrum es un cambio masivo para todo el equipo y, eventualmente, para la organización. Todos los cambios ocasionan miedos; reconocer y discutir estos miedos es un importante primer paso para mitigarlos y quitarlos. A veces un coach nos puede guiar en la transición. La única forma de poder hacer que alguien cambie es explicándole cómo se verá beneficiada; las buenas noticias son que Scrum tiene beneficios para todos, y está bien tomarse tiempo en recorrer este camino.
