Caso práctico: ¿Debería presentar un nuevo sistema de gestión de proyectos?

Cynthia Ramos solo quería coger su ensalada de pasta de la nevera común y comer en su escritorio, pero en vez de eso se vio envuelta en otro intercambio con Jim Miller. Desde que se unió a MainFrame como desarrolladora de software, seis meses antes, cada conversación con Jim giraba en torno al obstáculo que era el sistema de gestión de proyectos de la empresa. Su primer día, en una sala llena de nuevos colegas, le preguntó si su antiguo empleador había utilizado Scrum.1 Cuando ella dijo que no, él se rió entre dientes y dijo: «¡Puede que se arrepienta de haberse ido para venir aquí!»

Ahora Jim gritó un saludo: «Hola, Ramos, ¿qué tal su ¿Va a correr?» Sus compañeros de mesa —Adnan Persaud y Wai Quon— y él se echaron a reír. «Está bien», respondió Cynthia, sonriendo y cogiendo su comida. Al salir de la habitación, oyó a Jim susurrar: «Sé que odia Scrum tanto como yo».

A Cynthia no le encantaba Scrum, pero le gustaba trabajar en MainFrame. Su anterior empleador, Ambitious Computing, una startup centrada en la inteligencia artificial, era más avanzado tecnológicamente y sus colegas estaban más contentos, pero MainFrame era una de las tres principales empresas de hardware y software del mundo. Llevaba 40 años en el negocio y le pagaba casi un 50% más que a Ambitious.

El cambio más difícil había sido pasar de trabajar de una manera mucho más rápida y estructurada a adaptarse al ritmo más metódico y deliberado del MainFrame. El equipo de nueve personas de Cynthia incluía desarrolladores de la India, Australia, el Reino Unido y los Estados Unidos. Utilizaban un modelo de seguimiento del sol que maximizaba la productividad al garantizar que el trabajo se realizara de forma continua, ya que los miembros del equipo de una zona horaria entregaban el trabajo a sus colegas de otra día a día. Era fundamental una comunicación clara entre los equipos.

Tras el proceso de Scrum,2 El trabajo de cada equipo de software de MainFrame se dividió en sprints de dos semanas con una publicación de código importante cada trimestre. El código se probaría e integraría en los sistemas críticos en tiempo real de los clientes, como equipos militares, satélites, vehículos autónomos y dispositivos médicos, que tenían que funcionar sin fallos.

Al final de cada sprint de dos semanas, Cynthia enviaba un lote de código a un equipo de pruebas y reunía a su propio equipo para reflexionar sobre cómo habían ido las cosas y qué les gustaría cambiar para el siguiente sprint.3 También revisaba el atraso, una lista priorizada de los proyectos que el equipo de pruebas había identificado para que su equipo trabajara a continuación, como funciones de soporte o errores que corregir. La lista y la hoja de ruta de productos asociada las generó y aprobó un equipo directivo muy por encima de su nivel salarial. El equipo de Cynthia solía completar 10 historias (o tareas) en cada sprint. MainFrame quería que todos completaran al menos 12. A pesar de sus quejas, solo Jim Miller alcanzó esa cuota.

Cynthia, Jim, Adnan, Wai y los demás «maestros de Scrum» dependían de Emma Burger, la directora responsable de recopilar los requisitos detallados de los usuarios desde el punto de vista empresarial y de transmitirlos a los equipos de software. Emma dependía de Chris Patrick, el director de fabricación, quien supervisó 34 informes, incluidos directores de proyectos técnicos, ingenieros de desarrollo de software y directores de versiones en los Estados Unidos y en todo el mundo.

A Cynthia le gustaba trabajar para Emma y quería hacerle la vida más fácil, no más difícil. Pero estaba de acuerdo con Jim: los procesos de MainFrame eran demasiado engorrosos. Por eso, cuando Jim la siguió fuera de la cantina hasta su cubículo, se sentó en su escritorio y le pidió que lo ayudara a cambiar las cosas, ella la escuchó y, al final, accedió a reunirse con él más tarde para hablar de un plan.

La petición de Jim

«Estaba esperando a que alguien como usted se uniera a MainFrame», dijo Jim. «Lo escucharán».

«¿Qué quiere que haga?»

«Trabajando en lotes pequeños, con cadencias tan ajustadas, limitados por la administración en lo que podemos hacer, nunca vamos a ser tan productivos como ellos quieren que seamos», dijo. «Se tarda mucho en publicar por fin la actualización más pequeña. Necesitamos un sistema diferente. ¿Ha utilizado Flow? Mi hija también es desarrolladora de software y así es como trabaja su equipo».

Cynthia no solo había utilizado las herramientas y técnicas analíticas de Flow cuando estaba en Ambitious Computing, sino que se había graduado en el método. La verdad es que no quería hacer el curso, pero su jefe y mentor de la época había insistido. «Aquí es hacia donde se dirige la industria», dijo.

«Usé Flow at Ambitious», le dijo Cynthia a Jim.

«Así que usted conocer es mejor», dijo. «No hay inicios y paradas continuos e innecesarios, ni flujos de trabajo en silos, más libertad.4 Se acabaron las reuniones redundantes diarias de las 9 de la mañana a las que mi equipo en Bombay tiene que unirse a las 18:30 hora local. Hemos fijado la fecha de lanzamiento. Aprovechamos el análisis predictivo y utilizamos la IA en lugar de pedir plazos ampliados».

Cynthia estaba de acuerdo con Jim en esos puntos, pero también sabía que no a todo el mundo le gustaba trabajar con Flow. Por ejemplo, las herramientas basadas en la IA a las que hacía referencia Jim eran excelentes para predecir errores e impedimentos que impedían un flujo de trabajo fluido, pero eso solo se debía a que todo el trabajo se supervisaba y gestionaba de forma transparente en tiempo real. Los equipos que trabajaban en Flow (y sus directivos) podían ver el proceso de desarrollo en las pantallas digitales de sus oficinas, lo que quizás era fantástico para la colaboración en equipos distribuidos, pero era estresante para los desarrolladores con menos confianza.5

Además, MainFrame fue un incondicional de la tecnología, una de las primeras empresas en producir software comercial. Cynthia no estaba segura de que, después de solo seis meses en una empresa que había tenido éxito durante 40 años, pudiera pedir a sus líderes que cambiaran su forma de hacer negocios.

«¿En qué puedo ayudarlo con esto?» preguntó ella.

«Quiero que presente Flow a los superiores», dijo Jim.6

Un proyecto piloto

En contra de su buen juicio, Cynthia accedió a asistir a una reunión con Emma y Jim. Fue el que más habló, explicando su visión de cómo sería un programa piloto y cómo pensaba que Cynthia podría presentárselo a Chris Patrick en la revisión anual de la mejora de los procesos.

Emma se mostró escéptica. «Cynthia, ¿qué opina?»

«Flow funcionó muy bien en Ambitious», dijo Cynthia. «No estoy seguro de que sea lo que necesitamos aquí, pero estaré encantado de ayudar a pilotarlo».

«¿Estaría dispuesto a presentar los resultados a la junta?» Preguntó Emma. Cynthia se encogió de hombros.

«Cynthia es licenciada en la Ivy League», dijo Jim. «Trabajó para un futuro unicornio. Tiene un diploma en Flow. Si alguien puede demostrar y comunicarle a Chris la necesidad de este cambio, es Cynthia».

A Cynthia le sorprendió lo mucho que Jim sabía de ella, pero también la complació su estima. Desde que se unió a MainFrame, ha mantenido la cabeza agachada y ha hecho todo lo posible para cumplir los plazos poco realistas que le habían fijado sus supervisores. Tal vez era hora de que alzara la voz y se arriesgara.

«Vale, mientras todos cumplan sus cuotas, no me importa cómo lo hagan», dijo Emma. «Pero si hay algún signo de problema, lo voy a cerrar».

Durante los meses siguientes, Cynthia revisó artículos de investigación académica e informes de consultoría para comparar las técnicas y los desafíos de Flow con los de Scrum y otros métodos de desarrollo de software, como la programación extrema (XP) y el desarrollo basado en funciones. Ella releyó Deje de empezar, empiece a terminar y libros similares. Luego le dijo a Emma que estaba lista para trabajar con un proveedor para lanzar un proyecto piloto en su software Flow, impulsado por la IA, que, a diferencia del sistema actual, tenía una función de tablero Kanban digital para mejorar la comunicación del equipo y podía generar automáticamente métricas, como el tiempo de ciclo y el tiempo de entrega, que los equipos de Scrum necesitaban registrar y hacer un seguimiento por sí mismos.

En las reuniones de planificación de sprints, ahora programadas para medio día en lugar de reducirse a una hora, el equipo de Cynthia analizó la cartera de productos, dividió los proyectos en tareas y planificó los sprints futuros para cumplir con los requisitos priorizados. En algunos casos, Cynthia tuvo que diseñar una combinación de técnicas de Scrum y Flow, especialmente al principio de los proyectos.7 El enfoque de entrega frecuente de los sprints de dos semanas era un requisito de MainFrame. Esa regla no podría cambiarse hasta que todos trabajaran en Flow.

El piloto era un tema candente en la cantina. El día que Cynthia anunció que su equipo experimentaría con la coordinación de Flow, Wai habló directamente con ella por primera vez. «¡Gracias por hacer esto!» dijo. «¡Me muero de ganas de que todos lo tengamos!»

Un año después

Tras un año de duración del piloto, Cynthia estaba orgullosa de los resultados. Su equipo había mantenido su producción de 10 historias por sprint, pero ahora desplegaba código de forma continua sin errores críticos, y la moral del equipo había mejorado. Jim la había animado todo el camino.

«De verdad lo hizo», le dijo. «Tenemos a la IA que elige y prioriza sus proyectos, en lugar de a un imbécil corporativo que nunca ha escrito una línea de código. Se trata de detectar los defectos y los cuellos de botella antes de que su gente lo haga. Los jefes pueden ver exactamente la posición del equipo en sus proyectos y el poco tiempo que le dedican».8

Estudio de caso Classroom Notes

El término «scrum» (en el contexto del desarrollo de productos) se introdujo en Harvard Business Review

…

Pero Emma pronto reventó su burbuja. «He hecho una vista previa de lo que estamos haciendo para Chris», dijo en una videollamada con Cynthia y Jim desde Londres, adonde había viajado para una reunión de planificación de alto nivel. «Tuvimos una gran discusión. Nunca usó Flow. Lo primero que preguntó fue cuántas historias promedió el equipo de Cynthia en cada sprint. Cuando le dije que la productividad básicamente seguía siendo la misma, puso los ojos en blanco».

«Entonces, ¿eso es todo?» Preguntó Cynthia. «¿Seguimos presentándonos a la junta de mejora de procesos? ¿Podemos mantener el piloto en marcha?»

«Chris dijo que era nuestra decisión, pero confía en que el comité nos criticará, especialmente los miembros más antiguos, que no tienen experiencia en software. Sinceramente, Cynthia, usted tiene la experiencia y dirigió el piloto, así que es su decisión. ¿Cree que esto mejorará nuestra productividad a largo plazo? ¿Y es lo suficientemente fuerte en esa convicción como para ponerse de pie delante de estos tipos y decirlo?»

Esa noche, al salir de la oficina, Cynthia se metió en la cantina para coger su contenedor de Tupperware sin abrir. No tenía hambre de almorzar esa tarde. Tenía el estómago hecho nudos. Wai, Adnan y Jim salían de la oficina para la happy hour y le preguntaron si estaba lista para presentar Flow. Dijo que tenía un mal presentimiento.

«No se preocupe, Ramos», dijo Jim. «Lo hará muy bien».

Los expertos responden: ¿Debería Cynthia presentar Flow a la junta de mejora de procesos?

Sonali Raut es científico de datos sénior en Múnich RE Automation Solutions.

Cynthia debería esperar a presentar Flow a la junta de mejora de procesos. Primero debería elaborar meticulosamente una propuesta en la que se describan los motivos de esta iniciativa, incluidos datos bien investigados y argumentos basados en pruebas. Eso mejorará las perspectivas de implementar con éxito la metodología.

Su mayor error fue no incluir a Chris Patrick en el proyecto Flow desde el principio. Como empresa consolidada con un historial de éxitos, MainFrame no introducirá un nuevo sistema de gestión de proyectos sin su apoyo.

Pero no se equivoque: añadir Flow a los procesos de la empresa mejoraría absolutamente la estructura, la adaptabilidad, la eficiencia, los gastos administrativos y la productividad del proyecto. Es responsabilidad de Cynthia reforzar su propuesta con datos, resultados de investigaciones y estudios de casos pertinentes.

Ahora que Chris por fin sabe lo que hacen Cynthia y Emma, deberían explicarle todo lo que el equipo ha logrado. Sabiendo que se centra en las historias por sprint como métrica clave y que su equipo no lo mejoró durante el piloto, Cynthia debería destacar la transparencia que ofrece el tablero Kanban digital, la mejora del trabajo en equipo y el aumento de la moral.

Debería hacer hincapié en que una métrica de historia por sprint sin cambios es, de hecho, un indicador positivo: su equipo pudo mantener la productividad durante el proyecto piloto, incluso cuando pasó a la integración y el despliegue continuos del código, mejoró la supervisión y hizo felices a los desarrolladores. A medida que el equipo se haga más experto en el nuevo sistema, la velocidad y la eficiencia no harán más que aumentar.

Cynthia debe esforzarse para que Chris comprenda que otras métricas, como la mejora de las funciones del producto y la reducción de los costes de desarrollo, también son importantes. Quizá pueda ofrecer un ejemplo de una mejora realizada durante el piloto que encantó a los clientes, o de un error detectado por los desarrolladores y que se habrían saltado sin usar Flow. También debería mostrarle a Chris estudios de casos de otras empresas que han hecho la transición a Flow y explicarle cómo los utiliza su anterior empleador.

Por último, tendrá que detallar los argumentos de negocio para el cambio. ¿Sabe cuánto costará la transición? ¿Tiene un presupuesto en mente para el proyecto? ¿Cuánto tiempo tardará? ¿Cuánto dinero ganará o ahorrará la empresa al mejorar la productividad, la colaboración y la transparencia? Es decir, ¿cuál es el ROI?

Solo después de que Chris esté de acuerdo y ella, él y Emma hayan resuelto estas cuestiones, debe hacer su presentación ante la junta de mejora de procesos. Estoy seguro de que Cynthia podrá convencer a MainFrame de que pase de Scrum a Flow, pero aún no está lista para exponer sus argumentos.

Alex Estevam es director de programas técnicos en Mastercard.

Cynthia está lista para presentarse. Uno de los cinco valores clave de Scrum es el coraje. La guía de Scrum, que fue redactada y modificada por los creadores del marco Scrum, dice que las personas que utilizan los métodos de Scrum deben sentirse lo suficientemente cómodas con sus colegas como para defender lo que creen. Eso es lo que debe hacer Cynthia aquí.

Tiene buenas razones para querer introducir los procesos de flujo en MainFrame. Los métodos Scrum requieren un enfoque de arriba hacia abajo. La alta dirección elige en qué trabajan los desarrolladores y les dice cuánto tiempo tienen que trabajar en ello, algo que no les gusta a los desarrolladores. Flow, por el contrario, ofrece a los desarrolladores la posibilidad de mostrar a la administración lo que hay que arreglar y cuándo. Además, muchos de sus colegas quieren Flow, y parece que Cynthia también. Así que debería presentarlo.

Por supuesto, no importa la eficacia con la que presente Flow a la junta, algunos directivos e incluso algunos desarrolladores se resistirán. Aunque conozco a algunos desarrolladores que odian absolutamente las reuniones diarias de Scrum, que consideran una pérdida de tiempo y creen que los gerentes solo las llevan a cabo porque tienen que hacerlo, otros piensan que son esenciales, ya que permiten que todos se preparen colectivamente para el día que viene.

Sin embargo, Cynthia sabe que la transición a Flow es la decisión correcta a largo plazo para MainFrame. Por eso es fundamental que lo presente en la junta. Que tenga éxito probablemente dependerá de lo bien que eduque a los miembros de la junta. Ya ha demostrado que su equipo puede mantener la productividad, implementando código nuevo de forma continua sin errores importantes. Eso es una victoria.

También debería encontrar una justificación financiera para el cambio. Debería dejar claro que puede ampliar el programa piloto y empezar a recopilar datos para demostrar que los procesos han mejorado y que, en última instancia, esas mejoras le ahorrarán mucho dinero a MainFrame.

Si nadie tiene el coraje de presentar Flow, puede que la dirección nunca aprenda lo suficiente sobre él como para entender qué tan bien funciona. La colega de Cynthia tiene razón. Es la persona mejor situada para persuadir a los escépticos como Chris.

Otra cosa que quiero señalar: La guía de Scrum dice que el coraje debe ser bilateral. Eso significa que si Cynthia es lo suficientemente valiente como para presentar a Flow a la junta, Chris debe tener el coraje de escuchar su argumento y, si hace uno bueno, admitir que se equivocó con respecto a Flow.

Los estudios de casos ficticios de HBR presentan los problemas a los que se enfrentan los líderes de empresas reales y ofrecen soluciones de expertos. Este está basado en un caso impartido por Nien-hê Hsieh, profesor Kim B. Clark de Administración de Empresas en la Escuela de Negocios de Harvard.