Charla sobre Scrum en mundos imperfectos

El viernes 27 de Mayo estuve dando una charla sobre Scrum en mundos imperfectos como parte de las actividades de AgileAlicante. Fué en las instalaciones de Sistel en Alicante, ofrecidas gustosamente a la comunidad para la celebración del evento.

Hablé de los requerimientos que tiene Scrum y que hacen que sea un framework hyperproductivo. Sin embargo estos requerimientos no son siempre fáciles de conseguir pero ello no quiero decir que cualquiera no pueda beneficiarse del agilismo y usar parte de lo que propone Scrum.

Hubo 15 apuntados (llenado el aforo) y como me gusta a mí, la conversación posterior fue muy interesante. Los asistentes comentaron sus dudas y problemas, sobre todo relacionados a la estimación y el presupuestar a clientes en base a proyectos, sprints o incluso historias separadas. Al no tener pizarra no puede explicar bien cómo propongo hacerlo pero haré un artículo en breve sobre ello.

Las diapositivas de la presentación puedes verlas aquí.

Quizá repita más veces el formato de mini-evento para que la comunidad AgileAlicante se conozca un poco más y que no quede solamente el University Day de Octubre.

Las palabras del Daily Standup se las lleva el aire

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

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

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

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

TarjetaObjetivos

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

 

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?

¿Incluyo el trabajo de documentación en la estimación de historia?

Esta es una duda que nos surgió este sprint y que seguro que surge en más de un equipo. Aquí viene mi análisis.

Opción 1) Si todo el trabajo del escritor técnico está incluido en la capacidad del equipo o es un porcentaje fijo y no  realiza historias aparte de documentación.

En este caso, todas las historias tienen su parte de documentación, más pequeña o más grande. En este caso, en circunstancias estables, el equipo al completo desarrolla a una velocidad estable. Es importante valorar bien la parte del manual en las historias de desarrollo porque podría pasar el no llegar a completar el número esperado de historias, ya que la parte del manual que corresponde se había infravalorado.

Si la documentación NO forma parte de la definición de DONE de la historia. Como se puede realizar la documentación en otro sprint, tendríamos que revisar el tamaño estimado de esa historia cuando no se va a realizar en ese momento la documentación.

 

Opción 2) Si sólo una parte variable del trabajo del escritor técnico afecta al trabajo del equipo.

En este caso recomiendo no incluirlo, ya que impediría obtener la capacidad de la parte del equipo que sí que aportan el 100% de su tiempo. Podría pasar que distintos sprints en las mismas condiciones se tuvieran velocidades distintas dependiendo de si tienen más o menos trabajo en el manual. Haría más difícil la planificación por la variabilidad de esta velocidad del equipo.

Si la documentación SÍ está incluida en la definición de DONE, recomiendo una doble estimación, la del tamaño del desarrollo y de la propia documentación. En este caso, el equipo que está en el desarrollo del producto puede planificar cuántas historias desarrollar en base a su velocidad como equipo y el escritor técnico tener en cuenta su aportación y tenerla en cuenta a la hora de planificar su propio sprint junto con otras historias propias.

 

La ventanita para la motivación

Tenía la edad de 10 años cuando el artista foguerer del pueblo (el que hacía la hoguera para las fiestas de Sant Joan) usó un local de los bajos de mi edificio para montar la hoguera de ese año. Después de hacer acopio de valor, me ofrecí a ayudarles en lo que pudiera. La mayor parte del tiempo solamente ayudaba a aguantar los listones de madera mientras los cortaban (eso sí, siempre haciendo la presión en el punto exacto necesario). Un día hice lo que para mi fue mucho más que eso, pude pintar un trocito de la hoguera, de 10 cm cuadrados más o menos. Eso para mi fue lo más. ¡Qué contento estaba cuando la hoguera estaba expuesta y yo miraba con orgullo y enseñaba a mi familia mi aportación, ese trocito del monumento que todo el mundo podía admirar!.

La visión global y la aportación personal es algo muy importante para la motivación personal. Sin embargo, dependiendo del tamaño de la empresa y el puesto que cada uno esté haciendo, puede ser muy difícil hacer llegar esa visión a todos. En empresas medianas y grandes, es posible que la única interacción de los desarrolladores con el resultado de su trabajo completado es cuando dejan las nuevas versiones listas para que otro departamento como el de operaciones lo instale. Una vez hecho esto, sólo les queda esperar a que el nuevo sprint empiece y tengan una nueva lista de cosas por hacer.

Aportar esa visión del trabajo realizado y cómo forma parte de algo mayor y más importante es una parte crucial de nuestro papel cómo líderes . Tienen que saber que cada palada de remo suyo hace avanzar el barco. Para ello es necesario que puedan ver al menos por una ventanita las cosas buenas y malas que ocurren en la empresa como resultado de su trabajo y el del resto de compañeros. Existen herramientas como los OKR que usan en Google y sistemas como Hoshin Kanri que ayudan a aportar esta visión y alineación pero cualquier esfuerzo que se haga por parte del lider en esta línea, debería aportar resultados satisfactorios en la motivación del equipo. ¿Tiene tu equipo esa ventanita?

Mi retrospectiva personal de entrada del 2016

Ya estamos a 1 de Enero del 2016. Es tiempo de buenos propósitos igual que el mes de septiembre. Las personas nos ponemos objetivos que muchas veces se quedan en el aire. Una buena forma en la que perduren un poco más y sean más efectivos es hacerlos públicos. El tenerlos escritos también sirve para que podamos evaluar en el próximo año cuántos de estos objetivos se han conseguido.

Yo este principio de año voy a hacer una retrospectiva personal.  Como hacemos en VSN cada final de sprint (periodo de 3 semanas) voy a usar el método llamado la estrella de la retrospectiva. Con esta forma de hacer retrospectiva se identifican acciones que encajen en una de las 5 puntas de estrella que corresponden con aspectos positivos que reforzar y negativos que mejorar.

  • Empezar a …
    • Tener un equipo de colaboradores para AgileAlicante.
  • Hacer más …
    • Actividades y viajes con mi familia.
    • Escribir artículos en mi blog para consolidar y compartir conocimientos.
    • Ayudar a la gente cercana a mi.
  • Seguir haciendo …
    • Deportes que me gustan como el Judo, correr y patinar.
    • Estudiar los temas que me gustan: agilismo, liderazgo, motivación…
  • Hacer menos …
    • Evitar las confrontaciones o negociaciones.
  • Parar de …
    • Estudiar temas que para mi no tienen ningún objetivo personal claro.

 

 

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

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

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

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

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

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

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

 

Fuentes

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

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

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

Sobre la transparencia y los tests hechos por desarrolladores

Hace poco me contaron que un CEO de nuestra competencia vio un vídeo en Youtube diciendo que no teníamos equipo de QA. El vídeo en cuestión es la charla que di para el Lean Kanban South Europe 2015. En esta charla hablaba de cómo usabamos Kanban para reducir el tiempo de feedback entre desarrollo y testing y cómo podíamos responder a requerimientos de proyectos, a soporte y además avanzar en producto.

Mi frase  “No tenemos ningún tester ni equipo de QA” se sacó de contexto y se usó como comentario para crear malestar. En VSN tenemos cerca de los 2000 tests automáticos que se pasan varias veces al día y que incluyen de unidad, de integración y de interfaz. Tenemos procedimientos muy concretos, certificados con una ISO 9001 sobre hacer el test cuando terminamos de desarrollar y además realizamos una batería completa de tests manuales de regresión en la que todo el equipo comprueba de manera transversal todo el producto antes de dar por buena una entrega. Usamos muchas de las técnicas incluidas en las certificaciones internaciones de Agile Testing. El no tener equipo de tests separado cada vez se está adoptando más para conseguir una respuesta rápida al cliente sin bajar en calidad. Además empresas como Atlassian estan descubriendo y demostrando que los desarrolladores pueden ser buenos testers. Piensan igual que yo que cuando los desarrolladores tienen el mismo criterio de calidad que los testers, los productos de alta calidad se CONSTRUYEN desde el principio.

Volviendo al tema de la charla, creo que el hablar sobre cómo trabajamos en VSN es más beneficioso que perjudicial. VSN cada vez está mas presente en charlas y conferencias a nivel nacional e internacional. Aquellos que usan frases sueltas de lo que decimos  y basan su “perfección” en su oscurantismo son los que deberían reflexionar sobre cómo hace las cosas. Nosotros esta reflexión la hacemos cada 3 semanas desde hace más de 6 años de manera contínua y es la que nos permite ser cada vez mejores, piensen lo que piensen otros.

 

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

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

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

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

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

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

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

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

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

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

Objetivos. Poder cumplir objetivos personales o profesionales.

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

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

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

 

 

Ten un Maestro Elodin en el equipo de desarrollo

“Words are pale shadows of forgotten names. As names have power, words have power. Words can light fires in the minds of men. Words can wring tears from the hardest hearts.” 
Patrick Rothfuss, The Name of the Wind

En VSN hemos contratado hace unas semanas a un escritor técnico. Su misión principal es escribir los manuales que incluiremos y estarán enlazados desde nuestro software para consultar rápidamente.  Pero su colaboración hacia el equipo de desarrollo está yendo mucho más allá.

“Every time you write a comment, you should grimace and feel the failure of your ability of expression.”
Bob Martin, Clean Code 

Muchas veces es difícil encontrar la palabra adecuada para esa variable, método o clase cuando estamos desarrollando. Para no quedarnos parados indefinidamente pensando acabamos añadiendo un comentario que explica su uso.

En el caso de manuales ocurre lo mismo respecto al software que documentan, existen por la incapacidad del software de ser autoexplicativo. Para que no hiciera falta manual, cada botón, etiqueta y elemento del interfaz debería indicar por sí mismo y de modo preciso qué es y para qué sirve sin tener que consultarlo en un manual. Esto implica que el equipo de desarrollo debe encontrar el nombre perfecto en cada ocasión, lo cual es una tarea nada fácil. En los libros de Rothfuss el encontrar el nombre perfecto de las cosas es la habilidad de los llamados maestros nominadores, como el Maestro Elodin.

Ahora tenemos la suerte de que David Branco, nuestro escritor técnico, esta cumpliendo este rol. Siempre tiene para nosotros la palabra precisa que necesitamos para poner el nombre a un nuevo tipo de almacenamiento, el texto de una etiqueta o del botón que estamos añadiendo para que exprese de modo preciso su misión. Ya tenemos nuestro Maestro Elodin.