• 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

escalado

Scaled Professional Scrum – Virtual Edition


Virtual Evento Virtual Evento

3 noviembre, 2020 a las 8:30 am al 5 noviembre, 2020 a las 1:30 pm

Escalar Scrum utilizando el Nexus Framework

Durante 3 días, los alumnos simulan un gran proyecto de desarrollo de Software utilizando el Nexus Framework. Esta formación se realiza utilizando un enfoque eminentemente práctico donde los estudiantes trabajan juntos y simulan el desarrollo de un producto complejo a escala.

Herramientas prácticas de escalado

Este curso proporciona a los alumnos un entendimiento de como lanzar, estructurar, contratar, operar y gestionar un proyecto Agile de gran envergadura utilizando los fundamentos de Scrum.

Además, durante dos días se aprenden la infraestructura, herramientas y prácticas que se necesitan para escalar Scrum con éxito para maximizar el valor de su iniciativa de desarrollo de software.

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

Enfoque realmente práctico

Al tratarse de un enfoque práctico, los alumnos se involucran en el proceso de aprendizaje, donde pueden experimentar de primera mano los retos de las grandes iniciativas.

Datasheet Scaled Professional Scrum course
DESCARGAR FICHA TÉCNICA

¿A quien va dirigido?

Esta formación pone el foco en aquellos que desarrollan su labor en iniciativas de desarrollo que emplean potencialmente a cientos de personas.

Scrum Masters

Si te encargas de gestionar Scrum en uno o varios equipos, los conocimientos de este curso te ayudaran a mejorar tu efectividad y te enseñarán técnicas nuevas para afrontar retos.

Agile Coaches

Cuando estás inmerso en una transformación ágil de una organización, conocer de verdad cómo funcionan las mecánicas de Scrum para poder dar soluciones a problemas es básico.

Product Owners

Aquellos Product Owners que están implicados en iniciativas de desarrollo de productos ágiles a escala, se beneficiaran de nuevas técnicas de gestión del backlog e aprenderán como interaccionar con sus equipos.

Program Managers

Los Program Managers con habilidades operativas que tienen que gestionar la parte de negocio, aprenderán como funciona Nexus y cómo obtener beneficios de la interacción con los equipos de desarrollo.

Preguntas más frecuentes

Las preguntas más frecuentes sobre el curso oficial de Scaled Professional Scrum de Scrum.org

¿Incluye la certificación?

Todos los participantes que finalizan el curso Scaled Professional Scrum reciben dos intentos para realizar el examen de la certificación SPS.

El examen de certificación se realiza online. Consta de 40 preguntas y una duración de 60 minutos. En el curso se cubre todo el material necesario para obtener la certificación.

¿Es necesario tener otra certificación o curso?

No es necesario ningún tipo de curso o certificación previo, aunque tener un conocimiento y experiencia en Scrum ayuda a entender los contenidos del curso.

¿Es un curso sobre Nexus?

No. El curso se estructura en torno a Nexus pero se enseñan +50 prácticas que son aplicables a cualquier entorno de escalado, como la gestión de dependencias, la formación de equipos ágiles, el reporting y el trabajo del día a día. Las prácticas de este curso se utilizan de manera exitosa por organizaciones que utilizan LeSS o SAFe.

¿Que incluye el precio?

El precio incluye el curso, material, 2 intentos para el examen de certificación, desayunos y comidas durante la duración del curso, además del acceso a nuestra comunidad de alumnos y guías específicas.

¿Obtendré PDUs/SDUs con la realización de este curso?

Sí. Este curso califica para la obtención de 14 PDUs del Project Management Institute o 14 SDUs de la Scrum Alliance, para la renovación de las certificaciones PMP, PMI-ACP, CSP-SM y CSP-PO.

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

Eventos Relacionados

  • Professional Scrum Product Owner

    6 febrero a las 9:00 am al 9 febrero a las 1:00 pm
  • Professional Scrum Master

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

    22 febrero a las 8:30 am al 23 febrero a las 4:30 pm

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.

Scrum Studio, una breve introducción

Esto de la transformación digital no es nuevo. Es simplemente la última forma de denominar la búsqueda de ciclos rápidos de feedback y la adaptación hacia y en torno al cliente. En esa línea, todo es transformación digital. Y nada lo es.

Más allá del debate filosófico, lo que es una realidad es que la tecnología juega un papel fundamental dentro de esa transformación digital. Y para eso hay que escalar las iniciativas tecnológicas. No es fácil cuando IT ha sido vista como un centro de coste -un mal necesario- durante los últimos 20 o 25 años en la mayoría de las organizaciones.

Las conversaciones en torno al escalado y gestión de los productos de Software cuando hay involucradas 20, 30 o 100 personas han sido frecuentes en la comunidad y han generado un debate airado. En el video más arriba, introduzco los conceptos de escalado vertical y escalado horizontal y como Nexus o Scrum Studio pueden ayudar a resolverlos.

Escalando Kanban

Cuando se trata de escalar el desarrollo de productos de software, la mayoría de las organizaciones miran a soluciones como SAFe, LeSS o Nexus. Sin embargo, hay algo que olvidan: la parte de gobernanza.

Es fácil perderse en hacer Scrum o Kanban a nivel equipos o a nivel producto, pero la mayoría de las organizaciones tienen decenas o incluso cientos de productos, internos y externos, que poseen una fuerte interdependencia. Una de las soluciones es Scrum Studio.

El caso de Kanban y su acercamiento a la agilidad es distinto. Sigue un camino distinto, en el que prima la adaptación sobre la disrupción. Conforme vamos creando servicios dentro de nuestra organizaciones que podemos gestionar con Kanban, establecemos las reglas que gobierna la interacción entre ellos.

Para entender Kanban hay que pasar por tres etapas, que conducen a tres paradigmas fundamentales.

Aprender a crear flujo

Aunque pueda parecer muy abstracto (a quién no le pareció abstracto el concepto de Scrum Master la primera vez que oyó hablar del mismo) esto tiene un sentido fundamental: Si no somos capaces de identificar cuál es el proceso que sigue el trabajo desde que lo ideamos hasta que lo entregamos, nunca seremos capaces de controlarlo. De igual manera, si no sabemos cuántas habitaciones tiene nuestra casa, nunca podremos mantenerlas limpias y ordenadas.

Además, para crear flujo, es necesario limitar el trabajo en cada uno de los procesos que sigue nuestro trabajo. Sólo así podremos empezar a gestionar nuestro sistema. A esto se le llama crear límites WIP (Work in Progress).

En esta etapa conseguimos:

  • Dejar de empezar trabajo y empezar a terminarlo
  • Aprender cómo funciona nuestro sistema para mejorarlo
  • Generar transparencia y momentos de inspección y adaptación

Entender las organizaciones desde la perspectiva de los servicios

Uno de los conceptos de más difícil asimilación de mis estudiantes de Kanban es entender la diferencia entre un servicio y una clase de servicio.

Mientras que el primero está relacionado con identificar y aprender a ver la organización como una serie de servicios interdependientes que se retroalimentan unos a otros, el segundo es asignar una dimensión de riesgo a nuestros ítems de trabajo, una prioridad. Basada en datos. ¿Cuál es el coste de no terminar algo a tiempo?

Por ejemplo, un departamento de RRHH puede ofrecer distintos servicios: Un servicio de recruitment, un servicio de onboarding de nuevos empleados y un servicio de gestión de altas, bajas y notificaciones. Ambos son interdependientes y a la vez son sistemas separados que hay que tratar como tal.

En esta etapa conseguimos:

  • Medir los tiempos de espera
  • Analizar la eficiencia de nuestro flujo de trabajo
  • Adaptar un servicio para que ofrezca mejores resultados
  • Entender cómo los servicios se relacionan entre ellos

Convertir nuestra organización en una máquina orientada a deleitar al cliente

Sólo los mejores consiguen llegar a entender esta última etapa, en la que empezamos a unir unos servicios dentro de nuestra organización con otros para conseguir crear una máquina afinada, un reloj perfecto que continuamente supere las expectativas de nuestros clientes.

En esta etapa, las organizaciones gestionan la demanda de los clientes de tal manera que siempre pueden saber donde algo está fallando, adelantarse a la competencia y ofrecer una propuesta de valor única.

En esta etapa conseguimos:

  • Adaptar nuestra organización al milímetro
  • Incrementar exponencialmente los niveles de innovación
  • Métricas en tiempo real de cómo va nuestro negocio
  • Ultraagilidad

En este video, David J. Anderson comenta los 7 problemas más comunes que nos encontramos al escalar Kanban.

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”.

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