archivo

Archivo de la etiqueta: mejora continua

Un aspecto que me parece muy interesante para ser analizado en las retrospectivas son las contingencias o incidencias que se han producido en la última iteración o que se están produciendo de un tiempo a esta parte en el proyecto y que han tenido un impacto significativo en él, de tal forma que han puesto en riesgo o directamente han impedido que se alcancen los objetivos marcados hasta la fecha (a nivel de sprint o a más alto nivel).

Dentro de ese análisis me parece fundamental hacer autocrítica sobre esas incidencias y determinar para cada una de ellas si se han podido prever o no. No se trata de hacer un juicio sumarísimo sobre quien o quiénes se hayan podido equivocar sino de tratar de poner medidas para reducir el riesgo de que este tipo de situaciones se vuelvan a repetir en el futuro porque lo que es evidente es que si no se hace nada, otros problemas similares a estos o incluso estos mismos volverán a producirse.

En ese análisis nos daremos cuenta que en la mayoría de los casos se podría haber previsto el problema, es duro pero hay que asimilarlo, insisto, si no se asumen los errores es imposible mejorar.

Dentro de los previstos habría que diferenciar los casos en los que siendo previsibles no han podido serlo debido a que la carga de trabajo era excesiva o a que la atención estaba centrada en otros aspectos como consecuencia de prioridades marcadas desde más arriba, ya que el problema en estos casos no es de una falta de atención, previsión, despiste, exceso de confianza, falta de conocimiento o negligencia y las actuaciones a realizar para tratar de evitarlos en un futuro son distintas.

Si las normativas, procedimientos o procesos de desarrollo de software de tu organización no cambian o lo hacen en contadas ocasiones y en aspectos de poca trascendencia querrá decir, probablemente, que nos encontramos con alguna de las siguientes circunstancias:

1) Se ha descubierto un “martillo de oro” que permite que todos los desarrollos de la organización se realicen de la forma más efectiva posible independientemente de las características propias de cada proyecto.

2) No existe ningún tipo de intención y/o política de mejora continua y no por el hecho de que se haya encontrado esa llave que abre todas las puertas, sino porque se ha creado una cierta zona de seguridad sin analizar si realmente la misma aporta o no un valor a la altura de la inversión que hay que realizar en la misma tanto para su aseguramiento como para su aplicación (sobre todo).

Aunque pueda parecer sorprendente, cuando la normativa no cambia es porque hay un poco de ambas, por un lado se cree que se ha alcanzado una solución óptima para el contexto (es importante eso porque, muchas veces, cuando se analizan cambios, la defensa del inmovilismo se centrará en que las innovaciones no son válidas para el entorno de trabajo o la naturaleza de la organización) y por otro, el proceso está tan consolidado (que no es equivalente a obtener resultados) que apetece poco hacer cambios.

Ante estas circunstancias, podemos sospechar y lo más probable es que no nos equivoquemos es que unos procesos que no cambian se convierten con el paso del tiempo en obstáculos cada vez mayores porque los proyectos sí que viven en primera instancia la incertidumbre y los cambios de contextos y si se establecen límites artificiales, ajenos a esta realidad, se estará mermando la capacidad de las personas de poder hacer frente a ellos.

La palabra proceso nos crea la imagen mental de burocracia y esto es así no porque nos hayamos levantado de esa manera una mañana sino porque la mayoría de nosotros ha sufrido procesos de desarrollo de software que daban lugar a un mayor coste que a un beneficio real y que estaba lleno de hitos y entregables que se convertían en un obstáculo más que solventar en el ya de por sí complejo camino que son los proyectos de desarrollo de software.

Sin embargo, por mucho que no soportemos los procesos, muy probablemente aplicamos determinadas metodologías, estrategias o prácticas que en esencia también son procesos, lo que pasa es que como muchas de ellas para nosotros son automatismos o confiamos en sus resultados, no las vemos de esa forma.

¿Qué quiero decir con esto? Pues que tal vez el problema no se encuentra en el concepto sino en su definición e implementación, en la falta de una visión orientada a su mejora continua (si un proceso no sufre ajustes algo está pasando) y a la falta de flexibilidad que se ofrece a la hora de adaptarse a las particularidades concretas de cada proyecto.

Un proceso debe aportar, no restar. Si nos pone límites ficticios que dificultan nuestro margen de maniobra quiere decir que nuestros resultados en el proyecto estarán condicionados por impedimentos que perfectamente podrían haberse eliminado, ¿no es absurdo en estos casos abogar por la ortodoxia en lugar de la solución que más conviene?.

En los proyectos de desarrollo de software intervienen infinidad de variables y es el resultado de la colaboración de una serie de personas y no hay nada más impredecible que un ser humano, por ese motivo la definición de los procesos debe tener en cuenta esa circunstancia.

No se trata de acertar a la primera sino de tener capacidad de ir adaptándolo y mejorándolo con la experiencia y de dotar a su aplicación de la flexibilidad suficiente (incluyendo excepciones) para adaptarse lo máximo posible a las necesidades concretas que requiere el proyecto.

La efectividad de Kaizen puede verse sensiblemente mermada si el cortoplacismo (centrarnos exclusivamente en los problemas que tenemos ahora) o la complacencia tomen el mando.

Precisamente creer que se está lo suficiente bien, que no se puede mejorar o que la clave de nuestro éxito o fracaso está fuera de nosotros es uno de los principales enemigos de Kaizen. Sin espíritu crítico, sin la capacidad de reconocer errores o sin el valor de tomar decisiones, no es posible establecer estrategias orientadas a la mejora continua que tengan algún tipo de repercusión real y no solo eso, dará lugar a una importante pérdida de tiempo (porque cualquier acción se quedará en palabras) y creará frustración entre aquellos que sí crean que es posible y necesaria una mejora continua.

Kaizen pretende que siempre se sea competitivo, de manera que incluso en procesos o acciones en donde se están obteniendo buenos resultados de manera objetiva, se considera que es posible mejorar e incluso alcanzar otro nivel, ya que se parte del hecho de que si no lo haces tú, siempre habrá otro que tarde o temprano lo hará.

Al seguir una estrategia de mejora continua, Kaizen no pretende la realización de cambios a gran escala, sino que se basa en la filosofía de que pequeños cambios que se van consolidando (con una visión general de lo que se pretende conseguir) terminan afectando de manera positiva al conjunto de la organización.

Su funcionamiento no puede ser más simple: cambio, monitorización y ajuste. Lo realmente complicado es priorizar cuáles deben ser esos cambios, seleccionar las acciones que resulten más apropiadas y por encima de eso, conseguir que la mejora continua forme parte de la cultura de la organización.

Kaizen es aplicable a diferentes escalas que van desde la organización en su conjunto, departamentos, grupos de trabajo, proyecto, hasta llegar al nivel de las propias personas.

No debemos olvidar pese a que el contexto en que lo estamos tratando es a nivel de organización o de negocio, Kaizen trasciende esas fronteras y su filosofía puede ser válida para cualquier ámbito de la vida.

Cuando se aplica a un dominio de personas se considera que todas son importantes porque al fin y al cabo todas intervienen en su proporción correspondiente y atendiendo a su rol a que la mejora sea efectiva, se considera admisible si fuera necesario la participación de otras personas ajenas al dominio si se considera necesario.

Kaizen no trata las mejoras como una necesidad que surge en un momento dado en el tiempo: “algo está fallando o entiendo que es posible mejorar en tal o cual aspecto”, sino que debe tratarse como un proceso diario, más allá de estrategias de mejoras puntuales, lo que hace necesario que formen parte de la cultura de la organización.

Kaizen es eminentemente proactivo, no se esperan señales de fuera (más allá de las necesarias para verificar el efecto de un determinado cambio) para poder actuar, si bien no puede ser ajeno a acontecimientos externos que requieran una reacción.

La necesidad de una mejora continua en todos los ámbitos y a diferentes escalas se enfrenta a diario con nuestros problemas y prioridades a corto plazo. Estamos tan ocupados con ellos que pocas veces nos paramos a reflexionar en equipo o individualmente sobre qué estamos haciendo bien y qué estamos haciendo mal, en qué podemos mejorar, qué acciones aplicar para conseguir esa mejora y cómo vamos a verificar si efectivamente lo estamos consiguiendo.

La mejora continua necesita constancia y requiere que seamos metódicos, no vale con que se hable de ello en una reunión o en un desayuno porque las palabras son solo palabras y la mejora continua requiere acción y verificación.

En algunas metodologías ágiles a través de las retrospectivas se trata la mejora continua como parte del propio proceso de desarrollo y es algo lógico porque no se puede entender la agilidad sin ella, porque la agilidad trata, entre otras cosas, de capacidad para adaptarse al cambio dentro de un umbral de tiempo razonable (que es aquel en el que no has perdido tu capacidad competitiva o que no te suponen unas pérdidas difíciles de recuperar).

Todo lo que sea minimizar ese tiempo es un valor que tiene la organización, el equipo de trabajo o el proyecto y eso solo se consigue desde una visión critica y objetiva del modelo, de las prácticas y de las propias personas, sin olvidar el contexto y las circunstancias reales (siempre con los pies en el suelo).

Kaizen es un término japonés que significa mejora o buen cambio (proviene de dos palabras kai y zen que vienen a significar respectivamente cambio y bueno o beneficioso). No tiene un componente temporal y tampoco define una filosofía de trabajo, refiriéndose a acciones que, de manera puntual o gestionadas en el tiempo, producen una mejora.

Su asociación al concepto de mejora continua surge precisamente por la falta de un término en japonés que significase exáctamente eso, por lo que a falta de encontrar una solución mejor, se utilizó para asociarle un término a los procesos de mejora continua en los procesos industriales o de negocio que se realizan en Japón, teniendo como principal estandarte a los que se venían aplicando y utilizando en Toyota.

Me parece muy acertada la siguiente reflexión de Watts Humphrey (traducción libre):

“Los cambios en los procesos de desarrollo de software se complican a menudo por el hecho de que no hay nadie responsable de que se lleven a cabo.

Si la mejora de los procesos de desarrollo de software no es el trabajo de nadie, no te extrañes de que no se consiga. Si es lo suficientemente importante, alguien debe tener asignada la responsabilidad ofreciéndole los recursos que sean necesarios.

Hasta ese momento, la mejora en los procesos de desarrollo de software seguirá siendo algo interesante que hacer algún día, pero no hoy”.

¡Cuántas horas de charla en reuniones e interminables hilos de correos electrónicos para nada!. Filosofando sobre qué está fallando y cómo podemos mejorarlo, discutiendo (incluso acaloradamente) sobre distintos puntos de vista porque cada uno ve el desarrollo de software desde su perspectiva, formación y experiencias.

La realidad es que las palabras se quedan en nada si no hay nadie dispuesto a asumir el peso del cambio y si no se le ofrecen los medios necesarios.

Y el cambio es un proceso continuo, no termina nunca si lo que se quiere es encontrar el camino de la mejora continua.

No basta con hacer una ruptura con respecto al modelo actual porque lo mismo la solución es equivocada y seguro que será mejorable, no debemos quedarnos ahí. El problema es que una vez alcanzada esta fase cuesta otra vez mucho trabajo volver a realizar cambios, de manera que en lugar de ser continuos se convierten en escalonados (si es que se consigue de nuevo tener voluntad para el cambio) y se reacciona, tal vez, demasiado tarde ante circunstancias que no son positivas en los procesos de desarrollo.