Archivo de la categoría: Productividad

Características de la comunicación de equipos de alto rendimiento

Hay multitud de vídeos, libros, artículos en Internet que hablan de los equipos de alto rendimiento. ¿Qué son? ¿Cómo se definen? ¿Qué los diferencia del resto? Y casi lo más importante. ¿Cómo un equipo puede llegar a serlo?

En el Laboratorio de Dinámicas Humanas del MIT han estudiado multitud de equipos y han identificado qué características de comunicación tienen. Estas características se observan en equipos que tienen gran creatividad y trabajan con gran energía y compromiso por encima de cualquier otro equipo. Estas características son observables, cuantificables y pueden usarse para ayudar a equipos a mejorar, enfocándose en sus flujos de comunicación.

La comunicación de los equipos se puede ponderar usando tres categorías principales.

  • Energía

La energía de comunicación es lo que también se llama ancho de banda.  En esto interviene mucho el medio que usen los miembros para comunicarse entre sí.  El medio de comunicación con más energía o ancho de banda es una conversación cara a cara. Cada interlocutor observa los gestos y el lenguaje corporal, oye e interpreta la entonación con la que dice cada frase además de entender el contenido del mensaje en sí mismo.  Después de éste, pasaríamos a usar la videoconferencia en la que no podemos ver por completo a la persona con la que hablamos al estar limitados a una pantalla. Después de los medios audiovisuales tendríamos los medios de comunicación de sólo voz como el teléfono. En ultimo lugar tenemos sistemas de mensajería asíncronos como los correos electrónicos . En estos últimos son en los que más malinterpretación hay por lo que se gasta mucho tiempo en ser exhaustivos en su escritura y aún así no consigue transmitir correctamente el mensaje.

Un equipo de alto rendimiento hace uso de canales de comunicación de gran energía. Conversan hablandose cara a cara para transmitir la información en el menor tiempo posible y disminuyendo los malentendidos.

  • Engagement o dedicación. 

Cuando se mide la dedicación de la comunicación, lo que observamos es la frecuencia en la que ocurre la misma entre cada uno de los miembros del equipo. Lo importante de esta parte es que la frecuencia entre todos sea homogénea, que todos hablen con el resto del equipo aproximadamente las mismas veces. Cuando los flujos de comunicación son heterogéneos y desiguales, se puede detectar por ejemplo que hay un líder el cual siempre interviene para que otros miembros se sincronicen entre sí. Esta persona recibiría más flujos de comunicación que el resto de miembros y se convierte en un cuello de botella. También se puede detectar a miembros del equipo que no están tan integrados. Estas personas recibirían una menor frecuencia de comunicación de sus compañeros que la que recibe el resto y normalmente no pueden aportar tanto como el resto.

  • Exploración

En un equipo de alto rendimiento siempre hay necesidades de conocimiento nuevo que no tienen. Para ello es importante que sepan explorar y encontrar en otros medios (Internet, libros, foros, comunidades técnicas,  contactos en otras empresas,..). Cuanta más facilidad tengan en encontrar esa información, estos equipos tendrán menores bloqueos y sus resultados serán de mayor calidad.

¿Cómo podemos medir estas características?
En un próximo artículo que escribiré en breve, explicaré una herramienta con la cual se puede visualizar el engagement o dedicación de un equipo.

Fuente: Harvard Business Review

Autogestión en equipos dentro de consultoras – Novela corta de ciencia ficción

Amanece en la playa Muchavista, situado a media distancia entre la población de Campello y la ciudad de Alicante.  Ya se ve bastantes corredores aprovechando el buen tiempo para estirar las piernas a lo largo del paseo marítimo. Los barrenderos limpian los últimos restos y vasos de Mac Donalds dejados por los paseantes nocturnos antes de dar paso a un día que promete tener bastante ocupación de la playa.

Sin embargo, el verdadero movimiento no está precisamente en la arena. A pocos metros de la misma se ve un chico de 30 años, de pie mirando al mar y disfrutando de su café en una taza en la que se lee las palabras “Clean Code”. Da los últimos sorbos, deja la taza en una mesa del jardin y estira sus brazos y piernas para despertarlos después de una noche de sueño reponedor. Javier y su equipo son miembros de una consultora internacional, HGY,  que da servicio a grandes corporaciones financieras. Son un equipo 100% autogestionado dentro de la compañía, y muy disputado entre los clientes de la misma.

Javier recoge la taza y se va al interior de la pequeña casa de dos plantas con vistas al mar.  Deja atrás el pequeño jardín algo dejado a su destino al que nadie presta atención. Atraviesa la cocina  y sube los escalones que dividen la casa entre la planta en la que Javier y sus compañeros de equipo descansan y comen de la planta donde trabajan. El clac, clac, clac de un teclado mecánico le devuelve a Javier a la realidad del trabajo, y le produce una sonrisa.

– Diego, ¿Cómo fue la revisión de lo que entregamos ayer por la tarde a Banco Palomo? ¿Tenemos ya algún comentario de Daniel, nuestro querido Product Owner? – Pregunta tirando  una pelota de malabares que había encima de una de las mesas a  Diego, un miembro del equipo que estaba revisando el tablero Kanban del proyecto.

– De momento no, hay que dejarles que respiren. La entrega de ayer por la mañana les encantó como bien nos dijeron. Un par de días más y creo que ya tendrán el producto que esperaban. Bueno el que ni siquiera se esperaban. – Responde Diego cogiendo la pelota al vuelo, para sorpresa de Javier.

Diego tiene un poco más de edad que Javier pero, al contrario que él, aún no se le asoma ninguna cana.  Es especialista en sistemas web y entre él y Raúl han desarrollado casi todos los interfaces de usuario del sistema Peer Loans, que permite al banco que sus clientes elijan a quién prestar el dinero de sus depósitos.

– ¿Sabemos algo de Héctor? Desde que cogió el avión a Tailandia con su novia Malai no hemos recibido ninguna de sus fotos empalagosas de parejita feliz. – Pregunta Raúl sin mover la cara del monitor de 32 pulgadas en el que va añadiendo pruebas automatizadas para empezar a desarrollar uno de los últimos módulos de Peer Loans. –  Eso me recuerda que tenemos que revisar a los últimos candidatos para reemplazarlo. –

Raúl es un chico de 33 años, experto en lenguajes web y siempre viste con camisetas de Dragon Ball. Lleva en el equipo 3 años y siempre le acompaña su mujer y sus dos hijas allí donde vayan a trabajar.

– A mi me gustaba Jesús, le da a los dos palos de back y front con la suficiente soltura como la que necesitamos. Además es un miembro respetado del Meetup Full Stack Dev Alicante. – Dice Eva acercandose al monitor de Raúl  – Podemos hacerle una visita o quedar en algún bar para hablar con él. Si le gusta el sueldo que le ofrecemos, que seguro que lo hará, estará con nosotros en un par de días. –

Eva es la chica  de QA, de casi 40 años, y en los últimos años ha hecho un gran trabajo inculcando conocimientos sobre casuísticas de tests a los miembros del equipo. Tiene facilidad de palabra y habla muchos idiomas, lo que le permite estar en comunicación constante con los clientes para prevenir todos los escenarios posibles.

– Raúl, no te olvides del buffer overrun en el tratamiento de este campo –  Le dice Eva a Raúl acercándose a su hombro – Por cierto, buen trabajo con estos escenarios. – Una sonrisa de satisfacción casi imperceptible asoma en el rostro de Raúl mientras ejecuta los tests. Una columna de puntos rojos de tests fallidos le indican que es momento de empezar a trabajar en ese trozo de código.

–  No olvidemos que en un par de semanas tendremos nuevo proyecto. A este le quedan sólo un par de coletadas.-  Recuerda Javier desde su puesto de trabajo abriendo la página de la tecnológica Dell y buscando un servidor nuevo para su sistema de integración continua- ¿Habéis revisado últimamente la lista de posibles proyectos? –

Diego se acerca jugueteando con la pelota de malabares a su puesto. Pulsando un botón de su portátil pone en iluminacion su gran monitor así como los leds de su teclado y ratón. Sin sentarse coge el ratón y abre la lista de proyectos que los clientes de HGY les ha enviado. Su éxito con la nueva herramienta de Banco Palomo ha hecho que sean uno de los equipos más solicitados de toda la consultora y prácticamente de toda Europa.  Los honorarios que ellos mismos solicitan son altos pero hay muchos clientes a los que no le importa gastar un poco más para tener a estos chicos a su disposición.

– Ja, ja, ja. ¿A que no adivinais quién nos pide volver a trabajar con ellos? – Suelta Diego riéndose con las manos detrás de la nuca.

Eva y Javier se acercan a su monitor y se unen a Diego en las risas.

– ¿Podemos reirnos todos? – Suelta socarronamente Raúl sin levantar la mirada del monitor y sin dejar de teclear.

Eva, apoyada en la espalda de Diego, se vuelve a Raúl y le dice con una gran sonrisa – Nuestro “amigo” Financial Bureau quiere que le hagamos el sistema de banca con Realidad Aumentada igual al que le hicimos a Banco Marsella. –

–  ¡ Ni de coña ! – Suelta tajantemente Raúl mientras vuelve a ejecutar la lista de tests.  Ahora una columna de puntos verdes remplaza a los rojos, indicando que su cambio ha funcionado a la perfección. Aprovecha para girarse y mirar al resto del equipo. – ¿Os acordáis de lo impertinente que fue el CIO? Nos obligaba a trabajar a través de su entorno virtual. Como si nuestro entorno de red cifrada no fuera menos seguro que el suyo.  Quiere velocidad y calidad y nos da un martillo y un cincel para escribir código.  ¿Hay algun proyecto en Tailandia?  –

– Tú lo que quieres es intentar que Héctor vuelva con nosotros. Si encontramos una oficina cerca de donde van a montar la Startup estarías visitándole a todas horas. – Le dice Eva mirando la lista de posibles clientes.

– No. Es que allí tiene la oficina central Jurgen Fowler, el experto en EcmaScript 11, y que lideró su definición. – Responde Raúl, con media sonrisa –  He estado en comunicación con él últimamente y creo que nos puede preparar un curso intensivo al menos unos días si estamos por allí. El precio que pone es asequible y algunos lo necesitáis bastante… –

– Venga, me apetece empezar a codificar ya. ¿Qué os parece que hagamos una ronda de 3 pomodoros? – Sugiere Diego dirigiéndose a su silla. Esta idea hace que Javier y Eva también vayan corriendo a sus sillas y Raúl haga crujir sus dedos preparándose para una sesión intensa. – Pongo el crono de 25 minutos en marcha.  Empezamos en  3,2,1… –

El sol ya está iluminando con fuerza la arena y los primeros bañistas entran en las aguas de la playa Muchavista. Javier y su equipo están ya concentrados trabajando el resto día para terminar lo poco que le queda de su asignación actual. En un par de semanas, en la fachada de la casa colgará un cartel de “Se alquila”. El equipo se habrá desplazado a un lugar algo más montañoso, por sugerencia de Eva. Sólo ellos mismos saben cual será el siguiente proyecto y lugar en el que trabajen. Son dueños de su propio destino.

FIN

Esta historia, que es naturalmente una historia de ficción, representa una imagen que a día de hoy parece imposible de conseguir en equipos que trabajan para consultoras. Hemos visto algunos ejemplos de decisiones en manos en un equipo totalmente autogestionado, aunque puede haber más. Estos equipos:

  • Deciden quién entra y quién se va de su equipo
  • Deciden su sueldo
  • Deciden su proyecto
  • Deciden dónde trabajan fisicamente
  • Deciden sus herramientas
  • Deciden su formación
  • Deciden cuándo toman vacaciones

Cuando un equipo llega a estos niveles de autonomía, logran una gran motivación y eficacia, lo cual les convierte en un equipo de alto rendimiento y para los clientes se traduce en productos de gran calidad e innovación. Sin embargo para llegar a estos niveles hace falta que tanto los miembros de los equipos como los directivos de las organizaciones tengan como meta conjunta esa autogestión. Los directivos y cargos intermedios tienen que aprender a delegar aunque suponga que al principio cometerán errores. Pero también cada miembro del equipo debe responsabilizarse del poder que se le da y saber dar el paso adelante para tomar esas decisiones. Aunque no lo parezca, tan difícil es lo uno como lo otro. Pero ¿quién sabe?, la ciencia ficción a veces se convierte en realidad. Todo camino empieza por un primer paso ¿Qué tal si empezamos por que los miembros de tu equipo puedan  autoasigarse las tareas?

 

 

Día 1 en la Conferencia Agile Spain 2017 en Sevilla

Keynote de Ramón Cabezas.  @RamonCabezas
Human & Digital Transformation
Ahdalid.com Kaps.es

Estuvo hablando de la transformación digital y la importancia de tener al cliente en el centro.  Enseñó un par de sus productos que se diseñaron teniendo eso en cuenta. como un pulsador para que te llame alguien para gestionar un accidente y el usuario no tenga que buscar los papeles del seguro o a quién llamar.

 

Jerónimo Palacios.  @giropa832
Scrum Studio

Habló de Scrum Studio, un framework diseñado por Scrum.org. Es una célula de trabajo totalmente independiente de la empresa y con los elementos imprescindibles para que pueda trabajar de forma autonoma y ágil. Va tomando proyectos poco a poco de la empresa madre y haciéndolos de forma ágil. Tiene la autoridad para  tomar y echar gente de sus equipos. La idea es que vaya fagocitando poco a poco al resto.

Tanto es su potencia que puede ocurrir el caso que le ocurrió en la que el CEO de la empresa acabó terminando la célula ágil.

Frase: Culture eats Agile. Al final, las personas de poder que no quieren perder su autoridad acaban por destruir los intentos de implantación de cualquier sistema ágil a escala.

El CIO  se transforma para dar Leadership services, lo que necesita esa celular para funcionar como una empresa autónoma: RRHH, contable, …

Hay que cambiar la visión de proyectos (algo que cuesta dinero) a producto (algo que genera valor y dinero por ende a la empresa)

La gestión se hace mediante Evidence based management (Scrum.org).  Basado en el triángulo MEASURE, IMPROVE, DIAGNOSE.

Existe un Scrum Development Kit que miraré  bien 😉

 

Toño de la torre. @adelatorrefoss
Discusiones y decisiones: herramientas para la efectividad

Primero hizo un disclaimer que todo venía del libro de Gamestorming y retrospectivas. Habló de conceptos básicos del gamestorming como los juegos de apertura para generar ideas, de exploración para categorizarlos y formar ideas procesadas y juegos de cierre para acabar con una decisión. También estuvo explicando varias dinámicas de gamestorming para trabajo colaborativo .

 

Israel Alcazar.  @ialcazar
Equipos de alto rendimiento

Matriz de autoridad de Richard Hackman. Parecido a la matriz de delegación de Jurgen Appelo pero más alto nivel.

Auto-organización. El equipo decide la forma de trabajo
Auto-diseño. El equipo decide qué necesita miembros o ya no.
Auto-gobierno. El más alto nivel, como si fuera una cooperativa de socios

Alto-rendimiento es una suma de resultados satisfacción y motivación. Es importante tener objetivos claros, entorno seguro y  responsabilidad compartidas.

Habó de las 5 disfunciones del equipo, del libro de Patrick Lencini

Jerarquía es como comunicación padre-hijo como trata el Analisis transaccional. Tratando al trabajador como un padre que trata al hijo hace que el hijo se comporte como rebelde o apagado.  El equipo necesita autonomía y responsabilidad.  Lo cual se trabaja con una combinación de confianza, delegación y feedback. Un entorno de confianza es el que se debe conseguir como mínimo en las retrospectivas. Comentó que se encuentra con que en las primeras retrospectivas los miembros sólo “sueltan mierda” porque tienen muchos problemas acumulados que necesitan decir y las retrospectivas es la primera oportunidad.

Las herramienta de evaluacion de equipo deben ser usados por los propios equipos. Conflicos/Cohesion/Eficacia

La evolución se hace mediante una serie de pasos en espiral con varias iteraciones. No necesariamente en el mismo orden

  1.  Proposito
  2. Conexión (empatía).  Aportación como persona
  3. Acuerdos (Roles, Reuniones, Formas de trabajo)
  4. Seguridad a trabajar en las retrospectivas
  5. Autoconocimiento (capacidades)  funcional, llegar a identificar los Roles de Belbin (explorador, investigador, coordinador..)
  6. Consciencia
  7. Autonomía
  8. Responsabilidad

Jose Ramón Díaz. @joserra_diaz
Taller de Liderazgo para la transformación. 

Empezamos haciendo una definición de liderazgo entre todos. Salieron conceptos como capacidad/habilidad, conocimiento referente, personas, sigues, empatizas, objetivo/visión, moviliza gente, forma consciente/inconsciente

Cuando una persona tiene autoridad se la da poder, principalmente para que aporte una dirección, de orden y protección. En sociedades democráticas está asignación ocurre de abajo a arriba y en empresas normalmente de arriba a abajo.

Cuando es autoridad formal se asigna a una persona por parte de la dirección. Cuando es autoridad informal ocurre a través de la confianza.  Cuando son distintas las personas que tienen ambas ocurren los conflictos.

Después idenficamos las características de un buen seguidor. Identificamos características como  empatía, ser crítico, autonomía, fidelidad .., Después se nos pidió identificar cuales de esas características no corresponde con las de un buen lider, descubriendo por nosotros mismos que no las había. Son las mismas características.

¿Para qué necesitamos un lider?

Hay ciertos problemas que requieren conocimiento técnico como puede ser lo que ocurre cuando un médico de urgencias pide y ejecuta todo lo necesario ante un paciente que llega con una parada cardíaca. También hay problemas de tipo adaptativo que tienen que ver con el trato a personas y gestión de conflictos y que requieren un líder con valores.

Definición Liderazgo: Process of mobilizing groups to engage its challenges developing its skills for their progress and well-being.

Las conversaciones normalmente tienen un umbral de conflicto (con su nivel máximo y mínimo) que representa la zona de aprendizaje. Es importante para el líder hacer que los conflictos se mantengan en esta zona, sin que esté por debajo y no permita aprender o por encima y el conflicto tenga consecuencias negativas.

Un reto conlleva a tomar acciones lo que lleva a estar en la zona de conflicto.  ¿Cómo se sabe que está en la zona correcta?  El líder va girando entre  Observar, Interpretar y Actuar. Debe proteger el liderazgo que surge en estas conversaciones para no parar el proceso en si mismo y el propio liderazgo expontaneo.

Terminamos definiendo acciones para un reto elegido entre todos e identificando si las acciones requirieren de un líder más técnico , si requiere autoridad por parte de la compañía o un líder con valores.

 

Marta San Martín. @MartaSanMartin
Introducción al coaching. Cómo tener conversaciones diferentes

Marta nos enseño la técnica del Mirroring en la que se escucha a la persona que tiene un problema sin darle soluciones ya que normalmente esa persona tiene todo el conocimiento necesario. Hay que hacerle preguntas abiertas tipo “¿Cómo’, ¿Cuándo?, ¿Quién?, ¿Dónde?. La pregunta de “¿Por qué ?” no es recomendada porque normalmente crea en la persona que explica el problema una justificación que puede crearle incomodidad. Una cosa que sí se puede hacer es interrumpirse y refrescar para hacerle ver que se está escuchando con atención.

Hicimos el ejercicio de Mirroring en parejas, al final de cual explicábamos el uno al otro cómo nos sentíamos tanto el que explicaba el problema como la persona que hace de coach. Entre uno y otro hicimos un ejercicio de mindfuldness aprovechando que Marta es certificada y experta en el tema.

 

Keynote de Marta Pinillos. @pinillos_marta
La voz, la clave del éxito en tu comunicación

En este divertido e increíble keynote de despedida, Marta explicó la importancia de la comunicación ya que es el más usado. Realmente la comunicación cara a cara es un valor ágil por lo tanto hay que darle importancia a la voz para transmitir correctamente los mensajes.

  • Ritmo: el ritmo correcto debe ser entre 130 a 150 palabras por minuto. Si es menos el emisferio derecho que el que procesa de forma rápida se queda “dormido”.
  • Volumen. Hay que manejar el volumen, bajando en las partes importantes más que subirlo para no parecer una verdulera.
  • Tonos: Hay que tener 5 tonos de voz distintos y saber manejarlos.
  • Modulación. Manejar la modulación haciendo cambios de riemo. No debe haber un ritmo constante para mantener la atención.
  • Dicción. Saber marcas las consonantes en las palabras importantes
  • Pausas. Hacer 4 ó 5 pausas ¿por minuto?
  • Entonacion. Saber marcar las palabras
  • Respiración. Tener una respiración diafragmatica y un tono no agudo porque aporta seguridad y credibilidad.

Con esto terminó el primer día. Muchas cosas descubiertas y a tener en cuenta.

Eficacia vs Eficiencia en Scrum

Llevo tiempo dandole vueltas

Ultima mente creo que estoy dando el mensaje incorrecto sobre Agile, que no persigue la eficiencia ya que waterfall es mas eficiente. Todo esto surge de una de las lineas que vi como propuesta del Manifiesto Lean Kanban. No hay sistema teoricamente más eficiente que el waterfall. Cada fase está realizada por un equipo especialista que, sin cambio de contexto, pasa todo su trabajo de una a la fase siguiente. Sin embargo waterfall falla en cuando hay cambios a mitad de proyecto, o cuando hay alguien que no hace perfectamente su trabajo. Cosas que ocurren el 100% de los proyectos. Sin embargo, un equipo que pasa de waterfall a scrum tiene sensación de perdida de eficiencia por las siguientes razones:

  • Reworking. Cada vez que se enseña el software al cliente existe la posibilidad de que toque rehacer algo. Implica cambiar cosas que has hecho en un sprint en el sprint siguiente. También para que el software sea entregable al fin de sprint muchas veces hay que hacer trabajo extra para dejarlo listo.
  • Tener que integrar en cada sprint hace que se tenga que cambiar el contexto continuamente. Si desde el sprint 1 el equipo está peleando con integraciones, a primer momento parece no ser tan eficiente como estar solamente desarrollando. Sin embargo, esto convierte el gran problema de la integración final en una molestia desde el primer sprint.
  • Reuniones de Scrum : planning, daily, review y el refinement. A los equipos a los que se les tradicionalmente se les da una lista de tareas sin mayor explicación, les parece que son innecesarias todas estas reuniones… “Era más productivo cuando se me daba la lista de tareas”.

Sin embargo, aunque no lo parezca Scrum hace que un equipo pueda llegar a ser mucho más productivo. Como indica el titulo del libro de Jeff Sutherland, se puede llegar a entregar el doble de valor en la mitad de tiempo que con metodologías tradicionales. Aunque esto no se consigue por la metra transición a Scrum y mucho menos en el primer sprint. Lo que sí que permite es el marco para que el equipo consiga gran eficiencia. ¿Cómo?

  • Promoviendo que no se haga más de lo solicitado (“make the right think done”). No se debe escribir una sola linea de código que no tenga que ver con el objetivo de la historia de usuario y no se debe hacer una sola tarea o historia que no esté dentro del objetivo de sprint.
  • Protegiendo al equipo de las interrupciones. El equipo está expuesto a interrupciones para hacer burocracia, explicar o documentar su progreso y hacer cosas que no tienen que ver con su objetivo de sprint. El Scrum Master es responsable de proteger a los miembros del equipo.
  • Focalizando las reuniones. Cada reunión Scrum tiene su objetivo y su ventana temporal. Esto hace que las reuniones mismas sean más productivas y permite que durante el tiempo en la que el equipo no está reunido (work time) no tenga que cambiar de contexto por culpa de ellas. Hay que detectar y minimizar o eliminar las reuniones sin foco y que no aporten nada al equipo o producto.
  • Mejorando la comunicación del equipo, haciendo que estén mas coordinados y tengan menos esperas y colisiones entre ellos.
  • Acercando el feedback y testing al momento de desarrollo. Esto hace que la corrección tarde hasta 20 veces menos que si se hubiera hecho semanas después.
  • Permitiendo al equipo pensar de qué modo mejorar a si mismo. Al juntarse en las retrospectivas les permite analizar cómo eliminar los impedimentos y desperdicios (waste) para hacer más y más puntos de historia cada sprint.
  • Permitiendo hacer experimentos de mejora durante un sprint y evaluar si seguirlo o no. Un equipo puede probar algo que parece una locura durante un sprint y evaluar en la siguiente retrospectiva su resultado. De este modo es posible encontrar modos ingeniosos de mejorar la productividad sin poner en riesgo el proyecto.

La proxima vez que explique Scrum, no olvidaré en contar ambas facetas (efectividad y eficiencia). Efectivamente se prima la efectividad ante la eficiencia, pero hay que transmitir que se puede conseguir mucha más eficiencia con equipo Scrum que en equipos tradicionales.

 

 

Las palabras del Daily Standup se las lleva el aire

Esto fue lo que había estado observando en un par de Dailyes. Un desarrollador podía decir a sus compañeros con pleno convencimiento: “Hoy voy a reticular los splines y fluzear los vértices del condensador” y al día siguiente decir que en el día anterior había hecho cualquier otra cosa sin inmutarse lo más mínimo. Lo más normal es que ni uno mismo se acuerde de cuales eran los objetivos que se había marcado el día anterior. ¡¡ Y mucho peor !!! Podía haber fallado completamente en cumplirlos por causas ajenas a su voluntad sin ni siquiera darse cuenta ni saber sus causas.

Otra cosa que había observado es que a veces se llega a los Dailyes sin tener claro cuáles van a ser los objetivos para ese día. Frases como “En cuanto termine esto ya veré con qué me pongo” o “Ahora miro el Kanban a ver que será lo siguiente”. En VSN hacemos los Daily standup a las 10 de la mañana, lo suficientemente pronto como para que sea el disparo de salida del día y lo suficientemente tarde como para que todo el mundo tenga claro ya en qué va a trabajar. El problema de no tener totalmente claros los objetivos para el día puede hacer que se acabe trabajando en las cosas urgentes y poco importantes que siempre surgen. Lo importante y no urgente se acaba retrasando hasta que es demasiado tarde. Además esto provoca que se acabe el día con la sensación de que aunque no se ha parado ni un momento,  no se ha hecho nada útil.

Eisenhower Matrix
http://www.gsdfaster.com/blog/wp-content/uploads/2015/02/eisenhower-matrix.jpg

Para evitar estos problemas, hemos llevado a cabo un experimento que por el momento está saliendo muy bien. Para el Daily todos llevan preparada un pequeña hoja (10cmx10cm) con la fecha y su objetivo (o máximo 2) para el día.  Usando estas pequeñas hojas leemos  lo que nos pusimos como objetivo el día anterior, si lo hemos cumplimos o no (y por qué) , cuál o cuales van a ser los objetivos para el día y qué bloqueos pueden ocurrir o qué necesidades vamos a tener para cumplirlos. Los Dailyes son ahora más productivos porque no se divaga con cosas que no tienen que ver con esos objetivos principales. Reuniones, tests, atenciones a soporte dejan de ser centro de conversación a no ser que hayan sido la razón para no cumplir lo importante.

TarjetaObjetivos

En el resto del día esa pequeña hoja encima de la mesa recuerda a qué se debe aferrarse. Conseguir este objetivo con la ayuda de herramientas como la técnica Pomodoro, reduciendo interrupciones, revisando el correo a horas fijas, gestionando correctamente las reuniones y automatizando lo automatizable… es otra historia.

 

Precaución: el trabajo en equipo puede perjudicar al equipo

Estamos en una época de revolución de los métodos de trabajo. Se está demostrando que un equipo motivado, autoorganizado y con visión de producto es capaz de dar valor al cliente de forma rápida mientras aprende lo que va necesitando. Hemos aprendido a trabajar en equipo, colaborar, estimar en equipo, planificar en equipo…  Prácticas como el mob-programming en las que un grupo de desarrolladores trabajan en un mismo código con un mismo teclado están creando tendencia. Estamos abriendo las oficinas, quitando muros y juntando mesas para que haya comunicación entre todos los miembros, para que se vean y se oigan fácilmente y la comunicación osmótica fluya.

Sin embargo, todo esto tiene un límite. Estudios recientes están demostrando que la colaboración puede llegar a ser excesiva cuando impide conseguir los objetivos personales de los miembros del equipo. Actividades de colaboración (reuniones, responder preguntas, hacer coaching a un compañero, conectar por escritorio remoto para ayudar a un colega, etc …) puede llegar a suponer más del 50% del tiempo disponible de trabajo.

Además, se está demostrando que alrededor del 25-30% del valor añadido en estas colaboraciones es aportado por solamente el 3 ó 5% de los miembros. Son estas personas que están continuamente en reuniones o resolviendo preguntas. Su experiencia les ha convertido en personas indispensables a la hora de tomar cualquier decisión. Y esto desde cierto punto de vista está bien pero se acaba generando un círculo vicioso que hace que cada vez estas personas sean más indispensables y tengan menos tiempo para su trabajo personal.

Igualmente también nuestros adorados espacios abiertos se están convirtiendo en un problema. El ruido de conversaciones, notificaciones de los teléfonos móviles, sonidos de teclado pueden llegar a anular totalmente la capacidad de concentrarse en el trabajo. Según la comunicación osmótica es importante el valor añadido que puede dar una idea tuya que das por haber oído una conversación cercana o lo que puedes aprender de esa conversación. Pero estos hechos muchas veces son tan aislados que no compensa la falta de productividad que genera el no poder entrar en flujo por culpa del ruido ambiental.

La respuesta está en ser generoso  hacia el equipo con el tiempo personal pero también darle un gran valor. Cosas que se pueden hacer:

  • Saber decir que NO.
  • Priorizar las peticiones de ayuda (informativas, persuasivas y de tiempo).
  • Obligarse a tomar tiempo de concentración (pomodoros) con los auriculares puestos para evitar interrupciones.
  • Gestionar bien las reuniones. JGI
  • Gestionar correctamente el email y los sistemas de mensajería interna.

 

Fuentes

https://hbr.org/2016/01/collaborative-overload

http://time.com/money/4160139/collaboration-teamwork-lower-productivity/

https://hbr.org/2015/12/muting-unwanted-noise-in-an-open-office

¿Qué motivadores consideras más importantes en tu vida?

Me encantó el libro Workout de Jurgen Appelo. Expone claramente por qué deberíamos tener otra perspectiva del management, con más gente que se auto-dirija y menos directores. Esto permite un incremento de productividad, creatividad y motivación que no se pueden conseguir fácilmente con métodos tradicionales.

Una herramienta que voy a empezar a usar es la de “Moving Motivators“. Con este ejercicio, uno evalúa distintos motivadores y se ordenan de derecha a izquierda según  tienen más o menos importancia para el/ella. Estos motivadores son:

Curiosidad. Ver cosas novedosas, fuera de lo común. Aprender cosas nuevas cada día

Aceptación. Ser miembro de un equipo como uno más tal y como es y con lo que hace. Formar parte de los éxitos y ser reconocido cuando se hacen bien las cosas

Maestría. Llegar a ser un experto de una tecnología o técnica mediante estudio o experiencia y poder compartirlo con otros

Poder. Poder tomar las decisiones que tienen que ver con la forma de trabajar y el entorno. Expresar autoridad.

Libertad. Poder hacer cosas sin preguntar y ser creativo. No depender de aprobaciones de otros o normas estrictas.

Relaciones. Relaciones sinceras y abiertas con otras personas. No trabajar sólo.

Orden. Estabilidad, concreción, determinismo, sin sobresaltos, con procedimientos y opciones claras

Objetivos. Poder cumplir objetivos personales o profesionales.

Status. Tener un posición importante y respetada por el resto.

Moving motivators right to lefty
Tarjetas con los motivadores puestos en orden. Más importante a la derecha, menos importante a la izquierda.

Esta semana empezaré a usarlos y haré un experimento cuyos resultados quiero compartirlos dentro de poco.

 

 

Optimiza el uso de tu memoria (mental)

¿Cuantas cosas sabes hacer a la vez? ¿y hacerlas realmente bien? ¿Y además en un tiempo aceptable? Antes de responder a estas preguntas, me gustaría que conocieras cómo funciona nuestra mente.

El cerebro está compuesto de bloques de memoria de cortisimo plazo o de trabajo, de corto plazo y de largo plazo. Cuando realizamos un trabajo utilizamos una combinación de todos estos bloques a la vez. Por ejemplo, un desarrollador de software necesita tener en la mente el lenguaje de programación a usar, el diagrama conceptual del proyecto que está modificando, el objetivo de la funcionalidad que está desarrollando y en la zona de cortísimo plazo el algoritmo que se está escribiendo en ese momento. Un ingeniero de soporte puede tener el sistema del cliente, los detalles del problema en cuestión y el producto del cual está dando soporte. Un comercial puede tener detalles del producto que vende y detalles del cliente al que quiere vender.

Bloques de memoria de un desarrollador concentrado
Bloques de memoria de un desarrollador concentrado

Contínuamente tenemos que reemplazar estos bloques. Esto puede ser  por una interrupción que provoca un cambio de contexto y necesitas modificar tu memoria de más corto plazo. Pero también puede ser cuando cambias a desarrollar otro programa, otra historia de usuario u otra funcionalidad, incluso por un cambio de lenguaje de programación. Cada cambio requiere que uno o más bloques de memoria se reemplacen. Y ese reemplazo tarda tiempo. Si es memoria a corto plazo puede tardar incluso más de 15 minutos pero si es memoria de medio plazo como el lenguaje de programación se puede tardar días en sustituirlo completamente.

Cambio de tarea en otro lenguaje de programación
Cambio de tarea en otro lenguaje de programación

Hasta que un bloque es completamente sustituido, el bloque tiene una mezcla de distintos contenidos. Es el momento en el cual se toman decisiones incorrectas y se cometen fallos. Es cuando lo justificamos a que no estamos completamente concentrado y se producen frustraciones.

Para tomar mejores decisiones, realizar un trabajo de mejor calidad y más rápido hay que reducir el WIP. WIP significa trabajo en curso (Work In Progress) y hay que intentar que como máximo se tenga una tarea en la cabeza,  o una característica nueva a la vez por equipo, o una incidencia de soporte a la vez. Ya existen herramientas como Kanban, GTD y la Técnica Pomodoro para ayudarte a enfocarte en una tarea o con un mínimo de trabajo a la vez. Pero ninguna de estas técnicas ayuda a decidir con qué tareas ponerse o qué trabajo empezar una vez se ha terminado para minimizar el reemplazo de la memoria de trabajo.

Para ello propongo hacer una lista de los 5  elementos que más se tienen en cuenta a la hora de realizar una tarea . En el ejemplo del desarrollador de sofware, haríamos esta lista:

  • El tipo de tarea a hacer: desarrollo, administrativo (emails, imputar,…) , test, formación…
  • El lenguaje de desarrollo a usar
  • La estructura del programa a modificar
  • El framework o API que se usa: ASPNET MVC, Backbone, Angular,…
  • Las características del cliente que usará la funcionalidad

Para cada característica distinta a la de la tarea que se ha terminado se suma un punto. Si hacemos un tipo de tarea completamente distinta tendríamos 5 puntos porque seguramente necesita reemplazar todos los bloques de memoria. Si es del mismo programa pero hay que cambiar de lenguaje es un punto por el cambio de lenguaje y seguramente otro por el cambio de framework llegando a 2 puntos. Cada vez que se elige una nueva tarea hay que evaluar los puntos de lo que podemos empezar dentro de las que tengan igual prioridad. Idealmente se elegirá una tarea del mismo lenguajes, del mismo programa, con el mismo framework y para el mismo cliente. De este modo reducimos el número de bloques de memoria a reemplazar consiguiendo un resultado con mejor calidad, en menor tiempo y sin frustraciones.

 

Cómo el stress afecta a la calidad del software

El uso de las metodologías ágiles en el desarrollo de software ha supuesto un antes y un después en relación a la calidad de los productos. Webs, aplicaciones, juegos, son cada vez más elaborados, imaginativos y más seguros.

Uno de los principios ágiles habla de ritmo sostenible (sustainable pace). La interpretación más aceptada es la de jornadas de trabajo de 40 horas semanales. Está más que demostrado empíricamente que las horas extras en desarrollo de software está linealmente relacionado con un incremento en los bugs cometidos.

Bien, pues aquí tenemos la razón.  La culpa la tiene el stress.

El stress envía hormonas a la sangre para preparar al cuerpo y la mente para la situación amenazante. Durante miles de años, para los humanos, las situaciones amenazantes tenían que ver con peligros físicos de animales depredadores, posibles accidentes o peleas entre tribus y estas sustancias preparaban al cuerpo para afrontarlas. Sin embargo en la época de la información y para trabajadores del conocimiento tienen precisamente el efecto contrario.

Estas dos simpáticas hormonas son la famosa adrenalina, que produce un incremento en el ritmo cardíaco, la presión de sangre y la respiración; y glucocorticoides como el cortisol. Bueno, pues estos últimos producen entre otros, unos efectos muy perjudiciales a la memoria de corto plazo y la memoria de trabajo.

La memoria de trabajo es la parte del cerebro en la que almacena los datos que tenemos que combinar, comparar y analizar para resolver los problemas. Nuestra memoria RAM. Tipicamente un cerebro  normal mantiene y trabaja con 7+-2 chunks o bloques de datos simultáneamente para resolver los problemas. Los glucocorticoides reducen este número por lo que la mente se ve limitada a trabajar con menos datos y menos alternativas para intentar resolver ese diseño o ese código que hay que hacer que funcione.

Los militares han hecho muchos estudios relacionados con la reacción de las personas en situaciones de stress (ver referencias). En un estudio se demostró que el stress tenía el efecto positivo de reducir el tiempo de reacción, sin embargo esto tenía el efecto colateral de crear un mayor número de falsas alarmas y errores que las surgidas en condiciones de tranquilidad. Es decir, estresados fallamos más que una escopeta de feria. Mantenemos nuestra atención en la parte negativa del problema para intentar resolverla lo cual nos impide mirarlo desde fuera, afrontarlo lateralmente para poder ver otros ángulos y encontrar mejores soluciones.

En otro estudio se demostró que las personas, en situaciones de stress experimentamos una percepción superficial de la realidad, poniendo nuestra atención sólo a una pequeña parcela del problema a la hora de tomar una decisión o encontrar una solución. En este estado de alta tensión tomamos decisiones basadas en un conjunto incompleto de información y tomamos atajos basados en experiencias pasadas.

En resumen, tenemos que un desarrollador o u trabajador en general cuando está estresado reduce  su memoria de trabajo, no es capaz de tener visión lateral y creativa y toma atajos para resolver el problema lo más rápidamente posible sin pensar en más allá que el alcance de su problema… Conseguimos al DESARROLLADOR BOMBA. Preparaos para bugs por doquier, deuda técnica acumulandose, software de baja calidad y clientes decepcionados.

Todo esto se puede evitar manteniendo el ritmo de trabajo a un ritmo mantenible. Respetando la capacidad del departamento de desarrollo mediante sistema PULL con Kanban o de compromiso de equipo en el  sprint de Scrum. Respetando la definición de DONE sin saltarse por la presión y manteniendo un ambiente de trabajo animado y relajado. Todo esto no debe ser un lujo, sino un requerimiento.

 

 

 

 

 

 

 

 

 

 

Referencias

 

http://en.wikipedia.org/wiki/Effects_of_stress_on_memory

http://en.wikipedia.org/wiki/Short-term_memory

http://en.wikipedia.org/wiki/Working_memory

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

http://the-programmers-stone.com/wp-content/uploads/2007/10/StressAndPerformance.pdf

http://www.researchgate.net/publication/259781769_Impact_of_Overtime_and_Stress_on_Software_Quality

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países “más modernos” prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>