Cuando se trata de trabajar en un equipo Scrum es habitual que nos surja la duda de como organizar el trabajo dentro de un Sprint. Al fin y al cabo no todos los Developers tienen las mismas skills y conocimientos.
Anteriormente ya he hablado de distintas categorías de equipos: equipos autoorganizados, cross-funcionales, de componente o feature teams. También dediqué un artículo a profundizar sobre estrategias para formar equipos ágiles.
Merece la pena echar un vistazo a estos artículos para tener contexto sobre el que estás leyendo ahora mismo.
Para responder a la pregunta de este artículo es necesario entender los tres problemas que suponen la organización del trabajo en los equipos Scrum: la organización por capas, la ausencia de skills transversales y los títulos.
Organización por capas
Consideremos un equipo que tiene que lidiar con distintos aspectos del desarrollo de una aplicación. Tenemos Developers que conocen el back-end, los que conocen el front-end y aquellos encargados de gestionar la api y el middleware.
La manera tradicional de organizar el trabajo es en torno a las capas. Para cada feature que queramos desarrollar, dividiremos el trabajo en front-end, api y back-end. Esta manera intuitiva de división del trabajo, popularizada por la revolución industrial posee un problema de base: Completar cada una de las tareas no significa necesariamente que la feature está completa.
Es habitual que nadie sea responsable del proceso de integrar todo ese trabajo. Al estar la responsabilidad dividida en cada capa se nos escapan pequeños problemas de acoplamiento de las mismas que generan dependencias y necesidades de adaptación en las otras. Esto genera retrasos.
Cuantas más personas trabajen en el producto más retrasos se generaran, dando lugar a un ciclo vicioso en el que cada vez estamos más ocupados y eventualmente, nada sale adelante.
Tal y como explica Javier López, una autopista llena de coches es un garaje. Por un lado, una carretera con una utilización del 100% está totalmente aprovechada. Por otro, ningún coche llegará a su destino. Eduardo Ferro lo ilustra perfectamente en Twitter.
Es evidente que la organización dentro del equipo Scrum por sub-roles presenta este problema. Veamos ahora un segundo problema.
Presencia o ausencia de Skills en T
Para luchar contra este problema lo primero que hay que hacer es eliminar la división del trabajo. Pensar que no trabajamos en una fábrica de zapatos sino que nuestro trabajo, cuando se trata de lidiar con problemas complejos, se asemeja al de un zapatero artesano.
De esta manera tratamos los problemas como un todo, adaptando los niveles de colaboración de los Developers en función de cada tarea y no dividiendo las tareas en trabajo para cada una de las especialidades.
Eso nos lleva a un segundo problema: la ausencia de skills transversales. Es normal que un especialista en back-end piense que es mucho más eficiente trabajando solo en tareas de back-end. Y tiene toda la razón.
La paradoja es que al ser especialista en ese área solo trabajará en tareas especialistas de ese área. Cada vez será más especialista, llevándonos de nuevo hacia el primera problema.
La solución a este problema es limitar la utilización y asumir que una parte del tiempo de este especialista estará dedicada a colaborar y trabajar con otros miembros del equipo en resolver los problemas que el equipo aborda.
Esto es difícil de realizar por persona pero es tremendamente sencillo de hacer por equipo. Limitando el WIP -el número de elementos en los que el equipo Scrum trabaja a la vez-, crearemos un espacio de colaboración para los miembros del equipo.
Si tenemos un equipo formado por siete personas y solo podemos trabajar en dos elementos al mismo tiempo es evidente que tienen que darse dinámicas de colaboración entre los miembros del equipo para no quedarse sin nada que hacer.
Estas dinámicas evolucionarán con el tiempo ensanchando las habilidades de cada uno de los miembros del equipo, dándoles herramientas para abordar problemas fuera de su área de especialización.
Programar o Testear son skills, no son títulos
Uno de los problemas heredados de tratar de comprender que hacen los especialistas es asignarles el título correspondiente a su skill principal. Así, un especialista en Java terminará siendo Senior Java back-end especialista certified in whatever, dando la sensación de que su trabajo se confina a ese área concreta.
Sin embargo, en los equipos Scrum es normal que distintas personas tengan que realizar una variedad de trabajos. Este es un principio de la agilidad. Para poder adaptarnos rápidamente necesitamos tener liquidez de talento que sea capaz de abordar distintos problemas rápidamente.
Para resolver esto no necesitamos cambiar la industria. Ni siquiera el departamento de Recursos Humanos. Lo único que necesitamos es cultivar la noción de que dentro del equipo Scrum nuestro trabajo es resolver los problemas que nos surjan.
Podemos mantener el título de LinkedIn y no es necesario cambiar de categoría laboral. Solo tenemos que dejar de estar enamorados del código que creamos y empezar a enamorarnos del valor que nuestro trabajo crea.
Deja una respuesta