No es ningún misterio que muchas veces se llama Scrum a la dinámica que muchos equipos tienen simplemente por tener Sprints, Product Owners, Scrum Masters y reuniones. De igual manera que si no podemos planificar se opta por denominar Kanban a la dinámica que se sigue. Y al final ninguna de las 2 corresponde con ellas.
Repetir dinámicas o disponer de roles propios de un framework no garantiza que un equipo o una organización sea más agile. Después de todo somos humanos y en ocasiones (quizás más de las que nos gustaría) podemos equivocarnos. Antes de abordar cómo vamos en esto de la agilidad en habitissimo hagamos un repaso de algo habitual que suele pasar y que forma parte del proceso de muchos equipos y/o empresas. Y es que lo que sucede es que en muchas ocasiones los árboles no dejan ver el bosque.

Si hay un rol que caracteriza a una dinámica Scrum es el del Scrum Master. Básicamente es quien tiene que liderar ese cambio a agile y, por lo tanto, quien supone tener el mayor conocimiento sobre el proceso y el marco de trabajo Scrum. Lo bueno de la inspección y adaptación continua es que nos ayuda a identificar aquellas cosas que no nos hacen tan agile. Por eso detectar cosas como éstas en tu día a día cuando eres Scrum Master y descubres que hay algo que cambiar, por mucho que lideres esa ‘transformación’ hacia la agilidad…. que, dicho sea de paso, no tiene por qué pasar por Scrum, aunque suele ser la opción más obvia.

Patrones anti-scrum del Scrum Master (by Stefan Wolpers)

Es una práctica habitual ‘mapear’ un marco de trabajo o una aproximación de tal manera que se adapte la forma de trabajo que previamente existía. Pero no nos tiremos piedras encima, ésto es un proceso por el que muchos pasan y que es fácilmente detectable si hacemos realidad esa ‘inspección y adaptación continua‘.
Por poner ejemplos, es habitual transformar a un Product Manager en Product Owner, pero ejerciendo todavía de la manera previa. También sucede que las reuniones empiezan a denominarse daily en vez de briefing, pero sigue reportándose en ellas y, lo que es peor, el P.O. que es un P.M. sigue trasladando peticiones o requisitos en ellas. Las reviews o demos son reportes extendidos y las retrospectivas reuniones de catarsis colectiva para dirimir qué no hay ido bien y desahogarse. En cuanto a las planning, lo cierto es que, se reducen bien a refinamientos o simplemente a la asignación de tareas previamente planificadas al sprint que toca. En ocasiones, todo de acuerdo con lo que determinado consultor o especialista ha instruido para reorientar de Waterfall a Agile, usando ‘Scrum‘.
Y, si no se puede planificar, se opta por ‘escoger’ una dinámica ‘Kanban‘ o lo que es lo mismo mapear en un tablero lo que se va haciendo y seguir con dinámicas Scrum, pero sin plannings, reviews/demos (y si las hay es porque en el fondo son reportings) e, incluso, eludiendo las retrospectivas.

En cualquiera de las 2 situaciones un equipo no será más agile, simplemente usará técnicas de ambas aproximaciones agile y, en muchas ocasiones, tan solo habremos incrementado el número de eventos y convertido el proceso en mini-cascadas en vez de un proceso iterativo e incremental. Es decir, generaremos patrones anti-agile que podríamos denominar ‘de manual‘.

Hay que recordar, eso sí, que para ser ágiles hay que empezar y, evidentemente, uno no se pone un día el traje de ‘agile’ y se convierte en ello. Hay que abrazar éste proceso e incluso los errores que cometemos en él. Cuanto antes detectemos estas cosas, antes iteraremos a una consciencia más agile, independientemente de si hibridamos aproximaciones o marcos de trabajo.

No está mal utilizar técnicas de ambas aproximaciones, siempre y cuando éstas se utilicen de forma eficiente y se denominen por lo que son. Por ejemplo, usar un tablero no te hace ‘kanban‘ y tan solo te proporcionará visibilidad, que es la primera de las 6 prácticas de Kanban: VISUALIZAR el FLUJO de TRABAJO. Pero que no nos aportará mucho más que visibilidad si no analizamos qué pasa, qué podemos hacer y cómo podemos mejorar. Es decir, aplicar el resto de prácticas:

  1. Visualizar el flujo de trabajo.
  2. Eliminar interrupciones, y por lo tanto asumir que no somos multitarea y establecer un límite de Trabajo en Curso.
  3. Gestionar el Flujo de trabajo, y hacer que éste sea continuo e ininterrumpido.
  4. Hacer las políticas expresas, y así garantizar que todos en el equipo estén alineados con el objetivo común y la manera de conseguirlo.
  5. Crear circuitos de retroalimentación, y así garantizar que existen momentos para revisar el trabajo en equipo, compartir y dar feedback, incluso con el cliente.
  6. Mejorar colaborando y aplicar el método científico, para poder orientar al equipo hacia la mejora continua consensuada.

De igual manera no está mal aplicar elementos del framework de Scrum si esto nos ayuda a ser más ágiles, lo que implica en muchos casos un desarrollo iterativo e incremental. Por ejemplo, los roles han de cumplir su función y los Product Owner tener la ‘propiedad del producto’ teniendo capacidad real de decidir sobre la priorización y qué se afronta en cada Sprint. De igual manera que el equipo de desarrollo pueda determinar sin lugar a dudas el ‘cómo’ se realiza. Ésto, que parece tan obvio, no es factible en una organización con una marcada vertiente jerárquica y en la que se hablar de recursos en vez de personas. Más aún, es más que habitual encontrar que el P.O. lleve los requisitos de negocio al equipo en forma de requerimientos y, en muchos casos, ni siquiera representar los intereses del cliente. O, también por ejemplo, ¿cómo un equipo de desarrollo puede ser multidisciplinar si ‘estratégicamente’ se ha decidido que todos estén ‘especializados’ en Frontend?.
Éste y otros anti-patrones de Scrum son habituales cuando la ‘transformación agile‘ se inicia ‘desde abajo‘.

Un equipo puede estar siendo ‘fiel’ al marco de trabajo Scrum que, dicho sea de paso, es relativamente sencillo. Pero no por ello estar alineados los valores y principios ágiles recogidos en el ‘Manifiesto Agile‘. Simplemente aplicarán un marco de trabajo pero, ¿lograrán el objetivo que se proponían?, ¿lograrán ser más ágiles? Ésto, evidentemente, será relativo.

Ser ágiles, ¿eso qué es?

La respuesta fácil es: aplicar los 4 valores del Manifiesto Agile. Es decir:

  • Individuos e interacciones por encima de procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta al cambio sobre seguir un plan.

En definitiva, no consiste en aplicar Scrum, Kanban, XP o cualquier otra aproximación ‘estructurada’ o ‘pre-instalada’ en los equipos. Ésto ayuda sin duda, da un estructura a quien quiere empezar y no sabe como, pero no es una garantía. Sin embargo tener siempre presentes estos 4 valores nos ayuda a determinar si vamos camino de ser ágiles, independientemente de la aproximación que escojamos. Es decir, el camino a ser agile quizás pase por ser ‘agnóstico de la metodología’ y ‘fiel a los principios y valores’, lo que nos proporciona un mayor margen de maniobra e, incluso, considerar solo los elementos que nos ayuden a iterar de forma continua y constante hacia ello. Sin olvidar, eso sí, que ‘ser agile’ no es un fin en sí mismo si no una actitud con la que poder alcanzar los objetivos de nuestra organización.

Una observación: el Manifiesto Agile tiene ya un par de décadas a su espalda y desde entonces poco ha cambiado, sin embargo los tiempos y la forma de hacer y entender el software sí. Posiblemente si cambiasemos ‘Software‘ por ‘producto‘ en esa segunda frase quizás para muchos tenga más sentido y su aplicación sea más amplia.

Hibridación y aproximaciones sistémicas

Y así entramos en el proceloso mar de la hibridación, algo que a nivel creativo es bastante habitual. Y lo primero que pensarás es que te estoy hablando de ‘Scrumban‘ y que eso, precisamente, NO es una metodología como tal. Y tendrás razón… en parte. Esa parte en la que muchos equipos cogen los que les parece para ser ‘más ágiles’ pero sin entender el sistema del que forman parte. Por ello viene bien recordar un poco de dónde viene el término y, en concreto, esta charla de Corey Ladas sobre ello o, más bien sobre la aplicación de Sistemas Kanban para Desarrollo de Software Lean (ver el video un poco más abajo).

A priori el término Scrumban surgió como una forma de describir la iteración de un equipo Scrum incorporando dinámicas Kanban en su flujo de trabajo cuando el marco de trabajo no les resultaba suficiente. Es decir, en cierto modo, aplicar más principios Lean a su proceso de desarrollo de software. De esta manera, por ejemplo, el tablero Scrum se convierte en un tablero Kanban que ofrece una más información y mejor visualización del flujo de trabajo, se inician prácticas como la limitación de trabajo en curso con el fin gestionar este flujo e identificar las ineficiencias. El objetivo es claro, disponer de políticas expresas para impulsar una cultura de mejora continua y, por ende, actos de liderazgo a todos los niveles.
Si quieres saber más, puedes echar un vistazo a la siguiente charla.

Sin embargo antes de hablar de aplicar una u otra metodología hay que tener en cuenta 3 factores: la evolución, historia y cultura de la organización en la que aplicarla. O, lo que es lo mismo, el ‘estado actual‘ que definirá el sistema que queremos ‘transformar’.
Personalmente prefiero no ‘etiquetar’ las cosas y, mucho menos, los procesos. Mi opinión al respecto es simple: si le pones nombre es por que es tu criatura. Así, si alguien tiene que etiquetarlo, es el conjunto de personas que desempeñan su trabajo en una organización, aquellas que tienen propiedad de su proceso. Considero que, por mucho que se hable de ‘Scrum’, ‘Kanban’, ‘Agile’ o lo que se tercie cada organización tiene sus particularidades. Por eso quizás sea preferible más que hablar de ‘metodologías’ o marcos de trabajo, hablar de sistemas y, concretamente, de sistemas organizativos. De hecho un sistema se define como:

Un objeto complejo cuyas partes o componentes se relacionan con al menos alguno de los otros componentes, bien sea material o conceptual“.

Y también como:

“Un conjunto ordenado de normas y procedimientos que regulan el funcionamiento de un grupo o colectividad”.

Y, sí, ésto es la aproximación sistémica de la cual se parte para ‘implantar’ un sistema Kanban en una organización. Comenzando por analizar el estado actual para paulatinamente ir iterando y mejorando el sistema. No es casual: cada empresa es diferente, cada grupo humano lo es y, sin lugar a dudas, han seguido un proceso de evolución propio y particular. No hablamos de contexto únicamente, si de ‘proceso e historia’ también y, por eso, entender cual es el sistema existente en cada organización es el primer punto de partida para conseguir la agilidad, bien en los equipos bien en la empresa. Aunque ésto último, sin duda, daría lugar a otro post, quedémonos con la idea de que conocer el sistema sobre el cual actuamos nos dará la claves para accionar aquellos elementos a modificar para lograr un cambio sustancial en el mismo. Y, también, que ésto está ligado con la idea de un:

“desarrollo constante y sostenido”.

Lo que, a su vez, está ligado con la idea de que la consecución de objetivos de forma sostenible en el tiempo quizás no pase por cambios radicales y explosivos de forma y, si, con cambios paulatinos iterativos e incrementales. Esos que, precisamente y a pesar de ser casi imperceptibles, se notan con el tiempo y garantizan la resiliencia de una organización.

¿Estamos camino de ser Agile en habitissimo?

Work In Progress es, quizás, la definición más adecuada al respecto. Al igual que otras muchas organizaciones nos encontramos en un proceso de inspección y adaptación constante para evolucionar a un desarrollo iterativo en el que también haya integración continua. Responder con un SÍ rotundo a la pregunta de si somos ágiles, sin duda sería algo pretencioso, pero responder con un NO sería también bastante incorrecto. Y, dejando de lado la teoría cuántica, podríamos decir que estamos en un estado intermedio y con la actitud adecuada para llegar a serlo. No hay que olvidar que el proceso para ser ágiles implica cuestionar dicho proceso y detectar aquello que nos hace ser más ágiles y aquello que no. Es un proceso de mejora continua y la mejora continua dista de la complacencia.

Durante un tiempo hemos aplicado Scrum con algunas ‘licencias’ para alinear la forma de trabajo de los equipos con la cultura preexistente de la empresa. Es decir, a pesar de un marco de trabajo claro, la cultura, la historia y el proceso de la organización han condicionado, como en cualquier otra, la ‘implantación’ del mismo. También la naturaleza del trabajo. No es lo mismo acometer trabajo en modo ‘proyecto‘ y, por lo tanto, planificable, que trabajo en modo ‘servicio‘ y, por lo tanto, no planificable. Ésto no quiere decir que no hayamos aplicado Scrum tal y como lo indica la guía Scrum, tampoco que no tuviésemos claro que queremos ser lo más ágiles posible. Simplemente que hemos tenido un proceso de adaptación con el que sin duda nos hemos ido acercando al ideal agile. No es nada nuevo, Shu Ha Ri es un concepto que, aún proviniendo de las artes marciales, describe muy bien nuestro proceso de aprendizaje. En él primero aplicamos técnicas fundamentales según el manual (Shu), para después encontrar puntos donde podemos mejorarlo (Ha) y finalmente asimilarlo como parte de nuestra identidad desarrollando nuestra forma de ser ágiles (Ri).

http://1.bp.blogspot.com/_9kQQgQD35rY/Sdutzf6SRxI/AAAAAAAAAmg/p5GGUOZ2vzI/w1200-h630-p-k-no-nu/shuhari.jpg

En la actualidad podemos decir que, a nivel de Tecnología y Producto, estamos progresando en una aproximación híbrida que intenta obtener lo mejor de las 2 aproximaciones más extendidas: Scrum y Kanban. Sin perder de vista la incorporación de prácticas contempladas en XP y orientándonos a la entrega continua y centrados en el usuario. Ésto nos permite estar abiertos al continuo cambio y que los equipos puedan escoger si funcionan en modo ‘servicio‘ o ‘proyecto‘ en función de la naturaleza del trabajo que han de realizar. La incorporación de perfiles especializados en UX y Data en los equipos los hace multidisciplinares y aproxima la realidad del usuario a los equipos de desarrollo. Y, de igual manera, la integración de Product Owners dedicadas y coordinadas en una comunidad de Producto en continuo contacto con los StakeHolders garantiza la visión de negocio.

Sin duda estamos en progreso y, si tomamos los 4 valores ágiles como punto de partida, vemos que no estamos nada desencaminados. De hecho, podemos afirmar que:

  • Nuestra organización prioriza las personas y sus interacciones, ésto incluye el cada vez más marcado carácter ‘user-centric’ que la define.
  • Trabajamos para ofrecer una entrega continua y, por lo tanto, software/producto funcionando como muestra de progreso.
  • Nuestro servicio de Atención al Cliente está en continuo contacto con el equipo de desarrollo gracias al trabajo de las P.O. y, por lo tanto, éste conoce para qué desarrolla software.
  • El cambio es una constante y no dudamos incluso de cambiar prácticas que no aportan valor ni al usuario ni al equipo de desarrollo para lograr un proceso de mejora continua. Lo hacemos a través de la inspección continua.

Caminante no hay camino, se hace camino al andar…” decía Antonio Machado.

  •  
  •  
  •  
  •  
  •  

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.