Capítulo 20: Lecciones aprendidas
Capítulo 20: Lecciones aprendidas
Lunes después del release. El equipo se reúne por última vez en la sala donde todo empezó hace ocho semanas. La pizarra todavía tiene los cinco valores de XP que Carlos escribió el primer día. Hoy cada persona comparte qué aprendió, qué se lleva y qué le recomendaría a otro equipo.
Anterior: Release final | Índice: Volver al índice
El antes y el después
Carlos pone dos columnas en la pizarra: “Antes de XP” y “Después de XP”.
Carlos (TL): “Quiero que cada uno piense en cómo trabajaba antes y cómo trabaja ahora. No lo que sabe, sino cómo se siente al trabajar.”
Elena:
Elena (Dev): “Antes: llegaba al trabajo con ansiedad. No sabía si lo que estaba construyendo era lo correcto. Esperaba días por respuestas del PO. Los deploys me daban terror. Trabajaba hasta tarde y mi código era peor, no mejor.”
Elena (Dev): “Después: llego sabiendo qué voy a hacer. Si tengo una duda, Ana está a tres metros. Los deploys son rutina. Me voy a las 6 y mi código es mejor cada semana.”
Diego:
Diego (Dev): “Antes: programaba solo. Creía que pedir ayuda era debilidad. Estimaba al azar y me comprometía con fechas imposibles. Cuando algo fallaba, sentía que era culpa mía.”
Diego (Dev): “Después: no imagino trabajar sin pair. Mis estimaciones se basan en datos. Cuando algo falla, es un problema del equipo, no de una persona. Y descubrí que sustainable pace no es pereza: es la forma más profesional de trabajar.”
Ana:
Ana (PO): “Antes: era la mensajera entre los stakeholders y un equipo invisible. Les decía lo que querían oír y después negociaba a escondidas con los developers. Nunca sabía realmente cómo iba el proyecto hasta que era demasiado tarde.”
Ana (PO): “Después: soy parte del equipo. Tomo decisiones en tiempo real. Tengo datos: velocity, bugs, scope completado. Cuando hablo con stakeholders, tengo confianza porque sé exactamente dónde estamos.”
Carlos:
Carlos (TL): “Antes: era el arquitecto que diseñaba en una torre de marfil y entregaba documentos que nadie leía. Tomaba decisiones solo y culpaba al equipo cuando no las seguían.”
Carlos (TL): “Después: facilito. No dicto. Las mejores ideas de este proyecto no fueron mías. Fueron de Diego, de Elena, de Ana. Mi rol fue crear el espacio para que esas ideas aparecieran.”
Las cinco lecciones del equipo
El equipo destila lo aprendido en cinco lecciones que cualquier otro equipo podría usar.
Lección 1: La confianza se construye con transparencia
Ana (PO): “Nunca escondan el estado real del proyecto. Si van atrasados, díganlo. Si hay un bug, díganlo. Si una estimación fue mala, díganlo. La confianza crece cuando la verdad es consistente, no cuando las noticias son buenas.”
Lección 2: Las prácticas técnicas no son opcionales
Carlos (TL): “Muchos equipos adoptan los rituales ágiles (standups, retrospectivas, sprints) pero ignoran las prácticas técnicas (TDD, pair programming, CI, refactoring). Es como comprar zapatos de correr y no salir a correr. Los rituales sin prácticas son teatro.”
Lección 3: Simplicity no es hacer menos, es hacer lo correcto
Elena (Dev): “Simple Design no significa código mínimo. Significa código claro. A veces ‘simple’ son tres funciones en vez de una, porque cada una tiene un nombre que explica qué hace. Simple es lo que tu compañero de pair entiende en diez segundos.”
Lección 4: El cambio es la norma, no la excepción
Diego (Dev): “Ana cambió prioridades cinco veces en ocho semanas. Ninguna fue un drama. Cada una mejoró el producto. Si tu proceso no absorbe el cambio con gracia, el proceso está roto.”
Lección 5: Sustainable pace es la práctica más difícil y la más importante
Diego (Dev): “Es contra-intuitivo. Parece que trabajar menos produce menos. Pero trabajar a un ritmo sostenible produce mejor. Menos bugs, menos re-trabajo, menos burnout. En ocho semanas produjimos más que equipos que trabajan doce horas diarias durante seis meses.”
Recomendaciones para equipos nuevos en XP
El equipo imagina que alguien les pregunta: “¿Cómo empiezo con XP?”
Carlos (TL): “Lean el libro de Kent Beck. ‘Extreme Programming Explained: Embrace Change’. La primera edición para las prácticas puras. La segunda edición para la filosofía más madura. No es largo. Es claro. Es transformador.”
Elena (Dev): “No intenten todas las prácticas a la vez. Empiecen con TDD y pair programming. Son las dos prácticas que más cambian la forma de pensar. Las demás fluyen naturalmente.”
Diego (Dev): “Busquen un Carlos. Alguien que haya vivido XP y pueda guiar sin imponer. Los primeros días son incómodos y es fácil abandonar sin alguien que diga ‘confíen en el proceso’.”
Ana (PO): “Si eres PO, siéntate con el equipo. No al lado: con ellos. Las decisiones que tomas en treinta segundos habrían costado días por correo. Tu presencia es la práctica más barata y más valiosa.”
Carlos (TL): “Y no esperen perfección. Nosotros tuvimos conflictos, bugs en producción, estimaciones incorrectas y momentos de frustración. XP no elimina los problemas. Los hace visibles temprano y los resuelve rápido.”
El cierre
Carlos borra la pizarra. Los cinco valores de XP desaparecen. Pero no de la memoria del equipo.
Ana (PO): “¿La siguiente fase del Kanban? ¿Seguimos con XP?”
Carlos (TL): “¿Alguien quiere no seguir?”
Silencio. Cuatro sonrisas.
Elena (Dev): “No podría volver a trabajar de otra forma.”
Diego (Dev): “Yo tampoco.”
Ana (PO): “Entonces seguimos. Mismo equipo, mismas prácticas, más producto.”
Carlos (TL): “Kent Beck estaría orgulloso.”
El equipo sale de la sala. El tablero de corcho en la pizarra está vacío, listo para las tarjetas de la siguiente fase. Los post-its del futuro todavía no existen. Pero el equipo que los va a escribir ya sabe cómo trabajar juntos.
Práctica XP del capítulo
Todos los valores: Este capítulo cierra el ciclo con los cinco valores de XP presentes en cada lección:
- Communication: la transparencia como base de confianza
- Simplicity: hacer lo correcto, no lo mínimo ni lo máximo
- Feedback: ciclos cortos que permiten corregir el rumbo constantemente
- Courage: decir la verdad, cambiar lo que no funciona, aceptar el cambio
- Respect: cada persona aporta valor; nadie es más importante que otro
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Comparte transformación como PO, propone continuar con XP |
| Carlos | Facilita la retrospectiva final, reconoce que las mejores ideas no fueron suyas |
| Diego | Reconoce su crecimiento, recomienda buscar un mentor |
| Elena | Destila lo aprendido sobre Simple Design, valida la transformación del equipo |
Anterior: Release final | Índice: Volver al índice