viernes, 25 de marzo de 2016

¿Qué tal easyBacklog como software para gestionar la pila de producto y los sprints?

Gertrudis, una asistente a uno de mis cursos de ingeniería de requisitos ágiles, entregó uno de los ejercicios en que hay que escribir 10 historias de usuario en forma de un documento obtenido por easyBacklog. Me encantó la forma en que lo hizo y le eché un vistazo a ese software y descubrí una opción simple y completa, gratuita y on-line, para gestionar de forma virtual una pila de producto y ejecutarla en sprints.

En su página lo definen como:
  • easyBacklog IS: An intuitive time saving backlog management tool for Agile practitioners working in or with agencies.
  • easyBacklog is NOT: Yet another all purpose project management, Agile or collaboration tool for teams.
Cómo se puede observar en la pantalla de configuración pone énfasis en la estimación de historias, información clave para que el Propietario del Producto pueda hacer una buena gestión de la pila de producto.
easyBacklog - Configuración
Lo que no me gusta:
Lo que me gusta:
easyBacklog - La pila de producto
easyBacklog - Pilas de producto y sprint
easyBacklog - Los gráficos
easyBacklog es un software mínimo para la gestión virtual de un proyecto Scrum. Desde mi perspectiva, y en consonancia con el primer valor del Manifiesto Ágil "Individuos e interacciones sobre procesos y herramientas" pienso que una herramienta minimalista, como esta, es la mejor opción para no quitar el foco de lo que importa, las personas.

Mis agradecimientos a Gertrudis por descubrirme este software.

domingo, 20 de marzo de 2016

¿Cómo generar un contexto compartido para una buena comunicación en un proyecto?

Incepción Ágil, el dado a nuestro favor
El 90% de proyectos fallidos ocurren por la falta de comunicación, y el 90% de proyectos exitosos lo son por las personas que han participado. Por tanto generar un contexto compartido, para que los comprometidos e involucrados se comuniquen mejor a lo largo de la ejecución del proyecto, es apostar por el éxito del mismo. Desde la Agilidad Jonathan Rasmusson nos propone la Incepción Ágil en su libro "The Agile Samurai" para lograr este fin.

Tal como define José Manuel Beas en su artículo "La Incepción Ágil, es un conjunto de dinámicas orientadas a enfocar a todas las personas involucradas en un proyecto hacia un mismo objetivo, reduciendo muchas de las incertidumbres, ayudando a explicitar los riesgos más evidentes y poniendo en común las expectativas de todos".

Por tanto se trata de una técnica de conceptualización para emplear en el proceso de iniciación de un proyecto y así aumentar la probabilidad de éxito del producto resultante, con el objetivo de construir una visión completa sobre el concepto de producto, una visión compartida y comprendida de idéntica forma por los comprometidos, involucrados e interesados, de manera que se eviten los sesgos personales. Tal como recoge Alfons Corrales en su artículo sobre la Incepción Ágil, la utilidad de las técnicas viene fundamentada por los siguientes aspectos:
  • Distintos interesados tienen distintos intereses y necesidades sobre un producto o proyecto concretos. Generando la conversación adecuada entre ellos emergerán aspectos que de otra forma podrían haber quedado descuidados.
  • Hay requerimientos y necesidades difíciles de explicitar. Hay necesidades que a veces son difíciles de comunicar, incluso porque a veces no somos conscientes de las mismas. Mediante técnicas como el incepción podemos lograr que emerjan a la superficie.
  • El proceso de comunicación suele ser imperfecto. Con una misma frase, dos personas pueden entender cosas completamente distintas. Es necesario trabajar en profundidad el concepto de un proyecto para asegurar una visión y comprensión común.
  • La Incepción Ágil permite poner en valor nuestro expertise. Se trata de una oportunidad única para aportar valor añadido a nuestros clientes y mejorar la calidad de las relaciones, consiguiendo que el producto se centre en lo que el cliente necesita en lugar de en lo que dice que quiere.
La práctica más popular para generar este contexto común y comenzar a definir la pila de producto es el taller colaborativo Agile Inception Deck. Viene a ser una baraja con 10 actividades, que son opcionales e incluso se pueden sustituir por otras actividades con el mismo objetivo. Han de estar presentes todas las personas comprometidas e involucradas para considerar las 10 preguntas y llegar a la verdadera esencia del producto, y definir y comunicar esa visión a todos los miembros del equipo e interesados.

1. ¿Por qué estamos aquí?
Es un recordatorio del por qué estamos aquí, quiénes son nuestros clientes, y porqué hemos decidido hacer el proyecto.

2. Crear una visión general, un elevator pitch
Si tuviéramos menos de dos minutos y dos frases para describir nuestro proyecto, ¿qué diríamos?

3. Diseñar la caja del producto
Si tuviéramos que diseñar un anuncio de nuestro producto o servicio para una revista y que resaltara al hojearla, ¿qué diría? ¿atraería para comprar?

4. Crear una lista de lo que NO es
Tenemos una idea clara acerca de lo que vamos a hacer en el proyecto, ahora vamos a tratar de ser más claros y ver lo que no vamos a hacer.

5. Conocer a la comunidad
La comunidad de nuestro proyecto es siempre más grande de lo que pensamos...

6. Mostrar la solución
Pensemos en un alto nivel de la arquitectura y en las tecnologías que vamos a utilizar.

7. ¿Qué nos impide dormir?
Hay mil cosas que podrían ser erróneas en nuestros proyectos, algunas las podemos gestionar, otras no. Esta actividad trata de asegurarnos que identificamos los riesgos más importantes.

8. Estimar el tamaño
¿Es un proyecto de tres, seis o nueve meses?

9. Compensar las decisiones
Todos los proyectos tienen que estar balanceados en el tiempo, el dinero, el alcance y la calidad. ¿Cuál es de la mayor y de la menor importancia en este momento?

10. ¿Cuánto cuesta?
Hay dos cosas que preocupan a nuestros clientes¿Cuánto cuesta? ¿Cuánto tiempo vamos a necesitar?
Mapa visual del Inception Desk, para verlo al detalle máximo clickar encima de imagen - cortesía de Gertrudis :-)

sábado, 5 de marzo de 2016

¿Cómo resolver el conflicto cuando dos miembros de equipo aportan cada uno una solución?

Resolución de conflictos
A veces ocurren reuniones de refinamiento y de planificación de sprint en las que dos miembros de equipo defienden acaloradamente su solución a un problema o requisito. Si el Scrum Master no interviene y no modera la discusión esta puede escalar a un "y yo más..."  y menguar el entorno que propicia y estimula la generación de buenas ideas y soluciones, y en definitiva debilitar al equipo como unidad.

Recientemente estuve haciendo co-training con Marcos Garrido en una clase de CSM en la que aprendí esta dinámica, que de forma simple y elegante ayuda a resolver conflictos, y que pretendo describir en este post.

La dinámica se basa en tablero muy simple, como el de la foto de la izquierda:
  • En la cabecera se ponen las soluciones, en este caso A y B, y en los encabezados de fila, en la primera, las ventajas (ADV), y la segunda, las desventajas (DISAD).
  • El facilitador pregunta y anota en la primera fila las ventajas que cada uno de los contrincantes ve en la solución del otro.
  • De modo similar el facilitador pregunta y anota en la segunda fila las desventajas que cada contrincante ve en su propia solución.
Acto seguido el equipo vota con un punto la solución que le parece más idónea, pero no importará únicamente la naturaleza de la solución, en el ejemplo el equipo votará con mucha probabilidad la solución A porque piensan que quién ideó B no colaborará igual, y saben que justamente la colaboración hace la diferencia entre una solución buena y una excelente.

martes, 1 de marzo de 2016

¿Puede trabajar cualquier equipo con Scrum?

Estuve hablando con un miembro de un equipo clásico que se interesó por saber qué era eso de Scrum. El concepto de equipo que se siente propiedad colectiva de un software no le convenció, decía que si trabajas mucho tiempo con el mismo equipo te acabas acomodando y pierdes la motivación. Por otro lado él estaba encantado con saltar de cliente en cliente, de proyecto en proyecto, decía que el hecho de variar de entorno le estimulaba y le motivaba, y que rompía con el inevitable sabor boca del proyecto anterior entregado fuera de plazo. Pensando en una compañía sin directivos ágiles que velen por un personal motivado, llegué a comprender su perspectiva, así que me animé a escribir este post que dibuja lo que significa para un miembro de equipo trabajar con Scrum.

Scrum implica una forma diferente de trabajar y el equipo que vaya a hacerlo tiene que ser consciente de ello y estar alineado en actitud y mentalidad. Equipos que nunca han trabajado con Scrum han de pasar por una adaptación a otra forma de trabajar, con ciclos cortos, con absoluta transparencia, construyendo confianza y estar abiertos a mucha comunicación. La pregunta que debe de plantearse cada miembro de un equipo que vaya a iniciarse en Scrum es la siguiente:

¿Hasta qué punto me gustaría ser libre?

Equipo de Scrum trabajando
Como libertad se entiende que el equipo decide cómo se construye, tiene libertad de moverse, tiene libertad de aceptar cambios y tiene libertad para probar y utilizar tecnologías, pero eso implica autoorganización, aprendizaje continuo, responsabilidad y compromiso en equipo. Todos deben de comprometerse por todos, tanto en las decisiones como en los errores. Se decide en equipo, por tanto todos toman la responsabilidad de cada decisión, y con cada decisión no acertada aprenden para la próxima vez. Por otro lado cada miembro debe de aceptar que sus compañeros hagan errores y apoyarlos incondicionalmente, para también aprender de los errores de todos. Scrum requiere equipos multifuncionales en los que todo miembro se interesa por lo que hacen sus compañeros, han de estar abiertos a aprender lo que hacen los demás y a ayudarles en momentos de sobrecarga. Como se puede ver hay que estar abierto a aprender en varios frentes durante todo el tiempo de construcción del proyecto/producto.

El éxito de Scrum se da en gran medida por el equipo, por la difusión y transferencia del conocimiento y la base de conocimiento común que se forma de manera distribuida en el equipo, por la confianza y conexión entre sus miembros, por la gestión de la comunicación que es elemental en tiempos tan cortos como son los sprints. Todo ello convierte a los equipos en equipos ganadores, de excelencia o hiperproductivos.

Los miembros del equipo han de reaprender a recibir feedback, capacidad innata que tenemos de niños y que de adultos tendemos a perder. Como adultos tendemos a justificarnos ante el feedback que recibamos sobre algo que hemos construido, y no es nada trivial cambiar de mentalidad para aceptar feedback y comprender que en Scrum simplemente hay que mirar para adelante y actuar, no hay premios ni penalizaciones. Scrum significa incertidumbre cosustancial y cambios constantes para el equipo, no hay nada mal hecho, todo está bien hecho; hay cosas menos bien hechas, simplemente bien hechas y más bien hechas. Cosas menos bien hechas, como que las personas hacen errores o el software vivo en cuya naturaleza están las incidencias, son oportunidades de aprendizaje, los errores e incidencias ocurren, se analizan y se corrigen. Los miembros de un equipo de Scrum han de aprender a ver los problemas y a ponerlos sobre la mesa, sin miedo, con el fin de que se arreglen cuanto antes, y no vuelvan a pasar. Quien encuentra un error o un problema, incluidos los propios, ha de exponerlo en la reunión diaria por ejemplo, y todo el equipo debe de aplaudirle, ya que un problema que ahora es pequeño podría haberse convertido en uno grande cuando inevitablemente apareciera más adelante.

En el día a día el equipo se ha de volcar y focalizar en las tareas del sprint, poniendo énfasis en lo que ofrece el momento, el sprint, y en su cumplimiento. La "solución" no existe, siempre hay varias soluciones para un problema, y estas se discuten entre todos para encontrar el camino con la solución más rápida y eficiente para llegar al objetivo del sprint.
Equipo de Scrum al completo, gracias Sergio por el dibujo
No todo equipo es adecuado para trabajar con Scrum, hay equipos que les cuesta lidiar con la libertad, el compromiso y la responsabilidad, de la misma manera que proyectos, negocio y dirección pueden hacer que no sea adecuado trabajar con Scrum. Hay personas con Scrum en su ADN, personas escépticas pero con curiosidad y personas claramente contrarias a Scrum, sólo es recomendable trabajar con Scrum con miembros de equipo de los dos primeros tipos, y aún así sólo es recomendable si todos pueden y quieren aprovechar esa oportunidad.

Agradecimientos a Thorsten Huber quién en su video "Kann jedes Team SCRUM?" plantó la semilla para este post.

sábado, 27 de febrero de 2016

¿Qué unidad es la mejor para estimar, horas ideales u horas reales?

Harry Potter, 8 horas de lectura ideales, y ¿cuántas reales?
Tiempo ideal es una medida de esfuerzo, mide en tiempo cuanto cuesta construir algo en condiciones mentales óptimas, sin interrupciones y con todos los recursos necesarios disponibles. El tiempo real es medida de tiempo, la duración que mide el tiempo real que se ha aplicado a una tarea. Por ejemplo, el esfuerzo para leer un tocho de Harry Potter puede ser entre 8 y 12 horas, pero leerlo seguramente será más de una semana.

Se puede utilizar tiempo ideal como unidad de medida del esfuerzo de las historias de usuario y de las tareas, pero no es recomendable. Imaginemos nuestra tarea que reza "leer el tercer tomo de Harry Potter = 8 horas" colgando en el tablero, entra un jefe o directivo, lo ve, y exclama "bien, ¡mañana el libro está leído!"...

El tiempo ideal es una unidad complicada; 24 horas ideales/40 horas reales es una buena productividad para un profesional, pero a quién no esté familiarizado y no lo comprenda le puede chirriar, no siendo consciente de que en la realidad tenemos reuniones, contestamos emails, llamadas telefónicas, descansos, hay días con el ánimo mejor y otros peor... es por ello que es preferible trabajar con una unidad relativa que no tenga nada que ver con el tiempo, unidad como los puntos de historia.

Actualmente nos está funcionando el siguiente esquema de unidades de estimación, historias en puntos de historia y tareas en horas

Historias de usuario y tareas estimadas en unidades distintas
1. Estimar las historias de usuario en puntos de historia, una unidad relativa arbitraria, obtenida con planning poker. Al final de cada sprint la velocidad será la suma de los puntos de historia entregados en la revisión de sprint. La velocidad media permitirá planificar el siguiente sprint y proyectar las entregas de la pila de producto en rangos de fechas futuras. Resaltar que elementos grandes como epics grandes y temas se pueden estimar de forma relativa en tallas de camisa.

2. La estimación de las tareas de la pila de sprint la haga el equipo en horas ideales y teniendo en cuenta la disponibilidad real de cada uno. De esta manera el equipo siente seguridad para comprometerse con las historias que ha incluido en el sprint. La suma de horas ideales no tiene porqué llenar el tiempo real disponible. Es la velocidad media, en puntos de historia y pila de producto, en lo que se debe de apoyar el equipo para decidir lo que entra en la pila de sprint.

3. En la reunión diaria cada miembro del equipo reestima en horas "reales" (entiendo como estas horas ideales inmersas en la realidad) sus tareas con el objetivo de marcar en el burndown las horas pendientes y así poder detectar desviaciones. Recordemos que en Agilidad lo que determina el grado de avance del proyecto/producto no es midiendo el trabajo realizado, sino el pendiente de realizar.

Puede sorprender que se mezclen unidades, pero cada una tiene su función y no tienen porqué cuadrar:
Venimos de una cultura de estimación/imputación de horas donde nos convencemos que los números representan la realidad y que han de cuadrar, cuando de lo que se trata, como vemos en este esquema, es de dotar el equipo de herramientas para que se planifique, tome decisiones y se gestione mejor.

viernes, 19 de febrero de 2016

¿Qué marco de Scrum escalado elegir?

Actualmente existen varios marcos de Scrum escalado sobre los que la empresas que quieran crecer en Agilidad han de decidir cuál se adapta mejor a sus necesidades. Es un tema de conversaciones y debate muy actual en mis clases y en las empresas que acompaño como coach ágil.

Nexus es un marco leve en detalles y que no trata cuestiones organizativas, y que ha partido de Scrum reutilizando los artefactos, los roles y las reuniones. Es un marco concebido para pequeñas empresas con 3 a 9 equipos de desarrollo.

LeSS consiste un marco de Scrum escalado mínimo que ofrece un alto grado de flexibilidad en su implementación, no es preceptivo y se limita a dar sugerencias. Es una gran opción para organizaciones maduras en Agilidad que estén en fase de crecimiento y que estén buscando un marco que les ayude a escalar Scrum.

DAD es un marco cuyo objetivo es llenar los vacíos de proceso que le faltan a Scrum. Lo hace de forma híbrida en donde gobernabilidad y gestión del ciclo de vida se basan en métodos tradicionales en cascada. Es un marco semi-tradicional válido para grandes empresas.

SAFe® es el marco ágil más conocido por sus éxitos de implementación en múltiples grandes compañías. Está muy estructurado y es prescriptivo, de manera que ayuda a las compañías en su madurez hacía la Agilidad en todos los niveles.
Áreas (de arriba a abajo: Visión, Estrategia y Táctica) que cubren los cuatro marcos:
Verde = cubre, Amarillo = cubre parcialmente, Rojo = no cubre

La imagen de edificio es una cortesía de Pixabay
Resaltar que entre estos marcos no hay ninguna bala de plata con soluciones milagrosas, son marcos de los que se pueden coger las partes que convienen y adaptarlas, pero cuidado, siempre dentro de la madurez ágil.

Veamos los cuatro marcos más en detalle:

Nexus

Nexus es el marco escalado de Ken Schwaber pensado para 3 a 9 equipos de Scrum, equipo de equipos que forma la unidad de desarrollo. Añade un "equipo de integración" que se centra en las dependencias, la interoperabilidad y la integración de código entre los equipos de Scrum. "El Equipo de Integración Nexus consiste en individuos que son expertos en el uso de herramientas y prácticas asociadas con el trabajo de desarrollo escalado".

Todos los equipos parten de la misma pila de producto y tienen pilas de sprint individuales que se manejan de forma agregada en el "Nexus Sprint Backlog", pila con la que se da visibilidad de forma integrada del trabajo que están realizando los equipos.

Contiene los eventos formales de Scrum a nivel de coordinación y le añade "Nexus" como prefijo, significa literalmente nexo o punto de conexión y es el mecanismo o nombre para el Scrum de Scrums. Por ejemplo "Nexus Scrum Diario" contiene representantes de cada equipo individual de Scrum.
Nexus, el marco que lleva al corazón del escalado de Ken Schwaber
¿Cuales son los valores de Nexus? Los mismos cinco que Scrum: 1) foco 2) coraje 3) franqueza 4) compromiso 5) respeto.

El marco no trata otras consideraciones organizativas como la estructura organizativa, como lo hacen DAD y SAFe.

LeSS (Large Scale Scrum)
LeSS, el marco de Craig Larman y Bas Vodde
para productos menores de hasta 8 equipos

Para la adopción de LeSS la compañía ha de comprender primero los propósitos y elementos de Scrum para un sólo equipo, y escalar a partir de ese punto, manteniendo el propósito dentro de las restricciones de los roles de Scrum formal.

Craig Larman y Bas Vodde crearon este marco para gestionar grandes proyectos dentro de las limitaciones del "Vainilla-Scrum", el Scrum más puro, y han creado con LeSS una elegante extensión de Scrum. Se han desarrollado dos marcos en función del tamaño del proyecto a desarrollar.

Debido a que estos dos marcos, LeSS y LeSS Huge, permanecen fieles a las restricciones de Scrum, LeSS no puede ser considerado como una práctica, sino un marco de diseño de la organización.

LeSS Huge, el marco de Craig Larman
y Bas Vodde para grandes productos
LeSS es para proyectos de hasta alrededor de 8 equipos. Las funciones básicas no han cambiado, pero algunas la de las reuniones cambian y algunas se replican a nivel de equipo cross. Por ejemplo, la planificación del sprint se divide en dos; la primera es una reunión para todos los equipos en donde elijen las historias de usuario en las que van trabajar, y las segunda es una reunión separada por equipo en la que cada equipo crea su plan de sprint. De modo análogo hay una una retrospectiva cross con representantes de cada equipo para facilitar la mejora continua global. Los equipos están organizados como equipos funcionalidades, de extremo a extremo. Se pueden añadir otras reuniones de coordinación entre equipos, por ejemplo en forma de Scrum de Scrums y reuniones Open Space.

LeSS Huge está diseñado para proyectos aún más grandes, con alrededor de un millar de personas para un solo producto. Este marco añade una función adicional, el propietario del área de productos, que asume la propiedad del producto de una sección importante del producto. También se añade una revisión de sprint y una retrospectiva generales para garantizar la coherencia del producto y la mejora de procesos global.

¿Cuales son los valores de LeSS? Los mismos cinco que Scrum: 1) foco 2) coraje 3) franqueza 4) compromiso 5) respeto.

DAD (Disciplined Agile Delivery)

Este marco de proceso de Scott Ambler y Mark Lines, en su versión 2.0, es "un marco de segunda generación que pugna por ofrecer una estrategia de extremo a extremo coherente con las prácticas de entrega de soluciones ágiles, con un enfoque ágil híbrido para entrega de soluciones IT basado en personas y orientado al aprendizaje. Cuenta con un ciclo de vida de riesgo-valor, está orientado a objetivos, y tiene en cuenta toda compañía". 

¿Qué valora DAD? Las cuatro prioridades principales son las siguientes: 1) Las personas primero 2) orientado al aprendizaje 3) ágil y 4) híbrido.

Híbrido significa que el DAD también recurre a otras fuentes más tradicionales, como un proceso unificado para la gobernabilidad y la gestión del ciclo de vida. Los proyectos se dividen en tres fases, Incepción, Construcción y Transición. En comparación con Scrum, DAD pone más énfasis en la arquitectura y la reducción del riesgo técnico a través de la designación de un Propietario de Arquitectura. DAD también cambia muchos de los nombres de Scrum, por ejemplo el Scrum Master se llama Líder del Equipo.
DAD 2.0, el marco desarrollado por Scott Ambler y Mark Lines, cómo metodología para IBM Rational
Uno de los puntos débiles de DAD es que, al ser híbrido, habla de fases, y eso puede anclarnos en la mentalidad de proyectos en cascada.

SAFe (Scaled Agile Framework)

Como lo describe su creador Dean Leffingwell, SAFe 4.0 es "una base de conocimiento expuesta libre y públicamente de patrones probados para la implementación de software y sistemas de desarrollo Lean-Agile a escala de la compañía. Provee de una guía exhaustiva para trabajar a niveles de la Cartera de la compañía, los Flujos de Valor, los Programas y los Equipos".

A nivel de equipo se acreca mucho a Scrum y Kanban, incluyendo las prácticas de XP. No todos los sprints producen necesariamente un incremento potencialmente desplegable en producción, aunque las entregas ocurren con frecuencia.

A nivel del programa los esfuerzos de los equipos ágiles están alineados e integrados para atender las necesidades de la empresa y sus grupos de interés. SAFe ofrece una buena cantidad de detalles sobre cómo hacer esto.

A nivel de flujo de la valor SAFe da independencia presupuestaria y táctica a las diferentes lineas de negocio de la compañía.

El nivel de la cartera ofrece estrategia y a alineación de objetivos entre los niveles de inversión y los niveles operativos de la organización.

¿Qué valora SAFe? Incorpora el pensamiento Lean, los principios de flujo de desarrollo de productos y los amplios beneficios que el desarrollo ágil (Manifiesto Ágil, Scrum, Kanban, prácticas técnicas XP), pero lo que realmente valora son: 1) Alineación 2) Calidad Built-In 3) Transparencia 4) Ejecución del Programa.

Para empresas que no dividen su estrategia por lineas de negocio y con un flujo de valor de alrededor de 120 personas, SAFe propone una versión del marco colapsada sin el nivel de flujos de valor:
Big picture con la versión 4.0 del framework de Dean Leffingwell colapsado a tres niveles
Para grandes compañías, las más grandes a nivel mundial, con más de un flujo de valor y con más de 120 personas en cada uno, SAFe propone una versión del marco expandida:
Big picture con la versión 4.0 del framework de Dean Leffingwell expandido a cuatro niveles
Después de su implementación exitosa en grandes empresas de todo el mundo, SAFe está recibiendo mucha atención, y como todo lo que se sitúa en el foco tiene que enfrentarse a críticas de los expertos ágiles mas reconocidos en todo el mundo.

Agradecimientos a Peter Stevens por su artículo "Scaling Scrum: SAFe, DAD, or LeSS?" del que he aprendido mucho para escribir este post.

domingo, 14 de febrero de 2016

¿Es necesaria la formación en Scrum para iniciar desarrollos con este marco?

¡Absolutamente! Scrum es un marco de trabajo con un proceso muy simple, pero muy difícil de implementar, pone al descubierto los problemas sistémicos de la compañía, por tanto la transformación a Agilidad es un cambio sustancial y la compañía debe de sobrevivir a la resolución de estos. 

La formación es fundamental para que equipos, Propietarios del Producto, interesados y líderes adopten una mentalidad Lean-Agile, comprendan los valores y principios ágiles y cómo su práctica puede mejorar sus productos, junto con la adopción de la perspectiva de la experiencia del cliente. También es importante que entiendan sus nuevas funciones y responsabilidades, y cómo ejecutar las prácticas de Scrum para obtener el máximo valor en todo momento. Muchas veces, aunque todo el mundo tenga experiencia “desarrollando ágil” no se puede asumir que tengan la necesaria, recordemos que para que funcione Scrum y resulte en proyectos exitosos es necesario implementarlo al 100%.

Esta formación también sirve para garantizar que todo el mundo juegue con las mismas reglas y tenga expectativas similares de lo que es Scrum. Por ello lo ideal es que todos los involucrados reciban primero una formación formal tipo certificación, y esta sea reforzada por agentes de cambio internos de la empresa, como un Scrum Master o un coach ágil. Estos pueden ofrecer las singularidades propias de la compañía aprendidas en proyectos de éxito. De ser una empresa que inicia sus primeros pasos en Scrum esta formación debe de darla un trainer experimentado en Scrum, uno que haya invertido tiempo en la comprensión de la organización.

La empresa deberá de considerar la formación continua para asegurar que nuevos interesados entiendan el fundamento y las expectativas de la organización como un todo.

En la cultura de las TI españolas es usual la formula de clientes y consultoras, en la que el cliente contrata recursos o equipos a la consultora para desarrollar un proyecto. Me he encontrado con equipos a los que he aconsejado fervientemente formarse, he visto adopciones de los artefactos de Scrum que pueden aportar algo, pero que no tienen nada que ver con Scrum.

Hay casos en que la consultora ha formado al equipo y estos se han convertido en equipos ganadores, pero también hay casos en que los equipos se encuentran en una situación de abandono. La consultora más tradicional no invierte en formación por considerar que el proyecto es finito en el tiempo, y una vez acabado al fin y al cabo el equipo se desmontará y sus miembros se integrarán en otros equipos. El cliente tampoco invierte en formación a empleados que al fin y al cabo no son suyos.

Ante situaciones como esta invito al equipo a formarse en nuestra plataforma on-line de Scrum Manager con sus cursos gratuitos que siempre refuerzo con la mentalidad ágil del Manifiesto y con algún taller en alguna sala de reuniones al mediodía o al finalizar la jornada laboral.
El autor entrenado a un equipo en un simulación de 3 sprints