La realidad de Scrum en el día a día del desarrollo de software no es color de rosa. Los equipos de desarrollo la pasan mal cuando pocas veces se implementa correctamente. Lo que debería ser un proceso fluido y colaborativo termina convirtiéndose en una pesada carga burocrática. Los equipos no logran adaptarse ni entender cómo sacarle el jugo a esta metodología, y al final del día la frustración se apodera del ambiente. Sin una buena base, todo el potencial de Scrum se diluye y los desarrolladores terminan odiando algo que podría ser genial.
El rechazo a Scrum viene de la mano de las dailies que no sirven y reuniones de planificación que parecen un desperdicio total. Los equipos quedan atrapados en un ciclo interminable de charlas que no llevan a ningún lado, con una comunicación que no fluye como debería. La burocracia se come todo el tiempo que podríamos estar usando para hacer lo que más nos gusta: programar. No sorprende que los desarrolladores pierdan las ganas y se desconecten de sus proyectos.
Quejas comunes sobre Scrum
Los equipos de desarrollo viven una realidad compleja con Scrum. Los desarrolladores expresan su frustración con las dailies no sirven, la planificación es una pérdida de tiempo y hay demasiada burocracia. Estas ideas generan un ambiente tenso y bajan el ritmo de trabajo del equipo. Acá están los puntos que más me preocupan:
- Las dailies no sirven
- La planificación es una pérdida de tiempo
- Demasiada burocracia
Implementación incorrecta en equipos feature
Los equipos de desarrollo reciben todo servido en bandeja. El 90% de los ‘feature teams’ laburan con requerimientos pre-armados, sin poder meter mano en el proceso creativo. Los devs terminan programando como autómatas, y así se pierde toda la magia de Scrum. Esta forma de laburar genera un montón de bronca y desinterés en los equipos. Los pibes se convierten en robots que solo ejecutan código, y por eso después todos miran mal a la metodología. Sin un foco real en laburar juntos y mejorar día a día, Scrum se transforma en un montón de ceremonias vacías.
Todo este quilombo de no dejar que los equipos metan mano en definir los problemas hace que los pibes pierdan las ganas. Los desarrolladores sienten que su laburo no mueve la aguja. Los procesos se vuelven un dolor de cabeza en vez de ayudar. La posta está en armar un ambiente donde todos puedan tirar ideas y criticar constructivamente. Solo así vamos a poder dar vuelta la tortilla y sacarle el jugo a Scrum en el desarrollo de software.
Experiencia personal con Scrum en trabajos anteriores
La realidad de mis laburos anteriores me pegó fuerte cuando vi cómo le erramos feo con no se implementó bien Scrum. Los daily se transformaron en un trámite más, sin sentido ni dirección. La planificación se volvió un embole total porque nadie se animaba a poner sobre la mesa los quilombos posta del equipo. Todo terminó siendo un montón de burocracia que no sumaba nada, y al final el grupo entero se la pasaba con la moral por el piso y sin ganas de hacer nada.
La falta de un Scrum Master que la tuviera clara nos jugó una mala pasada tremenda. Sin nadie que nos guiara como corresponde, el equipo se quedó a mitad de camino. Las tareas se estiraban como chicle, y nadie se calentaba por cumplir con lo que había que hacer. Al final, todo ese chamuyo de ser más productivos y mejorar día a día quedó en la nada misma, puro verso sin ningún resultado real en el laburo diario.
Cambios positivos al usar Scrum en SquadS
La puesta en marcha de Scrum en SquadS nos trajo una onda totalmente distinta al equipo. La conexión en el equipo fluyó naturalmente, y las ideas empezaron a circular con más libertad. Me copa ver cómo la definición de problemas quedó más clara para todos. El ambiente de colaboración se potenció y la eficiencia en el desarrollo de software pegó un salto que nos tiene contentos a todos.
La realidad es que también nos topamos con algunas piedras en el camino. La falta de priorización en las tareas nos complicó bastante, y nos costó concentrarnos en lo verdaderamente importante. Por otro lado, nos mandamos cualquiera con los tiempos: la subestimación de los tiempos nos jugó una mala pasada más de una vez. Tenemos que ajustar estos puntos si queremos que Scrum funcione como corresponde y que el equipo siga creciendo.
