Implantación de metodologías Ágiles (Scrum, Kanban) en grandes organizaciones.

La integración de metodologías Ágiles en grandes organizaciones muchas veces plantea problemas,
sobre todo a nivel organizativo y de resistencia al cambio.

Según mi experiencia, al llegar a una organización para trabajar con Scrum/Kanban muchas veces
sin darnos cuenta entramos como un elefante en un cacharrería dando por sentado muchas cosas que
para nosotros son obvias, pero que para el resto de la organización tenemos que tener en cuenta
no lo son, esto nos planteará a la larga problemas sobre todo de resistencia al cambio por parte
de algunos actores que intervienen en la implantación, ya sea por parte de los jefes de proyecto,
personal de la oficina de proyectos, etc… No por nada, sino por desconocimiento de la nueva
metodología y porque están acostumbrados a trabajar en el desarrollo en cascada, una forma
diferente a lo que propone el marco de trabajo de Scrum.

Para evitar esto, lo más óptimo es la implantación de forma gradual para que todos los
implicados entiendan conceptualmente el modelo de trabajo.

Paso 1. Según mi experiencia lo mejor es empezar realizando charlas o cursos de formación
(en una palabra, evangelizando) a los equipos para que entiendan el modelo basado en flujos
de trabajo que propone Scrum/Kanban antes de comenzar ninguna implantación. Parece de perogrullo
lo que estoy diciendo pero ya os digo que me he encontrado con equipos donde les ha dado una
charla de 30 minutos el «scrum master» de la organización y les han soltado al ruedo a pecho
descubierto…

Una vez hecho esto todos deberían de entender por lo menos el concepto de trabajo
basado en flujos.

Paso 2. Ahora cada uno tiene que crearse un tablero Kanban personal muy sencillo donde tienen
que ir indicando las tareas que realizan en su día a día y en que estado se encuentran.

Los estados para cada tarea pueden ser: pendiente de hacer, listo para hacer,
trabajando en ella y finalizada o realizada.

Una de las cosas a poner en el tablero Kanban (que creo que es de las más importantes) es la
de indicar la cantidad de tareas que son capaces de realizar en paralelo cada uno de ellos,
en definitiva, la capacidad de trabajo.

El objetivo del tablero Kanban personal es mejorar la productividad. Muchas veces los individuos
no son conscientes de la cantidad de tareas que realizan a largo del día, de esta forma se tiene
visibilidad sobre ellas y sirve para que sean capaces de identificar cuellos de botella en base
a la capacidad de trabajo marcada por ellos.

Todo esto va a permitirles realizar una mejora continua basada en la evolución de las tareas
recogidas en sus tableros.

A modo de ejemplo aquí os dejo un tablero Kanban personal que yo he utilizado:

En este caso aparecen las siguientes columnas que se corresponden con los siguientes estados
mencionados anteriormente:

Backlog > ToDo > WIP (Work In Progress) > Done

Pendiente de hacer > listo para hacer > trabajando en ella > finalizada o realizada.

Paso 3. Una vez hecho esto el paso siguiente es el de realizar un tablero Kanban departamental,
donde se recoge la representación del trabajo que está realizando un equipo de un departamento en
concreto. Lógicamente en este tablero se recogerán las tareas a un alto nivel sin llegar al detalle
que puede aparecer en los tableros Kanban personales. Las columnas a indicar en este tablero
difieren muy mucho dependiendo del trabajo que se realiza en cada departamento, aquí os dejo uno
donde se recogen los estados para el caso de un departamento encargado de dar soporte de
aplicaciones a otras áreas de la empresa.

Incidencia > ToDo > WIP > Des > Pre > Pruebas > Pro

Ejemplo de maqueta del tablero Kanban departamental:

En este caso se utilizarán post-it de diferentes colores para indicar la criticidad de la
incidencia.

Paso 4. Llegados a este punto ya podríamos empezar a utilizar Scrum en el desarrollo de
nuestros proyectos, ya que por lo menos nuestros equipos están ya acostumbrados a trabajar en base
a flujos y utilizando tableros Kanban, con lo que les va a ser mucho más fácil entender la dinámica
del trabajo.

Sobre esto tengo que indicar que creo que es necesario hacer una reflexión siempre antes de
iniciar un proyecto y es que hay casos en los que No es necesario aplicar Scrum a todos los
proyectos…

Nos estamos empecinando muchas veces en utilizar la metodología ágil de Scrum en proyectos
donde no hubiera sido necesario hacerlo.

Por ejemplo, en todos aquellos proyectos donde no se necesite una construcción incremental del
producto o en todos aquellos proyectos donde está perfectamente definido el alcance, los
requisitos o historias de usuario están claras y por tanto se ha podido hacer una valoración
detallada del proyecto y se tienen además unos plazos de entrega claros. ¿Es necesario utilizar
Scrum?, creo que la respuesta es NO, lo único que podría hacer que me decantara por utilizarlo
sería en el caso en el que el equipo de desarrollo fuera nuevo y quisiera tener un mayor control
sobre él, ya que Scrum me da los mecanismos para que a través de los daily Scrum,
retrospectivas etc… tenga un mayor control sobre el proyecto y el equipo…

Otra de las situaciones que me he encontrado donde me parece complicado utilizar metodologías
ágiles es en el caso en que el equipo de desarrollo y el de gestión estén deslocalizados
(esto no significa que no se pueda utilizar, pero sí que a mí me ha dado dolores de cabeza más
que otra cosa).

Quiero contaros mi experiencia sobre el siguiente escenario: En este caso es un cliente donde
el desarrollo se subcontrata a un proveedor externo pero la gestión del proyecto se realiza desde
las oficinas del cliente y además el equipo de pruebas se subcontrata a otra empresa distinta a
la que realiza el desarrollo y las pruebas además se realizan desde las oficinas de este otro
proveedor.

Primer problema: las reuniones de daily scrum se realizan por video conferencia por lo que la
cercanía y el feeling diario persona-persona que creo que es importante en todo equipo,
se pierde.

Segundo problema: durante las video conferencias se revisa el tablero físico Kanban, el cual
tiene que estar sincronizado con el que maneja el responsable de la gestión de proyectos y el
equipo de pruebas, lo que al final se convierte en un caos, porque cuando cambia algo hay que
notificarlo al resto, etc…

Para que no os ocurra lo que a mí os recomiendo lo que al final tuvimos que hacer, y es la
utilización de una herramienta software para que todos los miembros del equipo tuvieran los
datos actualizados. Sé que queda muy vistoso eso de utilizar un enorme tablero kanban en una
pizarra llena de postit, pero creedme, en este caso fue un infierno….

Al final, el proyecto, después de mucho luchar llegó a buen puerto, pero os puedo decir que
con un esfuerzo extra por parte de todos los miembros del equipo.

Con esto os quiero decir que por lo menos reflexionéis antes de abordar un proyecto basado
en Scrum, principalmente para minimizar el impacto de su utilización y si os encontráis con
proyectos con unas características singulares, como el que yo os he contado y que habéis
abordado con Scrum, os invito a que contéis lo bueno y lo malo con lo que os habéis encontrado
a la hora de ponerlo en marcha, al igual que yo he intentado mostrar en este artículo….

Si quieres conocer más sobre mi experiencia en metodologías Ágiles, puedes ver el
siguiente artículo:

Cuando llega el día de informar a la dirección de proyectos sobre el estado de un
proyecto Ágil (Scrum)

Por supuesto al igual que en artículos anteriores cualquier crítica o petición de aclaración
sobre cualquier parte del artículo será bienvenida