En una empresa de petróleo y gas a la que acompañamos, teníamos un tablero con el trabajo del equipo y una columna para los impedimentos. Esa columna seguía creciendo mientras las entregas se demoraban.
El jefe de tecnología nos había contratado para desarrollar aplicaciones internas más rápido. Entrenamos al equipo y empezamos a acompañarlo en la implementación de Scrum. Había interés en hacerlo funcionar. También había personas repartidas entre varios proyectos y compras de equipos que no se concretaban.
El jefe de tecnología llevó esos problemas a sus superiores. Pidió que las personas pudieran concentrarse en el producto y que se agilizaran las compras. No consiguió cambiar esas condiciones. Con el tiempo, el equipo se frustró y terminó culpando a Scrum.
Conté esa experiencia en Your Scrum Playbook, donde llamé a la empresa Big OG para mantener su anonimato. Me dejó un aprendizaje bastante concreto: antes de iniciar una transformación, conviene comprobar quién tiene la capacidad de resolver los problemas que van a aparecer fuera del equipo. Nosotros también teníamos que haber prestado más atención a eso.
Dónde se va el tiempo
Una estrategia puede estar equivocada. Si estamos apostando por un producto que nadie necesita, acelerar su lanzamiento difícilmente va a salvarnos. Antes de atribuir un mal resultado a la ejecución, hay que revisar la apuesta y sus supuestos.
Pero cuando existe una prioridad clara y el trabajo se queda detenido esperando una decisión, vale la pena seguir esa espera hasta encontrar su causa.
Piense en una iniciativa que hoy esté atrasada. ¿Qué está ocurriendo con ella en este momento? Puede haber alguien trabajando en una solución y comprobando si funciona. También puede estar detenida hasta la próxima reunión del comité, aunque la información necesaria para decidir lleve días disponible.
Todo ese tiempo aparece al final en la fecha de entrega. Para el cliente, los días que su propuesta pasó entre correos también cuentan.
Por eso me interesa separar el tiempo de trabajo del tiempo de espera. Cada uno exige una intervención diferente. Si falta una capacidad técnica, habrá que desarrollarla o conseguirla. Si la decisión está pendiente porque nadie tiene claro quién puede tomarla, capacitar de nuevo al equipo dejará ese problema intacto.
Al revisar las aprobaciones, hay que entender qué riesgo controla cada una. Algunas serán necesarias; otras pueden estar duplicando una revisión que ya se hizo. Esa diferencia permite simplificar el recorrido sin quitar una protección que la empresa necesita.
Las prioridades se deciden al asignar personas
En Big OG, una parte del problema era que las personas trabajaban en varios productos. El equipo tenía que planificar entregas con una capacidad que otras iniciativas también reclamaban.
Suponga que su empresa define una nueva prioridad, pero mantiene todas las anteriores y les asigna a las mismas personas. Alguien tendrá que decidir, cada día, qué pedido atender y cuál dejar esperando. Si la dirección no resuelve ese conflicto, puede terminar decidiendo el jefe que más insiste.
Después resulta difícil entender por qué la prioridad estratégica no avanzó como se esperaba.
Para darle capacidad a una iniciativa, puede hacer falta posponer otra. Eso exige explicarle a su responsable por qué ahora tendrá que esperar. Mantener todas las promesas también tiene un costo, aunque al principio sea más fácil evitar esa conversación.
Como directivo, revisaría la asignación real de las personas antes de pedir un compromiso adicional. Si alguien recibe instrucciones incompatibles de dos responsables, corresponde resolver esa incompatibilidad. Exigirle más compromiso no le permite estar en dos sitios a la vez.
Un patrocinador necesita poder actuar
El jefe de tecnología de nuestro caso intentó resolver los problemas. Su dificultad estaba en que los cambios necesarios dependían de personas sobre las que no tenía suficiente autoridad o influencia.
En otra empresa, una compañía colombiana de telecomunicaciones que en el libro llamé GoTelecom, encontramos una dependencia parecida. El equipo necesitaba un desarrollo de software. El área de tecnología pidió que se incluyera en el presupuesto del año siguiente; después, desarrollarlo podía tomar otro año.
El vicepresidente que patrocinaba la transformación resolvió ese impedimento contratando personal de tecnología para su división. Tenía la capacidad de cambiar la forma en que se conseguían los recursos. Eso permitió resolver una dependencia que el propio equipo no podía eliminar.
Crear un grupo de tecnología separado puede traer costos y nuevas dificultades de coordinación. Lo que rescato de ese caso es que había alguien capaz de tomar la decisión y responder por ella. En Big OG nos faltó esa capacidad.
Por eso, antes de asignar la responsabilidad de ejecutar una iniciativa, haría explícito cómo se van a resolver los conflictos entre áreas. El responsable del equipo necesita saber a quién acudir y cuándo obtendrá una respuesta. Agregar un nombre como patrocinador en la presentación del proyecto no resuelve ninguna de esas preguntas.
También conviene revisar qué decisiones podrían tomarse más cerca del trabajo. Una decisión reversible, con un costo de corrección limitado, puede permitir más autonomía. Una decisión difícil de deshacer necesita otro nivel de análisis. Delegar exige definir esos límites y preparar a las personas para usarlos.
Esta relación entre ejecución, prioridades, liderazgo y organización es parte de lo que abordamos con VELO5™. Si se cambia la forma de trabajar de un equipo, hay que mirar qué necesita del resto de la empresa para poder entregar.
Una revisión que puede hacer esta semana
Para mejorar la ejecución estratégica, empezaría por una entrega importante que se haya atrasado. Reconstruiría su recorrido con las personas que participaron, usando las fechas y solicitudes reales. Querría responder estas preguntas:
- ¿Desde cuándo está pendiente la entrega y qué parte del tiempo se fue esperando?
- ¿Qué impedía avanzar durante esas esperas?
- ¿Quién podía resolver cada impedimento y qué necesitaba para hacerlo?
- ¿Qué otro trabajo competía por las mismas personas o recursos?
De esa revisión debería salir un cambio concreto que alguien tenga la autoridad de hacer. Si una entrega se detuvo porque una persona fue asignada a otro proyecto, habrá que resolver esa asignación. Crear una reunión adicional para pedirle avances dejaría intacta la causa de la espera.
Después hay que comprobar si ese cambio ayuda. Mire la siguiente entrega: cuánto tardó, dónde se detuvo y si apareció un problema de calidad o riesgo que antes no existía. Reducir una espera solo sirve si acerca un resultado útil al cliente.
Si el impedimento vuelve a aparecer y requiere una decisión suya, póngale fecha. El equipo ya hizo su parte al mostrar dónde está detenido el trabajo.
¿Quieres conocer cómo hemos generado resultados e impacto en organizaciones reales, con personas e inteligencia reales? Conoce nuestros casos de éxito