miércoles, junio 13, 2012

Diarios de Praga II: Implementación de Scrum sin éxito

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.