Work Expo, una actividad para conocer los equipos

El equipo cambiante

Vivelab Bogotá es un Living Lab creado por la Universidad Nacional de Colombia, el ministerio de las  TICs y la alcaldía mayor de Bogotá. Somos el laboratorio abierto de los ciudadanos, trabajamos en una amplia variedad de proyectos, desde desarrollo de software hasta pruebas de usabilidad y hackatons.

Al trabajar en diferentes proyectos los equipos cambian constantemente. Existe un equipo base que frecuentemente se expande dependiendo de las necesidades de los proyectos; por esto ver nuevas caras entre rostros familiares es un escenario muy frecuente. Estos nuevos equipos trabajan tanto en proyectos antiguos cómo en nuevos proyectos.  Es dificil mantener informadas a todas las personas sobre quienes están trabajando ahora en el Vivelab,  esto debido a que no todos los equipos interactúan entre ellos.

Work expo

Para trabajar en este problema usamos el ejercicio “Work Expo”, el cual se explica en el libro #Workout ( https://management30.com/product/workouts/how-to-find-purpose-in-your-organization/ ). En nuestra versión de la actividad cada persona debe realizar un dibujo que responda las siguientes preguntas:

  • Por que se encuentran trabajando en el Vivelab y no en otro lugar?. Las respuestas a esta pregunta nos ayudan a saber qué debemos hacer para convertirnos en un lugar feliz para trabajar e incentivar a más gente talentosa a trabajar con nosotros.
  • Que hacen en el Vivelab?. Este es el momento de presumir, de mostrar a todos que hacemos y por qué es importante para la organización tenernos en sus equipos.
  • La exposición: Una vez todos han terminado su obra maestra la expondrán en su estación de trabajo, mientras el grupo de espectadores realiza un recorrido por cada escritorio y escucha la exposición del autor. Esto nos ayuda a crear una relación entre lo que la gente está diciendo y el sitio donde podremos encontrarlos.

Sight_2015_09_02_180853_037Los resultados fueron bastante interesantes, y siendo honestos bastante motivadores.  La mayoría del equipo base expresó cómo su mayor motivación el entorno laboral del Vivelab, algo en lo que ponemos bastante empeño. Los nuevos integrantes se encuentran emocionados de conocer nuevas formas de trabajar y un estilo diferente de proyectos. Todas las personas tuvieron la oportunidad de mostrar qué hacen y pasar un buen rato explicandolo.  Y ya que las presentaciones fueron hechas en cada puesto de trabajo, nos ayudaron a reconocer quienes son las personas que vemos cada día.

Conclusiones

Sight_2015_09_02_180905_909

Es bastante dificil mantener un ambiente que sea familiar y desafiante al mismo tiempo.Cuando el equipo cambia, y esto ocurre con más frecuencia de la que quisiéramos, es importante recordarnos por qué aún seguimos trabajando aquí y cuales son las motivaciones que mueven a las personas. El ejercicio “Work Expo” nos dio la oportunidad de hablar a todo el equipo y escuchar lo que cada uno tenía por decir. Repetiremos esta actividad en el futuro, cuando los equipos y proyectos cambien de nuevo, o tal vez incluso si no lo hacen. Porque tal vez seamos las mismas personas pero nuestras motivaciones siempre están en movimiento.

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í.