Respect for downstream

Otra vez esperando en una sala de espera (¡acertado nombre para la sala!) y me vienen a la cabeza algunas experiencias que he tenido en las últimas semanas sobre el sprint plan.

Para que dirías que sirve este evento de Scrum?

No me considero un ultra especialista de Scrum, por aquello del síndrome del impostor tan común en el sector de la agilidad (otro día hablamos de esto), pero le veo algunos beneficios importantes. 

Sirve:

• Para tener una conversación abierta entre equipo y PO sobre “qué hacemos a continuación”.

• Para equilibrar adecuadamente la capacidad de desarrollo con el tamaño del trabajo que vamos a acometer. (dígase tamaño en todas las acepciones que podamos pensar en el sector del software)

• Para establecer las expectativas del PO al respecto de lo que el equipo espera entregar a lo largo de la próxima iteración.

• Para aislar al equipo de desarrollo de toda la complejidad del backlog completo y del ruido que se genera cuando hablamos de cosas que no sabemos seguro de si queremos o no hacer. Para enfocar.

El punto de equilibrar la capacidad con el WIP que inyectamos al sistema es fundamental, porque de ahí se deriva en gran parte la viabilidad de cumplir con los objetivos y que el equipo esté alineado con las expectativas establecidas al principio del sprint.

Algo así como decir que 

En el sprint plan calibramos el tamaño del trabajo, priorizamos con la PO y seleccionamos juntos lo que vamos a abordar, la PO está de acuerdo con esa selección y espera recibir eso durante la iteración; el equipo se enfoca y todos trabajan en pro de conseguir ese objetivo común.

Si esos objetivos se cumplen de manera consistente, la PO sentirá que el equipo es predecible, lo que lleva a fortalecer los vínculos de confianza. Eso hace que la PO pueda, por su parte, adquirir compromisos con otras partes de la organización e ir preparando todo lo que desencadena una entrega de nuevas funcionalidades a Negocio: modificación de procesos de negocio, gestión del cambio, comunicación, comunicación a cliente final, variación de contratos o, incluso en alguno de los casos que estoy conociendo de primera mano, reestructuración de los espacios físicos para adoptar las nuevas maneras de trabajar.

Es decir: aguas abajo hay muchos grupos de trabajo que dependen del cumplimiento de las expectativas generadas en un Sprint Plan.

-- Hay incertidumbre en el desarrollo.
-- Ya lo sé. 
-- Estamos en un mundo complejo, la organización y el software forman un sistema adaptativo-complejo que lo hace de todo menos predecible. 
-- También lo sé. Y por eso no pido adherencia al 100%, pido trabajo continuo en pro de la mejora.

Cuanto más puedas reducir la desviación que hay entre lo que te propones hacer en un sprint y lo que consigues, la organización funcionará mejor aguas arriba (en la relación entre los POs y el resto de personas interesadas en aquello que se desarrolla) y aguas abajo (la relación que todas esas personas tienen con el incremento).

Como le decía Batty a Deckard minutos antes de morir, “he visto cosas que vosotros no os creeríais”. He visto muchos equipos que se toman la planificación del sprint como un “trocear el trabajo en bloques de 15 días”, pero también los he visto que planean y comunican aguas abajo para que todo el flujo vaya suave. 

Hay gente ahí fuera que lo hace de película: esos son los imprescindibles, esos son aquellos de los que debemos aprender.

PS: Te dejo un par de preguntas para que le des a la reflexión:

1. ¿Qué factores influyen en la predictibilidad de tu(s) equipo(s)?

2. ¿Cómo influye la cantidad de información disponible al respecto de un determinado PBI sobre la capacidad que tenemos de cumplir la meta del sprint?

3. ¿Cuál es el valor del refinamiento en todo esto?

4. Estimar o no estimar... esa es la cuestión.

5. ¿Tiene sentido generar ocupación al 100%? ☠️

Las amebas y la estrategia

¿Has visto alguna vez una ameba? Al microscopio, en vivo y en directo… en la EGB, quizás? en el Instituto?

Una ameba es un ser vivo unicelular, no tiene cilios ni flagelos, como podrían tenerlos un paramecio o un vibrión colérico. Una ameba se mueve emitiendo pseudópodos, arrastrando lentamente parte de la masa celular en el sentido en que se quiere desplazar y luego moviendo el resto de la célula completa hacia allí.

Cuando se quiere alimentar, emite dos pseudópodos que rodean la partícula que quiere absorber hasta que éstos se unen y fusionan, dejando a la particula dentro de la ameba.

Pues las empresas son como las amebas.

Llevo años explicando esto en mis clases, primero cuando hablaba de mejora continua en ITIL, después cuando hablaba de mejora continua en ISO/IEC 20000, luego cuando hablaba de mejora continua en Lean y últimamente cuando hablo de mejora continua en Agile. Es mi forma de ver la importancia que tiene el impacto que tiene desplegar el pensamiento estratégico hacia toda la organización cuando estamos fomentando una cultura de mejora continua. Y sin embargo, repasando este blog nunca había escrito sobre la ameba.

Pero hoy he visto un post de Txell Costa donde hace una metáfora parecida pero con una goma elástica… y por eso me he decidido a escribir sobre la relación que hay entre un ser unicelular, microscópico, sin cilios ni flagelos, que se mueve por medio de pseudópodos … y tu empresa.

Las empresas son como las amebas. Emiten un pseudópodo y exploran nuevos territorios, como tú cuando tocas el agua de la playa con la punta del pie antes de meterte, tanteando a ver si está demasiado fría. Estos nuevos territorios pueden ser nuevos mercados, nuevos productos, nuevas maneras de hacer, nuevas maneras de organizar… emiten un pseudópodo y tantean y, si les parece que el agua está de su gusto, se tiran (algunas de cabeza y otras de culo… ya sabemos cómo va esto...)

En un entorno tradicional y jerarquizado, la alta direccion sabe a dónde quiere ir, y cuáles son los planes estratégicos para los próximos 5 años. La visión es clara y dirige el timón con mano férrea hacia ese horizonte que se ha planteado. En estos casos, transmitir la estrategia a los trabajadores no es necesario, es incluso contraproducente, no vaya a ser que alguien se vaya de la lengua, cuente nuestros planes y la competencia acabe adelantándonos.<ironic mode off>

Y qué pasa con la mejora continua? Los pequeños movimientos evolutivos no forman parte de aquellos grandes planes estratégicos, asi que aparece otra manera de avanzar: el modo ameba, en el que pequeños grupos de personas dentro de la organización se plantean pequeñas mejoras que hacen más eficiente el sistema o más valioso el producto final. Esas pequeñas mejoras se plantean como pruebas o experimentos (Da igual cuál sea el modelo de mejora continua que uses, más tarde o más temprano aparece el Dr. Deming con su ciclo PDCA y el planteamiento de experimentos… no conozco ningún modelo de mejora continua que no pase por ahí)

Bien. Ya he puesto en tu cabeza la imagen de la amena extendiendo sus pseudópodos para experimentar un nuevo terreno.

¿Funcionará bien la nueva manera de gestionar pedidos? Hacemos un piloto, probamos un MVP, hacemos una prueba con un par de clientes, extendemos a “friends & family” y si todo va como debe ir, pues ¡adelante!

Pero los métodos modernos de mejora continua tratan de conseguir un factor multiplicador involucrando a todo el personal de la organización (a lavez que potencian la cultura, empoderan al personal y un buen atado de otras ventajas). Se trata de paralelizar el modelo evolutivo y conseguir un pipeline continuo de experimentos. Hasta llegar al extremo asombroso de booking.com y sus 2^1000 versiones concurrentes de la web. Esto significa que estamos montando modelos de mejora continua que tratan de conseguir multitud de pequeños equipos distribuidos por la organización haciendo experimentos y provocando pequeños cambios que, en algunos casos, pueden resultar interesantes y provocar una tensión de movimiento “hacia allí"

Pero ¡atención! No estamos hablando de un ser pluricelular que hace muchos experimentos, sino de una pobre y triste ameba, unicelular y sin cilios ni flagelos.

¿Qué le pasa a la ameba si de repente emite 50 pseudópodos en direcciones opuestas y se empeña en moverse?

Lo mismo que le pasa a tu empresa cuando no se ha transmitido la estrategia y se montan grupos de mejora: cada vez que un grupo de mejora encuentra algo interesante (es decir, realiza un experimento exitoso) provoca una tensión hacia aquello que ha descubierto. Una empresa cuyos equipos no conocen la estrategia y tiene pocos experimentos exitosos se moverá como un tronco a la deriva en medio del océano: en el mejor de los casos, se deja llevar por los resultados de estos experimentos.

Pero una empresa que no ha transmitido la estrategia a sus colaboradores, que fomenta un entorno de mejora continua con gran parte de su personal y que además consigue multitud de éxitos en los experimentos, puede terminar intentando avanzar de forma simultánea en direcciones contrarias. En el mejor de los casos no se mueve y en el peor de los casos se rompe, se parte la pared celular y todo citoplasma queda por ahí desparramado. ¡Qué triste!

¿Nunca has tenido la sensación de que en tu empresa tienes varios jefes y que estos jefes estiran de ti en direcciones opuestas como si te estuviesen torturando al estilo mongol con 4 caballos?

Una buena transmisión de la estrategia corporativa ayuda a que los experimentos vayan en direcciones similares al menos, reduciendo el riesgo de que la empresa se parta, los trabajadores se quemen o la goma elástica de Txell salte por los aires.

Finalmente y por aterrizar esto a un terreno más práctico: si te imaginas una empresa que tiene varios equipos de desarrollo usando Scrum y estos equipos hacen retrospectivas y plantean pequeñas mejoras, te recomiendo que:

1. Los equipos tengan claro hacia dónde vamos
2. Hagas Retros de Retros uniendo representantes de los equipos o una comunidad de Scrum Masters para que vean periódicamente si las mejoras propuestas por el equipo A no le están haciendo la vida imposible al equipo B o al departamento C

Scrum en organizaciones Lean: más madera para el Product Owner!

Dentro de mi viaje particular al Nirvana del Flow, esta semana he tenido un momento importante. Facilitando un evento Kaizen para el equipo de almacén de un cliente, intentando corregir unos “problemillas” que había con unos bultos que se traspapelaban por el camino hemos seguido todos los pasos de rigor: plantear el problema, hacer un VSM, identificar oportunidades de mejora, análisis de causas etc etc.

Lo de siempre en el mundo Lean, siempre tan interesante gracias a la participación de todos. Aparte de todo lo que aprendí del mundo de los almacenes y la logística, que es impresionante, pude vivir (otra vez!) la excitación que te genera ver que el equipo Kaizen no se enfoca en las guerras personales y empieza a trabajar de manera creativa en comprender el problema y plantear contramedidas, siempre de manera transversal y cross-departamental. ¡Es alucinante!

Pero por el camino empecé a notar que la cosa se podía complicar. En seguida aparecieron propuestas de pequeños cambios en el proceso, pequeñas modificaciones en la operativa (con el consiguiente problema de Gestión del Cambio con el personal y sus diferentes turnos) y el nacimiento de nuevas necesidades de información, controles y sistemas de información.

¿Quien dijo que los procesos industriales son más fáciles de gestionar porque están estandarizados?

Este proceso que estábamos analizando es fácil de comprender, pero la cantidad de casuísticas que tiene es impresionante y ahí aparecía una de las lecciones importantes del Kaizen… recuerdas? “Kaizen … yo me flagelo y hago un sacrificio por el bien común”.

Para conseguir un proceso más homogéneo y sin tantas excepciones y casos especiales todos deben hacer pequeñas concesiones para conseguir optimizar el proceso de forma global en lugar de perseguir las optimizaciones locales e independientes para cada uno de los interesados. En este caso, el equipo de almacén se ve afectado por los requisitos, limitaciones o presiones impuestas en el proceso aguas arriba (por ejemplo, presiones en la planificación establecidas dos o tres eslabones antes de llegar a la preparacion de un pallet que debe ser expedido).

Y ahora vamos a pensar un poco más allá; este post no pretendía ser una explicación sobre una sesión de Kaizen. ¿Te imaginas una empresa en la que los diferentes equipos hacen sesiones de Kaizen para ir mejorando poco a poco los procesos de negocio? En el almacén, en compras, en logísticas, en pedidos… en todas partes gente haciendo pequeñas modificaciones y pequeñas mejoras sobre los procesos, haciendo que la empresa lentamente vaya evolucionando a mejores cotas de calidad, eficiencia y valor para el cliente. ¿Mola, no?

¿Y dónde están los informáticos?

¡Esa es la reflexión clave! Si los procesos evolucionan continuamente, informática debe ser capaz de soportar esas modificaciones de forma continua, debe facilitar la adaptación permanente de los sistemas de información a las necesidades y a los cambios provocados por la mejora contínua del negocio.

Es lo que hacemos siempre, no? Desde luego, no me cabe la menor duda de que siempre estamos intentando mantener un ritmo decente de modificaciones/evoluciones a nuestros sistemas de información, pero en un entorno Lean donde la evolución y el cambio son constantes el nivel de exigencia es mucho mayor.

¿Y cómo respondemos en informática a esta situación de elevada demanda de pequeños cambios sobre los mismos sistemas de información?

Con equipos especializados en esos sistemas de información, focalizados en el proceso, orientados a la ejecución de tareas que finalizan con un incremento de producto totalmente funcional.. respondemos a las células de producción con células de producción. Los equipos ágiles son especialmente necesarios en estos entornos donde no dar respuesta incremental a estas demandas significa frenar la mejora de los procesos de negocio.

Por eso es tan y tan importante provocar la transformación ágil en los entornos Lean para hacer que flujo, valor y calidad vayan de la mano en todos los sentidos. Y cuando tengas en marcha equipos ágiles, si usas Scrum por favor, asegúrate de que al menos el Product Owner asiste a las sesiones Kaizen de su cliente.

Ni te imaginas el aprendizaje y la cantidad de información y de ideas enriquecedoras que el equipo de desarrollo se va a llevar de esas sesiones: es ver a tus usuarios tratando de resolver sus problemas utilizando tus herramientas.

Postdata: en este evento Kaizen que estoy facilitando está presente la Product Owner y varias personas del equipo de desarrollo… está siendo una experiencia super enriquecedora para todos!

No es el problema. Eres tú frente al problema.

La primera vez que oí hablar sobre el modelo Cynefin fue allá por el año 2012 cuando estaba colaborando con Rob England en la traducción del libro Gestión Esencial de Servicios al castellano. En aquel momento me pareció un framework muy interesante para clasificar los problemas y cómo nos enfrentamos a ellos; luego Rob lo utilizó en su libro Plus! Standard+Case y en el congreso TFT13 yo le dí una vuelta más tratando de enlazar los conceptos de S+C, Cynefin y Minería de Procesos.

Pero luego vino el esquema de certificación de la Lean IT Association y la certificación LITA Kaizen. Cuando me preparaba, volvió a aparecer el modelo de Cynefin y esta vez venía con fuerza, como parte central del proceso de resolución de problemas que plantea la LITA combinando Kaizen con Six Sigma (DMAIC) y Cynefin.

Fue mientras daba una clase de Kaizen que me vino la iluminación; uno de esos momentos A-HA! que sólo puede tener el profesor cuando por el simple hecho de poner las cosas en orden en su cabeza para poderlas explicar, éstas encajan de una manera especial y plop! se hace la luz.

El modelo Cynefin ve los problemas como un cúmulo de causas y efectos; aquellos en los que la relación causa - efecto es clara, los entiende como “Simples”, mientras que en aquellos en que la relación causa - causa - causa/efecto intermedio - causa - efecto es intrincada, con multiples ramificaciones y multitud de causas contribuyendo a la aparición de los efectos los clasifica como “Complejos” y aquellos en los que las relaciones entre los eventos no son permisibles los clasifica como “Caoticos”.

Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas o de comprenderlas.

Pero, lo caótico no es el problema. Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas. Sin embargo si eres capaz de aprender nuevas ideas, si eres capaz de cambiar la perspectiva o el espectro en el que te mueves (en la vista, por ejemplo, cambiar a espectro infrarojo te permite ver las cosas desde otro punto de vista; en matemáticas, pasar de una serie temporal a un histograma te permite comprender otras facetas del problema analizado; en Telecos, Fourier cambió para siempre la forma de entender las ondas), si eres capaz de pensar de una manera diferente es cuando empujas el problema hacia niveles Cynefin de menor complejidad.

Aquí es justo cuando me viene a la cabeza ese momento en que Neo comprende.

Cómo clasificas el problema dice más de ti que del problema en sí.

Cómo clasificas el problema dice más de ti que del problema en sí. Y esta es una de las razones por las que utilizamos Kaizen para enfrentarnos a los problemas que nos parecen complejos o complicados: utilizamos un equipo para atacar el problema; un equipo multidisciplinar que, gracias a las diferentes perspectivas, experiencias y formas de vivir y de entender el problema hará que el grupo entero gane un nuevo nivel de conocimiento al respecto del problema y sus relaciones con los factores que contribuyen a su aparición. Ese es uno de los motivos por los que, casi sin darnos cuenta, los equipos multidisciplinares y la diversidad hacen empresas más eficientes: los problemas parecen menos cuando los enfrentas en buena compañía.

PS:: Este post viene provocado como reflexión ante una pregunta de Javier Garzás en linkedIn… como siempre, un placer! :-)

Qué hacer con las interrupciones

LLevaba días con ganas de escribir algunas reflexiones al respecto del problema que suponen las interrupciones para la efectividad de un equipo y finalmente Javier Garzas se me adelantó con este post sobre control de interrupciones.

Efectivamente, tal y como indica el post de Javier, las interrupciones son uno de los mayores destructores de productividad tanto del individuo como del equipo, fundamentalmente porque somos muy malos gestionando los cambios de contexto y por lo tanto el overhead intelectual que tiene dejar de hacer lo que estamos haciendo para atender un interrupción y volver a ponernos es elevadísimo.

A ese esfuerzo intelectual tenemos que sumarle el mal humor acumulativo que le va entrando a la persona interrumpida que en las dos o tres primeras interrupciones no tiene problema y atiende con una sonrisa, las siguientes 3 ya no son tan bienvenidas y a partir de la séptima ya empieza a desesperarse y a desear esconderse en una cueva para que le dejen concentrarse en paz.

Son un problema importante y debemos tratarlo como tal. Seguro que si analizamos un poco podremos ver que tenemos diferentes tipos de interrupciones en función del grado de proximidad al individuo (yo las clasifico en internas, de equipo y externas) y esto nos indica tambien con quien debemos contar para resolverlas.

Así, resolver las interrupciones internas será tarea de cada uno de los miembros del equipo, adoptando rutinas y formas de trabajar libres de interrupciones (modo Foco en el ordenador que estes utilizando, musica de concentración, evitar el web-browser sobre todas las cosas, técnicas del tipo Pomodoro).

Por otra parte, resolver problemas de interrupciones a nivel equipo o a nivel compañía es un trabajo mucho más duro. Normalmente nos encontraremos con que este tipo de interrupciones vienen dadas porque existen dependencias entre las personas o los equipos y es ahí donde debemos trabajar.

Durante mi vida profesional me ha tocado trabajar con multitud de equipos distintos que sufrian las interrupciones de diferentes maneras. La forma más común de enfrentarse a ellas es el llanto y la flagelación: “En esta empresa no se puede trabajar, es que es imposible hacer nada… no hay manera… me pillo una sala para poder estar concentrado”…

La siguiente manera de enfrentarse, y esta viene más en entornos con cierto nivel de madurez y sobre todo en entornos ágiles en los que se ha reservado un espacio para la reflexión y la mejora continua del equipo, es el planteamiento de la situación en una retrospectiva: “no conseguimos llegar a nuestros objetivos porque estamos sometidos a gran cantidad de interrupciones. ¿Qué podemos hacer?"

… y aquí es donde viene el meollo de la cuestión: el equipo se plantea qué hacer con las interrupciones y como es normal lo primero que se plantea es objetivizar un poco la situación y aparecen los tableros para visualizar el problema como el que describe Javier en su artículo. Luego en pequeñas sesiones de trabajo el equipo va explorando las causas de las interrupciones y tratando de poner freno o límites.

A mi me gustaría ir mucho más alla: dado que las interrupciones son un problema importante para el/los equipos (no olvidemos que quien interrumpe probablemente también vea un problema en la necesidad de interrumpir) y que debemos estudiarlas desde un punto de vista sistémico (porque si no, optimizaremos localmente y conseguiremos un bonito desastre a nivel de sistema de producción), debemos tratarlas con un enfoque Kaizen.

Por ejemplo, en una retrospectiva participan los miembros del equipo; si las interrupciones son del tipo externo, ¿No nos falta el otro lado para poder analizar el problema?

El modelo Cynefin clasifica los problemas en Simples, Complicados, Complejos y Caóticos. Los problemas simples son aquellos que se pueden explicar fácilmente desde una perspectiva de Causa-Consecuencia y en mi opinion personal (y seguro que muy discutible) son geniales para ser atacados en las retrospectivas: un equipo en un par de horas trabajando sobre ellos llegará fácilmente a proponer una solución que podrá ser incorporada como mejora continua en su backlog, al tiempo que se entrena en el análisis de problemas, autocrítica y mejora continua.

Sin embargo, las interrupciones como mal sistémico de una organización no pertenecerán a este tipo de problemas: no tendrán una clara relación causa-efecto, sino que serán provocadas por una sucesión de causas que contribuyen a la aparición del problema o incluso habrá algunas veces en las que las causas y los efectos no podrán ser observados a priori sino que vemos su aparición a posteriori. Es el terreno de los problemas Complicados y Complejos que es justamente donde el Kaizen se mueve bien.

Así, desde aqui mi propuesta es no pensar que existen las varitas mágicas y ser conscientes de que la probabilidad de que una “best-practice” nos solucione el problema de las interrupciones es realmente baja, tendiendo a cero. El Kaizen es un método sistemático para atacar este tipo de problemas, así que empieza por visualizar el tamaño de tu problema (y decidir si las interrupciones son realmente un problema en tu organización) y después sigue los pasos del método uno por uno.

Kaizen según la Lean-IT Association

Si quieres saber más sobre Kaizen en el mundo Lean-IT, te recomiendo el libro oficial de la Lean-IT Association (descarga gratuita) o los programas de formación en Lean-IT de G2

4 ideas para aumentar la velocidad

En Scrum se utiliza el concepto de velocidad para referirnos a la capacidad que tiene el equipo de “quemar puntos”, o sea, a su capacidad de producción. El aumento de la velocidad es uno de los principales indicadores de que el equipo está cohesionado, en continuo aprendizaje y en mejora continua.

Pero... ¿cómo se aumenta la velocidad?

Desde luego, no es por azar. En este artículo veremos cuatro herramientas fundamentales para la mejora de la velocidad en tu equipo Scrum.

1.- Identificar QUÉ nos resta capacidad

Si sumamos todo el tiempo laboral del que disponen los miembros del equipo, tendremos una capacidad productiva teórica máxima.

Esto es una simplificación, porque estamos sumando “peras con manzanas” ya que una hora de María no es igual a una hora de Joan y, desde luego, una hora de Joan haciendo análisis no es igual que una hora de Joan haciendo testing. Por esta razón utilizamos puntos en lugar de horas para estimar las tareas, pero esta es otra historia que debe de ser contada en otra ocasión.

Centrémonos: tenemos una capacidad máxima teórica que luego se convertirá en una capacidad efectiva real. ¿Cuál es la diferencia? ¿Qué nos está mermando la capacidad productiva?

Debemos aprender a identificar en qué estamos invirtiendo el tiempo del equipo para ver cómo podemos optimizarlo y ganar en capacidad productiva, o al menos ganar en objetividad y no engañarnos pensando que el equipo produce 8 horas al día. Por ejemplo, nos encontraremos frecuentemente que los miembros del equipo dedican parte de su capacidad en tareas como:

• Reuniones
  
• Llamadas telefónicas
  
• Formación
  
• Participación en otros proyectos
  
• Colaboración con otros equipos
  
• I+D
  
• Ausencias / Absentismo
  
• Ejecución de tareas no planificadas
  

Atención! Hemos dicho “optimizar”, no “eliminar”. Hay que ser conscientes de en qué invertimos nuestro tiempo y en conseguir un equilibrio. Por ejemplo, una de las grandes ventajas de aislar al equipo y tratar de eliminar las interrupciones es reducir el tiempo dedicado a reuniones y llamadas telefónicas; o una de las ventajas de mantener acotado el numero de equipos a los que pertenece una persona es reducir el overhead de coordinación y de cambio de contexto.

2.- Identificar EN QUÉ derrochamos capacidad

Este punto está más relacionado con la parte “interna” del trabajo como equipo Scrum. De todo el trabajo que hacemos como equipo (es decir, del que estamos considerando dentro del cómputo de la velocidad), ¿qué podemos optimizar? ¿Se nos va el tiempo en actividades que no aportan valor al usuario?

Hay tres grandes “vampiros” de la eficiencia en el trabajo de un equipo scrum: Muda, Mura y Muri.

Muda: Son actividades que no aportan valor y que están clasificadas por algunos autores en 8 grandes bloques:

1. Trabajo a Medias (el famoso WIP)

2. Exceso de Funcionalidad (hacer más de lo que el cliente requiere)

3. Procesos Extra (algo parecido al exceso de burocracia o procesos excesivamente complicados)

4. Traspasos (cruzar barreras organizativas siempre añade retrasos a nuestro flujo)

5. Retrasos (todo aquello que suponga tiempos de espera)

6. Conmutación de Tareas (la multitarea es enemiga de tu cerebro, que es tu principal medio de producción!)

7. Defectos (los errores y la deuda técnica)

8. El talento desaprovechado (por eso somos un equipo scrum!)

Mura: es la irregularidad en las tareas o en los resultados. Por eso tratamos de estandarizar las entradas al proceso, utilizar plantillas y checklists o incluso homogeneizar el trabajo a nivel inter-equipo scrum y hasta hemos formalizado una Definition of Done

Muri: es el trabajo tensionante. El stress sobre personas y máquinas produce errores y genera más muda. Por este motivo buscamos equipos motivados, equilibrados y felices.

Aprender a ver, clasificar y eliminar muda, mura y muri en el trabajo que hace el equipo Scrum día a día debe convertirse en uno de los puntos clave de las retrospectivas y alimentar el backlog de mejora continua de forma implacable.

Aprender a ver, clasificar y eliminar muda, mura y muri debe convertirse en uno de los puntos clave de las retrospectivas para optimizar el trabajo del equipo Scrum

3.- Aprender a NIVELAR la demanda

En el sprint plan hacemos entrar trabajo al sprint backlog y se adquiere el compromiso del equipo con respecto a los objetivos a cumplir. Si dejamos entrar demasiado, tendremos más demanda que capacidad y eso genera muri. Si dejamos entrar poco, tendremos más capacidad que demanda y eso genera muda.

Tenemos que aprender no sólo a dejar entrar la cantidad justa sino que además debemos aprender a dejar entrar la combinación adecuada de tareas en función de las características del equipo (y por esta razón los equipos deben de ser lo más estables posibles).

Así, debemos trocear las historias de usuario en paquetes pequeños que fluyan suavemente y debemos evitar entrar bloques grandes en el proceso. Un trabajo “grande” se comportará como un tractor en una carretera: todo el resto del trabajo estará atascado detrás, ya trabajes en modo Scrum o en modo Kanban.

Esta técnica de combinación de la demanda para ocupar nuestra capacidad se llama Heijunka y es clave en la planificación industrial de la producción.

4.- Aprender a ayudar al FLUJO

Recuerdas el manifiesto ágil? Decía algo así como “Preferimos software funcionando sobre documentación extensiva”. Nos gusta más el software funcionando, es decir, nos gusta ese momento en que pasamos un “PSPI” (Potentially Shippable Product Increment) a Done.

Así que cuando acabes una tarea, en lugar de dirigirte al sprint backlog y coger la próxima tarea para iniciarla, para un momento y mira el tablero; recuerda que somos un equipo y nos medimos como equipo, así que no se trata de ser el que más tareas inicia, sino que se trata de que como equipo debemos terminar las tareas que nos hemos comprometido.

Lo importante es llevar la historia de usuario a done, no las tareas individuales. Esto nos hace trabajar como un equipo y poner foco en la entrega de valor.

Una vez hecha esta reflexión plantéate:

1. ¿Hay alguna tarea bloqueada que tú puedas desbloquear?
   
2. ¿Hay alguna tarea a medias en la que tú puedas ayudar?
   
3. ¿Hay algún compañero que necesite tu ayuda?
   
4. De todas las tareas que hay en el sprint backlog y tú puedes hacer, ¿Cuál es la que más ayuda a una historia a terminar?
   

La idea, una vez más, es completar el trabajo que hemos comprometido al inicio del sprint. ¿Qué crees que hará más feliz al cliente al final del sprint, mostrar que hemos iniciado todas las historias y no hemos acabado ninguna o mostrar que hemos acabado el 70% de las historias y que no hemos llegado a completar el otro 30%?

¿Qué otros trucos tienes para aumentar la velocidad? Estos cuatro son sólo eso... cuatro de entre los cientos que podemos imaginar.

¿Transformación Digital? No sin DevOps!!

Se me repite la ocasión en que vuelvo a casa despues de un curso de DevOps Foundations. Probablemente disponer de tres horas de tranquilidad después de tanta actividad hace que me aparezcan algunas ideas y me den ganas de escribir.

Una de las slides que presento en la versión para managers de este curso está sacada del documento State of DevOps Report 2015, publicado por Puppet Enterprise y que representa un informe sobre el estado de la cuestión que han venido publicando desde 2013 y que se ha ganado el respeto de la comunidad.

La primera vez que vi esta gráfica se me pusieron los pelos de punta y creo que es de una importancia tan grande que es necesario dedicarle un post, una noticia en el periódico y hasta un libro si fuera necesario con tal de hacer entender a todos los directivos del pais lo que significa.

Vamos a ir por partes: en el eje vertical tenemos tenemos la frecuencia de despliegues en la organización., pero atención, representada en una escala logarítmica donde 1 significa un despliegue al día… pero es que 2 significan 10 despliegues al día y 3 significan 100 despliegues al día; no nos dejemos engañar por la inocencia de esa gráfica.

En el eje horizontal tenemos, en escala también logarítmica, el tamaño de los equipos de desarrollo. Asi que me he permitido el lujo de calcular “a ojo” los valores de la curva, meterlos en un excel y hacer una gráfica parecida pero con escala lineal, para no suavizar el impacto del puñetazo que nos dan estos datos

¿Y qué significa esto? Pues básicamente que

a) Los “low performers” (aquellos que con sus prácticas actuales no llegan a más de 100 desarrolladores y que aún así están haciendo como mucho tres o cuatros despliegues a la semana.

b) El rendimiento de los “low performers” cae rápidamente cuando crecen en número de desarrolladores. Esto es típico de las aproximaciones tradicionales: al añadir más personal, crece la desorganización y el waste y por lo tanto la eficiencia cae en picado. En la siguiente gráfica he quitado a los high performers para poder percibir esta situación:

c) Con respecto a los “Mid Performers”, podemos ver que soportan relativamente bien la incorporación de cada vez más personal y lentamente aumentan el número de despliegues al día. Fijémosnos en que esto significa, desde el punto de vista del negocio, que podemos llegar a doblar el número de desarrolladores (e incurrir en costes mucho más elevados, ya que el aumento de costes no es lineal al numero de personas) y aún así no llegan al despliegue diario (en el fondo, quizás aqui el aspecto importante de verdad es que puedes doblar los recursos, pero no doblarás la velocidad de despliegues, sino que se mantendrá relativamente constante)

d) Finalmente, los “High Performers”. Estos son los preocupantes. Estos se mantienen más o menos cercanos hasta llegar a los 300 desarrolladores. Entonces comienza su escalada brutal: pasan a los cinco despliegues al día y rápidamente con capaces de llegar a los 80 despliegues al día apenas triplicando los recursos (osea, triplico los recursos y multiplico por 15 los resultados (!!!)

Posiblemente en estos momentos estés pensando que eso en el fondo son unos números más o menos trucados, quizás que en tu empresa hay doscientos programadores y que eres capaz de hacer 40 despliegues a la semana (que son unos 5 al día) y que eso está chupado, o simplemente que “¿y para qué quiero yo hacer tantos despliegues al día?”.

Perdón, que me ha faltado la última excusa, bastante frecuente además, la de “si, claro… pero ¿cuántos de esos despliegues son buenos? ¿Qué nivel de fallos tienen estos tios a esa velocidad?”. Te lo respondo en la siguiente tabla, tambien sacada del mismo State of Devops Report 2015

Ok, pues esto nos muestra que se está produciendo una brecha inmensa que está separando a los high performers del resto del mundo a una velocidad pasmosa y eso es un problema.

Ahora piensa en todos aquellos que están hablando sobre Transformación Digital. En el fondo están tratando de aplicar soluciones del mundo digital a los problemas que tienen sus clientes y buscando nuevas vías de contactar con ellos, de mantenerlos ligados a su marca, productos y servicios y rompiendose la cabeza para innovar en sectores que posiblemente sean muy tradicionales: ¿cómo ofrecer novedades en el sector banca, seguros, retail?

Y resulta que todo el concepto de Transformación Digital se basa en cuatro palabras: experimentar, innovar, aprender y digitalizar. Una empresa que aborde una iniciativa de transformación digital tiene que ser consciente de que esto no es un proyecto con inicio y fin, sino una transformación: ahora eres una cosa y luego serás otra, pero esa otra cosa, ese punto de destino es móvil y cambiante; las empresas transformadas ya no son empresas rígidas sino que son empresas líquidas que se adaptan de forma continua a un entorno, a un mercado y a unos clientes que cambian continua y rápidamente.

¿Y cómo puedes conseguir eso en un entorno digitalizado? Pues con velocidad. Necesitas que en IT tu flujo de aportación de valor sea muy rápido y que tu lead time sea muy corto con un nivel de acierto elevadísimo… y eso es exactamente lo que están consiguiendo los high performers de nuestra gráfica de arriba.

Resulta que los high performers han llegado a una situación en la que su lead time de experimentacion es muy corto, su capacidad de desplegar pruebas en los entornos de produccion es altisima, su riesgo muy bajo y su capacidad de recuperarse ante los errores es increible… los high performers pueden probar nuevos productos, nuevas lineas de negocio y nuevas maneras de comunicarse y satisfacer a sus clientes 200 veces más rápido que una empresa “normal”: o espabilamos o se nos comen!!

Así pues, la próxima vez que te plantees la transformación digital de tu compañía piensa primero en los cimientos sobre los que debes consruir ese cambio:

• una cultura de colaboración
  
• una organización transversal que huye de los silos verticales
  
• equipos multidisciplinares
  
• flujo de valor
  
• aprendizaje
  
• automatización
  

En definitiva, Lean-IT, Agile y DevOps o lo que nosotros llamamos Agile IT Management.

Y esos cimientos debes construirlos rápido: los high performers llevan años haciéndolo así que no te van a dejar respirar.

No tardes y empieza ya!

La muerte del proyecto o el Nirvana del Flow

Voy en el AVE volviendo de impartir un (otro) curso de Lean-IT; eso significa que llevo al menos tres días en los que mi cabeza sólo tiene un foco: el flujo, el waste, el valor, la Voz del Cliente y todo ese tipo de conceptos. Cuando consigo ese nivel de concentración pasan cosas interesantes, las ideas van sedimentando y de tanto explicar conceptos, otros más grandes se van consolidando encima de ellos.

Cierro los ojos y veo el flujo, como Neo. Me imagino una situación ideal, el Nirvana del flow y tiene pinta de un equipo multidisciplinar y no demasiado grande, bien avenido, motivados y con muchas ganas de cumplir su misión: entregar un software a su comunidad de usuarios que funciona, que hace lo que necesitan los usuarios incluso sorprendiéndoles con algún que otro truco sacado del sombrero de chistera del product owner o del UX Designer. Un software que va a la velocidad que quieren los usuarios, que está disponible, que no falla y que además cumple con las normativas y mantiene la seguridad en regla.

Pero ese equipo, además, resulta que se mantiene en contacto permanentemente con los usuarios, con los clientes (no obligatoriamente son la misma persona!) y de esa manera va incorporando nuevas funcionalidades y características al sistema de información y a la manera en que la empresa tiene de ponerlo al alcance de los usuarios (nuevos modos de contratación, nuevos modelos de facturación, nuevas formas de estar en contacto con los usuarios o incluso nuevas maneras de ayudar a los usuarios a sacarle el máximo provecho a tan preciado software).

¿Y sabes cómo empezó todo? Con una pequeña idea que probaron en un laboratorio de esos semestrales que la empresa facilita: “la semana que viene hay hackaton”, dijeron… se juntaron uno de marketing con un desarrollador, un experto en usabilidad y uno que trabaja en soporte, pero que le encanta jugar los fines de semana montando contenedores Docker, dejaron salir todo lo que tenian dentro y plof! Apareció una primera idea que parecía que podía tener éxito.

Cuando terminó el hackaton le mostraron a sus compañeros el resultado (basto, poco pulido, pero con una pequeña muestra de funcionalidad) y hubo quien apreció la viabilidad, así que la empresa decidió apostar y les pidió que en dos meses tuvieran montado un MVP (un Producto Minimo Viable) que pudieran presentar para ver si lo lanzaban.

A medida que pasaba el tiempo la lista de ideas iba creciendo: algunos usuarios piloto daban su opinión y encontraban nuevas maneras de usar la aplicación, muchos de los desarrolladores soñaban con nuevas funcionalidades y habia quien pensaba que añadiendo integraciones hacia otras partes de la organización podrían sacarle mucho más partido.

El equipo no era novato y ya había vivido esas sensaciones antes. Hicieron un gran esfuerzo para mantener a raya el WIP. Había que morder el pastel a pequeños trozos, masticarlos bien y hacer la digestión. Poco a poco aquello que era apenas una maqueta pasó a ser un MVP y el MVP fue creciendo hasta convertirse en un producto a secas y al cabo de los años hasta le quitaron el logo de “Beta” que tenía en la home page.

Durante todo este tiempo, el equipo permaneció relativamente estable. Algunos entraban y otros salían, pero el indice de rotación se mantuvo relativamente bajo. Sí que es cierto que cuando el producto comenzó a tener éxito, las nuevas ideas entraban mucho más rápido de lo que les daba tiempo a fabricarlas, así que trabajaron duramente para automatizar todo lo que podían para que los ciclos de desarrollo-integración-pruebas-aceptación-despliegue fueran lo más cortos posible, eliminando siempre que podían los frenos al flujo y habilitando bucles de feedback para que todo el equipo supiera en cada momento qué estaba pasando.

También es cierto que a medida que el volumen de usuarios iba creciendo el tamaño de las actividades de soporte y apoyo era cada vez mayor. Compredieron que no era sostenible así que decidieron poner en marcha todos los mecanismos que les facilitaran reducir este tipo de demanda: tolerancia cero a la deuda técnica, controles de calidad cada vez más exhaustivos, un interfaz de usuario brillante y fácil de usar, formación a los usuarios y una magnífica base de conocimientos que permitiera a los usuarios resolver sus dudas. Para terminar de poner la guinda a este pastel se inventaron el rol de “usuario ayuda a usuario” y habilitaron un foro de soporte en el que unos usuarios ayudaban a otros, todo inspirado por un potente motor de gamificación que permitía ganar puntos que podrías canjear en algunos establecimientos colaboradores (si ayudas en el foro puedes conseguir un pase VIP para el estreno de Star Wars!!).

Han pasado algunos años, y el producto sigue en constante evolución: siempre hay ideas nuevas, siempre hay necesidades nuevas y siempre hay formas nuevas de interactuar con el cliente, de forma que el equipo no se ha disuelto, siguen siendo aquellos que empezaron junto con otros que se han sumado a la aventura.

Lo que más me sorprende de todo esto es el cambio tan profundo de mentalidad: nunca ha habido un proyecto… nunca ha habido una planificación a un año vista ni tan sólo un roadmap (porque el roadmap lo hacen los clientes en as reuniones quincenales que tienen con el product owner. El roadmap nunca es a 5 años vista, sino que es a dos meses vista).

Esta manera de pensar ha sido “la muerte del proyecto” tal y como lo conocemos. Ahora ya no hay proyectos en esta empresa; lo que hay son experimentos que dan lugar a un ciclo de vida de producto (o de servicio, según lo quieras mirar). El proyecto tiene fecha de fin: acaba cuando se termina de construir, pero en este modelo no terminamos nunca de construir.

Hay algunos en el equipo que empiezan a dar señales de aburrimiento. Tienen ganas de nuevas aventuras, pero no piensan en cambiar de empresa. ¡Ni locos!

El mes que viene hay hackaton. ¿Te animas?

———
REFERENCIAS:

Para los conceptos de MVP y experiementación para incorporar la innovación, Lean Startup de Eric Ries
Para los ciclos cortos de desarrollo y contacto con el cliente, Agile
Para la automatización de los ciclos de desarrollo-pruebas-despliegue, Integración Continua de Jezz Humble
Para la cohesion de equipos multidisciplinares (de verdad), DevOps y Agile. Gene Kim y Jezz Humble
Para la motivación de los equipos y mantenerlos a tu lado, Management 3.0 de Jurgen Appelo
Para aprender más de todo esto sin tener que leerte la Biblioteca de Alejandria, G2 Gobierno y Gestión de TI

La minería de procesos en acción

Hacía mucho tiempo que tenía ganas de hacer esto. Un pequeño vídeo que demostrara las capacidades de la minería de procesos de tal forma que te pudieras hacer una idea más clara de lo que se puede llegar a conseguir con este tipo de herramientas.

La semana pasada organizamos en G2 el evento Business Process Transformation, donde explicamos varias técnicas que nos permiten facilitar la mejora continua y la transformación de los procesos de negocio, y entre ellas hablamos de la minería de procesos. Un “problemilla” técnico deslució mucho una demo en la que tenía puestas muchas ilusiones así que he aprovechado un rato que tenía disponible para preparar este video. No soy un profesional de la edición, así que ha quedado como ha quedado… pero estoy seguro de que te activará las neuronas y te dejará imaginando cómo podrías aplicar este tipo de ideas en tus procesos.

Sólo una pista a tener en cuenta: cuando hablamos de “proceso” hablamos de “cosas que cambian en el tiempo”… así que podemos aplicar estas técnicas para analizar la evolución en el tiempo de cualquier concepto. Por ejemplo, mi compañero Jorge hizo una extracción de datos de LinkedIN para representar el mapa de cuáles son los caminos más exitosos para que una persona se convierta en CIO. Mi amigo Mariano quiere utilizarlo pasa estudiar el comportamiento de los alumnos en los MOOC de la Generalitat y yo lo he utilizado para estudiar el proceso de conformación de facturas o el factor de rotación de personal de un outsourcer del que no se mucho más que el rastro que dejan sus operadores en mis herramientas de gestión.

Abre tu mente, imagina cómo podrías utilizarlo y ponte en contacto con nosotros en http://www.gedos.es si quieres un piloto o una prueba con tus propios datos. ¡Aprender es gratis!

Jugando a Lean Lens con el itSMF

Una de las últimas adquisiciones de G2 en materia de juegos didácticos ha sido Lean Lens, un juego creative commons desarrollado por Andrea Darabos y Bazil Arden en 2014 y que presentaron en las jornadas CAS2014 que se desarrollaron en Barcelona el año pasado.

El juego es una representación en forma de obra de teatro en la que hasta 9 grupos de personas interpretan diferentes escenas de la vida cotidiana de las TIC, desde las conversaciones con Negocio para discutir nuevas funcionalidades en la web hasta la resolución de correctivos afectando a diferentes partes de la aplicación. En cada una de las escenas intervienen diversos roles (el Stakeholder, el developer, el tester, el project manager, el tecnico de soporte, etc.) e incorporamos un rol especial en cada grupo que hace las labores de observador. El observador tiene como misión analizar cómo se desarrolla la escena e identificar los diferentes tipos de waste que se generan durante la actividad, de forma que posteriormente se discute con el equipo y se llega a un consenso sobre los derroches identificados.

Cuando se han escenificado todas las escenas, los observadores rellenan el “Mural del Waste”, que hace patente la presencia de los 8 tipos de derroche en cada una de las etapas de la cadena de valor de las TIC, al tiempo que se plantean las diferentes soluciones y formas de mejorar el escenario propuesto.

El juego facilita la comprensión de los diferentes tipos de derroche, la colaboración en equipo y sobre todo demuestra cómo un Mural del Waste puede convertirse en una herrmaienta importantísima (y visual) a la hora de potenciar las actividades de mejora continua dentro de las organizaciones.

Algunos de los comentarios que surgieron en esta edición de Lean Lens con el itSMF España en el Curso de Verano fueron

Lo que estamos representando aquí es tan familiar que le podríamos poner nombre y apellidos a cada post-it que estamos pegando en el Mural del Waste

Pero… ¿Vamos a mejorar ya, o nos quedamos mirando esto como si nada?

Nos ha parecido tan evidente y tan típico lo que estabamos representando que nos da la sensación de que nos vamos a repetir mucho al poner los derroches en el Mural del Waste

Una mañana intensa en la que hemos aprendido mucho; los alumnos se han llevado nuevas técnicas para hacer aflorar las ineficiencias en su organización y para apalancar los planes de mejora continua y yo… pues yo me he llevado un paquete de mejoras a plantearle a Andrea sobre el juego y un paquete de experiencia adicional para mi mochila.

Dilbert y el Lean Sourcing

Hace un par de semanas fui a dar con esta tira de Dilbert que viene a resumir muchas de las tristes situaciones que se dan en los procesos de Outsourcing en los que he participado en los últimos años (que como puedes ver en esta conferencia que di para la ATI en 2012 es uno de los temas candentes en G2). La tira, además de hacerme reir un rato, me hizo reflexionar y poco a poco fue saliendo este texto que resumo aquí en forma de dos cartas.

---

Querido Proveedor:
Yo se que a veces soy un poco caótico y que no acabo de establecer un paquete claro de prioridades, pero es que las cosas son así… la vida en los negocios, como tú ya sabes, no es estable ni tranquila sino que es cambiante y variopinta. Por esta razón no acabo de ver claro que podamos cerrar un acuerdo rígido de colaboración a 5 ó 7 años vista donde se describa con detalle todo lo que vamos a hacer, los niveles de servicios que me prestarás y las tarifas de precios que me cobrarás; no veo que así tú te puedas ganar la vida mientras que yo pueda tener las TIC que deseo para mi empresa.

¿Cómo vamos a plasmar en un contrato las necesidades que tendré dentro de dos años, si ni tú ni yo sabemos lo que necesitaremos dentro de seis meses?

En realidad, lo que a mi me gustaría es que entiendas por qué te escojo a tí y no a cualquier otro de los que han presentado ofertas respondiendo a la RFP que hemos publicado. No es por el precio, ni porque sea “más bonita”. Es porque me transmite confianza; la confianza en que me vas a acompañar durante los próximos siete años, en que vas a poner los intereses de mi compañia por delante de una visión cortoplacista, de la venta y del margen; la confianza en que te vas a preocupar por sentarte conmigo para discutir por dónde vamos, cuáles son las mejores líneas de trabajo, cuáles son mis necesidades y cuáles tus preocupaciones.

Yo estoy eligiendote a tí frente a un departamento de IT propio, y en ese gesto estoy arriesgando mi negocio para ponerlo en tus manos. Eso lo hago porque tengo la confianza en que tú, como la gran compañia a la que representas, sabrás estar a la altura, podrás proporcionarme los conocimientos, los servicios, las habilidades y sobre todo la experiencia que yo necesito al ritmo que yo necesito (que es más rápido de lo que tarda mi equipo IT interno en aprender o en ganar la experiencia).

A cambio, espero que podamos establecer un modelo en el cual tú también te ganes la vida, obtengas tus margenes de beneficios y no te ganes la vida regateando ni haciéndome trampas que lo único que harán será minar nuestra relación. Espero también que puedas destinar parte de los ingresos a potenciar el personal que necesitaré el día de mañana. Para eso espero que te preocupes de conocer cuáles serán mis necesidades el día de mañana.

Y de esa manera no serás un proveedor más, serás mi compañero de viaje y yo te preferiré a ti frente a otros porque tú me conocerás y me comprenderás y esa será tu gran ventaja competitiva.

Querido proveedor, me pongo en tus manos. ¡No me falles!

---

Querido Cliente:
Lo que me planteas es muy atractivo, porque para mi es muy complicado establecer de partida un modelo de precios y de servicios que satisfaga tus necesidades (desconocidas en un futuro próximo). Entiende, por favor, que estamos en un momento de bidding y por lo tanto estamos más preocupados por asegurar la venta que por asegurar la prestación: para que exista la posibilidad de prestar los servicios primero es condición indispensable haberle ganado a la competencia y por esta razón en los negocios “normales” tenemos que apretar mucho en esta fase.

¿Qué te parece si por un momento nos olvidamos del dinero? Al fin y al cabo, el importe que tú pagues por los servicios te parecerá barato o caro en función de dos factores fundamentalmente: el mercado (cuánto cobran otros por un servicio similar) y el valor aportado (el valor que aportan mis servicios a tu negocio).

Si establecemos un marco de colaboración fuerte, con interacciones potentes entre tu negocio y mi compañía habremos eliminado el factor “mercado”, pues no habrá en el mercado otro que te ofrezca un servicio similar; al mismo tiempo espero que el valor sea muy superior al habitual gracias a que entenderemos tus necesidades, te podremos orientar en las líneas de acción y podremos entregar rápidamente los recursos que nos pidas pues podremos prever con cierta antelación tus demandas.

Pero para eso te necesito a ti, querido cliente. Porque yo necesito que tú no pienses que “hacer un outsourcing va a arreglar todos tus problemas” y que no te creas que puedes olvidarte de mí. Yo necesito que me cuentes tus problemas, que me expliques qué necesitas y que juntos diseñemos una informática adecuada para tus necesidades, en la que ambos nos sintamos responsables del producto final que le entreguemos juntos a tu negocio. Necesitamos que no haya “unos” y “otros”, sino que trabajemos como un equipo para entregar servicios TIC de calidad.

Sé que no te puedo pedir estabilidad, pero tampoco puedo trabajar apagando fuegos permanentemente… tú tampoco puedes, en estos momentos en que tienes tu departamento propio; no pienses que somos superhéroes que podemos con todo. Hay recursos, hay flexibilidad, pero también hay una capacidad limitada. Hablemos. Prioricemos juntos y tratemos de sacar adelante el máximo de trabajo con las capacidades y herramientas que tenemos.

Y ahora que más o menos tenemos claro qué queremos ambos, tendremos que sacar el tema del dinero: ¿cómo podríamos poner un precio al trabajo realizado? Tenemos que buscar juntos unos drivers económicos que sean justos para ambos: tú quieres valor, agilidad, experiencia, conocimientos. Yo te los puedo dar, pero a cambio quiero beneficios, ganarme bien la vida y poder satisfacer a mis accionistas. Si no lo hago así, no será sostenible y no podré pagarle al personal los sueldos que se merecen y será todo un desastre. Debemos trabajar juntos para encontrar un modelo que sea bueno para ambos, sostenible en el tiempo; que te permita a tí descontarte las mejoras que podamos crear juntos y me permita a mí ampliar el volumen de negocio que tengo contigo.

Prometo no hacer trampas en el corto plazo, ganarme tu confianza, ampliar cada vez más el abanico de servicios que hacemos para tí y mantener unos niveles de facturación razonables (al tiempo que la mejora continua, la innovación, la automatización y la ampliación de negocio me permite garantizar unos márgenes cada vez mayores).

Estoy seguro de que podemos crear una gran relación entre ambas compañías, para eso necesito que no me escojas por ser el más barato en las ofertas, sino por ser el que mejor te puede satisfacer las necesidades actuales y futuras al tiempo que te transmite la confianza necesaria.

Lo esencial es invisible a los ojos

A mediados de los años 70 yo cursaba 3º de E.G.B. Carmen, la profesora que nos había acompañado desde primero, se despedía de nuestra clase deseándonos a todos un gran futuro con una gran sonrisa y para que no nos olvidásemos de ella jamás, nos regaló a cada uno de sus alumnos un ejemplar de El Principito con una dedicatoria especialmente pensada para cada uno de nosotros.

Ese libro me ha acompañado toda mi vida y la historia ha ido variando de interpretación a medida que yo iba creciendo y ganando en comprensión del mundo que me rodea; al principio me llamaba mucho la atención la figura de las boas abiertas y cerradas y cómo era cierto que los mayores no entendían las cosas que les contábamos pequeños porque están tan influenciados por su mundo de mayores y han perdido la habilidad de imaginar que los pobres no entienden nada…

Luego me convertí en profesor y me di cuenta de que las cosas difíciles hay que explicarlas como las explican los niños. Por eso mis clases están llenas de anécdotas, ejemplos y preguntas: tengo que conseguir que los adultos que tengo delante vean el elefante dentro de la boa y no un simple sombrero (a veces, otros profesores más serios ven mis clases y me advierten de que quizás mis alumnos tan serios no van a estar muy cómodos con mi forma de dar clases, pero en general consigo despertar al niño que todos llevan dentro)

Pasaron los años y fui a parar a la mejora continua, los procesos y el uso de LeanIT y aquí volvió a entrar El Principito en acción. Uno de los principios fundamentales del pensamiento Lean es aprender a ver el flujo de valor. El libro que describe el método para representar el flujo de valor (Value Stream Mapping) se llama Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA y ya nos deja claro cuál es el reto

Siempre que hay un producto para un cliente, hay un flujo de valor.
El reto consiste en verlo

…y eso que John Shook, Mike Rother, Jim Womack y Daniel Jones venían del mundo de la fabricación, donde los materiales se mueven, son tangibles y con un poco de paciencia puedes ver cómo fluyen! Quizás por eso pusieron tanto empeño en recordarnos que es un reto: lo que tenemos que ver no es un flujo de materiales sino un flujo de valor.

El flujo de valor en IT

Cuando pretendemos aplicar los métodos de gestión Lean a las tecnologías de la información nos encontramos con que algunos aspectos son esencialmente diferentes al mundo de la fabricación. Uno de estos aspectos diferentes es el concepto de Servicio IT: el servicio es intangible, es invisible, se crea en el momento de consumirse… tiene muchas características que hacen que ver ese flujo sea un reto mucho mayor aún si cabe.

Y cómo vemos y representamos el flujo de valor?

Uno de los personajes que más impactan de El Principito es el zorro. El zorro pide al Principito que lo domestique, pues eso significa crear vínculos y hacer que ambos sean importantes el uno para el otro; pasa el tiempo y el Principito se debe marchar y en la despedida el zorro le dice

–Adiós –dijo el zorro–. He aquí mi secreto. Es muy simple: no se ve bien sino con el corazón. Lo esencial es invisible a los ojos.

Hay varias técnicas para hacer aflorar aquello que es invisible a los ojos, para visualizar el flujo de valor y para representarlo de una forma visual que sea comprensible para todos. La primera, las más utilizada, la que nos enseñan John Shook y sus compañeros es la del Value Stream Mapping:

1. Identifica el flujo que quieres representar. Es decir, pon foco, no trates de representar *todos* los flujos de valor de tu departamento de golpe, que no podrás. Selecciona algo pequeño para empezar, una petición de servicio, por ejemplo. (puntero mental: aquí entra en juego el concepto S+C de Rob England)
   
2. Reúne a un equipo de personas con representantes de las diferentes unidades organizativas o grupos de trabajo por los que pasa la ejecución de este flujo. Si puedes incorporar a un cliente también, mejor que mejor.
3. Provoca un diálogo constructivo en el equipo con el fin de descubrir qué tareas y en qué orden hacemos cada uno para completar la petición (demanda del cliente).
4. Identifica qué tareas debe de hacer el cliente para poder hacer la petición (pull) y qué momentos de la verdad hay durante toda la ejecución de la petición
5. Ten la mente abierta, deja que todo el mundo se exprese y no intentes arreglar nada en ese momento: ahora estamos descubriendo el flujo, no analizándolo ni mejorándolo.
6. Cuando hayas terminado, da un paso atrás y míralo todo con perspectiva: ¿Dónde empieza? ¿Es ahí donde debe de empezar? ¿Dónde acaba? ¿Estás seguro? ¿Hay demanda fallo adicional? ¿Cuál?
7. Repite desde el punto 3 para dar un par de vueltas más

En realidad hacen falta algunos pasos más, porque después de representar el flujo de valor querrás analizarlo y para eso te harán falta más datos, sobre todo de cantidades: cuántas veces hacemos las actividades, cuántas repeticiones, cuánto tiempo tardamos, cuántos recursos hay que lo puedan hacer, cuánta variabilidad, cómo son los patrones de demanda… es decir, tendremos que llenar de números el mapa del flujo que acabamos de hacer, y esos números no son nada fáciles de conseguir.

Aquí entra en juego el método CDO de estimación de valores: piensa en el indicador que quieres calcular. Visualízalo en tu mente. Extiende el brazo todo lo que puedas. Abre la mano separando los dedos y ahora mueve la muñeca de forma oscilatoria mientras piensas “mmmmhhh más o menos soooon cuarenta!”. CDO, son las siglas de los Cinco Dedos Oscilantes (Gracias Jordi Cirera por enseñarme tan magnífica técnica!).

Si no queremos trabajar con estimaciones, entonces tendremos que acudir a sistemas de medicion, pero la gran mayoría de veces nos encontraremos con que no tenemos sistemas de medición adecuados para las tareas que estamos intentando analizar y aquí es donde viene la debacle: si tengo que montar sistemas de medición cada vez que quiera mejorar algo, va a ser más caro remedio que la enfermedad (al menos a corto plazo, claro!) y por eso es por lo que los que trabajamos en Lean utilizamos métodos de estimación y conceptos como el del valor de la información para descubrir qué variable de las que componen nuestro modelo de estimación influye más en la reducción de la incertidumbre.

En los últimos años, ha entrado con fuerza una nueva disciplina en el mundo del análisis de la información: la Minería de Procesos. Se trata de un conjunto de técnicas que tienen su origen en la Universidad Tecnológica de Eindhoven y que nos permite realizar algo parecido a una ingeniería inversa de los procesos utilizando para ello la información de logs y trazas que su ejecución deja en los Sistemas de Información.

Partiendo de estos logs, la primera etapa de la minería de procesos es el Descubrimiento del modelo de proceso, utilizando conceptos tan alucinantes como el algoritmo Alfa o el Heuristic Miner.

Una vez que hemos descubierto el modelo del proceso a partir de las trazas, viene el momento del Enriquecimiento: tenemos toda la información al respecto de quién hace las tareas, cuánto se tarda en ejecutar, cuánto tiempo están las tareas en las colas, qué tipología de tareas, en qué momento se crean los casos y cuánto tiempo tardan… lo tenemos todo, y la minería de procesos es capaz de incorporar toda esa información en el mapa del proceso de forma que puedes comprenderla rápidamente, e incluso puedes hacer un Replay y volver a ver la ejecución de cada uno de los pasos de tu proceso.

Cuando ves un mapa de estos, ocurre que de repente ¡Plaf! lo esencial se hace visible a los ojos… en realidad no estamos mirando con el corazón sino que hemos utilizado las matemáticas para hacer visible lo que hasta el momento sólo eran sensaciones o suposiciones.

La minería de procesos nos abre las puertas a entender cómo funcionan en realidad nuestros procesos, a descubrir los puntos de mejora, las características de cada uno de los pasos del proceso para saber si son estables, capaces, de calidad… Nos abre la puerta a una mejora continua objetiva e incluso a poder demostrar fácilmente si nuestras iniciativas de mejora continua realmente están dando resultados o no, en base a analizar el proceso antes y después de los cambios.

Las posibilidades son enormes, sólo hay que abrir la mente y ver con el corazón para que no se te escape lo esencial.

Más Información

Talleres de Mejora Continua en G2
Monografía sobre Minería de Procesos en la revista Novática (ATI)
Conferencia “Buceando en Standard+Case” en el congreso TFT13
Conferencia sobre el uso de la Minería de Procesos en la Auditoría de Sistemas de Información (ISACA)
Entrevista en Flux Capacitor sobre la presencia en el Process Mining Camp
Conferencia “Process Mining and Lean” en el Process Mining Camp 14
Artículo “Las posibilidades de uso de la Minería de Procesos en ITSM”, finalista para el premio Novática 2013

Lean-IT reloaded

Una certificación vale tanto como las empresas (u otras organizaciones) la exijan, y las empresas la exigirán cuando entiendan su significado y contenidos y cuando vean que un profesional certificado realmente domina la materia de la certificacion.

Por esta razón, el mercado de la formación y las certificaciones profesionales necesita un poco de orden y de estabilidad, para asegurar que no existe un abanico enorme de certificaciones procedentes de diferentes institutos u organismos certificadores sobre las mismas temáticas; si con dos o tres esquemas de certificación profesional sobre Gestión de Servicios o sobre Gestión de Proyectos ya hay dudas al respecto de cuál escoger, imaginemos qué pasa cuando para una misma temática puedes encontrar hasta cuatro o cinco esquemas de certificación diferentes: el mercado se fragmenta, pierde prestigio, los alumnos pierden el interés y ninguno de los esquemas consigue la masa crítica necesaria como para que sea “un estándard de facto reconocido en el sector”.

Esta era la situación en la que se encontraba Lean-IT hasta Marzo de este año: había un gran incremento en la demanda de formación en los conceptos de Lean-IT, pero nadie había definido exactamente qué era. Había un gran interés en certificar al personal en Lean-IT, pero nadie sabía exactamente qué esquema de certificación seguir… cuál será mejor, el Lean-IT Foundations de EXIN o el de APMG? Valdrá la pena el de Quint? Nadie sabía exactamente a qué atenerse, y no podías descartar a ninguno porque todos los players del mercado eran grandes pesos pesados en la industria de la certificación profesional. La situación era complicada y corríamos el peligro de que la cuerda se rompiese.

En un alarde de profesionalidad, en Marzo de 2015 se presentó a nivel mundial la Lean IT Association (http://www.leanitassociation.org ), una organización sin ánimo de lucro formada por tres de los grandes organismos de certificación (EXIN, APMG y PeopleCert) y tres de los grandes en formación (ITpreneurs, Pink Elephant y Quint Wellington Redwood) cuyo principal objetivo es proporcionar una visión homogénea sobre Lean-IT, sus materiales de formación y su esquema de certificación para profesionales.

Un pequeño paso para un hombre...
pero un gran paso para la humanidad.

Al poco tiempo de su creación, la LITA presentaba al mundo su esquema de certificación basado en tres niveles (Fundamentos, Practitioners y Profesional) con cinco certificados orientados a capacitar y a acreditar a los profesionales en las diferentes áreas de trabajo en las que se orienta la aplicación de los principios del Lean Thinking al desarrollo y gestión de los servicios IT.

El nivel de fundamentos ya está definido, con syllabus, temario y exámenes de certificacion y la verdad es que es muy bueno: el alumno se lleva una visión global de los principios del Lean Thinking y su aplicacion en todas las áreas de IT, sirviendo de enlace hacia las futuras certificaciones en IT4IT o hacia las certificaciones en metodologías ágiles.

G2 es Accredited Examination Center y Accredited Training Provider con EXIN y por lo tanto tenemos la capacidad de realizar los examenes de certificación también en el nuevo esquema Lean-IT de la LITA y ya hemos comenzado los primeros cursos de Fundamentos en la UPC Tech Talent School dentro del programa de formación Agile IT Management.

¡Bienvenidos!

IT4IT: L’enfant terrible

En verano de 2014 The Open Group dió a conocer su nueva propuesta de modelo de arquitectura para las TIC llamada IT4IT. Posiblemente no me hubiera llamado mucho la atención si no hubiera sido porque el anuncio de publicación me llegó del mismísimo Charlie Betz, persona a la que sigo asiduamente desde hace al menos unos diez o doce años y autor al que admiro y respeto profundamente. Si lo anuncia Charlie, la cosa es importante!

La primera imagen que le llevas de IT4IT ya es de por sí impactante: un modelo de cadena de valor al estilo Porter con las piezas fundamentales que componen el negocio de las TIC

Eso llama mucho la atención, pero lo más impactante de todo es lo que se muestra en la parte superior: las cadenas de aportación de valor, los cuatro grandes flujos:Strategy to Portfolio, Requirement to Delivery, Request to Fulfill, Detect to Correct. Son las cuatro grandes áreas en las que podemos clasificar el trabajo que se hace en un departamento de IT, los cuatro grandes flujos de valor, el pipeline que todos desean automatizar y mejorar… es una aportación inocente, que muestra las TIC ordenadas en cuatro grandes flujos, pero lo cambia todo:

a) El concepto de servicio sigue existiendo junto con el del ciclo de vida, pero aparece sólo si tu quieres (inicialmente está diseñado para unas TIC orientadas a servicios, pero si lo tuyo no es la orientación a servicios, puedes mover en el pipeline aplicaciones, infraestructuras, o lo que quieras: hablé con un señor holandés que lo utiliza para el uniforme y equipamiento de la policía)

b) Está pensado para ser un modelo normativo: plantea una arquitectura para “el negocio de las TIC”, de la misma manera que eTOM lo plantea para el negocio de las Telco, BIAN para la banca o ACORD para los seguros. La arquitectura estará detallada en niveles, llegando incluso al nivel de atributos y tipos de dato.

c) Si se consigue su adopción, se habilitará un mecanismo increiblemente potente para normalizar el trabajo, integrar procesos multicompañia, evaluar proveedores de sourcing, definir aplicaciones o “ERP para IT”… Piensa en las posibilidades que te daría que el concepto de incidencia fuera homogéneo entre todos tus diferentes proveedores de soporte.

d) Es un modelo con Lean, Agile y DevOps “en el ADN”. Ha nacido pensado para eso

Más tarde, en Noviembre de 2014 me escapé a las jornadas CAS2014 en las que pude hacer un ejercicio importante de inmersión en el mundo de los agilistas, les observé, atendí a sus presentaciones y saqué algunas conclusiones; y una de estas conclusiones fue precistamente “hace falta una teoría unificadora que permita a las TIC ver el flujo completo. Todos necesitamos ver el pipeline”. Y eso me llevó a continuar mirandome IT4IT con muchísimo respeto: no era un modelo más de esos que hay cientos; esta vez hay algunos detalles diferentes.

Durante el congreso gigaTIC15 tuve la oportunidad de presentar junto con Walter Henríquez una charla sobre la evolución que ha vivido Cuatrecasas Gonçalves Pereira después de cuatro años de utilización de técnicas Lean en su centro de soporte, y sobre los retos que se le plantean a la organización en un futuro próximo. La utilización algunos de estos conceptos de IT4IT me vino de perlas para explicar algunas de las problemáticas que tienen Cuatrecasas y cuáles serán las vías de mejora en el futuro:

a) La dedicación del personal a diferentes cadenas de valor sin estar formalizada esta dedicación, hace que se le presete poca (o demasiada) atención a los flujos segundarios

b) La escasa participación transversal de las diferentes unidades organizativas a los diferentes flujos hace que la visión sea de silos en lugar de transversal (pero no organizados alrededor de procesos tradicionales, sino agrupados entorno a cadenas de valor, todo muy Lean)

Finalmente, esta semana se ha celebrado en Madrid el congreso Enabling Boundaryless Information Flow, organizado por The Open Group y que contaba con un track especial de IT4IT en el que presentaba el mismísimo Charlie Betz.

¡¡Cómo me lo iba a perder!!

Así que me planté en Madrid, atendí a todas las presentaciones de IT4IT en las que pude descubrir algunos detalles que explicaré más adelante y por si fuera poco pude asistir como invitado especial a las reuniones de los grupos de trabajo de IT4IT en los que se trataron aspectos del futuro del modelo de arquitectura que no te puedo contar porque me hicieron firmar un acuerdo de confidencialidad, así que lo único que puedo decir de lo que aprendí por la tarde es que en Octubre habrá magníficas noticias.

El punto débil de DevOps

Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)

En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase

 

Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system

o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema

Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.

Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es

Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system

o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.

Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.

Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.

Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.

Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?

Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.

Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.

Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.

Ufff… esto es complicado, pero va cogiendo sentido!

¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).

Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día.

En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.

De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)

En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?

¡Usa los comentarios, por favor!

Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!

Un nuevo libro sobre Lean: Introducción a Lean

La verdad es que no recuerdo bien cómo ni cuándo comenzaron mis contactos con Jose Miguel Vives. Probablemente fuera a través de su blog AltaCuncta o bien a través del timeline de twitter, pero lo cierto es que la proximidad en pensamiento y el buen rollito hicieron que fueramos intercambiando cada vez más correo y charlas por skype.

Al poco tiempo José Miguel publicó en su blog un pequeño libro con una introducción a Lean, que tuve el gusto de revisar y comentar; como la idea era realizar un trabajo de carácter divulgativo, lo puso como descarga gratuita en AltaCuncta y pronto se convirtió en una documentación de referencia dentro de la escena Lean en castellano. Después de eso vino la creación del grupo LeanSpain en LinkedIN, una comunidad de más de 200 personas de diferentes sectores que administramos conjuntamente y que sirve de lugar de encuentro y discusión sobre los diferentes sabores y experiencias en la aplicación de Lean en prácticamente cualquier entorno (hay gente de industria, de sanidad, de informática…)

El contacto con Mark Graban hizo que comentásemos la existencia de una plataforma de publicación especial: LeanPub, y de ahí a que Jose Miguel se pusiera las pilas a escribir no hubo demasiada distancia. Hoy ha nacido el resultado de su esfuerzo: Introducción a Lean, un libro claro, interesante y divulgativo. Está plagado de ejemplos, sacados de las principales industrias que han abordado una transformación Lean y sacados de la vida real como pueda ser la visita al médico de familia. Un gran paso para la difusión del pensamiento Lean en castellano de la mano de uno de los principales divulgadores de esta temática en el país. Además, por el hecho de haber utilizado la plataforma LeanPub, tiene un par de características innovadoras: 1.- Es un libro “con contrato de mantenimiento”: el comprador recibirá de forma gratuita las diferentes actualizaciones que el autor pueda ir realizando sobre el contenido; de esta forma, la mejora continua del contenido del libro te llega de forma directa y sin costes adicionales. 2.- El precio lo marcas tú: a partir de un precio mínimo, puedes comprar el libro por el importe que tú consideres que se merece. El valor lo define el cliente y lo proporciona el autor.