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.

La rana en la olla, agile y los equipos de operaciones

Cuando das clases de muchas temáticas diferentes pasa que durante un curso tu mente se enfoca en una materia concreta y al siguiente curso la materia cambia. Si en medio además te dedicas a hacer proyectos, notas cómo esas materias te influencian fuertemente en tu manera de enfocar o de abordar los problemas que se plantean en la ejecución.

Este último mes he tenido proyectos de agilidad, clases de lean y clases de ITIL® así que mi cabeza es un hervidero de ideas. Entre ellas, esta mañana apareció un flash: ¿que pasa con los atributos de garantía en un entorno ágil?

Hace unas semanas escuchaba a Alex Ballarin en una clase diciendo algo que me hizo sonreír: las historias de usuario pueden usarse también para expresar requerimientos no funcionales, por ejemplo algo así como "Como sistema quiero soportar 1000 usuarios concurrentes para que no se ralentice la cadena de valor"

Con la interpretación “tradicional" de ITIL® vemos el ciclo de vida del servicio como una gigantesca rueda waterfall que lleva un servicio completo desde la Estrategia hasta la Operación y luego lo hace evolucionar en forma de "servicio modificado” con la mejora continua del servicio. Con esta visión es fácil comprender la importancia que tiene en la etapa de diseño que utilicemos las famosas 4P para tener en cuenta los aspectos de garantía del servicio y que incorporemos los requerimientos de garantía en el diseño y posteriormente en la construcción, pruebas y despliegue.

La cosa es grande y viene de lejos, así que nos preparamos para acogerla en nuestro entorno de producción; para ello tendremos en cuenta a los equipos de operaciones o, para ser más itileramente formal, a las funciones de la etapa de Operación del Servicio y por ejemplo prepararemos las infraestructuras para dar soporte al volumen de usuarios que esperamos.

Cuando se avecina un cambio grande, es normal que se cree esa sensación de necesidad de preveer las consecuencias y por lo tanto que se piense en aspectos como la capacidad, la disponibilidad o la seguridad.

Pero… ¿y qué pasa en el momento en que cambiamos el modo de trabajo y pasamos a trabajar el modo “evolutivo” desde el minuto cero?

Peter Senge explica en su libro La Quinta Disciplina el concepto de adaptación a los cambios lentos y graduales y el peligro que conllevan si no estamos atentos y lo ilustra con una parábola que a mi personalmente me pone los pelos de punta por lo cruel de la idea: la parábola de la rana hervida. Muy cruel, pero explicita!

Si ponemos una rana en una olla de agua hirviente, inmediatamente intenta salir. Pero si ponemos la rana en agua a la temperatura ambiente, y no la asustamos, se queda tranquila. Cuando la temperatura se eleva de 21 a 26 grados centígrados, la rana no hace nada, e incluso parece pasarlo bien. A medida que la temperatura aumenta, la rana está cada vez más aturdida, y finalmente no está en condiciones de salir de la olla. Aunque nada se lo impide, la rana se queda allí y hierve. ¿Por qué? Porque su aparato interno para detectar amenazas a la supervivencia está preparado para cambios repentinos en el medio ambiente, no para cambios lentos y graduales.

De repente ocurre que en algún momento aparece esa necesidad de soportar 1000 usuarios concurrentes, la implementamos y luego se producen 200 modificaciones posteriores a las funcionalidades del servicio en forma de sendas historias de usuario que se implementan en sprints sucesivos…. y de repente esas pequeñas modificaciones que una a una eran poquita cosa hacen que nuestro sistema deje de soportar 1000 usuarios concurrentes.

Técnicamente esto no debería pasar, porque a cada modificación hacemos pruebas de regresión y pruebas de los requerimientos funcionales y nos aseguramos de que cada pequeño cambio no rompa nada, pero… por favor, que levante la mano el que esté dispuesto a asegurar que hace eso para todos sus servicios en la etapa de construccion.

Si salen más de 10, prometo borrar este post.

En resumen, que propongo que al menos para empezar, la historia de usuario se reescriba para contemplar este peligro y quede en algo asi como

Como sistema, quiero soportar 1000 usuarios concurrentes y seguir soportándolos despues de los próximos 10 sprints. Depués volvemos a hablar de demanda, capacidad y arquitectura.

A media que vayamos madurando y consigamos un flujo continuo con todos los requerimientos de información necesarios, una arquitectura flexible y escalable y un sistema de testing automatizado que nos garantice que cumplimos los requisitos no funcionales en modo regresión entonces podremos modificar la historia de usuario para reflejar el objetivo real:

Como sistema quiero soportar el numero de usuarios concurrentes que necesite el negocio en todo momento de modo flexible, elástico y con una estructura de costes asumible por la organización.

Pero eso requiere un nivel de madurez enorme en toda la organización: el negocio debe decir de forma continua (o casi) la demanda prevista, la capacidad debe poderse adaptar de forma instantánea, las arquitecturas deben poderse redimensionar al momento y todo esto con un esquema económico razonable… o podemos quitar al negocio de la ecuacion y montar un sistema flexible y automatizado que crezca o decrezca según la demanda real…

¿Ciencia Ficción?

¡Preguntale a Etsy o a Netflix!

PS:: Iba a ilustrar este post con alguna foto… lo primero que me vino a la cabeza fue esta preciosa ranita de San Antonio del blog Naturaleza Andaluza, pero finalmente me he negado…. no se ha dañado ninguna rana para escribir este post. Ojalá Peter Senge piense en otra parabola menos salvaje!

El secreto que el itSMF no quiere que sepas

Hace un par de meses me llamaron desde el equipo que organiza el X Curso de Verano del itSMF para preguntarme si me gustaría participar en una de las clases. La temática de este año es Preparando a los profesionales de IT para la transformación digital, algo que es imprescindible para la evolución que tendrán las empresas en los próximos años.

Llevo colaborando con esta asociación desde su fundación allá por el año 2005, así que no podía negarme; planteé una clase teórico-práctica sobre el impacto que tiene la cultura DevOps en la prestación y operación de servicios y me encajaron en la agenda, que puedes consultar en este enlace.

¿Has visto los contenidos? ¡Como cada año, este curso de verano es interesantísimo! Hablaremos de Modelos de Transformación, de Bimodal-IT, de DevOps, de Gamificación... todo aquello que necesitas echarte a la mochila para facilitar la transformación digital de tu compañía (por ejemplo, leiste el artículo que publiqué hace unos meses titulado "¿Transformación Digital? ¡No sin DevOps!" )

Cuando el equipo del itSMF España publicó la agenda del curso, me sorprendió agradablemente ver que el precio del curso es de 295€; teniendo en cuenta los contenidos y la duración del curso es un precio más que razonable. Pero cuando se envió el mailing presentando el curso a los miembros del itSMF vi encantado que el curso es gratuito para los miembros de la asociación!!

El X Curso de Verano del itSMF España, centrado en las habilidades y conocimientos que debe adquirir el Área de TI para facilitar la Transformación Digital es una actividad gratuita para socios.

Así que si eres miembro de esta gran asociación, no tardes en inscribirte al curso, en cualquiera de sus sedes. Pero... ¿y si no eres socio? ¿Tienes que pagar los 295€ que cuesta la inscripción al curso?

Aquí es donde viene el secreto que quiero contarte... el itSMF España lleva 11 años dando charlas, haciendo congresos, publicando documentos, haciendo whitepapers. En definitiva, esta asociación lleva 11 años compartiendo conocimiento en prácticas relacionadas con la Gestión de Servicios y todo ese conocimiento está almacenado en las interioridades del portal de socios de la organización.

Esta asociación organiza anualmente al menos tres congresos (el Nacional, el de Catalunya y el Universitario), varios encuentros regionales, varios seminarios en modalidad online, un curso de verano y uno de herramientas. Todas esas charlas y presentaciones se ponen al alcance de los miembros de la asociacion sin que esto suponga un coste extra al importe de la membresía; y hacerte socio de itSMF España cuesta 100€ al año.

Hacerte socio del itSMF España sólo cuesta 100€ al año y te aporta más beneficios de los que te esperas

Así que si quieres asistir al curso de verano, enterarte de todo lo que vamos explicar y de rebote tener acceso a la mayor biblioteca de prácticas de gestión de servicios en castellano hazte socio del itSMF España ya mismo, antes de que se den cuenta y cambien las políticas de membresía o suban los precios!

La primera paga extra

Corría el año 1983 y yo entraba en el instituto con la cabeza llena de ideas y sobre todo con una pasión que me había acompañado desde que tengo memoria: la biología. Desde que tengo recuerdos, yo iba a ser biólogo, a ser posible entomólogo o herpetólogo, y mi mayor héroe era Gerald Durrell, que se había criado de una manera muy parecida a mi, en una isla y rodeado de bichos (para muestra, un botón: el libro “Bichos y demás parientes”).

Una vez en el instituto conocí a Víctor, quien se convertiría en uno de aquellos amigos “para toda la vida” y que compartía conmigo un montón de aficiones e intereses, como la música y las matemáticas (pero no la biología). Víctor tenía una calculadora HP de aquellas que se programaban en notación polaca inversa y eso era la bomba! No había nada más entretenido que pensar en cómo hacer que la calculadora aquella nos ayudara con los problemas de trigonometría. A mitad de curso yo ya pensaba que después de hacer biología me gustaría aprender algo de informática.

Más adelante, Víctor me presentó a un amigo suyo que estudiaba FP y que tenía una calculadora programable que se programaba en Basic, una Casio PB-100

No me lo podía creer! Aquello era la bomba! *Necesitaba* una..! Me la prestó un fin de semana y creo que no hice otra cosa durante esos dias que programar y programar… había que ver qué era capaz de hacer esa maravilla.. ¿multiplicar determinantes? ¿hacer integrales definidas? ¿calcular fórmulas químicas?

Unos años antes, en 1976, había desembarcado en Gran Canaria un equipo de El Corte Inglés con la misión de construir el primer centro de los grandes almacenes en la isla. Escogieron para construirlo justamente el solar que había al lado de mi casa, allí donde los chiquillos del barrio jugábamos a futbol o practicábamos tiro al blanco con piedras y latas vacías. En 1977 inauguraron por todo lo alto el local con bendiciones del párroco de la Iglesia del Pino incluidas!

Así que para los años de instituto yo ya era un asiduo a pasar el tiempo libre echando un vistazo en los escaparates de El Corte Inglés; hasta que un día los chicos de ECI pusieron a la venta una “cosa rara”: un ordenador personal (??) que se conectaba a la televisión y se podía programar: un Sinclair ZX-81. Yo inmediatamente me llevé a mi padre a ver aquello y a decirle que me encantaría tener una cosa de esas, pero la respuesta de mi padre fue tajante: “Eso es una porquería. El día que tengan un ordenador de verdad, te compro uno."

¡¡Un ordenador de verdad!! Y el maravilloso ZX que tenía delante qué era?? Pues a ojos de mi padre, el ZX-81 debía ser poco más que una calculadora programable o incluso menos! Así que hubo que esperar. Pero mientras esperaba yo iba casi cada día a mirar aquel aparato, luego vinieron otros: el Spectrum, el Casio portable, los diferentes fabricantes y modelos de MSX, el Vic-20, el Commodore 64...

Pasaron al menos dos o tres años en los que yo invertía gran parte de mi tiempo libre en ir a la Planta 4 de El Corte Inglés a toquetear ordenadores; todo lo que aprendía en el instituto lo intentaba aplicar así que “inventé” las curvas de lissajous (luego descubrí que ya estaban inventadas), implementé los algoritmos para multiplicar determinantes, descubrí que si pintas una gráfica en la que la X se mueve según un sin(t) y la Y se mueve segun cos(t) obtienes una circunferencia (si y solo si las dos variables están debidamente sincronizadas) y luego cuando en el instituto me explicaron las coordenadas polares me resultó obvio: ¡ya lo había descubierto en El Corte Inglés!

Llegué a conocer a los dependientes y ganamos tanta confianza que cuando un “adulto” entraba preguntando por un ordenador para comprarle a su hijo, lo redirigían a mí para que le explicara para qué podría usar el ordenador su criatura.

Y un buen día llegué yo a la cuarta planta y uno de los chicos me dijo “Mira: ha llegado esto; a ver qué puedes hacer con él”… y allí estaba… flamantemente nuevo, un Amstrad CPC 464 con sus 64Kb de RAM y lo que era más alucinante, su monitor de súper alta resolución que podía darte 320x200 en cuatro colores!!

No me lo podía creer, aquello era un pedazo de ordenador; seguro que sería lo que mi padre llamaba “un ordenador de verdad”. Así que lo llevé a verlo y … no!, seguía siendo un juguete; así que tocó seguir aprendiendo, programando y casi que trabajando en El Corte Inglés.

Para acortar un poco la historia, cuando Amstrad presentó el CPC-6128 ya en el año 1985, aquello ya se pareció a “un ordenador de verdad”, así que mi padre hizo un tremendo esfuerzo (que lógicamente ocultó y del cual yo no fui nunca consciente) y me compró el aparato. Ya con él en casa, me conseguí un manual de programación en ensamblador y de llamadas al sistema (fuera lo que fuera aquello) y escribí mi primer juego en ensamblador (una variante de Tron, película que me había dejado encandilado por aquella época)

El resto ya vino rodado; un día estaba en El Corte Inglés y llegó un señor a preguntar quién podría hacer un programa para llevar el control de los gastos de la flota de ambulancias de la Cruz Roja y el dependiente me señaló a mí. Fueron mis primeras 10.000 pesetas ganadas honradamente programando; luego alguien de Indescomp buscaba a un programador que pudiera hacer las traducciones del software educativo al castellano y comencé a trabajar para ellos: me daban los diskettes del software en inglés y con una herramienta muy parecida a las PC-Tools, yo traducía aquello al castellano con un editor hexadecimal. Ahora mirándolo en la distancia me parece que la cosa no debía ser muy legal, pero yo estaba convencido de que si, porque ellos eran “la casa madre”.

Ya para esa época había abandonado la idea de estudiar Biología (bueno, en realidad decía que estudiaría Biología después de Informática; que la Informática sería para comer y la Biología para gozar), así que cuando estaba en 3º de BUP me compré una calculadora Casio FX-850P que me acompañó durante todos mis años de facultad y que aún tengo en mi poder en perfecto estado. Entré en la Facultad de Informática de la ULPGC y empecé a jugar en una liga más importante, así que vendí el CPC-6128 y me compré mi primer PC, un Amstrad PC1512 que fué rápidamente substituido por un Inves 80286 (También de El Corte Inglés!).

Así que cuando la semana pasada ví en la tele la publicidad de El Corte Inglés titulada “La primera paga extra” me emocioné mucho… parecía como si alguien de ECI hubiera entrado en la agencia de publicidad a pedir un spot emotivo y hubiera contado mi historia; el chaval baja las escaleras feliz por haberse comprado su primer iPad y yo comencé a construir mi futuro gracias a aquel Amstrad y al buen criterio de mi padre que no quiso comprarme un “ordenador de juguete” sino que decidió que había llegado el momento de hacer el gran esfuerzo familiar cuando vio que aquello realmente me interesaba.

33 años después, GRACIAS.

Gracias a mis padres, por el pedazo de esfuerzo que sé que tuvieron que hacer.
Gracias a mi familia, por el apoyo que siempre me han mostrado.
Gracias a mis amigos, por darme el empujón que me cambió la vida.
Y Gracias al equipo de El Corte Inglés que trabajaba en la Planta 4 del centro de Mesa y Lopez 15 porque podrían haberme echado o haberme dicho “niño, no toques los ordenadores que son muy caros”, pero sin embargo me dejaron hacer durante los 3 ó 4 años que estuve yendo hasta que entré en la Universidad y me facilitaron el acceso a algo que no me podía permitir fácilmente.

¿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!