• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

scrum

Las novedades de la guía de Scrum 2020

Durante el año pasado, en Scrum.org trabajamos junto con los creadores de Scrum, Jeff Sutherland y Ken Schwaber, así como Scrum Alliance y Scrum Inc. en una actualización de la guía de Scrum.
​
Aunque estaba previsto que se anunciara en Primavera, la pandemia provocada por el COVID-19 hizo que se pospusiera el anuncio de la nueva guía, que no se había actualizado desde 2017.

En este post repaso la evolución de Scrum y su guía a lo largo de este tiempo, para sentar las bases de los próximos cambios que vendrán en breve.

Pulsa aquí si quieres leer la nueva guía

Scrum, quién te ha visto y quién te ve

En Noviembre, Scrum cumplió 25 años desde que se anunció en la OOPSLA en el año 1995. Y durante estos últimos 25 años, Scrum ha cambiado mucho.
​
La primera vez que llegó a mis manos un manual de la “Metodología SCRUM”, tenía 160 páginas que describían detalladamente todas las mecánicas, roles y artefactos de lo que entonces era una metodología, no un marco de trabajo. Varias decenas estaban orientadas a explicar en profundidad cómo hacer estimaciones.
​
Por aquel entonces, lo único que necesitabas para ser Scrum Master era el manual, valor y mucha paciencia para aplicar todo aquello en un equipo.
​
Sin embargo, conforme pasó el tiempo y más organizaciones fueron adoptando Scrum, se hizo evidente que era imposible describir todas las posibles situaciones a las que un equipo usando Scrum podían enfrentarse.
​
Para entonces, ya habían pasado más de cinco años desde la edición de aquel pesado manual de 160 páginas y se había producido una explosión de personas que usaban Scrum junto con otros métodos, como XP.
​
Así, surgió la iniciativa de los autores para producir una guía más ligera, más enfocada en los aspectos clave y menos en los superficiales, que fuera una referencia a la que acudir ante la miríada de versiones sobre los que ocurría en Scrum, fuertemente avivadas por la explosión de formadores y formadoras que habían aprendido Scrum y lo enseñaban a través de sus propias experiencias.
​
Así, en 2010, nació la guía oficial de Scrum.

2010 – La primera guía oficial de Scrum

En la versión 1.0, además de la sustancial reducción de literatura, se hacía referencia por primera vez a Scrum como un “marco de trabajo” en lugar de una metodología.
​
El cambio no es gratuito. Los fans de las metodologías exigían una explicación minuciosa de cada detalle de las partes que gobernaban Scrum, llevando habitualmente a reducciones ad absurdum.
​
Cambiando la palabra metodología por marco de trabajo se expresaba que Scrum, de manera efectiva, es una herramienta que puede ser usada de diferentes maneras, y que es responsabilidad del que la usa conocerla y adaptarla a su realidad -o viceversa-.
​
En esta versión se hace referencia a la metáfora de los cerdos y las gallinas, a un release planning meeting y como artefactos obligatorios se listan el release burndown y el Sprint Burndown.
​
Quizás una de las referencias más interesantes sea, por primera vez, la de undone work o trabajo no finalizado. Algo que a los que llevábamos tiempo practicando Scrum nos surgía muy a menudo y para lo que no había una solución clara.

2011 – Definición de Scrum, Grooming y descripción de los Roles

Las dos grandes cambios de la primera gran revisión, en Julio de 2011, fueron definir Scrum como un framework en el que se lidia con problemas complejos adaptativos para construir productos del mayor valor posible y la adición del Grooming para preparar historias de usuario.
​
De nuevo, un pequeño cambio de lenguaje como es el uso de “producto” en lugar de “proyecto”, supone un cambio sustancial en la manera de usar Scrum. Marca la dirección de los siguientes años en Scrum, que donde realmente aporta valor es ayudando a resolver la incertidumbre del desarrollo de productos, más que a ayudar al cumplimiento de fechas, presupuestos y alcance de los proyectos.
​
El Grooming deja de ser una sugerencia para convertirse en una práctica para hacer Scrum y el Sprint Plan deja de ser un compromiso para convertirse en una previsión.

También se pone énfasis en realizar una descripción de qué hacen los roles en Scrum. El Scrum Master aparece como ScrumMaster -lo cual tenía poco sentido y se elimina poco después- y se eliminan la referencia a Cerdos y Gallinas, aunque ésta tardará años en salir del ideario de los practicantes de Scrum.
​
Por último, en Octubre de ese mismo año se produce un cambio menor orientado a relajar el foco en las reglas de Scrum.

2013 – Las tres preguntas en la Daily Scrum y el foco en el Sprint Goal

En la versión que se publicó en Julio de 2013 se pone el foco en el Sprint Goal. Muchos de los equipos que utilizaban Scrum nos estaban viendo mejoras sustanciales porque habían convertido al equipo Scrum en una caja negra que ingería requerimientos y digería código, lo que no estaba de ningún modo relacionado con la capacidad de aportar valor a la organización de los equipos que estaban utilizando Scrum.
​
Así, la palabra valor toma mucha relevancia a lo largo de toda esta iteración. Además se añade una sección en cómo los artefactos de Scrum facilitan la transparencia. De nuevo, se pone el foco en el control empírico de procesos como la base de Scrum
​
De nuevo, se reduce el lenguaje de la guía y se introducen cambios sutiles. El más prominente es el cambio de las preguntas del Daily Scrum: ¿Qué hiciste ayer? a ¿Qué hiciste ayer para ayudar a conseguir el Sprint Goal?.

2016 – Los valores de Scrum

Tras la desaparición en 2011 del commitment del Sprint, se debatió mucho sobre la necesidad de trabajar con equipos comprometidos, y el uso de la palabra previsión podía dar lugar a pensar que cumplir con una entrega de valor continua es algo opcional. Eso se arregla en la versión de 2016.
​
Además, para que funcione el control empírico de procesos -Transparencia, Inspección y Adaptación-, la transparencia es condición necesaria. Si no, no puede haber inspección y adaptación
​
Sin embargo, muchos practicantes de Scrum observaban cómo los equipos, más veces que menos, carecen de transparencia y profesionalidad.

Por primera vez, la conversación se dirige hacia los valores que tienen que tener estos equipos y no hacia las skills o conocimientos de los mismos.


Así, se introducen el compromiso, la apertura, el foco, el respecto y el coraje. Son descritos como un sustrato sobre el que trabajar para hacer que Scrum tenga éxito dentro de una organización.

Esto, además, proporciona unos principios guía para los Scrum Masters con los que poder dirigir la evolución cultural que Scrum requiere para proporcionar los máximos resultados.

2017 – Las preguntas en el Daily Scrum son optativas y los usos de Scrum

En la última versión publicada por primera vez se reconoce que las preguntas en el Daily Scrum son optativas y solamente una manera de dirigir el evento. Además, se relajan otra serie de reglas y se eliminan prácticas, para dejar los conceptos clave más a la vista.
​
También se introdujo una sección sobre los usos de Scrum, para reconocer que es algo que ha evolucionado más allá de los equipos de tecnología. También se hizo menos dependiente de la palabra Software, ya que hay multitud de equipos no relacionados con la tecnología usando Scrum en todo el mundo.
​
Además se incluyen multitud de pequeños cambios de lenguaje para hacerlo más claro.

2020 – Autogestión, Product Goal y Scrum más allá del Software

La última versión de la guía de Scrum continua con los cambios orientados a hacer Scrum agnóstico y a reconocer que se usa en muchas industrias más allá del desarrollo de Software.

Por eso se ha trabajado mucho en eliminar no sólo la terminología relacionada sino el trasfondo de desarrollo de productos digitales que hay de fondo. En esto entraré a fondo en un próximo post.

Además se ha puesto el acento en producto, producto y más producto. Desde la guía del 2013, la evolución ha sido principalmente a intentar alejar Scrum de la gestión de proyectos, que por su naturaleza de tiempo, coste y alcance cerrados no aprovechan la principal ventaja de Scrum, la capacidad de adaptación a la incertidumbre y la entrega continua de valor.

Entre los cambios, hay tres muy importantes.

La introducción del Product Goal

La meta del Product Goal es servir de guía para entender como los esfuerzos de cada Sprint van dirigidos a un objetivo de negocio concreto. El Product Goal habitualmente consistirá en un gran objetivo de negocio a ser conseguido a lo largo de uno o múltiples Sprint.

Para situarnos en el lugar correcto, pensemos en el Product Goal como releases de nueva funcionalidad. Los equipos de desarrollo trabajan consiguiendo alcanzar Sprint Goals y una vez que se cumple el Product Goal, se pasa al siguiente.

De hecho, es tan importante que se ha ligado la propia existencia del Product Backlog a la existencia del Product Goal. Ahora, en el Sprint Planning, el equipo Scrum tiene que desarrollar un Sprint Goal que sirva de paraguas para el trabajo desarrollado durante el Sprint y que además esté asociado al Product Goal.

El Product Goal es, además, una medida de progreso que la organización puede valorar a la hora de medir el valor generado.

Equipos autogestionados

Durante muchos años se ha debatido sobre el poder de la auto organización en Scrum. Es un tema recurrente en la mayoría de los foros, pero lamentablemente hay que reconocer que aunque el término es poderoso, se habla más de él por su ausencia que por su presencia.

La realidad es que la mayoría de los equipos Scrum no tienen capacidad de organización, simplemente porque las organizaciones no dejan espacio para que esta auto organización ocurra.

Si permitimos a los equipos auto organizarse pero decidimos sobre salarios, incentivos, horas de trabajo, herramientas, políticas de vacaciones, organización del desarrollo de producto y hasta en qué mesa pueden sentarse, ¿Que nos queda para organizar nosotros? ¿La retrospectiva? Y muchas veces ni siquiera eso.

Sutherland y Schwaber han querido dejar esto claro en la nueva guía, donde ahora se puede leer que el equipo Scrum se autogestiona.

De hecho, ya no diferencia entre Scrum Team y Development Team. Ahora el equipo Scrum es UN sólo equipo. Incluso deja entrever que el Scrum Master o el Product Owner tienen que sentarse a trabajar en producto si es necesario.

Incrementos útiles y de valor

Por último, el cambio que a mi más me ha gustado ha sido con respecto al incremento. En guías anteriores se hablaba de incrementos potencialmente entregables. Eso daba lugar a sesudos debates en torno a qué era potencialmente entregable. ¿Es en producción? ¿En preproducción? ¿En postproducción? ¿Pri, pra, pre, pro o pra?

En resumen: En todos sitios menos en las manos del usuario.

Con la nueva guía queda claro que los incrementos tienen que ser útiles y de valor. ¿Qué significa esto? Pues que tiene que estar en manos de un usuario. Que tienen que ser útiles para el usuario, y que además tienen que generar valor y medirlo.

Esto supone un salto de calidad grande sobre lo que teníamos anteriormente, que era un lenguaje vago que la mayoría de las veces conducía a una discusión sobre que significaba potencialmente entregable en lugar de trabajar para hacerle ganar a la organización.

Aunque existen más cambios, estos son los que más poderosos me han parecido. ¿Y a ti? ¿Qué cambios de la guía te han gustado más? Puedes dejárnoslo en los comentarios.

5 argumentos en contra de usar Scrum

Durante los últimos meses he observado un cierto encarnizamiento en torno al debate sempiterno de las metodologías ágiles y en especial de Scrum del que he preferido mantenerme a distancia.

Este tipo de debates no es nuevo y creo que cada dos o tres años experimentan un renacimiento a causa de la decepción que muchas personas experimentan con los métodos ágiles.
​
El objetivo del presente artículo hoy es dar contexto a los argumentos en contra de Scrum, en un intento de intentar ayudar a entender qué es y qué no es.

Me he centrado en cinco: La excelencia técnica, el rol del Scrum Master, el intrusismo, la mercantilización de las certificaciones y la muerte de Scrum.

Scrum no promueve la excelencia técnica.

Muy cierto. Ningún equipo de desarrollo de Software que hiciera una basura de producto con clases de mil líneas, acomplamiento extremo, spaghetti code y cuyo concepto de test es “funciona en mi máquina”, tras aplicar Scrum, han conseguido ninguna mejora.
​
Es más, muchos de ellos, debido a la presión inherente al proceso de Scrum, han terminado haciendo cosas incluso peores, fruto de una falta absoluta de orientación a producto y una Definition of Done.
​
Porque puedes coger cualquier cosa en este mundo, y de la forma más amateur del mundo, destrozarla y decir que no promueve lo que tu quieres que promueva.
​
Y eso está bien, porque Scrum no promueve la excelencia técnica. Son las personas que hacen Scrum las que tienen que promover la excelencia técnica. En concreto el Equipo de Desarrollo (Dev Team).

No concibo trabajar en 2020 con un equipo que no entienda cómo escribir buenas Historias de Usuario ayuda a dirigir una arquitectura hexagonal u onion. Tampoco que no entendamos las bondades que aporta reducir los ciclos de feedback a través del uso de herramientas de integración y despliegue continuo como Azure. O del uso de telemetría para identificar quick wins y el impacto que el software que escribimos tiene en el valor que nuestros usuarios perciben.

Azure application insights permite integrar telemetría de la aplicación directamente en Visual Studio

Que Scrum no hable específicamente de excelencia técnica no significa que Scrum excluya la excelencia técnica.

Significa que es un framework ligero, usado en multitud de industrias y sectores en todo el mundo; como tal, es imposible describir todas las opciones que existen para mejorar la excelencia técnica sin caer en el error de intentar hacer el diccionario Larousse del Scrum: Una iniciativa noble, épica pero inútil.

​
El Scrum Master es un rol, no es una persona.

Totalmente cierto. Y todavía no he encontrado quien diga lo contrario. Sin embargo, es habitual que dada la naturaleza física del mundo, el rol del Scrum Master termine realizándolo una persona y no el espíritu santo.

Es más, debido al caos que suele generar un cambio de contexto continuo en caso de que una persona comparta varios roles, muchas de esas personas querrán dedicarle tiempo completo al rol, mientras que otras no.

El tiempo que le dediquen afectará a la efectividad del rol.
​
También afectará a la efectividad del rol la capacidad y el conocimiento que la persona o personas que ejerzan el rol tengan sobre Scrum y sus posibles consecuencias o ramificaciones.

Si su exposición a Scrum está limitada al popular episodio: “Peppa Pig y su familia desarrollan Software usando Scrum” es posible que su capacidad de entendimiento esté limitada por una falta de conocimiento sobre las consecuencias de hacer Scrum.
​
E incluso así, se puede hacer Scrum.

Igual no es un Scrum maravilloso que además cae en los problemas expuestos en el punto anterior pero la naturaleza de Scrum, que es ser libre para ser usado por quien quiera, permite usarlo.

Los Scrum Masters y Product Owners no han programado nunca. Son unos intrusos.

​
​Bingo, otra en la frente. Ahora mismo hay muchas personas ejerciendo el rol de Scrum Master, Product Owner, enseñando Scrum y certificando gente que no tienen ni idea de programar.

Es más, hay organizaciones y partes de organizaciones con cientos y miles de personas que no producen software utilizando Scrum.

E incluso hay personas que utilizan Scrum o partes de Scrum en cosas que no tienen nada que ver con la Tecnología.

Este es precisamente uno de los motivos por los que Scrum es tan popular. Porque no tiene una legión de policías diciéndote lo que no puedes hacer sino que son unas reglas de juego que puedes utilizar para múltiples cosas.
​
Y no sólo hay personas haciendo Scrum en equipos de tecnología que no saben programar. Hay CTOs, CIOs, Development Managers, Arquitectos de Software e incluso programadores que no tienen ni idea de programar.
​
Por un lado, yo nunca contrataría a un Scrum Master para trabajar con un equipo de tecnología que no tiene un conocimiento mínimo de Software. Y si ese es el caso, le invitaría a hacer al menos dos o tres cursos de los miles gratuitos que hay en línea para que aprendiera qué es programar, para qué sirve el control de versiones o por qué una arquitectura monolítica puede superar en beneficios a una de microservicios en equipos pequeños y cross-funcionales.
​
Por otro, los técnicos tendemos a pensar que el valor de nuestro Software reside en el código. Y el ciclo de vida del Software es mucho más que eso. Podemos hacer un código maravilloso y ofrecer cero valor a nadie. En la mayoría de los casos hacen falta personas de producto, de proceso, de operaciones, de administración de sistemas, de marketing, de ventas y de administración para ofrecerle valor a alguien.
​
Los programadores hemos de dejar de estar enamorados del código que escribimos y empezar a enamorarnos del valor que el código que escribimos crea.

​
El mercado de Scrum y las metodologías ágiles se ha mercantilizado. Las certificaciones no valen nada.

Absolutamente cierto. En la fiebre del oro del lejano Oeste quienes tenían ganancia asegurada no eran los buscadores de oro, sino los vendedores de palas.
​
Lo cual no quiere decir que no hubiera buscadores de oro que no se hicieran tremendamente ricos.
​
Hoy en día hay compañías completamente alejadas de estos debates que están usando Scrum para ser tremendamente ágiles: competitivos, adaptativos e innovadores.
​
​Durante una reunión en 2015 a la que asistí en Boston, cuna de Scrum, descubrí que existe un acuerdo total entre las compañías certificadoras para identificar a individuos influenciables y a través de campañas dirigidas de Facebook Ads, anuncios en conferencias ágiles y una campaña orquestada por redes sociales, fabricantes de post-its, rotuladores y el lobby de las jirafas, para certificarlos a todos. Todo se hizo con conocimiento del club Bilderberg y la aprobación del Conde Drácula y Don Pimpón.

A pesar de que alguien haya leído el párrafo anterior y le haya dado un vuelco al corazón – ¡Lo sabía! – es ironía. Lo cual no cambia el hecho de que Scrum se haya mercantilizado.
​
No hay más que crear una sensación de demanda para dirigir un comportamiento.

No es nuevo.

En 1775 se hizo en Francia para fomentar el consumo de la patata, que se veía como un alimento para el ganado.
​
Las compañías, sobre todo en el último lustro, han demandado más profesionales con conocimientos de Agile. Y Agile se ha asociado tradicionalmente a Scrum. Es por ello que han surgido cientos o miles de compañías dedicadas a la fabricación en masa de certificaciones ágiles cuyo marketing es cuestionable o puede llevar a engaño.
​
Y hoy en día, tenemos un maravilloso y variado mercado de limones.

No es algo exclusivo de Agile, es algo inherente a cualquier sector emergente en cualquier industria en cualquier país.

Desde las mascarillas para el COVID a los másteres que no son másteres.
​
Un momento. ¿No soy yo, Jerónimo Palacios, parte de esa mercantilización? Por supuesto que sí, en la medida en que todo el que tiene que ver con las certificaciones cae dentro del mismo saco.

Sin embargo, creo que dado el posicionamiento que hemos tenido, intentando mantener la calidad -y por ende el precio- por encima de la media, centrándonos en hacer de la formación -y no de la certificación- una palanca de transformación en las organizaciones con las que he trabajado y aportando experiencia haciéndolo.
​
Como ser humano es imposible no caer en contradicciones. Estoy seguro de que he formado personas que utilizan Scrum como un báculo con el que golpear a otros. Personas que han terminado formando parte de equipos de Software como Scrum Masters sin saber de tecnología.

Siempre he creído que lo importante de mi trabajo es explicar las cosas, la importancia que tiene la tecnología y las personas en torno al valor que creamos, pero siempre lo he hecho desde la perspectiva de Scrum.
​
Además, no es ningún secreto que puedes ir a Scrum.org y pasar la certificación PSM sin necesidad de asistir a nuestra clase ni a la de ningún Professional Scrum Trainer. Es más, con un poco de google fu puedes buscar archivos con cientos de preguntas por la red que te ayudarán a pasar la certificación sin saber siquiera cuantas preguntas está obligado a responder el Team todos los días al Scrum Manager.
​
Y eso hace que la certificación no valga nada. Porque la certificación certifica -¡Sorpresa!- que en un momento dado has pasado un examen de conocimiento básico sobre Scrum. Lo que vale es el conocimiento, ideas, habilidades y capacidades de la persona que ostenta esa certificación de ejercer ese rol en una organización.


Scrum ha muerto.

Toda la razón. Llevo viendo morir a Scrum y Agile desde que empecé a aplicar técnicas de desarrollo ágil y XP en 2007, cuando me subí al carro de Ruby on Rails. Hay pocas cosas tan viejas en el desarrollo de Software moderno como Scrum, que ya tiene 25 años.
​
Dentro de unos años Scrum no existirá. Y con ello habrá desaparecido la mercantilización, la falta de excelencia técnica y el rol del Scrum Master.

Ojalá el motivo de la desaparición de Scrum tiene como motivo que las organizaciones que desarrollan productos complejos han entendido que todas las cosas que promueve Scrum, incluyendo la agilidad de negocio, forman parte de su ADN, y por tanto no tienen que recurrir a ningún framework, método, certificación o bala de plata para mantenerse competitivas.

Compromiso y Scrum, una guía para tomar decisiones

En ocasiones, entender el funcionamiento de los compromisos en Scrum es difícil dada la diferencia de comprensión sobre qué es un compromiso y los conceptos de simetría y asimetría en el mismo. Veámoslo con una pequeña historia.

María quiere casarse con su pareja. Llevan siete años juntas, pero han tenido algunas dificultades.

A pesar de estar dentro de una relación, María se siente tentada a abrirse a otras personas y a otras experiencias.

Esto no quiere decir que no la quiera, todo lo contrario.

María entiende las relaciones como algo abierto, mientras que su pareja lo entiende como algo cerrado.

Este es un caso clásico de simetría y asimetría del compromiso.

Mientras que la pareja de María entiende que cuando se está en una relación de pareja el compromiso de fidelidad es mutuo (simétrico, igual para los dos actores), María entiende que no tiene por qué serlo (asimétrico, distinto para los dos actores).

En ocasiones tampoco existe transparencia acerca del compromiso, así que cada uno de los actores asume que su manera de entender el compromiso es la bueno. Es la vara de medir que utilizará para atizar al otro.

Esto dará lugar a problemas en la relación de María y su pareja en el futuro.

Compromiso en El Mundo Real™

¿Y en las organizaciones? Ocurre igual.

Mientras que algunos jefes les piden a sus subalternos cosas en las que ellos no creen, los subalternos piensan que en la misma posición ellos lo harían de forma diferente.

Error.

El problema de nuevo es la simetría del compromiso.

Cuando el departamento de gestión de calidad encarga un nuevo proyecto y pide un alcance, tiempo y coste cerrado, el departamento de Software entiende que las estimaciones y compromisos estarán atados a que no haya cambios.

Sin embargo no es así.

Tanto por un lado como por el otro es imposible tener un compromiso simétrico.

Calidad querrá que Software se atenga a su compromiso mientras ellos no respetan el su parte del trato y Software luchará para que haya simetría de nuevo, indicando que es imposible mantener el compromiso inicial cuando se han cambiado las reglas del juego a medio camino.

Y al igual que en la relación de María, esto genera problemas continuos en las organizaciones con las que trabajamos.

¿Y cual es la solución? No se trata de establecer procesos pesados que definan el compromiso para siempre, se trata de asegurarse de que cuando las reglas cambian, todos los implicados están de acuerdo con los cambios y aceptan que los compromisos iniciales quedan invalidados de acuerdo a la nueva situación. Esto es la capacidad de adaptarse a nuevas situaciones.

La principal ventaja de la agilidad.

Para poder mejorar la simetría, lo primero es establecer un “punto de compromiso”, dentro del marco en el que trabajamos, que obviamente es uno en el que se acepta que los cambios pueden surgir. En este punto de compromiso, se realinean expectativas y se hace transparente hasta donde se está dispuesto a llegar.

Compromiso en Scrum

En Scrum, esto ocurre durante el Sprint Planning. Los Sprints en Scrum permiten dar flexibilidad al cliente y constancia al equipo. De esta manera, se fija un Sprint Goal (simétrico, no cambia para el Development Team y para el Product Owner) y un Forecast o previsión (asimétrico, puede cambiar en función de las necesidades que surjan).

Este proceso se hace transparente a través del Sprint Backlog, que junto el Sprint Goal y el Forecast o previsión para el Sprint, nos ayudan a definir una guía sobre la que trabajar durante el próximo mes -o menos-.

En el método Kanban ocurre de forma similar. Mientras que los tickets se encuentran a la izquierda del punto de commitment (normalmente una columna llamada Next, que se elige durante el Replenishment), son solamente opciones. Los peticionarios pueden pedir pero hasta que los tickets no entran dentro del sistema. No se establece la relación de simetría o asimetría.

Una vez que pasan este punto de no retorno, se convierte en simétrico: ahora hay un acuerdo explícito y transparente. Hay que evitar abortar a toda costa cosas que ya están dentro de nuestro sistema, porque tenemos un compromiso de entrega.

¿Qué ocurre cuando el equipo no es capaz de responder a toda la demanda?

Entonces lo protegemos y ordenamos la demanda por prioridad, dejando que sea el equipo el que haga tantas cosas como puede hacer. De esa manera maximizamos la eficacia de ese equipo.

Si además limitamos la cantidad de trabajo en curso, usando límites WIP, conseguiremos que el flujo de entrega sea más estable y de esa manera, responder adecuadamente a un compromiso simétrico.

Tampoco es decir a todo que sí

Es evidente que decir a todo que sí, o su variante “No puedo decir que no” es una receta desastrosa para mantener una simetría del compromiso. Si decimos a todo que sí, o no podemos negarnos a nada, nuestra capacidad de mantener un compromiso estable de entrega de valor es completamente asimétrico.

Nuestro compromiso no vale nada.

No tenemos control sobre lo que podemos comprometer. Evidentemente eso afecta a la capacidad de adaptarse a nuevas situaciones en nuestra equipo u organización.

Precisamente saber cual es la capacidad real de compromiso y esforzarse por fomentar una simetría a través de la autonomía en la toma de decisiones es clave para conseguir que Agile nos permita acelerar y mejorar los resultados de nuestro negocio.

Hacer lo contrario, es decir, meter todo lo que se puede a ver si sale algo. Además poner un carril de urgentes -normalmente llamado Scrumban– es una receta para el desastre. El que más comprometido está es el más débil de la relación.

Volviendo al ejemplo de María, sería como si esta hablara a su pareja de las bondades de la fidelidad mientras disfruta de tres amantes distintos. No sería lo mejor para nadie, ¿No?

Professional Scrum with Kanban – Virtual Edition


Virtual Evento Virtual Evento

23 noviembre, 2020 a las 3:00 pm al 25 noviembre, 2020 a las 8:00 pm

Professional Scrum with Kanban

Professional Scrum with Kanban™ (PSK) es un curso de 2 Dias de duración que enseña como aplicar prácticas de Kanban a participantes experimentados con Scrum. A través de teoría, casos y ejercicios, los alumnos entienden la importancia de la transparencia y el flujo como parte del uso de Scrum.

Scrum es el standard de facto para equipos Ágiles. Para funcionar, necesita usarse al completo y es un gran contenedor para otras técnicas y prácticas. Los equipos Scrum siguen mejorando como trabajan, basándose en lo que aprenden e inspeccionando y adaptando frecuentemente.

Entradas

Los números presentados abajo incluyen entradas a este evento que ya están en tu carrito. Al pulsar “Adquirir Entradas” podrás editar los datos de los asistentes, así como o cambiar la cantidad de entradas.
Entradas ya no están disponibles

¿Qué voy a aprender?

En esta clase, los alumnos aprenden como equipos Scrum pueden introducir prácticas adicionales de Kanban mientras continúan trabajando de la misma forma que con Scrum, sin cambiarlo.

Scrum.org y el equipo de Professional Scrum Trainers han estado trabajando con Daniel Vacanti para diseñar este curso. En 2007, Daniel ayudó a dar forma al método Kanban para trabajo basado en el conocimiento. Gestionó la primera implementación de Kanban ese año y ha seguido trabajando para introducir Kanban como trainer, coach, consultor y mentor desde entonces.

Objetivos del curso

Conseguir entender como funciona el Flow dentro del contexto de Scrum

Exposición a prácticas de Kanban que los equipos de Scrum pueden adoptar para ayudar a mejorar su efectividad y eficiencia

Entender como usar de manera efectiva estas prácticas sin cambiar Scrum

Aprender un enfoque práctico para mejorar la transparencia y la visibilidad del trabajo

¿Para quién es este curso?

El curso Professional Scrum with Kanban™ es para cualquier que use Scrum. Es particularmente beneficioso para aquellas personas dentro de una organización que utilizan Scrum para entregar productos, incluyendo Product Owners, miembros del Equipo de Desarrollo y Scrum Masters.

Temas del curso

  • Rompiendo mitos comunes
  • Entendiendo Professional Scrum
  • Teoría de Kanban, principios y prácticas
  • Kanban en la práctica
  • Scrum con Kanban

Certificación Professional Scrum with Kanban

Todos los participantes que completan el curso Professional Scrum with Kanban™ reciben dos intentos para la certificación Professional Scrum with Kanban I (PSK I). Este examen sólamente está disponible para alumnos que participan en la clase actualmente. Si intentas el test y no pasas durante los siguientes 14 días del curso, tienes un siguiente intento sin coste adicional.

Hola, soy Nacho

Professional Scrum Trainer

  • Visit Twitter account (opens in a new tab)
  • Visit YouTube account (opens in a new tab)
  • Visit LinkedIn account (opens in a new tab)
  • Email

Jerónimo Palacios

Edición Virtual

Curso realizado a través de una plataforma virtual para clases en directo. + Google Map
+34 689 399 468
Ver la web Local
995,00€
  • Google Calendar
  • iCalendar
  • Outlook 365
  • Outlook Live

Eventos Relacionados

  • Professional Scrum Master

    20 febrero a las 8:30 am al 21 febrero a las 4:30 pm
  • Professional Scrum Product Owner

    22 febrero a las 8:30 am al 23 febrero a las 4:30 pm
  • Professional Scrum Master II

    6 marzo a las 8:30 am al 7 marzo a las 4:30 pm

Scrum y la Business Agility

Muchas veces se tienen dudas como “Y en Scrum se puede…”, “¿y puedo hacer…?”, “¿y se puede…?”. Parece que Scrum es como un conjuro mágico en el que si solo cambias algunas cositas podría seguir funcionando. Y si en vez de ancas de rana pongo ojos de sapo, ¿funcionará? Scrum está lejos de ser una fórmula mágica que soluciona todos nuestros males. Veamos cómo la Business Agility o Agilidad Empresarial puede ayudarnos con estas cuestiones

¿Qué es la Agilidad Empresarial o Business Agility?

El problema real que encierra esta pregunta es que estamos asumiendo que Scrum es un fin. “¿Se puede hacer esto o lo otro y sigue siendo Scrum?”. Cuando a nadie le debería importar si es Scrum o no. 

El día que un CEO toma la decisión de reservar una buena parte del presupuesto de los siguientes años para comenzar una transformación, no está buscando que los equipos estén haciendo Scrum, Kanban, Product Owners empoderados o equipos auto-organizados. 

Nuestro CEO está buscando la supervivencia de su empresa ganando competitividad e intentando poder luchar de tú a tú algún día con las nativas digitales. Busca alcanzar la Agilidad Empresarial o “Business Agility”:

  • Capacidad de poner en valor rápidamente nuestro desarrollo (fast revenue)
  • Alta gestión de riesgos
  • Poder aprovechar las oportunidades de mercado

Scrum es una herramienta para activar Business Agility en las organizaciones. Lo hace creando al menos un incremento terminado, potencialmente usable, un incremento Done en cada Sprint. De esto va Scrum. No es un fin, es un medio.

Scrum no va de daily, retrospectivas bailando o similares. Va de entregar valor. Scrum nos proporciona elementos: artefactos, eventos y roles, que nos brindan una alta capacidad de inspección, adaptación y transparencia. Los pilares del empirismo. Son las armas que necesitamos para crear incrementos de alto valor y maximizar nuestra capacidad de generar ingresos.

¿Como nos habilita el Incremento “Done” la Agilidad empresarial?

Fast revenue

Los desarrollos de productos se siguen enfocando a proyecto. Primero obtenemos todos los requisitos, creamos un plan para los siguientes meses (o años) y, al final del todo, me voy al mercado a intentar monetizar.

Con el enfoque iterativo incremental que nos propone Scrum y teniendo incrementos terminados, integrados y listos para usarse en cada Sprint, podré ir buscando una version de mi producto que me permita llegar al mercado e ir generando beneficios.

Un ejemplo es el lanzamiento de Amazon Prime Videos. Con poco catalogo, sin soporte para Chromecast o sin aplicaciones nativas para tablets y teléfonos comenzó a poner en valor su nuevo producto lo antes posible.

Alta gestión de riesgos

Podemos hablar de tres grandes riesgos y la manera que tiene Scrum de gestionarlos es resolverlos.

  • Riesgo de mercado: ¿Estoy creando lo que mis usuarios realmente necesitan? Scrum va de crear un incremento y conseguir feedback real para adaptar mis siguientes pasos si es necesario.
  • Riesgo financiero: ¿Esto cuánto me va a costar? Por mucha documentación y planes que hagamos ya sabemos que siempre habrá variables que no conozcamos. E incluso las variables que conocemos tienen baja predictibilidad. La única manera de conocer el coste es realmente empezar a hacerlo y luego intentar obtener predictibilidad basada en datos históricos.
  • Riesgo técnico: ¿Mi idea se puede realizar con las tecnologías que actualmente estoy usando? Una vez más, la única manera de saberlo es empezar a hacerlo e ir obteniendo una nueva versión de mi producto Sprint a Sprint.

Capacidad de aprovechar oportunidades del mercado

Si tienes previsto un desarrollo de más de un año y una oportunidad de mercado llega cuando estás en el sexto mes de trabajo con todo abierto, nada integrado, en definitiva, nada terminado. O Incluso si simplemente has estado documentado lo que vas a hacer los siguientes meses, sumarte a esta nueva ola conlleva muchísimo esfuerzo. Tanto que generalmente se decide dejar pasar o esperar a terminar todo el desarrollo disminuyendo drásticamente tu capacidad de competir. 

Conclusion

Una vez que tenemos claro qué Scrum es un medio para hacer crecer Business Agility en nuestra organización, será fácil respondernos a preguntas “¿en Scrum se puede…?”. Simplemente debemos pensar si al introducir un cambio estoy aumentando o disminuyendo mi Agilidad Empresarial.

¿En Scrum se puede tener dos sprints de desarrollo y luego otro de hardening?

Cuando terminen los sprints de desarrollo:

  • Si viene una oportunidad de mercado…
    • ¿Podré sumarme a ella? No.
    • ¿Alguien me puede asegurar cuándo podré hacerlo? No. Nadie puede asegurar que el hardening vaya a tomar solo un sprint o dos.
  • ¿Puedo poner en el mercado lo que tengo al final del Sprint de desarrollo? No. Adiós al fast revenue.
  • ¿Estamos tomando decisiones del futuro de nuestro producto basándonos en feedback real? No. No lo hemos podido poner en producción por lo que no tenemos ninguna métrica de negocio real. Al no estar nada terminado no tenemos transparencia de la situación del producto, esto nos llevará a discusiones sin fundamento con los Stakeholders en la Sprint Review eliminando nuestra capacidad de adaptación al mercado.

¿En Scrum se puede hacer la Daily Scrum 2 veces por semana?

La Daily Scrum nos permite inspeccionar el avance de nuestro Sprint para alcanzar la Sprint Goal con nuestro Incremento. El Sprint Goal puede representar una hipótesis sobre nuestro producto que negocio quiere comprobar si realmente es lo que quieren los usuarios y si nos va a otorgar el beneficio esperado. Por ejemplo, que mis usuarios van a querer pagar con Paypal. 

La Daily Scrum es una manera de maximizar las posibilidades de que el equipo de desarrollo tenga terminado todo el trabajo relacionado con la Sprint Goal a final del Sprint. Eliminando algunas daily,

¿estoy ayudando a mi Agilidad Empresarial o poniéndola en riesgo?

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Páginas intermedias omitidas …
  • Ir a la página 5
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad