---

¿Qué puede causar caos y frustración antes del marco Scrum? ¡Puede que te sorprenda!

Para comprender mejor el impacto de Scrum en nuestras prácticas de ingeniería y negocios, conviene observar un día de trabajo de un proyecto de software.

Por eso me gustaría hablar brevemente de un proyecto del pasado, anterior a la adopción del marco Scrum de desarrollo y entrega de software en nuestras organizaciones.

Unos días antes de escribir estas líneas, almorzamos con un antiguo compañero con quien trabajamos hace casi 20 años.

Marcus obtuvo su certificación Scrum Master y certificación Scrum Product Owner en International Scrum Institute™. Actualmente trabaja como Scrum Master en una de las principales empresas de software de gestión ágil de proyectos.

Marcus apoya ahora a un equipo ágil Scrum cuyos miembros están repartidos en distintas ubicaciones geográficas del mundo.

Durante el almuerzo, Marcus reconoció que los equipos ágiles Scrum distribuidos afrontan muchos retos habituales. Entre los problemas concretos que mencionó sobre su proyecto estaban:

• Diferencias en los estilos de trabajo de los miembros,
• Diferencias horarias,
• Desajustes culturales y
• Limitaciones lingüísticas.

Pese a estas dificultades, Marcus añadió que gestionar un proyecto con el proceso ágil Scrum resulta más divertido, productivo y enriquecedor que nuestra forma de trabajar hace 20 años. Comparado con los días en que trabajábamos sin los procesos Scrum de desarrollo y entrega de software.

Su afirmación era un gran testimonio a favor del marco Scrum, procedente de un gerente, Scrum Master y Product Owner de amplia experiencia y trayectoria.

¡Gracias, Marcus!

Entonces le explicamos uno de nuestros antiguos proyectos, anterior a la adopción del marco Scrum. Estoy segura de que muchos Scrum Masters reconocerán experiencias similares en sus proyectos anteriores a la obtención de sus certificaciones.

A finales de la década de 1990, formábamos parte de un grupo de ingeniería de software que desarrollaba una infraestructura de clave públicabasada en tarjetas inteligentes. Estas protegían de forma segura las claves privadas de los miembros de la infraestructura; las claves públicas asociadas y los certificados que las contenían se distribuían abiertamente, como indica su nombre.

En aquella época, era de por sí un proyecto de TI relativamente complejo que requería varios equipos interdependientes de ingeniería de hardware y software. Tuvimos que realizar grandes esfuerzos de investigación y desarrollo (I+D) para construir un sistema de hardware y software plenamente funcional.

Recuerda que en ese proyecto aún no utilizábamos el concepto de producto mínimo viable (MVP) para experimentar, crear, aprender y volver a experimentar.

Crear sin Scrum una infraestructura tan sofisticada, formada por numerosos componentes de hardware y software, era todo un reto.

Estos son tres grandes contratiempos que sufríamos al no contar en nuestros equipos con Scrum Masters ni con nadie que tuviera una certificación Scrum Master.