eficiencia

Escalando Kanban

Cuando se trata de escalar el desarrollo de productos de software, la mayoría de las organizaciones miran a soluciones como SAFe, LeSS o Nexus. Sin embargo, hay algo que olvidan: la parte de gobernanza.

Es fácil perderse en hacer Scrum o Kanban a nivel equipos o a nivel producto, pero la mayoría de las organizaciones tienen decenas o incluso cientos de productos, internos y externos, que poseen una fuerte interdependencia. Una de las soluciones es Scrum Studio.

El caso de Kanban y su acercamiento a la agilidad es distinto. Sigue un camino distinto, en el que prima la adaptación sobre la disrupción. Conforme vamos creando servicios dentro de nuestra organizaciones que podemos gestionar con Kanban, establecemos las reglas que gobierna la interacción entre ellos.

Para entender Kanban hay que pasar por tres etapas, que conducen a tres paradigmas fundamentales.

Aprender a crear flujo

Aunque pueda parecer muy abstracto (a quién no le pareció abstracto el concepto de Scrum Master la primera vez que oyó hablar del mismo) esto tiene un sentido fundamental: Si no somos capaces de identificar cuál es el proceso que sigue el trabajo desde que lo ideamos hasta que lo entregamos, nunca seremos capaces de controlarlo. De igual manera, si no sabemos cuántas habitaciones tiene nuestra casa, nunca podremos mantenerlas limpias y ordenadas.

Además, para crear flujo, es necesario limitar el trabajo en cada uno de los procesos que sigue nuestro trabajo. Sólo así podremos empezar a gestionar nuestro sistema. A esto se le llama crear límites WIP (Work in Progress).

En esta etapa conseguimos:

Dejar de empezar trabajo y empezar a terminarlo
Aprender cómo funciona nuestro sistema para mejorarlo
Generar transparencia y momentos de inspección y adaptación

Entender las organizaciones desde la perspectiva de los servicios

Uno de los conceptos de más difícil asimilación de mis estudiantes de Kanban es entender la diferencia entre un servicio y una clase de servicio.

Mientras que el primero está relacionado con identificar y aprender a ver la organización como una serie de servicios interdependientes que se retroalimentan unos a otros, el segundo es asignar una dimensión de riesgo a nuestros ítems de trabajo, una prioridad. Basada en datos. ¿Cuál es el coste de no terminar algo a tiempo?

Por ejemplo, un departamento de RRHH puede ofrecer distintos servicios: Un servicio de recruitment, un servicio de onboarding de nuevos empleados y un servicio de gestión de altas, bajas y notificaciones. Ambos son interdependientes y a la vez son sistemas separados que hay que tratar como tal.

En esta etapa conseguimos:

Medir los tiempos de espera
Analizar la eficiencia de nuestro flujo de trabajo
Adaptar un servicio para que ofrezca mejores resultados
Entender cómo los servicios se relacionan entre ellos

Convertir nuestra organización en una máquina orientada a deleitar al cliente

Sólo los mejores consiguen llegar a entender esta última etapa, en la que empezamos a unir unos servicios dentro de nuestra organización con otros para conseguir crear una máquina afinada, un reloj perfecto que continuamente supere las expectativas de nuestros clientes.

En esta etapa, las organizaciones gestionan la demanda de los clientes de tal manera que siempre pueden saber donde algo está fallando, adelantarse a la competencia y ofrecer una propuesta de valor única.

En esta etapa conseguimos:

Adaptar nuestra organización al milímetro
Incrementar exponencialmente los niveles de innovación
Métricas en tiempo real de cómo va nuestro negocio
Ultraagilidad

En este video, David J. Anderson comenta los 7 problemas más comunes que nos encontramos al escalar Kanban.

El mito de la eficiencia

Hace unos meses, en un esfuerzo por reducir mi altísima carga de trabajo, contraté a una empresa de Granada para llevar la gestión del Marketing Online de los cursos públicos. Nada muy sofisticado, apenas consistía en llevar campañas de Google Adwords, Facebook, la gestión de las publicaciones en redes sociales y un rediseño del material y la web. Mi principal problema era de tiempo, no de conocimiento. Para mi, es mejor externalizar todo lo que no añade directamente valor a las formaciones y centrarme en mejorar su calidad.

Saqué dos horas de mi agenda para sentarme a hablar con ellos y explicarles cuales eran los detalles y la problemática que tengo. Sabía que tocaba hacer muchos deberes y podía aprovechar las dos semanas siguientes para trabajar en lo que hiciera falta. Tres semanas después, contactaron por primera vez conmigo después de nuestra reunión para enviarme un presupuesto. Había perdido mi ventana de oportunidad.

A pesar de todo, intenté darle salida y buscar tiempos antes de las 8 de la mañana para hacer reuniones telefónicas y darles lo que necesitaran. Todo se encasquilló en torno al diseño de unos banners, que en un principio estaban presupuestados pero luego no lo estaban. Les dije que si, que necesitaba avanzar, pero la discusión siguió en torno a si serían 90€ o 120€ más por hacer los banners. Me da igual, les dije. Necesito sacar esto adelante.

Siete semanas después de sentarme por primera vez, por fin pudimos darle salida a la primera campaña en Adwords. No había banners y del resto de cosas que quería hacer ni siquiera tenía un presupuesto. La gota que colmó el vaso fue cuando descubrí que pretendían cobrarme sus servicios por adelantado. Unos servicios que, por lo que había visto hasta ahora, eran increíblemente ineficientes. Desde el punto de vista del flujo.

Cuando les comuniqué que no pagaría por adelantado más que lo que estaba estipulado en el contrato, la persona del departamento de Publicidad me remitió al departamento de Administración, que a su vez me dijo que tendría que remitirme al departamento de gerencia. ¿Sabes cuantos empleados tiene esta empresa, incluidos los socios? 11. Entre solo 11 personas habían creado un entramado de departamentos y de colas de espera que serían el deleite de cualquier ejecutivo de un call-center de Telefónica.

Eficiencia de recursos y eficiencia de flujo

Desde el punto de vista de esta pequeña compañía, probablemente tienen un entramado eficiente. Alguien que se encarga de comercial, algunas personas lo hacen de publicidad, hay un departamento de administración. Todos funcionan como silos perfectos que se comunican entre ellos. Están equivocados. La eficiencia matará su compañía.

Es la manera perfecta de maximizar el número de horas que una persona está ocupada. De identificar si hay una sobrecarga de trabajo en un área determinada. No contratan más gente hasta que el sistema está al borde del colapso.

Es eficiencia de recursos.

Los recursos son limitados y el objetivo es maximizar su eficiencia introduciendo nuevos recursos sólamente cuando es completamente necesario.

El problema reside en que esta eficiencia de recursos no tiene en cuenta la satisfacción del cliente. Yo, como cliente que planea invertir miles de euros al mes en sus servicios, espero una atención rápida y deliciosa.

Cualquier compañía digital entiende que lo importante no es cuan eficientes seamos, sino la velocidad de adaptarnos a las necesidades del cliente. En otra compañía de similar tamaño, me reuní directamente con la persona que se encarga de la publicidad, que además es el único punto de contacto para mi, como prospecto o como cliente. En un par de horas tenía un presupuesto y el tiempo para tener la campaña online era de un par de días.

Este enfoque se llama eficiencia del flujo.

Aquí, lo importante no es utilizar todas nuestras horas de forma óptima, sino que el tiempo de espera sea el mínimo, mientras que la densidad del valor añadido sea máxima.

Si contamos con que el tiempo de creación de valor añadido: Reunión, definición, alta de campañas, facturación y cobro son 15 horas en ambos casos, la eficiencia de la primera compañía es de apenas un 1.2%, mientras que en la segunda compañía es del 20.8%.

Como se puede ver, lo importante no es optimizar la eficiencia de los subprocesos, sino la experiencia global.

Cada vez que introducimos una optimización en uno de esos subprocesos, reducimos la eficiencia de flujo del total de la experiencia de cliente.

La base de Lean

Esta diferencia entre eficiencia de recursos y eficiencia de flujo es la base de Lean, un proceso que situó a la Toyota de la posguerra como el mayor fabricante de automóviles del mundo, por encima de compañías americanas y europeas con un porcentaje de optimización de recursos mucho mayor.

Esta es también la base de la transformación digital, en la que prima la velocidad de respuesta al consumidor que la capacidad de optimizarnos internamente.

Cómo la eficiencia hundió tu empresa

Hace unos días di un curso para una compañía muy conocida. Casi al final del segundo día, uno de los asistentes, Manager, me dijo: ¿Entonces cómo mido la eficiencia de la gente? ¿La eficiencia de la gente? Sí, claro… si trabajan o si no.

Estaba anonadado. Casi no sabía qué decir.

Justo en ese momento de la clase hablábamos de medir la productividad a través del throughput (ritmo de entrega) y la variabilidad de cada uno de los ítems entregados. Una alternativa mucho mejor al uso de Story Points. Tan distinta como comparar la homeopatía con un tratamiento médico de doble ciego.

Un ejemplo: Si un equipo entrega de media 10 Product Backlog Items y otro entrega cinco, eso no nos da mucha información. Los PBIs pueden ser más grandes o más pequeños, o el equipo tener distintas capacidades técnicas, el stack puede ser más o menos complicado y un sinfín de situaciones.

Pero si además de decir si un equipo entrega 10 o 5, lo acompaño con el número -medio- de días que tardan en entregar, entonces si tengo una métrica realista. Dos equipos, uno entregando 10 PBIs y otro entregando 5, que entregue en 20 y 10 días respectivamente, tendrán una productividad similar.

Pero esto no era suficiente.

La preocupación de este alumno era distinta. No le preocupaba el valor. No le preocupaba lo que se entregaba. Le preocupaba que su cliente viera a la gente -gente por la que paga- ocupada todo el día. Y claro, enfocándose en generar valor, es difícil que eso pase. Veamos por qué.

Eficiencia vs Valor

Hoy en día, las compañías deciden enfocarse en la eficiencia, y encuentran que los frameworks como Scrum o los métodos de Management como Kanban requieren de un salto de fe desde la eficiencia, entendida como todo el mundo debería de estar trabajando a toda velocidad, hacia el enfoque de valor.

Sin embargo, ¿qué es valor? Hace unas semanas, estuve con todos los Product Owners de una conocida startup en Barcelona. Juntos, llegamos a la conclusión de que su trabajo los había convertido en meros gestores de horas. Su misión era que los desarrolladores estén ocupados. Si la gente no trabaja ocho horas, entonces no son eficientes. Error.

Valor, en el negocio del desarrollo de Software, es llegar antes que los demás al mercado. Validar y seguir. Fallar y rectificar. Eso es la agilidad. Mientras no hacemos una release de Software al cliente, el valor que generamos es cero.

Cuando nos enfocamos en que todo el mundo esté ocupado, entonces tendemos a crear colas. Como en el desarrollo de Software por naturaleza las distintas tareas que podemos hacer tienen una alta variabilidad, entonces las colas tienden a crecer hasta el infinito. Que todo el mundo esté ocupado significa, inequívocamente, que nuestro ritmo de entrega tenderá a cero.

Conseguir una release supone ineficiencia. Sólo podríamos alcanzar un estado de alta ocupación y alta entrega si todas las tareas tuvieran exactamente la misma carga de trabajo. Lamentablemente, en el Software, debido a su naturaleza de crear siempre cosas nuevas, las cargas varían mucho.

La ley de los retornos disminuidos

Un 95% de las empresas trabajan totalmente ciegas a sus economías internas. Ni las entienden, ni saben que existen. Ni pueden ni saben cuantificar cuál es el coste de decidir hacer una nueva feature en lugar de invertir en mejorar la calidad técnica del producto.

Algunos desarrolladores de producto comprenden “algunas variables”, y por ejemplo te dirán que lo más importante es reducir el tiempo de desarrollo -cycle time-, pero no tienen ni idea de cuánto va a afectar al total del ciclo de vida del desarrollo de producto o a su beneficio.

¿Qué sentido tiene reducir el tiempo de proceso si al final estoy limitado por otras variables?

Esto es algo habitual en la gran corporación. Por ejemplo, los bancos están invirtiendo cantidades ingentes de dinero en mejorar sus procesos de desarrollo usando Scrum, Kanban, SAFe o Nexus. Sin embargo, para poder lanzar una aplicación a producción, siguen necesitando a un comité de cambios que apruebe la subida a producción. Este comité se reúne una vez cada tres meses, limitando toda la mejora obtenida mediante Scrum a cero. ¿Qué sentido tiene desarrollar de manera ágil si al final vamos a llegar al mercado al mismo tiempo que lo hacíamos antes?

Por otro lado, la única manera de comprender la importancia económica de las colas que creamos cuando nos enfocamos en que todo el mundo esté ocupado -eficiencia-, es cuantificar el coste de retraso -cost of delay- en los proyectos de desarrollo de producto. A pesar de eso, sólamente el 15% de los desarrolladores de producto conocen el cost of delay asociado con sus proyectos y productos.

Cost of Delay

El cost of delay tiene una fórmula simple: ¿Cuánto me cuesta si no entrego a tiempo? A tiempo no es la línea temporal que me he marcado en mi plan de proyecto, sino el momento en el que el mercado me lo demanda. ¿O acaso lanzarías una campaña de Navidad en Febrero?

Un detalle: Cuando me refiero a desarrolladores de producto, no me refiero a ingenieros de software, ni programadores. Me refiero a todos aquellos implicados en el desarrollo de producto, desde el Product Manager hacia abajo, todos deben ser conscientes de estos elementos.

Prosigamos.

Así, estos tipos de Producto, se enfocan en variables proxy como la utilización (¿Trabajamos al 80% o al 90%?; ¿Está todo el mundo ocupado?) o la reducción del cycle time (Tenemos que tardar menos en desarrollar esta nueva feature) que en llegar antes el mercado con un MVP. Pero que todo el mundo siga muy ocupado.

Este vídeo lo explica muy bien:

Al final, esto se llama trabajo por lotes. ¿Te suena? Sí, esta es la base de PMBOK o Prince2. Trabaja por lotes que así serás más eficiente. Sin tener en cuenta que los lotes retrasan exponencialmente la salida al mercado y nos suponen una pérdida económica.

Métricas circunstanciales vs Métricas directas

El peligro de enfocarse en estas variables circunstanciales es que éstas interactúan unas con otras.

Mejorar la utilización de la capacidad de trabajo disponible tiene el efecto beneficioso de mejorar la eficiencia y el efecto negativo de incrementar el cycle time.

Para entender el impacto neto, hay que comprobar ambos efectos. Para hacerlo, hay que expresar los cambios de todas las variables proxy en la misma unidad. Esta unidad es life-cycle profit impact, que es la última medida de éxito en el desarrollo de productos. Si quieres leer más sobre esto, puedes hacerlo en el libro Lean Product Development Flow de Don Reinertsen.

Eficacia, eficiencia y efectividad

Tal y cómo se vende hoy, la productividad parece el remedio a todos los males, incluida la crisis, y puede ser el factor que impulse a muchos paises, como España, con una competitividad bajísima, a salir de la recesión y superar la crisis. ¿Cómo puedes descubrir tu potencial en productividad?

En primer lugar, hay que tener en cuenta que somos productivos per se. La medición de la productividad no podría tener lugar si no fuera por comparación. ¿Cual es el factor determinante en la comparación de la productividad?

Un ama de casa es productiva si se encarga de realizar todas sus tareas diarias y mantener su casa. De la misma manera, un ejecutivo es productivo si se encarga de hacer todas sus funciones y mantener al día todas las competencias de la que es responsable. Es realmente difícil medir en términos de horas, coste o éxito el grado productivo de dos personas y profesiones tan distintas.

Aún así, si queremos homogeneizar los hipotéticos resultados de un estudio que midiera perfiles tan variables, tendríamos que utilizar otros medidores normalizados, es decir, que de un mismo vistazo, supiéramos que la información que tenemos es fiable y se puede aplicar igual a todos los perfiles objeto del estudio.

Éstos tres medidores son:

La eficacia mide el grado de consecución de un objetivo. Si tengo que criar 10 pollos de granja y al final de un tiempo determinado, todos los pollos están sanos y listos para el consumo, entonces podríamos decir que he alcanzado una eficacia del 100%.
La eficiencia mide el grado de consecución de un objetivo con respecto al coste de recursos del mismo. Es decir, si además de criar los 10 pollos, hemos gastado la cantidad óptima de alimento y otras materias primas necesarias para hacerlo, podemos asegurar que la consecución del objetivo además, ha sido eficiente.
Por último, la efectividad incluye un factor positivo o negativo con el entorno, el de la ecología. Es decir, además de criar 10 pollos y alimentarlos de forma eficiente, lo hemos hecho con alimento biológico y no hemos hecho daño al entorno. Podríamos decir que el “karma” influye en la medición.

En ocasiones, la productividad no tiene en cuenta todas estas variables, y como muestra un botón(**).

Javier tiene una plaza como funcionario en la administración pública andaluza, donde tiene asignado un puesto con competencias de técnico. Javier, en su afán de mejora diaria y de hacer su trabajo mejor, decidió iniciarse en la productividad: Lo primero que hizo fue ordenar y mantener su mesa llena de papeles, así como su bandeja de correo electrónico a cero durante todo el día. En este punto Javier se encontraba O.K.

Javier siguió leyendo y leyendo sobre productividad, y decidió comenzar a realizar otros cambios productivos en su vida, como levantarse muy pronto y enfocarse en un orden absoluto que incluso podría calificarse de manía. Pronto empezó a decir a sus compañeros como debían comportarse, así como a su mujer e hijos, e impuso un estricto orden de productividad en casa que favoreció que todos hicieran muchas más cosas en menos tiempo. En este punto Javier se encontraba O.K., su fuerza y energía vital disminuyó un poco y su entorno, aunque receloso, se encontraba O.K.

Decidió hacer todavía más cambios en su vida, y comenzó a enfocar su energía en otros aspectos, sobre todo los relacionados con su entorno: Adoctrinaba sobre la productividad, reñía a sus niños si introducían algún cambio en la agenda de tareas programada, y cuando consiguió un ascenso gracias a su excelente productividad, se convirtió en los que muchos denominaron el pequeño dictador. Javier tenía que imponer sus normas. En éste momento Javier ya no se encontraba tan O.K., su entropía energética con el exterior había aumentado mucho y su entorno había comenzado a rechazarlo.

Quizás la primera conclusión a la que podemos llegar, es que Javier se excedió en lo que a sus labores le correspondía y no supo calibrar donde se encontraba situado en el mundo, aunque si rascamos un poco más, veremos como muchas veces nuestro propio afán por hacer las cosas mejor, influye negativamente en nuestro entorno.

Cuando somos dueños de la verdad, y las personas empiezan a sentir que estamos por encima del bien y del mal, entonces debemos plantearnos no sólo si somos eficaces o eficientes, sino también si estamos siendo efectivos.

* Nota sobre la efectividad: Ésta definición es una interpretación de la efectividad, que yo considero y asumo como la correcta. Aunque recomiendo ir a Google o a la Wikipedia y sacar conclusiones propias

** Nota sobre Javier: El caso expuesto es un caso real, que tengo autorización a reproducir por el sujeto protagonista de la historia