Pregunta: EL DESAFÍO DE RADICO El personal ejecutivo de Radico Corporation estaba muy satisfecho con el programa de capacitación de un día al que asistieron sobre los beneficios de usar Agile y Scrum en algunos de sus proyectos. Radico proporcionó productos y servicios a clientes del sector público y privado, casi todo a través de licitaciones competitivas. No se

EL DESAFÍO DE RADICO El personal ejecutivo de Radico Corporation estaba muy satisfecho con el programa de capacitación de un día al que asistieron sobre los beneficios de usar Agile y Scrum en algunos de sus proyectos. Radico proporcionó productos y servicios a clientes del sector público y privado, casi todo a través de licitaciones competitivas. No se requería TI para ninguno de los productos y servicios proporcionados por Radico. Agile y Scrum habían demostrado ser exitosos en proyectos de TI internos, pero había algunas preocupaciones sobre si el mismo enfoque podría usarse en proyectos no relacionados con TI para clientes. También hubo cierta preocupación sobre si los clientes comprarían el enfoque ágil y Scrum. Radico reconoció el crecimiento y la aceptación de Agile y Scrum, así como el hecho de que eventualmente podría afectar su negocio principal en lugar de solo la TI interna. A pedido de la organización de TI de Radico, se llevó a cabo un programa de capacitación de un día solo para los niveles superiores de administración para presentarles los beneficios de usar Agile y Scrum y cómo sus técnicas podrían aplicarse en otras partes de la organización. Los ejecutivos terminaron el seminario sintiéndose bien con lo que escucharon, pero aún existía cierta preocupación sobre cómo se implementaría esto en toda la organización y cuáles eran los riesgos. También hubo cierta preocupación sobre cómo podrían reaccionar sus clientes y el impacto que esto podría tener en la forma en que Radico hace negocios. LA NECESIDAD DE FLEXIBILIDAD Radico fue como la mayoría de las otras empresas cuando reconoció por primera vez la necesidad de la gestión de proyectos para sus productos y servicios. Debido a que los ejecutivos temían que los gerentes de proyectos comenzaran a tomar decisiones que estaban reservadas para los niveles ejecutivos de administración, se desarrolló una metodología rígida de administración de proyectos basada en ocho fases del ciclo de vida: 1. Planificación preliminar 2. Planificación detallada 3. Desarrollo de prototipos 4. Pruebas de prototipos 5. Producción 6. Pruebas finales y validación 7. Instalación 8. Cierre contractual La metodología proporcionó a los ejecutivos estandarización y control sobre cómo se llevaría a cabo el trabajo. También creó una gran cantidad de papeleo. A medida que la gestión de proyectos maduró, los ejecutivos ganaron más confianza en los directores de proyectos. A los gerentes de proyecto se les dio la libertad de usar solo aquellas partes de la metodología estándar que fueran necesarias. Como ejemplo, si la metodología requería que se desarrollara un plan de gestión de riesgos, el director del proyecto podría decidir que el plan era innecesario ya que este proyecto era de muy bajo riesgo. Los gerentes de proyecto ahora tenían cierto grado de libertad, y la metodología rígida se estaba convirtiendo lentamente en una metodología flexible que podía adaptarse fácilmente al modelo comercial de un cliente. Incluso con esta flexibilidad adicional, todavía había límites en cuanto a cuánta libertad se pondría en manos del equipo del proyecto. Como se muestra en la Figura I, la cantidad de superposición entre la metodología de Radico, la metodología del cliente típico y la metodología ágil fue pequeña. Radico se dio cuenta de que, si utilizaba un enfoque ágil de gestión de proyectos, la superposición podría aumentar significativamente y dar lugar a más negocios. Pero nuevamente, existen riesgos, y se necesitaría dar más confianza a los equipos de proyecto. LA IMPORTANCIA DEL VALOR La comunidad de gestión de proyectos de Radico ha dedicado bastante tiempo a intentar convencer a la alta dirección de que el éxito de un proyecto no se puede medir únicamente cumpliendo la triple restricción de tiempo, coste y alcance. Más bien, argumentaron que la verdadera definición de éxito es cuando se crea valor comercial para el cliente, con suerte dentro de las restricciones impuestas, y el cliente reconoce el valor. La comunicación efectiva entre el cliente y el contratista, como se identifica en el Manifiesto Ágil, podría hacer que esto suceda. El curso reforzó la creencia de los gerentes de proyecto de que medir y comprender el valor del proyecto era importante. Se demostró que Agile y Scrum son algunas de las mejores técnicas para usar cuando el valor de los entregables del proyecto es de importancia crítica para los clientes, ya sean clientes internos o externos. La experiencia de gestión de proyectos de Radico se basó en gran medida en el enfoque tradicional en cascada en el que cada fase de un proyecto debe completarse antes de que comience la siguiente fase. Esto crea un problema con el valor de medición como se muestra en la Figura II. Con el enfoque tradicional en cascada, el valor se mide principalmente al final del proyecto. Desde una perspectiva de riesgo, existe una gran cantidad de riesgo con este enfoque porque no hay garantía de que el valor deseado estará allí al final del proyecto cuando se mide el valor, y puede que no haya habido indicadores de alerta temprana sobre si se lograría el valor deseado. Con un enfoque ágil, el valor se crea en pequeños incrementos a medida que avanza el proyecto, y el riesgo de no alcanzar el valor comercial final deseado se reduce considerablemente. Este enfoque incremental también reduce la cantidad de tiempo necesario al final del proyecto para las pruebas y la validación. Cuando se utilizan en proyectos que cambian rápidamente, a menudo se considera que las metodologías ágiles y Scrum tienen funciones de gestión de riesgos integradas. Aunque todavía son necesarios otros métodos de mitigación de riesgos, este beneficio adicional de la mitigación de riesgos fue una de las fuerzas impulsoras para convencer a los ejecutivos de Superposición de metodologías de considerar cambiar a un enfoque ágil para administrar proyectos. Agile y Scrum fueron vistos como excelentes formas de superar los riesgos tradicionales de retrasos en el cronograma, sobrecostos y aumento del alcance. PARTICIPACIÓN DEL CLIENTE Durante décadas, los programas de capacitación en gestión de proyectos para los sectores público y privado recomendaron que los clientes se mantuvieran lo más alejados posible del proyecto para evitar la intromisión de los clientes. Por esta razón, la mayoría de los clientes asumieron un papel un tanto pasivo porque la participación activa en el proyecto podría limitar las oportunidades de avance profesional si el proyecto fracasara. Radico tiene alguna participación de clientes en proyectos para el sector privado, pero prácticamente ninguna participación de agencias gubernamentales del sector público. Las organizaciones del sector público querían ver una extensa documentación de planificación como parte del proceso de licitación competitiva, un informe de estado ocasional durante el ciclo de vida del proyecto y luego los entregables finales. Todos y cada uno de los problemas durante la ejecución del proyecto fueron responsabilidad de Radico para su resolución con poca o ninguna participación del cliente. Radico entendió que una talla no sirve para todos y que Agile y Scrum podrían no ser aplicables a proyectos más grandes, donde el enfoque tradicional de gestión de proyectos que utiliza la metodología de cascada puede ser mejor. Tendría que haber un entendimiento de cuándo el enfoque en cascada era mejor que ágil. Para que Agile y Scrum funcionen en algunos proyectos más pequeños, tendría que haber un compromiso total por parte del cliente y su equipo de gestión a lo largo de la vida del proyecto. Esto sería difícil para las organizaciones que no están familiarizadas con Agile y Scrum porque requiere que el cliente comprometa un recurso dedicado durante la vida del proyecto. Si el cliente no reconoce los beneficios de esto, entonces puede percibirse como un gasto adicional incurrido al otorgar el contrato a Radico. Esto podría tener un impacto grave en las actividades de licitación y adquisición competitivas y dificultar o imposibilitar que Radico gane contratos gubernamentales. CAMBIOS DE ALCANCE Con la gestión de proyectos tradicional, acompañada de requisitos bien definidos y un plan de proyecto detallado, los cambios de alcance se manejaban mediante el uso de un tablero de control de cambios (CCB). Se anticipó que, con la cantidad de tiempo y dinero gastados en iniciar y planificar el proyecto, los cambios de alcance serían mínimos. Desafortunadamente, este no fue el caso con la mayoría de los proyectos, especialmente los grandes y complejos. Cuando se iniciaron las solicitudes de cambio de alcance, se convirtió en un esfuerzo costoso y lento para la CCB reunirse y escribir informes para cada solicitud de cambio, incluso si la solicitud de cambio no fue aprobada. Con Agile y Scrum, acompañados de una participación activa del cliente, se pueden realizar cambios de alcance frecuentes y económicos, especialmente para proyectos con requisitos en evolución. Los cambios podrían realizarse de manera oportuna sin un impacto grave en el trabajo posterior y con la capacidad de seguir brindando al cliente el valor comercial deseado. INFORMES DE ESTADO Todos los proyectos, ya sean ágiles o en cascada, pasan por las áreas de dominio de inicio, planificación, ejecución, seguimiento y control y cierre del Project Management Institute. Pero la cantidad de tiempo y esfuerzo invertido en cada área de dominio, y la frecuencia con la que se pueden repetir algunas partes, pueden cambiar. Para empeorar las cosas, las agencias gubernamentales a menudo exigen documentos de informes estandarizados que deben completarse. Muchos de estos son similares a los diagramas de Gantt y otras técnicas de programación que tardan en completarse. Es posible que los clientes no estén satisfechos si se les dice que el estado ahora aparece en un tablero de Scrum junto con las historias. Las agencias gubernamentales tienden a utilizar modelos de contratación estandarizados; y declarar en una propuesta que el contratista utilizará un enfoque ágil o Scrum puede violar sus políticas de adquisición y hacer que Radico no responda a la declaración de trabajo de la propuesta. REUNIONES Una de las preocupaciones que tenían los ejecutivos de Radico era la cantidad de reuniones necesarias para Agile y Scrum y la cantidad de participantes que asistieron. El tiempo dedicado a las reuniones por parte del propietario del producto y el Scrum Master, y en muchos casos el propio equipo, se consideró como horas potencialmente improductivas que aumentaban los gastos generales del proyecto. Con el enfoque en cascada, las reuniones casi siempre dieron como resultado numerosos elementos de acción que a menudo requerían meses y reuniones adicionales para resolverse. En Agile y Scrum, los elementos de acción se mantuvieron al mínimo y se resolvieron rápidamente porque las personas del equipo tenían la autoridad para tomar decisiones e implementar cambios. Esto también facilitó la creación de entregas de valor comercial de manera oportuna. También hay técnicas disponibles para minimizar el tiempo dedicado a las reuniones, como crear una agenda y proporcionar pautas sobre cómo se llevarán a cabo las reuniones. Agile y Scrum trabajan con equipos autónomos formados por personas con diferentes antecedentes, creencias y hábitos de trabajo. Sin un líder definitivo en estas reuniones, existe la oportunidad de conflictos y mala toma de decisiones. Sin una capacitación efectiva en la que cada equipo entienda que están trabajando juntos hacia un objetivo común, puede reinar el caos. La gente debe creer que las decisiones grupales tomadas por el equipo son mejores que las decisiones individuales típicas del enfoque en cascada. La toma de decisiones se vuelve más fácil cuando las personas no solo tienen competencia técnica, sino también una comprensión de todo el proyecto. Las reuniones efectivas informan a los miembros del equipo desde el principio que es posible que no se cumplan ciertas restricciones, lo que les permite suficiente tiempo para reaccionar. Este requisito de más información puede requerir significativamente más métricas que las que se utilizan en los enfoques en cascada. A veces, se puede invitar a los ejecutivos a asistir a estas reuniones, especialmente si tienen información sobre los factores ambientales de la empresa que pueden tener un impacto en el proyecto. PERSONAL DEL PROYECTO En el enfoque en cascada, se dedica una cantidad exorbitante de tiempo a la planificación con la creencia de que se debe preparar un plan completamente detallado al inicio del proyecto y se seguirá exactamente y que se requerirá una cantidad mínima de recursos durante la ejecución del proyecto. El riesgo y la imprevisibilidad luego se manejan mediante una replanificación detallada continua y costosa y numerosas reuniones en las que participan personas que pueden entender muy poco sobre el proyecto, lo que requiere un tiempo de recuperación. En el enfoque de cascada, especialmente durante la licitación competitiva, el cliente puede solicitar datos de respaldo o de respaldo sobre por qué se necesita personal del proyecto a tiempo completo en lugar de a tiempo parcial. Algunas agencias gubernamentales argumentan que demasiadas personas a tiempo completo es un costo de gestión excesivo en el proyecto. Con equipos ágiles y Scrum, el alcance del proyecto evoluciona a medida que avanza y la planificación se realiza continuamente en pequeños intervalos. El éxito de este enfoque se basa en el uso de personas a tiempo completo que no están bajo la presión de otros proyectos que compiten por sus servicios. Las personas en el proyecto a menudo se rotan a través de varias asignaciones de proyectos; por lo tanto, el conocimiento del proyecto no está en manos de unos pocos. Por lo tanto, el equipo puede ser autodirigido, con el conocimiento y la autoridad para tomar la mayoría de las decisiones con poca participación de recursos externos (a menos, por supuesto, que surjan problemas críticos). El resultado es una retroalimentación rápida de la información, una captura de las mejores prácticas y lecciones aprendidas, y una rápida toma de decisiones. La toma de decisiones colaborativa que involucra a partes interesadas con diversos antecedentes es una fortaleza del enfoque ágil. Una vez más, este enfoque podría ser perjudicial para la adquisición si el cliente no tiene conocimiento de Agile y/o Scrum durante las actividades de licitación competitiva. Radico ahora parecía consciente de muchos de los problemas críticos y tuvo que decidir sobre la conversión a un enfoque ágil. No sería fácil.

PREGUNTAS 1. Dadas las cuestiones del caso que enfrenta Radico, ¿dónde debería comenzar Radico?

2. ¿Qué debe hacer Radico si los clientes no comprometen recursos para proyectos ágiles o Scrum?

3. ¿Cómo debe manejar Radico el desarrollo profesional de los empleados cuando se dan cuenta de que no hay puestos formales en proyectos Agile/Scrum y los títulos pueden no tener sentido? ¿Qué pasa si los empleados sienten que ser asignados a un equipo ágil/Scrum no es una oportunidad de avance profesional?

4. ¿Qué tan dañino podría ser para un equipo ágil si los trabajadores con habilidades críticas son reasignados a proyectos de mayor prioridad o se les pide que trabajen en más de un proyecto a la vez?

5. ¿Cómo debe manejar una situación en la que un empleado no seguirá el enfoque ágil?

6. En las reuniones donde no hay un líder, ¿cómo resuelve los problemas de personalidad que resultan en conflictos constantes?

7. ¿Puede una metodología ágil adaptarse al cambio más rápido que una metodología en cascada?

8. ¿El concepto de equipos autoorganizados requerirá que Radico trate la conversión como un desafío cultural?

9. ¿Una parte de la empresa puede usar ágil y otra parte de la empresa usar cascada?