Asignación de roles en Scrum - 1 de ∞: El Equipo

Introducción

Convocatoria: Asignación de roles en Scrum - 13º Encuentro Ágil Barcelona

Asistentes:

• Jordi Rubio - Dpto. de consultoría del Grupo Intercom - empezando a implantar metodologías ágiles en distintas empresas del grupo.
• Iván - Programador en NetQuest - focalizado en elos aspectos ágiles de la ingeniería.
• Albert Pumpido - Empresa de consultoría web 2.0/comunidades - estudiando las técnicas ágiles, tratando de pasar de la teoría a la práctica.
• Jaume - Consultoría técnica en tecnologías Microsoft; responsable de I+D+i - buscando como ayudar a los equipos que empiezan: aprender para enseñar.
• Pedro - Responsable de tecnología en una empresa de comunidación, con foco en los aspectos de gestión. Utilizanso agile.
• Juan - Responsable de sistemas - aprendiendo sobre la gestión del desarrollo, sin intención de aplicarlo a corto plazo.
• João Gama - Desarrollador de aplicación para soportar proyectos ágiles (entra en beta hoy, yay João!)
• Xavi Albadalejo - Agile Coach en Indra (felicitaciones por el nuevo rol!)
• Bea - En DoubleYou, intentando implantar metodologías ágiles en la empresa - identificar soluciones a algunos problemas que está teniendo (muchos proyectos pequeños compitiendo por recursos limitados)
• Jordi Salvat (Escribano) - CTO en Salir.com - dirigiendo (manager & coach) un equipo de desarrollo ágil (Scrum+…)

Tras las presentaciones, iniciamos la sesión haciendo "brainstorming" de posibles puntos de discusión, y votándolos a mano alzada, sin límite de votos por persona. Los resultados, en la foto adjunta.

Sigue una transcripción 'ad libitum' de la discusión. Se invita a los participantes a añadir/editar según crean conveniente.

1. El Equipo

1.1. Capacidades y cualidades

Cualidades que tiene que tener un trabajador de un equipo ágil:

• Perogrullada: capacidad de trabajar en equipo.
• Capacidad de comunicación.
• Ganas de ayudar.
• Ganas de aprender.
• Humildad.
• Aportación clave de Xavi: capacidad de llegar a consenso.
  • Este artículo es interesante: [http://www.proyectosagiles.org/skills-equipo-agil]
  • Abierto de mente. Flexible. NO intransigente.
  • Se añade: capacidad de llegar a consenso _y de ejecutar según lo decidido_.
  • No vale aceptar el consenso y luego no contribuir a ejecutarlo. El saboteador es el caso extremo.
  • Posible impedimento: falta de transparencia, que lleve a aceptar verbalmente el consenso sin estar realmente de acuerdo. Puede tener causas dentro o fuera de la persona misma [e.g. falta de seguridad para expresar libremente su opinión].

En este momento de la reunión resulta evidente que no queremos (ni podemos) cubrir ni siquiera los 3 temas más votados. Ante la opción de cubrir mucho terreno o profundizar más, elegimos la 2ª y decidimos pasar a otros aspectos relacionados con el equipo.

1.2. Disfunciones

• Qué pasa si no se llega al consenso?
  • El "jefe" puede pegar un puñetazo en la mesa y decidir. Este es el último recurso e indica que se ha fallado. El equipo no es autogestionado.
  • Se puede usar Timeboxing para acelerar el consenso.
    • Caso especial: convocar las reuniones a las 13:00.
• Y si sucede recurrentemente que no se puede llegar a consenso?
  • Eso es que no tenemos un equipo, sino un grupo de trabajo.
  • Como transformar un grupo en un equipo?
    • Tener un objetivo común.
    • Decisiones compartidas.
    • Ser partícipe del éxito o del fracaso conjunto.
• Y si un miembro del equipo no cree que el proyecto pueda tener éxito?
  • Podemos definir sub-objetivos que si se vean factibles. Scrum lo hace definiendo sub-objetivos por iteración.
  • Esto es un parche, pues haciéndolo se pierde la creatividad del equipo de cara al objetivo final.
  • Pero el éxito repetido en los sub-objetivos ayudará a cambiar la percepción de esos escépticos.
• El cliente tiene que estar involucrado con el equipo. El chiste del cerdo y el pollo es el peor aspecto de Scrum.
  • (Nota sobre el orígen de Scrum: The New New Product Development Game)

1.3. Roles dentro del equipo

• Scrum no define roles dentro del equipo, pero exige que sea multidisciplinar.
  • Esto signfica que tenga todo el conocimiento necesario para ejecutar el proyecto sin (o con pocas) dependéncias externas.
• También pide que todo el mundo participe ("everybody chips in").
  • Requiere que a nadie se le caigan los anillos.
  • Requiere sacrificar la eficiencia en pro de la eficacia. El objetivo es obtener resultados pronto, no tener todos los recursos ocupados.
  • Debido a las diferencias en especialización (conocimientos y capacidades), esto es utópico: no todas las tareas pueden ser acometidas por cualquier miembro del equipo.
  • Siendo utópico:
    • Es bueno.
    • Es una utopía que hay que perseguir.
      • Hasta el punto de forzar tareas que no són la especialidad?
        • El equipo puede decidir tomar esta actitud de aprender y que cada uno trate de coger tareas que van un poco más allá de sus capacidades actuales.
    • Así se fragua el equpo. [N.d.E.: buena traducción de "jell". Grácias!]

Retrospectiva

• Puntuación global: 7,1
• A mejorar: el tema era enorme; tendríamos que haber subdividido los sub-temas ganadores; alguno se ha sentido perdido durante la votación.
• Bien: se agradece la moderación/escribanazgo (de nada).

Para definir próximos temas:

• Bea listará los temas generados durante el brainstorming de hoy.
• Los añadiremos a la página de [Próximos temas para los encuentos en Barcelona]
• Borraremos las listas de interesados, por considerarse excesivamente antiguas (tanto el grupo como los indivíduos hemos evolucionado mucho desde entonces).
• Pediremos en la lista que los interesados se apunten de nuevo.
• Condicionado a que haya voluntarios para prepararlos, trataremos de elegir los temas con más gente interesada.

Safareig

• 4 de los 10 asistentes piensan asistir al Agile Spain 2010. :-)
• A otros 2+ les gustaría, pero no pueden por falta de medios y/o tiempo. :-(
• El programa se ve super-interesante. Henrik Kniberg de keynote speaker!