Muchas de las implantaciones de Scrum ( u otras metodologías ágiles ) que he conocido estos años son implantaciones que podríamos llamar bottom-up, es decir que parten del equipo de desarrollo. Estos se dan cuenta que no pueden continuar con la organización que llevan ahora y deciden tomar cartas en el asunto y empezar a hacerlo por ellos mismos. Es lo que se denomina comúnmente agilismo de guerrilla.
Aun siendo una muy buena opción para empezar ( yo empecé así ) a la larga se acaba quedando corta y es necesaria la implicación de la gerencia para llegar a algo más completo. Para mi los principales puntos débiles son:
-
Adolecen de un mentor experimentado: en la mayoría de los casos, el equipo se ha documentado sobre Scrum y empieza a probarlo.
-
Mala repartición de los roles: sobretodo si sólo está utilizando Scrum un equipo, hay gente que tiene dos roles: equipo y Scrum Master o equipo y Product Owner. La por situación es si hay alguien que tiene los tres roles, en lo que esto tiene muchos números de convertirse en un command and control encubierto.
-
Product Owner poco implicado: al ser un miembro del equipo le va a costar hacer de Product Owner. No va a tener relación directa con el cliente, no va a saber todo lo que se tiene que hacer a lo largo del tiempo o no le va a gustar definir bien las historias.
Veamos este punto con un poco más de detalle. Todas las cosas en contra que he comentado no tienen porqué pasar... pero tienen muchos números de que pasen. A los desarrolladores en general no nos gusta demasiado hacer especificaciones, definiciones de acabado y cosas por el estilo. Por lo menos a mi no me entusiasma ni a ninguno de mis compañeros. Esto desemboca en que nuestro Product Backlog no sea lo que tendría que ser.
Pero llega un día en que alguien con mucha más relación con el cliente y con visión del producto se instala en tu equipo. Y empieza a generar un Product Backlog con todas las historias que quiere que a corto/medio plazo se implementen, las prioriza, detalla más las más importantes, especifica las condiciones de aceptación de cada una de ellas. Este día será un día importante en tu historia dentro del proyecto. Los cambios más importante que se producirán en tu equipo para mi son:
-
Ánimo dentro del equipo: ver que la gerencia se preocupa por el proyecto y pone toda la carne en el asador para que tire adelante anima a la gente.
-
Mayor cuidado con la aplicación: todos somos profesionales y estamos comprometidos, pero no es lo mismo que cada quince días el equipo le haga a un Product Owner "externo" la demo del sprint que se la hagan entre ellos.
-
Mayor acierto con la implementación de las histórias: el equipo desarrollará lo que el Product Owner quiere, no lo que él cree que el Product Owner quiere.
-
Mayor visión del producto: el equipo sabe hacia donde tirará el proyecto y puede tomar decisiones en función de ello.
Por lo tanto, si tienes ya un buen Product Owner en tu equipo, cuídalo y no lo dejes marchar, y sinó búscate uno en quanto puedas!
Nota 1: este post está basado en hechos reales. Ningún Product Owner, Scrum Master o miembro del equipo ha sido maltratado en la realización del mismo.
Nota 2: este post está basado en mi experiencia. Si la tuya es diferente, no dejes de contarla en los comentarios!
No hay comentarios:
Publicar un comentario