Blog Post

¡¡Scrum cumple 25 años!!

Antonio Jesús Ruiz Córdoba • 20 de noviembre de 2020

Con una nueva versión de la guía...

El 18 de Noviembre de 2020, en un evento retransmitido en directo por internet, los creadores de Scrum (Jeff Sutherland y Ken Schwaber) dieron a conocer la nueva versión de la guía. Una guía más corta que la anterior.

El 30 de agosto, el propio Ken escribió en su blog que la nueva versión iba a tener tan solo 13 páginas (por las 19 de la previa). Yo estaba asombrado de cómo era posible recortar tanto de un marco de trabajo del que apenas había donde recortar. Me habían provocado una impaciencia e incertidumbre por ver el resultado.
Aquí podéis ver el anuncio del que os hablo: https://kenschwaber.wordpress.com/2020/08/30/scrum-guide-2020/

Una vez que la he tenido en mi mano y he podido ver los cambios, me he sorprendido gratamente por el cambio. Han mejorado algo que era muy difícil mejorar.
Vamos a ver juntos los principales cambios y los vamos a ir valorando uno a uno:

Se ha vuelto menos prescriptiva : Ya lo comento en las formaciones. Scrum es un marco de trabajo y dentro del marco podemos hacer lo que nos dé la gana (mientras mantengamos el espíritu del marco y la mentalidad Agile). Lo que han hecho ahora es poner el marco más fino para que tengamos más margen de maniobra. ¿Cómo? Pues suavizando las palabras prescriptivas reduciendo pasos como en el Daily Scrum o en la cancelación de Sprint lo cual nos permite tener más poder de decisión (entre otros).
Mi opinión : Me gusta que intente alejarse del concepto de metodología. Dependiendo del nivel de madurez del equipo, el SM será el que tenga que proponer distintas pautas o formas de actuar para corregir los distintos problemas que puedan darse, pero ahora con aún más manga ancha.
Un equipo, un producto : Desaparece el concepto de Equipo de Desarrollo y los roles. Ahora sólo hay un equipo, el equipo Scrum, con distintas responsabilidades. Ahora el ST lo forman un SM, un PO y Desarrolladores.
Mi opinión : No terminaba de ver qué se ganaba con el cambio hasta que oí a Jeff Sutherland explicarlo en directo. Yo partía de la base de que el objetivo de todos es el mismo y ahora eso mismo lo remarcan con mayor claridad. Según Jeff anteriormente se podía llegar a producir un "nosotros vs ellos" y aunque estamos todos en el mismo equipo, realmente había un sub-equipo, un grupo separado, una especie de "gueto" en el cual podía llegar a relajarse la responsabilidad de toma de decisiones a tan sólo una persona (el PO). Ahora sigue habiendo distintas responsabilidades pero remarcando que el objetivo de enfocarnos en lo mejor para el producto sigue siendo algo de todos. Es un matiz importante que evita malinterpretaciones y simplifica. ¡Bravo!
Product Goal : Aparece el concepto de Objetivo del Producto o Product Goal asociado al Product Backlog. Con esto el equipo podrá siempre poner el foco hacia un objetivo de mayor valor. Cada Sprint el producto irá acercándose a más al Product Goal .
Mi opinión : Básicamente lo que han hecho es exportar la idea del trabajo del Sprint al producto. En el Sprint, evaluamos día a día si nuestro trabajo se acerca al objetivo del Sprint y hacemos un plan diario para favorecer que nos acerquemos. Ahora hacemos lo mismo pero también a un nivel mayor de tiempo. Sin poner ese objetivo (igual que cuando no se pone objetivo en el Sprint) se dificulta la toma de decisiones y se pierde el foco. Buen añadido.
Un lugar para el Sprint Goal, Definition of Done y Product Goal : En las versiones anteriores, aparecía el concepto de Objetivo del Sprint o Sprint Goal y Definición de Hecho o Definition of Done , pero no se les daba identidad. Ahora, los dos que ya existían, más el nuevo aparecen asociados con un artefacto cada uno, de forma que cada artefacto tiene un compromiso: El Product Backlog con el Product Goal, el Sprint Backlog con el Sprint Goal y el Incremento con el Definition of Done.
Mi opinión : Aquí se está clarificando y simplificando algo que la versión anterior ya tenía. Es verdad que con el Definition of Done muchos alumnos se preguntan si es o no un artefacto y si no lo es, ¿por qué no? si es algo que el equipo realmente usa durante el desarrollo. Ahora aclara que cada artefacto tiene un compromiso de transparencia hacia algo y le pone nombre. Además reafirma lo que comento en las formaciones: El DoD va a nivel del PBI que es lo que finalmente va a ser el incremento.
Auto-gestión en lugar de auto-organización : En la versión anterior, el equipo de desarrollo se auto organiza decidiendo de forma interna quién y cómo se realiza el trabajo. Dado que el equipo de desarrollo ya no existe, ahora el equipo (el Scrum Team, el único equipo que hay) se auto gestiona, es decir, que ya no sólo decidimos quién y cómo, sino también qué trabajos se van a realizar.
Mi opinión : Me pasó algo parecido al cambio explicado en el punto 2. No veía la importancia del cambio. Con la auto-gestión deja claro la desaparición del sub-equipo y que todos vamos hacia el mismo objetivo, así que añade a ese nivel de organización el poder de decisión del qué vamos a hacer incluyendo por supuesto a los desarrolladores.
Tres temas en el Sprint Planning : En la versión anterior, el Sprint Planning se dividía en dos: Qué vamos a hacer y cómo lo vamos a hacer. Ahora se añade un punto previo para que el equipo hable del por qué (o para qué) vamos a trabajar en el Sprint que comienza.
Mi opinión : Esto es algo que ya hacían muchísimos equipos. Es muy difícil preparar un buen "qué vamos a hacer" si no sabemos el por qué (o para qué) vamos a hacerlo. Sin embargo aún hay equipos que no lo hacen (principalmente porque están ocultando un Kanban dentro de Scrum o cosas peores que no quiero nombrar). Dejar claro la necesidad de que el equipo conozca el por qué de todo es algo muy positivo y los que me conocéis sabéis de sobra que los "por qué" de todo es fundamental para poder escoger siempre una opción que se acerque más a las necesidades reales de la situación, el producto o el mercado.
Simplificación del lenguaje para una mayor audiencia : Se elimina contenido complejo o redundante y cualquier referencia al mundo del software, dejando claro su apuesta multi-sectorial. Con todo ello se ha reducido el contenido hasta las 13 páginas.
Mi opinión : Vámonos un momento al mundo Lean. Uno de los conceptos de Lean es "eliminar desperdicio". Uno de los puntos del desperdicio es la "documentación superflua". Eliminando contenido complejo y redundante se han acercado más aún, no sólo esos principios de Lean a los que hago referencia, sino también al principio de "Simplicidad" del Agile Manifesto. No por tener más contenido se es mejor. Lo habitual es que sea al contrario y lo han conseguido. Además, ya han abandonado completamente el mundo del software (ejemplo claro de entornos complicados y complejos) para dar cabida a cualquier sector. Me pregunto si cuando actualicen la guía de Nexus (versión actual de 2018) eliminarán todas las referencias al software que ahí sí están usando.
Cambios menores: Hay algunos cambios pequeños que también son curiosos:

Los pilares de Scrum no son útiles si no se usan los tres bien. Esto que explico durante las formaciones, ahora se menciona explícitamente en la guía. No hay Adaptación sin Inspección. No hay Inspección sin Transparencia.
Al desaparecer el Equipo de Desarrollo, también lo hace el número de integrantes (de 3 a 9). Ahora aparece el tamaño del equipo (el único equipo que hay, el Scrum Team) y el número es de " típicamente 10 o menos ". Ya no se especifica un mínimo y el número de personas que pueden trabajar en tareas del Sprint Backlog suben de 9 a 10 (la guía vuelve a dejar claro en el Daily que tanto el SM como el PO pueden hacer tareas de desarrollo, como ya lo hacía en la versión anterior cuando decía que en el máximo de 9 se contaban al SM y al PO si éstos hacían tareas de desarrollo).
El SM pasa de ser un "líder-sirviente" como aparecía en la versión anterior, a un "verdadero líder que sirve al equipo y a la organización". En palabras de Jeff Sutherland, se quiere evitar que el SM sea un mero secretario del equipo para dejar claro su importancia real en él. Personalmente me gustaba el concepto de líder-sirviente, pero creo que ahora deja más claro lo que realmente se espera de este un SM. Por ejemplo, en la guía ahora aparece que el SM es el que causa que los impedimentos desaparezcan mientras que en la versión anterior venía que el SM eliminaba los impedimentos. Todo esto refuerza la labor del SM en su empeño en que el equipo crezca a nivel grupal e individual.
En la versión anterior, se mencionaba que el Daily Scrum se hace en el mismo sitio y misma hora para reducir la complejidad. Ahora se menciona explícitamente que TODOS los eventos se hacen en el mismo sitio y misma hora para reducir la complejidad.
En la versión de 2016 de la guía había que hacer tres preguntas durante el Daily. En la de 2017 esas preguntas son un ejemplo que se puede hacer. En esta nueva versión desaparecen las preguntas para que cada daily se pueda hacer como mejor se considere dentro de la auto-gestión, siempre que se enfoque en el progreso hacia el objetivo del Sprint y provoquen un plan para su actuación.
El Sprint Review es uno de los que más recortes tienen a nivel prescriptivo. Deja claro el para qué se hace, pero elimina pasos que había que hacer durante el mismo.

Me daba pánico pensar en los cambios que iban a hacer y que provocara una reducción en el contenido. Una vez evaluado y comprendido, me ha parecido todo un acierto, consiguiendo reduciendo el tamaño de la misma hacerlo más enfocado al objetivo de entregar valor de forma continua. La base es la misma. Scrum sigue siendo Scrum. Pero creo que han mejorado.

He ojeado también la traducción al español. No la he evaluado al completo, pero tiene mejor pinta que la anterior. Han corregido el error de traducción que había en la versión 2017, donde " desapareció " el respecto dentro la lista de valores de Scrum. Sin embargo, en una simple ojeada, he visto un error (grave, a mi parecer) porque cuando indican los cambios principales han indicado el "Development Team" como parte del Scrum Team cuando justo es una de las cosas que han desaparecido...

No os preocupéis demasiado por estos cambios. La base es la misma, la idea es la misma. Si sabéis scrum, vais a seguir sabiendo. Pero si os da miedo qué puede pasar en los exámenes, tranquilos: Hasta el 09/01/2021 todos los exámenes de scrum.org van a seguir estando basados en la guía de 2017. A partir de esa fecha la nueva guía será el foco de las preguntas.

Si queréis ver cómo fue el evento de presentación de la nueva guía, lo tenéis disponible aquí: https://www.scruminc.com/updated-scrum-guide-release/

¿Has visto ya la nueva versión? ¿Qué te ha parecido?

-------------------------------------------------------------------------------------------------------
Edito y me corrijo: Ya he leído la guía en español. Pensaba que tenía mejor pinta, pero tras verla sólo puedo seguir recomendando la original (en inglés). La traducción de la versión 2017 ya era bastante mala, pero la nueva no mejora mucho. Varios ejemplos:

Cuando se habla del PO y de la gestión del PB, uno de los puntos menciona " Ordering Product Backlog items ", que traducido sería "Ordenar los elementos del PB". Bueno, pues la traducción viene algo tan original (e imposible de entender) como: " Pedido de artículos de trabajo pendiente del producto ". Parece que Google Translator ha tenido bastante peso aquí.
El SM ayuda al PO entre otras cosas " Helping find techniques for effective Product Goal definition and Product Backlog management ", que traducido sería como "Ayudando a encontrar técnicas para una definición efectiva del Product Goal y la gestión del PB". Su traducción ha sido: " Ayudar a encontrar técnicas para una definición eficaz de los objetivos del producto y la gestiónde los retrasos en el producto ". ¿Retrasos? ¿De dónde sale eso?
Los nombres de los eventos y roles son nombres propios (vienen en mayúscula siempre) y su traducción podría ser la misma, es decir, podemos hablar en español de Product Owner, Sprint Review o Sprint Backlog sin necesidad de traducirlo. Eso sí, si se traduce debería hacerse medio bien. Cada vez que se traduce el Product Backlog lo hacen como " el trabajo pendiente del producto ". La nueva versión de la guía es más ligera en la versión original, no parece que la española lo haya tenido en cuenta. Mejor no traducirlo y si lo haces deja algo tan sencillo como "pila del producto".
El peor de todos: El ya comentado " Development Team " en la nueva versión donde ya no existe dicho grupo.

< Entrada más antigua

Entrada más reciente >

E-mail

Otras entradas del blog:

Scrum no funciona

Por Antonio Jesús Ruiz Córdoba • 11 de febrero de 2025

En mi experiencia, me he encontrado con muchos casos donde gente muy diversa reniega de Scrum afirmando, con excusas y ejemplos muy diversos que Scrum no funciona. Y esto lo hacen a todos los niveles, desde alta dirección, management, desarrolladores e incluso, algunos "Scrum Master". "Scrum está bien en la teoría, pero en la práctica no funciona", "es que nuestro caso es especial y Scrum no encaja en lo que hacemos", "Scrum tiene demasiadas reuniones que nos hacen perder el tiempo", "Scrum no sirve porque no se mira la calidad", "que sí, que en nuestra empresa hay un Scrum Master certificado y lo hemos probado en un proyecto tal cual viene en la guía y no hemos terminado en tiempo todos los requisitos que se nos pedían"... Casualmente, todos tienen algo en común: Interpretaciones o implementaciones incorrectas. Esto hace que el marco de trabajo Agile más común a nivel mundial, no sólo no dé ninguna ventaja, sino que acaba resultando contraproducente. ¿Quieres que veamos algunos de estos casos? Proyectos cerrados : Excusa : "Es que yo quiero xxxx para dentro de 30 meses y con un presupuesto cerrado de $$$ y con Scrum no puedo tenerlo" Explicación : Este punto parte de una base errónea que además es muy popular: "En Scrum está prohibido tener proyectos cerrados". No. En ningún sitio pone que esté prohibido tener proyectos cerrados y se puede trabajar perfectamente con Scrum un proyecto cerrado. ¿Pero, si la ventaja de Scrum es la adaptabilidad, para qué serviría en un caso como este? Pues justo para eso, para la adaptabilidad. La gran ventaja de Agile en general y Scrum en particular es que nos va a mostrar los problemas con muchísima antelación para que nosotros seamos capaces de adaptarnos, de forma que si vemos que no llegamos podemos aumentar el equipo (o reducirlo), adquirir nuevas herramientas que faciliten el desarrollo o cualquier punto que veamos que puede reconducir el problema. Si nos resultase imposible haciendo cambios de forma interna, tendremos que renegociar algo (alcance, coste y/o tiempo). Renegociar con mucha antelación da opción a que las condiciones puedan cambiar, mientras que si retrasamos dicha negociación hará que se complique o que las nuevas condiciones sean problemáticas para todas las partes. Si es imposible renegociar, posiblemente sea mejor cancelar un proyecto en el mes cinco que en el mes 29, que es lo que pasaría en caso de usar Waterfall (tendríamos muchos más gastos para llegar al mismo punto: No se puede hacer) Problema : Aquí el problema no es Scrum. Es el hecho de aceptar proyectos completamente cerrados en entornos complicados o complejos. Auto-engaño : "Es que mis clientes así lo exigen". MENTIRA (salvo que trabajes con la Administración Pública). ¿De verdad crees que RENFE exigió tener la mayor vergüenza de la ingeniería de software de la historia de España, en forma de una web donde los usuarios que querían hacer una compra sólo conseguían insatisfacción máxima? ¿No crees que si le hubieran dicho "Ey, renegociamos algo porque esto no tiene toda la calidad esperada" no hubieran preferido entregar con calidad un mes después o haber invertido un 5% más pero que los usuarios finales estuvieran contentos? Y si nos vamos al ejemplo inicial: ¿De verdad crees que, en un mundo como el actual donde cada poco tiempo sale algo totalmente novedoso, tu cliente quiere dentro de 30 meses algo que era útil hace 30 meses pero que en el momento de la entrega está obsoleto? ¿Y si durante ese tiempo sus necesidades han cambiado qué hacemos? ¿Le damos algo que ni quiere ni necesita sólo porque el proyecto era cerrado? ¿De verdad crees que ese cliente va a repetir con nosotros? Solución : Es tan sencillo como hablar con tus clientes y mostrarles, pero de verdad, que tu objetivo es su satisfacción y que para facilitar adaptarnos a sus necesidades y evitar casos "web de Renfe" debemos conocer qué podemos negociar en caso de ser necesario (aunque reflejemos qué, cuándo y con qué coste de forma inicial). ¿Quieres que veamos más ejemplos? Sigue atento a esta página donde actualizaremos con más detalles o únete a la Newsletter donde las próximas entregas irán dedicadas a desmitificar bulos sobre Scrum y Agile.

¡PMI y Agile Alliance se unen!

Por Antonio Jesús Ruiz Córdoba • 10 de enero de 2025

Hace unas semanas una chica me preguntó por la certificación de Agile Coach que ofrece el PMI (Project Management Institue). Mi respuesta no podía ser otra que, aunque el saber no ocupa lugar y mientras más te formes mejor, yo no me centraría en esa certificación y el motivo que le di era muy sencillo: Si a mí me pide una empresa que les ayude a contratar a un Agile Coach y hay varios candidatos que me demuestran similares conocimientos y experiencia, yo no sólo no valoro como algo positivo tener certificaciones del PMI, sino que incluso prefiero a alguien que no tenga ninguna al que sólo tenga de esta institución. ¿Por qué? La mayor empresa en el mundo en las certificaciones de Project Management lleva desde 1969 defendiendo un punto de vista predictivo y una forma de trabajo en cascada que no encaja con la filosofía Agile. No está mal en entornos muy simples, pero en cuanto el entorno se complica un poco esta forma de trabajo en cascada ha demostrado una y otra vez su ineficacia, de ahí que naciera hace más de 20 años Agile y su manifesto, para hacer las cosas de una forma distinta. Cuando vieron que perdían el monopolio de las certificaciones en gestión de proyectos por una forma más óptima de trabajar se unieron al carro haciendo su propia certificación en Agile, defendiendo que Agile era perfectamente encajable en la gestión de proyectos tradicionales haciendo algo así como la imagen de este post (imagen de monolit-it.pl/2018/02/Water-Scrum-Fall ). Es decir, que cogen una gestión de proyectos en cascada y, dentro de la fase de desarrollo, es donde se hace un trabajo en iteraciones como si trabajar así ya te hiciera Agile. Algo similar (con otra imagen) es algo que publicó por X (twitter) la cuenta @PMIMadridSpain (si lo quieres, tengo el enlace aunque acabaron borrando el contenido por la burrada tan gorda que defendían, prometo que era mucho peor que lo de la imagen). Aunque podría llegar a entender que trabajes así si es tu primer día en una transformación Agile (y no estás siguiendo mis consejos), debes saber que haciendo esa mezcla, vas a tener las desventajas de los dos mundos (cascada y Agile) y sin ninguna ventaja reseñable ni a corto ni a largo plazo. Así que es muy difícil tomarse en serio a quien claramente demuestra su incompetencia (por desconocimiento, por mantener el status quo...) y nos enseña como caso ideal lo que claramente es una crónica de una muerte anunciada y motivo por el que Agile nunca funcionará en tu organización. Y de repente, para empezar el año, noticia bomba: El Project Management Institute y la Agile Alliance han anunciado el día 3 que se asocian: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ Esta noticia ha dejado perplejo a todo el mundo dentro de la Agilidad. ¿Cómo es posible que dos formas tan antagónicas de entender la gestión de proyectos se unan? De una parte una organización sin ánimo de lucro que busca promover y compartir la filosofía Agile y por otra una gran empresa que busca mantener su hegemonía como único referente en la gestión de proyectos. Pues para entenderlo basta con leer la letra pequeña: "As part of this process, Teresa Foster, Managing Director of Agile Alliance, and her team will transfer to PMI" Esto es como cuando una gran empresa energética recibe una ayuda del gobierno que nadie entiende y que perjudica al resto de ciudadanos, y luego vemos que los ministros que la aprobaron, casualmente pasan a la empresa como asesores... pues algo parecido. Por un lado, la Agile Alliance será subvencionada por la mayor empresa en el mundo de certificaciones de Project Management, y el PMI, que ya vendía certificaciones Agile, ahora dirá que su contenido es bueno porque viene avalado por la Agile Alliance por lo que venderá más; y todo ello mezclado con esas "puertas giratorias" donde los que aprueban la colaboración se llevarán "su comisión". Así que, al final, es el dinero el que nos ha llevado a esto. ¿Mi opinión? Yo me mantengo receloso de esta colaboración. El cambio que tendría que dar el PMI para moverse en la mentalidad Agile tendría que ser tan grande que, casi casi habría que refundarlo. También creo que sus certificaciones de Project Manager van a seguir defendiendo esa forma de trabajo predictivo que funciona, sí, pero sólo en entornos muy simples. Hoy en día, hay muchas empresas certificadoras sobre Agile en general (y Scrum en particular) que, con mayor o menor prestigio hacen una defensa de esta forma de trabajar mucho más óptima (y coherente), por lo que yo no me iría a obtener una validación profesional justo a las antípodas de esta forma de trabajar. Si quieres validar tu carrera como Project Manager tradicional, ve al PMI. Si lo que quieres es validar tu evolución en Agile (y Scrum), que es lo que ahora más demanda el mercado, mi primera opción sería el PSM I de scrum.org (que puedes conseguir con mis cursos de Scrum ), siendo igual de válidas para la mayoría de las ofertas de trabajo hacerlo con EuropeanScrum o CertJoin (ambas también se pueden conseguir con mis formaciones ) o incluso Scrum Manager, Scrum Alliance y otras certificadoras. ¿Quién sabe? Igual, como he visto bromear en algún foro sobre este tema, dentro de poco nos encontramos con que el PMI ha abierto la certificación de "Agile Project Manager" o alguna aberración similar. Habrá que estar atento. ¿Y tú qué opinas sobre esto?