Trabajando con Metodologías Ágiles en el Gobierno

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.

Llamado de sesiones para Agiles 2015

El Equipo Organizador de Ágiles 2015 te invita a participar del evento como expositor. La Comunidad Latinoamericana de Metodologías Ágiles quiere escuchar tus ideas, experiencias y aprender de las técnicas que utilizas para trabajar.

Envío de propuestas

Las propuestas se envían mediante el sistema gestión de propuestas de la conferencia: http://sesiones.agiles.org/.

A la hora de enviar tu propuesta debes indicar:

  1. Título: es lo primero que se ve de la propuesta y como es costumbre la primera impresión tiene una gran valor, por eso piensa bien el título procura que sea descriptivo y al mismo tiempo atractivo.
  2. Descripción corta: esta es la descripción que aparecerá en el programa, debes ser preciso ya que durante la conferencia esta información será clave para que la gente decida o no asistir a tu sesión
  3. Temática: ver sección Tracks y Temáticas
  4. Audiencia: cual es el nivel de conocimiento que debería tener la audiencia de tu sesión respecto del tema de la misma
    1. Principiantes: gente que no conoce o que recién está dando sus primeros pasos en la temática
    2. Practicantes: gente que ya está familiariza con la temática, entiende los fundamentos y los ha llevado a la práctica
    3. Expertos: gente que domina ampliamente el tema y busca innovar en la temática
  5. Tipo de sesión:
    1. Presentación (lecture): el orador presenta un tema, generalmente usando diapositivas y en un momento de la sesión da la oportunidad a que la audiencia haga preguntas. Duración: 45 minutos.
    2. Reporte de experiencia (experience report): el formato es análogo a la presentación pero aquí el contenido consiste en la presentación de una caso real de aplicación. Duración: 45 minutos.
    3. Taller (workshop): es una sesión de tipo interactivo, donde hay una gran participación de la audiencia. Duración: 90 minutos o 180 minutos
  6. Límite de participantes
  7. Link al video de invitación a la sesión: debe grabar un video de 3 minutos máximo explicando tu propuesta e invitando a la comunidad a participar de tu sesión. El video debe estar subido a la nube (YouTube, Vimeo o el servicio que gustes) y debes asegurarte que sea accesible de públicamente.
  8. Descripción completa: aqui tienes la posibilidad de explayarte detalladamente sobre el contenido y la dinámica de la sesión. También puede incluir en este campo cualquier otra información que consideres necesaria/apropiada compartir con los revisores y los responsable de la organización del evento.

En caso de consultas puedes escribirnos a sesiones2015@agiles.org.

Mientras esté abierto el CFP podrás actualizar tu propuesta cuantas veces quieras.

Puedes enviar cuantas propuestas desees, pero solo una sesión por individuo será aceptada en el programa final

Proceso de feedback y revisión

Como es costumbre en nuestra comunidad, podrás recibir feedback de tus pares en cualquier momento, ya que todas las propuestas presentadas estarán visibles para toda la comunidad.

Adicionalmente si envías tu propuestas antes del 11 de Mayo, el equipo de revisores te dará feedback formal de cara a que puedas mejorar tu propuesta y así aumentar la chances de que la misma sea seleccionada para formar parte del programa de la conferencia.

Tracks y temáticas

Esperamos propuestas de sesión en marcadas en los temas listados a continuación. Asimismo para facilitar la coordinación de revisores y el posterior armado del programa de la conferencia, hemos agrupado los distintos temas en 3 tracks. Cada track es en sí mismo una temática de alto nivel que contará con su propio equipo de evaluadores y un coordinador.

  • Track de gestión, coordinador: Fernando Guigou
    • Enterprise Agile
    • Liderazgo y aprendizaje
    • Cultura y colaboración
  • Track técnico,  coordinador: Nicolás Paez (@inicopaez)
    • DevOps & Entrega continua
    • Prácticas de desarrollo y pruebas automatizadas
    • Experiencia de usuario
  • Track complementario, coordinador: Hiroshi Hiromoto (@hhiroshi)
    • Uso de agile fuera del desarrollo de software
    • Innovación
    • Startups & Emprendimiento

Fechas importantes

  • Apertura del llamado para presentar propuestas : 20 de Marzo
  • Fecha límite para envio de propuestas a recibir feedback formal: 11 de Mayo
  • Cierre del llamado para presentar propuestas: 1 de Junio
  • Notificación de propuestas aceptadas: 1 de Julio
  • Fecha límite para confirmar la participación: 15 de Julio
  • Publicación del programa: 1 de Agosto

MAYOR INFORMACIÓN, PUBLICACIÓN ORIGINAL Y ACTUALIZADA: Click aquí.

Buenas retrospectivas = equipos en mejoramiento constante

Por Leonardo Agudelo (@sweepnoise)

Buenas retrospectivas = equipos en mejoramiento constante

 

Desde hace algunos días he tenido la oportunidad de facilitar retrospectivas de varios equipos y la experiencia obtenida merece ser compartida.

Los equipos a los que facilité la retrospectiva no necesariamente tenían como costumbre hacerlas con una frecuencia definida, otros tenían bastantes problemas cuando las realizaban y otros ya no las hacían… en fin… había necesidad de cambiar la estrategia.

Me basé en la estructura recomendada en el libro “Agile Retrospectives: Making good teams great” para planear las retrospectivas, la cual cuenta con los siguientes puntos:

  1. Preparar el escenario: lograr que las personas se focalicen en los objetivos de la reunión, en el tiempo estipulado y con una dinámica productiva.
  2. Conseguir datos: lograr una visión común de la situación a analizar, tanto con datos objetivos como subjetivos. Es la base común de hechos, eventos, sentimientos que permitirá tener una comunicación efectiva el resto de la reunión.
  3. Generar entendimiento profundo: entender el por qué, tanto de lo que anduvo mal como de lo que anduvo bien. Ir más allá de la primera apariencia, para encontrar las causas profundas que hay que sostener y mejorar o cambiar.
  4. Decidir qué hacer: teniendo una lista de posibles experimentos que el equipo puede realizar para mejorar, es el momento de elegir, ya que no todo se puede hacer para el siguiente sprint.
  5. Cierre: finalizar claramente la retrospectiva, con una nota positiva y ganas de realizar los experimentos que se encontraron.

Complementé estos pasos con otros dos que me recomendó un entrenador muy reconocido en el continente (Alan Cyment):

1.1 Revisar los compromisos adquiridos en la retrospectiva pasada

2.1. Priorizar los datos

Estos dos puntos adicionales me parecen vitales, ya que por un lado es una mala práctica (o antipatrón) de retrospectiva no revisar los compromisos adquiridos en retros anteriores, y tratar de cubrir todos los temas que afloran en medio de la retrospectiva es ineficiente.

Usé en cada una de las etapas de la retrospectiva actividades o dinámicas que facilitan e incentivan la participación de los miembros del equipo. Me parece que se pueden recomendar las siguientes:

Para preparar el escenario: la actividad “Histograma de satisfacción” . Cada participante selecciona el nivel de satisfacción en el sprint que termina desde un punto de vista general y lo explica al resto del equipo. Los niveles son:

  • 5-  Somos los mejores del mundo! Qué gran equipo que somos!
  • 4- Estoy orgulloso de ser parte del equipo y de cómo trabajamos.
  • 3- Bastante satisfecho, trabajamos bien juntos la mayoría de las veces.
  • 2- A veces estoy satisfecho, pero pocas.
  • 1- Estoy disconforme y poco satisfecho con el nivel de trabajo en equipo.

Se debe revisar el avance 2 o 3 iteraciones después

Nota: para esta actividad es importante tener un timebox de 2 minutos para que cada explique lo que lo llevó a elegir su nivel, de lo contrario se convierte en el paso 2 de la estructura de retros, que es conseguir datos.

Para Conseguir los datos: me pareció muy buena la actividad Mad, Sad, Glad (Enojado, Triste, Alegre), en esta actividad cada participante identifica en 7 minutos todos los momentos que le causaron esas sensaciones y los escribe en postit, (uno por postit), luego los expone al grupo. Esta actividad promueve el uso de frases “Yo”, ya que pone de antemano el sentimiento que le generaron al participante diferentes situaciones o momentos durante el sprint y evita el señalamiento y atribución de culpas.

Nota: los mensajes “YO” son así:

Cuanto tu (establezca el comportamiento)
Me siento (establezca el sentimiento)
Entiendo lo que sientes (empatice con el otro)
Porque (establezca consecuencia)
Te pido el favor de (establezca la petición, negocie el cambio)

Para generar entendimiento profundo: ensayé dos formas, la técnica de 5 por qué’s, la cual facilita la búsqueda de las causas reales de un problema al preguntarle al grupo ¿Por qué? reiterativamente, se supone que tras 5 respuestas ya hay un entendimiento más profundo. Esta técnica es buena, pero me pareció mejor la espina de pescado (diagrama de Ishikawa), esta permite hacer un análisis causal sin perder de vista algunos aspectos de la discusión que se pierden fácilmente con la técnica de los 5 por qué’s. Es muy importante que el equipo ponga los porcentajes de aporte al problema de cada rama del diagrama.

Para decidir qué hacer: la mejor forma que he visto es una lluvia de ideas en parejas. En un timebox (pueden ser 7 minutos) se proponen actividades concretas, que se puedan asignar a alguien en el siguiente sprint. Luego de los 7 minutos cada pareja explica las propuestas y se van agrupando si se refieren a lo mismo que las propuestas de otras parejas. Finalmente se permite que cada persona vote por las ideas que más le gustan. A cada participante se le dan 5 puntos, los cuales pueden ser distribuidos como quiera entre las propuestas. Las 3 o 4 propuestas que tengan más votos serán las que el equipo se asigne.

Es muy importante que las actividades ganadoras tengan un doliente que se encargue de que sucedan (no necesariamente son quienes las ejecutan).

Para el cierre: ha funcionado bien una sesión de agradecimientos, donde cada persona le expresa al resto del equipo a quién le agradece y por qué.

Estas actividades han dado muy buenos resultados, pero es muy importante variarlas, en la siguiente dirección se pueden obtener cerca de 2 millones de retrospectivas diferentes: http://www.plans-for-retrospectives.com/index_es.html , esto es, contando las posibles combinaciones de diferentes actividades para cada etapa. Así que no hay excusas para no variar las retros.

Una ventaja para resaltar al usar la estructura propuesta es que con ciertas actividades hay mayor participación de personas que nunca participaban en las retros con otra estructura, alguna vez alguien me dijo “… este nunca hablaba…”, lo cual es bastante gratificante.

Otra cosa que me parece muy buena es que el mismo equipo es el que logra identificar sus problemas y proponer las soluciones, como facilitador solo aporto cuando veo que hay un concepto de agilismo que no está totalmente claro, y así yo crea que tengo la solución para un problema que viven ellos, me lo guardo y espero que encuentren sus propias soluciones. La tentación es grande, porque solemos creer que tenemos la respuesta para todo, pero los mismos equipos son los que sufren los problemas y ellos deben encontrar sus salidas, creo que esto fortalece la noción de autogestión y de compromiso del equipo, parte esencial de los equipos de alto desempeño.

Me parece que hay un riesgo que se debe manejar y es que las actividades que se eligen y para las cuales queda alguien responsable no se lleven a cabo. Cuando esto sucede la sensación en la siguiente retrospectiva puede ser que no sirve para nada hacer la retro. Para mitigar esto es bueno poner las tareas en el tablero Kanban, tal como las actividades de desarrollo y no perderlas de vista durante el sprint.

Como siempre digo en los entrenamientos, si un equipo no hace retrospectivas es como si dijera: “Somos perfectos, ya no hay nada que podamos hacer para mejorar”, lo cual es una mentira. Siempre hay forma de mejorar, de buscar la excelencia, de permanecer en el camino de la mejora continua.