Monthly Archives: junio 2011

Potenciación de equipos (parte III)

Al fin llega la tercera parte de la charla de Potenciación de equipos. Vamos allá.

Para que un equipo esté equilibrado y dependa lo menos posible de personas externas a él que puedan convertirse en un obstaculo o un cuello de botella,  cada uno de estos roles deben identificarse para ejercitarlos y desarrollarlos entre todos los miembros del equipo.

  • Coordinador: Coordina los esfuerzos de todos para alcanzar metas, aunque no ocupe el cargo de líder. Hay que evitar que una misma persona mantenga este rol durante mucho tiempo y se recomienda que se vaya rotando entre todos los miembros del equipo.
  • Impulsor. Está lleno de energía, “empuja” a los demás para avanzar en el trabajo. Su optimismo y decisión para afrontar los retos hace ver al resto que cualquier cosa es posible.
  • Creador. La persona creadora está llena de ideas,es fuente de propuestas y sugerencias originales y sencillas. Es importante que esta persona entienda perfectamente el ámbito del problema para que saque su máximo potencial.
  • Evaluador. Analiza las ideas presentadas, valora sus pro y sus contra, proporciona instrumentos de análisis. En las reuniones se puede ver frecuentemente debates entre el creador y el evaluador que puede suelen acabar en soluciones muy buenas.
  • Realizador. Es el organizador práctico que transforma las decisiones y estrategias en tareas definidas y realizables, que los miembros del equipo puedan manejar. Es el que tiene más claras las tareas en las que se descompone una historia de usuario y su papel es fundamental para plasmarlas en el kanban.
  • Investigador. El que aporta ideas del “exterior” de la organización, su papel principal es evitar que el equipo se quede estancado. A veces se confunde con el “creador” pero, a diferencia de este, no aporta ideas originales, sino conocidas por sus lecturas, observaciones, u otras fuentes externas. Es el samurai del google, no hay ejemplo de código fuente  o solución a un problema que se le escape.
  • Comunicador. El más sensible para identificar necesidades e inquietudes de los demás miembros.. Su instinto lo lleva a crear ideas en los demás, sirve de “puente” en el manejo de conflictos. Ayuda a disolver las discusiones entre dos personas que no entienden sus posturas entre sí, explicando a cada uno el punto de vista del otro.
  • Detallista. Se preocupa por lo que puede estar mal hecho y por los detalles para asegurarse de que  nada se ha pasado por alto. Ayuda mucho en las revisiones finales de las historias de usuario porque siempre detecta el problema que a todo el mundo se le ha escapado.

El tema del lider en un equipo ágil siempre es tema de debate. ¿Tiene sentido un lider en un equipo autogestionado? Yo creo que siempre es útil una persona cuyo objetivo sea hacer lo posible para que el equipo sea productivo, esté unido y contento con su trabajo.

Esto requiere una serie de funciones:

  • No dice qué hacer, pregunta. Encuentra las preguntas adecuadas para provocar las ideas en el equipo.
  • Alienta la creatividad. No reprocha los fracasos ni las ideas extrañas. Lo contrario podría llevar a  que se los miembros de equipo autolimiten en sus ideas para prevenir “broncas”. Todas las ideas son analizadas y evaluadas sin descartarlas por adelantado
  • Alienta la participación. Todos los del equipo deben participar. El lider debe estar atentos a personas que no hablan, normalmente esta falta de palabras indica falta de entendimiento.
  • Propone mejoraas (coach). Investiga en metodologías y las propone al equipo. Intenta mejorar el número de puntos a realizar por sprint.
  • Les incluye en las decisiones que les afectan, por ejemplo, participan en la selección de personal que formará parte del equipo.
  • Evita impedimentos (papel del Scrum Master)
  • Se asegura que el equipo técnico este siempre en funcionamiento
  • Se come las reuniones innecesarias para el equipo, las que no les aporta visión de producto.
  • Hay una que no comenté en la reunion de Agile Alicante pero salió el tema en la cena posterior. El lider debe aislar al equipo de las tensiones que puede haber en el resto de la empresa. Debe hacer de escudo de toda la negatividad para que el clima en el equipo de desarrollo sea favorable a la creatividad y la calidad técnica.

Antes de terminar quisiera recomendar dos libros que me han encantado y que hablan de la psicología del equipo son dos:

Management Rewired (del que ya hablé en otro post)
Peopleware. No se puede llevar un equipo de desarrollo sin leerlo.

Potenciación de equipos (parte II)

Después de una semana mortal de trabajo vuelvo a estar en posesión de mi tiempo. Voy a continuar con la exposición que di en la sesión de Agile Alicante el 13 de Mayo. Puedes ver la primera parte aquí.

Cuando trabajamos con un equipo, ya sea de desarrollo de software o en otros entornos, no hay que olvidar que este equipo tiene una serie de necesidades. Prestar atención a cada una de ellas es importante como lider de équipo para desarrollarlo y sacar el mejor partido de él.

Si queremos que el equipo esté motivado, que sea capaz de juntar su esfuerzo con el de los compañeros para conseguir un objetivo común, no hay que olvidar que todos los miembros deben tener una visión global y clara de ese objetivo. El Product Owner es el responsable de que el equipo tenga una visión de alto nivel del producto a desarrollar. Con visión de alto nivel me refiero a que hay que evitar el dar visiones parciales sólo a los desarrolladores que van a realizar cada pequeña parte. Cuando el equipo conoce perfectamente qué tipo de software va a realizar, quién van a ser los usuarios, cual es la competencia,etc..  se produce la verdadera generación de ideas que hace de un producto algo innovador y de gran calidad.

Un error común que se suele cometer, es que los desarrolladores sólo conocen los problemas del software ya son los que tienen que resolverlos o ayudar a resolverlos. Sin embargo, elementos como el número de horas sin incidencias, el número de usuarios concurrentes que lo han usado sin causar saturación u otros elementos positivos, normalmente no llegan a oidos de los desarrolladores. Estos elementos positivos son un potente aglutinador que mantiene al equipo unido y motivado y con fuerzas para superar nuevos retos.

El entorno fisico en el que trabaja el equipo tiene mucho que ver con cómolos miembros se sienten parte de ese equipo . Los cubículos que aun parece que se usan en algunos entornos hay que descartarlos completamente. La ubicación de los puestos de trabajo debe fomentar una colaboración directa cara a cara. El equipo además debe disponer de una zona común para realizar el daily, juntarse para analizar los problemas, … Sin embargo no hay que olvidar que el trabajo tambien requiere concentración. El equipo debe disponer de elementos  para indicar que un miembro está en estado de concentración. Quienes conocen la técnica pomodoro sabrán que es importante que durante los 25 minutos de trabajo intenso no se reciba interrupciones. Hace poco descubrí el CherryTomato que marca en el skype con el estado “Do Not Disturb” durante el tiempo del pomodoro. Esto sirve para que el resto del equipo sepa facilmente si  es momento de hacerte las preguntas o si se las apunta para después.

El equipo además necesita de elementos de gestion visual. El kanban es un buen elemento para que se auto-gestionen el progreso de los proyectos y se asignen el trabajo a sí mismo. Les permite encontrar los cuellos de botellas y resolverlos ellos mismos.

El equipo debe ser multidisciplinar y multinivel. Esto no quiere decir que cada miembro del equipo debe ser multidisciplinar y dominarlo todo sino que las especialidades combinadas de los miembros forma la capacidad de equipo que los proyectos necesitan. Tampoco hay que ver a los miembros como clones entre sí sino cada uno puede tener distintas capacidades, personalidades y necesidades. Esto último normalmente se omite cuando se piensa en un equipo. Puede haber un miembro que necesite doble monitor mientras que otro necesite una impresora cerca. Aunque cada miembro trabaje primero en la parte que más conoce y controla, esto no quita que si ha acabado su parte  y quedan tareas pendientes para finalizar el sprint, se arremangue y las realice evitando así cuellos de botella. Hay que buscar la parte buena de la especializacion evitando que ocurra la negativa.

La semana que viene espero terminar la charla escrita.