Fuente: Pixabay (link)

En los últimos años, muchas empresas están aplicando o están intentando aplicar Scrum, no sólo por un tema de moda, sino porque realmente creen que necesitan ser ágiles para poder responder de una manera más rápida, frente a sus clientes, frente al mercado y/o frente a sus competidores.

En este proceso de adopción, muchos profesionales y empresas cometen diversos errores, los cuales les generan diversos problemas, algunos fáciles de resolver, pero otros, en su mayoría críticos, terminan afectando a las personas y por ende a los resultados del proyecto.

A continuación, presentamos los errores más comunes que se comenten cuando aplicamos, intentamos aplicar o creemos que aplicamos Scrum:

No capacitar a tu equipo… ni a tus usuarios

Uno de los principales problemas, es que todo tu equipo no tiene la misma base o formación necesaria para aplicar Scrum. Algunos han llevado el curso de certificación, algunos además de llevar el curso lo han aplicado en algunos proyectos, y otros no saben de Scrum o de metodologías ágiles.

Llevar el curso de certificación, NO ES SUFICIENTE. Es importante mencionar esto, pues el llevar el curso quizás sea uno de los primeros pasos que se debe dar, luego de ello existe un gran camino para comprender y alcanzar la agilidad.

Como lo comenté en otro post (Ciclo de Vida de Desarrollo del Sistema Ágil – Un extracto del libro An Executive’s Guide to Disciplined Agile, de Scott W. Ambler), en la mayoría de los cursos de certificación no te enseñan cuál es el ciclo de vida de un proyecto cuando aplicas Scrum, sólo te enseñan lo que hay dentro de cada Sprint.

¿Cómo puedes desenvolverte bien en un proyecto que está siendo llevado con Scrum si no estás lo suficientemente capacitado? Esta es la pregunta que nos debemos hacer.

¿Quieres tener éxito en tu proceso de adopción de agilidad? Pues capacita a tu personal y contrata a un Scrum Master con experiencia, no alguien que recién haya terminado un curso, sino alguien que sepa de Scrum, de Kanban, de Coaching, de otras metodologías ágiles, que lo haya aplicado con éxito y que también haya vivido varios errores y problemas, para que sepa cómo solucionarlos!!

No te olvides de tus usuarios, explícales el cambio de la metodología, de tu proceso de desarrollo de software, explícales los conceptos básicos, ¿qué es Scrum? ¿qué es un Sprint? ¿qué es una historia de usuario? ¿qué son los criterios de aceptación? ¿Hasta cuándo tienen para definir la funcionalidad de la aplicación a implementar en el siguiente Sprint? ¿Cuál es el porcentaje de asignación que deben dar al proyecto con este nuevo framework? Explícales que las cosas van a cambiar y que necesitas de su apoyo (y disponibilidad) para todo resulte un éxito.

Aplicar Scrum “a tu manera”

He conocido empresas que aplican Scrum “a su manera”, sin considerar que al omitir estos pasos, artefactos, entregables o ceremonias, afectan directamente al resultado del proyecto.

Recuerdo la gran lección que me enseñó uno de mis profesores de Maestría, en una asesoría, donde me explicaba claramente la forma en cómo se genera una metodología como la del PMBOK, “en donde miles de miles de profesionales comunican libremente las prácticas que les han generado los mejores resultados, hacia un Comité encargado de crear la nueva versión de esta metodología, en otras palabras, esta metodología es creada a partir de mejores prácticas y que han tenido la oportunidad de ser probadas”.

Scrum está diseñado y pensado, en el conjunto mínimo de ceremonias, roles y artefactos a ejecutarse para asegurar la calidad y el éxito del proyecto.

“Scrum provides a minimal set of boundaries (five events, three roles, three artifacts) to have the appropriate conversations at the appropriate time with the appropriate people.”

Fuente: Barry Overeem Blog (link)

¿Podría no celebrar las reuniones de los daily meetings? Me ocupan mucho tiempo!! No! no puedes! Debes hacer los daily meetings, bien hechos no toman tiempo. Los daily meetins son necesarios para que todo el equipo se entere de lo que han hecho el día anterior, de lo que van a hacer dicho día y conocer los impedimentos existentes.

¿Puedo aplicar Planning Poker con barajas comunes? De preferencia no. Las cartas y números incluidos en un planning poker siguen la secuencia de fibonacci o progresiones similares. ¿Por qué? Porque lo que se busca es reflejar la incertidumbre propia de la estimación, y obtener distintos valores de parte de todas las personas que participan de la estimación, a fin de luego generar el consenso necesario.

Y así como esas preguntas o cuestionamientos, habrán muchos más, así como las respuestas a cada uno de ellos.

Poner a cargo a alguien que no sabe de Scrum

Esta quizás es una de las peores acciones que se dan cuando intentas ser ágil. Recuerdo bien el caso de un amigo que me contó lo que ocurrió en su empresa: “han puesto a cargo del proyecto (en el que estaba trabajando) una persona que no sabe nada de Scrum, y tampoco tiene deseos de aprender, es más, le ha comentado al usuario líder que esta metodología no es la que el necesita.”

Sin importar el nombre de la metodología, del framework o del proceso, esta persona “a cargo del proyecto” es un detractor, y cualquier práctica ágil, cualquier principio del manifiesto ágil o cualquier ceremonia que quieras aplicar, sólo la podrás aplicar de manera parcial o en su mínima expresión.

De nada sirve cuestionar el escenario, quizás lo mejor en estos casos sea escalar el problema o dar un paso al costado.

Contratar una empresa proveedora que dice que aplica Scrum, o que dice ser ágil, y que no lo es!

Imagínate, encontrarse en pleno proceso de adopción de un framework ágil, intentando sacar adelante este cambio en tu área, en tu empresa, y tener que trabajar con un proveedor que no aplica las principales prácticas de Scrum.

Un amigo me comentó el siguiente caso: “Mi proveedor no hace un Sprint Review adecuado, el hace algo así como un Sprint Overview! Sólo nos presenta las nuevas funcionalidades desarrolladas, pero no le permite al usuario realizar las pruebas en dicha ceremonia… Nuestro Sprint dura 3 semanas, pero el Review sólo dura 2 horas!!”

Como bien sabemos los Sprint Review son timeboxed, si el Sprint dura 4 semanas, el Sprint Review debe durar 8 horas. En el caso anterior el Sprint Review debió durar por lo menos 6 horas.

Otro amigo me comentó su caso: “Todos los Sprints que trabajamos tienen diferentes duraciones, unos 2 semanas, otros 3 semanas y otros 4 semanas, es esto correcto?” La respuesta es simple, sí y no. pensando en ver como podemos cuadrar las fechas del proyecto, en algunos considerando los aspectos del portafolio de proyectos o aspectos comerciales. No pensando en desarrollar adecuadamente tu equipo, pues al tener Sprints de diferente duración, no puedes comparar la velocidad obtenida por tu equipo en cada Sprint.

Finalmente, un exalumno me comentó su caso: “Mi proveedor nos indica que debemos realizar pruebas de lo entregado en el Sprint X, en el Sprint X+1, y recién lo solucionará en el Sprint X+2.” Esto tampoco es adecuado, lo ideal es que durante la celebración del Sprint Review, se encuentren todos los defectos y bugs posibles, y que estos sean corregidos en el siguiente Sprint. ¿Por qué tu proveedor te daría tanto tiempo para probar? Bueno, es claro que el nivel de calidad del proveedor no es el más idóneo, o necesario para dicho proyecto.

Esto sin considerar, la forma en la que deberías de contratar a tu proveedor, no de la forma bill & materials, sino aplicando un tipo de contrato fixed-price, ya que este último es el que mejor le conviene a la empresa contratante.

No realizar un adecuado Scrum Release Planning

Uno de los puntos más importantes cuando se aplica una metodología ágil, es definir que contendrá cada uno de los releases del producto que se va a construir o que se viene construyendo, definiendo adecuadamente el Minimum Viable Product (o MVP), si es que se comprende correctamente dicho concepto.

Existen libros, artículos y muchos recursos que nos pueden ayudar a comprender la correcta definición de MVP, y cómo esta debe de aplicarse a un proceso de desarrollo de software llevado con Scrum. Ya en otro post hablaremos de Growth Driven Design (GDD).

Uno de los principales problemas de su errónea comprensión, es que terminas postergando el desarrollo de muchas funcionalidades para una muy cercana fase de estabilización.

Les adjunto una muy buena presentación que encontré, la cual fue realizada por Ken Schwaber en el 2010, donde hace referencia al estado de Scrum y los principales problemas de su adopción, haciendo énfasis en este último punto.

En conclusión…

Llegar a alcanzar un adecuado nivel de adopción de Scrum en tu área o en tu empresa, además de muchas ganas, toma tiempo, pero si van a hacerlo, deben hacerlo bien y haciendo lo correcto. Van a aparecer mil y un problemas, pero lo apropiado es aplicar el framework como debe ser, no como crees que es.

Recuerdo lo que me dijo un ex compañero de trabajo: “Cuando aplicas mal una metodología frente a tus usuarios, quemas la metodología!! luego los usuarios no creen en ellas (en las metodologías) y no tienes oportunidad de volver a aplicarlas…”

Espero que este artículo les haya servido :). Déjanos tu comentario, indicándonos cuál fue o es el principal problema en tu empresa.