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: