Image by Alexandr Ivanov from Pixabay |
Sobre multifuncionalidad y la creación de un incremento de producto
O de las minicascadas en el Sprint y de cómo
deshacernos de ellas
“Todos los patrones de conjuntos fijos son incapaces de adaptabilidad
o flexibilidad. La verdad está fuera de todos los patrones fijos”. -Bruce Lee
De dónde venimos
Todos hablamos de que un equipo Scrum es un equipo multifuncional y autogestionado. En nuestro contexto, multifuncional significa que el equipo en pleno suma todas las habilidades y capacidades necesarias para producir un incremento de producto al final de cada iteración. En la práctica eso es más fácil decirlo que hacerlo posible. ¿Qué sucede cuando conformamos un equipo cuyos miembros, en el mejor de los casos, dominan solo una pequeña parte de ese espectro de multifuncionalidad necesaria para hacer el trabajo?
Estos escenarios son mucho más comunes de lo que creemos.
Solo para mencionar uno de estos: pensemos en una empresa que viene trabajando
con prácticas tradicionales de gestión en las últimas décadas y cuya área de
Tecnología cuenta con proveedores externos: unos para desarrollar el software y
otros para realizar las pruebas de este. Y tanto las personas de un proveedor
como del otro no se hablan sino a través de procesos y herramientas, como un bug
tracker o actas formales de entrega y recepción de partes del producto.
Es muy probable que en esos equipos prime la alta
especialización: el así llamado desarrollador de front-end, el analista
de requisitos, el desarrollador de back-end, el arquitecto del software,
de un lado. El analista de pruebas funcionales, el de pruebas no funcionales,
el automatizador de pruebas, lo que sería un gran avance, del otro lado.
Seguramente cada uno de estos equipos incluya uno o más gestores de esto y de
lo otro. Incluso la empresa para la cual trabajan, el cliente, cuente con sus
propios roles y responsabilidades dentro de todo este intrincado ecosistema de
trabajo.
Imaginemos ese escenario: aquí los unos y los otros son
de organizaciones diferentes. Pensemos en que ahora esa empresa quiere hacer
las cosas usando enfoques ágiles y lean y prácticas como Scrum e historias de
usuario. Además, quiere aprovechar el conocimiento que tienen sus proveedores
actuales y decide invitarlos a embarcarse en un viaje que los llevará por los
caminos ignotos de la agilidad: una nueva forma de pensar y de hacer las cosas,
nuevos comportamientos, conceptos y preceptos muy distintos a los que venían usando,
“metodologías” con poca información sobre el cómo hacer las cosas. Nuevos roles. ¡Y un solo equipo!
Para dónde vamos
Image by Merhan Saeed from Pixabay |
Entonces esto de la autogestión y la multifuncionalidad no ocurre mágicamente por la intervención de un Scrum Master o de un agente de cambio con alguna etiqueta específica. Es fácil decir o proponer que el tamaño de los elementos del product backlog se encuentren en un rango, por ejemplo, entre 1/10 a 1/6 de la velocidad “conocida” del equipo. Pero una cosa es contar con un equipo cuyos jugadores dominen más de una especialidad, sino todas, a hacerlo en un equipo donde eso no ocurre ni ocurrirá durante algún tiempo. Adquirir habilidades T toma tiempo, aunque los beneficios son evidentes una vez que se consigue. Pues bien, una primera recomendación es reducir aún más el tamaño de las historias de usuario.
Es algo para tener en cuenta cuando se hace refinamiento
o, simplemente, cuando se dividen elementos del product backlog en piezas
más pequeñas. Eso es necesario porque el trabajo en el sprint será una
minicascada: si se trata de desarrollo de software, por ejemplo, primero se
realizará el trabajo de diseño y programación y luego se hará el trabajo de pruebas
o de aseguramiento de la calidad. Incluso es posible que, en cada una de esas
breves fases, haya etapas más pequeñas que se lleven a cabo de manera
secuencial.
Las cosas así, no será posible cumplir la promesa de
tener elementos del product backlog (alias las historias de usuario)
terminados durante los primeros días del sprint. Esto, como sabemos, sube la
presión y el estrés sobre el equipo y sobre los interesados y usuarios, representados
por el Product Owner. Es un hecho: llegar a la mitad del sprint o más
allá, independientemente de su duración, sin que ninguna historia de usuario alcance
la Definición de Terminado, aumenta la ansiedad e inicia un ciclo nocivo de
sucesos que derivan en resultados pobres, pero, sobre todo, en desmotivación y en
una baja de energía en el equipo.
Estas son algunas recomendaciones de experimentos que he encontrado útiles para despejar esas nubes cenizas que arremeten contra el trabajo colaborativo:
· Menos historias de usuario.
· Sprints de dos o de tres semanas. Siempre podemos disminuir la duración más adelante.
·
Un refinamiento que “mire” dos o, mejor, tres
Sprints hacia adelante.
·
Manejo de expectativas con los usuarios e
interesados, vía la Product Owner o el Scrum Master o alguna otra
persona del equipo o muy cercana a este.
·
Ordenamiento por valor del product backlog,
más que hacer priorización. Es decir, ordenar uno a uno, por valor e
impacto para el negocio, para los usuarios o clientes, cada historia de
usuario. Muchas veces la priorización se hace por grupos de elementos. El
ordenamiento se hace de manera individual. Esto asegura que en cada sprint se
entregue Valor, aunque este sea en pocas cantidades.
· Foco en una historia a la vez y concentrarse en su finalización.
· Promover la colaboración, el trabajo en equipo, la inteligencia colectiva.
Pero lo más importante y crítico es poner en
marcha un plan de desarrollo de competencias que faculte a las personas para adquirir
habilidades T en principio y, más adelante, habilidades Pi. Esto toma tiempo,
requiere de una inversión considerable, pero es lo que va a permitir hacer las
cosas de una manera diferente de una vez por todas y para siempre. Un plan que
incluya:
·
Adquisición de nuevas prácticas y, si es
necesario, de nuevas herramientas.
·
Trabajo en pares.
· Usar el patrón Swarming o Enjambre. Esto es, todo el equipo, o casi todo, trabajando en una única historia de usuario a la vez. Más sobre este patrón en: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/.
·
Pasantías.
·
Acompañamiento y mentoría.
·
Autoestudio.
·
Potenciación de habilidades.
·
Práctica. Kata. Kata. Kata.
Los beneficios de desarrollar este plan no girarán solo
en torno al aumento de la productividad del equipo, sino también a la entrega
de mayor valor en cada iteración, al incremento de la calidad, a la mayor
satisfacción y felicidad de usuarios o consumidores finales, y también contribuirán
a energizar al equipo, a su bienestar, a menos estrés y a más motivación.
¿Qué te parecen estas ideas? Por favor, cuéntamelo en el
foro.
---
*Crédito de la imagen de la sección "De dónde venimos": silhouettes by Gerd Altmann from Pixabay
Suena simple, pero no es fácil, pero trae grandes rendimientos. Hay que insistir en esto una y otra vez. Lo esencial no se puede omitir. Excelente artículo de referencia y reflexión
ResponderBorrarNo recuerdo haberla leído, otra recomendación es liberar producto en producción, en modelos beta tester. El liberar producto de forma temprana en ambientes controlados, con modelos de clientes/usuarios de confianza/colaboración "friends and family -amigos y/o familia" conocidos, ayuda a los equipos a madurar es su proceso de ir a la entrega continua y la retroalimentación real y directa de usuarios reales.
ResponderBorrarEn cuanto a los modelos de habilidades trabajar en una ruta para evolucionar a T, Pi y lo que yo llevo ya algunos años a incorporar modelos comb (peine). Ver https://www.linkedin.com/feed/update/urn:li:article:8720530307082628297?commentUrn=urn%3Ali%3Acomment%3A%28article%3A8720530307082628297%2C6354432419210227713%29