¡Una empresa entera ágil!
- Detalles
- Publicado: Miércoles, 23 Diciembre 2009 15:50
- Escrito por Diego Gomez
Hablando el mes pasado con mi amigo Siraj nos preguntamos ¿por qué la "filosofía" ágil no resulta tan bien en los negocios como un todo?. Lo que quiero decir es que resulta bastante fácil de encontrar hoy en día un departamento de desarrollo de productos/software de una empresa que use métodos ágiles, pero ¿qué es lo que falta para que recursos humanos, marketing, financiero, administrativo, comercial y todos los demás departamentos también entren en esto?
Imaginen si existieran perillas para manejar la capacidad (o velocidad), el tiempo de ciclo, la calidad y la predictibilidad de los proyectos, y que pudieramos configurar nuestro proceso moviendo estas perillas. "Quiero alta capacidad, tiempos de ciclo bajos, alta calidad y alta predictibilidad. Así que voy a girar estas perillas a 10, 1, 10, 10 respectivamente".
"ScrumMaster" es un nombre que sugiere ser el guardián del proceso de Scrum. Él es un agente de cambio que apoya a su equipo, que enseña y promueve Scrum en toda la organización. Garantiza el buen funcionamiento de las actividades del equipo erradicando los impedimentos y manteniendo al equipo protegido de las distracciones externas. Sin embargo, en ciertos escenarios, los equipos ágiles sienten que el ScrumMaster en sí es el mayor impedimento. 
Hace algún tiempo pensaba en si dos metodologías de desarrollo de software, una tradicional y una ágil, podrían ser combinables. Y pues, a simple vista es difícil dimesionar si dos aspectos distintos de hacer las cosas pueden convivir bajo una misma nube, y llegué a la conclusión que si, pues usualmente las metodologías tradicionales proponen estructuras de trabajo en base a procesos, mientras que las ágiles apoyan el postulado de basarse en las personas para lograr que un proyecto sea exitoso.
Un equipo que adopta Ágil por primera vez tiende a cometer varios errores durante los primeros días. Uno de los errores más comunes es intentar hacer una estimación precisa. Durante la Reunión de Planificación del Sprint de la primera iteración, el equipo no conoce su velocidad y tiende a gastar tiempo intentado crear estimaciones "precisas" o estima usando "colchones" arbitrarios. Gastan demasiado esfuerzo detallando las tareas y estimándolas.
Es bien sabido que en Scrum es muy importante tener software que funcione al final de cada sprint. Pero... ¿por qué? Joe Little comparte 4 buenas razones por las cuales tenemos que enfocarnos en tener software que funciona, siempre.
Trabajando con varios equipos de líderes y gerentes, me di cuenta que necesitan cambiar cómo están organizados para realmente lograr tener equipos ágiles más productivos.
Mucho se habla de la duración de las iteraciones, en especial la duración "ideal" de un Sprint de Scrum. El tamaño sugerido va desde 4 semanas hasta tan pequeño como 2 semanas (e incluso algunos están probando con sprints de 1 semana). ¿Cuál existe una duración ideal? ¿Por qué hay un consenso sobre "mientras más chico, mejor"?
A muchas organizaciones les interesa adoptar Ágil por la habilidad de entregar valor de negocio de forma temprana, incrementar la productividad, realizar entregas más frecuentes y mejorar la moral de los empleados. Hay muchos cursos y libros disponibles que ayudan a los equipos a aprender los fundamentos del desarrollo ágil, pero se suelen enfocar en los desafíos a nivel de equipo, y no tratan muy profundamente los temas organizacionales que pueden ayudar o impedir una transición a esta nueva forma de pensar y trabajar. Este artículo busca mostrar las áreas en donde muchas organizaciones encuentran dificultades para adoptar Ágil, para que puedan estar mejor preparadas al momento de enfrentar el desafio.
Las historias de usuario son...
En Scrum se habla mucho de "quemar puntos" y de su famoso Gráficos de Burn-Down. Y es que resultan una herramienta muy útil y simple de usar, que nos permite ver rápidamente si el equipo llegará a cumplir con su compromiso para la iteración, o si deberá tomarse alguna acción.