El Scrum señala que hay tres roles dentro del Equipo de Scrum: Product Owner, Scrum Master y Equipo de Desarrollo. Exista mucha bibliografía que explica los dos primeros, pero casi nada acerca del último.
¿Qué es el Equipo de Desarrollo?
De acuerdo con la Guía del Scrum, son todas las personas necesarias para hacer que un elemento del backlog del producto se transforme en un incremento del producto potencialmente entregable. De forma claramente asertiva, son ellos las que hacen que sucedan las cosas. Si no contamos con un buen Equipo de Desarrollo que construya el producto, poco importa disponer de los mejores Product Owners y Scrum Masters.
Características del Equipo de Desarrollo
Debe ser:
- multidisciplinar
- autoorganizado
- autogestionado
- autónomo
- comprometido
- focalizado
- incansable en la búsqueda de mejorar su forma de trabajo y sus resultados.
Son características fáciles de teorizar, difíciles de llevar a la práctica. Analicemos cada una de ellas.
Multidisciplinar
El Equipo de Desarrollo tiene todas las habilidades necesarias para ejecutar el flujo de trabajo de principio a fin. Desde la formulación de las hipótesis de solución de un problema comercial hasta la entrega al consumidor final y la recogida de resultados.
Si trabaja en una pequeña o mediana empresa, crear un equipo multidisciplinar es relativamente fácil. Si está en una gran empresa, probablemente se encuentre con un escenario donde ya se han constituido grandes verticales de especialización.
Ejemplo de jerarquía de expertos en grandes empresas
La especialización supone la administración de los especialistas, el fuerte control del coste de la operación y coordinación de los “recursos”. Esto dificulta bastante contar con un equipo realmente multidisciplinar, pues ahora se precisa hacer política.
Cuando el equipo no es multidisciplinar comienza a hacer handoffs (traspasos de testigo) a personas externas. Esto disminuye la eficiencia y crea el espíritu de nosotros frente a ellos: “ya te he pasado la pelota, ahora te toca a ti”.
Me gusta mostrar las pérdidas que sufrimos con los handoffs externos. El primer punto es dejarlo claro en el Panel de Tareas cuando tienen lugar.
Además, el uso de métricas es fundamental para aumentar la transparencia. La más interesante es el Customer Lead Time, que es el tiempo transcurrido desde que el Equipo de Desarrollo se compromete con un elemento del backlog hasta su entrega al consumidor final. Y también el Local Lead Time (Cycle Time), que es el tiempo entre cualquier etapa dentro del flujo.
Así, el equipo tendrá el tiempo durante el cual elemento de valor permanece bajo su responsabilidad y cuánto tiempo el elemento permanece con los equipos externos.
Panel de tareas del equipo. Las columnas en rojo son los handoffs externos. Difícil de controlar, prácticamente imposible predecir cuánto tiempo durarán allí las cosas
Otra métrica importante que no suele aparecer cuando hablamos de Agilidad es el coste del equipo. Es importante conocerlo para justificar la llegada de una persona o la inversión que tendremos a realizar para que algún miembro adquiera la capacidad que aún falta en el equipo.
Estas son tres métricas de eficiencia. Es fundamental contar con la eficacia del equipo, de lo contrario se verá sólo como coste y a las empresas les encanta recortar gastos. La próxima pregunta es ¿cuánto vale ese tiempo? ¿Cuánto gana la empresa con las entregas que hace?
Existen varias métricas de eficacia que se pueden utilizar aquí: facturación, churn, satisfacción del cliente, conservación, adquisición de clientes, recuperación de la inversión, etc. (Vea el artículo Métricas – Cómo medir la agilidad de su equipo).
Una que yo recomiendo y quiero explicar en este blog es el Coste del Retraso (Cost of Delay).
Explicado de forma sucinta: es cuánto dinero dejo de ganar por retrasar la entrega de un producto o por el incremento del producto. Esta métrica tiene en consideración posibles competidores que entran en el mercado y eventos estacionales.
Provisto de tal información, el equipo puede buscar más inversiones. ¡No discuta con gestores y directores sin datos ni hechos!
Imagen del filme Los intocables de Eliot Ness (1987), donde el personaje de Malone (Sean Connery) habla con un asesino: Isn’t that just like a (pejorative slur)? Brings a knife to a gun fight.
Autoorganizado
En la Guía del Scrum se afirma que NADIE fuera del Equipo de Desarrollo debe decirle cómo realizar el desarrollo. Ni el Scrum Master, ni los gestores. El Product Owner dice lo que se hará. El cómo depende del Equipo de Desarrollo.
Sin embargo, es normal ver a equipos que preguntan a personas en posición de liderazgo cómo harían ellos el desarrollo, qué tareas deben realizarse o qué personas deben hacerlo.
El origen de este problema se halla en el modelo de enseñanza que perdura hasta hoy. Desde niños tenemos una figura que determina el rumbo de las personas. La relación profesor-alumno que viene del modo fordista (Ver el vídeo de Sugata Mitra sobre el tema).
De ahí en adelante, aprendemos que existe un ser superior que es el “más inteligente de la sala” (profesores, padres, gestores y líderes) y a quien debemos seguir.
La autoorganización quiebra dicho paradigma. A partir de ahora, el Equipo es la persona más inteligente de la sala. Esta ruptura depende mucho de la madurez tanto de los líderes como de los liderados.
Si usted es un líder, cada vez que entra en acción para adoptar una decisión o responder a una pregunta que el equipo tiene capacidad de responder, debe sonar en su cabeza una sirena. Antes de llevar a cabo ninguna acción, la primera pregunta que debería hacerse es: ¿Qué estoy haciendo mal para que el equipo aún me necesite para tomar esta decisión?
A continuación, las preguntas que generan acción: "¿Cómo hago para que mi equipo no dependa de mí para eso?" "¿Cómo hago para que no me pongan en copia en todos los correos electrónicos (inseguridad)?" "¿Cómo hago para no participar en reuniones que no dependen de mí?"
Si usted fuera parte del Equipo de Desarrollo, las preguntas inversas podrían formularse así: “¿Necesitamos que las personas más caras de la empresa ($$$) estén presentes para tomar esa decisión o para responder a esta consulta?" "¿Merece la pena obstruir la carpeta de e-mails del líder con cualquier asunto?”
Desafortunadamente, hay gestores que todavía creen en el modelo retrógrado de gestión y creen que si no dicen exactamente cómo deben hacerse las cosas, estas irán “a la deriva”. Si usted está en esa situación, siento decírselo, pero cuando hablamos de trabajadores del conocimiento, trabajo creativo y sistemas complejos (algo realmente extenso, quizás tema para otro artículo) el “control” ya está perdido.
Me gusta mucho la frase de Peter Senge en su libro La quinta disciplina (1985): “Usted contrata a las personas por lo que tienen del cuello para arriba y no del cuello para abajo”.
Autogestionado
Hay equipos que piden a las personas en posición de liderazgo permiso antes de hacer algo o la bendición después de hacerlo. En un Equipo de Desarrollo maduro, se espera que no solo sepan organizarse, sino también administrarse.
El Equipo de Desarrollo debe ser capaz de decidir a quién deben contratar o despedir, qué formación seguirán los miembros, si el trabajo es a distancia o in situ, el horario de las reuniones, la participación de eventos, entre otras atribuciones de gestión.
Esto es particularmente difícil para algunas empresas, ya que existen leyes y procesos que a menudo bloquean la autogestión. En estos casos, es importante averiguar hasta dónde puede llegar el equipo. Por ejemplo: puede decidir los horarios de las ceremonias del Scrum, pero el despido y la contratación dependen de la unidad de recursos humanos. ¿Cuál es el nivel de autonomía?
Autónomo
El Equipo de Desarrollo debe tener autonomía para adoptar las decisiones necesarias para realizar su trabajo. Qué herramientas utilizar, autorizaciones, actividades administrativas, conocimientos necesarios, etc.
Una herramienta muy interesante para determinar el nivel de autonomía del equipo y dar transparencia es la Tabla de Delegación (Delegation Board) (Otro artículo que aún tenemos que escribir). En resumen: es una tabla en la que el Equipo de Scrum y los gestores pueden definir cuál es el nivel de autonomía para cada tipo de decisión. Los niveles van de 1 (el gestor decide) hasta 7 (Delegación total). En la versión más reciente, de 1 a 5.
Delegation Poker y Delegation Board del Management 3.0
Comprometido
Comprometido con el incremento del producto, comprometido en resolver el problema del cliente, comprometido con los resultados de la empresa y principalmente comprometido con el Equipo de Scrum. Si no existe compromiso en estos temas, no tenemos un equipo, solo un grupo de personas que, con suerte, podrán entregar algo.
Además, no hay subequipo dentro de un Equipo de Desarrollo. No podemos caer en la discusión del tipo: "Yo ya he hecho mi parte". El éxito depende del trabajo de todos. El fracaso es compartido por todos.
Focalizado
Focalizarse en la entrega. Si el equipo está comprometido, debe tener muy claro el objetivo a alcanzar y qué métricas de eficacia utilizará para saber si lleva el rumbo correcto.
Atención a la transparencia. No podemos tener trabajo invisible ejecutándose durante el desarrollo. Si algunos miembros del equipo están haciendo otras actividades que no están relacionadas con la construcción y entrega del producto, tenemos que dar visibilidad a ese trabajo. Puede ser en el panel de trabajo o en un panel aparte. Mida el impacto causado por este tipo de trabajo antes de intentar eliminarlo (recuerde la sugerencia de Malone mencionada arriba).
Panel del Equipo de Desarrollo de Software. El panel principal (resaltado en verde) es el flujo de trabajo del desarrollo del producto. El más pequeño, al lado (realzado en rojo), da visibilidad al trabajo no relacionado con la entrega de productos
Mejora continua
Dejar de mejorar es dejar de evolucionar. El Equipo de Desarrollo debe ser incansable en el perfeccionamiento de su trabajo. Mejora en todas las direcciones: flujo de trabajo, procesos, herramientas, formas de colaboración, procedimientos administrativos, etc. En el Scrum tenemos un evento específico para eso, la retrospectiva. Es importante resaltar que cualquier momento es un momento de mejora. No es necesario esperar a la retrospectiva.
Es fundamental que tengamos una cultura de experimentación. No intente acertarlo todo al primer intento. Prever todas las posibles consecuencias de un experimento lleva al trágico BDUF.
Ciclo de Experimentación. Sirve para la construcción del producto y para la mejora del equipo
Dimensión del Equipo
El Equipo de Desarrollo debe estar compuesto de un mínimo de tres personas para que sea mínimamente multidisciplinar y no tengamos dependencias externas que nos imposibiliten entregar el incremento del producto. Tampoco debe ser superior a nueve personas, pues el coste de coordinación equipos grandes es muy elevado. La Ley de Brooks sobre interconexiones de canales de comunicación nos explica el porqué.
Ley de Brooks donde I es la cantidad de conexiones, y en el caso de Scrum, n es la cantidad de personas en el Equipo de Scrum y demás partes interesadas
La Ley de Brooks en imágenes. El número de nodos representa la cantidad de personas del equipo y las aristas la cantidad de conexiones (canales de comunicación)
Si usted tiene 11 personas (9 en el Equipo de Desarrollo + Product Owner + Scrum Master), tiene al menos 55 canales de comunicación. Más de esto supone un coste de coordinación y un tiempo para la toma de decisiones muy elevado.
Solo personas
Otra desgracia fue que el mundo de la gestión y gestión de proyectos se acostumbró a llamar a las personas recurso, y recurso nos da la impresión de objetos. Si se rompe, deshágase del mismo y compre otro nuevo. Si está en un Equipo ahora, obsérvelo. Qué haría si sus mejores técnicos se fueran de la empresa hoy mismo. ¿Formaría a alguien nuevo?
Curva de aprendizaje (Learning). Para que un nuevo componente llegue al nivel más básico del Equipo de Desarrollo. Llevará tiempo y experiencia (Experience).
Sillas, mesas, papel, lápices, teléfonos, ordenadores son recursos. Ellos no necesitan aprender y no evolucionan con el tiempo. Si desea mejorarlos tendrá que comprar otros nuevos. Las personas son diferentes. Se perfeccionan con el tiempo. Trabajar a un ritmo sostenible, proporcionar un entorno seguro, respetar la diversidad transformará a su equipo en un Equipo de Alto Rendimiento.
¿Le gustó este artículo? Consulte otros relacionados con el tema:
¿Qué es el Scrum?
Scrum Master: quién es y qué hace
Product Owner: descubrir el papel del PO
Espiral positiva de equipos de alto rendimiento
