La agilidad en el desarrollo de software está en todas partes; se habla de ella a diario, hay cientos de eventos al año donde la mencionan, se invierten miles de dólares en capacitación y certificaciones y se afirma que es el estándar para hacer software.

Sin embargo, siguiendo los testimonios de muchas empresas y equipos de desarrollo, los resultados aún son muy parecidos (prácticamente iguales) a los que había “antes de la agilidad”:

• Retraso en las entregas
• Mucho sacrificio de los desarrolladores para cumplir con las entregas
• Alta incidencia de defectos en producción
• Insatisfacción en muchos devs por el estrés y la forma en que trabajan
• Fricciones entre equipos, que se ven como rivales: devs vs. testers, devs vs. Project Managers

La agilidad es algo deseable. Es más, no debería ser opcional, pues el objetivo de todos los que estamos involucrados en este trabajo es entregar software de valor en el menor tiempo posible, pero pocos lo están logrando.

¿Qué es lo que está pasando?

En mi experiencia trabajando con diversos equipos y organizaciones, he observado que estos resultados se deben a la forma de trabajo que tienen, principalmente a la diferencia entre lo que entienden que es la agilidad y lo que esta es.

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.

Escucha los nuevos episodios en los que te compartiré mi experiencia y consejos para abandonar estas malas percepciones. Compártelo con tus amigos y con todo aquel que consideres que debe saber esto.

¡Nos escuchamos en el próximo episodio!