Una idea muy difundida, y creída hoy en día, respecto a la agilidad es que es una metodología. En muchas ocasiones he escuchado esto: * “Queremos implementar Scrum” * “Queremos trabajar como lo hacen en Spotify” * “Queremos adoptar Lean” * “Queremos certificarnos como Scrum Masters, Product Owners” Obligatoriamente, les pregunto “¿por qué?”, y la respuesta siempre es: “porque queremos ser ágiles”. Sin embargo, las organizaciones y equipos de desarrollo se embarcan en iniciativas para “implementar y adoptar metodologías ágiles”. El resultado suele ser una forma de trabajo que llaman “ágil”, que pocas veces lo es. Te han mentido. No existe tal cosa como “la metodología ágil” porque la agilidad no se puede prescribir. No es una píldora que tomas una vez y resuelve tus problemas de un día para otro. Pero muchos siguen convencidos que sí lo es. Una metodología es un proceso definido. Una serie de pasos, prácticas, artefactos, herramientas, políticas, roles y métricas; un conjunto de “recetas”, las cuales suelen seguirse y repetirse al pie de la letra. En pocas palabras: una metodología es algo que contradice uno de los principios de la Agilidad (individuos e interacciones sobre procesos y herramientas). Incluso, las que son tomadas como “metodologías” no se definen a sí mismas como tales, sino como “marcos de trabajo” (frameworks): te ofrecen un conjunto de guías y herramientas para que construyas una forma de trabajo propia, adecuada para tu organización y para los resultados que buscas. Por lo tanto, para encaminarte a la agilidad, lo primero que hay que hacer es abandonar esta creencia. Agile no es una metodología. Entonces, ¿cómo debe ser? Primero, entendamos qué es ser ágil Ser ágil no es una forma de actuar. No es un proceso. No es algo que repites siguiendo una serie de pasos. Ser ágil es una característica que te permite actuar ante las circunstancias que enfrentas. Eso no se logra apegándose a un método prescriptivo. No eres ágil porque sigues el método, sino porque obtienes el principio básico de la agilidad: entregar valor en el menor tiempo posible. En el contexto del desarrollo de tecnologías, es entregar software adecuado, funcionando y sin fallas en el menor tiempo posible. La agilidad es una forma de ser. ¿Cómo ser ágil? Eres ágil cuando tienes una forma de trabajo que es adecuada para entregar software funcionando en el menor tiempo posible. Esto significa que tu organización está diseñada para producir esos resultados. Aprovecha sus talentos, recursos y circunstancias. Además, es capaz de reorganizarse cuando las circunstancias cambian y mantener los buenos resultados. Es un cambio de paradigma. Es un desarrollo de habilidades amplio. Es permitirle a cada individuo que tome decisiones autónomas. Es comprender que el objetivo de la organización es dar buenos resultados, en vez de decir “trabajamos con metodologías ágiles”. Por lo tanto, el inicio es desarrollar las habilidades de autonomía en las personas. La forma de trabajo ágil emergerá de las decisiones que tomen. ¿Quieres saber cómo llevar la agilidad a tu equipo y organización? ¡Contáctame! Visita mi web en edgarfernandez.com en donde encontrarás mis redes y medios de interacción. También tendrás acceso a más contenido gratuito que hago para ti. Comparte este episodio con tus amigos y con todo el que consideres que debe saberlo. ¡Hasta la próxima!

En esta nueva serie de artículos quiero hablarte de muchos de los conceptos que se entienden mal sobre la agilidad y, por lo tanto, se aplican erróneamente en las formas de trabajo (por ejemplo, que “Agile” es una metodología y se adopta como tal). Quiero hablarte de cómo es que esto ocurre y cómo lo podemos arreglar para que cambiemos los resultados en nuestros desarrollos.

Una estrategia de aseguramiento de la calidad mal diseñada entorpecerá el flujo de trabajo y generará retrasos. Veamos algunas maneras de optimizar el flujo del equipo, asegurando una alta calidad.

Esta es la historia de un conflicto ríspido entre Testers y Devs, y de cómo lo podemos eliminar

Es común creer que empezar a probar antes garantiza la calidad y ocurre lo opuesto ¿Por qué? Vamos a encontrar la respuesta a esta cuestión

Más allá aún: ser capaz de predecir la cantidad de defectos y fallas que tendrá el software antes de iniciar testing

En el primer episodio de esta serie, te compartí que hubo un cambio en mi forma de trabajo y mi actitud al desarrollar software, que me hizo un mejor desarrollador

En el desarrollo iterativo, suele pensarse que parte de iterar sobre el MVP incluye arreglar los bugs y fallas. No es lo más adecuado, porque si tu MVP ya es suficiente para ir a producción, no lo podrías enviar inmediatamente porque tiene fallas, lo cual impide la agilidad. La calidad debe ser una cultura, un conjunto de actividades continuas a lo largo del desarrollo y no ser solamente momentos en el tiempo donde decimos “ahora nos concentraremos en la calidad”. Hacer el producto correcto y hacerlo bien.

Un tema que tuvo un alto impacto profesional en mí fue el de Gestión de la Calidad en el desarrollo de software. Literalmente cambió mi vida para bien y para siempre. Hoy, es algo que difundo y comparto (a nivel de evangelizador) a donde voy, pues lo considero fundamental para el desarrollo de software. Te comparto la experiencia con la que lo comprendí.

La mala gestión ocurre en software. Una serie de decisiones y acciones conducen a esta situación. A lo largo del tiempo, he identificado cinco que siempre están presentes y te las describo