Saltar al contenido

¿Deseas suscribirte al blog y recibir mis últimas actualizaciones? Haz click aquí.

SCRUM no es vitacilina

Entre las cosas místicas que nos han heredado nuestras abuelas se encuentran la pomada de la campana, las perlas de éter y particularmente la vitacilina. Para los que no tienen abuela, o no saben que es vitacilina, es uno de esos ungüentos que prometen aliviar prácticamente todo, al más puro estilo de brebajes y sustancias vendidas por merolicos en siglos pasados. Si bien este fabuloso ungüento posee algunas propiedades curativas para la piel, dista mucho de ser un medicamento que solucione todos los problemas dermáticos. Del mismo modo, en la administración de proyectos de software, pensar que una metodología solucionará todos los problemas es ser iluso.

Existen varias metodologías de desarrollo de software y administración de proyectos, muchas para listarlas aquí. Algunas que tomaron importancia a principios de los 2000’s fueron las definidas como ágiles, una de ellas, SCRUM, que plantea procesos iterativos donde inspeccionamos los requerimientos en ciclos de tiempo más pequeños y nos adaptamos conforme estos van cambiando. Dicha metodología tomó fuerza sobre todo por dos aspectos principales: el boom de los startups y, primordialmente, por el fracaso casi continuo de las viejas metodologías.

Por cierto, el término SCRUM proviene de una jugada o formación del deporte rugby donde el equipo se re-agrupa para continuar el juego. En esta misma analogía, SCRUM como metodología supone trabajo en equipo y re-organización cada vez que sea necesario.

¿Por qué fracasan los equipos de SCRUM?

Hace algunos años escribí sobre este tema. La verdad es que podría decirse que he estado involucrado en pocos proyectos utilizando SCRUM, 4 para ser exactos, y conforme ha pasado el tiempo he adquirido experiencia en el tema después de, claro está, fracasar en proyectos tanto en waterfall como en SCRUM. Actualmente tengo el rol de Scrum Master en mi equipo de trabajo (aunque sigo felizmente haciendo labores de ingeniería) y aunque seguimos puliendo el proceso podría decir que es el equipo donde hemos madurado más rápido y obtenido resultados en poco tiempo.

Como es usual, navegando por LinkedIn me encontré una publicación interesante de una persona que, según su perfil, tiene al menos 20 años en la industria desempeñandose como project manager, y comparte el siguiente texto acompañado de una foto:

Mateo es el electricista del barrio. Ha hecho un curso exprés de Transformación electro-digital y electro-Agile en instalaciones eléctricas. Cuenta con un certificado eléctrico. Su último proyecto ha sido un verdadero éxito. Al menos, eso dice él. En cada sprint ha aportado valor al cliente. Siempre de forma ágil y rápida. Sus clientes no entienden de temas eléctricos. No les interesa. Solo necesitan una cosa. Consumir energía eléctrica para sus dispositivos. La energía es importante para ellos. En el sprint 1 Mateo sólo necesitó dos adaptadores. De los baratillos. Dio servicio a dos clientes que necesitaban energía para una lámpara y un móvil. La entrega fue un éxito. Tuvieron energía. El sprint 2 fue un poco más complicado. Necesitó 4 adaptadores que fueron acoplados empleando las mejores prácticas. Dio servicio a 3 clientes que necesitaban energía para un despertador digital, una aspiradora y una Tablet. El resultado no podía ser mejor. Ágil. Adaptativo. Rápido. Barato. En plazo. Transformador. Digital. Escalable. Ningún cliente insatisfecho. Todos tenían lo que querían.

Scrum Fail
Scrum Fail

Y yo, como muchos otros que comentaron el post (yo me aguanté las ganas) pienso que lo que esta persona extrapoló fue una frustración personal, quizá por un proyecto en SCRUM mal administrado, o varios o, simplemente, por el desconocimiento de la metodología. Es fácil caer en esa posición ya que muchos profesionistas piensan aun que ágil es sinónimo de rápido. Algo así como el «Free software not as in free beer«.

Hay muchas razones por las cuales la administración de proyectos fallan, en particular, para SCRUM podría citar las más importantes:

  1. Pensar que SCRUM es, de hecho, una manera de administrar proyectos
  2. Usar SCRUM para el diseño de arquitectura de alto nivel de un producto
  3. No delegar responsabilidades y roles
  4. Simple desconocimiento, es decir, implementar SCRUM con coaches que nunca han usado SCRUM.

Consejos para mejorar el trabajo en SCRUM

SCRUM como tal no es una metodología de administración de proyectos, es mas bien, una metodología de trabajo. De hecho, el tener a un PM o project manager en sincronía con el equipo SCRUM es algo bastante saludable mas no es parte de la metodología, en SCRUM no hay un «jefe» ni tampoco «líderes», existen roles bien predefinidos, ceremonias o «rituales» y «artefactos» o herramientas para aplicar dicha metodología y me parece que es ahí donde está el problema principal en equipos o líderes con poca experiencia en el tema: el miedo al cambio y sobre todo la aceptación de la cadena de comando que es, inexistente en este caso.

Aunque podría hablar largo y tendido sobre el tema (cosa que se me da) listaré algunos de los puntos más importantes que considero pueden ayudar a implementar de manera satisfactoria la metodología de SCRUM y que particularmente me han ayudado en mis proyectos:

Involucrar a las personas adecuadas

El primer problema que he visto en las organizaciones y proyectos donde he laborado ha sido primordialmente este. SCRUM define solo tres tipos de roles dentro del equipo: Product Owner, Scrum Master y Team Member. Existe también el término de Stakeholder que es escencialmente quien tiene interés de comercializar el producto o que el proyecto sea éxitoso, usualmente esto se traduce en: los inversionistas, ejecutivos de la empresa, etc.

Si bien el Product Owner no es el administrador del proyecto (SCRUM no define tal cosa) es quien será el encargado de ser el canal de comunicación entre stakholders y los miembros del equipo o Team Members. Parte escencial de su trabajo es la definición de requerimientos basado en comunicación constante con los stakeholders y priorizar u ordenar estas tareas. No tener a una persona definida como Product Owner en cada equipo es simplemente fórmula ideal para el fracaso del proyecto.

Por otra parte, también es importante contar con un Scrum Master. Su principal responsabilidad es asegurarse que se implementa la metodología de manera adecuada y que nadie en el equipo tenga contratiempos para hacer su trabajo, es un «coach«. Un error común es tener a un Product Owner realizando labores de Scrum Master, peor aún, a un Project Manager siendo Product Owner y Scrum master, de nuevo, fórmula para el fracaso.

En resumen, es necesario que todos los roles estén bien definidos y sobre todo involucrados en el proceso y no solo los programadores, diseñadores,  devops, etc. Uno de los valores principales del «manifiesto ágil«, de hecho el primero, nos dice «Individuals and interactions over processes and tools» es decir, dar más importancia a la comunicación e interacción constante que a los procedimientos o herramientas ¿Les suena? Es mejor preguntarle en el momento al Product Owner alguna duda sobre alguna tarea que mandar un correo y esperar respuesta o documentar algo que nadie va a leer.

Implementar exponencialmente

Si bien existen algunas cosas muy bien definidas en SCRUM, como en cualquier cambio en estructuras de trabajo, es casi imposible hacerlo de la noche a la mañana. Tal como quitarnos los malos hábitos, implementar SCRUM supone una serie de pequeños cambios exponenciales de manera que el equipo pueda transicionar a esta nueva forma de trabajo (e incluso los stakeholders) sin agobiarse. Si comenzamos por ejemplo con simplemente empezar a tener las ceremonias entonces de ahí podemos pasarnos a otros cambios, sobre todo para equipos ya funcionales que tienen quizá una manera muy definida (o indefinida) de trabajar.

En el caso de mi equipo, por ejemplo, hemos hecho las estimaciones de user stories utilizando un promedio, es decir, considerando puntuaciones diferentes. En equipos ya altamente funcionales y con experiencia en la metodología se recomienda discutir «la carta» o puntuación mas alta y la mas baja, entre todo el equipo, hasta que todos lleguen a un consenso, es decir, a la misma puntuación, sin embargo, esto nos hubiera quitado más tiempo del que tenemos para esta ceremonia así que opté, al inicio, por usar el promedio.

Otro buen ejemplo son los action items en las retrospectivas. Inicialmente no los tomábamos en cuenta, simplemente discutíamos que habíamos hecho bien durante el sprint y donde podíamos mejorar. En posteriores sprints comenzamos a capturar action items o cosas a las que el equipo o alguien específicamente se compromete a mejorar o cumplir para el siguiente sprint, de esta manera se volvió más fácil entender la importancia de dichos elementos de acción y llegó un momento en que ya se volvieron responsabilidades. En resumen, suavizar el inicio y, conforme avanzamos y se vuelven hábitos en todo el equipo, comprometernos a seguir más de lleno la metodología.

Apoyarse en herramientas

Una de las cosas «divertidas» de SCRUM son sus herramientas: «El board«, donde pegamos pequeños post-its con las historias por hacer durante el sprint, el juego de estimaciones o «poker planning» donde se asignan puntos a las historias, etc. Aunque muchos practicantes de SCRUM recomiendan realizar todas estas ceremonias físicamente, con artefactos físicos (un pizarrón, post-its, barajas de estimación, etc.) es poco práctico sobre todo para proyectos donde cambian constantemente las cosas y, si nuestro equipo es nuevo en SCRUM, es muy probable que esto sea aun mas difícil.

Para poder llevar una administración inteligente de cada sprint, utilizar herramientas de software es definitivamente la mejor opción, sobre todo si tenemos equipos distribuidos de manera remota donde no todos los equipos están en el mismo lugar físico.  Existen herramientas como JIRA, Trello, Pivotal Tracker, etc. diseñadas particularmente para estas metodologías que ayudarán a todo el equipo no solo a cumplir los objetivos sino a tener visibilidad para los stakeholders y el product owner. Hablamos del product backlog, el sprint backlog, los burndown charts o incluso algo más avanzado como un user story map.

Pero no solo las herramientas usuales son útiles, fomentar el uso de un calendario compartido, por ejemplo, para que todo el equipo esté al tanto de los horarios de las ceremonias o compartir enlaces de video-conferencias. Por otra parte, esto le permite al Scrum Master tener visibilidad de la disponibilidad de todos los involucrados y ajustar las ceremonias si existen cambios en la agenda de alguien en particular, de manera que siempre estemos participando, sin importar si hay una agenda rígidamente definida.

Respetar las ceremonias

Esta es una de las tareas más difíciles en mi experiencia. Debemos motivar a todos los involucrados a respetar las ceremonias o rituales, es decir, el daily standup, el backlog grooming, el sprint planning, el sprint review y el retrospective. Realmente todas las ceremonias son importantes pero, lo que es particularmente importante es que los roles necesarios a involucrarse en cada una de ellas estén disponibles y las tomen en serio. La mejor manera de hacerlo es siempre motivando a la gente a que participe pues de eso se trata SCRUM y no dejar que un solo miembro se adueñe de alguna de estas ceremonias, por ejemplo, es común que en equipos nuevos si el Project Manager tomó el rol de Product Owner no deje hablar a los demás, esto desmotiva a los asistentes.

También es importante entender que debemos adaptarnos a la disponibilidad de los demás. Si bien ayuda tener bien definidos los horarios y días para cada ceremonia nada está escrito en piedra; si el Product Owner está en una junta importante y no puede estar en nuestra llamada de Daily Standup entonces es preferible re-agendar la llamada de ese día de manera que pueda estar presente. Por otra parte, los stakeholders son parte esencial del proceso y aunque es difícil involucrarlos al principio, sobre todo si son trabajadores de nivel ejecutivo o «Upper Management«, hay que motivarlos a que participen y sobre todo mantengan comunicación continua con el Product Owner.

Inspeccionar y adaptarse

La parte elemental de SCRUM: inspeccionar, y adaptarse. La razón de ser de esta metodología es precisamente solucionar algunos de los problemas de rigidez de otras como waterfall así que es natural y saludable estudiar y analizar los resultados sprint con sprint y adaptarnos a los cambios, no solo dentro del equipo sino de los objetivos de la empresa. En resumen, no forzarnos a hacer las cosas de alguna manera o a alguna hora o tiempo en específico pero si comprometerse a hacerlas y sobre todo a ir mejorando la manera de hacerlas.

Y finalmente, como les he dicho tanto a stakeholders como a miembros del equipo cuando inicio mi coaching: SCRUM no es una llamada diaria de teléfono a las 9:00 am, es más que eso.

 

Publicado enIngeniería De Software

Sé el primero en comentar

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.