Luego de un comienzo alentador, de haber convencido a mis
superiores que Scrum podía ayudar y
solucionar ciertos problemas que experimentaban los proyectos de la empresa, me
choque con la dura realidad y mi intento de aplicar Scrum, o un hibrido
adaptado a sus necesidades, falló. Les recomiendo que lean mi
artículo anterior
para conocer en profundidad mis hallazgos iniciales.
Pronto entrare en detalles, pero en resumen mi intento fue
muy apresurado, no llegue a conocer bien a la empresa, a su gente, su cultura,
su forma de trabajar y los problemas actuales que tienen con los clientes. Solo
había estado con ellos un mes. Tuve apoyo interno inicialmente y un cliente
aprobó la implementación, pero por diversos problemas periféricos que estábamos
experimentando en el proyecto en ese momento, no se tuvo la paciencia necesaria
para aplicar el proceso y volvimos todo atrás.
La situación no era buena, se habían retrasado muchas entregas y
últimamente no podíamos cumplir los compromisos asumidos. Otra causa
relacionada es que el cliente no era una empresa de desarrollo, sino una
empresa de retail que tenia su sitio de e-commerce, y su área de sistemas no
estaba al tanto de Agile ni de Scrum.
Otro tema fue el interno, no logre apoyo suficiente para
lograr el cambio. Aunque tuve apoyo inicial, cuando surgió el primer inconveniente
con el cliente perdí la confianza y el apoyo de la empresa. El problema
principal fue que no logre un completo consenso interno antes de lanzar este
proceso con el cliente. Lo ideal hubiese sido aplicar cambios graduales y luego
cuando todos estén listos, hacer el cambio
definitivo.
También el cliente creía que el proceso era una bala de
plata que iba a resolver todos sus problemas. Empezaron a hacer pedidos
irreales, como por ejemplo que el proceso soportase incrementar y disminuir el
output de desarrollo de una semana a la otra sin retrasar las funcionalidades
planeadas, que eliminase la posibilidad de que existan defectos y también que
provea fechas para todas las fases del desarrollo de cada funcionalidad (Fechas
para la finalización todos los estados: especificación, desarrollo, testing y
UAT).
Volvimos a manejar todo con planes en un Gantt. El cliente
prefiere tener un plan con fechas para todo, aunque no sean reales y luego se
retrasen. Es un círculo vicioso, porque siempre se llega a situaciones límite
con el cliente por retrasos entendibles y relacionados a la naturaleza del
desarrollo de software. El cliente tiene la suficiente fuerza como para que en
la empresa se pongan fechas irreales y
luego siempre se retrase todo, se llegue a un conflicto, y se re-planifique. Es
una forma de trabajar muy poco sana Hay presión, negatividad y muchas veces se
hace overtime sin necesidad.
En la empresa siguen apoyando la idea de tomar ideas agiles,
pero saben que no es el momento. Mi experiencia sirvió para hacerles dar cuenta
que tienen que ir paso a paso. El problema principal es la gente, ya que la
empresa cuenta con un pequeño equipo técnico que maneja varios proyectos a la
vez y la todos van saltando de un proyecto a otro apagando incendios y
resolviendo defectos. La idea de tener un equipo dedicado a nuevas
funcionalidades y otro a resolver defectos no es posible en este momento, no se
puede tener un equipo fijo que es uno de los principales requisitos de Scrum, ya
que sin un equipo no se puede lograr medir la velocidad de desarrollo para
lograr un planeamiento a largo plazo (Release planning).
Aunque interpretarse como un fracaso, yo tomo lo positivo de
esta experiencia. Me sirvió para aprender que para aplicar procesos tengo que
tomarme más tiempo para estudiar la realidad de la empresa, lograr un consenso
total de todos los involucrados (y uno mayor de la gente de arriba), e ir aplicándolo
gradualmente los cambios para que las posibilidades de tener éxito sean
mayores. También fue mi primera experiencia con una empresa no dedicada al
desarrollo de software, la diferencia realmente es abismal. De todo se aprende.
