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!

BCN DevOps Tour

El itSMF es una asociación veterana; recuerdo cuando en 2005 nos reunimos en Madrid para iniciar las conversaciones para su fundación y cómo en aquel momento el foco principal de todos los que estábamos allí era aprender, compartir y difundir conocimientos relacionados con la Gestión del Servicio.

En el año 2005 la Gestión del Servicio era ITIL. No había mucho más a lo que agarrarse y así fue como el itSMF España se convirtió en algo muy parecido a todos los demás itSMF del mundo: el foro de la gente interesada en ITSM y por consiguiente el foro que difundía ITIL. Las primeras acciones fueron traducir el glosario, los libros de ITIL V2 y la norma ISO 20.000-1 al castellano… todo hervía alrededor de ITIL.

El tiempo fue pasando y gracias a la visión estratégica que siempre ha caracterizado a las diferentes instancias de la Junta Directiva fuimos incorporando otros marcos de referencia y otras prácticas… y así ha sido hasta estos días en que hicimos un curso de verano centrado en DevOps y un congreso especializado en Agilidad: el itSMF se consolida como la asociación de aquellos que estamos preocupados por la Gestión de Servicios a lo largo de todo su ciclo de vida y eso incluye nuevas maneras de crear, mantener y evolucionar los servicios como son los métodos ágiles y las prácticas DevOps.

Pero eso no es todo! Tambien nos interesa la gente, sus prácticas, su manera de organizar el trabajo, su manera de relacionarse y de organizarse… así que incorporamos aspectos de motivacion, de organizacion y de Lean-IT.

Todos estos intereses tan variopintos se reflejan en los congresos que hacemos por toda la geografía; este año hemos tenido (así, que yo recuerde ahora mismo y de memoria) e Madrid, Barcelona, Asturias, Valencia y Sevilla…pero eso nos sabía a poco así que hace poco más de un año en el comité de Catalunya iniciamos un experimento con los meetups: pretendiamos vernos más a menudo, algo más frecuentemente que una vez al año. (Ya tardas en inscribirte siguiendo el enlace!!)

Pues este mes de Diciembre de 2017 todo esto converge en una gran iniciativa que ha contado con la participación de miembros del comité de Catalunya, miembros del equipo de itSMF España y empresas “usuarias” que desean compartir experiencias: El próximo 12 de Diciembre arranca el BCN DevOps Tour, una iniciativa en la que pretendemos acercar a la comunidad de expertos en Gestión de Servicios las prácticas #DevOps y lo que ello significa en las empresas que están utilizándolas. Para ello hemos buscado a varias empresas finalistas, de diferentes sectores y que estén llevando a cabo actividades relacionadas con DevOps para iniciar una conversación abierta y enriquecedora sobre qué hacen, qué quieren hacer, beneficios, problemas, herramientas, resultados y todo aquello que quieran compartir con nosotros.

La primera sesión será en el Campus Norte del IESE y contaremos con la participación de Jordi Badía, CIO de Venca, quien nos explicará el impacto que ha tenido DevOps en su organización.

Quieres venir?

1. Inscribete en este enlace
2. Haz RSVP en la web de meetup
3. Marca el Martes 12 de Diciembre de 18:00 a 20:00 en tu agenda como ocupado

No te puedes perder esta iniciativa única en la que aprenderemos directamente de los que están en las trincheras… quieres venirte al Gemba con nosotros?

PS:: Ayudanos a difundirlo, comparte enlaces, comentarios y opiniones con tus amigos en las redes sociales y echanos una mano a llenar el aula!

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.

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!

PS2: Pues resulta que este post inspiró a mi amigo Rui Soares, autor de ITIL Blues y creador de los personajes Mush & Room, quien me dibujó la  fantástica ilustración que acompaña  este artículo. GRACIAS!