A vueltas con el Manifiesto Lean Kanban

Hace un par de semanas vi este tweet de David J Anderson, creador de Kanban para desarrollo de sofware. Sé que hace tiempo que viene dandole vueltas a tener un manifiesto Lean Kanban y no sé si este será finalmente el que tomen pero sí tiene muchos puntos para reflexionar. Empieza así:

I believe in…
Empirical Process over Defined Process
Kanban, Scrum y otras metodologías ágiles están basados en el empirismo: transparencia, inspección continua y adaptación. Definir los procesos es necesario para estandarizar el trabajo y buscar mejores formas de hacerlo pero la situación real de cada momento es lo que manda.

System Thinking over Analytical Thinking
System Thinking se caracteriza por visualizar cualquier trabajo u operación como una serie de pasos interconectados que forman un flujo. Una vez definido y estandarizado este flujo de trabajo es posible ser ejecutado por más personas sin depender de un análisis concienzudo de cada petición de cliente por parte de dirección. Permite escalar una organización, buscar la mejora contínua y el empowerment de los que trabajan en ella. 

Effectiveness over Efficency
A esta le estuve dando muchas vueltas. Siempre se piensa en la eficiencia como algo que hay que perseguir pero, ¿es realmente lo más importante?. Pensando en cualquier sistema adaptativo, lo primero que hay que conseguir es un resultado de la manera más simple y lo antes posible con los medios y los conocimientos que se tienen en el momento de empezar. Por ejemplo, si el cliente piensa en tener un coche dentro de un año, nosotros le entregamos un monopatín en dos semanas. Realmente no es la forma más eficiente de trabajar ya que podríamos empezar a construir el coche sin tener que rehacer nada, pero podríamos fallar completamente buscando la forma más eficiente desde el primer momento. La eficiencia se busca poco a poco, historia tras historia, iteración tras iteración. Hazlo ya, vuélvelo a hacer de forma más eficiente, hazlo otra vez de forma aún más eficiente, y otra y otra…
Flow Efficiency over Resource Efficiency
Tradicionalmente se ha intentado aprovechar mejor los recursos individuales que ocuparse en el flujo completo de valor, desde la primera fase hasta la última. La gente de backend haciendo servicios a todo trapo sin que posiblemente los de front end tengan tiempo de integrarlos a tiempo. Es como si yendo un grupo de amigos en varios coches a un concierto cada coche fuera lo más rápido que pudiera sin pensar en el resto de amigos. Hacer esto no sólo no sirve para nada porque el coche más lento es el que define a qué hora entrarán sino que provocan problemas de sincronización que hace que vayan aún más lentos.
Small Batches over Big Batches
Trabajar en pequeños lotes tiene una serie de ventajas: se entrega antes trabajo terminado y se obtiene feedback antes, se obtiene progreso basado en software funcionando más contínuo, emergen los problemas antes, se reduce el stock de trabajo sin entregar, se puede controlar mejor la calidad… ¿Qué más razones necesitas?
Pull System over Push System
Base del sistema Lean. No hacer más trabajo de lo que necesitan las fases posteriores. Por ejemplo, no enviar a testing más de lo que puede manejar, no planificar más historias de las que se pueden desarrollar, etc.. Y por supuesto no hacer más producto de lo que pide el cliente.
Emergence over Command and Control
Las empresas están aprendiendo a cambiar su estilo de dirección reduciendo capas de jerarquía. En lugar de intentar dirigir todo top-down, se deja espacio a los trabajadores a que seas sus propios managers y resuelvan ellos mismos los problemas. De este modo se puede conseguir que empresas grandes y pequeñas respondan rápidamente a los nuevos retos que requiere la sociedad digital.
Problem Focus over Solution Focus
Es facil empezar a pensar en soluciones teniendo en consideración solamente la superficie del problema, los síntomas. Sin embargo hay que analizar más el propio problema, buscando las causas raices del mismo mediante técnicas como 5Whys o Fishbone. Una vez encontrado y estando centrados en el problema raíz ya podemos buscarle soluciones.
Omission Error over Commission Error
Preferimos quedarnos cortos y tener la posibilidad de hacerlo bien en un segundo paso que hacer algo erroneamente y tener que corregir, arreglar, deshacer y volver a hacer. Lo segundo generá más retrabajo que lo primero. Por ejemplo, sacamos de alcance la parte de una historia de usuario que no está clara para desarrollarla más adelante con máyor información.
Products Development over Project Execution
Cuando desarrollamos software es facil centrarse en los requerimientos del proyecto (plazo, cliente, necesidades solicitadas,..) sin pensar que estamos realizando un producto que tiene una vida mucho más larga que el propio proyecto, que puede usarse por varios clientes o incluso que el mismo cliente puede solicitar cambios grandes en el futuro. Esto hace que debamos prestar atención a factores como la calidad de código, la adaptabilidad y una buena elección de la tecnología.

14 años y 103 sprints

Tal día como hoy 29 de Julio ha sido mi último día en Video Stream Networks.
Pongo punto final a una etapa en la que he aprendido mucho como profesional y persona. He aprendido a desarrollar con la calidad que necesita un sector como el de broadcast (software de gestión y emisión de contenido audiovisual para cadenas de televisión), en el cual los programas deben funcionar 24 horas al día, 365 días al año y si falla aunque sólo sea un espacio de milisegundos, hay millones de personas que se darán cuenta al momento.
Es un sector innovador que a su vez necesita de integraciones entre muchos distintos componentes de distintos fabricantes. Un entorno en el que las fechas de “puesta al aire” van moviéndose por variables como tener el edificio listo, la sala de racks, ahora se inunda la sala de redacción, ahora se retrasa porque hay cambio de gobierno y ahora para dos semanas tiene que estar todo funcionando porque el presidente de ese país va a inagurar el canal en directo.
En ese sector he crecido y he descubierto el único sistema capaz de manejarse como pez en el agua entre tanta incertidumbre y riesgo: el Agilismo. Estoy bastante seguro que gracias a cosas como a una entrega iterativa e incremental por etapas, una buena cobertura de test y un equipo motivado y muy creativo, VSN ha conseguido ser referente de Innovación año tras año.
Pero ha sido el momento de decirle adiós a VSN. Empiezo una nueva época en GFT, cuyos valores ágiles se ven claramente en cada rincón de su página web y sus redes sociales.
En esta nueva etapa espero seguir aprendiendo y conseguir la perspectiva que me falta al haber trabajado sólo en una empresa. Empezaré como Scrum Master pero espero que pronto pueda dar mis primeros tumbos como Agile Coach. Mientras tanto… que se prepare el equipo con el que me asignen al empezar porque tengo muchos planes para ellos (Insights, Management 3.0, Kanban, Lean…).
Atrás dejo mucho amigos que lo seguirán siendo. Les deseo de todo corazón que consigan todos sus objetivos. Se lo merecen todos y cada uno de ellos.

Principios en VSNÚltimo día en VSN

Presupuestar historias de usuario sueltas

En la charla del viernes 27 de Mayo sobre Scrum en mundos imperfectos salió el tema de cómo presupuestar a clientes basado en historias de usuario. En ese momento no tenía una pizarra y no pude explicar cómo pienso que es la mejor forma de hacerlo por lo que voy a dejarlo plasmado en este artículo.

Lo primero es conocer la capacidad del equipo de desarrollo en puntos de historias durante un sprint. Ese sprint puede ser de una a cuatro semanas.Lo ideal es tener ya la capacidad de unos cuantos sprints para tener una media. Para nuestro ejemplo, en Baylor Enterprises, vamos a decir que la capacidad de desarrollo son 45 puntos por un sprint de 3 semanas. No está nada mal 😉

SalidaPuntos

Lo segundo es conocer qué costes tiene la empresa en ese sprint. Estos costes son la entrada necesaria en euros para producir los puntos de historia. Para calcularlo sumamos sueldos de desarrolladores, administración, alquileres, electricidad,… Puedes sumar todos los gastos mensuales y hacer una regla de 3 para conocer los relativos al sprint. Para la Baylor Enterprises, mi multinacional, los gastos totales relativos a un sprint son 10.000 Euros.

Como imagino que no trabajas en una ONG, querrás que la empresa tenga beneficios, por lo que tenemos que aplicar un multiplicador a los gastos, y entonces obtenemos los ingresos deseados por sprint. Como CEO de Baylor Enterprises, decidí aplicar un multiplicador de 1,2 y así  obtener 12.000 Euros de facturación deseada por sprint.

Facturacion

Ya lo único que nos queda hacer es dividir ese beneficio deseado por sprint por los puntos de capacidad. Esa división nos dará los ingresos deseado por punto de historia. Como en Baylor Enterprises queremos una facturación de 12.000  € por sprint y generamos 45 entonces 12000/45 = 667 € por punto de historia. Ya tenemos nuestro número mágico.

Ya puedes presupuestar para los clientesuna historia de por ejemplo  2, 3 ó 5 puntos.  Sólo multiplicando el número mágico de beneficio por punto por la estimación en puntos realizada. Para un Epic con varias historias hay que sumar los puntos de todas las historias que constituyen el Epic.

Nota: Si llega un momento que se consigue subir la capacidad del equipo sin que lleve a un mayor gasto tenemos 2 buenas opciónes: Mantener el mismo precio consiguiendo más beneficio para la empresa en cada desarrollo o bajar el precio por punto de desarrollo consiguiendo mayor competitividad.

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