Especialización dentro de SCRUM

0

He pensado comenzar el artículo de muchas maneras. Algo gracioso, algo ocurrente, … Al final creo que lo mejor es ir directamente al grano. Así que empecemos directamente con un spoiler del final de este artículo:

Los miembros de los equipos ágiles tienden a especializarse, y eso no es bueno. Hay que romper esta tendencia.

Si no pones mecanismos en juego que lo eviten, los miembros del equipo empezarán a especializarse y cuando quieras darte cuenta ya no tendrás un equipo, sino un conjunto de roles. ¿Por qué pasa? ¿Cómo lo evitamos?

Todos los caminos llevan a Roma

Cuando diseñas un equipo SCRUM le asignas unas responsabilidades. Me refiero a responsabilidades de equipo. Son responsabilidades como por ejemplo, la de acometer un determinado proyecto, hacerlo con la calidad adecuada, mantener otros proyectos que se entregaron en el pasado, etc. Estas responsabilidades que se le asignan al equipo se terminan convirtiendo en tareas, las cuales requieren de habilidades diferentes. Necesitaremos hacer análisis de algunas tareas. Otras necesitan desarrollo, que puede ser en distintas tecnologías o con distintos productos. Otras pueden requerir conocimientos de negocio de una determinada área. Otras estar relacionadas con testing o con QA. Otras con sistemas y preparación de entornos. Otras de documentación, que podría llegar a ser en varios idiomas. Etcétera.

En SCRUM se definen dos roles, un product owner y un scrum master. El resto es el equipo. Pero el día a día, si el scrum master no lo controla, les llevará a ir especializándose y a crear nuevos roles dentro del equipo. Y lo peor de todo, la organización les animará o incluso impondrá que se creen esos roles. ¿Por qué pasa esto?

La especialización aumenta la productividad

Este es un mito fácil de entender. Imaginemos que hay dos habilidades: A y B. Y tenemos dos personas, Juan y Carlos. Tenemos dos opciones:

  • Especialización: Juan se hace experto en A y Carlos en B.
  • Polivalencia: Tanto Juan como Carlos tienen experiencia comparable en A y B.

Imaginemos que esto es un juego de rol, y que damos puntos a las habilidades. En el escenario de la especialización tendríamos por ejemplo:

  • Juan:
    • A: Nivel 4
    • B: Nivel 2
  • Carlos:
    • A: Nivel 1
    • B: Nivel 5

En el escenario de Polivalencia, tendríamos tanto a Juan como a Carlos a nivel 3 en todas las habilidades.

Ahora planteemos que al equipo le llegan tantas tareas de A como de B. Pues este equipo con especialización tiene a una persona de nivel 4 haciendo A y a una persona de nivel 5 haciendo B. Mientras que si hay polivalencia, tendremos a personas de nivel 3. Menor nivel implica: más tiempo y menor calidad.

El párrafo anterior es el origen del mito. Así los miembros del equipo tienen a especializarse, porque lo ven como manera de mejorar su productividad. E incluso los scrum masters tienden a promoverlo. Pero esto es falso, como os presentaré más adelante (otro spoiler…).

Las personas tienen gustos y esto anima a la especialización

Hay personas a las que no les gusta documentar, o hacer test, o hacer análisis. Sólo les gusta programar. Hay otros que sólo les va el diseño y la UX. Otros ven en el análisis una manera de progresar, y sólo quieren hacer análisis. La gente le va cogiendo el gustillo a algo, se sienten más seguros en ese área y tienden a la especialización.

Así cuando se reparten las tareas, ellos solos tienden a  especializarse.

Los trabajos tienen categorías

Según Scrum, esto es un equipo y todos somos iguales. Pero algunos son más iguales que otros. Así, la gente tiene una determinada antigüedad o un reconocimiento técnico por parte del equipo. Esto les hace estar por encima de los demás, psicológicamente hablando. Por otro lado hay habilidades que se consideran de más categoría y otras de menos.

Así, las tareas de documentar, testear o mantener se consideran de bajo nivel. Y hay tareas como UX, análsis o diseño de la arquitectura, que se consideran de alto nivel. Por lo tanto, así como los chicos guapos se juntan con las chicas guapas en el instituto (salvo raras excepciones), en el día a día los miembros de alta categoría se juntarán con las habilidades de alta categoría. Y veo muchas veces como los scrum masters promueven esto en el equipo, con actuaciones como dejar en una tarea a un junior el coger una habilidad de más categoría, “porque ha trabajado y se lo merece, para poder progresar”. Es decir, también tienen en su psique ese concepto introducido. Y esto no lo digo sólo por los equipos que he llevado directamente. Lo digo por mi mismo cuando he llevado algún equipo y por lo que me comentan otros compañeros del sector.

Desde mi punto de vista esto de las categorías es una falacia en sí misma. Yo creo que es más por un tema social. Si pones al crack a hacer testing, lo estás degradando! Desde mi punto de vista, si un programador considera que hacer el testeo es degradarlo es que no tiene cultura de calidad.

La cara oculta de la especialización

De lo anterior podría parecer que la especialización es buena porque:

  • Aumenta la productividad.
  • Aumenta la confianza de los miembros del equipo en lo que hacen.
  • Se ajusta al perfil y experiencia de cada uno.

Pero esconde muchas contras, que están un poco ocultas, pero que desde mi humilde punto de vista tienen más peso.

Pérdida de flexibilidad

El equipo no es flexible. No puede adaptarse a las distintas demandas en un sprint. A lo mejor estamos en una fase que necesitamos a prácticamente todo el equipo en tareas de QA, por el motivo que sea. O a lo mejor, hay dos tecnologías y en un sprint queremos a todo el mundo en la misma. Cuando esto pase (que terminará pasando, tiempo al tiempo), nos veremos con:

  • El equipo rechaza la tarea que se le pide. Pone pegas y dice que no pueden estar todos haciendo lo mismo.
  • Habrá gente anulada en ese sprint porque nunca ha visto esas habilidades.
  • La motivación decaerá en esos sprints.
  • El compromiso de llegar no existirá: “Ya te avisamos de que era mala idea poner esas tareas, normal que no lleguemos”

Dependencia con la persona

Un equipo de 6 personas, ante una baja implica una bajada de rendimiento leve. Pero si especializamos, realmente no tenemos un equipo de 6 personas, sino 6 equipos de una persona (en el peor de los casos). Una baja, implica que desaparece un equipo. Así habrá tareas que no se podrán hacer.

Y tendremos vacaciones, bajas o incluso rescisiones de contratos, porque deciden irse.

Además la dependencia con la persona, le otorga poder y podemos crear héroes o gollums, tan poco deseados.

No hay comunicación técnica en el equipo

Si solo hay un experto en una habilidad, desaparece la comunicación técnica. Si sólo tenemos un maquetador, hará lo que quiera y de la manera que quiera. No contrastará su trabajo con el de otro, no tendrán revisiones entre ellos, no tendrá a quien pedir ayuda. Será él sólo contra el mundo.

Así, este flujo de comunicación tan valioso se pierde, o en el mejor de los casos se degrada, con la especialización.

No hay compromiso de equipo

El equipo pasa a subdividirse en mini-equipos y los mini-equipos son los que asumen la responsabilidad. Así, durante el sprint planning, salen tareas. Todos saben las habilidades necesarias para acometer esas tareas. Por lo tanto saben qué mini-equipo las va a realizar. Los compromisos ya no son del equipo, son del mini-equipo. Al mini-equipo experto en A le dará exactamente igual lo que se haga en el mini-equipo B. Sólo le importará si hay dependencia de tareas.

Esto es fácil de detectar:

  • Cuando en el panel kanban se hace swimlanes por tecnología, producto o habilidad y sabes quién está en cada swimlane: tienes compromisos por swimlane.
  • Cuando en la review al final del sprint, cada mini-equipo hace su presentación por separado, y se evalúa por separado a cada mini-equipo: tienes compromisos por cada mini-equipo.
  • Cuando en el stand-up-meeting ves que cuando una persona habla, sólo los miembros de su mini-equipo se interesan por lo que dice o comentan cosas.
  • O incluso, cuando el scrum master decide hacer varios paneles, y separar los stand-ups por “no hacer perder el tiempo a los otros”.

Perder el compromiso de equipo es malo. Porque se convierte en muy fácil el incumplir. Si un mini-equipo va sobrado en un sprint, cogerá nuevas tareas para su mini-equipo. No tenderá a echar una mano a los otros. Además se pierde el concepto de “compromiso ante el equipo” tan bueno en Scrum. En un equipo de Scrum sano cuando un miembro no llega a lo que se ha propuesto le da vergüenza delante de sus compañeros y aprieta. Siente que tiene un compromiso con el resto del equipo y no quiere quedar mal. Es un nivel más alto que el compromiso con negocio, ese concepto es de los “jefes”. Un compromiso con el resto del equipo es mucho más fuerte. Pero si hay mini-equipos, estos compromisos desaparecen. Los compromisos son dentro de cada mini-equipo. Y si son mini-equipos de una persona, entonces no existe ese compromiso.

Conclusiones

Los miembros de los equipos ágiles tiende a especializarse, y eso no es bueno. Hay que romper esa tendencia.  ¿Pero cómo? Lo dejo para otro artículo.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios