Tras algunos años trabajando con metodologías ágiles, recopilo todo lo que he aprendido y los errores más comunes que solemos cometer. Están expuestos a modo de lista de ideas, sin matizar, con el objetivo de no hacerlo excesivamente largo.

General

• Las metodologías son una herramienta, un medio para hacer buenos productos.
• Son las personas las que hacen que las metodologías funcionen.
• Se pueden hacer buenos productos con metodologías tradicionales, al igual que malos productos con metodologías ágiles.
• Las metodologías ágiles son las que mejor se adaptan a Internet, donde los proyectos son algo vivo.
• Las metodologías ágiles te permiten hacer algo diferente a lo inicialmente planteado, pero que aporte mucho más valor.
• Las metodologías ágiles, bien aplicadas, pueden aportar un punto adicional al trabajo de un buen equipo.
• Las metodologías ágiles no tienen la culpa de todos los males que ocurren en un proyecto (ni todas las soluciones).
• Metodología ágil no significa ausencia de metodología.
• La metodología es necesaria, se puede sustituir por el sentido común solo en proyectos pequeños y entornos muy controlados.
• Más gente significa "menos ágiles".
• No se necesita poner nombre a las cosas para trabajar con metodologías ágiles.
• Las metodologías ágiles son transparentes, para lo bueno y para lo malo.
• Las métricas de trabajo individuales son casi siempre innecesarias y van en contra de los principios de scrum.
• Pensar siempre en que estamos construyendo un producto, no entregables.
• Las metodologías ágiles no son solo metodologías de desarrollo de software.
• Las metodologías ágiles son metodologías de proyectos en su totalidad.

Aplicación

• La teoría es importante, pero tu experiencia personal lo es más aún.
• El problema más común con las metodologías ágiles es que no se aplican correctamente.
• Tras un par de meses, un equipo coordinado rinde el doble que un equipo recién montado.
• Algo está fallando si tardas un día entero en una preparación de sprint.
• Si las metodologías ágiles te parecen complejas, es que algo estás haciendo mal.
• Algo está fallando si mantener el proceso te lleva más tiempo que avanzar en el producto.
• En proyectos grandes, debes incluir tareas de análisis-definición de funcionalidades futuras entre las tareas de desarrollo.
• No he encontrado ningún product owner que haga todas las funciones que se esperan de él, siempre hay que complementar de alguna forma su trabajo.
• La metodología se puede adaptar a las necesidades de tu proyecto y tu cliente.
• La mayoría de las adaptaciones se hacen por desconocimiento de la metodología.
• El scrummaster no debe ser el único que trate con el cliente, el equipo debe estar lo más cerca posible del negocio.
• Se necesita definir al principio del proyecto una visión global de todo sin entrar en detalles (arquitectura técnica y UX), para que después las piezas encajen bien.
• Scrum se adapta mejor a los cambios, pero los cambios que afecten a las bases del proyecto (arquitectura técnica y UX) son un problema. Esto pasa con scrum y cualquier otra metodología
• Hay que evitar todo lo que no aporte valor al producto o ayude a su mantenimiento.
• Estimar es algo que no aporta al producto final, pero sirve para saber si un desarrollo será rentable antes de abordarlo.
• Metodologías ágiles no implica ausencia de documentación.
• Un sistema de documentación colaborativo con la última versión de las decisiones es mucho más útil que tener actas de todo con decisiones antiguas.
• A veces alguien externo al equipo, que aporte otro punto de vista, te ayuda a mejorar.
• Kanban encaja mejor que scrum en proyectos con correctivo-evolutivo.
• "Más reuniones" significa "Menos tareas hechas".
• Las metodologías ágiles no encajan del todo con proyectos de I+D, pero tampoco conozco ninguna que encaje mejor.
• Todos los miembros del equipo, especialmente los encargados de definición y diseño deben permanecer en el equipo hasta el final.

Consultoría

• Las metodologías ágiles son mucho más difíciles de aplicar en el mundo de la consultoría, donde hay una relación contractual con un cliente.
• Las metodologías ágiles son incompatibles con las RFP's cerradas.
• El contrato ágil es un mito, las cosas solo funcionan si hay una relación de confianza.
• Las metodologías ágiles requieren la implicación del cliente y esto requiere tiempo, pero se nota en el resultado final.
• La formación es fundamental en los primeros proyectos con metodologías ágiles.
• La mejor forma de convencer es hacer una prueba y demostrar que funciona.
• Comenzar a trabajar con metodologías ágiles supone un cambio muy drástico para el cual no todo el mundo está preparado. Es imprescindible avanzar paso a paso.
• Algo está fallando si solo hablas con el cliente en las demos cada 15 días.
• "Metodologías ágiles" no quiere decir que haya "barra libre" de cambios y funcionalidades nuevas.
• El objetivo del cliente y del consultor debe ser siempre el mismo. Si no lo es, hay un problema.

Lean UX

• Construir un equipo que mezcle perfiles de diseño con perfiles técnicos ayuda mucho a los proyectos.
• Tratar de diseñar un proyecto completo antes de empezar a programar es una pérdida de tiempo (a no ser que el proyecto sea muy pequeño).
• El expertise es importante, pero el feedback temprano y la respuesta de los usuarios lo es aún más.
• Define primero la estructura global a alto nivel y a partir de ahí ve detallando todo en cada sprint.
• Hay cosas que deben estar definidas antes de empezar a programar para que después todo encaje: objetivos del servicio y las pantallas principales.
• La UX de un sprint debe estar terminada antes de que empiece el sprint.
• A día de hoy no hay ninguna charla, libro o post que te dé una solución para este tema. Y si existiera, una solución que encaje a otro en sus circunstancias no tiene porque encajar en las tuyas.

Calidad

• La calidad no es una persona, es un concepto que debe estar muy presente en cada miembro del equipo.
• Programar hasta el último minuto antes de la demo es lo más común, pero lo ideal es incluir menos funcionalidades y bien probadas.
• Se saca todo el partido a las metodologías ágiles cuando se combinan con prácticas de ingeniería como pruebas automáticas, TDD, control de versiones, integración continua, pair programming, etc.
• Tener tras cada sprint un entregable listo para subir a producción es un buen objetivo para un equipo de scrum.

Comunidad

• En 2013 el 73% de las empresas se consideran ágiles, pero pocas lo aplican correctamente.
• ¿Llamamos referente a una persona que destaca por su trabajo o por su capacidad de hacer ruido? ¿Sabrías distinguirlos?
• Las metodologías ágiles pueden servir de catalizador para cambiar la forma de trabajar de una empresa e incluso su estructura.
• Hay una creciente tendencia a pensar que metodologías ágiles sirven para hacer la sociedad mejor, creo que se esto se le ha ido de las manos a algunos.