Teniendo 4 valores como base, y 12 principios añadidos, es grande la multitud de maneras de llegar a crear una cultura que pueda llamarse Ágil. Y esto va más allá de cumplir punto por punto con un framework Ágil, como Scrum, de tener mucha gente certificada o de seguir un framework de dudosa Agilidad como es SAFe (ten cuidado y no estés tan seguro con #SAFe).
- Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito (de 2012)
- El cambio cultural Ágil más allá de la implantación de procesos Ágiles
No obstante, y con lo complicado que puede llegar a serlo, hoy, podemos ver en la web multitud de empresas que se auto-denominan Ágiles.
No hay, ni creo que sea buena idea que exista, una especie de «check list» irrefutable para, fácilmente, saber el grado de Agilidad de una organización. Pero si que, bajo la amplitud de todo esto, hay ciertos indicios que, de darse, hacen difícil justificar una mínima Agilidad (por fácil que sea decir aquello de «somos Ágiles»).
Así que, de manera similar al post de ayer, te voy a dejar algunos indicios (hay muchos más de los que deje en este post) que hace sospechar de que, por mucho que podamos decir que «somos Ágiles»… realmente lo seamos (aunque estemos en camino de ello).
Por ejemplo, es difícil justificar una cultura Ágil si no creas software usable y Testeado (que termina en pre o producción) en cada Sprint (a esto ya le dedicó un post uno de los padres de la Agilidad). No digo imposible, porque es demasiado absolutista, pero muy muy muy difícil es decir que ya tienes una cultura Ágil si pasa esto (yo aún no he visto ningún caso convincente, por mucha excusa y razón quieran darte, será muy justificable pero… no es Ágil).
También sería difícil justificar que tienes una cultura Ágil si tus equipos no son estables (no los forman siempre las mismas personas y/o no trabajan bajo el mismo objetivo) y ven condicionada esta estabilidad por fechas e hitos de proyectos.
Esto no implica que no puedas trabajar, de cara a clientes, en «modo» proyectos, pero de cara a equipos el modelo de trabajo es… de equipos (de producto lo llaman también, pero no sé si es la mejor manera de llamarlo). Te dejo abajo algunos post sobre esto.
- 3 síntomas de que te gestionas por proyectos y no por equipos
- Mi mundo habla en «proyectos» pero yo quiero ser «ágil»
Si tienes silos en tu estructura, del tipo «somos el cliente y ellos son los desarrolladores», o «Testing / Operaciones es un equipo o empresa externa», o «somos el cliente pero nos desvinculamos del día a día de los Product Owner (que son del proveedor)», etc. Es muy raro que puedas justificar una cultura Ágil (por mucho que te hayas gastado en certificar a cientos de personas de tu empresa en Scrum).
Si cierras grandes «Backlog» de historias en Jira, que se suponen se completarán dentro de mucho, y que, además, cambiar esos backlogs es problemático… dudo de tu Agilidad.
O si la comunicación vía acta, papel, mail, pdf, etc., está por encima de la comunicación cara a cara.
O si la excelencia técnica no es algo presente de manera continua.
O si, por poner alguno más, las decisiones operativas, de cómo realizar una historia, cuántas se pueden hacer por Sprint, qué historias entran en un Backlog, etc., se toman desde fuera del equipo (y, recuerda, el Product Owner está dentro del equipo). Esto, muy simplificadamente, son cosas que deben quedar en la auto-organización de los equipos.
Podría poner más, pero se me alarga el post. No obstante si quieres más, o si quieres saber en qué me baso, por si piensas que estoy loco, que me he inventado todo esto, pero que «tu Agilidad es muy buena», puedes irte a una web muy buena que seguro te aclara estas dudas, se llama… Manifiesto Ágil.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024