A veces creo que estamos errados.
Estoy totalmente convencido que el secreto para construir organizaciones ágiles está en construir las organizaciones alrededor de los equipos. Cómo organizamos los equipos, quiénes trabajan ahí, cómo trabajan con otros equipos... todo esto determina qué tanto valor vamos a generar para el negocio, y en última instancia para nuestro cliente.
Hay cosas importantes sobre los equipos... y otras no tanto. Si logramos comprender lo que realmente queremos lograr con nuestros equipos vamos a poder superar algunos dogmas, batallas de metodologías, y Scrumentalistas que nos obstaculizan adoptar prácticas ágiles de manera incremental. ¿Nuestro objetivo es adoptar Scrum, o nuestro objetivo es lograr mayor agilidad en el negocio?
Lo importante sobre los equipos
Los equipos entregan valor
A veces esto significa que los equipo trabajan en distintas disciplinas sobre el software. A veces significa que entregan servicios para ser consumidos por otras áreas de la misma organización. Los equipos puede ser parte del negocio y encargarse de la facturación... o del marketing... o de las ventas. Sólo me interesan los equipos multi-funcionales en el sentido de que el equipo necesita tener todo lo necesario para entregar el valor para el cual fue creado.
Los equipos son responsables
Los equipos hacen y cumplen compromisos y son responsables de cumplir estos compromisos. Son responsables por el resultado. No me importa mucho cómo cumplen estos compromisos... siempre que operen dentro de límites morales y éticos. Me importa que los equipos hagan lo que dicen que van a hacer, y entreguen en valor que le prometieron al negocio.
Los equipos son predecibles
En el tiempo, los negocios deberían poder dar entradas específicas, y obtener predecir razonablemente los resultados. La tasa de salida debería ir en aumento... y deberíamos saber porqué aumenta. Si la tasa de salida disminuye, deberíamos poder comprender porqué ocurre. Si la tasa de salida es variable, debería tener al menos un promedio predecible. No podemos planificar nada sin equipos predecibles.
Los equipos mejoran
Necesitamos tener algún mecanismo para mejorar a lo largo del tiempo. Puede ser una retrospectiva al finalizar un sprint, un tablero de Kanban. Podemos confiar en que el conocimiento y la creatividad del equipo aumenten... o podemos usar herramientas específicas para ayudar a hacer visibles los problemas, y ayudar a corregirlos. No puede estar bien aceptar la mediocridad.
Los equipos son transparentes
El negocio necesita poder comprender exactamente lo que un equipo está haciendo, y cómo se relaciona su entregable con los objetivos del negocio. El negocio necesita comprender qué problemas tiene el equipo, para poder ayudar a resolverlos. Las métricas de rendimiento del equipo tienen que ser visibles y explicables.
Y otras cosas no tan importantes sobre los equipos...
Los equipos tienen un Dueño del Producto
Me voy a metern en problemas acá... pero no creo que un Dueño del Producto sea tan importante. Lo importante es tener un buen Backlog del Producto. Lo importante es tener a alguien que responda las preguntas del equipo en nombre del negocio o de los clientes. Lo importante es que el negocio sea responsable por tomar decisiones en tiempo y forma, y de guiar al equipo.
Si todo esto lo puede hacer una única persona llamada Dueño del Producto, perfecto. Pero lo importante es que todo esto ocurra.
Los equipos tienen un Scrum Master
Otra vez, me meto en problemas. Lo que realmente necesitamos es alguien que ayude al equipo a mantener el rumbo, a mantener la visión, que ayude a quitar impedimentos, y que colabore con el equipo para ayudar a mejorarlo. Si es el ScrumMaster, genial. También puede ser un líder de proyecto, un gerente de producto. Puede ser un buen líder técnico o un arquitecto.
Los equipos realizan reuniones diarias de parado
Lo que necesitamos es comunicación entre los miembros del equipo. Trabajé con equipos que estaban sentados juntos, en el mismo lugar. Trabajaban juntos todo el día, y siempre sabían lo que estaba ocurriendo. Si la reunión diaria agrega valor, háganla. Tan sólo recuerden porqué la hacen, y si están obteniendo lo que necesitan. La comunicación, la transparencia, la responsabilidad compartida: estas son las cosas importantes.
Los equipos tienen rituales de planificación
Los equipos necesitan planificar. Necesitan tiempo para pensar el problema y coordinar su trabajo. Necesitan tiempo para inspeccionar y adaptarse. Esto puede ocurrir con una Reunión de Planificación del Sprint y una Demo del Sprint. Puede también hacerse ad-hoc a medida que se mueven los requerimientos individuales del backlog del producto a la cola de "en proceso".
¿Nos importa el "qué" o el "cómo"?
Cuando las personas comienzan con Ágil, es facil que queden atrapadas en el cómo. Cómo van a planificar, cómo van a hacer reuniones, cómo van a hacer las demos al cliente, cómo van a asegurar su responsabilidad. Necesitamos enfocarnos en lo que el equipo va a entregar, y en los atributos de este entregable que son importantes para el negocio.
Es extremadamente importante que los equipos entreguen algo de valor en ciclos cortos, que sean responsables, que sean predecibles, que mejoren con el tiempo, y que sean transparentes para el negocio. Mientras los Dueños de Producto, ScrumMaster, las reuniones diarias y de planificación nos ayuden a lograr esto, resultan herramientas útiles.
Pero son herramientas, y podrían no encajar bien en una organización que está comenzando a adoptar ágil. Debemos pensar lo que realmente queremos lograr, y generar estrategias para situaciones específicas para construir equipos... y hacer que estos equipos sean predecibles.
Podría sonar poco razonable pedirle al negocio que tome a su Gerente de Producto y lo transforme en un Dueño del Producto, así de golpe. Pero suena completamente razonable pedirle que se asegure que los equipos tengan los requerimientos para construir software... requerimientos que se acomodan al cambio, que ayudan a mitigar el riesgo, y que entregan valor más rápido y mejor para el negocio.
Entonces, mi pregunta: ¿estamos más preocupados en adoptar prácticas ágiles específicas, o en hacer todo lo necesario para crear equipos que funcionen bien?