“El software que vale la pena desarrollar es el que producen los equipos…”
La semana pasada estaba escuchando el Podcast de Adam’s Grant “Cómo diseñar equipos que no apesten“. El mensaje principal del podcast es que la composición y la productividad de un equipo se pueden diseñar. Es posible diseñar el contexto en el que opera un grupo de personas para convertirlas en un equipo de alto rendimiento. Este contexto debe centrarse en establecer experiencias y responsabilidades compartidas, en lugar de depender únicamente de ejercicios de formación de equipos.
De hecho, el podcast destaca la ineficacia de actividades destinadas únicamente a construir relaciones interpersonales. A medida que avanzaba el podcast, comencé a vincularlo al Team Software Process (TSP). El TSP es una metodología de desarrollo de software que guía a los equipos de ingeniería en el desarrollo de productos con uso intensivo de software. El TSP siempre me gustó, sin embargo, creo que la historia no le ha dado a PSP y TSP el reconocimiento que merecían.
En esta publicación, intentaré unir estos dos (el podcast y TSP, en particular dentro de TSP, el proceso de lanzamiento de un equipo TSP) como una forma de aplicar los principios del Podcast de Adam’s Grant “Cómo diseñar equipos que no apesten“ en equipos de software.3
Los pilares del éxito: Experiencia compartida, responsabilidad compartida
Dos de los principios fundmentales discutidos en el podcast son la importancia de experiencia compartida y responsabilidad compartida. El sentido común podría sugerir que reunir un grupo de las personas más experimentadas es la clave del éxito, sin embargo – y de acuerdo al podcast – existe evidencia que los equipos con experiencias compartidas a menudo funcionan mejor, incluso si los individuos tienen menos experiencia en general. Esta experiencia compartida fomenta una mejor comunicación, permite a los miembros del equipo aprovechar las fortalezas de los demás y facilita el desarrollo de rutinas efectivas.
Justamente, el objetivo del proceso de lanzamiento de TSP es construir un cohesivo y unidad de trabajo eficaz comprometida con un plan detallado para desarrollar un producto intensivo en software. Para hacer eso, al equipo se le presenta una tarea desafiante y con un límite de tiempo (es decir, el equipo debe diseñar y comprometerse con un plan para la entrega de un incremento de software). Este desafio hace que el grupo de personas encuentre la forma de colaborar (estableciendo proceso, roles, responsabilidades) y compromisos compartidos hacia un objetivo en comun.
Otro punto destacado en el podcast es crear experiencias compartidas mediante el entrenamiento. Un equipo que se entrena en conjunto, que cuenta con un marco y un lenguaje común para la colaboración, puede sobresalir aprovechando las fortalezas de cada uno, compensando las debilidades de cada uno, mediante la creación de rutinas efectivas.
El podcast describe que tales actividades impulsan al equipo hacia una visión y responsabilidad compartidas enfatizando la importancia del vínculo de un equipo en torno a un misión común.
Responsabilidad compartida se logra estableciendo un claro “Quién, Qué, y Cómo’: La base de un equipo exitoso radica en definir un propósito, roles y procesos claros. En otras palabras, la documentación de un proceso definido.
- Quién: Garantizar una rotación estable de personas, permitiendo que estas desarrollen un sentido de pertenencia y propiedad dentro del equipo.
- Qué: Articular un objetivo factible y desafiante, que resuene en los miembros del equipo, creando un sentido de propósito e impulsando los esfuerzos colectivos.
- Cómo: Defina roles específicos para cada miembro del equipo, aprovechando sus habilidades únicas y asegurando una comprensión clara de sus contribuciones al objetivo general.
Esta visión de formación de equipos basada en procesos es inherente a la ingeniería de software moderna y – segun mi interpretación, el valor agregado del proceso de lanzamiento de TSP.
Intervenciones en el equipo
Incluso los equipos bien diseñados requieren de intervenciones para mantener su eficacia. El podcast y el TSP enfatizan la importancia del coaching de equipos, particularmente en los puntos de inflexión críticos. Este coaching debe centrarse en abordar problemas a nivel del sistema, promover la comunicación abierta y refinar/mejorar los procesos del equipo.
Por supuesto, el seguimiento y la retroalimentación periódicos permiten al equipo identificar problemas potenciales con antelación. El TSP utiliza valor ganado, sin embargo, los equipos ágiles modernos probablemente usarían métricas basadas en la velocidad.
Pre y post mortem
Probablemente todos estemos más familiarizados con la procesos de post-mortem. En Scrum, esto se llama Retrospectivas. El TSP incorpora el concepto de post-mortem en sus iteraciones como fuente de aprendizaje.
Curiosamente, el podcast defiende el análisis pre-mortem. Esta es una práctica de “visualizar el futuro”. Un ejercicio de reflexión donde se imagina haber incumplido el objetivo y se exploran las posibles causas raizes.
Me encantó esta sugeriencia. De hecho, nunca he hecho tal actividad con un equipo. Según el podcast, los beneficios del pre-mortem incluyen:
- Prevenir del exceso de confianza y establecer puntos de control en el proceso
- Descubrir nuevas ideas y
- Fomentar la innovación.
Pensamientos finales
Las ideas de la Work-life Balance con Adam Grant El podcast ofrece un argumento convincente: Los equipos de alto rendimiento no son producto del azar sino de un diseño deliberado y un apoyo continuo.. Esto ha sido capturado en ingeniería de software y puede reproducirse.
¿Estás buscando hacer de tu equipo de desarrollo un equipo de alto rendimiento? Contactame! Podemos trabajar juntos para mejorar la productividad de tu equipo.
