• 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

safe

SAFe: Ni tan bueno ni tan malo

Autor: Víctor Fairén

Dentro de la comunidad Agile que conozco encontramos 3 tipos de posturas muy distintas sobre SAFe. Si es realmente Agile o no es Agile, y si sirve o no sirve para nada:

SAFe es el Santo Grial: defensores acérrimos de las bondades y vicisitudes de este marco de trabajo. SAFe es Agile! Sin duda, y sobre todo es el único modo de llevar Agile a las grandes organizaciones.

SAFe es maligno: opositores convencidos que SAFe no tiene nada que ver con Agile. Algunos aluden a que cuando se publicó el “Agile Manifesto” su creador todavía estaba con métodos de trabajo incrementales (que no iterativos).

Todos los puntos de vista son respetables, por supuesto. A veces, estas posturas tan radicales se deben a falta de conocimiento o malas experiencias. Tendremos personas que han visto como las iniciativas Agile fracasaban en su empresa hasta que se usó SAFe como marco de trabajo y entonces empezaron a cambiar cosas. Otros han sufrido como trabajaban en equipos ágiles y cuando la organización ha empezado a usar SAFe todo se ha vuelto procesos estrictos y se trabaja desde una perspectiva de control sobre los equipos. En ambos casos, su opinión puede estar sesgada por su experiencia.

Hay un tercer grupo de personas:

SAFe… depende! SAFe puede ser muy útil para las organizaciones siempre y cuando se utilice bajo una perspectiva Agile. Por suerte este grupo cada vez es más numeroso. De hecho, a pesar de ser formador oficial de SAFe desde 2015 (SPC) me considero en de este grupo y ayudando a los indecisos descubrirlo y a la gente de los dos grupos anteriores a ver la otra cara de la moneda.

Generalmente, las personas tienen directamente la visión de SAFe que es la del propio formador que les ha explicado de que trata SAFe. No es poco habitual, por mala suerte, encontrarme gente que me espeta “SAFe no es para aquí”, “Como PO pierdo toda capacidad de influencia”, “antes era SM y ahora soy un PM venido a menos”. Ayudar a reconducir estas situaciones no es tarea fácil, es todo un reto… ¡y me encanta!

SAFe: pasar de Waterfall a Agile

En ocasiones, he oído que SAFe es la solución para las empresas para pasar de trabajar con modelos tradicionales predictivos a Agile o modelos empíricos. ¡Esto no es cierto! Lo siento no es tan fácil.

SAFe no es un marco “plug and play” donde un día somos waterfall y al siguiente Agile. O bueno, podemos ser un waterfall con elementos Agile pero realmente nada ha cambiado, solo cambios de nombres en los roles, usar post-its y nuevas ceremonias que se añaden a todas las que existían previamente.

Lo cierto es que SAFe nos puede ayudar en el cambio de waterfall a Agile:

SAFe puede ser la palanca para el cambio!

Aquí es donde empieza realmente el cambio, entender su uso como palanca. Y nos servirá para evitar caer en los principales y típicos errores que se dan en las organizaciones cuando usan SAFe:

  • Nuevos roles que se usan para perpetuar la jerarquía existente sin importar las competencias.
  • Reducir costes de ciertos eventos, quitando el potencial que podrían aportar.
  • No considerar los tiempos de coordinación al escalar.
  • Planificar sin considerar la incertidumbre del entorno ni la necesidad de flexibilidad.
  • No considerar las distintas competencias a adoptar en la organización.

Si quieres conocer más sobre SAFe y como puede ayudarte en tu evolución hacia Agile te animo a asistir a mi próxima formación. Veremos cómo SAFe puede servir tanto para evolucionar de un modelo tradicional a Agile o a escalar Agile dentro de la propia organización.

Próxima formación de safe

Autor: Víctor Fairén

Leading Safe 5.0 – Virtual Edition


Virtual Evento Virtual Evento

10 noviembre, 2020 a las 8:30 am al 12 noviembre, 2020 a las 1:30 pm

Leading Safe 5.0, escala la agilidad

Leading SAFe 5.0: Durante este curso de dos días, los asistentes obtienen el conocimiento necesario para liderar una empresa Lean-Agile al aprovechar Scaled Agile Framework® (SAFe®) y sus principios subyacentes derivados de Lean, pensamiento sistémico, desarrollo ágil, flujo de desarrollo de productos y DevOps. Los participantes en la clase obtienen información sobre cómo dominar la Business Agility (agilidad empresarial) para prosperar en el mercado competitivo. Se trabaja sobre cómo establecer la agilidad técnica y de equipo, y organizar y reorganizar en torno al flujo de valor. También aprenden y practican las habilidades para apoyar y ejecutar eventos de planificación del PI y coordinar múltiples trenes ágiles (ART). Se explora la importancia de adoptar una mentalidad centrada en el cliente y un enfoque de pensamiento de diseño para la entrega ágil de productos.  

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

Objetivos del curso

  • Entender las siete competencias clave de las empresas Lean
  • Aplicar los valores y principios de la mentalidad Lean-Agile
  • Aplicar los principios Lean-Agile de SAFe a los roles y las prácticas de SAFe
  • Crear equipos de alto desarrollo estableciendo la misión y el propósito.
  • Liderar a la ejecución de Agile Release Trains (equipo de equipos ágiles)
  • Coordinar grandes flujos de valor (Value Stream)
  • Gestionar un portfolio Agile y Lean
  • Alinear la organización hacia un modelo de procesos común
  • Configurar el framework SAFe para su entorno concreto
  • Potenciar la motivación de los equipos de desarrollo
  • Liderar la Transformación Lean y Ágil de la empresa

Contenido del curso

Introducción al framework de escalado de metodlogias ágiles SAFe

Interiorizando el mindset Lean-Agile

Comprendiendo los principios de SAFe

Implementando Release Trains

Experimentar el PI Planning

Desarrollando y entregando valor

Construyendo un portafolio Ágil

Coordinando grandes Flujos de Valor (Value Stream)

Liderando la empresa Lean / Ágil

Beneficios de SAFe

Navegación exitosa en la disrupción digital

Responder efectivamente a la volatilidad del mercado, cambios de las necesidades del cliente y tecnologías emergentes

Mejora del compromiso de los trabajadores

Satisfacción del cliente

Mejora de la productividad

Agilidad a nivel de equipos y de programa

Reducción del tiempo de salida al mercado

Mejora de las relaciones en el ecosistema de clientes y proveedores

Certificación

Este curso otorga los derechos de examen para la obtención del certificado oficial SAFe Agilist (SA) de ScaledAgile. ¿Cómo se obtiene la certificación? Se debe realizar un examen on-line en los 30 días siguientes al curso. Se puede usar el manual de referencia y cualquier otro medio durante el examen. Se trata de un test con 45 preguntas de verdadero/falso y de múltiple opción, a completar en 90 minutos (acertar 34 para aprobar). Puedes ver ejemplos de preguntas del examen aquí. ¿Este curso sirve para obtener PDU’s / SEUs? Los asistentes pueden obtener 15 PDU’s del Project Management Institute (PMI) para las certificaciones PMP y PMI-ACP, también pueden aplicar para SEUs de categoría C para obtener o renovar el CSP de la Scrum Alliance.

Trainer.

Conoce a tu Certified SAFe Program Consultant


Victor Fairén

Hola, soy Víctor

SAFe Program Consultant (SPC3 y SPC4)

El curso será impartido por Victor Fairén, profesional con más de 2.000 horas como SAFe Program Consultant, liderando la transformación de empresas e impartiendo formaciones basadas en el framework de SAFe.

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
  • Google Calendar
  • iCalendar
  • Outlook 365
  • Outlook Live

SAFe versión 5.0, todas sus novedades

En enero del 2020, la gente de scaledagile framework lanza una nueva versión del “marco de trabajo” para ayudar a llevar Lean y Agile a todos los niveles que se desee en las organizaciones. Hablemos de SAFe 5.0.

Este es la nueva imagen de la “big picture” de SAFe:

 

2 Nuevas competencias

En un artículo anterior contábamos las novedades de la versión 4.5 a la 4.6:

https://jeronimopalacios.com/2019/10/novedades-en-las-nuevas-versiones-de-safe-4-6-y-5-0/

En la 4.6 se añadía una nueva dimensión con la introducción de las competencias. Éstas nos dan una estructura para poder llevar a cabo una clasificación sobre los comportamientos y herramientas deseables.

Siguiendo esta línea, se identifican 2 nuevas competencias:

  • Agilidad de la organización.
  • Cultura de aprendizaje continuo.

 

Business Agility

En esta nueva versión irrumpe uno de los tópicos de moda en el mercado Agile desde hace unos años: Business Agility.

Entendemos como Business Agility, la capacidad de competir y prosperar en la era digital respondiendo rápidamente a los cambios del mercado y las oportunidades emergentes con soluciones comerciales innovadoras.

 

Business Agility requiere que todos los involucrados en la entrega de soluciones (líderes empresariales y tecnológicos, desarrollo, operaciones de TI, legal, marketing, finanzas, soporte, cumplimiento, seguridad y otros) utilicen prácticas Lean y Agile para entregar continuamente productos innovadores y de alta calidad y Servicios más rápidos que la competencia.

 

A Business Agility se la relaciona con la quinta revolución tecnológica. Para sostener esta capacidad se basa en las siete competencias centrales que propone el modelo.

SAFe 5.0 – Your Operating System for Business Agility

 

La adopción de Business Agility aporta una nueva visión más amplia del marco de trabajo. Ofrece una visión del objetivo que se quiere alcanzar mediante el uso de SAFe.

 

Esta visión afecta a los principios de SAFe, ahora hay 10 principios, frente a los 9 anteriores:

 

#10 – Organízate alrededor del valor

 

Para llevar a cabo la adopción a nivel de empresa de Lean y Agile, no se puede dejar de lado el modo en como se estructura los distintos equipos. No se trata de romper los departamentos existentes ni mucho menos, ya que esto sería una disrupción demasiado grande para algunas empresas.

Se trata de identificar todo el camino que recorre una petición de un cliente hasta que éste puede disfrutar del producto o servicio solicitado. Las cadenas de valor deberían estar por encima de las estructuras organizacionales pues el primer valor de Lean es la entrega de valor al cliente, y esta debe ser la máxima que persigan las organizaciones.

 

Obviamente lograr esta situación no suele ser sencillo. Normalmente requiere del uso de herramientas, roles y comportamientos que nos acerquen al objetivo. SAFe nos puede servir como referencia para poder avanzar hacía este objetivo.

 

Si quieres conocer todos los cambios al detalle, consulta nuestras próximas formaciones de SAFe: https://jeronimopalacios.com/training/leading-safe/

 

Novedades en las nuevas versiones de SAFe

SAFe v4.6

AUTOR: Victor Fairén

Como viene siendo habitual la gente de Scaled Agile Framework, van sacando nuevas versiones de SAFe cada cierto tiempo. Fue en noviembre de 2018 cuando lanzaron la nueva versión del framework 4.6: SAFe 4.6 para compañías Lean.

La versión 4.6 no incluye muchas novedades a nivel conocimientos, pero si introduce un nuevo enfoque. En esta versión cabe destacar que se crean 5 competencias a distintos niveles que serían el objetivo principal para poder comprender y adoptar SAFe. Las competencias son un conjunto de conocimientos, habilidades y comportamientos relacionados que permiten a las compañías mejorar la calidad y entrega de valor en el menor tiempo de ejecución sostenible.

La versión 4.6 de SAFe se centra en las siguientes 5 competencias:

A pesar de venderse como un marco de trabajo “out-of-the box” en esta versión se intuye que para poder desplegar SAFe es necesario el desarrollo de unas capacidades, conocimiento y habilidades previas.

Mi opinión sobre SAFe no es exactamente la oficial. Para mi, SAFe es una librería de recursos que deben ser usados según las necesidades de la organización. Este planteamiento ha sido muy beneficioso en el uso de SAFe a las empresas y alumnos que he apoyado. La novedad de la “capacitación previa” va muy alineado a esta postura: ¡”SAFe no es un marco de trabajo plug-and-play”!

Competencias v4.6

Las 5 competencias básicas que se introducen en esta nueva versión son:

  • Liderazgo Lean Agile: no podemos pretender una evolución Agile si los líderes de la organización o del cambio no tienen realmente una mentalidad Lean-Agile. Sin unas personas que puedan guiar y apoyar a la organización con el mindset adecuado no es factible.
  • Agile a nivel equipo y técnico: Los equipos son la base del cambio. No sólo se debe adoptar Agile como mentalidad de trabajo sino también a nivel técnico, con el uso de técnicas y herramientas que nos permitan estar alineados con el propósito que perseguimos.
  • DevOps y Entrega bajo demanda: la idea de en cualquier momento seremos capaces de entregar la solución funcionando, es la base de esta competencia.
  • Soluciones de negocio e Ingeniería de sistemas Lean: Agrupa todas aquellas prácticas, conocimientos, habilidades y comportamientos que ayudan a la gestión de grandes soluciones.
  • Gestión de Porfolio Lean: aplicación del enfoque lea en la gestión de carteras así como los presupuestos para las cadenas de valor.

Beneficios de la versión 4.6

Desde el punto de vista de formador-consultor, así como el feedback recibido por los alumnos podemos enumerar una serie de beneficios o ventajas que aporta esta nueva versión respecto a las anteriores

  • Mayor claridad sobre los ámbitos donde Agile puede (y debe) adoptarse para ayudar a la compañía en una evolución.
  • Simplicidad: ofrece una visión general más esquemática.
  • Mayor entendimiento de las necesidades mediante la agrupación de competencias.

SAFe v5

Lo han vuelto a hacer. En el afán de adaptarse a los tiempos cambiantes, el equipo de SAFe ha presentado una nueva versión del marco de trabajo. Esta versión no está madura todavía, de hecho, su lanzamiento oficial no será hasta el 2020, sin embargo, ya se han dado a conocer algunas novedades.

Novedades de la versión SAFe v5

Siguiendo la línea de la versión 4.6, en esta nueva versión aparecen 2 nuevas competencias para dar respuesta a dos elementos claves en una organización:

  • Gestión del conocimiento y aprendizaje continuo
  • Agilidad Organizacional

7 competencias básicas

A parte de las 5 ya conocidas:

  • Liderazgo Lean Agile
  • Agile a nivel equipo y técnico
  • Entrega de producto Agile
  • Entrega de Soluciones de negocio
  • Gestión Lean de Porfolio

Se crean dos competencias más:

  • Agilidad de la organización: describe cómo las personas con pensamiento Lean y los equipos Ágiles optimizan sus procesos de negocio, evolucionan la estrategia con nuevos compromisos claros y decisivos, y adaptan rápidamente la organización según sea necesario para capitalizar las nuevas oportunidades.
  • Cultura de aprendizaje continuo: describe un conjunto de valores y prácticas que alientan a las personas, y a la empresa en su conjunto, a aumentar continuamente el conocimiento, la competencia, el rendimiento y la innovación. Esto se logra convirtiéndose en una organización de aprendizaje, comprometiéndose con la mejora incesante y promoviendo una cultura de innovación.

Esta nueva versión incluye una autoevaluación sobre la agilidad de la organización, para poder detectar de los distintos ámbitos nuestro nivel y así poder trazar un plan de mejora continua.

AUTOR: Victor Fairén

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.
  • Ir a la página 1
  • Ir a la página 2
  • 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