Continuo y termino hoy con la serie que empecé ayer, sobre «Oxímoron y frases de dudosa veracidad que comúnmente se escuchan sobre Agilidad» (versión 2017), al final ayer me lié y se me fue de espacio el post, así que lo dividí en dos partes y aquí tienes la segunda.
Recuerda que, si tienes «Oxímoron y frases de dudosa veracidad que comúnmente se escuchan sobre Agilidad» sería genial que me los dejaras en los comentarios y así ampliar la lista.
«Pasos / Plan / Método / <pon alguno similar> de Auto-Organización de equipos»
Si en vez de los anteriores pones «recomendaciones», «buenas prácticas», ya sería otra cosa, pero… ¿plan para auto-organizarse? Pero si auto-organizado (no me extiendo en el concepto eh, te dejo post, Modelos para evaluar cómo llevas el liderazgo (ágil) y la auto-organización, que veo que este post, al final, también se me va de extensión) entre otros se basa en que, dentro de unas «constraints», el equipo aporta el «cómo» es la mejor manera de trabajar… ¿cómo externamente le puedo decirle la mejor manera de trabajar y cómo llegar a ella?
Bueno, sí, quizás si le doy pasos muy genéricos, prácticas típicas, pero, como en el anterior… ¿para qué le llamas plan o método?
«Workflow Ágil»
Por aquello de quitar los silos, en pro de los equipos multi-funcionales, para eliminar desperdicios derivados de decisiones que se pueden evitar y estados propietarios, cuellos de botella, potenciar las competencias en T, propiedad colectiva, responsabilidad compartida, y no sé cuantas cosas más, en agilidad lo típico (frente al workflow) es el «flujo continuo» (izquierda – derecha, sin vuelta atrás, etc.), entones… ¿qué pinta un workflow Ágil? Te recomiendo aquí aquello de tableros ágiles sospechosos.
Un workflow ágil, sacado de aquí
«Utilizamos el modelo (o lo que sea) ágil Kanban»
De esto ya hablamos en Kanban… ¿realmente es ágil? Kanban no tiene su origen en la agilidad, viene de Lean, y, sí, puede usarse de manera ágil (y beneficiarse y complementarse de ello) pero sus principios no son los del manifiesto ágil, pudiendo incluso usarse Kanban a la perfección, con excelentes resultados… sin seguir los valores del manifiesto ágil. Y lo anterior es lo que diferencia a Kanban de Scrum, XP, etc.
Otra cosa sería decir «usamos Kanban de manera ágil» (que no es lo mismo que decir el modelo ágil Kanban).
«Utilizamos ITIL de manera ágil»
No lo dudo, pero siendo ITIL lo que es, tantos cambios habría que hacerle que, en este caso, mi duda es si se le podría seguir llamando ITIL.
ITIL nace de la visión en silos, como modelo para Operaciones (sí, luego extendido a «servicios», pero quién lo ha usado de siempre ha sido Operaciones, Explotación, Producción, o como lo llames).
Entre otros, algún ejemplo… con una propuesta así para la gestión de cambios…. esto no parece sonar nada a DevOps y equipos multifuncionales.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hay veces que pienso que estoy sincronizado contigo, y otras que estamos en las antípodas. Tus dos últimos artículos me hacen sentir de esta segunda manera.
Pero bueno, supongo que eso es la salsa de la blogosfera. Si todos pensásemos igual, ¡qué aburrido!
En el anterior preferí quedarme callado y no trolear. Pero en este, con el punto de ITIL… ya tocas fibra sensible. ITIL nace del servicio, no se extiende al servicio. Que lo usen los departamentos de operaciones y nadie más es un error de bulto, que reconozco comete la mayoría. Y el 90% de sus buenas prácticas son aplicables en un entorno ágil. Necesita una revisión, y necesita actualizarse con las nuevas tendencias. Y de hecho prometen sacarla para 2018. Pero decir que no se puede aplicar un ITIL ágil, me parece demasiado categórico. Hay que darle al tarro y saber sacar lo bueno, y dejar lo rancio. Pero sigue siendo ITIL.
Pues yo el 100% de la gente que conozco que usa ITIL es de Operaciones. Y en foros de referencia donde se suele tratar ITIL, como itsmf, veo mucha gente de Operaciones…
Sí, es lo que te digo. Es un error que comete la mayoría. Encerrarlo en operaciones y no hacerlo transversal a toda la organización. Pero ¿Quien no ha visto áreas de desarrollo «ágiles» que sólo están en desarrollo; ignorando a operaciones, a negocio y a todos los demás?
Por la experiencia de la implantación de ITIL en mi organización, no es tanto el problema su «pesadez» como su implantación. Es decir, tú puedes implantar un workflow de ITIL de manera que para hacer un cambio necesites rellenar un formulario, tres firmas, dos revisiones y meter en el ajo a tres o cuatro departamentos distintos (entre ellos, uno dedicado exclusivamente al control de cambios).
O podrías haber diseñado un proceso que dejara constancia de todo lo que hay que dejar constancia según ITIL, pero a través de 4 clicks de ratón.
Hay referencias que hablan de una fusión entre ITIL y DevOps; la pregunta es, ¿cómo implementamos ITIL para que esté en la línea de DevOps? Como se hace habitualmente no, desde luego.
Ole! Miguel. En el clavo.