Estructura de un equipo Scrum — Scrum desde el Sprint 1 (parte 5)
Quinta parte de una serie de entregas destinadas a profundizar en la implementación del marco de trabajo Scrum. Si no haz visto las entregas anteriores, puedes pinchar en parte 1, parte 2, parte 3, parte 4
La estructura organizacional de la entidad financiera donde Hector trabaja no tiene mayor diferencia en su modelo al de otros que podríamos encontrar en muchas empresas. Existen distintas gerencias, cada una con su correspondiente especialidad, presupuesto y objetivos. Esto hace que funcionen en forma paralela y con cierta autonomía. Por tanto, cada gerencia es una fábrica (o micro empresa) de servicios particular y especializada que responde a las peticiones que otras áreas gerenciales realizan de acuerdo a sus propias necesidades.
Desde un punto de vista sistémico, la fuga de información relevante es alta debido a que el conocimiento “especializado” se concentra de distintas áreas, provocando que la empresa no pueda verse a si misma como un todo e intente resolver sus problemas preocupándose a nivel local de solucionarlos sin analizar las relaciones de sus piezas para intentar comprender causa y efecto. Perjudica el nivel de colaboración puesto que cada gerencia es medida y a veces premiada con diversos incentivos acorde a los objetivos definidos, lo que da pie a evitar compromisos hacia otros que puedan desviarles de sus correspondientes metas. Duplica el trabajo considerablemente debido al manejo interno de la toma de decisiones, por tanto es común que cada gerencia tenga su propia forma de abordar una misma iniciativa sin saber que su par también lo está haciendo en simultáneo o, ya los otros han logrado resolverlo y podrían compartir el conocimiento pero no se hace, por desconocer esta información dada la carencia de interacciones y la transparencia en la ejecución de sus trabajos pendientes.
Desde la perspectiva de la figura 2, podemos abstraernos hacia una relación de cliente-proveedor para comprender la “cadena” de valor involucrada en un flujo de punta a punta: esto es desde que alguien de la gerencia comercial levanta una necesidad, hasta que otra u otras áreas satisfacen esa necesidad.
El concepto de la fábrica que sirve a todos (por ejemplo, una gerencia TI le sirve tecnológicamente a “toda” la empresa) obedece a disminuir el costo operativo al centrarse en la eficiencia de sus recursos. TI recibe peticiones de toda la organización así es que, está totalmente ocupada atendiendo necesidades y sus clientes internos tienen que situarse en la cola esperando a ser atendidos, esto asegura que siempre tengan trabajo por hacer. Veamos nuevamente la figura 2 y analicemos lo siguiente: Claudio es jefe de productos intangibles y pertenece a la gerencia comercial. Claudio levanta una necesidad el 3 de abril hacia la gerencia de administración que dispone de una oficina de gestión de proyectos o gestión de la demanda (PMO) encargada de tomar los distintos requerimientos. Tres días después, recibe una respuesta donde se le notifica que tiene reservada una reunión dentro de una semana más. Llegado el día, se reúne con Cristobal, administrador de proyectos a quien se le ha asignado trabajar en la petición de Claudio. Durante un mes, Cristobal confecciona un documento de especificación de requerimientos que valida iterativamente con Claudio hasta que ambos coinciden en que lo escrito en papel, es “todo” lo que la gerencia comercial necesita para alcanzar sus objetivos. Ahora para Cristobal es posible proyectar estos requerimientos y llevarlos a horas hombre ideales suponiendo en una herramienta virtual, la cantidad de personas necesarias para realizar el trabajo. Un par de semanas más han corrido y es tiempo de contactarse con la gerencia tecnología y explicar el plan (además de solicitar los “recursos”) para llevarlo a cabo en su fase de ejecución. Pero hay un problema. Luego de seis días más, TI descubre que no cuenta con dos de los perfiles específicos para desarrollar el proyecto así es que tendrán que ponerse manos a la obra en encontrar a los profesionales adecuados en el mercado y luego contratarlos. Para eso, deben seguir los protocolos de transparencia en la compañía y levantar una licitación (tienen dotación interna completa así que deben externalizar el servicio) pasando veinte días más hasta que llegan los nuevos participantes. En paralelo, la sub gerencia de infraestructura ha dado el visto bueno para contar con el ambiente necesario y acorde a su guía. Ha llegado el momento en que el jefe del proyecto por fin se reúne con las personas que van a desarrollar el producto y entonces analizan el documento de especificación de requerimientos. Resulta que gran parte de los requisitos escritos no se entienden totalmente y los desarrolladores murmuran que los clientes nunca saben nada. Ochenta días después y con muchas observaciones en el documento, Cristobal vuelve con Claudio sin haber escrito una sola línea de código fuente. En la gerencia comercial la gente comenta que el área TI nunca sabe nada y todo lo hace a medias. La sub gerencia de control de calidad y la gerencia de operaciones, quedan para el final, cuando ya este “todo” listo y sea la hora de la verdad. Conocemos este momento en la industria del software como el big bang. Sin embargo hay algo muy interesante de observar aquí: todos los involucrados en esta historia, pasan el día completo ocupados llenos de trabajo por hacer.
Levantando un equipo Scrum
Para levantar un equipo Scrum, Hector ha recibido el apoyo de las distintas gerencias. Tomando el mismo esquema de la figura 1 y llevándolo hacia la figura 4: reunieron a un grupo de personas seleccionándolas desde todas las áreas necesarias para llevar a cabo el desarrollo del producto.
Dentro de las especificaciones que Hector indicó previo inicio de la transformación en la empresa, solicitó un espacio de trabajo abierto para que este nuevo equipo pueda crear el producto colaborando y eliminando los silos de información y reduciendo la complejidad en las interacciones de sus integrantes trabajando todos juntos en el mismo lugar y de manera cotidiana. Así, el nuevo equipo tendrá una mesa común en donde instalarán sus laptops. Dispondrán de amplias pizarras blancas para dibujar sus ideas, discutir los distintos diseños y respirar la visión del producto. Para Hector es importante basarse en Extreme Programming como pieza base que ha de “enchufar” al marco de trabajo Scrum para construir software.
Un equipo Scrum cuenta con tres roles: un Scrum Master, un Product Owner (Representante del producto) y un Equipo de Desarrollo (development team). En la figura 6 podemos observar la forma en que el equipo de desarrollo fue pensado. Al decir que estos equipos son “multifuncionales” es que tienen tanto el conocimiento o representación del negocio, del proceso y la implementación técnica en la mayor cantidad posible de capas o fases a fin de disminuir las dependencias externas que puedan interrumpir el desarrollo. Es importante destacar que un equipo de estas características no desarrolla por capas, sino en pequeños cortes verticales (incrementos de producto) que aseguran la construcción de punta a punta garantizando un trozo de software funcional y no un prototipo.
La guía oficial de Scrum menciona que el tamaño de un equipo de desarrolladores recomendado debería fluctuar entre un mínimo de tres integrantes y un máximo de nueve. Existe una fórmula de canales de comunicación que Jeff Sutherland comenta en su libro “El arte de hacer el doble en la mitad del tiempo” que es la siguiente:
Canales de comunicación = n(n-1)/2
Agilizar la toma de decisiones tiene estricta relación con cantidad de personas implicadas en el desarrollo del producto. Por tanto, deben ser suficientes como para eliminar el concepto de cadena o fase que nos quita visibilidad y disminuye el alcance hacia el cliente (final) y no deberían ser tantos como para convertirlos en un tanque con pedales.
En la siguiente entrega, veremos cómo el equipo Scrum trabaja en su visión del producto. Hasta la próxima!
