• Saltar a la navegación principal
  • Saltar al contenido principal
  • Saltar a la barra lateral 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 Backlog Management Skills
    • 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

Agile

Agile es un movimiento definido por la publicación del manifiesto ágil o Agile Manifesto, una declaración hecha por 17 críticos con el desarrollo de Software en el año 2001.

Actualmente Agile se ha convertido en uno de los drivers más importantes de la transformación digital y todas las grandes organizaciones del mundo beben de esta filosofía para intentar mantenerse más competitivos, más cercanos al cliente y mejorar su capacidad de innovación.

Las fechas de entrega son sagradas

Hace unos años la CNN estrenó un documental sobre la Cienciología, sus métodos y su historia. Reza Aslan tuvo la oportunidad de hablar con aquellos que en Cienciología se hacen llamar Free Zoners.

Son aquellos que, desencantados con las prácticas de la institución, siguen trabajando para promover las enseñanzas de L. Ron Hubbard desde fuera de la Iglesia.

En su momento, este documental me hizo pensar sobre el mundo de Agile y el mundo del Coaching.

Hace más de 10 años que estudié un master en Coaching de unos dos años de duración en una escuela de prestigio.

Aprendí muchas cosas sobre un grupo de prácticas y técnicas que a lo largo del tiempo, por un lado se han profesionalizado y por otro se han convertido en humo -cualquiera puede hacerlo-.

Hoy el coaching está más que nunca presente en nuestras vidas.

La mayoría de la gente ha escuchado hablar del mismo y muchos han hecho una cursos para aprender técnicas que, en la mayoría de las ocasiones, no tienen nada de ayuda para el acompañado y se basan más en manipulación y violencia emocional.

El Agile Coach

El título de Agile Coach se ha ido forjando con los años para denominar a aquellos que se encargan de promocionar una visión holística de los métodos ágiles más allá de una o dos metodologías.

Personas que, además del conocimiento, poseen una amplia experiencia en la aplicación de las mismas a dominios concretos, como el desarrollo de Software.

De hecho, en muchas organizaciones el Agile Coach se ve como el siguiente paso de evolución de un Scrum Master. El problema, al igual que en el coaching a secas, es que cualquier cosa vale.

En uno de antiguos clientes, tuvieron una experiencia horrible con un Agile Coach que se centró más en hacer de Psicólogo de la organización que en aportar ninguna herramienta que mejorara los procesos de la misma.

¿Por qué?

Porque es más fácil saber de algo de lo que no sabe nadie más y centrar los problemas en que los miembros del equipo de desarrollo sufren de dolor emocional y necesitan terapia de equipo.

Cuando, al cabo del tiempo, este Agile Coach se vio presionado por parte de la organización para saber de qué manera se podían mejorar los productos, la calidad y la entrega, se convirtió en el peor de los déspotas que no tuvo ningún reparo en sacar el látigo y ponerse a motivar programadores.

Hace unos años, David Bonilla decía lo mismo en su Newsletter: La fecha de entrega es sagrada, Agile o no Agile.

Fechas de entrega

No creo que David se considere de esa casta de gente que aprieta a la gente por beneficio propio.

El problema es que, cuando las cosas aprietan, nos quitamos las caretas y vemos lo que realmente es importante para nosotros.

Al fin y al cabo: Si descubrimos a nuestra esposa con otro, vemos nuestra casa en llamas y descubrimos que nos hemos sentado en un avispero, ¿De cual de los problemas nos vamos a ocupar primero?

Los métodos ágiles no tienen mucho que ver con las fechas de entrega.

Cualquier persona que, trabajando en la industria del Software da fechas -sagradas- de entrega a más de dos o tres semanas vista, no solamente es un inconsciente sino que además es poco profesional.

Este es el elefante en la habitación del mundo del desarrollo de Software. No es que nos desviemos un poco, es que en ocasiones el desvío es de órdenes de magnitud. Y esto es debido a la complejidad del mundo del software.

Las fechas de entrega no son un deseo, sino un resultado.

Solamente puedes tenerlas cuando mides la realidad de la empresa. Comprometerte a una fecha de entrega en el mercado del Software es como comprometerte a que mañana Lunes llegarás de Chamartín a Pozuelo de Alarcón en 30 minutos.

Quizás lo consigas o quizás no. Porque no depende de tí, sino de un mundo complejo en el cual tienes poca capacidad de controlar las variables que van a tener efecto en tu resultado.

Scrum no es sino un marco que nos permite eliminar las variables de promesas e inspeccionar y adaptar conforme vamos haciendo. Estoy en Chamartín, el cercanías va retrasado ¿Adapto? ¿Cambio mi plan? No tiene nada que ver con entregar, excepto en que Scrum no tiene sentido si no entregas.

Entregar no es entregar en una fecha. Es ser transparente con tu trabajo. La fecha de entrega no es sagrada. Es el deseo estúpido de un inconsciente.

Las metodologías ágiles y el Agile Coaching tienen que sufrir una reforma, al igual que le está pasando a la Cienciología. Porque si no, Agile terminará teniendo la misma percepción para el público que la Cienciología. La de una secta.

No importa si te sientes identificado con las creencias y valores que promulgan o no. Lo que hay que reformar es que cualquiera no pueda llegar a un cliente y pasar de hablar de terapia de equipo a motivar con el látigo con la excusa de las metodologías ágiles.

Soy consciente de que, al igual que los Free Zoners de los que hablaba al comienzo de la Newsletter, hay muchas personas que se sienten decepcionadas con la manera en que ciertos métodos, metodologías o librerías han tratado a sus creyentes de tal manera que se han convertido a formas de ser y de actuar alternativas.

Para terminar, te dejo un video que publiqué en Youtube aclarando el trabajo que tiene que hacer un Scrum Master.

No es voluntad, es disciplina ¿Como mantener vivas las iniciativas ágiles?

Las organizaciones que comenzaron a invertir en agilidad en 2016 o 2017 se encuentran en una situación en la que o dan a Agile, en su sabor preferido, por muerto, o por el contrario, lo dan por totalmente asimilado en su cultura.

¿Es suficiente con formarse y obtener una certificación en metodologías ágiles como Scrum y Kanban?¿Con repartir títulos y roles como si rompiéramos una piñata? ¿Qué más se necesita para mantener la agilidad en la empresa?

Hace algunos años los gimnasios de cuota anual se volvieron muy populares: el usuario pagaba una cuota, en muchos casos desorbitada, a principios de año con la esperanza de que ese dispendio les animaría a mantenerse suficientemente culpables para seguir asistiendo durante el resto del año.

Nada más alejado de la realidad.

Formarse no es suficiente

Si continuamos con la analogía deportiva, formarse -y obtener una certificación en su caso- no es más que el equivalente que saber como funciona la maquinaria de nuestro gimnasio o cual es la dinámica de nuestra actividad deportiva.

La certificación es tener el material adecuado para poder realizar el trabajo. Por supuesto que para practicar la mayoría de los deportes no necesitamos de un material extremadamente caro. Podemos salir a correr con unas zapatillas viejas, un bañador y una camiseta de la Caja Rural de nuestro pueblo.

Sin embargo, en cuanto avancemos seremos conscientes de las limitaciones de nuestro material.

Por otro lado el hábito no hace al monje, o dicho de otro modo, tener una certificación solo garantiza que en un determinado momento teníamos los conocimientos que nos habilitaban para pasar un examen objetivo.

En muchos casos, como ocurre en los cursos de la Kanban University, ni siquiera es necesario realizar un examen que valide nuestros conocimientos. La asistencia a uno de los cursos es la única condición necesaria para obtener las credenciales TKP o KMP.

Precisamente se evidencia que la formación y la certificación no es más que material para poder mejorar la agilidad de nuestra organización pero que en ningún caso van a realizar el trabajo por nosotros.

El hábito vence a la motivación

Algo que repito de manera incansable a lo largo de los años es que la mejor manera de entender Scrum es haciendo Scrum. Esto es válido para cualquier cosa que deseemos hacer en nuestra vida.

En Thinking Fast and Slow, Daniel Kahneman habla de los dos cerebros que cohabitan en nosotros: Uno rápido, heredado de una época en la que éramos más animales que personas y nos permite, mediante identificación de patrones, elicitar respuestas rápidas a los estímulos; uno lento, evolucionado como característica de la condición humana, que nos permite inferir y aprender sin experimentar directamente un evento.

Cuanto aprendemos algo nuevo, lo hacemos a través del cerebro lento. Inferimos y construimos en nuestra mente hipótesis que validamos sobre la práctica pero que nos requieren dos cosas: tiempo para decidir nuestra respuesta y energía para procesar esa respuesta.

De la misma manera que si nos encontramos física y mentalmente cansados cualquier trabajo cognitivo va a resultarnos tedioso, difícil e inabarcable -recordemos, necesitamos tiempo y energía para realizar tareas cognitivas complejas-, si nuestra organización se encuentra agotada es imposible que demos respuesta coherente a una nueva forma de trabajar.

El resultado será invariablemente que aprenderemos los nombres, los títulos y los procesos y los adaptaremos a lo que ya hacíamos, los procesos que teníamos aprendidos, los del cerebro rápido.

Iremos al gimnasio, sí, pero no haremos ejercicio.

Es por ello que mantener un hábito o usar una metodología ágil va a requerir necesariamente de crear un espacio para que pueda calar y mostrar resultados.

Orientación a resultados

Por último no hay que perder de vista que cualquier hábito sin un objetivo claro fracasará una vez superado el impulso inicial.

En el caso de Agile, si nos remontamos al origen del manifiesto, el objetivo era hacer una declaración de intenciones de cara a mejorar la forma de desarrollar Software, esto es, generar más valor y mejores productos a través de una serie de principios y valores guía.

Si no tenemos maneras de medir esa mejora es imposible que veamos ninguna evolución más allá de las sensaciones subjetivas que tengamos al respecto. Es por ello que cuando se aborda una iniciativa de agilidad organizacional es fundamental tener claro las métricas que queremos mejorar dentro de la organización.

Hace unos meses participé como keynote speaker en el Tech Management Day y ofrecí una visión sobre como medir en productos digitales que puedes ver en el siguiente video.

Mantener las iniciativas ágiles vivas no es una cuestión de voluntad, sino de disciplina.

Formarse y obtener una certificación en metodologías ágiles puede ser importante, pero no es suficiente para mantener la agilidad a largo plazo.

Asignar responsabilidades y nombrar personas que lleven a cabo las iniciativas tampoco.

Es necesario crear un espacio seguro en el que se fomente la colaboración y la mejora continua y tener claros los objetivos y las métricas de mejora para evaluar si estamos obteniendo los resultados deseados. Con estas prácticas, podremos mantener la agilidad en nuestra empresa y seguir generando valor para nuestros clientes.

5 estrategias para destruir Agile en tu organización

Es oficial: El mundo es Agile.

Viendo que la palabra de moda se menciona en todo tipo de foros y organizaciones, hay que confirmar que todas las previsiones que los más optimistas hacían hace 10 años se han quedado cortas.

Tras observar la evolución, hay que aceptar que lo Agile ha sustituido al Project Management, si no en su totalidad, en un gran número de corporaciones y gobiernos.

Los Project Managers han dejado paso a los Scrum Masters, los Product Owners y hasta a los mismísimos Agile Coaches.

Ahora que todos que somos ágiles y lo hacemos increíblemente bien, es hora de destruirlo.

He recopilado cinco estrategias que las verdaderas organizaciones ágiles nunca pondrían en práctica porque podrían dañar o destruir todo el esfuerzo conseguido.

Estrategia nº 1: Plásmalo todo en un manual del Agile y obliga a todos a que se rijan por él

Elaborar un buen manual de procesos es fundamental para así poder evaluar el cumplimiento Agile de las iniciativas y controlar quién lo hace bien y quién lo hace mal.

Si este manual del Agile además puede indicar un número exacto de minutos para los eventos, con cuántos equipos puede trabajar un Scrum Master y además obliga a documentarlo todo muy bien en JIRA, mejor que mejor.

Al cabo de poco tiempo verás como el objetivo es cumplir y al cabo de unos meses tu organización empezará a sufrir del acartonamiento provocado por la consecución de objetivos de proceso.

Si tu organización es de las que había fomentado autonomía y autogestión en los equipos, asegúrate de especificar una buena matriz RACI para que las personas no tengan duda de que su papel es ser un recurso, una FTE dentro de la organización.

Alternativamente, si quieres evitar este doloroso sufrimiento y la fricción que provoca, investiga técnicas de budgeting y compliance que sean compatibles con equipos autoorganizados orientados a objetivos de negocio.

Estrategia nº 2: Céntrate en certificar a todo el mundo

No importa si los Scrum Masters no han aprendido todavía que su papel no es el de convertir las retrospectivas en fiestas de cumpleaños dónde se hacen collares de macarrones.

Tampoco si los Product Owners nunca han hablado con un cliente de verdad y su Product Backlog es una lista a los Reyes Magos de Oriente.

Lo importante es certificarlos. Mucho.

Aunque no hayan tenido la oportunidad de conocer un entorno donde se practiquen mínimamente los valores de Scrum, asegúrate que tienen el PSM uno, dos, tres y cuatro.

Si se te acaban las ideas, certifícalos en OKRs, en Kanban o en ESS (Estudios del Santo Sudario). Mientras estén bien certificados, cumplirás con los objetivos del establecidos por la organización.

Alternativamente puedes colaborar con las personas de tu organización y dejarles que sean ellos los que decidan como quieren formarse y aprender conforme lo vayan necesitando.

Estrategia nº 3: No formes a nadie

Todo el mundo sabe que Agile se puede aprender leyendo artículos y viendo videos de Youtube igual que se puede construir una iglesia románica.

Si tienes dudas, lo mejor es contratar a un consultor que te dirá cómo hacerlo todo y así los recursos no tendrán que dedicarle tiempo a pensar, que no se les paga para ello.

Si alguien desea formarse, asegúrate que lo hace en su tiempo libre. Tardes y fines de semana es lo mejor.

No les proporciones facilidad ni bolsa de formación. Si les formas, entonces querrán irse a otra empresa a trabajar.

Alternativamente, puedes ayudarles a dirigir sus esfuerzos a aprender como desarrollar mejor su trabajo ya sea con formación, libros o actividades de comunicación dentro de la jornada laboral.

Estrategia nº 4: Mantén múltiples jerarquías dentro de la organización

Una vez que comienzas con una iniciativa de transformación, asegúrate de que las estructuras tradicionales no se modifican. En lugar de eso, convierte a los Scrum Masters y Product Owners en jefes. Si puedes, además, convierte a uno o dos Agile Coaches en los jefes de éstos.

Así conseguirás una nueva y flamante capa de gestión que luchará por el poder con otras capas de gestión a modo de juegos del hambre del parking de la empresa.

Sabrás que has tenido éxito cuando al cabo del tiempo los que están más arriba de la capa de gestión del Agile decidan pelear para ver quién es el jefe supremo. El ganador obtendrá el título de Head of Agile y como recompensa obtendrá los poderes del otro heredando las salas de Mural.

Alternativamente, trabaja en ablandar las jerarquías existentes y potencia las habilidades de resolución de conflictos. Algunas personas no estarán contentas con esta decisión. Esto es bueno, ya que tampoco estarían contentas con las iniciativas Agile.

Estrategia nº 5: No permitas que la gente Agile se salga del Agile

Si escuchas a un Scrum Master decir que hay impedimentos en el delivery que impiden que los equipos sean más ágiles a la hora de entregar, ten miedo.

Si una Product Owner expresa su preocupación en torno a los sistemas de planificación anual, tienes que tomar acción.

Esto es malo.

Los Scrum Masters deberían centrarse en hacer a la gente feliz y los Product Owners en redactar historias de usuario. Tocar las estrategias de delivery o cambiar las formas de estructurar trabajo quedan fuera de su órbita.

Si se da el caso, acúsales de ser fanáticos de Agile y explícales que en tu organización siempre se ha hecho así. Si además puedes referirles la página concreta del manual del Agile donde viene explicado, habrás ganado la partida.

Jaque mate.

Photo by Stephen Radford on Unsplash

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.

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?

  • 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 16
  • Ir a la página siguiente »

Barra lateral principal

Jeronimo Palacios & Associates

Somos una consultora boutique especializada en la creación y desarrollo de productos digitales con un enfasis en metodologías ágiles.

Búsqueda

Cursos oficiales certificados

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