A medida que las empresas pasan con las soluciones de software de las instalaciones a la nube, a menudo se fijan el objetivo de ser más «ágiles». A menudo, esto debería aplicarse idealmente a todo a nivel interempresarial. Y, por supuesto, en todas partes al mismo tiempo.
La transformación de los procesos podría ser fácilmente posible, al menos en teoría. Puede definir ceremonias de scrum y reasignar personas a nuevas funciones (como maestros de scrum, propietarios de productos, gestores de entregas y equipos de scrum).
Puede incorporar herramientas como Jira, Azure ADO y Miro boards y hacer que su uso sea obligatorio. Pero, ¿qué pasa con los procesos que conectan las herramientas entre sí? ¿Qué pasa con la transformación de las mentes, los comportamientos y las formas de trabajar de las personas? Queda claro que esos no se transformarán sin problemas, ni terminarán rápidamente. Observemos ahora por qué.
¿Qué es una iniciativa de transformación de la entrega y por qué lo hacen las empresas?
Una gran parte de las empresas actuales siguen trabajando según el modelo de entrega en cascada. Esto significa que:
- En primer lugar, planifique lo que desea como resultado/producto final y cuánto puede costar aproximadamente.
- Inicie el proceso de recopilación de requisitos, en el que se discuten a fondo todos los detalles del producto final, se ponen objeciones, se cuestionan, se acuerdan, se vuelven a discutir y, por último, se confirman.
- Estime el conjunto y confirme las expectativas presupuestarias.
- Diseñe la solución. Celebre varias reuniones con las partes interesadas. Cree varios documentos y deje que las partes interesadas los revisen. Confirme y apruebe el diseño funcional y técnico final.
- Implemente la solución basándose en el diseño. Aquí es donde se desarrolla el producto final completo.
- Entre en la fase de pruebas y ejecute varios tipos de pruebas: pruebas unitarias, pruebas del sistema, pruebas funcionales, pruebas de integración, pruebas de rendimiento, pruebas de regresión, pruebas de aceptación del usuario y potencialmente muchas más (dependiendo de la cultura de la empresa). Documéntelo todo y deje que las partes interesadas lo revisen y aprueben.
- Despliegue la solución en el entorno de producción. Aquí es donde los usuarios objetivo empiezan a utilizar el producto final y completo.
- Programe alguna fase de soporte durante la cual el equipo de desarrollo corrija los posibles errores de la solución.
Todo este proceso puede llevar de unos meses a unos años y, como puede ver, los usuarios no verán los resultados hasta el final del mismo. Así pues, tras una larga espera llega el momento de la verdad (o del fracaso).
Si algo cambia durante ese largo tiempo y el producto final debe tener un aspecto algo diferente, se trata de una situación denominada solicitud de cambio. El diseño debe reabrirse, reelaborarse y volver a aprobarse. Esto prolonga todo el calendario en otra parte.
Evidentemente, esto no es ágil ni mucho menos. Cada cambio requiere reiniciar todo el proceso anterior.
Pasar a la agilidad
Entonces, ¿cómo salimos de esta situación y la cambiamos para que sea ágil? La gente trabaja en la configuración de cascada durante muchos años o incluso siglos. Tienen funciones y responsabilidades con las que se sienten cómodos y no quieren cambiar el statu quo. La razón principal es que hacer este cambio significa, en última instancia, perder parte del poder que tenían hasta ahora.
Esta es la razón principal por la que un cambio de este tipo extrae el nivel más fuerte de resistencia de la gente que se pueda crear.
#1. Reestructuración del equipo
Lo primero y relativamente más sencillo de hacer es reestructurar a la gente en equipos scrum. Divídalos basándose en las áreas funcionales o en cualquier otra división lógica que tenga sentido.
La división suele realizarse sin problemas; el problema comienza cuando se da cuenta de que las personas siguen vinculadas a las estructuras originales. Aunque ya formen parte de los nuevos equipos scrum, en la práctica, no lo están. Siguen trabajando en esa antigua configuración porque todavía tienen responsabilidades que no se terminaron junto con el proceso de reestructuración del equipo (porque por qué iba a ser – a la dirección no le importa mucho lo que hay que terminar, sino sobre todo lo que hay que empezar).
Así que, prácticamente, se acaba teniendo un equipo scrum que no es un equipo scrum totalmente dedicado. Es un grupo de personas que ahora simplemente tiene más trabajo que hacer. No hay tanto tiempo para el trabajo dentro del equipo scrum como espera la dirección.
Al mismo tiempo, la expectativa es que las personas terminen sus actividades originales así como esta nueva expectativa dentro de los equipos scrum. Es un montaje decidido al fracaso desde el principio.
#2. Programar ceremonias Scrum
Ordenar a los equipos que programen varias convocatorias periódicas (ceremonias del sprint) es fácil de definir y de poner en marcha. Al menos, suponiendo que sus equipos scrum no estén formados por personas de 3 zonas horarias (lo que suele ser el caso).
El problema empieza cuando la gente no se une a las ceremonias de forma regular. Dependiendo de quién falte y con qué frecuencia, esto puede derivar en diversos tipos de problemas. Por ejemplo:
- Si los propietarios de los productos no asisten a las ceremonias de planificación y perfeccionamiento, el equipo no tiene nuevas historias en las que trabajar. O la descripción de las historias es tan pobre que el resto del equipo no puede empezar a trabajar en ellas.
- Si los scrum masters no acuden a las convocatorias, el equipo carece de la orquestación básica de scrum y, con el tiempo, podría perderse.
- Si los miembros del equipo de desarrollo faltan a menudo, no pueden sincronizarse entre sí, y la comunicación dentro del equipo es mucho más difícil. Además, se necesitan más reuniones para ponerse al día, lo que resta aún más tiempo al equipo.
En última instancia, no es necesariamente culpa de las personas que faltan a las ceremonias. Es sólo que la configuración no les permite estar en las convocatorias (véase más arriba sobre las asignaciones previas paralelas).
#3. Estabilidad del equipo
Puede tener un equipo scrum con estructura y ceremonias, pero si ese equipo no es estable durante un periodo de tiempo más largo -digamos que al menos medio año idealmente, un año de estabilidad sería mi requisito mínimo personal-, entonces ese equipo no puede evolucionar y mejorar realmente.
Además, probablemente nunca llegará a tener un equipo scrum totalmente independiente que gestione los sprints como si fuera su trabajo habitual. Por último, tendrá que educar y aprender constantemente a las personas del equipo para que comprendan la mentalidad y los procesos de scrum. Es un problema agotador.
Se trata de un problema muy subestimado, en concreto por la dirección o la gerencia de la empresa. Llamar a los equipos de personas sólo «recursos» y planificar su «utilización» de trimestre en trimestre es un camino instantáneo al infierno.
#4. Nuevas funciones para las mismas personas
Otro obstáculo a superar es la reasignación de las personas existentes a nuevas funciones diferentes. Los que antes dirigían equipos con el máximo poder pueden convertirse ahora en Propietarios de Producto, por ejemplo. Esta es una posición fuerte en un equipo scrum, pero puede verse como un papel más débil en relación con la configuración existente.
De repente, los propietarios del producto deben sincronizarse con el scrum master o los directores de programa. Siguen siendo responsables del contenido, pero no tanto de los procesos de entrega. Esta situación exige renunciar a algunas responsabilidades que tenían anteriormente y, por lo tanto, es difícil de digerir.
#5. Formas de trabajar
Esta es interesante, y la oigo de vez en cuando con bastante frecuencia: tenemos que aprender nuevas formas de trabajar para ser relevantes en un mercado en evolución en el que la agilidad es la expectativa básica. Pero, ¿qué significa exactamente esas formas de trabajar?
Si me pregunta, está claro lo que la dirección quiere decir con ello: conseguir (mucho) más en menos tiempo. Tras la creación de los equipos scrum, la expectativa es que cada miembro del equipo consiga de repente algunos resultados incrementales documentados de un día para otro. Si no es así, la dirección empezará a preguntarse por qué el proceso ágil no funciona bien.
De la nada, la dirección espera que cada hora cuente y que los equipos de scrum no tengan básicamente ningún tiempo muerto, simplemente porque podría decirse que no hay espacio para ello con todos los procesos de scrum en marcha. Y esa es la definición de «nuevas formas de trabajar» desde la perspectiva de la dirección en pocas palabras.
Por supuesto, esta expectativa no se basa en la comprobación de la realidad. Es ilusorio esperar que la gente de la empresa empiece a trabajar más en el mismo periodo, sólo porque algunos procesos cotidianos vayan a cambiar. Algunos podrían hacerlo, aunque sólo sea una minoría. Sin embargo, incluso a este grupo se le reduce aún más atiborrándoles de más tareas al mismo tiempo.
Diferencia entre el objetivo y la realidad
No cabe duda de que la descripción del objetivo final suele ser buena y tiene mucho sentido. Se basa en los siguientes principios:
- Equipos scrum estabilizados que trabajen en backlogs independientes con KPI y OKR claros.
- Propietarios de productos que elaboren hojas de ruta sólidas y planifiquen contenidos priorizados para entregar con plazos concretos.
- Contenido de backlog definido con características relevantes ya detalladas antes de comenzar el trabajo.
- Procesos de prueba fiables ejecutados junto con el trabajo regular de desarrollo del sprint.
- Lanzamientos regulares a producción: al menos una vez al mes, pero idealmente tras la finalización de cada sprint.
- Seguimiento de riesgos y problemas y comunicación entre los distintos equipos scrum en caso de dependencias.
Luego, cuando se trata de la realidad, puedo decir que ninguno de los puntos anteriores es fácil de conseguir.
- Usted forma los equipos scrum, pero éstos cambian constantemente (de trimestre en trimestre). Inviertes tiempo en enseñar al equipo los procesos de scrum, y una vez que por fin empiezan a aceptarlo y a cambiar su forma de trabajar, reorganizas los equipos para el siguiente periodo. Las hojas de ruta se modifican, se cambian o se cancelan.
- Los propietarios del producto no tienen ni idea de los detalles de la hoja de ruta y (sólo porque antes tenían esos hábitos) asignarán directamente al equipo las tareas de elaboración del contenido del backlog. Como resultado, el equipo no tiene tiempo para desarrollar el contenido, ya que primero tiene que averiguar qué desarrollar.
- Los procesos de prueba son sólo manuales y requieren un montón de subpasos y aprobaciones y procesos complicados de seguir. Eso significa que no hay forma de que las pruebas puedan terminar en el mismo sprint que el desarrollo.
- Como consecuencia, la puesta en producción se retrasa varios sprints.
- La comunicación entre los diferentes equipos scrum es caótica e ineficaz, ya que cada equipo tiene cada sprint un montón de actividades que realizar. De hecho, los propietarios del producto tienden a asignar al equipo demasiado contenido cada sprint. No hay ninguna posibilidad de que el equipo pueda completarlo todo, por lo que están constantemente bajo estrés de plazos.
Corregir los errores
Con la experiencia de unos cuantos proyectos de transformación ágil, me gustaría resumir algunos de los mayores errores que he experimentado y dar algunas opiniones subjetivas sobre la posibilidad de superarlos.
#1. Responsabilidades correctas para funciones correctas
Si intenta torcer la definición y distribuir las responsabilidades de otra forma a como deben ser según scrum/agile, estará abocando toda la iniciativa al fracaso.
- Los propietarios del producto deben ser los dueños del contenido y mantener el backlog. Son responsables de las historias del backlog, y si éstas no están bien definidas, les corresponde a ellos tomar medidas y arreglarlo. Por otro lado, no deben tener ninguna influencia en las asignaciones de las personas del equipo scrum ni en las decisiones sobre el presupuesto del proyecto.
- Los scrum masters no tendrán ninguna responsabilidad sobre el contenido del backlog. Están en el equipo para orquestar las ceremonias y educar al equipo en una forma de trabajo ágil. No deben ser secretarios de los Propietarios de Producto. Al contrario, deberán proteger al equipo de desarrollo frente al propietario del producto y las partes interesadas externas.
- Cada equipo Scrum deberá tener asignado un líder de entrega. Esta persona conectará al PO, al SM y al equipo de desarrollo en una configuración viable, definirá los procesos de entrega y resolverá los posibles riesgos, problemas o conflictos que pueda tener el equipo. El líder de entrega es la persona adecuada para decidir las cuestiones de personal y presupuesto del proyecto. Esta persona se esforzará por crear un entorno para el equipo en el que todos puedan rendir al máximo.
- La responsabilidad del equipo de desarrollo es desarrollar las historias del backlog. Pueden ayudar a la OP a construir el contenido de algunas historias (principalmente las que son demasiado técnicas), pero no son responsables o ni siquiera deben rendir cuentas de las historias que construyen la hoja de ruta de creación de contenidos.
#2. Equipo estable
Invertir en la formación ágil del equipo es importante y debe ser un proceso rápido. Dejar que estos conocimientos desaparezcan cada pocos meses es una pérdida de tiempo para todos.
Los primeros cinco sprints puede utilizarlos como curva de aprendizaje para que el equipo conozca y practique las actividades básicas de scrum. Una vez que estén claras para todo el equipo, puede comenzar el proceso de mejora continua del equipo scrum. Pero si las personas del equipo cambian con regularidad, se encontrará en un bucle constante de transferencia de conocimientos y formación.
Un equipo así probablemente nunca alcanzará su pleno potencial de rendimiento, y el equipo de dirección seguirá preguntándose por qué antes (antes de la transformación ágil) era más eficiente de lo que parece ahora.
Por lo tanto, construya el equipo, invierta los conocimientos y, una vez que el equipo se sienta seguro con los nuevos procesos, manténgalo como está y siga desarrollándose. A partir de aquí, comenzará el camino constante hacia la perfección.
#3. Matriz RACI
Es una buena práctica elaborar y acordar la matriz RACI (Responsable, Contable, Consultado, Informado) entre todos los equipos justo antes de que comience el trabajo real. Esto puede eliminar muchas confusiones desde el principio.
Es muy importante, sobre todo en las primeras fases de las iniciativas de transformación. De lo contrario, la gente empezará a plantearse preguntas sobre quién debe hacer qué en qué situación, especialmente en aquellas que no se abordaron explícitamente a través de las comunicaciones del equipo.
He aquí un ejemplo de dicha matriz RACI para algunas de las responsabilidades. Su proyecto puede tener un conjunto diferente. Es importante capturar las relevantes.
| Tarea | Solicitante | Jefe de entrega | Propietario del producto | Scrum Master | Equipo de desarrollo |
|---|---|---|---|---|---|
| Sesiones de planificación de sprints | C/I | C | A/I | R | C/I |
| Entregar incremento de liberación | N/A | I | A/I | C/I | R |
| Revisión Sprint | C/I | I | R | I | C |
| Sprint Retrospectivo | I | I | A/I | R | C/I |
| Afinar la cartera de pedidos | I | A/I | R | A | C/I |
Conclusión
Aún podría haber mucho sobre lo que escribir, ya que hay muchas formas y muchos lugares en los que la transformación ágil puede desviarse del camino. El propósito era señalar algunos de los problemas que considero que se repiten a menudo.
La iniciativa en sí es una buena idea. Sin embargo, puede convertirse rápidamente en una pesadilla para todos los participantes si no se respetan algunas reglas básicas. He destacado algunas de ellas, pero utilice el sentido común y todo irá bien. 🙂
A continuación, consulte los buenos recursos de aprendizaje para la certificación Agile.