Archivo de la etiqueta: Project Management

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.

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.

 

 

La importancia del término «software funcionando»

Uno de los 12 principios ágiles dice claramente «El software funcionando es la medida principal de progreso».  Esto puede parecer muy claro cuando se están leyendo los principios de inicio a fin pero tiene aspectos que deben tenerse en cuenta.

¿Qué significa «software funcionando»? Seguramente haya tantas respuestas como ingenieros tecleando código. Una forma de llegar a un consenso de equipo sobre los criterios que lo forman es hacer entre todos la Definition of Done (DoD). Estos criterios pueden contener aspectos como mínimos de cobertura de test, de validación de código según reglas de Sonar u otro analizador, de tests manuales realizados por un QC, etc .. y no servir absolutamente para nada.

Hace poco en un proyecto subestimé la importancia de lo que significa «software funcionando». Me di cuenta de que debe contener todos los criterios que hagan del sofware que se está produciendo una herramienta real y completa. Con completa me refiero a que de nada  sirve probar historias de usuario ejecutadas sólamente con datos moqueados porque los servicios web (que posiblemente haga un tercero) no están listos, tampoco sirve que estas pruebas se ejecuten en un entorno que no tiene que ver con el entorno real en el que se va a vivir la aplicación… Si en el proyecto faltan integraciones, fases de deploy o cualquier otro paso posterior  estamos desarrollando en un sistema Waterfall por sprints, no estamos en un proyecto Agile.

Si no vamos realizando todas las fases imprescindibles (from concept to cash) de todas las historias de usuario completadas, estas no serán más que papel mojado y al terminar «nuestro trabajo» entraremos en un entorno de incertidumbre sin saber cuándo va a funcionar de verdad todo eso que hemos estado enseñando en los Sprint Reviews. El cliente seguramente ya no creerá en el proveedor cuando le muestre el progreso en historias completadas y perderá la confianza en eso que llamamos Agile.

Para evitar estos problemas, asegurate de tener el entorno real (o como el real) lo antes posible, asegurate de integrar todas las piezas conforme se va construyendo el software.  Si no lo consigues porque está fuera de tus dominios, al menos, ten claro que ha dejado de ser un proyecto Agile.

 

Sentándose un día con un desarrollador

En Lean cuando hablamos de Gemba, significa que los que están a cargo de un equipo o una empresa se paseen o estén donde realmente ocurre la acción. En las plantas de producción tradicionales estos lugares son los pasillos donde se elabora el producto. En desarrollo de software el Gemba sólo se puede realizar sentándose con el propio desarrollador.

Sin embargo, lo normal es que cuando un líder, jefe o responsable se acerca para ver cómo está trabajando el desarrollador, éste se ponga en modo inspección y empiece a explicar qué está haciendo y cómo lo lleva. Lo que ocurre en ese momento es el Principio de Incertidumbre, lo que se quiere estudiar cambia su comportamiento solamente por observarlo. También es normal que el líder, después de esta más o menos breve explicación se levante y vuelva a su puesto dejando que el desarrollador continúe para no interrumpirle más.

¿Es esto suficiente? ¿Se pueden saber así los problemas reales con los que se enfrenta y ayudarle a realizar mejor su trabajo? Mi respuesta es que no. Para hacer un autentico Gemba hace falta que el desarrollador trabaje como si no estuvieramos ahí. Para ello tenemos que ponernos en pair programming y sentarnos al menos un día completo con él para que «se olvide de las cámaras».  Trabajando juntos de este modo empezaremos a conocer sus problemas con el  framework, la arquitectura, lo que le cuesta un cambio de requerimientos, de datos de entrada, etc … . También en esas condiciones son en las  que podemos hacer coaching y enseñarle cómo organizar mejor el código, mejorar en TDD para desarrollar con mejor calidad y ayudarle a ser más productivo y ágil.

¿Cuánto tiempo hace que no te sientas un día completo con un desarrollador?

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>

Los tres primeros pasos en la gestión Ágil/Lean

Cuando uno empieza a querer organizar su forma de trabajar quizá lo que aporta Internet es demasiada información. Hace falta saber qué buscar para conseguir lo que necesitas para empezar a cambiar. Después de todos los años que llevo estudiando y aplicando las metodologías ágiles lo que aconsejo siempre es empezar con 3 sencillas cosas. El ABC de la gestión Agil.

1.- Daily Standup. Reuniones de máximo 15 minutos con los miembros del equipo en posición de pie en la cual cada uno comparte en qué trabajo el día anterior, en qué va a trabajar y qué obstáculos o problemas tiene en su camino.

Consejos:

  • No debe ser un informe al jefe. La información es de todos para todos
  • Debe empezar lo antes posible para que de pistoletazo al día pero que este presente el máximo número de personas
  • Si se abre un tema que necesite discusión larga se deja para después del daily.
  • Gente fuera del equipo puede hacer participaciones cortas que ayuden a algún problema. Lo fundamental es no pasarse de los 15 minutos.

2.- Tablero kanban. Panel en el cual hay una columna por fase por la que pasa cada elemento de trabajo representadas por etiquetas. Estos elementos pueden ser historias de usuario, diseños que hay que hacer, máquinas que montar, arreglar, etc.. Cada mes se limpian las etiquetas completadas en la última fase. Cada miembro del equipo mueve la etiqueta de una columna a otra según se va completando. Permite una visión común de cómo va el trabajo y permite tomar decisiones de mejora y de eliminar los bloqueos.

Consejos

  • Ponerlo en un lugar visible y accesible para todos
  • No debe haber más de 20 etiquetas por equipo para que se pueda ver de modo más sencillo
  • Debería haber límites máximo por columna aunque sean altos a principio. Si llega un momento en el que se supera ese límite debería analizarse la causa del problema y mejorar.
  • Ir bajando ese límite máximo según se va mejorando para conseguir un sistema más lineal y eficiente.

3.- Retrospectivas. Reunión a final de mes en cual se junta el equipo para ver qué han hecho bien y qué pueden mejorar. Se puede usar el método del barco  para además identificar las minas, es decir, los elementos externos que os afectan como equipo y para las que tenéis que estar preparados. No debería durar más de una hora u hora y media.

Consejos:

  • Sinceridad pero sin buscar culpables. Algo mal hecho es porque no se tenía conocimientos o herramientas para hacerlo mejor. Esta reunión sirve para buscar estas cosas.
  • Los problemas encontrados deberían buscarse soluciones. Asignar responsables para trabajar en ellas.
  • Se puede usar para dar pequeñas formaciones que ayuden al equipo. Club de lectura, vídeos de Internet, etc..

Con estas tres herramientas cualquier equipo puede empezar a trabajar mejor y de forma más organizada. Es posible que se vean nuevos problemas y se piense que antes no estaban, pero seguramente sea porque antes no se veían. Surgirán problemas que estaban ocultos y que ahora salen a la luz. Permitirá que surjan nuevas necesidades para ir mejorando cada vez más vuestro método de trabajo. Es posible que necesitéis nuevas herramientas para cubrir esas necesidades pero estas tres herramientas básicas os acompañarán día tras día.

Conseguir el ISO y el CMMI3 sin dejar de ser Ágiles, interesante reto

Este año en VSN nos hemos propuesto a pasar la certificación ISO para poder optar a proyectos en que lo requieren. Estamos con la ayuda de un consultor que nos va diciendo lo que tenemos que hacer.

De momento lo que vamos haciendo consiste en documentar todos nuestros procesos internos. No parece más que dejar bien por escrito todo lo que hacemos de manera corporativa. En desarrollo es concreto me toca escribir cómo manejamos los requerimientos en sprints, cómo hacemos seguimiento mediante los dailys y el Diagrama de Flujo Acumulado, como aseguramos la calidad mediante los tests automáticos y manuales. Como hemos ido escribiendo todo lo que ibamos estandarizando en las retrospetivas tenemos bastante escrito.  Sobre todo parece que hay que tener manual de todo lo que se desarrolle. No puede salir un desarrollo nuevo sin un escrito en el que se dice qué y cómo funciona. Yo espero que lo que escribimos como procedimiento de test para que otro desarrollador lo pruebe sea suficiente documentación.

Aparte del ISO se nos recomienda tener una certificación concreta de software. Yo estoy seguro que podemos optar a un CMMI 3 también con el modo ágil en el que trabajamos. De momento me toca ir empollando bien qué piden y si nos falta algo más que gestionar. Cuento con que mejoremos sin dejar de ser ágiles. Veremos si en lo que escribí a mediados de 2009 tenía razón.

Iré contando los avances…

Algo llamado «Declaración de Interdependencia»

De nuevo en el libro de David J Anderson, descubrí algo llamado «Declaration of Interdependence» DOI. En español, Declaración de Interdependencia. Esto fue una redefinición del manifiesto Agil pero centrado solamente en la gestión de proyectos. Sus autores forman la creme de la creme en gestión de proyectos ágiles con nombres como el propio David J Anderson, Alistar Cockburn o Mike Cohn.

Sus puntos son:

Incrementamos el retorno de la inversión (ROI) centrándonos en un flujo contínuo de valor.
Habla de dar valor al cliente de forma más continua posible. Mejor iteraciones de 2 semanas que de 3. Mejor aportaciones diarias que cada 2 semanas. Lo que necesita de forma más rápida posible desde el momento que lo necesita.

Entregamos resultados fiables haciendo participes a los clientes en interacciones frecuentes y compartiendo la propiedad.
El cliente debe formar parte activa del resultado. Cuando más participe en la definición de producto y en su revisión frecuente mejor adaptado estará a sus necesidades.

Esperamos lo inesperado y lo gestionamos mediante iteraciones, anticipación y adaptación.
El mundo es caotico por naturaleza. Lo que es cierto por la mañana deja de serlo por la tarde. Los procedimientos de trabajo tiene que ser flexibles y con ciclos cortos para poder seguir dando valor en estas condiciones.

Damos rienda suelta a la creatividad y la innovación reconociendo que los individuos son la fuente última de valor, y creando un entorno en el que puedan diferenciarse.
Los desarrolladores son los que crean. Cárgalos de stress en un entorno de trabajo restringido y obtendrás resultados mediocres.  Déjalos que disfruten con lo que hacen y dales los medios oportunos y crearán grandezas.

Disparamos el rendimiento mediante la responsabilidad  común sobre los resultados y sobre la propia efectividad del equipo.
No hay equipo más eficiente que aquel que está motivado y se le dan las herramientas para que ellos mismos hagan su trabajo más rápido y con mejor calidad.

Mejoramos la efectividad y la fiabilidad mediante estrategias, procesos y prácticas especificas para cada situación.
Existen muchas metodologías pero no hay una sola que funcione para todos los entornos. Hay que probar, medir y adaptar hasta encontrar el sistema que mejor funcione (mientras funcione).

Estos son los 6 puntos que habla la DOI. Puntos para reflexionar e interiorizar poco a poco. Puntos muy importante para quien quiere agilizar el desarrollo de software pero… David tiene razón.¡ Qué pena de nombre !.