Loading Likes...

El pasado dos de Marzo, GSBIT nos invitó a compartir la experiencia gestionando nuestro día a día con Scrum en varios de nuestros equipos. La cita era parte de los desayunos TIC que organiza la asociación. En este caso fui yo, Pablo Bernardo, el encargado de acudir como uno de lo Scrum Masters de habitissimo.

El formato es interesante. Un grupo de asistentes, más de veinte en este caso, comparte mesa sentados en el Café Cuba. Mientras tomamos un café, se expone la temática durante una media hora, seguida de al menos otra media hora para responder dudas y poder debatir.

Desde el principio tuve claro que lo interesante no era en este caso acudir para evangelizar sobre Scrum. Hay mucha bibliografía y blogs que se pueden leer para aprender la teoría sobre qué es Scrum, como se debe implementar y cuales son los errores clásicos. Lo interesante de esta oportunidad era explicar algo más aterrizado; nuestro caso real, concretamente. Esto quedó claro desde el comienzo de la charla. Una de mis primeros puntos fue explicar que no estaba allí para convencer a nadie de que trate de implantar Scrum en sus empresas. Solo para explicar cómo hacemos nosotros para bien y para mal y tratar ver si a alguien le sirve nuestro aprendizaje.

El perfil de los asistentes era variado, desde desarrolladores hasta directores de alguna compañía pasando por varios gestores de proyecto. Esto, evidentemente, condiciona un poco el contenido de la charla. No podemos hacer el mismo hincapié en todos los puntos de la misma manera, sabiendo que interés y el punto de vista de los participantes es tan distinto. Por eso lo que traté de aportar fue un recorrido general por los puntos básicos de la guía de Scrum, anotado en este caso con todo aquello por lo que ya hemos pasado y estamos pasando.

En toda organización, cuando hay un cambio en los sistema de organización y gestión siempre surgen dudas, resistencias, conflictos y demás. Esto se multiplica cuando hablamos de pasar a organizarse a fondo a través de metodologías ágiles. No suelen ser siempre bien entendidas y aceptadas por todas las partes implicadas y es ahí donde empieza una parte muy interesante de pedagogía y negociación para el Scrum master. En habitissimo no tenemos problemas en reconocer que nos equivocamos y compartir el aprendizaje, así que a eso nos lanzamos.

Parte del contenido de la charla fue explicar cómo iniciamos el proceso de reorganización a través de Scrum. Tradicionalmente ya habíamos aplicado algunas prácticas de Scrum,  pero eramos conscientes de que lo hacíamos con muchas carencias y probablemente demasiadas licencias respecto a lo que el marco de trabajo recomienda. Hace unos meses nos propusimos ponernos muy en serio a implantar Scrum de una manera ordenada y mucho más ortodoxa. Queríamos ser capaces de seguir equivocándonos, pero poder detectarlo pronto y corregir rápido. Sabiendo que no iba a ser fácil, eso sí. Nos gustan los retos.

Durante la charla compartí muchas de las dudas típicas que suelen aparecer en las empresas y cómo nosotros las hemos solventado. Por ejemplo qué debe o no hacer un Scrum master respecto a la distribución de tareas, resistencias típicas de la parte de negocio tipo cómo se va a controlar si la gente está trabajando todo lo que puede y otras como ¿tengo que hacer de verdad tantas reuniones? ¿cómo hacéis las estimaciones? ¿de verdad hace falta que todo el mundo participe en todo eso? Como casi todos los equipos que trabajan por Scrum, hemos pasado por todo esto.

Tampoco hay reparo en compartir cosas que aún no estamos haciendo bien del todo y somos conscientes. No tenemos bien asimilada en todos los equipos la necesidad de que alguien se dedique a fondo a las tareas de Product Owner, ni la interferencia posible de competencias y tiempos dedicados cuando un desarrollador lleva a cabo las tareas de Scrum master. Pero realmente no lo vemos como problemas, son etapas que forman parte del proceso de transformación y contar cómo lo estamos gestionando ayuda a otros en su propio proceso y a nosotros a ser más conscientes.

Por supuesto también los éxitos. La productividad, la responsabilidad e implicación de nuestros equipos ha mejorado muchísimo con los cambios. Esto se nota no solo en ellos sino, lo que es fundamental, en la mejora del aporte que hacemos a producto. Y esto también lo contamos en el desayuno, para que se vea el impacto que se puede llegar a conseguir.

La parte del coloquio me resultó súper interesante porque salieron algunos temas que me esperaba pero también otros que me sorprendieron. Se hizo patente que muchas veces la resistencia viene de preguntarse cómo puedo adaptar Scrum a mi empresa, lo que en muchos casos supone un error de base porque Scrum implica algunos cambios de paradigma. No vamos a poder hacerlo funcionar si no estamos dispuestos a hacer cambios en cómo se organizan los desarrolladores, cómo tratamos y negociamos con los clientes o la manera en que distribuimos el trabajo.

También apareció algún caso de intento frustrado de implantación en el que parecía claro cual había sido el problema. Scrum no es la solución para todo ni tiene por qué servir para todos los flujos de trabajo. Para algunos casos, comentamos allí, hay otras metodologías como Kanban que se pueden adaptar mejor. Tratar de meter un método con calzador donde no encaja puede llegar a provocar desastres y mucha frustración, hay que tenerlo presente antes de intentarlo.

Aparecieron temas interesantes como la experiencia en algunas empresas de servicio con esta metodología, que nos explicaron cómo han resuelto ellos algunas de las particularidades de trabajar con varios clientes en varios desarrollos de manera simultanea. Incluso la aclaración de que ya se están estableciendo relaciones contractuales con clientes en las que se establecen los plazos de entrega por sprints e incluso la posibilidad de terminar la relación contractual al finalizar uno de ellos.

El balance para mí y parece que para muchos de los asistentes es muy positivo. Compartir aprendizajes nos sirve para aprender unos de otros pero también para hacer auto-evaluación de dónde estamos y de dónde venimos. Algo que cuesta hacer en el día día pero que, por otra parte, forma parte esencial del proceso de trabajar con Scrum.

Loading Likes...

Deja un comentario

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