La primera vez que tuve que usar una metodología ágil fue en 2009 cuando trabajaba en una empresa de Alemania como desarrollador web con un pequeño equipo de 4 personas. Me presentaron esa extraña metodología llamada «Scrum». Lo que obtuve en ese momento de Agile es que tuvimos que completar un formulario con 3 preguntas, luego tuvimos que compartir las respuestas durante una reunión diaria. En ese momento, me pareció útil sincronizar el equipo, pero aparte de eso, me pareció inútil como desarrollador.
No sabía que el concepto «ágil» iba a ser tan popular en los años siguientes. Empecé a ver la metodología «Ágil» en todas partes, todos querían seguir los rituales «Ágiles». Por lo tanto, comencé a documentarme, leer libros sobre las diferentes metodologías y adaptar las que podrían funcionar más para mi caso. A pesar de que usé Scrum varias veces, me di cuenta de que no funcionaba para la mayoría de mis proyectos, así que me enamoré de la flexibilidad de Kanban.
Si va a la definición de Scrum, lee algo como esto:
Scrum es un marco iterativo e incremental para gestionar el desarrollo de productos. Define «una estrategia de desarrollo de productos flexible y holística en la que un equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común.
«¿Qué es Scrum?». ¿Qué es el scrum? Un marco ágil para completar proyectos complejos – Scrum Alliance. Scrum Alliance. Consultado el 24 de febrero de 2016.
¿Notó la parte «Desarrollo de productos»? Significa que la metodología fue pensada para productos y un equipo dedicado que trabaja en torno al desarrollo de este software. Además de eso, tienes reglas como:
Funciona perfecto para una empresa que trabaja en torno a un solo producto, pero en la vida real de una empresa de desarrollo de software, no es factible.
Kanban parecía ser mejor para el caso de mi equipo. Necesitamos hacer releases todo el tiempo, y no siempre el release está planeado, ¡y más si estamos en modo de producción y encontramos un error que debe corregirse lo antes posible!
Kanban es un método sencillo para gestionar y mejorar el trabajo en los sistemas humanos. Este enfoque tiene como objetivo gestionar el trabajo equilibrando las demandas con la capacidad disponible y mejorando el manejo de los cuellos de botella a nivel del sistema.
Wikipedia: https://en.wikipedia.org/wiki/Kanban_(development)
De acuerdo, pero si gestionas el trabajo de acuerdo con la capacidad, ¿no suena como un trabajo sin un plan? Parece un poco desorganizado. Es por eso que apareció el término «scrumban», que significa: planear como scrum pero ser flexible como kanban.
Los equipos de desarrollo hacen grandes esfuerzos para seguir estrictamente todos los rituales de cualquiera de estas metodologías, y no se dan cuenta de que cuando estás forzando una metodología creada por otra persona, ¡estás haciendo lo contrario a ser ágil!
Después de varios años trabajando y viviendo ágilmente, me di cuenta de que ágil debería ser más acerca de la evolución constante porque todo cambia y si te apegas a las mismas reglas de hace 10 años, no te adaptarás a los nuevos requisitos.
Personalmente, me gusta usar una combinación de Scrum, Kanban y programación extrema, y dependiendo del proyecto o la compañía, uso algunas ideas de cada uno. No estoy diciendo que no debas definir reglas, lo que te recomiendo es que debas definir tu propia metodología para tu equipo y adaptarla, de esta manera el equipo habla el mismo idioma y lanza un gran código.