Síntomas de que la agilidad no está bien implementada en una empresa.

Lo primero, ¡feliz año 2015! La verdad es que cuando comienza un año nuevo siempre me vuelvo melancólica. Me gusta echar la vista atrás al año que dejo y ver lo que he aprendido y lo que más me ha marcado ese año.
Sin duda, a nivel profesional, una de las cosas que más me ha marcado es formar parte de 233 Grados de TI, y todos los proyectos en los que hemos participado este año.
En 2014 me atrevería a decir que una de las cosas que más se han repetido, ha sido que nos contrataran para ayudar a mejorar o implantar Scrum, agilidad, Integración Continua etc.
Y lo más complicado, pero que a la vez me encanta, es lidiar con el cambio de mentalidad, de cultura, que eso supone.
En muchas empresas implantar Scrum no es tan sencillo. Que los valores y prácticas ágiles realmente se asuman y se apliquen cuesta su tiempo, y mucha gente no se da cuenta de ello. Hay muchas empresas que creen que son ágiles, pero realmente no lo son.
La agilidad conlleva un cambio en la forma de organizar equipos, de entender la calidad, de probar (el testing no se tiene que dejar para el final), por mencionar algunos aspectos.
Hoy me gustaría resumiros una experiencia en uno de esos proyectos en los que colaboramos en el 2014, que empezó con un “somos ágiles, pero seguimos igual, tenemos muchos fallos en producción” y en el que terminamos detectando y resolviendo problemas que indicaban que realmente la cosa no era tan sencilla como parecía.
Voy a explicarte de forma resumida ciertos síntomas que nos hicieron notar que la agilidad no estaba bien asumida, y el porqué de ello.
Lo cierto es que había una gran diferencia entre lo que los managers creían que se hacía, con lo que realmente pasaba en el día a día.
Todo empezó con la siguiente frase:
 

1 – Somos ágiles, usamos Scrum con iteraciones de 3 semanas. Desarrollamos durante 2 semanas y dejamos la última semana del sprint para hacer las pruebas.

Esta frase, en este proyecto en concreto, podría resumir la situación de muchas más empresas a las que hemos ido en 2014. No terminan de ser ágiles del todo, el testing lo hacen al final, tienen un mini cascada, una fase monolítica de testing al final (No se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints))
[box type=»shadow»] Si dejas las pruebas para el final, no eres ágil. Tienes que probar desde el principio, para tener más tiempo de reacción y detectar los fallos lo más antes posible.[/box]
¿Qué es preferible, detectar un fallo enorme en la semana 2 de la iteración o horas antes de subir a producción?
¡Dejando las pruebas para el final tenemos muy poco tiempo de reacción! Cuesta más resolver un fallo en este punto que justo cuando se implementó la funcionalidad.
 

2 – No, no, pero la última semana hacemos regresión, y mientras, hacemos pruebas por historia de usuario, cuando los desarrolladores terminan de programar. (O eso me dijeron que hacían)

En este caso, un simple vistazo a la herramienta de gestión de defectos mostraba que había un problema.
La mayor actividad se centraba en la última semana de la iteración. En esa semana se abrían más defectos, por no decir que todos se abrían en esa semana.
[box] Si realmente eres ágil, la detección de defectos debería ser más o menos constante, y todos los fallos no deberían surgir al final del sprint, sino más repartido.[/box]
 

3 – Muchas tareas en done, pero nada se ha probado

Por otra parte, he de decir que soy fan de los tableros de Scrum en la pared. Me encanta ver el progreso de las historias de usuario y la colaboración y comunicación que se genera en torno al tablero. Y cuando voy a los proyectos me fijo en ellos.
En este caso, en un punto del sprint me llamó la atención que había muchas tareas en “done”. ¿Y no han surgido defectos?
Un tester me dijo que no habían probado las historias de usuario. No había podido porque su entorno de pruebas no era estable, porque los desarrolladores no le habían podido instalar lo que tenía que probar.
 

4 – Entornos de pruebas inestables

O sea, los tester no pueden probar más frecuentemente porque su entorno es inestable.
Y ese “no me han podido instalar” nunca me gusta.
[box] Soy partidaria de que eso esté automatizado y cualquiera pueda instalarse en su entorno una versión concreta de la aplicación que esté en el control de versiones.[/box]
 

5 – Problemas con el control de versiones

¿Y qué versión tienes ahora? Pregunté.
No sé, lo que me suben.
Ahí está. Problemas en el control de versiones. No está controlado lo que hay instalado en cada entorno.
 

6 – Las actividades de testing no están incluidas en la planificación, en las reuniones, en la velocidad del equipo + Mala definición de DONE.

Además, no nos va a dar tiempo a probarlo todo. Quedamos en que subirían el código al entorno de QA el Lunes, y estamos a Jueves y todavía mi entorno es inestable.
¿Habéis planificado algún colchón, un margen en la velocidad del equipo por si pasan estas cosas y no os da tiempo a probar?
No, si QA va separado. La velocidad del equipo es de desarrollo. El testing no está incluido en las estimaciones ni en la velocidad ( ¿Qué es la velocidad en un proyecto software (normalmente ágil o Scrum)? Aclaración de dudas frecuentes).
Otro síntoma de testing en cascada, de mentalidad no ágil.
El equipo debe definir la definición de terminado de una historia de usuario ( En un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)).
[box]Lo recomendable es que una historia de usuario esté terminada cuando se prueba.  El testing está incluido en las tareas que hay que hacer en la historia de usuario, por lo que hay que estimar el tiempo que me lleva probar, e incluir las actividades de testing dentro de las planificaciones, de la velocidad del equipo.
El departamento de QA no debe tener su planificación, y desarrollo otra. Los testers están dentro del equipo que sea.
[/box]
Seguí tirando del hilo.
 

7 – Equipos no multidisciplinares

Por lo visto “Pepe” tenía muchísimo trabajo, y no pudo terminar todo a tiempo.
Ese comentario me pareció raro, porque había gente de ese equipo que estaba muy relajada. ¿Por qué esa gente no ayudaba a Pepe?
No, es que Pepe se encarga de desarrollar funcionalidades que tocan el componente X. Solo Pepe sabe hacer eso.
En este sprint había dado la casualidad de que muchas tareas tocaban ese componente. Se estimaron mal, y Pepe no podía con todo.
Esto es un gran síntoma de que realmente tu equipo no es ágil, no es multifuncional. ¿Qué pasa si Pepe se va de vacaciones? ¡Se acaba el mundo!
[box] Un equipo multifuncional debería estar más equilibrado, aunque haya gente especialista que se le dé mejor ciertas cosas, casi todo el mundo debería saber o estar dispuesto a tocar de todo (Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad) .[/box]
Así podrían haberle echado una mano a Pepe.
 

8 – Mala definición de las historias de usuario

Además, de que la definición de historias de usuario no ayudaba demasiado. Había historias de usuario especializadas: solo de backend, solo de frontend etc.
[box]Las historias de usuario deben definirse a nivel de lo que quiere el usuario, que luego puede traducirse en tener que tocar un poco de backend, un poco de frontend etc.
Así la gente tiene que saber un poquito de todo.
[/box]
 

9 – No hay sentimiento de equipo ágil + Los testers son policías + La calidad es de QA, no de desarrollo

Lo peor de todo, es que me di cuenta de que no había sentimiento de equipo.
No, esas tareas son de Pepe.
No, yo desarrollo y luego que el tester pruebe que está bien. Si no, ya vendrá a decirme algo.
¡Un tester forma parte del equipo! La calidad no debe ser algo del final, deberías hacer las cosas con calidad, como se esperan.
Un tester ágil no es el que va a romper el sistema una vez ya está algo desarrollado.
[box] La mentalidad ágil es que tanto los testers como los desarrolladores trabajen en conjunto para hacer las cosas bien desde el primer momento, detectar fallos lo antes posible, solucionar problemas de mala interpretación de las historias de usuario etc.[/box]
Los testers no son policías que vienen a fastidiar lo que los desarrolladores hacen, a controlar que todo esté bien después.
 

Terminando…

En este proyecto convertimos un “somos ágiles, pero no notamos mejoría, tenemos muchos defectos al final” en actividades y acciones de mejora para, entre otras cosas:
– Hacer que los miembros del equipo fueran multidisciplinares: Formaciones, pequeñas charlas los viernes de la gente que más sabe de algún tema etc.
– La estrategia del control de versiones (¿Qué estrategia de control de versiones seguir en un equipo Scrum?, Feature toggles: ¿Qué pasa si no quiero crear una rama por historia de usuario? )
– Las promociones de código entre entornos.
– La estabilidad de los entornos.
– La división y definición de historias de usuario.
– Integrar a los tester en el equipo, en las estimaciones, en las reuniones.
– Fomentar la colaboración y el sentimiento de equipo.
– Que todo el mundo sienta como propia la calidad, las pruebas, y no algo que se deja para el final.
– Probar desde el principio, más frecuentemente: utilizando BDD, implementando Integración Continua, automatizando ciertas pruebas etc.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Síntomas de que la agilidad no está bien implementada en una empresa.”

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *