Sobre cerdos y gallinas

Aunque muy conocida la fábula o chiste del cerdo y la gallina, lo voy a reproducir en versión libre, para que sirva de introducción para el que no lo conozca.

“Se encuentran un cerdo y una gallina y deciden abrir un restaurante.

El cerdo dice: ¿como llamaremos al restaurante?

La gallina responde: Huevos con bacon

El cerdo contesta: No me parece justo, yo estaría comprometido mientras que tú solo estarías involucrada”

Los roles “cerdo” y “gallina” están presentes en todos los ámbitos de la vida, no solamente en SCRUM :-). En todas las comunidades, sociedades, equipos y convivencias, hay roles cerdo y gallina en mayor o menor medida.

La diferencia entre estar involucrado o comprometido, que a priori, se podría asociar al nivel de riesgo que se toma al participar en un proyecto; laboral o sencillamente de relación, en muchos casos se vuelve algo absolutamente subjetivo y cada uno cree ocupar un rol, que no es visto así por los demás.

Tenemos como “gallinas innatas” a aquellas personas que que se dedican a “estar”; en algunos casos, solo a “figurar”, que arriman el hombro en contadas ocasiones y solo, cuando no queda más remedio. Algunos de estos “fasiánidos”, suelen tener una habilidad especial, para aparecer cuando ha finalizado el trabajo.

Tenemos como “cerdos de vocación”, a aquellas personas que lo dan todo, que no reparan en sacrificios para conseguir el buen fin del proyecto y con los que puedes contar cuando se ponen las cosas feas. Este tipo de “suidos”, a menudo se ven eclipsados por los “fasianidos” cuando las cosas salen bien y cargan con las culpas cuando la cosa se tuerce.

Esta categorización puede parecer un poco extremista y de hecho, lo es, pero ¿le suena a alguien?. La realidad no es blanca ni negra y oscila sobre la escala de grises con el tiempo.

¿podemos elegir nuestro rol? . No, generalmente nos viene impuesto en cada caso, además no suele ser buena idea cambiarlo, no suele acarrear buenos resultados. Cada momento y cada escenario son una partida distinta, solo puedes jugar las cartas o pasar la mano, habrá otras.

El grado de implicación y compromiso es difícil de medir, además, bajo determinadas circunstancias, todos tendemos a pensar que los demás son las “gallinas” y nosotros los “cerdos” y esto en realidad no es más que un reflejo de nuestra propia frustración.

El cerdo y la gallina, sí pueden poner un restaurante juntos, solo hace falta cambiarle el nombre a "La tortilla de patata".

Releyendo Scrum y XP desde las Trincheras

El otro día se me ocurrió volver a leer el clásico de la literatura Scrum “Scrum and XP from the Trenches”, con el objetivo de comparar la aplicación de Scrum que se comenta en el libro y la que practicamos en mi organización. 

Cuando leí el libro por primera vez, antes de comenzar a aplicar Scrum, a medida que leía el libro trataba de prestar atención en aquellos aspectos en los que el autor ponía más énfasis, suponiendo que una vez inmerso en la práctica, esas cuestiones serían a las que más importancia darle. De forma inconsciente, fui haciendo una selección de estos aspectos para quedarme con un top-10.

Después de volver a leer el libro, e intentar hacer un top-10, la verdad es que lo he tenido más difícil, ya que algunas cuestiones que pasé por alto en su momento, han adquirido ahora una especial relevancia.

En el libro se insiste en que no hay una regla única para aplicar Scrum y que se debe probar con diferentes formas de hacer las cosas, hasta dar con la que mejor se ajusta al contexto donde se aplicará. En efecto eso es así, tanto que incluso si en la primera iteración de su aplicación nos encontramos cómodos, debemos probar a hacer cambios, incluso a sabiendas de que alguno de los cambios que hagamos será a peor, pero eso también sirve para encontrar el modelo óptimo para tu caso.

No se debe tener miedo a cambiar las cosas incluso si creemos que lo que hacemos ya está bastante bien. La mejora continua, debe ser una constante.

Volviendo al tema del libro, uno de los aspectos a los que se le da mucha importancia, pero que yo no supe ver en su plenitud tras la primera lectura, es el conocimiento de la velocidad de los equipos. Al principio pensé que era un indicador más, pero he observado que es vital en dos aspectos que inicialmente no di demasiada importancia: la reducción del riesgo y la mejora continua.

Reducción del riesgo: La estimación y la planificación de un proyecto, no tendrá base objetiva si no conocemos este dato y por lo tanto, estaremos más expuestos a incurrir en retrasos y sobrecostes, sobre todo cuanto más grande sea el proyecto.

Mejora continua: La evolución de la velocidad de los equipos, será un claro indicador de la madurez de los equipos, y como eso se traduce en una mejora de sus resultados. Si analizamos los picos y valles en la evolución de las velocidades y los contrastamos con acciones o cambios introducidos en los equipos, podremos sacar jugosas conclusiones.

Otro aspecto que ha adquirido una especial relevancia para mi, ha sido la importancia del artefacto “Sprint Burn Down Chart”, sobre todo si comparamos la evolución de estas gráficas a lo largo de los distintos Sprints. El seguimiento diario de su evolución permite aprender mucho de como estamos distribuyendo y abordando las historias. No hace falta asistir a todos los “Daily” para darse cuenta mirando este gráfico, de que algunos miembros del equipo repiten durante demasiados días “Sigo trabajando en X”.

La verdad es que ha sido un buen ejercicio leer de nuevo este libro, ha sido como juntarse con algún colega para compartir experiencias sobre Scrum.

No se si ya lo ha dicho alguien antes, pero se me ocurre que un buen consejo para finalizar, sería: “Se práctico y no escatimes esfuerzos en ahorrar trabajo”.

Si alguien no conoce el libro y está interesado en su lectura, se puede descargar de Internet en formato PDF, tanto en inglés como en castellano. Es una lectura amena y no lleva demasiado tiempo leerlo.

No pongo ningún enlace ya que se puede encontrar con facilidad y existen numerosos sitios de descarga.

Factores clave en la adopción de Scrum por las empresas de TI

Las metodologías ágiles en general y Scrum en particular, están gozando de creciente aceptación y aplicación en nuestras empresas de TI. Aunque estas metodologías no son nuevas, si es verdad que en los últimos 2 o 3 años se han percibido sus beneficios de forma sustancial, todo ello motivado seguramente por aspectos externos como el propio mercado, la crisis económica, etc.

La metodología Scrum tiene unos fundamentos sencillos y aunque a primera vista pueda parecer simple de aplicar y nada nuevo respecto a lo que hemos venido haciendo tiempo atrás, en realidad no es así y aunque sus principios son pocos y sencillos, es imperativo seguirlos para que la aplicación de la metodología consiga el objetivo.

Sin entrar en detalle de como se aplica la metodología, que significan sus roles, artefactos, métricas, etc., si me gustaría señalar algunas cuestiones clave para la aplicación de Scrum y sobre las cuales merece la pena reflexionar antes de adoptar esta metodología.

En cualquier caso, antes de plantearse adoptar Scrum como metodología de trabajo, habrá que pararse a pensar si cumplimos ciertos requisitos o qué podemos hacer para cumplirlos antes de comenzar.

Aunque hay muchos aspectos importantes a valorar, como por ejemplo la comunicación, la implicación del cliente, la estabilidad, etc., quiero centrarme en dos que para mí tienen una especial relevancia: El Cambio organizacional y el Compromiso del equipo.

El cambio organizacional

Por lo general, en la mayoría de las empresas, existe un organigrama demasiado jerarquizado, que no encaja demasiado en la definición de roles de Scrum. En este sentido, la dirección de la empresa debe remodelar la estructura para “achatar la pirámide”.

El cambio organizacional, es quizá el más controvertido a la hora de aplicarlo. Ya no tiene sentido hablar de Jefe de Departamento, Jefe de Proyecto, Analista Funcional, Analista Programador, Programador Senior, etc. donde cada uno parecía tener sus funciones acotadas y de la misma forma que representaba la estructura, se procedía a un trabajo en cadena, donde cada uno hacía una parte y se la pasaba al siguiente. Esto en Scrum ya no tiene sentido.

Es un error habitual, es asimilar el rol tradicional de Project Manager al de Scrum Master. Un Project Manager puede convertirse en Scrum Master, si sus skills le permiten ser un facilitador, pero ya no tiene por que ser un buen gestor. Ahora el equipo se autogestiona.

Es complicado para la empresa, acometer un cambio en la estructura, pero seguramente es más complicado para las personas, que de repente pierden su “status” y se disuelven en un “Scrum Team”. Esto hay que saberlo gestionar adecuadamente para que se traduzca en una oportunidad en vez de una amenaza para las personas.

El compromiso del equipo

En Scrum, el equipo y el trabajo en equipo adquieren una nueva dimensión, ahora el equipo es un ente con atribuciones que hasta ahora, solo recaían en ciertas personas en particular. Ahora el equipo se autogestiona y toma sus propias decisiones.

El objetivo es pensar en el equipo como un ente único, pero queramos o no, los equipos los forman las personas y las personas tienen sus virtudes y sus defectos.

Las personas brillantes son siempre bienvenidas en todos los equipos, pero el problema surge cuando alguna de estas personas por ego profesional o personal, trata de imponer sus criterios o manipular al resto del equipo. Las individualidades deben supeditarse al equipo y el éxito o el fracaso es siempre del equipo, no de las personas por separado.

Cualquier persona, siempre tiene algo que aportar al equipo, solamente es cuestión de buscar que es y aprovecharlo. No sirve dejarse llevar, siempre hay que aportar.

Dentro del equipo, las personas deben confiar unas en otras y ser transparentes en su trabajo, si no es así, deberán cambiar algunos de sus anteriores hábitos.

El cambio de mentalidad puede llegar a ser un problema si no se gestiona adecuadamente por parte de la organización. En este sentido, será preciso hacer una labor de mentalización y convencimiento para que las personas tengan claro que su apuesta debe ser por el equipo.