Introducción
La intención de este artículo es describir los obstáculos para la implementación de Scrum en proyectos realizados para el gobierno Colombiano, y plantea posibles formas de abordarlos para disminuir su impacto. Las observaciones que aquí se realizan parten de la experiencia adquirida por el Vivelab Bogotá, pero es posible replicar estos resultados en contextos similares.
Obstáculos para el Agilismo en el Gobierno
Los proyectos del Gobierno tienen un desarrollo que encaja en el modelo de cascada, con unas fases muy bien definidas y secuenciales típicas de este tipo de metodologías. Las etapas de este proceso están controladas por procesos de calidad estrictos que limitan el espacio de experimentación y fomentan estructuras jerárquicas verticales donde los procesos son más importantes que las personas y sus interacciones. Esto dificulta la inclusión de prácticas Ágiles para el manejo de proyectos y genera una serie de obstáculos para un equipo de personas que desea trabajar de esta forma. A continuación se describen algunos de ellos:
- Uno de estos obstáculos es la documentación rígida que dificulta la colaboración con el cliente. Existe una etapa inicial donde se generan documentos de requerimientos que son asumidos como compromisos por el equipo de desarrollo, dichos compromisos se adquieren en uno de los momentos de mayor riesgo, esto debido a las propiedades del cono de incertidumbre que describe cómo la certeza respecto a los estimados del proyecto aumenta durante el desarrollo del mismo . Esto ocasiona que el producto se cree atado a una serie de requerimientos que pueden perder validez durante el proceso de desarrollo, pero al estar sujetos a planes ya aprobados se dificulta colaborar con el cliente para ajustarlos. La gran rigidez de estos documentos es ocasionada por las múltiples leyes que los cubren y los diferentes sistemas de control que tienen como función verificar su cumplimiento.
- La inclusión de sanciones y problemas legales eleva lo que está en juego y genera una fuerte tendencia hacia seguir el plan sobre favorecer los cambios. Los proyectos se ejecutan por medio de un convenio o contrato en el cual se especifican las cláusulas de incumplimiento, y este incumplimiento ocurre cuando no se entregan los requerimientos especificados al inicio del proyecto. Esta tendencia termina dañando el producto, se busca jugar a lo seguro, no se da el espacio para experimentar por miedo a dichas cláusulas de incumplimiento.
- La infraestructura suele ser bastante cerrada debido a razones de seguridad, por ejemplo los servidores no pueden ser accedidos de forma fácil desde equipos ubicados fuera de sus instalaciones. Esto dificulta enormemente la ejecución de pruebas y la entrega de un producto funcional al final de cada iteración.
Estos factores generan un ambiente con bastantes retos para el Agilismo, pero las mismas prácticas que se utilizan en otros ambientes también pueden ser efectivas en este. En la siguiente sección se hablará un poco de estas herramientas.
Herramientas para la construcción de confianza
Uno de los elementos en juego es la falta de confianza entre los involucrados, que se refleja en la rigidez de los contratos. La confianza entre la entidad gubernamental y el equipo de trabajo se puede construir, algunas herramientas que pueden ayudar a este cambio son las siguientes:
- Demostrar el avance del proyecto con un producto funcional al final de cada iteración. Esto ayuda enormemente a la relación, ya que permite pasar de supuestos a un producto sobre el cual se puede probar y que exhibe el trabajo y compromiso del equipo. Para lograr esto de forma consistente es importante usar Integración Continua, ya que permite al equipo de trabajo demostrar el valor que se ha construido en el producto. Y teniendo en cuenta que existen obstáculos en la infraestructura, el disponer de una forma rápida y precisa de generar software que pueda ser probado es crítico.
- Negociar el alcance de diferentes elementos del proyecto. Existen diferentes herramientas, con su respectivo marco legal, que permiten ajustar la definición del proyecto. Estas herramientas dependen del tipo de contrato que se está manejando, pero considerando lo pesado que puede ser este proceso, es probable que las partes involucradas generen resistencia a estos cambios. Al demostrar el valor generado favoreciendo el cambio en lugar de seguir estrictamente el plan, se abre un espacio para negociar y hacer del proyecto una relación en la que todos ganan.
- Lean UX. Mediante ejercicios de sketching, prototipado y diseño participativo, se logra apropiar conceptos cómo la respuesta al cambio y se transmite la idea de que las funcionalidades del producto son algo emergente y que tratarlos de forma monolítica puede disminuir la calidad del resultado final. Por ejemplo, al presentarse el listado de requerimientos del producto, puede generarse una sesión de sketching entre los interesados. El objetivo de esta sesión será diagramar las interfaces que se usaran, pero durante este proceso se valida la funcionalidad y se crea un conocimiento compartido entre el equipo de trabajo y las personas interesadas en el proyecto. El trabajo de esta sesión es implementado durante la iteración y el producto que se genera durante este tiempo se presenta de nuevo a las personas involucradas. Generando esta dinámica de trabajo y creando transparencia, se está dando una razón clara del por qué hacer las cosas de una forma diferente y cómo esto puede llevar a mejores resultados. Adicionalmente se involucra a los funcionarios en el proceso de creación, lo cual genera un mayor sentido de pertenencia frente al producto y al equipo que lo desarrolla. Los involucrados pasan de ser un agente externo que influye en el proyecto a ser parte del equipo responsable de generar el mejor producto posible.
Trabajando en un ambiente de confianza es posible realizar cambios sobre los productos que fueron aprobados tiempo atrás. En este ambiente se confía en que cada miembro del equipo tiene las habilidades necesarias para realizar las actividades del proyecto, y la responsabilidad y el compromiso para llevarlas a cabo de forma transparente.Una estrategia efectiva para atacar este problema consiste en negociar sobre los criterios de aceptación de cada ítem, esto hace posible que se reduzca el trabajo necesario para completar algunas de las cosas y aprovechar ese esfuerzo en nuevos ítems que se han descubierto.
Conclusiones
Las recomendaciones y comentarios mencionados hacen referencia a las experiencias de un equipo de trabajo específico, realizando una serie de proyectos con entidades gubernamentales. Cada proyecto tiene sus propias características que pueden facilitar o dificultar la experimentación con las recomendaciones aquí mencionadas. Lo realmente importante es cómo se aborda el problema y la actitud con la que se enfrenta. Estos son los factores que permiten que se de un ambiente favorable para la introducción de prácticas ágiles en el trabajo con el Gobierno. Es un trabajo difícil, pero no es exclusivo de este ámbito y por lo tanto no debe ser una razón para escatimar esfuerzos que permitan que se hagan mejor las cosas a este nivel.
En nuestro país estamos en la lucha de educar a los clientes sobre los enormes beneficios de trabajar con enfoques ágiles y siendo optimista creo que esto va en buen camino 🙂 por otro lado no podría estar mas de acuerdo en que el agilismo en el gobierno es todo un reto sobre todo el como establecer canales para la creación de confianza cuando los proyectos ya tienen definido costos alcance y tiempo en un claro ganador perdedor