¿Cuál es el ciclo de eventos para Kanban?

Kanban no prescribe eventos rigurosos como Scrum. En su nueva clase de Lean Kanban "Practicing the Kanban Method" David Anderson introduce 7 cadencias de Kanban: el ciclo de reuniones que impulsan el cambio evolutivo y la prestación de servicios "aptos para el propósito". Estos son los 7 eventos que a lo largo de 5 niveles de madurez del modelo de madurez Kanban (KMM) que abarcan la estrategia y el escalado con Kanban.

Ciclo de eventos Kanban - Créditos de la imagen: Leankanban.com

Las meetings (reuniones) tratan la entrega del servicio y las reviews (revisiones) tratan mejoras del servicio.

Strategy Review

Trata de una reunión de revisión del equilibrio estratégico entre la demanda de servicios (solicitudes) y la capacidad para entregar a los clientes esas solicitudes a través un portfolio de servicios de la empresa a lo largo de todo el "sistema de sistemas". En la reunión se realiza una evaluación sobre cómo estos sistemas están respondiendo a las demandas solicitadas y cómo toda decisión de mejora en los sistemas ha impactado en la satisfacción del cliente.

Operations Review

Una reunión de revisión de cómo funcionan los sistemas Kanban individuales, de como funcionan juntos y de cómo sus dependencias están siendo equilibradas por la organización respecto a la demanda y a la capacidad del "sistema de sistemas" general.

Service Delivery Review

La revisión de la prestación de servicios refleja el estado actual y el comportamiento pasado de las decisiones del equipo con respecto a las expectativas de sus clientes. El propósito es discutir y decidir sobre los cambios que el equipo puede emprender para abordar las variaciones o el mantenimiento de la idoneidad del sistema Kanban para el propósito con el que está sirviendo al cliente.

Risk Review

Una reunión para la revisión de los riesgos que podrían afectar negativamente la capacidad de entrega al cliente de un servicio del sistema Kanban. Esto podría implicar la revisión de más de un sistema Kanban, aunque se enfoca principalmente en la capacidad de entrega del sistema Kanban que se está revisando.

Replenishment/Commitment Meeting

Trata de una reunión de reabastecimiento que se produce a intervalos regulares o idealmente en función de la disponibilidad de las opciones y la capacidad del sistema Kanban. Esta reunión determina qué elementos de trabajo se comprometerán en el sistema Kanban.

Standup Meeting

Reunión diaria organizada por el equipo, o los equipos, para poner foco y atención en la información que refleja su tablero Kanban y decidir en qué trabajos aplicar su energía y esfuerzo.

Delivery Planning Meeting

Reunión cuyo fin es planificar/replanificar la entrega de un lote de trabajo de valor para el cliente, y que tiene lugar con la frecuencia suficiente para garantizar que el sistema Kanban cumpla con su propósito y atienda a las necesidades del cliente.

Podemos identificar 10 ciclos de feedback en el diagrama de ciclo de eventos, estos muestran el flujo de información y los flujos de solicitud de cambio entre las diferentes reuniones. El flujo de información está destinado a facilitar la toma de decisiones; por ejemplo, el resultado de una Replenishment/Commitment Meeting aparecerá como información en una Standup Meeting. Las solicitudes de cambio implican que algo no está funcionando lo suficientemente bien, que existe la percepción de que alguna política actual está llevando a un resultado que no es "adecuado para un propósito"; por ejemplo, Service Delivery Review y Operations Review proporcionan información sobre la capacidad a la Strategy Review que redundará en una solicitud de un cambio de estrategia debido a la falta de capacidad operativa para cumplir con la estrategia actual.

¿Con Agilidad la jerarquía de directivos ha de romperse?

Intento de mapeo de la estructura actual con la que aporta SAFe

Una de las preocupaciones más comunes en una transformación ágil surge del hecho de que en Agilidad los equipos son autoorganizados y que por tanto todos somos gestores y ejecutores a la vez, dejando claramente fuera al jefe y al gerente, y a todos aquellos que gestionan otras personas. Eso conlleva claramente un cambio en las responsabilidades, y a primera vista parece que implique que los directivos pierdan el control sobre la organización, que se tenga que aplanar la misma y romper la jerarquía existente.

De ahí que las empresas tradicionales busquen "transformaciones ágiles" en marcos donde puedan "mapear" su jerarquía. Un ejemplo ocurre cuando descubren el marco de SAFe, lo perciben como complejo y intuyen que con sus cuatro capas se le puede trasladar la jerarquía existente.

En realidad lo único jerárquico en el marco de SAFe es el flujo entre las pilas, ni siquiera las pilas son jerárquicas, una pila da misión a la pila del nivel inferior para que esta esté alineada con la estrategia, pero cada una es independiente en sus elementos para así poder adaptarse y hacer que el sistema genere el máximo valor de negocio posible.

Recordemos que no se puede gestionar a personas que saben más de su trabajo que el gestor, el jefe o el gerente, pero si se les puede liderar. Ese es el punto clave; jefes de proyecto tienen cabida como Scrum Masters y Propietarios del Producto por ejemplo. Jefes de proyecto con habilidades sociales que siempre han protegido a sus equipos pueden ser excelentes Scrum Masters, y jefes de proyecto enfocados en la ejecución de proyectos pueden ser excelentes Propietarios del Producto. Y otros, excelentes técnicos que han llegado a jefes de proyecto por el desarrollo profesional clásico, pueden volver a desarrollarse en su talento como técnicos expertos en forma de miembros de equipo, de sistemas o arquitectura.

Con una formación adecuada y una transición hacia la mentalidad ágil, estos pueden convertirse en lideres al servicio que pueden mantener a los equipos de desarrollo en un entorno basado en las motivaciones intrínsecas desarrollándolos en verdaderos equipos hiperproductivos.

En definitiva los jefes de proyecto se convierten en System Thinkers que observan al equipo de forma holística, lo apoyan, lo proveen de recursos necesarios, eliminan impedimentos y desarrollan a sus miembros. El mismo enfoque se le puede dar a cualquier directivo, gerente o gestor de la organización. En cada nivel jerárquico hay un sistema que liderar, sea un equipo, un área o la organización al completo. Las organizaciones necesitan lideres que guíen en la dirección estratégica por ejemplo, líderes que den la visión y misión a su área, tren o tribu, líderes que inspiren y apoyen.

Desde esta perspectiva la jerarquía de una organización puede permanecer, la clave está en transicionar de una cadena de mando a una jerarquía operativa basada en el liderazgo. Establecer objetivos comunes que impulsen a colaborar a los líderes y a sus sistemas asociados y eliminar muros de confusión puede permitir que la organización pueda alinearse en su operación con los flujos de valor desde la perspectiva de la Agilidad.

Este enfoque alternativo puede ser un punto de partida que puede servir para una transición hacia una gobernanza como la sociocracia por ejemplo, en la que una jerarquía de círculos autoorganizados a diferentes niveles y doblemente enlazados en representación y voz y voto, gobiernan una organización de una forma alineada con la Agilidad.

¿Cuales son los mayores impedimentos o retos al implantar Agilidad en una organización?

Conocimiento ≠ Entendimiento

Cuando esta pregunta la planteó un estudiante aparecieron inmediatamente en mi cabeza dos impedimentos con los que he lidiado una y otra vez.

La ignorancia: en nuestra tradición empresarial TI no solemos dar el valor que se merece la formación. En las situaciones más rancias con las que me he encontrado el cliente no invierte en la formación en Scrum de los "externos" porque no son empleados suyos, y la consultora tampoco lo hace porque no le ve valor, y si lo hace es porque el cliente lo exige. Esta situación ha ido mejorando, actualmente he visto invertir en exámenes de certificación, como scrum.org, aunque muy poco en clases presenciales. El problema es que la formación no presencial no es transformacional y difícilmente alinea la mentalidad del estudiante con la Agilidad.

La formación a los directivos y negocio también es importantísima, han de entender la Agilidad para entender que han de premiar a quien se arriesgue, para que permitan el fallo y se produzca el aprendizaje continuo y para que sean verdaderos apoyadores en el cambio. El conocimiento ≠ entendimiento, el conocimiento la da la formación, y para adquirir el entendimiento hay empezar a caminar y tropezar las veces necesarias para aprender.

Como suele decirse "la ignorancia es valiente", en algunas transformaciones no se escucha demasiado a los expertos, a los coaches ágiles, y en cambio los directivos no expertos se les permite poner restricciones que son innegociables.

La falta de alineamiento: es muy usual que las diferentes áreas o diferentes grupos en una organización tengan diferentes metas y objetivos, creando una sensación de trabajo constante con poco o ningún progreso, ya que los esfuerzos de unos son anulados o minimizados por los esfuerzos de otros.

El gráfico vectorial de la izquierda de Geoffrey Moore muestra diferentes vectores que representan el trabajo, lo hacen a través de una dirección (estrategia/objetivos) y una magnitud (esfuerzo). Si los equipos e individuos no están alineados y sincronizados, sus esfuerzos se anulan entre sí dando un trabajo neto de cero.

Los impedimentos más fuertes para el alineamiento son la competencia y los intereses personales, ambos fomentan la no colaboración. Estructuras por silos con objetivos no alineados fomentan la competencia, y esta hace que haya pocos ganadores y muchos perdedores, pero sobre todo que haya un gran perdedor: la organización. Por otro lado, en un sistema de sueldos basados en variables y bonos se alimenta los intereses personales, ya que los individuos para maximizar el variable acaban priorizando las acciones alineadas con sus intereses.

La falta de alineamiento a lo largo de los flujos de valor es otro impedimento importante. Negocio, desarrollo y sistemas/arquitectura deben de ir alineados, y tal como fomenta la cultura DevOps, hay que comprender que no hay entrega de valor si la misma no es una responsabilidad compartida por todos ellos.

Leading Change de Kotter

A parte de los dos impedimentos mencionados he observado que se suelen producir los ocho grandes errores que menciona John P.Cotter en su libro "Al frente del cambio" ("Leading Change"):

• Permitir demasiada complacencia
• Fallar en la creación de una coalición de agentes del cambio empoderada
• Subestimar el poder de la visión
• Subcomunicar el poder de la visión en 10-100X
• Permitir obstáculos para bloquear la nueva visión
• Fallar en la creación de ganancias a corto plazo
• Declarar la victoria demasiado pronto
• Desatender asentar los cambios firmemente en la cultura corporativa

Todo cambio requiere su aprendizaje, su tiempo y su camino, y no hay atajos. Por tanto las transformaciones ágiles se han de producir a la velocidad que hayan de producirse, y desde mi perspectiva, aunque haya impedimentos como los mencionados en el post, el panorama actual en las organizaciones muestra una evolución general en dirección Agilidad, y eso es un éxito en si mismo.

¿Cómo resolver un reto rápidamente con técnicas de Design Sprint?

Sprint de Jake Knapp

Design Sprint es una técnica con la que resolver retos y problemas y testar las ideas generadas en 5 días, describe un proceso de creatividad que ha dado excelentes resultados en Google.

En las tribus, trenes (ARTs) y equipos de equipos hay mucho conocimiento de la realidad con la tratan día a día, mucho más conocimiento colectivo del que pudiéramos imaginarnos. En esta ocasión el reto que me pusieron trataba de utilizar técnicas de Design Sprint para obtener tantas ideas para casos de uso nuevos para Big Data como fuera posible, y no solo eso, hacerlo ¡solo en dos horas! Menos mal que el prototipado y el testeo quedaban fuera del taller.

El taller fue un éxito, obtuvimos una docena de casos de uso nuevos y modelamos tres ellos en menos de dos horas. En este post quiero describir nuestra experiencia.

Roles

• Decider: rol que tiene la tarea de tomar decisiones rápidas a lo largo del proceso para desbloquear al equipo de Design Sprint y continuar avanzando, y el poder de voto decisivo en las votaciones. En el taller fue el Propietario del Producto, el interesado principal en obtener nuevos casos de uso.
• Moderator: rol con un único responsable para asegurar que el equipo de Design Sprint siga los pasos del proceso dentro del tiempo asignado y llegue al final dentro del plazo, en nuestro caso el coach ágil.
• Expertos: miembros de los equipos que trabajan directamente en el producto en cuestión, en nuestro caso los miembros de los chapters de Data Scientists y Data Engineers al completo.

El proceso

Definimos el reto con el que trabajar: Obtener nuevos casos de uso

Tablero con ideas para casos de uso

Para obtener ideas aplicamos la técnica de brainstorming más común:

• En individual cada miembro del equipo escribió ideas de posibles casos de uso en post-its, y de forma optimista sin descartar ninguna idea por loca que pudiera parecer.
• Las consolidamos en un tablero, cada participante hizo un pequeño resumen de la idea de cada uno de sus post-its.
• Finalmente el decider agrupó las ideas y las priorizó.

El siguiente paso consistió en el mapeado de las ideas, en nuestro caso trabajamos los tres casos de uso prioritarios:

• Identificamos los puntos de partida y los colocamos a la izquierda de una hoja de rotafolios.
• Identificamos los objetivos y beneficios y los colocamos a la derecha.
• Identificamos y dibujamos los pasos entre los puntos de partida y los beneficios en medio, en nuestro caso un use case jorney que son los puntos de interacción con el cliente.

Obtenidos los mapas tomamos una perspectiva pesimista y buscamos problemas bloqueantes para esas 3 ideas de mayor prioridad. Estos blockers los escribimos en forma de HMW (How Might We) o "¿Qué podríamos hacer para [solucionar el blocker]... ?", por ejemplo "¿Qué podríamos para incrementar el número de usuarios?". Finalmente colocamos los post-its con los HMW en los puntos de interacción afectados en el mapa.

Resultado con un caso de uso modelado

Para buscar soluciones a los blockers todo el equipo visitó los mapas y los HMW, para hacer brainstorming desde la perspectiva de como lo resolverían otras empresas como por ejemplo:

• Ikea
• Google
• La competencia

Finalizamos el taller después de que cada participante colocara su solución en el mapa, lo expusiera e hiciéramos un debate para que todo el equipo convergiera en un modelo para cada una de las ideas, en nuestro taller para cada uno de los casos de uso.

El taller, aunque alejado del proceso original de Design Sprint, fue un éxito. Las tres ideas de casos de uso obtenidas se prototiparon y se testearon, se definieron sus indicadores predictivos y sus OKRs, y se incorporaron en la pila de producto de la tribu para su desarrollo.

¿Cuáles podrían ser los principios de un Manifiesto Ágil de Servicio al Cliente?

Trabajo por grupos para obtener los principios

La experiencia de generar un Manifiesto Ágil de Servicio al Cliente con 52 profesionales del sector fue muy interesante, obtuvimos 5 valores que demuestran claramente la mentalidad de personas sobre procesos.

Aprovechamos el meetup "Experiencia de transformación Agile en un entorno no IT: Equipos Agile de mejora de la Experiencia del Cliente", en el que expusimos el éxito de Scrum aplicado a un equipo de procesos de Servicio al Cliente, para obtener posibles principios para el Manifiesto.

La idea consistió en exponer a agilistas usuarios de servicios de móvil los valores del Manifiesto Ágil de Servicio al Cliente, y que estos como conocedores del Manifiesto por el Desarrollo Ágil de Software, propusieran en grupos de 4/5 personas los principios desde la perspectiva del cliente. Obtenidos los principios por grupos, cada asistente podía votar un máximo de 3 principios de todos los propuestos. Los votos sirvieron para seleccionar los más representativos y consolidarlos en 14 principios coherentes. Y he aquí el resultado del Manifiesto con sus valores y principios:

---

Manifiesto Ágil de Servicio al Cliente

Estamos descubriendo nuevas formas para enfocarnos a aportar valor a nuestros clientes y a ofrecerles la mejor experiencia con nuestros servicios. A través de este trabajo hemos aprendido a valorar:

• Descubrir las necesidades de los clientes a través de su feedback sobre procesos establecidos y productos rígidos
• Resolución de problemas en el primer contacto sobre esperar a haya un volumen crítico
• Segmentación del cliente por necesidad y valor añadido al mismo sobre beneficios monetarios y necesidad comercial
• Sencillez y transparencia sobre producto ofrecido bajo un marco contractual
• Honestidad para reconocer y compensar los errores sobre justificaciones que puedan generar falsas expectativas

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Principios del Manifiesto Ágil de Servicio al Cliente

Seguimos estos principios:

• Nuestra mayor prioridad es satisfacer al cliente mediante la excelencia operativa escuchándolo para mejorar su experiencia.

• Somos proactivos desde el primer contacto con el cliente para entender su verdadera necesidad y resolver su problema a través soluciones efectivas y oportunas.

• Junto al perfil de consumo del cliente diagnosticamos sus emociones y percepciones para customizar adecuadamente la solución a ofrecer.

• Evitamos procesos largos y difíciles para minimizar los tiempos de resolución de los problemas de nuestros clientes.

• Aceptamos la queja, la critica o el feedback negativos como oportunidad de mejora continua a través de la definición de acciones concretas.

• Los responsables de las diferentes áreas de la compañía y los equipos de Servicio al Cliente trabajan juntos de forma cotidiana.

• Los Servicios al Cliente se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

• El método más eficiente para comunicar información al equipo y sus miembros es la conversación cara a cara.

• La resolución rápida y efectiva de problemas es la medida principal de progreso. Los clientes que nos recomiendan son el principal indicador de nuestro éxito.

• El método más efectivo para una buena experiencia de cliente es probando nuestros experimentos en un entorno real, involucrando al cliente para obtener su feedback de manera directa.

• Asumimos y aceptamos los errores como parte de nuestro proceso de aprendizaje y compensamos al cliente en consecuencia.

• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

• Las mejores soluciones a necesidades de cliente emergen de equipos autoorganizados.

• A intervalos regulares el equipo reflexiona sobre como ser más efectivo.

---

Los tableros con los principios obtenidos por los diferentes equipos

Mis agradecimientos a todos los participantes del Meetup por su aportación a los principios, a Miguel y a Dani por hacerlo posible y a Gertrudis por su colaboración como coautora en este post ;-)