Los malos hábitos de flujos de trabajo “ágiles”
English version of this post here
He tenido la oportunidad de trabajar en distintas empresas en proyectos disruptivos que demandan cambios en la gran mayoría de la arquitectura, en la infraestructura, en la organización de los equipos y también un gran presupuesto.
El proceso es bastante similar en las empresas y básicamente comienza así:
- Surge la idea del proyecto para reemplazar los sistemas que la empresa utiliza porque el equipo de TI detecta que toda la infraestructura es un desorden.
- Planeación y concepción del proyecto en el cual se consideran estos recursos principales: más desarrolladores, testers, PMOs, tecnologías modernas, una nueva metodología, y la inversión económica, incluyendo la parte difícil de convencer al consejo de administración.
Entonces, después de haberle mencionado a los miembros del consejo que después de este proyecto, TODO será flexible, elegante y que ayudará a reducir costos, suena espectacular. Se promete eliminar los sistemas legados que fueron desarrollados hace muchos años y que son difícil de mantener o a lo mejor se tiene un sistema comprado que sube sus costos año con año y también se reemplazará, los tiempos de entrega y de corrección de errores se reducirá.
Entonces, el proyecto se aprueba gracias a que el equipo de TI lo pudo vender bien y todos están motivados en emprender esta nueva travesía de mejora.
Podría platicarles muchos aspectos que salen mal en este tipo de proyectos incluyendo desde sus inicios, pero este artículo me gustaría enfocarlo a la manera en que se lleva el flujo de trabajo.
Se decide contratar personal para crear el gran sistema perfecto del cual tendrán control absoluto, los nuevos desarrolladores son instruidos para trabajar desde un enfoque ágil. Para esto he visto a empresas querer implementar Scrum, pero tiendo a ver el mismo problema qué es intentar ser ágil y adoptar una nueva manera de desarrollar software pero al mismo tiempo manteniendo viejos hábitos.
Pongamos un ejemplo con el “Daily Scrum”. La reunión está concebida para que cada persona involucrada directamente en el desarrollo del producto responda estos 3 cuestionamientos: “¿Qué hice ayer?”, “¿Qué haré hoy?”, e indicar si existen impedimentos o cosas que detengan la posibilidad de concluir con las actividades que se están realizando.
El Daily Scrum está orientado a ser rápido y limitado a ese alcance. Pero he escuchado a los gerentes y a los asistentes decir:
- “15 minutos no es suficiente para tener una visión de lo que están haciendo todos”.
- “Les voy a platicar las reuniones que tuve ayer y lo que haré mañana”.
- “Realice un diseño de base de datos, que incluye estas tablas, estas relaciones, estas columnas…” y sigue explicando todo en detalle incluyendo como realizarle consultas a la nueva base de datos.
A ver, a ver… Primero que nada, los gerentes no deben de participar en estas actividades más que para escuchar lo que el equipo tiene que decir e identificar si requieren desatorar impedimentos durante el día. Se supone que solo las personas que están directamente involucradas en el desarrollo deben hablar, todos los demás escuchan. Tener al equipo de pie y desahogándose por una hora definitivamente no es ágil. No lo deberían llamar Daily Scrum solo porque están todos de pie. Es complicado mantenerse concentrado mientras estas parado y estás escuchando a solo dos personas discutir un tema muy especifico solo para que al final, no lleguen a un acuerdo y digan, “Lo revisamos más tarde en otra reunión”. Adicionalmente, considerando que estas reuniones se llevan por la mañana, he escuchado de muchas personas, que les genera des-motivación ya que se aburren y desvían sus energías desde el inicio del día.
Todo esto se debe a que al parecer nadie se adhiere a las 3 preguntas que debe de contestar: ¿Qué hice ayer?, ¿Qué haré hoy?, ¿Tengo impedimentos?. Si alguien tiene un tema especifico que tratar con otro miembro del equipo, se tiene que hacer en otra sesión, no todos se tienen que enterar en un Daily Scrum.
Tener a un equipo ágil significa cambiar la manera de comportarse y es altamente influenciado por la cultura de cada persona. Si los hábitos culturales invaden las actividades profesionales de tener largas reuniones de seguimiento solo una vez a la semana, te podrás dar cuenta que todos están atrasados y que los impedimentos no salieron a relucir hasta ahora que puede ser muy tarde. A su vez, llevar procesos ágiles no es solo cuestión del equipo de desarrollo, realmente involucra que toda la empresa cambie a pensar y actuar de manera ágil, ya que los usuarios o clientes están acostumbrados a pedirle al equipo de desarrollo lo que ocupan y volver cuando ya se termine todo. Agilidad implica que inclusive el cliente esté constantemente “pegado” al equipo de desarrollo recibiendo, probando y retroalimentando sobre los avances del producto.
Algo que he visto en equipos un poco más maduros, es que al final de un Sprint o Iteración, a lo mejor pueden terminar una especificación pero no lo despliegan a producción, y yo me preguntó, ¿Porqué no? El alcance de una iteración debería ser un entregable funcional y usable, ¿porqué esperar hasta que las otras iteraciones terminen y decir que estás siendo ágil con Scrum?
Lo que quiero transmitir es que muchos de nosotros, incluyendo equipos pequeños, malinterpretamos las “reglas” que Scrum y otros marcos de trabajo proporcionan para lograr flujos de trabajo ágiles.
Si los equipos se concentrarán en metas pequeñas, si siguieran los procedimientos que acordaron y no personalizarlos con la finalidad de “complementar” el marco de trabajo, solo hasta entonces, alcanzarán mejores resultados. De esa manera podrán convencer a los miembros del consejo que la inversión ya hecha realmente fue una inversión y no dinero tirado a la basura. Para así, evitar que estén amenazando al equipo de que el proyecto se cancelará. Además, el equipo se mantendrá motivado porque están siendo productivos y sabrán que su trabajo es estable. Evitemos la locura.
Locura: hacer lo mismo una y otra vez esperando obtener resultados diferentes.
