• 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

Victor Fairen

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.

Descentralizar las decisiones

SAFe está basado en una serie de principios Lean y Agile. Estos principios son fundamentales para la creación de un flujo eficiente de los procesos de desarrollo de productos, y todas las decisiones que se tomen deben estar basadas en estos principios:

  1. Tomar una visión económica
  2. Aplicar el pensamiento sistémico
  3. Asumir variabilidad; preservar opciones
  4. Construir incrementalmente con ciclos de aprendizaje rápidos e integrados.
  5. Basar los hitos en la evaluación de objetivos sobre sistemas funcionando
  6. Visualizar y limitar el WIP, reducir el tamaño de los lotes, y gestionar los tamaños de colas
  7. Aplicar cadencia y sincronismo mediante la planificación conjunta de varias áreas
  8. Desbloquea la motivación intrínseca de los trabajadores del conocimiento
  9. Descentraliza la toma de decisiones

Es muy importante tener presentes estos principios cuando se trabaja acorde con SAFe, al ser este un marco de trabajo, no todas las situaciones posibles estarán descritas, solo “las reglas del juego”.

Los principios de SAFe incluyen, entre otros, el pensamiento Lean y Sistémico, los principios y métodos agiles, el flujo de desarrollo de producto.

Muchos grandes pensadores han seguido este camino antes que SAFe, dejando centenares de libros y estudios a partir de los cuales destilar lo necesario para adaptar un marco de trabajo a las necesidades actuales de las empresas. El objetivo es sintetizar todo el conocimiento y las lecciones aprendidas de centenares de entregas en un solo marco de trabajo.

Varios de estos principios están basados en la obra de Donald Reinertsen (The Principles of Product Development Flow – Second Generation Lean Product Development) y en el libro de Daniel Pink (Drive).

Dichos principios no se limitan solo al ámbito del departamento de IT, de hecho hay un movimiento importante por parte de departamentos de HR (también conocidos como departamentos de gestión del talento) en la adopción de SAFe, sobretodo basado en los principios #8 y #9.

Cuando formamos a managers para liderar la transformación mediante la adaptación de SAFe, hay uno de los principios que suele generar controversia entre los asistentes: “Descentralizar la toma de decisiones”:

¿voy a dejar que la gente de mi departamento decida la dirección de la empresa?
¿van los equipos de desarrollo a gestionar la demanda del hardware?
¿los equipos pueden decidir que tecnología usan? ¿Qué hay de la arquitectura de la solución?
este principio no se va a aplicar ¿podemos quitarlo de la formación para los equipos?

Gente llevándose las manos a la cabeza, indignación en la sala…

Obviamente SAFe no dice que todas las decisiones de la empresa deben ser tomadas por los equipos de desarrollo. SAFe sugiere que deberíamos tener un marco de toma de decisiones para decidir qué tipo de decisiones las toman los CEOs, o los arquitectos de la solución, y cuáles pueden ser delegadas a los equipos.

Este marco de toma de decisiones debe considerar una serie de variables, como por ejemplo:

  • Escala económica: ¿es una decisión que potencialmente implique la inversión de mucho dinero por parte de la empresa? Es conveniente fijar un rango para que la decisión según este valor sea centralizada o descentralizada.
  • Criticidad temporal: ¿es una decisión que debe ser tomada ahora mismo? ¿no tomarla ahora tiene repercusiones negativas?
  • Frecuencia de la decisión: ¿Cuán frecuente es esta decisión? ¿es algo que se decide periódicamente o es una decisión puntual o única?
  • Dependencias con otros equipos/departamentos: ¿esta decisión impactará en el trabajo de otros equipos o departamentos?
    Estos son algunos de los parámetros a considerar en la descentralización de decisiones, puede haber muchos otros dependiendo de la empresa o del mercado. La experiencia dice que el factor económico suele prevalecer sobre el resto.
    Los objetivos de descentralizar las decisiones es conseguir realmente un movimiento de transformación hacia una empresa ágil.

Las razones/beneficios para implementar un marco para descentralizar las decisiones son varias:

  • Minimizar los cuellos de botella: no hagamos decidir al CEO sobre algo que no impacta económicamente, no afecta a nadie más y necesitamos tomar la decisión hoy.
  • Apoderar a los equipos en su ámbito de dominio: quien mejor que el equipo de desarrollo de una aplicación para tomar decisiones de bajo impacto económico pero frecuentes sobre el futuro del producto.
  • Mejorar el “time to market”: cuando no se toma decisiones conlleva retrasos. Las decisiones facilitan el flujo
    Este principio es fundamental si realmente queremos transformar la empresa hacia una empresa basada en el Management 3.0 (Jurgen Appelo) y sobretodo hacia una empresa agil!

Principios de SAFe®

Como dijo John Ratzenberger

encuentra gente que comparta tus valores, y conquistareis el mundo juntos.

Como todo “buen” marco de trabajo ágil, SAFe® está guiado por unos valores fundamentales que dictan las acciones y el comportamiento, y ayudan a la gente a distinguir entre lo correcto o lo incorrecto. Estos valores fundamentales son los que deben guiar la organización en el proceso de toma de decisiones sobre los distintos aspectos que vayan surgiendo en el proceso de adopción de SAFe®.

Hay cuatro valores fundamentales que SAFe honra, apoya y ayuda a ofrecer: Alineación, Calidad incorporada, Transparencia y Ejecución del programa.

Alineación

La alineación también se escala. Es una condición necesaria para poder abordar la realidad empresarial de un cambio acelerado, turbulencias creadas por la competencia y equipos geográficamente distribuidos.

Si no se mantiene el alineamiento entre los equipos, al escalar disfrutaremos de un entorno de trabajo donde reinaran la anarquía y el descontrol.

Todos los ART (Agile Release Train) son equipos de equipos alineados hacia un objetivo común. A su vez, todos estos ART están a su vez alineados según unos presupuestos que vienen dictados por los aspectos estratégicos de la empresa.
¿y cómo conseguimos que todos los equipos de un ART estén alineados? Sincronizando los sprints de todos los equipos implicados en el tren, todos ellos empiezan el mismo día y tienen la misma duración. Esto va en contra de la flexibilidad total, pero los beneficios son mayores que las pérdidas, pues incluso el acto de fijar fechas fomenta la comunicación entre equipos.

Calidad

La calidad debe estar asegurada en cada incremento de solución entregada al cliente, la calidad no se “añade más tarde”.

Si la calidad es importante a nivel de equipo, ésta cobra más importancia a nivel de programa puesto que inyectar código de mala calidad en la solución provocará más costes en la interacción con los otros componentes o funcionalidades del sistema. “If you produce crappy code and you scale it, you will get crappy solution”.

Sin ella, la organización operará con grandes entregables que no han sido verificados ni validados, esto provocaría una repetición del trabajo y por consiguiente una disminución de velocidad en la entrega.

La calidad debe estar presente a nivel de software mediante una atención continua a la excelencia técnica y el buen diseño de la solución (arquitectura) que faciliten la agilidad. También a nivel de hardware y en la integración de los distintos componentes del sistema.

Transparencia

El desarrollo de grandes soluciones es complejo. Las cosas salen mal o no funcionan como estaba planeado. La falta de transparencia da lugar a decisiones basadas en supuestos especulativos y la falta de datos. Nadie puede arreglar un secreto.

Los equipos de alto rendimiento están basados en la confianza, y su construcción lleva tiempo. La transparencia es el mejor facilitador de la confianza.

En SAFe® hay numerosos mecanismos o eventos que ayudan a la empresa a conseguir esta transparencia. El uso de herramientas visuales, así como herramientas virtuales, permite fácilmente irradiar información. También de manera regular se hacen sincronizaciones a distintos niveles (Scrum of Scrums, PO sync, Release Management, etc) que ayudan a fomentar la transparencia organizacional.

Ejecución del programa

Ninguno de los valores anteriores importa si los equipos no son capaces de ejecutar y entregar valor de manera continua e incremental (principio básico del agilismo).

La historia nos muestra que mientras muchas empresas empiezan la transformación con los Equipos Ágiles, a menudo se sienten frustradas, ya que incluso estos equipos luchan para entregar grandes cantidades de valor de la solución de manera fiable y eficiente.

Pero con la alineación, la transparencia y sin olvidar la calidad, los equipos tienen un poco de “viento a favor”. Eso permite enfocar la ejecución. Y si luchan -y lo harán, porque el desarrollo de soluciones complejas es difícil- tienen la piedra angular de los “Inspect and Adapt Workshops”. De esta manera, cierran el ciclo de ejecución y planificaran acciones para mejorar la siguiente iteración, también llamadas Incremento de Programa.

La ejecución del programa no puede ser solo cosa del equipo, no puede ser algo que suceda de abajo hacia arriba. Para el éxito en la adopción de SAFe® es necesario el apoyo activo de sus líderes (Lean-Agile leaders).

Estos valores son muy “bonitos”, todas las empresas quieren la entrega satisfactoria y con valor de las soluciones que construyen, ¿pero hasta qué punto están todos sus departamentos o incluso equipos alineados? Y sobre la transparencia, ¿creéis que acabar con las agendas ocultas es algo que se consigue en unos días? ¿o en unos meses? ¿o como líderes / managers no se presiona en un momento dado al equipo para que reduzca la calidad de la solución debido a una fecha de entrega? ¿se hace demasiado a menudo?

Empieza por hacer visible lo invisible mediante radiadores, ha hacer que fluya la información de manera constructiva a través de eventos de sincronización y sobretodo, periódicamente Inspecciona y Adapta a nivel de equipo de equipos.

Los valores fundamentales de SAFe® son una herramienta muy potente para la transformación digital de una empresa hacía una metodología de trabajo ágil mediante la adopción del mismo, pero es realmente muy difícil que dichos valores estén presentes en el día a día de la empresa y en las decisiones que se tomen y este va ser uno de nuestros mayores cometidos como “Lean-Agile Leaders”.

¿Que es SAFe®? ¿es tan bueno como dicen? ¿es tan malo como dicen?

SAFe® (acrónimo de Scaled Agile Framework Enterprise) es un marco de trabajo para la escalación de las prácticas ágiles basado en los principios de Lean y Agile para el desarrollo de software y sistemas, a nivel corporación.

SAFe®, en su página web, ofrece gratuitamente el marco de trabajo con una explicación detallada de cada elemento del mismo. Éste es un recurso de soporte muy útil en la implementación del mismo, sin embargo, esta información, se puede considerar solo de apoyo ya que se corre el riesgo de saturación ante tanta cantidad de información. Es por eso que en toda adopción de SAFe®, como marco de trabajo, se recomienda encarecidamente la formación e iniciación por parte de un SPC (SAFe® Program Consultant).

En el sitio web, se pueden ver estadísticas sobre los beneficios de adoptar SAFe®, tales como:

  • 20-50% de incremento en la productividad
  • + del 50% de incremento en la calidad
  • 30-75% más rapidez en lanzar productos al mercado

Ante todo que conste que soy un gran fan de las metodologías ágiles (a veces un poco extremista), pero también soy Ingeniero de formación con lo que confío en los principios del método científico y de la matemática.

La gran mayoría de estadísticas que comparan resultados de metodologías waterfall con metodologías agiles, son meramente “estadísticas anecdóticas”. Estoy muy seguro que no se ejecutó un proyecto en cascada (waterfall) y el mismo proyecto siguiendo SAFe® con condiciones “ambientales iguales”, para luego comparar, como aproximación al método científico.

Las experiencias en la adopción de SAFe® tiene muchos beneficios y la realidad es que sirve para transformar organizaciones hacia un modelo de negocio y de producción más agiles y con mejores resultados.

En la comunidad Agile, hay muchas críticas sobre SAFe: que si es SAFe® el “Fast Food” de Agile, que si SAFe® no es realmente agile, SAFe® no es flexible… hay grandes detractores y grandes partidarios y todos tienen razón y ninguno la tiene. ¿es SAFe® bueno o es SAFe® malo? Pues como suelo responder “depende”.

La pregunta clave no es si SAFe® es bueno o es malo, la pregunta es ¿va ayudarme la adopción de SAFe® en mi empresa? En este caso la respuesta es “depende de tu empresa y de cómo quieras aplicarlo, pero seguramente SI”. Como en cualquier cambio de esta magnitud, en una empresa se necesita formación, tiempo, gente con ganas de cambiar las cosas y recursos.

SAFe® es un marco de trabajo que nos ayudará a solucionar los problemas que solemos encontrarnos en el desarrollo de grandes proyectos:

  • La integración del software con distintos equipos implicados en el mismo proyecto. Lo que inicialmente se planifica en X días (o incluso 1 día) acaba siendo semanas, con la gente trabajando bajo presión y el consiguiente impacto en la calidad del software.
  • La ejecución de un plan hecho al principio del proyecto, suponiendo que no van a haber cambios en los requerimientos.
  • Falta de visibilidad del avance real del proyecto: hasta que no se llega a la fase de aceptación del cliente, no tenemos ningún feedback de cómo estamos haciendo el trabajo.

Hay una realidad evidente, y es que cada vez más empresas grandes están implantando SAFe® en el área de IT, de manera satisfactoria. El 60% de las empresas de TOP 100 Fortune de EEUU, cuentan en sus filas con “SAFe® consultants” o certificados en “Leading SAFe®”.

En SAFe® encontramos tres niveles (o cuatro en la versión extendida):

  • Equipos
  • Programa
  • Cadena de Valor (recomendado sólo para grandes corporaciones, puesto que cada nivel implica un coste de coordinación)
  • Portafolio

En la mayoría de las adopciones de este marco de trabajo se llega hasta el nivel de programa, hecho que me entristece. La plena adopción de SAFe® provoca la transformación hacía un entorno ágil de trabajo de otros departamentos de la empresa, no solo IT.

Como idea general, a nivel de programa encontramos los ART (Agile Release Train), que son equipos de equipos, centrados en mantener el foco de trabajo y entregar valor de manera sincronizada y cada cierto tiempo. Es por esto que se considera la cadencia y la sincronización hechos fundamentales en SAFe®:

  • Cadencia: permite transformar sucesos impredecibles en predictibles, hace los tiempos de espera predecibles y facilita la planificación
  • Sincronización: hace que múltiples eventos suceden al mismo tiempo, facilita el intercambio de personas y funcionalidades, y permite una integración de manera regular.

Para trabajar de manera efectiva, necesitamos que los ciclos de trabajo estén sincronizados. Esto nos permite reducir riesgos, ya que necesitamos/queremos saber cómo está avanzando la integración de todas las partes implicadas cada cierto tiempo.

He aquí unos cuantos beneficios de SAFe® basados en experiencias:

  • Permite grandes compañías moverse hacia un entorno ágil con seguridad
    • Entrega de valor al cliente, de manera incremental y continua
    • Transparencia
    • Colaboración
  • Permite definir responsabilidades a distintos niveles al tener nuevos roles.
  • Soluciona los problemas originados al intentar aplicar Scrum sin un alcance estandarizado en grandes y medianas organizaciones.
    • Falta de alineamiento hacía el objetivo común
    • Falta de sincronismo en las entregas
    • Mal manejo de las dependencias entre equipos

 

Si hay algo que me gustaría que te llevases de la lectura de este artículo es que SAFe® no debe ser considerado como un objetivo final, sino como un inicio. Permite a las grandes y medianas organizaciones conseguir algunos de los beneficios de las metodologías ágiles mientras se inician hacía el objetivo final que es la verdadera 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