Agile a escala

Como ayuda SAFe a las organizaciones

Como ayuda SAFe a las organizaciones. SAFe combinado con Lean, permite a las organizaciones escalar los beneficios de Lean y Agile en todos los niveles de la organización, creando eficiencias y vinculando la estrategia a la ejecución.

Artículo escrito por: Victor Fairén

Algunas estadísticas (anecdóticas)

En la página oficial podemos encontrar algunos resultados del impacto de SAFe en las organizaciones que lo usan. Estas métricas se centran en 4 aspectos fundamentales del negocio y los equipos: tiempo de puesta en el mercado, Calidad, Productividad y compromiso.

Los resultados típicos que se reportan a Scaled Agile Framework (SAFe) incluyen:

20 – 50% incremento de la productividad
25 – 75% mejora en la calidad
30 – 75% menor tiempo de salida al mercado
10 – 50% incremento en el compromiso de los trabajadores y su satisfacción laboral.

Está demostrado que el uso adecuado de SAFe para escalar las prácticas Lean y Agile, ayuda en los aspectos anteriormente mencionados. Aunque los porcentajes son poco rigurosos de acuerdo con el método científico.

Con SAFe, el trabajo duro vale la pena incluso en las primeras etapas de una implementación. La mayoría de las organizaciones ponen SAFe en práctica de forma incremental, a veces con solo un lanzamiento de un Tren ágil (ART) y algunos equipos. Este tipo de implementación ha demostrado una y otra vez que conduce a ganancias tempranas y, sobre todo, ganancias sostenibles a largo plazo.

¿Por qué los negocios necesitan SAFe?

Las empresas deben aprender a adaptarse rápidamente a los cambios tecnológicos y las condiciones económicas o se extinguirán, sin importar su tamaño, inteligencia o fortaleza. Esto es válido incluso para empresas que no se consideran empresas de tecnología de la información (TI) o software. Los servicios profesionales, los servicios financieros, las instituciones de atención médica y las entidades gubernamentales dependen en gran medida de su capacidad para producir nuevos productos y servicios basados en tecnología.

Las empresas que entienden la urgencia de moverse y adaptarse más rápido, y cambiar sus formas de trabajo, tendrán éxito. Los que no lo entienden, luchan, o simplemente se desvanecen. El mundo de los negocios está plagado de ejemplos: Blockbuster, Kodak, Palm Computing y Compaq fueron líderes icónicos del mercado que no pudieron adaptarse a los nuevos modelos comerciales e innovaciones tecnológicas por delante de sus competidores.

Scaled Agile Framework (SAFe) ayuda a las empresas a abordar los grandes desafíos de desarrollar y entregar software y sistemas en el menor tiempo de entrega sostenible. Es como una base de conocimiento en línea, libre, con patrones de éxito comprobados para implementar escalación de Lean-Agile a nivel compañía. SAFe combina el poder de Agile con pensamiento sistémico y desarrollo de productos Lean. Sincroniza la alineación, la colaboración y la entrega para múltiples equipos ágiles. Como resultado, SAFe proporciona grandes mejoras a la agilidad del negocio, incluida la productividad, el tiempo de comercialización, la calidad y el compromiso de los empleados, y más.

¿Por qué las empresas utilizan SAFe?

Aquí listaremos una serie de razones por la cuales las que SAFe es esencial para los equipos Agile y porqué deberían incorporarse para ayudar a alcanzar tus objetivos de negocio.

Fomenta la rápida adaptabilidad a los cambios tecnológicos y las condiciones económicas.
Promueve la colaboración y la transparencia entre el desarrollo y la alta dirección.

Asegura la obtención de valor de negocio en el menor tiempo sostenible.
Asegura un enfoque consistente hacia la planificación, ejecución y entrega.
Independientemente del tamaño de la empresa, SAFe permite la escalabilidad y la configuración que se adaptan a las necesidades de su negocio.
Los equipos ágiles multifuncionales entregan software de trabajo cada dos semanas.
La piedra angular de SAFe es la cadencia de la sesión de Planificación de Incremento de Programa (PI) donde los equipos ágiles se unen para definir los objetivos que desean alcanzar en un período de tiempo fijo. Esto da como resultado sesiones presenciales, colaborativas, interactivas e innovadoras que crean espíritu de equipo y sinergia.
Promueve la alineación de estrategia, visión y arquitectura entre el desarrollo y los equipos gerenciales.
La integración y validación continua entre los equipos ayudan a reducir los riesgos.
Proporciona una mejora significativa en la productividad del negocio, la calidad, el compromiso de los empleados y el tiempo de comercialización.
El uso de Scrum-of-Scrum en Agile Release Team mantiene al equipo sincronizado entre sí.
Promueve la innovación.

Artículo escrito por: Victor Fairén

Cómo formar equipos ágiles trabajando con Scrum

Conformar equipos ágiles cuando estamos trabajando con Scrum es un reto. ¿Cómo decidimos quien debe ir en cada equipo? ¿De que manera podemos extender Scrum a la organización y mantener la agilidad?

Hace unas semanas durante una charla para OnTech Innovation una de las asistentes me lanzaba esta pregunta en Twitter.

Jeronimo, por favor me indicas si existen técnicas de división de equipos, cuando ya se trabaja Scrum y Kanban? Escuchamos sobre la técnica (split and seed – split and grow) pero no encontramos casi información del tema. Gracias

— Monica Martinez H (@monicaromartine) September 26, 2019

Equipos auto-organizados. No equipos donde todo el mundo haga de todo.

Cuando usamos Scrum para lidiar con problemas complejos, podemos caer en dos tentaciones diametralmente opuestas: Distribuir el trabajo en trozos de acuerdo a los equipos que tenemos actualmente (Fron-end, Back-End, Data, etc…) e ir haciendo Sprints en el que el trabajo de unos recae en otros.

Otra opción es tener equipos donde todo el mundo haga de todo. En realidad, en Scrum no es ni lo primero, ni lo segundo, ni nada en medio de los dos.

Cuando Scrum fue descrito por primera vez en el New New Product Development Game, los investigadores Takeuchi, Nonaka y Ken-Ichi Mai observaron que los equipos de alto rendimiento que estudiaban tenían precisamente todos los perfiles que necesitaban para entregar algo terminado, funcionando y que el cliente valorara en un periodo muy corto de tiempo.

¿Como podemos conseguir identificar cuales son las skills necesarias para entregar un incremento de valor, terminado, en 30 días o menos? Es más fácil de lo que creemos. Sólo hay que preguntarle al equipo que trabaja en ese producto.

A pesar de que pueda parecer sorprendente, las personas que desarrollan un producto son las que más saben cómo organizarse para sacarlo adelante.

Para aquellos que temen que los techies se centren sólo en su área, esa es precisamente una de las problemáticas que resuelve Scrum.

Scrum proporciona los límites, la transparencia y la capacidad de inspección y adaptación para asegurar que la auto-organización funciona. Cuando un equipo de desarrollo tiene que entregar un incremento terminado en 30 días o menos, pone el foco en qué necesita para que eso ocurra.

Hace un año y medio, escribí un artículo sobre las diferencias entre distintos tipos de diseño de equipos.

En realidad nada ha cambiado mucho desde entonces, más allá de que sigue siendo difícil entender que para cambiar nuestra forma de entregar valor a los clientes, tenemos que cambiar la forma en que organizamos el trabajo.

Split and Seed y Seed and Grow.

Cuando nos planteamos escalar Scrum a distintos equipos de nuestra organización, se suele acudir a los métodos por los que Mónica pregunta en su Tweet: Split and Seed y Seed and Grow.

Con este método, se toma un equipo pequeño que establece un núcleo o un core y se divide.

En el primer caso (Split and Seed), una vez que el equipo está establecido, se divide en dos equipos que se utilizan como base para hacer crecer otros equipos, a modo de mitosis de equipo.

En el segundo caso (Seed and Grow), se toman algunas personas de un equipo que ya está funcionando y se utilizan como semilla para hacer crecer otro equipo, a modo de esqueje.

Este método plantea dos problemas: ¿Quien decide como se mueven los miembros de un equipo a otro? ¿El Agile Coach, el Scrum Master, el Propio Equipo?.

El segundo problema es que podemos partir de un equipo de alto rendimiento para terminar con dos equipos mediocres o que no funcionen en absoluto.

El método del becario

Una alternativa, que Jeff Sutherland llama “El modelo del amigo del equipo”, es introducir a un nuevo miembro del equipo de desarrollo, que se encarga de empaparse de la cultura, forma de trabajo y experiencia del mismo con el objetivo de graduarse y formar su propio equipo más adelante.

Un equipo de desarrollo identifica uno o varios compañeros, que trabajaran con ellos durante un periodo de 4 a 6 sprints.

Su papel durante este tiempo será aprender y participar en las actividades del equipo sabiendo que su permanencia tiene una fecha de caducidad en el tiempo. Cuando pase ese tiempo, serán los encargados de ser el pilar fundador de un nuevo equipo.

En ocasiones a estos equipos que admiten nuevos miembros se les llama “Equipos de bienvenida” o “Training Teams” y tienen una alta cultura de colaboración que puede ser expandida a nuevos miembros.

La decisión del número de Sprints que permanecen en el equipo es una decisión personal. Cuando están listos, pueden migrar al nuevo equipo.

La ventaja de este método es que asegura que no se rompe un equipo de alto rendimiento ya existente, tiene un impacto menor en el delivery actual y permite un crecimiento de acuerdo a las capacidades de contratación de la organización. Sin embargo, es un método extremadamente lento para aquellas organizaciones que quieren escalar Scrum rápidamente.

El observador

Otra opción, basada en el modelo anterior, es incorporar nuevos miembros como observadores. La principal diferencia es que mientras en el método del becario participan activamente de las labores, entrega y eventos del equipo, en este modelo sólamente actúan como observadores.

La principal ventaja de esta última opción es que la incorporación de un observador es mínimamente disruptiva.

Pueden continuar con se trabajo como hasta ahora sin tener que centrarse en enseñar a un nuevo miembro del equipo.

A pesar de todo, el efecto del observador puede ser disruptivo para equipos existentes. A nadie le gusta sentirse observado.

Puede tener consecuencias inesperadas cuando los nuevos miembros crean sus equipos e implementan lo que creen que han observado.

Lo más importante: Medir Siempre

Durante todo el proceso de escalado a equipos con Scrum, es importante medir el estado y la salud del equipo. El health check de Henrik Knieberg en Spotify puede ser un buen comienzo. La importancia de medir el estado de los equipos radica en que una manzana podrida en una cesta de fruta acabará rápidamente con todos los esfuerzos por mantenerla en buen estado.

Lamentablemente el crecimiento rápido en pocas ocasiones tiene buenos resultados. Si además se están adoptando prácticas que requieren de un alto grado de auto-organización, como Scrum, es necesario dejar que los equipos y la organización maduren a su propia velocidad.

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.

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.

Especializaciones y caminos para agilistas

Me gustaría empezar con un disclaimer: Todo esto puede sonar muy endogámico, pero la realidad es que sólo puedo hablar de lo que conozco. Desafortunadamente no conozco todo lo que las personas que están en esta industria hacen o preparan. Si crees que me falta algo, déjame un comentario para intentar mejorarlo.

Vamos allá.

Agile o no Agile

Una consideración inicial. Siempre que un compañero me dice que no sigue ningún método, que en realidad es Agile, me recorre algo entre una carcajada y un escalofrío.

Normalmente tras esa afirmación viene una explicación acerca de por qué los frameworks y métodos no son suficientes y que lo importante es hacer Agile. Mira, esto es simple, Agile, el manifiesto ágil es sólamente una declaración de intenciones, elaborada por unos locos que se reunieron en una estación de esquí para intentar cambiar la industria del desarrollo de software.

Esa declaración de intenciones está muy bien, pero si no eres capaz de explicarme qué haces para implementar Agile, mi conclusión es que te has inventado una nueva religión a tu medida porque no te convencen las existentes -o porque es más fácil que aprender las existentes-. Ésto está bien como decisión personal pero mal como decisión que tomas por tu organización o cliente. Hacer Agile es como decir soy buena persona. Como declaración de intenciones está bien, pero existe un sistema social -con un montón de normas- que es el que tiene que juzgar esa afirmación.

Detrás de cada método, framework o librería, hay cientos de miles de horas de profesionales con mucho conocimiento para destilar lo mejor de su experiencia. Si alguien piensa que es capaz de superar eso, es que quizás delire un poco.

Así que si no tienes mucha idea de Scrum o Kanban o XP, te recomiendo que no digas que haces Agile para compensar. Igual en tu imaginación queda bien, pero a los demás nos da un poco de vergüenza ajena.

En su lugar, se honesto y plantéate qué puedes hacer para mejorar tu conocimiento.

Aprender los básicos

El movimiento ágil viene -y se ha popularizado- desde el mundo del desarrollo de Software. Probablemente la gestión de proyectos de Software ha sido la industria más abusada y maleada de toda la historia de las profesiones de conocimiento en los últimos 50 años. éstos locos que se reunieron para elaborar un manifiesto que les permitiera cambiar la industria terminaron con esta declaración de intenciones. El problema es: Ahora que tenemos las intenciones ¿Cómo las ponemos en marcha?

Hay algo que no he contado. En lugar de reunirse y ver como cambiar la industria, el panorama era distinto. Lo que ocurría es que muchas de las personas alli presentes habían creado métodos para hacer Software de manera distinta: Scrum, XP, Crystal, DSDM… Lo que hicieron en realidad fue ponerse de acuerdo en lo que sus métodos tenían en común. Y de ahí salió el manifiesto ágil.

Scrum: Scrum es el método ágil más popular y más usado a nivel mundial. Si te consideras agilista, tienes que saber Scrum y es un buen comienzo. La guía de Scrum es el documento que sienta las bases sobre el marco de trabajo y las certificaciones más comunes son el Professional Scrum Master de Scrum.org y el Certified Scrum Master de la Scrum Alliance. Puedes ver sus diferencias aquí
XP: XP ha sido la referencia de muchos desarrolladores desde mucho antes que Scrum. Creado por Kent Beck, sigue siendo una referencia para la excelencia técnica. Muchas de sus técnicas, como las historias de usuario, han despegado y hoy son incluso más conocidas que el propio método. XP es una colección de técnicas más que un método compacto. La principal referencia monumental es el libro eXtreme Programming. Ahora mismo no conozco ningún buen curso en España para aprender XP.
Kanban: Kanban es más que conocido en el mundo Lean y TPS (Toyota Production System). El método aplicado al desarrollo de Software se popularizó a raíz del trabajo de David J. Anderson y Daniel Vacanti en AT&T. Posteriormente han evolucionado por caminos distintos, dando lugar el trabajo de Anderson a la Lean Kanban University y el de Vacanti a una colaboración con Scrum.org. El texto de referencia es el Blue Book de Anderson y la Essential Kanban Condensed. Un buen punto de partida para aprender es el Team Kanban Practitioner de la LKU o el Professional Scrum with Kanban de Scrum.org (PSK).
DevOps: DevOps no es ni un método ni un marco de trabajo. Es un movimiento que ha tomado fuerza desde 2011 en adelante y promueve una serie de prácticas para integrar las operaciones y el desarrollo de Software, rompiendo los silos existentes en grandes organizaciones haciendolas más ágiles. Aunque DevOps está muy orientado a la parte técnica, es necesario sponsorship del liderazgo de la organización para poder lanzar una iniciativa de este tipo. Un texto de referencia es el DevOps Handbook y un buen curso de iniciación es el DevOps Leader del DevOps Institute.

La parte de producto

Ningún método ágil va a funcionar si no somos capaces de cerrar el gap existente entre IT y Negocio. Y ese gap se llama producto. Algo que en muchas organizaciones directamente no existe y es lo que aúna esas dos patas y permite establecer métricas más ágiles en la organización. Los técnicos deben de dejar de mirar a negocio como si fueran vendehumos y los de negocio tienen que dejar de mirar a los técnicos como extraterrestres.

Product Ownership: Utilices el método que utilices en tu organización, es necesario conocer técnicas para desarrollar un producto. En general, cuando hablamos de proyectos hablamos de cómo gastar dinero y cuando hablamos de producto, de como ganarlo. Eso lleva a un cambio de mentalidad en el que pasamos de pensar en Alcance, tiempo y coste para empezar a pensar en Usuarios, retención o ingresos. El libro Product Ownership de Robert Galen es un buen punto de partida. También el Professional Scrum Product Owner de Scrum.org.
¿Como ampliar? User Story Mapping, Impact Mapping, Business Model Canvas, Value Proposition Canvas, Lean Canvas, Innovation Games o Lean Startup. Portfolio Management es un plus necesario cuando trabajamos con varios productos a la vez.

En general veo a la gente de producto muy verde a la hora de manejar técnicas que permitan sacar el máximo partido de su inversión (habitualmente dinero en forma de tiempo de desarrolladores). Lo que me suelo encontrar es con visionarios que pretenden que otros ejecuten, con una capacidad bastante limitada para transmitir su visión. Todas estas técnicas ayudan a poder entender al usuario y transmitir esa visión para poder crear productos del máximo valro posible.

Escalando el desarrollo de producto

Una vez que tenemos un producto claro, un Product Manager competente y una manera de gestionar al equipo de desarrollo, es normal que queramos escalar nuestro esfuerzo para construir productos más grandes. Hay que entender que cuanto más escalamos, más lenta será nuestra velocidad por cada magnitud de escalado, debido a la complejidad añadida de tener a más personas en el mismo producto.

Nexus: Nexus es la propuesta de Scrum.org para escalar de 3 a 9 equipos de 3 a 9 personas a su vez. Equipos Scrum. La guía de Nexus se puede descargar gratuitamente de [la página de scrum.org] y su formación correspondiente es el Scaled Professional Scrum.
LeSS: Large Scale-Scrum es la propuesta de Craig Larman y Bas Vodde para escalar Scrum dentro de un entrono de desarrollo de producto. Mezcla cultura, gobierno y desarrollo de producto en un sólo método que es más prescriptivo que Nexus
SAFe: Scaled Agile Framework es una propuesta que no sólo escala el desarrollo de producto sino también el gobierno de la organización de desarrollo, integrando el gobierno de programa y portfolio. Su creador lo define como una librería, más que un método, pero en su última versión incorpora uan versión essential que describe el mínimo para ponerlo en marcha.
¿Como ampliar? El uso de Evidence Based-Management como marco de trabajo sobre métricas de valor es muy interesante, así como la introducción de Upstream Kanban para gestionar la demanda.

De estos tres métodos, puedes ver una comparativa en este artículo del blog.

Escalando la organización

El problema del escalado es que se produce en varias direcciones. Si escalar el desarrollo de producto es escalar verticalmente, escalar la organización que soporta ese desarrollo de producto es escalar horizontalmente. Se trata de crear la organización ágil, que de soporte a iniciativas que proporcionen respuestas rápidas a las necesidades del mercado.

SAFe: En su versión de programa y portfolio, SAFe pretende dar respuesta a las necesidades de gobierno de las organizaciones, escalando las iniciativas desde el budgeting hasta los equipos de desarrollo. La información sobre SAFe está contenida en la Big Picture de SAFe y el curso de referencia es el Leading SAFe 4.5.
El método Kanban: El método Kanban ha evolucionado durante los últimos años para proporcionar una solución más flexible a organizaciones que desean ser más ágiles sin sacrificar las estructuras, roles y títulos existentes, sino kanbanizándolos e introduciendo una cultura de la mejora continua (kaizen) a través de cadencias regulares. Además acaba de incorporar el Kanban Maturity Model (KMM) como herramienta para diagnosticar y mejorar la situación actual. Para aprender más sobre Kanban tienes la acreditación Kanban Management Professional que comprende los cursos Kanban Systems Design y Kanban Management Professional.
Scrum Studio: Esta propuesta apunta a la creación de iniciativas ágiles a través de la creación de estudios de innovación, para vencer las resistencias tradicionales y crear algo que, junto a la organización, no se rige por las reglas habituales de la misma. Puedes ver mi charla sobre Scrum Studio en la última CAS en Youtube. Ahora mismo, además de un whitepaper que estamos preparando

Entendiendo la complejidad

Systems Thinking: El efoque sistémico y sus herramientas son necesarias en entornos de alta incertidumbre como son los de desarrollo de producto. Aunque no tengo una referencia clara para recomendar, es algo a tener en cuenta a la hora de especializarse.
Cynefin: La propuesta de Dave Snowden es un marco de trabajo para la toma de decisiones en entornos complejos. Mediante el análisis de patrones, Snowden recomienda la toma de decisiones basada en el dominio del problema, lo que nos permite atacar problemas concretos con herramientas adecuadas.
Lean Product Development Flow: Don Reinertsen lleva 30 años estudiando y enseñando los principios económicos que subyacen a métodos como Lean y aplican al desarrollo de productos. Mediante el análisis y el uso de herramientas lógico-matemáticas, proporciona una visión del desarrollo de software desde una perspectiva muchas veces olvidada: la de la economía.

La parte de personas

A pesar de haberla dejado para el final, la parte de personas es una de las más importantes de todo esto. El cambio cultural que supone la agilidad en una organización es un reto que no muchos están capacitados para afrontar. En este sentido, nada de lo que hay en el sector realmente me gusta y me iría al mundo del coaching tradicional.

Inteligencia emocional: Para poder lidiar con las emociones de los demás, tenemos que estar preparados nosotros emocionalmente. Asistir a una formación en inteligencia emocional es clave para entender los procesos internos que nos gobiernan y ponernos a prueba. Estas formaciones suelen ser muy vivienciales e intensas, y no las recomendaría a todo el mundo
Coaching personal y ejecutivo: Aunque el coaching es una de esas herramientas denostadas, los programas certificados de coaching de AECOP o ICF suponen un buen punto de partida para el aprendizaje de herramientas soft que nos permitan realizar mejor nuestro trabajo.
Agile Coaching: El Agile Coaching institute tiene programas para el desarrollo de distintas áreas de Agile Coaches. No los conozco personalmente y no tengo suficientes referencias como para opinar.
¿Como ampliar? Un programa de coaching completo, la facilitación gráfica, training from the back of the room o mindfulness pueden ser buenos complementos a esa parte de soft skills.

Yo tengo un sesgo claro. En el año 2011, cuando ya llevaba tres o cuatro años introduciendo Scrum en organizaciones, me di cuenta de la oferta tan pobre que había en torno a todo esto. Después de hacer un programa de coaching personal y ejecutivo de dos años (soy coach certificado por AECOP y el European Council of Mentoring and Coaching), decidí cursar el grado de Psicología por la UNED. Hoy me quedan un par de asignaturas y el TFG, que espero presentar en 2019.

Probablemente me he dejado mucho en este intento de aunar un montón de ideas que en ocasiones están inconexas, pero en general estoy contento con el resultado. Si te ayuda a entender mejor los pasos a seguir en este mundillo, entonces habrá cumplido su cometido. Por útlimo, mucho cuidado con las ensaladas de cosas, o podemos acabar como Deloitte:

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.