El verdadero sentido de los equipos cross-funcionales

Cuando usamos Scrum, la pregunta ¿Qué significa un equipo cross-funcional está siempre presente. La respuesta es muy sencilla: un equipo cross-funcional es aquel que tiene todos los perfiles necesarios para entregar un incremento de Software terminado al final de cada Sprint.

La complejidad de entregar Software

En el artículo sobre DevOps y Scrum, uno de los puntos más importantes a favor de la integración de desarrollo y operaciones es la capacidad de hacer software que esté orientado a la puesta en producción.

Anteriormente, también hemos hablado de como Scrum es una herramienta de gestión de la complejidad. Desarrollar software es complejo. Más que construir un edificio o cualquier otro tipo de ingeniería. Al ser un proceso completamente abstracto, las posibilidades son ilimitadas. Y las limitaciones son desconocidas. Gestionar esa complejidad es una tarea complicada. Merece la pena echar un vistazo a la Matriz de Stacey para entender este punto

El ciclo de vida del software

El ciclo de vida del software normalmente conlleva cuatro o cinco pasos fundamentales: Planificar, diseñar, desarrollar, probar y poner en producción. En Scrum todos estos pasos ocurren cada Sprint y todos los Sprints. Si no somos capaces de ejecutar todos ellos en un sólo Sprint, entonces tenemos que reconocer que existe un problema organizacional. Estos son los impedimentos que un Scrum Master ayuda a una organización a eliminar. No arreglar teclados o gestionar reuniones.

Las organizaciones que usan metodologías ágiles tienen que adaptar su mapa organizacional a un método que les permita ser ágiles. Tener un Sprint de diseño, uno de desarrollo, uno de testing y uno de operaciones no es utilizar Scrum, es hacer waterfall en Sprints. No hay que confundirse. Probablemente tenga un beneficio para la organización y en muchos casos esto acorte en buena medida el ciclo de vida del desarrollo de software, pero sigue sin ser Scrum.

Decidir la duración de un Sprint

Parece aceptado que el tiempo estándar de un Sprint es de dos semanas, sin cuestionamiento. Esta ha sido la recomendación clásica de autores como Mike Cohn o Roman Pichler. Sin embargo, tenemos que ir un paso más allá y ver cuales son los dos factores fundamentales para decidir la duración del Sprint:

1. El tiempo mínimo que necesita el equipo de desarrollo para entregar una pieza de Software terminado. Esto incluye los pasos expuestos más arriba: Planear, diseñar, desarrollar, probar y poner en producción.
2. Un horizonte aceptable de riesgo para el Product Owner. Quizás el Product Owner no considere oportuno entregar Software más allá de dos semanas. O quizás esté bien que se tarden 30 días o menos.

La realidad es que Scrum dice: Software en 30 días o menos. No dice Sprints de dos semanas. El objetivo es tener ciclos cortos de feedback que permitan transparencia, inspección y adaptación.

Los equipos cross-funcionales son la manera de entregar software en 30 días o menos

Ahora es más fácil ver por qué los equipos cross-funcionales significan cosas distintas para empresas distintas. Mientras que para una start-up un equipo cross-funcional puede ser todo desarrolladores junto con una persona de producto, para un banco, los equipos cross-funcionales deben de incluir un business analyst, alguien de compliance, un dba, un tester y alguien de operaciones.

La única manera de preguntarnos si tenemos equipos cross-funcionales es mirar si estamos entregando software terminado cada Sprint. Si no, es un impedimento a eliminar. En muchas ocasiones, eliminar ese impedimento supone desafiar el status quo de la organización para mejorar y optimizar procesos.

Este proceso es agilidad y transformación en estado puro. Scrum es simple pero no es fácil.