La pregunta del millón. La que los alumnos preguntan una, dos o diez veces en los cursos de Scrum y de Kanban. La pregunta a la que no hay una respuesta concreta porque cada organización es distinta. ¿O sí?
Luis es programador. Trabaja en un gran banco en el que todos los años se deciden los proyectos que se van a hacer en función de los presupuestos. Los presupuestos se hace en base a unas proyecciones que hacen los Jefes de Proyecto más o menos en Octubre y durante el mes de Noviembre se cierran los presupuestos.
En el banco, la forma de desarrollar es… tradicional. Se desarrolla en fases o etapas. Primero se hace el diseño, luego la arquitectura, luego se implementan las características, se prueba y se sube a producción. Todo el proceso debería de durar en teoría unos 6 u 8 meses, pero la realidad es que cada una de las fases se retrasa y va comiendo parte de las otras.
El año pasado, cuando subieron una nueva aplicación móvil a producción, el resultado fue desolador. Las críticas de los usuarios dejaron a la aplicación en una estrella en la Play Store de Android. A pesar de que todos los jefes de proyecto pasaron días haciendo cuentas para mejorar el ranking de la aplicación, no subió mucho más.
Se hizo un análisis post-mortem en el que se concluyó que el problema era que no se daba a los usuarios lo que querían y que eran muy exigentes. El banco no puede funcionar como una startup. Porque no lo es. Luis lleva 10 años trabajando así, para una consultora externa al banco. No ha aprendido mucho en los últimos cinco y su trabajo se hace con Microsoft Project en lugar de Eclipse.
Don Quijote luchaba contra molinos. No seas Don Quijote
Hoy en día, la forma en la que una compañía trabaja marca una gran diferencia a la hora de atraer talento. Si quieres cambiar la forma en la que trabajas, la manera más rápida es buscar otro empleo.
Una de las consecuencias de enseñar profesionalismo, es que aprendes a reconocerlo a kilómetros de distancia. Nos han enseñado que nuestro empleador puede pedirnos literalmente lo que quiera, aunque eso ponga en peligro nuestro propio profesionalismo. Los proyectos tienen que salir a toda costa y cuando todo el mundo aprieta el culo, la calidad es el intangible que más peligra. ¿No es lo que quiere el usuario? Eso no importa. Importa el coste, el alcance y la fecha de entrega.
Un antiguo ejecutivo de una empresa de «Internet» que había crecido mucho los últimos años y que fue despedido hace dos o tres, ahora da cursos de agilidad y explica como en esta empresa aplicaban Scrum, Kanban y Scrumban de una manera muy eficiente. El problema de esta afirmación es que es fácil encontrar a empleados que trabajaban con él y te dicen que no saben si habla del mismo sitio. La falta de profesionalismo le perseguirá durante años.
¿Por qué luchar? Mejor dejar caer las cosas por su propio peso
Cuando mis alumnos me preguntan: ¿Como convenzo a mi jefe de adoptar agilidad? es principalmente porque se han dado cuenta de que lo que hacen se parece a Scrum o a Kanban como un huevo a una castaña. La realidad es que están ejerciendo el rol del Scrum Master como el de facipulador que igual te organiza una retrospectiva que te aprieta a los recursos para que trabajen y entreguen a tiempo.
EL rol del Scrum Master está completamente desligado del delivery. La única forma que tiene el Scrum Master de influir sobre la entrega es mediante el uso correcto de Scrum. Enseñando Scrum. Asegurándose de que Scrum funciona.
Asegurarse de que Scrum funciona en una organización disfuncional supone varias cosas: Probablemente el equipo Scrum no sea capaz de entregar manteniendo un mínimo de calidad y Scrum va a exponer todas esas disfunciones a la vista de todos, haciendo que mucha gente se sienta incómoda.
Adoptarás agilidad solamente después de tener una revelación
La realidad es que el jefe de Luis no quiere escuchar por qué hay que adoptar agilidad dentro del banco. Al final los proyectos salen cumpliendo -más o menos- las métricas que se miden allí: Alcance, tiempo y coste. Y si no se hace un evolutivo para arreglarlos.
Luis es su propio enemigo. Como las cosas salen porque él se esfuerza, no hay ninguna necesidad de cambio. Como el Project Manager/Scrum Master se encarga de apretar al equipo para que se queden a echar horas extras, en realidad no hay ningún motivo para cambiar el statu quo.
No habrá agilidad de verdad hasta que no haya un trauma con el que lidiar. Entonces es posible que todo el mundo se ponga como loco a buscar otra manera de hacer las cosas. Sólo el tiempo suficiente para que parezcan estar de nuevo bajo control.
El programador que cambia profesionalismo por complacencia nunca tendrá agilidad. El Scrum Master que cubre al Product Owner porque está ausente está renunciando al profesionalismo, y por tanto a la agilidad. El mando intermedio que pliega ante los deseos imposibles de un top management, no es profesional y nunca tendrá agilidad.
¿Como convences a tu jefe de adoptar agilidad? Empieza a ser un profesional. Pon tu profesionalidad por encima de tu falsa seguridad. Si no, te perseguirá durante toda tu vida laboral. Scrum es simple, pero no es fácil. Nadie dijo que lo fuera. Si empiezas siendo un profesional, ya habrás dado tus primeros pasos ágiles. Habrás vencido.
Deja una respuesta