Archivo de la categoría: Agile

¡ LO QUE HACÉIS NO ES AGILE !

Quizá has oido esto mucho cuando, por determinadas circunstancias, se han juntado equipos en distintos puntos de madurez. Las comparaciones son siempre odiosas, y cuando comparas equipos, mucho más.

Cuando esto lo sumas a que estos distintos equipos están envueltos es una transformación global en una empresa, es peor aún. Lo que se acaba comparando son simplemente procedimientos o formas de trabajo concretas y a partir de esta comparación, algunas personas pueden catalogar a otros equipos como no-agile. Las razones suelen ser tán superficiales como que aún no han incorporado tal o cual practica ágil.

Si por ejemplo, juntamos un equipo que sí realiza ATDD (definición de los tests de aceptación antes del desarrollo) y otro equipo en el aún no lo hacen y los tests los realizan cuando el desarrollador ha terminado su parte, puede ocurrir que a estos últimos se les acuse con ¡Eso no es Agile, waterfallista!. Sin embargo, en mi opinión, el hacer esto es debido a tener una visión muy sesgada de lo que es un proceso de maduración Ágil del equipo. En este ejemplo, sólo se tiene en cuenta el QA y el equipo que realiza ATDD se considera que hace Agile y el que no, es un mero Waterfallista.

Cuando digo sesgada me refiero a que esta acusación tambien podría pasar desde el punto de vista de despliegue del producto. Si juntamos un equipo que hace integración continua y pone en producción cada historia que se va terminando y a otro equipo en el que sencillamente el despliegue se hace después de haber terminado el sprint, el primer equipo podría decir al otro «. ¡Eso no es Agile, waterfallista!

O lo mismo puede ocurrir desde el punto de vista de diseño. Si en esta ocasión juntamos un equipo en el que hay miembros que realizan el diseño como una tarea más a la vez que la codificación con otro equipo en el que el diseño se hace un sprint anterior, puede llegar el listo de turno y decirles a estos últimos ¡Eso no es Agile, waterfallista!

Entonces ¿Qué es hacer Agile o no? Si habeis trabajado con un buen agilista, lo más probable es que este tipo de cosas no hayan salido nunca por su boca. Nos guardamos mucho de catalogar una forma de trabajo como Agile o No-Agile. Entendemos que cada equipo está en una fase de maduración distinta e historicamente se puede haber enfocado en mejorar una serie de practicas sobre otras, para solucionar unos problemas que para ellos eran más prioritarios que otros.

Agile no es más ni menos que el tener presente una serie de valores y principios marcados en su manifiesto. No hay un modo de trabajo que se pueda catalogar como más Agile que otro. De hecho, seguramente se puede hacer un trabajo puro waterfall por fases (analisis, diseño, desarollo, qa, despliegue) y ser Agil al mismo tiempo: haber dado más importancia a las personas y a sus interacciones, también al generar sofware más que a la documentación exhaustiva, se ha colaborado de principio a fin con el cliente y no se ha seguido el plan a fe ciega sin tener en cuenta el contexto. Entiendo que los valores hacen mucho challenge de las problemas que genera el seguir a pies juntillas el sistema waterfall, pero este escenario podría ocurrir. Una serie de practicas concretas no identifican un equipo como Agile o no

Consejo: cuando evalues o compares equipos, evita categorizarlos. Cada equipo tiene su propia historia y sus razones de trabajar de un modo en particular. Si quieres ayudarles, enfócate a entender esas razones y sus problemas reales. A partir de esos problemas, es donde vamos a poder recomendarles una u otra práctica. Si no, mira hacia atrás y hazte la pregunta «¿Nosotros empezamos a ser Ágiles solamente desde que empezamos a hacer algo en concreto o sencillamente desde que nos planteamos empezar esta transformación?»

Crunch o sobresfuerzo en el trabajo, ¿Es autoimpuesto?

Ayer, mientras paseaba por la playa con mi padre, vi a un antiguo compañero que hacía mucho tiempo con el que no coincidía. Me contaba que estaba a tope de trabajo, como siempre desde que se cambió de empresa. Cuando le dije que ahora era Agile Coach en lugar de programador, me dijo que había hecho bien, ya que hay que intentar dejar la programación, ya que todos los programadores tienen crunch.

El crunch es un exfuerzo excesivo y continuado para terminar el trabajo asignado (normalmente software) en el plazo previsto. No es extraño oir casos en los que se han trabajado jornadas de incluso 60-80 horas semanales. Este concepto viene sobre todo del mundo de los videojuegos y se popularizó cuando dió la vuelta al mundo al ocurrir durante los ultimos meses anteriores a la salida del videojuego GTA5.

Yo tengo una opinion muy clara al respecto y es de lo que quiero hablar. Creo sinceramante que nosotros mismos debemos tener el control de la potencia de nuestro motor personal, que representa el trabajo que realizamos y por ello somos los unicos responsables de su sobrecarga cuando ocurre.

Asumiento esto, ¿qué obliga a uno mismo a forzar la máquina más de su capacidad? He visto muchos ejemplos de compañeros sufriendo de una gran carga de trabajo día tras día, generando gran ansiedad, poniendo incluso en peligro su salud y su vida familiar. Estas personas piensan que tienen a sus espaldas ya sea el proyecto, el equipo o incluso la empresa y que si bajan el ritmo, pueden ocasionar un gran problema. En muchos de estos casos, estas personas acaban cambiando de trabajo o necesitando meses de baja laboral por ansiedad. ¿Y adivinas qué ocurre con la empresa que tanto estaban protegiendo y por la que habían puesto en riesgo su salud? Al final no se ve perjudicada como ellos temían, sino que sólamente se readapta y sigue adelante.

Uno mismo debe intentar ser consciente de dónde viene esa presión por trabajar más, para gestionarlo apropiadamente y no llegar a estos extremos. Debe tener realmente el control del propio esfuerzo, para incrementarlo cuando es necesario pero también para bajar el ritmo cuando la situación se convierte en insostenible y empieza a ocasionar efectos secundarios como la falta de sueño, irritabilidad o incluso desgaste de las relaciones con los seres queridos.

Hay casos en los que esta presión viene del exterior, como el propio mercado, de los usuarios, stakeholders,negocio… Sentimos que siempre se pide más y más y pensamos que estamos fallando al no poder satisfacer la demanda. En estos casos hay que tener en cuenta que en el mundo del software, no hay limite al numero de ideas, iniciativas, mercados, hipotesis que probar… Siempre se va a pedir más y más funcionalidades y desarrollos. Sincéramente, no me gustaría trabajar en un equipo de desarrollo en el que no existíera esta demanda contínua de cosas nuevas a hacer. Para mí sería un síntoma de que las cosas van a pique, que el producto está a punto de morir.

También influye la presion social, compañeros, o jefes que tienen asumida esta cultura de darlo todo, y para encajar en el grupo necesitas hacer lo mismo. Mola mucho cuando estás en un equipo motivado. Sin embargo cuando notas que lo que ocurre al tu alrededor se escapa de la simple buena motivación y que en general todo el mundo se está dejando de lado la salud o la familia, hay un serio problema. En estos casos lo mejor es intentar entre todos hacer este análisis del origen de la presión en una retrospectiva o incluso tomando una cerveza en un bar, para poder disociarse del día a día y ser consciente de la realidad del problema. En ocasiones es dificil hablar de ello porque es un tema tabú o está demasiado asumido en la cultura del equpo para darse cuenta.

Sin embargo, en la mayoría de casos lo que ocurre es un exceso de autoexigencia en el que no hay una presión real que venga del exterior. Es sencillamente una sensación de necesitar hacer más y más porque siempre el backlog de cosas por hacer no para de crecer. También me he encontrado muchos casos en los que lo que ocurre es el sindrome del impostor, es decir, el sentir que no nos merecemos el puesto, cargo o sueldo que tenemos. Esto suele provocar el intentar trabajar más duro o más tiempo para «demostrar» que sí que nos lo merecemos. En estos casos es importante reforzar la seguridad en uno mismo, y también aprender que decir que «NO» es más profesional que decir un «SI» y después hacer algo de mala calidad y llegar a un sobresfuerzo que te obligue a buscar trabajo en otro sitio.

En la industria del software tenemos la ventaja de la gran oferta de puestos de desarrolladores. En 2 semanas podemos encontrar un trabajo y en un mes podemos encontrar un BUEN trabajo. La presión para hacer más y más está en todos los lados, pero es responsabilidad de cada uno mantener el control de la potencia de nuestro propio motor para ir a buena velocidad de manera constante sin «griparlo». Poder volver a disfrutar del trabajo de programador y al mismo tiempo hacerlo cada vez mejor por la motivación que tenías hace años y que has vuelto a encontrar. Sé que todo esto más facil decirlo que hacerlo. Si piensas igual, habla con alguien de tu confianza o pide ayuda si lo necesitas.

Las reuniones no me dejan trabajar

Era un viernes cualquiera, más o menos a la 1 del mediodía. Estaba yo facilitando la retrospectiva de fin de sprint. El ambiente era distendido y se notaba ya la brisa del fin de semana. Estaban todos los miembros del equipo añadiendo las tarjetas virtuales de aquellas actividades que querían hacer más, hacer menos, dejar de hacer, empezar a hacer y continuar haciendo. Vamos, el Starfish de toda la vida.
Entonces ocurrió. Sí, otra vez. Un miembro del equipo había puesto una tarjeta en «Hacer menos» indicando que había que hacer menos reuniones porque «estando en reuniones no puedo trabajar«. OMG!.

Es muy posible que esto no sea nuevo para tí. Para un equipo que está intentando trabajar con Scrum, una de las mayores fricciones que puede haber es el ver los rituales de Scrum (dailyes, planning, review, retro y refinamientos) como un impedimento para estar más horas picando código. Y el argumento suele ser el mismo. «Las reuniones nos quitan eficiencia».

Las primeras preguntas que deberían surgir cuando alguien habla de eficiencia son las que me ha recordado Angel Medinilla en su tweet. : ¿Qué es para tí la eficiencia? ¿En base a qué la mides, qué métrica? y la que quizá es más importante: «¿Qué dejas de lado para conseguir esa eficiencia?

Por otro lado, en mi opinión, esta actitud forma parte de los remanentes de una cultura en la que el desarrollador sólo aportaba valor convirtiendo unas especificaciones a bajo nivel en código de programación. Mero «fagocitador de backlog» que su atención pasa de la tarea que tiene asignada en JIRA o sistema de gestíon de tareas similar, al Pull Request que hace para darlo por terminado. Nada más ni nada menos. El tipo de programador al que se le puede decir: «Programador, dame cuarto y mitad de código en Java». Su rendimiento unicamente se basa en la cantidad de código que produce.

Sin embargo y por suerte, cada vez queda más extendida la idea de que el desarrollo de software es una actividad social. No se puede pretender ser buen desarrollador y no hablar con negocio para entender de primera mano qué necesitan, sin hablar con otros compañeros como QA, diseñadores, expertos en BBDD etc.. si quieres asegurarte que aquello que estas haciendo encaja como un anillo en lo que ellos están haciendo.
¡¡ No puedes !!

Si eres de los que creen que para tí no son las reuniones, hazte la pregunta de qué es para tí trabajar y por qué esa definición no la ves en las reuniones a las cuales te invitan. Quizá te estás perdiendo una parte importante de tu trabajo, y personalmente para mi, muy motivadora. Y posiblemente sea porque nadie te ha explicado todo lo que implica el desarrollo de software. Quizá sólo estás viendo tu trabajo desde un agujerito en el que el escribir líneas de código es tu único propósito. E incluso, sí, ¿por qué no?, quizá eso lo único que quieras hacer. Y lo puedo respetar. Pero si es así, te recomiendo expresarlo claramente a tu equipo para que no se hagan faltas expectativas. Es posible que no piensen como tú.

También he visto que este problema ocurre de arriba a abajo en jerarquía. Puede verse como algo normal la actitud de no incluir a todo o parte del equipo en reuniones para que «no pierdan el tiempo ya que hay prisa en las entregas». Esto es un síntoma más de un liderago de tipo paternalista en el que se impide el crecimiento y maduración de los «niños» «por su propio bien». En fin…

Cada miembro del equipo debería ser capaz de elegir cómo usar su tiempo de forma más eficiente para aportar el máximo valor como profesional. Si es asistiendo a las reuniones de negocio para entenderlo mejor y evitar errores, que así sea. Si es juntandose con todos los implicados en una historia de usuario, para sincronizaros y comprobar que teneis la misma visión, que así sea. Si eres manager de un equipo, intenta no decidir por cada uno de ellos cómo gestionar su tiempo para ser buen desarrollador. Esta decisión es muy importante, compleja y personal.

Los miembros del equipo deberian entender qué valor da y qué propósito tiene cada tipo de reunion, qué aporta. El valor, aparte de la sincronización del equipo o tener conocimiento de producto, también podría ser el poder decidir en una retro cómo mejorar, e incluso podría ser el escuchar de primera mano del CEO de la empresa que «vamos bien», o «vamos mal» y saber que estamos todos en el mismo barco. Como manager lo que sí que puedes hacer es asegurarte que esto lo tengan muy claro para que puedan tomar sus propias decisiones.

Disclaimer: Todo lo escrito arriba no está en conflicto con hacer un uso inteligente de las reuniones e intentar hacer cada uno de la forma más efectiva y eficiente. Para esto hay miles de consejos y técnicas como el que haya un facilitador, tener agenda, centrarse en el objetivo de la reunión, etc.. E incluso, si hay reuniones que no aportan valor a nadie, naturalmente lo mejor es eliminarlas.

A vueltas con el refinamiento deL PRODUCT backlog

Vamos primero a revisar qué dice la Guía Oficial de Scrum sobre el refinamiento

Definicion oficial del refinamiento de sprint

El refinamiento (refinement) de la Pila del Producto (Product Backlog) es el acto de añadir detalle, estimaciones y orden a los elementos de la Pila del Producto (Product Backlog). Se trata de un proceso continuo en el cual El Propietario del Producto (Product Owner) y el Equipo de Desarrollo (Development Team) colaboran acerca de los detalles de los elementos de la Pila del Producto (Product Backlog). Durante el refinamiento de la Pila del Producto (Product Backlog), se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo (Development Team). Sin embargo, los elementos de la Pila del Producto (Product Backlog) pueden actualizarse en cualquier momento por El Propietario del Producto (Product Owner) o a criterio suyo.

De la definición oficial lo fundamental a entender es que el Refinamiento NO ES UN RITUAL como así lo son el Sprint Planning, Review y otras. Tampoco obliga a que haya presente ningún rol en concreto sino que únicamente habla del equipo.

Personalmente he trabajado con muchas interpretaciones de cómo se hace un refinamiento. Empecé trabajando con Scrum sin hacer nada explícitamente que se llamara como tal. Prácticamente todo el trabajo de análisis del Backlog, estimación y demás se hacía con el equipo durante el Sprint Planning. Más tarde, en mis tiempos de consultora informática trabajando para bancos, un grupo de expertos en cada área como el arquitecto, los Product Managers, seguridad y demás rellenaban todo lo posible la información del elemento de Backlog en JIRA y el refinamiento por parte del equipo era una mera lectura de lo que ya habían refinado otros ( 0% de posibilidad de aportación por su parte, 0% ownership, 0% creatividad por parte del equipo) . En esta última etapa de trabajo en la que estoy, el equipo al completo se reúne con Product Owner, revisa el backlog, le añade información, lo aclara y lo estima. Aquí lo que nos encontramos muchas veces es que algunos miembros del equipo consideran improductivas estas sesiones de refinamiento ya que la discusión a veces se centra entre un par de personas. Otras veces surgen dudas que se necesitan aclarar e investigar y opinan que hubiera valido la pena revisarlo bien antes de que llegue al equipo. Esto último incluso, a veces, esto provoca que se salte el refinamiento de esa historia de usuario a una siguiente sesión.

A nivel de flujos de información, en la actividad de refinar detecto dos flujos principales.

1.- Análisis o incorporación de información hacia el elemento del backlog. Aquí el conocimiento del equipo junto con otras personas con información de negocio, entorno (legal, técnico, …) , arquitectura y resto de áreas confluyen junto con la creatividad del equipo en una definición de la solución técnica que hay que realizar.


2.- Difusión de la información hacia el propio equipo. El equipo necesita entender el trabajo que hay que realizar. Una buena forma de saber que el equipo conoce su alcance es mediante el ejercicio de la estimación en conjunto. Es un buen indicador de que todos tienen en la mente el mismo tipo de trabajo cuando el equipo al completo coincide en la valoración y en los criterios por los que se ha llegado a la misma. El último momento responsable en el que debería ocurrir esta difusión de información es durante el Sprint Planning, ya que es cuando el equipo se dispone a empezar su desarrollo.

¿Quién hace falta que esté presente en cada parte? En el segundo flujo está claro que debe estar todo el equipo. Si algún miembro no participa en la difusión de información es posible que no sea capaz de trabajarlo sin bloqueos cuando llegue el momento
en el sprint.
Es en la primera parte de análisis en la que no no lo veo tan claro. Si participan personas que no tienen el conocimiento para aportar información al Backlog Item, solamente escucharán discusiones entre otros miembros hasta llegar a la solución final. No digo que esta discusión no pueda aportarles información a estos miembros del equipo más junior y veo importante que puedan colaborar para conseguir ownership del producto por su parte. Sin embargo, dependiendo del nivel de maduración de cada uno dentro del equipo , puede haber otras formas más eficientes de conseguir estos mismos objetivos que sentándose juntos sólo a escuchar.

Mi propuesta es la participación de miembros de forma incremental y con un ángulo que depende de la maduración del equipo.
En equipos pocos maduros donde hay un líder que tiene mucho conocimiento, habrá mucho trabajo de análisis por su parte y este ángulo de colaboración hasta llegar a todo el equipo sería más cerrado. En equipos muy maduros, las fases de análisis y difusión se hacen de forma simultanea y eficiente, ya que todos pueden aportan a la solución y se enteran a la vez de qué hay que hacer. Aquí el ángulo sería muy abierto o casi inexistente.

Dentro de estas dos formas opuestas también hay matices o grises. Quizá los miembros que son más seniors hacen el análisis y después se revisa con el resto del equipo. Quizá puede empezar el Tech Leader con Product Owner y preparar un esbozo de la solución que se afine con el resto.
Independientemente de cómo se haga, veo importante,de vez en cuando, si se hace una sesión de refinamiento de equipo, evaluar cómo consideran los propios miembros del equipo cuánto ha sido de productiva la sesión. De este modo pueden aflorar síntomas de algo que no esta funcionando bien y podría mejorarse hablándolo en la siguiente retrospectiva. Inspeccionar y adaptar, la base de Scrum.

Visualiza los flujos de comunicación de tu equipo con sociogramas

Hace dos artículos hablé de lo importante que es que los flujos de comunicación en un equipo sean lo más homogéneos posible para conseguir que un equipo sea de alto rendimiento. Esto quiere decir que cada uno de los miembros hable con el resto con similar frecuencia sin que haya nadie que monopolice o encauce la comunicación del resto ni nadie que esté más aislado.

Para detectar qué tal está la comunicación en tu equipo, una herramienta muy potente son los sociogramas. Esta herramienta permite visualizar gráficamente los flujos y la frecuencia en que los miembros de un equipo hablan o se escriben entre ellos. Esta herramienta se usa en otros ámbitos como por ejemplo en la educación y permite identificar niños que estén aislados o que tengan problemas de relacionarse con su clase.

Hay muchas formas de generar el sociograma, ya sea por análisis de una descarga del Slack o con tarjetas de proximidad. Sin embargo, con una simple encuesta se puede conseguir resultados muy potentes y con poco trabajo. Un ejemplo del que uso yo con mis equipos lo puedes descargar aquí. Preparas el documento con los miembros del equipo que quieres analizar y lo envías a todos y cada uno de los miembros. Sólo requiere un minuto de cada uno del equipo por lo que no hay excusa.

El resultado lo pasas a excel, que será lo que te ofrecerá la primera visión de la comunicación del equipo. Este excel no es más que una tabla de NxN de los integrantes del equipo con su nivel de comunicación entre ellos. Para que sea visual se marcan colores según el nivel de comunicación entre cada dos miembros. Ejemplo de un excel puedes descargarlo aquí.

El último paso es analizar la información y generar el sociograma. Yo hago 2 tipos de reporte. El primero es una distribución por clusters o sub-equipos en el que se pueden identificar (si los hay) subgrupos de gente que hablan más entre sí que con el resto de compañeros. También se identifica si hay algún miembro de equipo que es el nexo entre los sub-equipos, normalmente marcando un liderazgo que genera un cuello de botella. Un equipo de alto rendimiento no tendrá sub-equipos ni personas que filtran comunicación entre otros miembros.

Ejemplo de sociograma en el que se identifica dos subequipos por las capas técnicas.
Ejemplo de sociograma en el que no se identifican sub-equipos aunque sí que la comunicación entre los miembros es desigual.

El segundo tipo de gráfico que genero es el resultante de sumar todos los puntos de comunicación por cada miembro. De este modo se ve la persona que más se comunica con el resto y la persona que menos. Un equipo de alto rendimiento debería tener más o menos las mismas puntuaciones. Sin embargo, es común encontrar miembros con valores más altos en comunicación que nos indican que estas personas tienen algún tipo de liderazgo. También se identifican miembros del equipo con poca comunicación. Estos últimos muchas veces se debe a una persona que no esta localizado geográficamente con la misma cercanía que el resto.

En este gráfico identificamos mucha comunicación entre los miembros del equipo excepto con LL (miembro no co-locado con el resto) y muy poca comunicación con el Product Owner (PROBLEMA).
Aquí vemos un equipo con bastante heterogeneidad de comunicación. Hay dos miembros (FF y MR) que prácticamente no se comunicaba con el resto del equipo. Se trabajaba mucho dependiendo del Project Manager que era quien dividía el trabajo, haciéndose cuello de botella.

El sociograma es una herramienta que uso con todos los equipos con los que trabajo. Lo he usado para tomar una foto de la comunicación antes de una implantación ágil y otra foto después de un tiempo trabajando con Scrum. También lo he usado como objeto de estudio en una retrospectiva para que el equipo sea consciente de sus flujos de comunicación y ellos mismos sean los que proponga las mejoras y los auto-compromisos. Espero comentarios si los usáis.

Empieza 2019. Mis artículos más leídos hasta el momento.

Después del intenso año de preparar la CAS 2018, es tiempo de reflexión y seguir trabajando en esas cosicas que me gustan. Entre ellas mi blog. Para saber de qué debo seguir escribiendo he hecho el ejercicio de saber cuáles son mis artículos más leídos.  Os paso el TOP 5.

Numero 5:  Wastes o desperdicios en desarrollo de software

28/10/2014. Identificar los desperdicios o wastes es muy importante, tanto en el desarrollo sofware como en cualquier tipo de trabajo.  Ser más rápidos que la competencia y aprovechar hasta el último euro o movimiento, músculo o neurona para que el producto ser más competitivo requiere buscar continuamente la eficiencia.  ¿Cuánto hace que no repasáis los desperdicios en vuestro trabajo? ¿Lo habéis hablado en una retrospectiva últimamente?. Hace poco con el equipo hablé del waste de defectos asociado a los requerimientos incompletos o cambiantes. Los agilistas intentamos reducir este waste, no bloqueando cambios de requerimientos que es lo que primero se puede pensar, sino reduciendo el impacto en cantidad de trabajo supone asumir cambio.

Número 4: Planificación estratégica Ágil mediante Releases

17/1/2013. Más allá de la mera visión táctica de los sprints, la creación de software requiere una planificación a medio plazo. Además, en una empresa que requiere la coordinación de varios equipos verticales, todos deben conocer qué se va a hacer, quién lo va a hacer y cuándo se va a entregar. Un tema muy importante sobre lo que no comenté nada es que hay que ir informando del avance, no sólo al final del Release sino también en cada sprint. Tanto el Product Owner como los stakeholders deben ir viendo lo que se va construyendo para que no haya sustos al final del sprint.

Número 3:  La importancia del término “software funcionando”

26/12/2016. Este artículo lo escribí tras uno de mis mayores errores como Scrum Master, dar por bueno un avance de software en el que solamente se iba entregando las capas frontales pero sin una integración real con los sistemas que funcionan por detrás. Esto da una falta visión de avance de proyecto y se acaba con una bola de nieve de software por integrar que acaba poniendo gravemente en peligro la entrega.

Número 2Algo llamado “Declaración de Interdependencia”

21/2/2014. No puede haber un nombre más aburrido para algo tan importante como una declaración de principios como los ágiles pero solamente aplicados a la gestión de proyectos. Sigue habiendo proyectos en los que se ve a las personas como recursos, moviéndolos de un sitio a otro, con instrucciones a bajo nivel sin compartir la visión de lo que se está haciendo y sin dejarles aportar. Este es el camino al fracaso del proyecto y del producto que se está construyendo.

Y el top de los top…

Número 1:  Eduard Estivill, Carlos González, Rosa Jové ¿Qué hago con mis niños a la hora de dormir? 

29/10/2011. Este es el artículo que hace que me replantee el segmento al que escribir. En un blog sobre Agile el más leído es sobre infancia. Es lo que tiene ser padre y tener también otras prioridades en la vida. Imagino que es lo que le ocurre a todo aquel que ha entrado a leerlo, que da igual en qué trabaja o cuál es su pasión. Todos caemos en los mismos temas conforme nuestros hijos crecen. Es bueno que ocurra porque significa que nuestras prioridades no son únicamente el trabajo sino nuestras familias. Sin embargo, como leí hace tiempo y confirmé hace poco en el libro que estoy leyendo de Tim Ferris Tribe of Mentors, «…escribe como si hubiera un millón de copias de ti mismo y espera que te encuentren». Tranquilo que no me convertiré en un investigador de puericultura, que ya hay gente muy buena sobre esto y no quiero entrar en un mundo en el que existe más radicalismo de opiniones que en el propio fútbol.

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

Las 5 disfunciones de un Sprint Planning

Hace poco facilité un Spring Planning en el que todo fue mal. Sólo un miembro del equipo se comunicaba con el Product Owner y el resto se quedaba callado protegido por el muro que ofrece la distancia y la audioconferencia.  Justo al terminar me llegó la información por parte de algunos miembros del equipo de que lo planificado en el sprint no tenía sentido, que no habíamos tenido en cuenta ciertas cosas.  Cuando lo escuché sentí que lo que de verdad no tuvo sentido fue la reunión en sí misma ya que no se pudo pactar el objetivo del sprint.

Hace poco me leí el libro de Patrick Lencioni sobre las 5 disfunciones de un equipo.  En este libro en forma de novela se tratan los problemas que suelen tener los equipos que no consiguen trabajar de forma colaborativa y estas disfunciones acaban viendose en los sus resultados. Estas mismas 5 disfunciones se dieron juntas en el propio Sprint Planning y voy a explicar por qué. Espero que  te ayude a identificar si ocurre lo mismo  en tu equipo Scrum.

5 Disfunciones de un equipo

Ausencia de confianza.
El equipo debe tener la misma confianza que tiene cuando se reune con sus amigos a hablar de fútbol. Debe poder ser capaz de preguntar todas sus dudas, levantar la mano  y decir lo que se le ocurra como «no lo entiendo» o «lo que dices no tiene sentido»  y hacer estimaciones sin miedo a represalias. Yo he participado en Sprint plnnings en los que además de los miembros del equipo Scrum había varias personas de la PMO (Project Managemenet Office) monitorizando y atendiendo a todo lo que se iba diciendo. Esto no ayuda a que el equipo se sienta cómodo y seguro en la sesión. Hay que estar atento a estas personas como por ejemplo algun lider técnico que reprocha cualquier intervención de sus compañeros con aire de superioridad
Mi compi de GFT @fedcasabianca como apertura de un curso sobre retrospectivas nos pidió valorar «¿Cuanto de seguro te sientes sobre dar tus opiniones?». Esto es muy importante evaluarlo antes de empezar un Sprint Planning. Además identifica si hay gente conectada de forma remota o asistiendo en la reunión que no han sido invitados por ninguno de los miembros del equipo Scrum. Preguntadles cuál es su rol para la reunión de sprint planning. Recuerdales el objetivo de la sesión y que quizá lo dificultan con su presencia (Principio de Incertidumbre). Sí notas que afecta al equipo y está dentro de tus posibilidades, intenta que no asistan. Lo importante es el propio equipo y que se sientan seguros .

Temor al conflicto
Cuando el equipo no se siente seguro en la sesión de planificación no surgen conflictos. No se discute nada.  El Product Owner dice cómo lo quiere o todo lo que necesita que esté en el sprint y el equipo asiente sin discrepar. O el considerado lider técnico da una valoración o una solución técnica y el resto la asume sin ponerla a juicio. En una sesión de Sprint Planning debe haber mucha comunicacion entre todos los miembros del equipo Scrum, incluyendo sobre todo quien es la voz del producto. Toda persona que no discuta un tema lo más seguro es que no lo haya entendido bien y tenga que preguntar qué hacer o cómo hacerlo a mitad de sprint, poniendolo en peligro.
Como herramientas en las planificaciones que ayudan a disminuir esta disfunción se viene usando el Planning Poker. Precisamente se usa porque al poner las cartas todos boca abajo y darles la vuelta a la vez, todos dan la estimación sin conocer la del resto. Cuando un miembro del equipo da una estimación que discrepa de las otras, debe hablarse (generarse el conflicto necesario) para que su opinión se tenga en cuenta o al menos se escuche y evalue. La persona que ha dado esa estimación distinta debe quedarse con la sensación de que al menos se ha escuchado su criterio.

Falta de compromiso
Según la guía de Scrum cuando termina el Spring Planning, el equipo y el Product Owner acuerdan un objetivo de sprint. La palabra «acuerdan» es muy importante. No es una imposición al equipo por parte del propietario de producto.  El equipo es la unica entidad que establece la cantidad de trabajo que puede asumir. Sin embargo, en muchos equipo no es así o los propios miembros no lo ven así. La tradicion waterfullista de agendas apretadas ha calado durante muchos años y algunos equipos esperan que les impongan los backlog item a meter en el sprint sin tener en cuenta lo que realmente pueden hacer. Esta imposición provoca que los que van a desarrollar no sientan que ese objetivo les pertenece y no lo asuman como propio.  Cuando esto ocurre puede pasar que finaizar el planning y alguien diga  «Eso no lo hacemos ni de coña». O peor aún, se asuma de forma silenciosa independientemente de cómo acabe todo.
El equipo debe sacar a la luz cuánto de realista el es objetivo de sprint antes de dar el objetivo del mismo por pactado. Para ello una herramienta que se usa es la votación con el puño de cinco.  Se les pregunta a los miembros del equipo de desarrollo cuánto de realizable es el objetivo del sprint con valores entre 0 – «Ni de coña» y 5 – «Lo hacemos con la patilla».  La votación de cada uno lo tienen que mostrar en conjunto levantando la mano por encima de la cabeza sin verse influenciados por el resto.  Si se está en remoto se puede usar una herramienta tipo planning poker remota para esta votación. Es importante que quienes pongan valores bajos expongan sus razones. Quizá saben algo que el resto no.

Evitación de las responsabilidades
Cuando el equipo siente que el objetivo del sprint ha sido impuesto, lo trabaja sin sentirlo como suyo. Eso hace que por ejemplo cuando se ve acercarse el final de sprint y se detecta que quizá no se puede entregar todo, no les importe y no tengan el compromiso de colaborar entre todos para conseguirlo. Con esto no estoy hablando de hacer horas extras. Con esto quiero decir que el equipo  no tiene el sentimiento en que en parte se han fallado a ellos mismos y no sienten la necesidad de mejorar como equipo sprint tras sprint. Sin esta sensación no tienen la motivación suficiente para llegar a convertirse en un equipo de alto rendimiento.
Para detectar y mejorar esto, en las retrospectivas al final del sprint se debería evaluar las razones por las cuales algo ha salido del objetivo.  El Product Owner, aunque sin llegar al reproche, sí debería transmitir la importancia de intentar cumplir el objetivo pactado, sobre todo si el no cumplirlo es algo que ocurre de forma frecuente. El alto rendimiento debería ser objetivo de todos y si a nadie le importa que no se entregue todo, el equipo puede llegar a la autocomplacencia y estancamiento.

Poca atención a los resultados
Todas estas disfunciones concluyen en que el equipo no siente el producto como suyo.  No sienten los triunfos del resultado de su trabajo como suyos. Por ejemplo no les imporata cuando se consigue que el producto llegue a hitos como una alta tasa de descargas o uso por millones de personas. Tampoco sienten como suyos problemas que afectan al producto como por ejemplo el no haber conseguido activar la campaña de Navidad a tiempo y perder muchisimas ventas. Cuando estos problemas ocurren puede ser normal en un equipo disfuncional echar la culpa a elementos externos como «a quien gestiona el proyecto», a «negocio» o a otras partes implicadas.  Sencillamente es un equipo que va «fagocitando» historias de usuario del backlog y convirtiendolos en software funcionando sin mayor visión. Esto puede ocurrir independientemente de si se usa Scrum, Kanban o Waterfall como metodología.
Para detectar esta disfunción es tan fácil como ver si al equipo le importan metricas de producto como número de usuarios, funnels de tendencias de uso, las opiniones de los usuarios, etc.. Hazte preguntas como: ¿Le suelen preguntar al Product Owner sobre cosas relativas al uso del producto? ¿El Product Owner les comparte el avance del producto, a dónde quiere que vaya en medio largo plazo y para el equipo es algo que le interesa?

He creado este formulario de Google  para recordarme y ayudarme en los Sprint Planning a recabar esta información sobre estos problemas. Espero que en dos o tres sprints haciendo esta evaluación y usandolo como dato en las retrospectivas  me ayude a identificar estas disfunciones y estudiar entre todos formas de mejorar. Feel free de copiartelo o adatarlo.

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.