31. jul., 2017

Los problemas e impedimentos comunes en la implementación de SCRUM en las Organizaciones Colombianas

En el mes de Junio estuve participando como asistente a una capacitación de Agile Team Facilitator-ATF organizada por la compañía Kleer en la ciudad de Medellín. En este espacio de capacitación surgió en algún momento  la revelación de los principales problemas que tienen las organizaciones a nivel colombiano (e incluso había conmigo participantes de otros países como Bolivia, Panamá y Perú) y a los que se enfrentan los Scrum Másters en la implementación de SCRUM.

Quiero en este breve escrito discutirlos con ustedes y resumir bajo mi experiencia en este Marco de Trabajo ágil cuales de estos problemas he evidenciado con la intención de que sean de su conocimiento para que no les pase lo mismo en sus equipos y en sus empresas.

En PMPMedellin listaremos a continuación los principales problemas e impedimentos que se tiene la implementar SCRUM:

1. Falta de apoyo de la alta gerencia: Cuando se tiende a implementar SCRUM solo por moda y no porque realmente estemos convencidos que la organización lo necesita y obtendrá beneficios con ello. Se menosprecia su implementación y sus ceremonias y roles.

Otro error común relacionado es que inicie su implementación solo en las áreas de TI y no en toda la organización como debería ser. Aquí tenemos que entonces la alta gerencia pierde de vista sus bondades y la razón de porque se tomó la decisión para traerlo a la organización. En este caso se aconseja dar a conocer a la alta gerencia ¿ Qué es SCRUM? e identificar cuales son los beneficios de su implementación y que ROI se puede obtener con  su implementación en la organización. Una vez la alta dirección se capacita sobre estos temas y recibe la información de los resultados que ha tenido Scrum en otras empresas entonces el apoyo se garantiza y esto permite mayor permeabilidad al resto de áreas. 

2. Problemas de Comunicación en el equipo: En este punto podemos decir que todos los proyectos en su mayoría sean ágiles o no padecen de este mal. En los equipos siempre hay personas con deficiente comunicación, o que no emplean métodos para llevar la misma hacia los niveles exigidos (Alto y Bajo). Entonces se hace evidente que no hay planes de comunicación en los proyectos que permitan identificar las estratégias para comunicar avances, riesgos y problemas /impedimentos que surjen en el proyecto. Si a esto le sumamos además el hecho de que tengas conviviendo a personas de diversas generaciones en la oficina - algunos autores hablan de poner a trabajar a abuelo, papá e hijo en el mismo espacio y en el mismo equipo. Esto hace que en los equipos ágiles desencadene problemas de comunicación porque cada uno tiene una manera diferente de ver el mundo e interactuar en grupos. Para resolver el problema el Scrum Máster deberá proponer canales de comunicación y definir un plan de comunicaciones así como se hace en la gerencia de proyectos tradicional de cara a cubrir las brechas comunicacionales que se tengan en el equipo y tratar los problemas de comunicación en las retrospectivas y seguimientos uno a uno.

3. Problemas de Planeación en el equipo: En la metodología tradicional las personas muchas veces no saben estimar o lo hacen sin método y en ocasiones con criterios débiles. En SCRUM la situación no es muy diferente quiero contarte que hay personas en el equipo que se comprometen a realizar "la Ceca y la Meca" y a la hora de la verdad no realizan nada de lo que se comprometen dejando en las historias de usuario comprometidas - Deuda técnica para los Sprints siguientes. Entonces podemos decir que uno de los problemas que se tiene es Mucho Work in Process y estimación de historias de usuario de gran tamaño. Por ello aquí también aplica la consigna: ¿ Cómo es mejor comerse un elefante? ....Por partes... Entonces es mejor efectuar una buena desagregación de las historias de usuario junto con los PBIs (Product Backlog Items) y tareas de manera que usted solo tenga tareas que pueda realizar en un día máximo (8 horas). Otro problema común en este aspecto es que el equipo realiza estimación de tareas que se comunican de forma aislada y el trabajo en silos solo genera reprocesos posteriores por problemas de integración. En los equipos maduros se empieza algo y no empieza lo siguiente hasta que no lo terminan, manteniendo una o dos tareas en paralelo al mismo tiempo como buena práctica. Así se evita que cuando llega el final del Sprint, la mayoría de las cosas están a medio acabar y no da tiempo a integrar con un riesgo adicional y es que el Product Owner apriete para mostrar cuanto más mejor en el Sprint Review y el equipo de desarrollo añada dicha “deuda técnica” al backlog, para revisitarla en el próximo Sprint y a veces en algunos equipos nunca se vuelve a retomar generando el efecto bomba de tiempo para el proyecto.

Otro error que encontramos en la planeación es la Falta de Sprint Goal- Este error consiste en que el Sprint Backlog se convierte en un cajón de sastre en el que entran decenas de cosas que no tienen nada que ver las unas con las otras. Esto hace que no haya coherencia en lo que va realizando el equipo y de esta manera se pierde el desarrollo iterativo e incremental y la transparencia. Podemos decir que el Sprint Goal es una dirección general que ayuda al equipo a mantener el foco y trabajar en incrementos de producto aportando a dicha meta del Sprint. Mientras que el Sprint Backlog puede cambiar, el Sprint Goal NO- Eso permite flexibilidad para lidiar con cosas que no estaban planeadas y un mejor enfoque en las necesidades de negocio. Hay otra situación peor que se presenta y es que no tengamos un Sprint Goal que dé dirección. Aquí perdemos una herramienta muy potente que promueve dos de los valores de Scrum: el Coraje y el Compromiso. Entonces Scrum se convierte en un proceso más dentro de la compañía, además de perder foco en el valor de negocio entregado en cada incremento.

4. Problemas en la asignación de tareas: Aunque suene paradójico dado que los equipos ágiles se autogestionan y definen sus compromisos. Ocurre que los miembros del equipo de desarrollo trabajan individualmente en tareas hasta que las completan y luego pasan a trabajar en otra cosa. Eso provoca, de nuevo, falta de integración y posibles problemas de dependencias en los desarrollos. Algunos equipos tienen normas para lidiar con esto. Por ejemplo, definen un code review por al menos dos miembros del equipo, el trabajo y revisión por pares pero esto no siempre tiene la efectividad esperada sobre todo si la carga de trabajo es alta. Entonces la única solución al tema es reducir la carga de trabajo - el ahorro de entregar más rápido se traduce en cuatro veces más para reparar la deuda técnica y de conocimiento que supone ese ahorro. Además, cuando se maximiza la utilización, se tiende a perder valor. Y te preguntarás ¿Cómo? Púes aumentando el tiempo de entrega. Cuando el equipo se enfoca en entregar unas cuantas cosas bien hechas, quizás esté perdiendo eficiencia, pero se asegura de entregar, lo cual ya supone una gran diferencia con muchos equipos, que trabajan en cosas durante meses sin llegar a entregarlas jamás.

5. Falta de responsabilidad: Tenemos que en Scrum, el rol responsable de dar cuentas sobre el incremento de producto es el equipo de desarrollo. Sin embargo, es importante tener claro que el nombre no nos puede engañar. En Scrum todos los miembros del equipo de desarrollo dan cuentas sobre todo el incremento y no existe la individualidad del desarrollador. Esto hace que desafortunadamente muchos miembros del equipo de desarrollo se quejen porque ellos sí hacen su trabajo. Aquí es importante destacar la ética de los miembros del equipo por un lado y por otro revelar que el Scrum Master no debe actuar sobre los miembros que consideramos destacados o vagos, sino mantener la discusión dentro del equipo y no escalarlo en la organización sino permitir al equipo que resuelva la situación y facilitarles espacios y actividades para ello. En el caso del Product Owner, él es el responsable de dar cuentas de la inversión que hace en el equipo de desarrollo cada Sprint y tiene que hacerlo con datos. Si la calidad técnica del producto falla, de rebote el Product Owner se convierte en responsable. Entonces la responsabilidad en últimas esta atada a la madurez de las personas... como siempre digo para alcanzar el éxito en Scrum debemos comprender que el tema es Humano.

6. Adoptar la creencia de que el equipo de desarrollo es el equipo de desarrolladores: Aunque suene raro muchas personas creen que un equipo de desarrollo tiene que estar formado por gente técnica: programadores, ingenieros de operaciones o calidad. Nada más lejos de la realidad. El equipo de desarrollo tiene todos los perfiles necesarios para poder entregar un incremento de producto. Si eso supone que tienen que incorporar a un Business Analyst, un arquitecto de TI, un tester, un experto en UX, un experto en seguridad informática, un especialista en SEO o un diseñador,entre otros...Ellos también son miembros del equipo de desarrollo.

7. Maximización de utilización o eficiencia: Este es uno de los peores errores que puede tener una organización. Enfocarse en que la gente trabaje muchas horas en lugar de generar valor. Debemos tener claro que estos dos objetivos son totalmente incompatibles. El desarrollo de software, por su propia naturaleza, incurre en una variabilidad muy grande y no es posible estandarizar tareas, duraciones, problemas o buenas prácticas. La realidad es que cada vez que hacemos algo en software, por muchas veces que creamos haberlo hecho antes, nos enfrentamos a algo totalmente nuevo: un entorno nuevo, un sistema nuevo, que nunca habíamos hecho antes. Es ineficiente porque aprendemos sobre la marcha. Las ineficiencias aparecen en forma de miembros que no tienen suficiente trabajo, otros que están sobrecargados y otros problemas intermedios. El temor a que la gente esté parada lleva a introducir trabajo no necesario para generar valor y que la gente esté ocupada. Entonces ocurre también un efecto fantasma como resultado - cuando el trabajo que tienen que hacer esos miembros es necesario, están ocupados haciendo otras tareas y en muchos casos están siendo ineficientes y haciendo perder dinero a la compañía porque las tareas pueden que tengan menos valor.

8. Retrospectivas que no prosperan: Este es uno de los dolores de cabeza que vemos de manera recurrente en el trabajo de los Scrum Másters - Tienen equipos que realizan sus ceremonias de forma periódica pero a la hora de hacer planes de acción para mejorar sus debilidades no los llevan a la acción. Y peor aún se hacen los de la "vista gorda" cuando son llamados a rendir cuentas. Esto pasa porque los Scrum Másters deben llevar a cabo tareas de Coaching y reuniones 1 a 1 y en muchos casos no se hacen. La ceremonia de Retrospectiva me atrevería a decir que son las más importantes porque permiten al equipo ser transparentes con los problemas del equipo, inspeccionar y adaptar cambios para mejorar. Pero en ellas muchos equipos tienden a centrarse más en los aspectos participativos de las mismas en lugar de resolver los problemas de raíz.

Puede decirse que las causas de porque las retrospectivas no prosperan son diversas y podríamos mencionar algunos aspectos para que tú como Scrum Máster no caigas en esta bola de nieve sin fin:

1) Hacer demasiada facilitación: No es que la facilitación sea mala. Lo malo es que las retrospectivas sean un espacio solo de juego y diversión y se evite hablar de los temas que preocupan al equipo o que le permitan resolver conflictos o impedimentos a nivel personal. Las retrospectivas más poderosas son aquellas donde los participantes entienden perfectamente cual es el objetivo y avanzan hacia él- aquí es importante entender- que las dinámicas son medios y no fines para conseguirlo.

2) El Scrum Master no participa: Dada la abundancia de herramientas (tecnológicas y no tecnológicas) y de información en los equipos esto ha hecho que muchos equipos se alejen del verdadero motivo de las retrospectivas para centrarse en las dinámicas. Sorprendentemente encontramos además muchos Scrum Masters que no participan en las retrospectivas, a pesar de que se quejan de que Scrum no funciona en su organización - Esto constituye una paradoja interesante.

Scrum propone que el Scrum Master tiene que actuar como facilitador del resto del equipo Scrum en la retrospectiva y eso lo coloca en una posición de dominación de la situación que exime de responsabilidad al resto de los miembros del equipo. El Scrum Master debe participar en la retrospectiva como uno más del equipo y no quedarse en la seguridad que le da el ser el que sabe del marco de trabajo  Scrum y el que organiza la actividad.

3) La presencia de externos en la retrospectiva: Ocurre también que en algunas organizaciones, las retrospectivas han pasado de ser la reunión que no le interesaba a nadie a ser el espacio para que cualquiera acuda a comentar los problemas que consideran oportunos o hablar de sus propias preocupaciones del proyecto. Aquí podemos decir que las retrospectivas son un espacio exclusivo para el equipo Scrum y en realidad los participantes externos no son bienvenidos. Es muy complicado crear un entorno de seguridad para que los participantes hablen cuando saben que pueden ser juzgados por alguien que no entiende las dinámicas del equipo Scrum y que no ha trabajado con ellos dentro del día a día del sprint o sprints.

4) Nadie habla de los verdaderos problemas: Otro problema que se ve de manera frecuente es que de nada sirven las dinámicas divertidas si los valores de Scrum no están presentes. Y esto es que la transparencia, el compromiso, confianza y coraje no esten en el paisaje. Se hace alusión a la confianza y el coraje porque en este espacio es donde las personas pueden abrir su mente y su sentir y dar a conocer lo que sienten y piensan frente a alguna situación o su posición en el proyecto. Pero ocurre que muchos equipos no tienen ninguno de los dos valores y en la retrospectiva solamente tienden a hablar de cosas simples, vanalidades y no tratan los verdaderos problemas. La labor del Scrum Master es gestionar Scrum y promulgar los valores de Scrum. Si el resto del equipo Scrum no tiene coraje para hablar de los problemas que les afectan, el Scrum Master tiene la responsabilidad de hacerlo. De nada sirven las dinámicas divertidas si los valores de Scrum no están presentes. Por ello el debe tratar de crear espacios de diálogo a nivel personal y grupal para conocer las dolencias del equipo y de los individuos.

5) Las retrospectivas son el momento de los sentimientos: Esto es que algunos Scrum Masters y equipos Scrum ven las retrospectivas como el momento de hacer terapia, donde se habla de sentimientos y relaciones personales. Esto está bien, siempre y cuando: a. Sean problemas reales de los equipos y b. Sean los aspectos más importantes a tratar, decididos por el equipo. La Psicología es genial cuando los verdaderos problemas son de relaciones humanas y para un martillo todos son clavos. Nuestra rol es de Scrum Masters y no de Psicólogos - eso debería ser claro para todos. Sin embargo, a veces no es claro para el equipo. Entonces debes ponerselo por delante al equipo.

Por otro lado se tiene que de nada sirve un equipo Scrum que se quiere mucho y tienen un clima de trabajo excepcional si la calidad del producto que desarrollan es pésima.

6) Otro error en las retrospectivas es tratar a los compañeros como si fueran estúpidos: Es común ver a equipos de desarrollo que se sienten tratados como si no tuvieran ni idea de relaciones, o de que significa hacer una retrospectiva, o cómo si no supieran Scrum. Si tratamos al equipo Scrum como niños, se comportaran como niños - así de simple. Si la única manera que tenemos de hablar de los problemas es a través de juegos y metáforas, ¿Cómo esperamos alcanzar soluciones adultas?. Aquí el Scrum Máster tiene inherencia y debe crear lúdicas pensando en ellas como espacios serios.

7) El momento de gloria del Scrum Master: La retrospectiva debe ser el momento de todo el equipo Scrum, no los 60 minutos de gloria del Scrum Master. He visto Scrum Masters enfadados con el resto del equipo porque no participaban en sus increíbles dinámicas o no hablaban de los problemas que el Scrum Master quería que hablaran.

Es importante en este punto destacar que una retrospectiva es una actividad orgánica, decidida por todo el equipo Scrum, en la que se tratan los temas que ellos consideran oportunos, y no el momento para que el Scrum Master despliegue su conocimiento sobre dinámicas de equipo. Aquí el consejo es "Escuchar antes que actuar".

8) Falta de compromiso con los planes de acción levantados en retrospectivas: en este punto hago enfásis en que no trabajamos con niños sino con adultos. Y los acuerdos y planes elaborados deben respetarse y seguirse. Los scrum máster por su lado deben hacer tareas de coaching con el equipo y de alguna manera traer a colación en la ceremonia estos planes para hacerles seguimientos.

9. Otro error común es la falta de previsión y gestión de Riesgos dentro de los proyectos: aunque estemos en Scrum este proceso debe llevarse a cabo. Las herramientas son las mismas que en la gerencia de proyectos tradicional (listas de chequeo, matrices de riesgos,etc) y el efecto de no hacerlo es incurrir en reprocesos y pérdidas económicas tal y como pasa en la gerencia de proyectos tradicional.

10.Formalizar los acuerdos. Ya lo habíamos mencionado en otro Post, pero es importante que las cosas que se acuerdan por el equipo queden registradas por lo menos mientras el equipo es maduro y prescinde de ello. El medio lo define el equipo puede ser un sitio web centralizado, una carpeta compartida, el correo electrónico , etc.

11. Los Scrum Másters no son Gerentes de proyectos. No ahondaré en la situación pero lo que quiero decir es que los equipos en Scrum son autogestionados y no necesitan de un policía que este detrás de los demás para revisar si su trabajo se realiza o no.

12. La falsa creencia que el Backlog es una lista de deseos. Los product owners tienen la responsabilidad de actualizar y priorizar la lista de historias de usuario que forman parte del Product Backlog y seleccionar las que forman parte del sprint backlog. El backlog debe tener una dimensión determinada y no convertirse en una lista infinita de requerimientos que al final se gestione como un proyecto predictivo con construcción de prototipos. Por ello, su no gestión nos hace tener un back log repleto - lleno de ideas que no tienen orden ni coherencia que desencadena desmotivación al final en los equipos de trabajo y reprocesos de tiempo y dinero.

En PMPMedellin esperamos que este resumen les sirva para aprender de lo que otros han padecido implementando SCRUM y les ayude a no caer en los mismos errores que otros ya han caído. Los problemas identificados tienen solución como hemos mencionado en el escrito y lo importante es que identifiques si esto te está pasando en tu equipo SCRUM para que hagas un alto en el camino y revises como puedes superar el impedimento y mejorar la dinámica con tu equipo. Si te ha  gustado lo que leíste no olvides en compartirlo con tus amigos, conocidos, compañeros de trabajo y familiares. 

Autor : Ing.Javier Mauricio León Reyes

Twitter e Instagram: @PMPMedellin

Fuentes Consultadas:
https://jeronimopalacios.com/2017/01/6-errores-facilmente-evitables-los-equipos-scrum/
https://jeronimopalacios.com/2016/05/7-razones-por-las-que-las-retrospectivas-en-scrum-fallan/
http://www.laboratorioti.com/2015/06/01/los-5-fallos-de-scrum-que-impiden-que-se-implante-en-tu-empresa/