De qué hablamos cuando hablamos de Valor

Uno de los factores que nos motivan a los seres humanos, luego de tener satisfechas nuestras necesidades básicas, es el valor que podemos aportar al mundo que nos rodea. Necesitamos que el resultado de nuestro trabajo tenga una retribución o reconocimiento. Además de eso, a muchos nos gustaría que ese trabajo genere valor. Es más: en muchas ocasiones, el trabajo que hacemos no tendría sentido si no aporta valor.

Antes de entrar de lleno a darle un enfoque más cercano a la agilidad o la entrega de valor desde un producto/servicio no sobra abordar el término desde las ciencias del comportamiento humano, que habla de cuatro ejes sobre los que los seres humanos contemplamos el valor: desde el dinero, el tiempo, el impacto y la perspectiva. Aparentemente, después de estudiar la valía que le damos a las cosas, esos cuatro caminos definen en buena medida lo que consideramos como valioso o que tiene valor.

El valor se pone en marcha dentro de un contexto y nuevamente, desde esa mirada comportamental, se habla de dos sistemas sociales donde el valor se puede medir: Sistemas de Retorno (de Valor) Inmediato y Sistemas de Retorno (de Valor) Diferido. En la medida que podamos comprender el marco de ese sistema podemos abordar el valor como un punto de partida para comprender el porqué de muchas de las acciones que ponemos en marcha. Desde la creación de soluciones y en un contexto laboral, la lectura de valor puede ser distinta.

El ciclo de de vida productos se divide en diversas etapas: prototipado, introducción, crecimiento, maduración, declive. La definición de valor y el (los) KPI medido(s) depende en qué etapa se encuentra dentro del ciclo de vida y del tipo de producto (por ejemplo, e-commerce, B2B, B2C, SaaS, etc).

A veces se puede medir o calcular y otras veces sólo se puede estimar.

  • ¿Qué significa valor?
  • ¿Cuánto valor entregó el proyecto?
  • ¿Para qué lo queremos medir el valor generado?
  • ¿Cómo se puede medir o calcular ese valor?
  • ¿Cuánto valor entregará este equipo durante el próximo es?
  • ¿Podemos estimar el valor que obtendremos?
  • ¿Cómo se puede estimar ese valor?

Si alguna vez te hiciste alguna de estas preguntas, este artículo es para vos.

El concepto de valor es lo que intentaremos comprender más profundamente en este artículo. Intentaremos visualizarlo y analizarlo desde diferentes perspectivas: Qué, Para Quién, Para Qué, Cuándo y Cómo.

Pretendemos que el análisis aplique tanto a desarrollo de productos de software como también a otro tipo de proyectos.

Qué

“El concepto de Valor de Negocio (Business Value) representa el beneficio al cual accede una empresa, institución o grupo de usuarios cuando se disponibiliza una nueva funcionalidad del software para su uso productivo” de Thomas Wallet.

Los usuarios del producto construido o del servicio diseñado valoran el trabajo de un equipo cuando les permite realizar mejor su trabajo, por ejemplo: más eficientemente.

Las personas de negocio que decidieron invertir (tiempo, dinero, capacidad productiva) también valoran el trabajo de un equipo cuando les permite recibir un retorno de la inversión realizada. Este retorno es el valor que pretendemos conocer, cuantificar, medir, entender. A veces tiene forma de ahorro de tiempo o dinero, otras veces tiene forma de ganancias de dinero o de cantidad de usuarios, por poner algunos ejemplos concretos.

El valor entregado será consecuencia del impacto (o los impactos) que se genere(n).

Para quién

Negocio

Sponsors / Inversores / Stakeholders

Product Owners “Estratégicos”, más orientado a ayudar a definir la visión, el roadmap del producto basado en el valor de negocio, apoyándose en enfoques más  experimentales y trabajando más del lado del negocio.

El Product Owners “Operacionales” que trabaja más cerca del equipo refinando el Backlog, aclarando y detallando las Historias de Usuario.

Usuarios – Consumen producto o servicio.

Lo que construye el equipo debería ser algo que le sirva al usuario final, que le sea de utilidad, que termine adorando. No solamente es lo que se quiere o desea, sino lo que se necesita. Posiblemente no sea lo que exprese en los requerimientos. En estos contextos son útiles las técnicas de descubrimiento (discovery) de User eXperience (UX).

Equipo

Los equipos de trabajo valoran que su entregable sea valorado. Además les ayuda a entender los criterios de priorización del Backlog.

Para qué

  • Para priorizar (iniciativas; proyectos de una cartera o portfolio; o requerimientos de un Product Backlog).
  • Para decidir si considerar o descartar el proyecto o funcionalidad.
  • Motivacional (un equipo que conoce sus impactos trabaja mejor).
  • Un punto de referencia (para saber cómo venimos con respecto a nuestros desafíos y nuestro pasado inmediato).

Cuándo

Determinar cuándo medir el valor entregado depende de las características del proyecto.

Un proyecto aporta valor al ser liberado el producto, el servicio o el aprendizaje que busca obtener. El momento en el que se genera la liberación de ese resultado es una buena instancia de medición. Hay proyectos en los cuales hay entregas intermedias y otros en los cuales se ven resultados solamente al final. Cuanto antes ocurra la liberación, antes se podrá medir o calcular el valor entregado, a partir del impacto generado.

Sin embargo, muchas veces no se puede esperar hasta el final para medir o calcular el valor entregado. Es para eso que se recurre a técnicas que permiten estimar dicho valor.

Cómo

Un punto inicial para medir o estimar el valor de negocio es hacerlo lo más simple posible, esto se puede realizar cuantificando los beneficios en dinero. Para esto se podría considerar: optimización de un proceso, ahorro de tiempo, impacto generado (cantidad de nuevos usuarios a partir de la liberación, cantidad de transacciones) y otros indicadores que puedan aplicar en cada caso.

El siguiente paso es experimentar con otras formas de medir el valor e incluso crear una técnica propia de medición.

  • Algunas técnicas que permiten medir el valor de negocio
    • Asignar rangos de valores (oro, plata, cobre, madera)
    • Priorizar con naipes o billetes
    • Ponderando criterios
    • Matriz de comparación
    • Estimar el valor relativo en $ comparándolo con otro producto que conocemos su valor
    • Modelo Kano: para entender qué es lo que el cliente quiere.
    • WSJF: costo del retraso.

Dos técnicas (más amplias y abarcativas que las anteriores), que nos permiten aprender qué aporta valor a nuestros clientes y usuarios, son Design Thinking y Lean Startup, pues proponen tener interacción temprana con ambos públicos y realizar experimentos con prototipos simples, en ciclos cortos, con feedback frecuente y de calidad.

Más allá de las técnicas existentes, cada organización deberá encontrar su mejor forma para estimar y medir el valor: “Necesitamos mapas (modelos) y necesitamos recorrer el territorio. Una de cal y una de arena“. Organizaciones que aprenden en base a crear ambientes de trabajo seguros donde se dan equipos empoderados que se permiten experimentar.

Este artículo fue escrito en equipo por Roberto Mejías, Pablo Lischinsky, Pablo Tortorella, Leo Barrientos y Juan Daza Arévalo.

Es un resultado tangible y una suerte de resumen de una valiosa conversación que ocurrió en el grupo de Telegram de participantes del evento Agile Open Camp 2016 (AOC) realizado en Bariloche.

En ella también aportaron sus preguntas, referencias, opiniones y ánimos unos cuantos colegas latinoamericanos de la comunidad ágil, a saber: Tommy Christie, Florencia Rossi, Hiroshi Hiromoto, Lina Jervés, Diego Sánchez, Mauro Strione, Andrés Herrera, Juan Manuel Relloso, Deiby Od, Fernando Claverino, Alejandro Faguaga, Thomas Wallet, Felipe Talavera, Elias Molini y Sebastián Ghelerman.


Un tiempo después de escribir este artículo, leí una publicación de HBR en la cual se describen una jerarquía de 30 elementos que representan valor. ¡Lectura recomendada!

Anuncios

Scrum es un framework, no una metodología

photo_2016-11-01_14-18-28

Se dice que Scrum es un Framework [1].
Framework
es una palabra anglosajona que significa armazón, estructura o cimientos.

Lógica mediante: A entonces B. B entonces C. A entonces C…

Si queremos definir una metodología de trabajo para nuestro equipo, Scrum funciona como armazón de la misma. Si bien Scrum nos brinda ciertos elementos que ayudan a navegar la complejidad accidental de nuestros proyectos [2], nos deja en el umbral de la incertidumbre sobre el cómo llenar ese armazón. Es necesario complementarlo, está incompleto por diseño.

photo_2016-11-01_14-18-26 [1] “Scrum is a framework for developing and sustaining complex products.” http://scrumguides.org/

[2] https://es.wikipedia.org/wiki/Accidental_complexity


Artículo escrito en pares por Pablo Tortorella y Camilo Velásquez

Experimentos en el Backlog

No innovamos. Los agilistas no innovamos… tanto. A fin de cuentas, también somos seres humanos y nos cuesta salir de nuestra zona de confort.
Cuando un equipo decide adoptar Scrum, es habitual que coloque Historias de Usuario en su Product Backlog. En todo el mundo se hace así.

Algo ahí hace ruido: las Historias de Usuario sirven para construir cosas que ya están definidas. Cuando llegan a los equipos de desarrollo, alguien (el Dueño del Producto con los usuarios, por ejemplo) ya descubrió, entendió y detalló lo que se requiere construir. También se lo involucró al equipo de desarrollo, seguramente. Han utilizado buenas prácticas: una tarjeta, varias conversaciones y criterios de aceptación. Todo muy “INVEST”… para luego ir a construir algo. Algo que aportará valor.

Detengámonos ahí. En la certidumbre. Pretendida certidumbre. Pretendida.

Los productos y servicios que se construyen usando Scrum, no suelen tener alcance predefinido. No se sabe qué características agregarán más valor al usuario y al cliente. Por eso, cada vez más equipos utilizan Design Thinking para descubrir de forma temprana y Lean Startup para descubrir de forma evolutiva, aquello que les conviene construir.

En ese contexto de incertidumbre, proponemos colocar Experimentos en los Backlogs.

Así como las Historias de Usuario sirven para aclarar qué se debe construir, un equipo podría (¿debería?) tener en su Backlog, unos cuantos Experimentos. Tantos como dudas e inquietudes tengan. Los mismos le permitirán aprender más y de forma continua, temas relacionados con sus usuarios, las necesidades, el potencial de sus ideas y características. Y ese aprendizaje crecerá a lo largo de todo el proyecto.

Cada experimento tiene su hipótesis. Cada hipótesis supone un camino y un resultado. Pero no sabemos si eso ocurrirá o no. Entonces diseñamos y ejecutamos el experimento más simple posible.

Validamos o refutamos. Y aprendemos.

Las Hipótesis dejan de ser tal cosa. Ese abordaje minimalista y prudente nos provee aprendizaje. Ese aprendizaje nos permite avanzar… o cambiar el rumbo.

Si refutamos una hipótesis, habremos ahorrado tiempo y esfuerzo que hubiéramos dedicado a construir algo que no lo valía.

Por otro lado, una vez validada la Hipótesis de cierto experimento, se hará más visible la conveniencia de avanzar con el desarrollo más profundo de las características en cuestión.

Presentamos, además de la idea, un Canvas de Experimentos, para que los equipos lo utilicen para diseñar sus propios experimentos de forma simple.

Para que cada día haya más Experimentos en los Backlogs de los equipos.


Este artículo fue escrito a partir de la aplicación y refinamiento de estos conceptos en diversos proyectos e iniciativas, por parte de Rodrigo Monelos y Pablo Tortorella, Agile Coaches de Kleer.


Mi paso por Girardot – IV Foro de Ingeniería de Software

“¿Qué mejor para cerrar el mes de mayo, que un viaje a Colombia, para visitar la cálida ciudad de Girardot?” – pensé.

Y así fue que la Universidad Piloto de Colombia me invitó como conferencista de la 4ta edición del “Foro Internacional de Ingeniería de Software“, cuyo foco este año lo acaparaban el Emprendimiento y la Innovación Social.

En la puerta de la Universidad Piloto de ColombiaLlegué al aeropuerto internacional Bogotá El Dorado y dos personas de la universidad me esperaban: Leonardo Andrés (del área de Relaciones Internacionales) y Don Víctor (a cargo ni más ni menos de llevarme a la conferencia!).

Luego del viaje llegamos a la sede de la Universidad en la cual, esa misma tardenoche, comenzaría el Foro. Conocí las oficinas administrativas y a muchos de los docentes, administrativos y directivos en una amplia recorrida guiada por Carolina, también de Relaciones Internacionales.

En la apertura del Foro tuve una participación de aproximadamente 10 minutos, luego de que los organizadores dieran las palabras de inicio y que escucháramos las estrofas del Himno Nacional de Colombia. Allí comenté la experiencia comunitaria emprendedora de la creación y el crecimiento de las Comunidades Ágiles de Argentina, Colombia y Latinoamérica; así como también resalté brevemente ciertos aspectos de la informática aplicada a la inclusión social, de la mano de las Redes Libres y del Proyecto Nahual.

Luego de mi charla expusieron varios emprendedores más, tanto de la ciudad de Girardot como de otras ciudades y de Colombia.

Más tarde cené junto a docentes, directivos y organizadores del Foro una deliciosa comida local en un bonito restaurante del centro de la ciudad.

Antes de describir los siguientes días haré una especial mención al alojamiento: en un acto notable de hospitalidad y buen trato, la Universidad Piloto me dio hospedaje en el hotel número uno de Girardot, el Hotel Tocarema. Se trata de un hotel de gran categoría en el cual me brindaron excelente alimentación (desayunos y almuerzos), servicios ( qué piscina!) y alojamiento (muy cómoda habitación!).

Hotel Tocarema de GirardotEl sábado comenzó temprano y terminó tarde:
– por la mañana facilité un taller introductorio de métodos ágiles.
– por la tarde facilité el primer Coding Dojo de la historia de Girardot.
– por la noche participé de un panel junto a otros conferencistas en la Cámara de Comercio de Girardot.

En el Taller matutino realizamos actividades lúdicas y dinámicas en grupo para aprender y conocer en detalle al Manifiesto Ágil y algo de Scrum y Kanban.

2014-05-30 13.16.40 2014-05-30 13.17.12
2014-05-30 13.17.16 2014-05-30 13.17.26
2014-05-30 13.17.33 2014-05-30 13.17.37

En el Dojo de la tarde, la mayoría de los participantes -de casi todos los semestres de la Universidad Piloto y otras instituciones educativas de la región- realizaron por primera vez pruebas unitarias automatizadas. Practicamos TDD (Test Driven Development) y Programación de a Pares (Pair Programming).

2014-05-30 17.12.12 2014-05-30 17.12.48
2014-05-30 17.18.59 2014-05-30 17.19.04

Ya por la noche, el foco de mi charla de 15 minutos lo tuvieron:
– el agilismo y la actividad comunitaria como motores del emprendimiento, y
– los conocimientos informáticos como herramienta de inclusión social.
Compartí el panel con notables expositores colombianos de diversas instituciones (Fundación Todos Podemos Ayudar, HETAH, Universidad del Tolima y la Secretaría de Ciencia y Tecnología de Cundinamarca), y al finalizar todas las charlas recibimos preguntas de los aproximadamente 100 asistentes que había en la colmada sala.

Panel sobre Innovación social y emprendedorismo en la Cámara de Comercio de GirardotEsa noche la cerramos con una reunión de camaradería en la casa de un emprendedor local, con música y buena onda.

Al día siguiente cerró el foro. Cada expositor tuvo 45′ para entrar más en detalle de alguno de los temas de su incumbencia. Yo me adentré en las técnicas que se suelen llevar a cabo al inicio de un proyecto ágil, aplicadas tanto a la construcción de productos como también a otro tipo de proyectos, tales como el dictado de una materia en el marco de la educación.

Al respecto de la agilidad en la educación, esa misma mañana calurosa también tuve el placer de poder compartir -con casi todos los docentes de la institución- algunas herramientas pedagógicas y de organización de clases y materias. Hablamos de Kanban, de “Training from the back of the room”, de Educación Participativa, de Retrospectivas en las aulas, de autoevaluación y de salones con sillas dispuestas en círculo. En esta charla me acompañó mi colega Camilo Velásquez, uno de los jóvenes agilistas más activos de Fusagasugá y Colombia.

2014-05-31 12.04.23Luego del cierre del evento, almorcé en el hotel y disfrutamos del partido amistoso de Colombia contra Senegal, en la preparación del equipo para el Mundial de Fútbol que se acerca, y más tarde fuimos nosotros los que practicamos ese hermoso deporte.

2014-05-31 16.27.17 La jornada terminó con otra cena de camaradería, más numerosa cada día.

2014-06-01 02.07.01

Al día siguiente me despedí de Girardot cuando mi amigo el Ingeniero Wilson Gordillo me llevó hasta Fusagasugá a continuar con mi labor de difundir métodos y prácticas ágiles por el mundo 🙂

Agilizando ando!

Dibujo realizado por @coti_mol

Un especial agradecimiento para Elkin Forero Soto y Wilson Gordillo por haber confiado en mí para este IV Foro Internacional de Ingeniería de Software.

… Y hasta la próxima!

Desarrollo ágil potenciado por prácticas! Láminas sobre TDD, ATDD y CI

Está muy debatido en la comunidad ágil el uso de prácticas y técnicas (como automatización, ejecución periódica de build y pruebas), como complemento necesario de las metodologías como Scrum y Kanban.

Existen ciertas técnicas que solemos difundir en charlas, eventos, cursos y publicaciones, que entran dentro de esta categoría. Se trata de TDD (Test Driven Development), ATDD (Acceptance Test Driven Development) y CI (Continuous Integration).

He aquí tres láminas que hicimos junto a Ángela Castaño Restrepo, del equipo de Arquitectura de software de Sura, una de cada uno de estos temas. Las realizamos en el marco de un curso de “Desarrollo ágil de Software”, en Medellín. La facilitación gráfica y la práctica concreta nos ayudan en estas capacitaciones para que los participantes entiendan y fijen mejor los conceptos.

TDD – Diseño guiado por pruebas

TDD es una técnica de diseño que implica mucha disciplina y que -cuando se aplica bien- hace ahorrar mucho tiempo y dinero a los equipos de desarrollo. Su principal ventaja es la simplicidad.

TDD y su ciclo "RGR" (Red, Green, Refactor)

TDD y su ciclo “RGR” (Red, Green, Refactor)

ATDD – Diseño guiado por pruebas de aceptación

ATDD es una técnica de diseño que involucra de forma temprana a usuarios, testers y demás interesados en el producto, que permite definir escenarios que guiarán el diseño y el desarrollo de dicho producto.

ATDD y su ciclo anidado RGR para Vista y Controlador, junto con TDD para el Modelo (contexto: arquitectura MVC).

ATDD y su ciclo anidado RGR para Vista y Controlador, junto con TDD para el Modelo (contexto: arquitectura MVC).

CI – Continuous Integration

CI significa “Integración Continua” en español. Es un concepto compuesto por prácticas, herramientas y actitudes, a saber: un repositorio compartido de código, políticas de utilización de dicho repositorio, un servidor de integración continua, y en los mejores casos, tambien pruebas automatizadas y algunos otros procesos automatizados, trabajo en equipo y colaboración frente a conflictos).

No subir al repositorio compartido el código si no funciona las pruebas tanto de mi código como del código ajeno integrado. CI es un concepto que hace referencia a la integración del equipo, apoyada en herramientas y prácticas.

No subir al repositorio compartido el código si no funciona las pruebas tanto de mi código como del código ajeno integrado.
CI es un concepto que hace referencia a la integración del equipo, apoyada en herramientas y prácticas.

Cada uno de estos conceptos amerita mucho más material y práctica para poder ser bien aprovechado, por lo cual posiblemente dedique más artículos al respecto más adelante.

Espero les sean de utilidad las láminas!

Sura y Kleer, colaborando con la agilización del ecosistema paisa y colombiano!

Sura y Kleer, colaborando con la agilización del ecosistema paisa y colombiano!

Presupuestos y Contratos Ágiles – Reseña de la sesión de Ágiles 2013 (Lima, Perú)

Ocurrió en Ágiles 2013, el evento Latinoamericano anual de Métodos y Prácticas Ágiles.

Llegado el día de la sesión, asistieron más de 80 personas… ¡Resultando una de las sesiones no-keynote con más participantes de todo el evento Ágiles 2013!

¿Cómo fue que anunciamos el taller?

Pre$upuestos y Contratos Ágiles
Cómo crear el marco para un proyecto exitoso… antes de comenzarlo.

– Trabajaremos sobre la contratación y la puesta a punto desde cero de un proyecto ágil.
– Incluiremos los temas Presupuestación, Estimación, Planificación, Análisis, Priorización del Alcance, Cláusulas Contractuales, Roles y Negociación.

Se llevó adelante en Lima (Perú), el Jueves 10 de octubre de 2013, de 4:30 pm a 6:00 pm. Fue parte del track “Adopción y Transformación” del evento, con la categoría de sesión “Workshop” (Taller).

¿Y qué fue lo que hicimos?

Facilitamos la sesión entre varios compañeros de Kleer y la Comunidad Ágil: Carlos Peix, Martín Salías y yo, habiendo preparado la sesión también con la colaboración de Juan Gabardini y Ricardo Colusso y recibiendo ideas de varios colegas más.

Realizamos dos láminas durante la sesión, utilizando técnicas de Facilitación Gráfica:

Contratos-Agiles-1

Lámina realizada en tiempo real por Pablo Tortorella, Martín Salías y Carlos Peix.

Contratos-Agiles-2

Lámina realizada en tiempo real por Claudia Sandoval

Dividimos a los participantes en varios grupos/equipos y realizamos un ejercicio de presupuestación:
Repartimos breves documentos que contenían el análisis -alto nivel- de varias situaciones), a partir de los cuales cada grupo debía responder la pregunta “¿Para cuándo estará la propuesta?“.
Adicionalmente, les pedimos que nos dijeron si sabían aproximadamente para cuándo estaría terminado el proyecto y más o menos cuánto costaría.

Luego de esta primera vuelta, debatimos acerca de varios puntos interesantes:

  • Autenticidad desde el momento 0.
  • Negociación por intereses, objetivo Gana-Gana (Win-Win).
  • Mitigación de riesgos con Actitud colaborativa y conciliadora.
    • Valor del manifiesto ágil: “Customer collaboration over Contract negotiation”.
  • Analizar si el Cliente es compatible con el Proveedor (culturalmente).
  • ¿Cuánto más análisis se requiere para estimar?
  • Incepción: La importancia de realizar Workshops de Impact Mapping y Story Mapping al inicio del proyecto (o incluso antes!).
  • Estimaciones vs Promesas. Gestión de la Incertidumbre.
  • Gestión del Alcance y Administración de Cambios.
  • Cómo manejarse cuando un proyecto tiene Fechas Fijas.
  • Cláusulas posibles para evaluar confianza al inicio: 2 semanas gratis? 1 persona gratis? 1 iteración gratis?
  • Gestión de Buffer/Colchón (Sprints “por las dudas”?).
    Estrategia de Hitos: Entregas tempranas con Fechas definidas y Alcance negociable.
  • Definition of Done coordinado entre todos (ej: ¿Seguridad Informática e Infraestructura estarán presentes desde el inicio del proyecto?).
  • ¿Qué hacemos si se trata de un pliego?
  • La importancia que tiene El Equipo: ¿el equipo ya trabajó antes como equipo? ¿conocemos a las personas? ¿conocen bien la tecnología? ¿cómo hacemos si el equipo todavía no está armado? ¿son los que realizaron el análisis y la estimación?

Los participantes volvieron a trabajar en equipos luego del debate y surgieron nuevas estrategias y respuestas a la pregunta original, basadas en los conceptos debatidos.

Al cierre de la sesión, antes del aplauso general, invitamos a continuar en el Open Space del último día de Ágiles 2013, a quienes quisieran seguir ahondando en alguna/s temáticas relacionadas con “Presupuestos y Contratos Ágiles“.

Quisiera agradecer especialmente a Hernan Susunday, de AgileUy (Comunidad ágil de Uruguay), quien se tomó el trabajo de colaborar con el caso utilizado, sobre el Plan Ceibal.

Documentación en proyectos ágiles – Mitos, respuestas y alternativas superadoras

Un tema complejo el de la documentación.

Muchos piensan que el manifiesto ágil incita a los equipos a no documentar, debido al segundo de los 4 valores: Software funcionando sobre documentación extensiva. Esto es falso, es un mito. Se puede documentar todo lo que realmente sea necesario.

Lo difícil radica en que siempre (estemos o no en un proyecto “ágil”) debemos preguntarnos para qué y para quién la haremos y analizar en cada caso, si es que realmente necesitamos documentos para cumplir esos objetivos.

Suelo recomendar el uso de gráficos y esquemas en las paredes del espacio de trabajo del equipo, con los temas importantes (ej: la arquitectura del proyecto, la infraestructura, las decisiones de diseño más importantes).

También puede ayudar el hecho de grabar videos con las explicaciones más complejas.

Estas dos primeras recomendaciones (gráficos y videos) serían útiles para asegurar la coherencia entre el diseño y la implementación de aplicaciones.

Otro tema importante en la documentación ágil son las pruebas automatizadas: Unitarias, de integración, funcionales, de aceptación, de performance…
Si ya las hacen, sabrán de qué hablo. De lo contrario, lo explicito: Las pruebas automatizadas tienen gran poder en cuanto a mostrar “qué hace la app” y “cómo lo hace“). Y además hacen más baratas las pruebas de regresión.

En cuanto a la capacitación de nuevos integrantes del equipo, nada peor que mandarlos a leer documentos. Suelen ser aburridos, fueron hechos casi siempre con un sesgo del autor, tienen partes ambiguas… (y una larga lista de etcéteras.)
Para resolver ese tema, recomiendo que usen programación de a pares (y pairing en general, para todas las actividades del equipo). Haciendo se aprende más rápido y mucho mejor, que leyendo documentación.

En cuanto a entender y comunicar requerimientos del sistema, creo que una buena User Story (Historia de Usuario) puede ayudar mejor que los Casos de Uso o Requerimientos tradicionales. En el libro de mi socio y amigo Martín Alaimo se explica este tema a la perfección.

Por último, quiero aclarar que conozco bastante bien el lenguaje de modelado unificado (UML) y creo que en muchas ocasiones es útil usar los diagramas de secuencia, de implementación (AKA deploy) y aquellos que el equipo requiera para entender mejor alguna situación compleja y/o repetitiva.

A modo de cierre: no creo que “ser ágil” implique “no documentar”. Sino que “ser ágil” implica siempre estar atento y crítico con todo el proceso de desarrollo. Todo es perfectible y la clave está en encontrar el balance y el equilibrio adecuado. Un buen primer paso puede ser analizar las opciones de mejora que estén a nuestro alcance, en el camino entre lo que hacemos ahora y la/s mejor/es alternativa/s posibles.

“Capacitación” (Not!)