• 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

agilismo

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?

Estimaciones conjuntas en SAFe

Idea inicial que plantea SAFe en la formación

Durante las formaciones de SAFe hay un momento en el cual los equipos deben calcular su capacidad para poderse planificar su carga durante la siguiente iteración.

En la simulación se considera que “Cada miembro del equipo de Desarrollo aporta 8 puntos al equipo por sprint de 2 semanas”. Esto resulta una sorpresa, negativa, para la gente habituada a trabajar con metodologías Agiles y utilizar la herramienta de las estimaciones relativas.

¿8 puntos por persona es poco? ¿o mucho?

Lo importante de este punto no es la cantidad de puntos que aporta cada miembro del equipo, sino una idea mucho más poderosa: las velocidades de los distintos equipos deben tener una referencia común.

El hecho de que todos los equipos que participan en la elaboración de una solución tengan velocidades comparables nos sirve para tener una predictibilidad de una manera sencilla. Ésta es la clave: predictibilidad poder saber si llegamos a la fecha comprometida o cuando habrá nuestro producto MMF (Minimum Marketable Features) estará listo para salir al mercado.

Cuando los equipos están empezando en la adopción Agile, esta propuesta de capacidad para el equipo es adoptada sin ningún problema. Pero ¿qué pasa con los equipos que ya tienen su propia definición de capacidad? ¿Qué sucede con la predictibilidad cuando necesitamos conocer las estimaciones de muchos elementos donde participan varios equipos en su elaboración? Y donde cada uno tienen sus criterios tanto de capacidad como de estimación relativa definidos.

Entender la adopción de SAFe

Aunque pueda ser presentado como un marco de trabajo, SAFe no es exactamente eso. SAFe es una base de conocimiento probado e integrado para el escalado de las prácticas Agile en las empresas. Me gusta presentar SAFe, sobre todo, como una biblioteca de herramientas para escalar la agilidad.

El símil de la biblioteca es muy válido, pues si no tenemos asimilada la mentalidad Agile el uso que le demos a las herramientas quizás no sea el mejor ni nos aporte ningún beneficio. Es como ir a una biblioteca de Francia sin saber francés, no podremos obtener todo el beneficio de aprender todo lo que los libros en francés nos quieren transmitir.

Estimaciones relativas SAFe

Las estimaciones relativas son una herramienta más de esta biblioteca, para equipos con poca experiencia en las metodologías ágiles, la propuesta de SAFe es aceptada como válida.

¿Y qué sucede con equipos más experimentados?

En una ocasión nos encontramos con que la empresa tenia ya una cultura Agile y existían varios equipos ya trabajando cada uno en sus productos que luego se integraban en la solución final.

Cada equipo hacía un producto, y algunos productos los podían hacer entre varios equipos. Las velocidades y estimaciones eran totalmente independientes entre ellos: había equipos que completaban 400 SP (story points o puntos de historia) en un sprint de 2 semanas y otros que hacían 20 SP. Los había cuya capacidad era 100sp, 150, 80, etc.. cada equipo había definido su manera de estimar y esto era perfecto a nivel de equipo. Y no era más eficiente el equipo de velocidad 80 que el de 20, ni que el de 400, era un tema de distintos criterios de valoración.

El reto se planteaba cuando necesitábamos saber si llegábamos a tiempo para entregar el proyecto incluyendo a todos productos. Poder estimar con cierta fiabilidad requería:

  • Descomponer las épicas de programa para identificar los productos relacionados
  • Cada equipo indagaba sobre las historias de usuario que les afectaba de la épica
  • Se estimaban todas las historias de usuario.
  • La estimación por equipo de las historias se agrupaba de manera que teníamos la estimación total de la épica para ese equipo
  • Las estimaciones parciales de las épicas se agregaban para obtener una estimación a nivel programa.

¿Qué sucede si cada equipo tiene su propio criterio?

Como cada equipo tenia su propio criterio se nos plantean varios retos:

  • Necesidad de saber exactamente quien hará cada épica. Había épicas que las podría hacer cualquier equipo y era muy poco flexible definir el responsable al inicio del proyecto. ¿y si luego ese equipo no la implementa? Esto era un gasto de tiempo en la estimación inicial que no servía.
  • Necesidad de ponderar cada una de las estimaciones para cada equipo para poder tener una velocidad combinada que nos permitiera tener predictibilidad. El esfuerzo era grande y resultaba que un equipo en un momento dado decidía cambiar sus referencias y las estimaciones ya no eran válidas, y se tenía que recalcular todas las estimaciones donde participaba ese equipo.
  • La cantidad de tiempo dedicado a las tareas anteriores era muy elevada.

Esta era la situación a la que nos enfrentábamos, necesitábamos tener predictibilidad a un coste inferior.

Se les planteó a los equipos nuestra necesidad y se decidió crear una Task Force con miembros de todos los equipos para definir un criterio de estimación común.

Primera iteración: Definir 1 SP para el tren

Los equipos en SAFe se agrupan por trenes, un tren es un equipo de los equipos que trabajan para un mismo programa. Lo lógico parecía que era probar esta idea en un tren antes de extenderla a toda la organización.

De esta manera nos fuimos reuniendo semanalmente 2 horas para compartir visiones de lo que suponía 1 Story Point para cada equipo.

Finalmente, conseguimos establecer un criterio común para todos de unas historias de usuario tipo que representaban la complejidad de 1SP.

Nos llevó nuestro tiempo, pero ya teníamos una referencia.

Segunda iteración: Definir algunos valores más de referencia (2SP, 5SP y 10SP)

Una vez teníamos definida las características de la Historia de Usuario tipo para todos los equipos del tren, el siguiente reto era definir alguna otra historia de usuario referencia mayor que 1 SP.

Los equipos empezaron a trabajar en la Historia de Usuario tipo para 2sp y empezaron otra vez las dificultades para alcanzar un acuerdo y la cosa se complicó más cuando trataron de definir una historia de 5 sp. En ese momento, la propuesta pasó a ser redefinir la historia de usuario inicial de 1 sp… Volvíamos a estar en el mismo punto que 2 meses antes.

Era momento de pivotar y buscar otro tipo de soluciones.

Tercera iteración: introducción de #NoEstimates

El siguiente experimento era probar de adoptar la idea de #NoEstimates, ya que usaba un elemento de referencia común e indiscutible para todos los equipos: la duración del sprint.

La idea de #NoEstimates se basa en el hecho de que, para tener predictibilidad en la consecución de un objetivo de negocio, no es necesario dedicar una cantidad ingente de tiempo a estimar todos y cada uno de los elementos.

#NoEstimates propone tener como referencia una duración, y que la “estimación” sea comparada sobre si es menor o mayor que el tamaño referencia.

Escogimos como referencia medio sprint, es decir 1 semana. Los equipos solo necesitaban analizar si la historia de usuario se podía hacer en una semana o menos. En caso afirmativo, pasaban al siguiente elemento. En caso negativo, se descomponía el elemento en otros más pequeños y nos repetíamos la pregunta sobre si cabía en medio sprint.

La predictibilidad se obtendría del numero de elementos que se finalizaban por equipo durante un sprint.

De esta manera obtuvimos beneficios casi inmediatos:

  • Los equipos dedicaban menos tiempo al proceso de estimación.
  • Los equipos estaban motivados a estimar, ya no era una tarea tediosa.
  • No hacía falta ponderar las velocidades pues contábamos elementos finalizados.
  • No era necesaria saber de antemano que equipo haría que épica pues al final la diferencia en el desarrollo de los equipos no era significativa.
  • Cambió el ambiente hacía una colaboración mayor entre equipos

No podía existir falta de acuerdo entre los equipos pues medio sprint era lo mismo para todos.

Cuarta iteración:  #NoEstimates a nivel de programa

Viendo el éxito de la adopción de esta práctica a nivel de equipo, nos planteamos los beneficios de escalarla a nivel de programa. Sonaba razonable, si al cliente le entregamos épicas pues porque no estimar directamente a este nivel.

El resultado fue muy satisfactorio, ahora miembros de los diferentes equipos del tren (Dev team y Product Owners) estimaban si las épicas podían hacerse en la mitad de una iteración de PI (program increment o Incremento de Programa). Es decir, la referencia para las épicas era si podían completarse en 6 semanas de trabajo (1 PI = 6 sprints, 1 sprint = 2 semanas).

Llevó un tiempo acostumbrarse a esta nueva escala de comparación, y aun así funcionó muy bien. Los equipos ya no necesitaban dedicar tanto tiempo a estimar, descomponer detalladamente las historias de usuario, sino que había una estimación a más alto nivel.

Como es normal, a este nivel la desviación podría ser mayor, pero al ser el margen (6 semanas) también muy grande quedaba bastante compensado. No hubo apenas épicas con grandes desviaciones de las estimaciones iniciales.

Take aways

De esta experiencia nos podemos llevar varios puntos interesantes:

  • Nueva herramienta para estimar: #NoEstimates
  • Idea clave sobre el aprendizaje: Aprender es un proceso iterativo experimental.
  • Lo importante no son las herramientas, sino el propósito que buscamos alcanzar con ellas.

Agilismo es oportunismo

La semana pasada publiqué un post sobre la duración de los Sprints en LinkedIn que suscitó un cierto debate sobre la idoneidad de DevOps sobre Scrum. Curiosamente, en la lista de trainers de Scrum.org se produjo un debate similar. Martin Hinselwood estaba preparando una presentación para una conferencia y también suscitó la misma discusión.

Ya he hablado sobre DevOps y Scrum en el pasado. Mi opinión es que son complementarias, y mientras que Scrum pone el foco en el ciclo de vida de un producto, DevOps lo pone en todo el pipeline de desarrollo y despliegue, lo que los convierte en aliados.

En este artículo quiero hablar sobre un mito que surgió en la conversación y que he escuchado muchas veces con anterioridad. ¿Supone Scrum hacer las cosas rápido y dejar de lado la seguridad y la calidad?

El cuchillo la mató, señoría

oportunismo del agilizo

El oportunismo del agilismo, un artículo publicado en el blog de Deiser, es el desencadenante de este debate. Cada vez más -especialmente durante los últimos dos años- el número de agilistas que se suben al carro ha crecido exponencialmente. Consultoras, empresas y profesionales que una vez creyeron en algo, ahora creen en todo lo contrario.

Y por ende, al final aquellos que usan Scrum, o Kanban, o DevOps, sufren de ese oportunismo de algunos que nunca entendieron bien que hacían.

Lo que no cuenta el artículo es que todos, alguna vez, fuimos oportunistas. Todos hemos aprendido haciendo camino, equivocándonos y dejando nuestros errores cerrados en el armario. ¿Cómo aprende una persona que solamente ha tenido éxitos en la vida?

El problema de fondo son las víctimas del oportunismo. Los que creyeron los cantos de sirena de aquellos que les prometían lo imposible. Un curso de dos días y una charla a sus empleados que cambiará su empresa. ¿Un curso de Scrum? Lo tengo. ¿Uno de Kanban? Como no. ¿DevOps? Déjeme que lo consulte con nuestro equipo de expertos y se lo dejamos a precio estándar.

El oportunismo de Scrum

Scrum es oportunista. Total y absolutamente. Nos permite hacer adaptaciones continuas y aprovechar la oportunidad que tengamos. En ocasiones en menos de siete días. Muchas organizaciones tienen un problema entendiendo este concepto y yo lo he sufrido personalmente.

En mi época de Product Owner en una empresa de energía, el equipo de desarrollo y yo teníamos verdaderas batallas porque sólo hacíamos lo que era posible en un Sprint. Este Sprint lo dedicaba a una feature enfocada al cliente y el próximo a una mejora del rendimiento de los algoritmos de Machine Learning.

Les costaba entender esto. Siempre hacíamos lo mínimo posible para pasar al siguiente Sprint, lo cual frustraba mucho a los desarrolladores. No podían dedicar dos, tres o cuatro Sprints a lo mismo. Sin embargo, siendo ésta la principal característica de los métodos ágiles… ¡Las organizaciones no la utilizan!

Quieren seguir teniendo planificaciones trimestrales, anuales, quinquenales. No quiere pensar la mejor manera de invertir su dinero cada Sprint, dicen que eso no puede ser posible. Y sí, es posible. Son esas organizaciones que entienden que tienen que aprovechar cada oportunidad las que están ganando la partida del consumidor digital.

El problema está en la palabra. En como la usamos en Castellano. Aquí, oportunidad, bien. Oportunismo, mal. Se usa en sentido peyorativo. Y no tiene por qué serlo. ¿Qué CEO se negaría a tener la oportunidad de aprovechar cada oportunidad antes de que pase?

Calidad, seguridad, NFRs…

Precisamente son las organizaciones más oportunistas las que no se pueden permitir escatimar en rendimiento, calidad y seguridad del Software que construyen. Saben que paso dado no es paso atrás, por tanto implementan pensando en tener una base de usuarios 10 veces mayor, aseguran su código con cientos de tests y tienen los sistemas de integración continua más avanzados entre su competencia. No hay posibilidad de deuda técnica.

Son aquellas organizaciones que quieren planes a cinco años, que no ponen nada frente al cliente hasta que no está aprobado por un comité de cambios, las que no entienden el oportunismo. Rechazan la herramienta más potente puesta a su disposición para poder mantener lo que ya conocen.

El agilismo es oportunismo. En el sentido peyorativo y en el sentido positivo de la afirmación. Así tiene que seguir siéndolo. Un día, algunos locos intentaron aprovechar la situación que la frustración de Prince 2 y PMP dejaban a sus clientes e inventaron esto. Hoy nos toca promover el oportunismo entre nuestros clientes para que entiendan qué es agilidad.

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