Cómo Crear Agilidad en Proyectos (con Dimitar Karaivanov de Kanbanize)

Lee la transcripción:

Estamos probando la transcripción de nuestros pódcast usando un software. Por favor, disculpa cualquier error, ya que el bot no es correcto el 100% del tiempo.

Ben Aston:

Lean, Scrum, Scrumban, XP, SAFe, DaD, LeSS, DSDM, Kaizen, Kanban. ¿Te suenan? Bueno, estos son solo algunos de los marcos existentes para entregar agile. ¿Pero cuál es el mejor y por qué? Sigue escuchando este pódcast para entender cómo puedes crear agilidad en tus proyectos y los beneficios de un enfoque y kit de herramientas Kanban.

Gracias por escucharnos. Soy Ben Aston, fundador de The Digital Project Manager. Bienvenido al pódcast de DPM. Nuestra misión es ayudar a los gestores de proyectos a tener éxito, ayudar a las personas que gestionan proyectos a lograr mejores resultados. Estamos aquí para ayudarte a mejorar tu nivel de gestión de proyectos. Visita thedigitalprojectmanager.com para conocer nuestros cursos y recursos exclusivos para miembros. Este pódcast está patrocinado por Clarizen, el líder en software de gestión de proyectos y portafolios empresariales. Visita clarizen.com para saber más.

Hoy estoy acompañado por Dimitar Karaivanov. Dimitar es un ingeniero convertido en CEO y es el cofundador de Kanbanize. Es un pensador lean, practicante de Kanban y tiene experiencia en desarrollo de software y mejora de procesos. Ha escrito algunos libros, Lean Software Development With Kanban y ¿Cómo puede el Portfolio Kanban beneficiar a tu negocio? Te haces una idea: es apasionado por Kanban. Así que, hola Dimitar, gracias por acompañarnos hoy.

Dimitar Karaivanov:

Ben, gracias por invitarme. Es un placer hablar contigo y con tu audiencia. Así que estoy expectante por este pódcast.

Ben Aston:

Sí, es grandioso tenerte. Y obviamente eres muy apasionado por Kanban y has creado un producto entero alrededor de Kanbanize. Pero en tu rol como CEO, me da curiosidad, ¿qué significa en realidad ese puesto? ¿Cómo es un día típico para ti como CEO y cofundador de Kanbanize?

Dimitar Karaivanov:

Sí, como CEO de la empresa, especialmente siendo una empresa en la etapa final de startup, tienes que ponerte muchos sombreros diferentes. Normalmente hablo con muchos clientes, ya que a menudo ocupo el papel de gestión del producto.

Ben Aston:

Claro.

Dimitar Karaivanov:

Después hablo con ingeniería para trasladar los comentarios recogidos de los clientes. Cómo implicarse en ventas empresariales. Y, por supuesto, recurro a la estrategia cuando el tiempo lo permite porque es un aspecto importante de lo que hacemos los CEOs. Por cierto, la estrategia también puede aplicarse con Kanban. Así que quizás debamos encontrar unos minutos para hablar de eso.

Ben Aston:

Sí, definitivamente. Pero antes de meternos en eso, tengo curiosidad por saber más acerca de tu historia de origen. ¿Cómo empezaste a crear software de gestión de proyectos?

Dimitar Karaivanov:

Eso normalmente surge de una necesidad. Yo era el agente de cambio en una gran empresa alemana. Estábamos pasando de procesos en cascada (waterfall) a procesos ágiles, y migramos como a 500 personas de esa vieja forma de hacer proyectos a scrum. Scrum era lo normal para cualquier nueva implementación ágil. Entrenamos a todos en scrum. Teníamos muchos equipos ágiles, como 25 o más, pero descubrimos que, aunque los equipos eran capaces de entregar de manera estable, era un completo lío a nivel de gestión, donde estaban los “trozos” grandes de trabajo, en nuestro caso, funcionalidades, épicas, ese tipo de cosas. Me di cuenta de que nos faltaban herramientas para gestionar tanto a nivel de equipo como de coordinación/gestión. Así nació Kanbanize, con el objetivo de escalar agile en toda la organización.

Ben Aston:

Genial. Y claro, al iniciar una herramienta de gestión de proyectos desde cero y construirla, seguro que te inspiraste en otras herramientas que te gustaban, y también en herramientas que no te gustaban y por eso pensaste que necesitabas crear la tuya. ¿De dónde vino esa chispa original de inspiración?

Dimitar Karaivanov:

Usábamos JIRA en aquella empresa. Es el “Godzilla” de 300 kilos allá donde vayas. Tiene muchas cosas buenas, pero esa pieza, especialmente hace ocho o nueve años, si no faltaba por completo, al menos era muy limitada. Así que, aunque hay buenos conceptos, la inspiración real sobre cómo escalar Kanban y agile en una organización vino más de un tablero Kanban físico. Así que lo que hicimos con Kanbanize fue tratar de imitar cómo visualizarías el trabajo en un tablero físico de Kanban, con el gran añadido de que es digital y puedes conectarlo con varios equipos y agregar datos para la gestión y la toma de decisiones informadas. Así que en realidad son dos herramientas. JIRA y tableros Kanban físicos.

Ben Aston:

Claro. Y, obviamente, tú haces tu propia herramienta de gestión de proyectos, pero me interesa saber qué otras herramientas integran con Kanbanize o que también usáis en paralelo para gestionar tu empresa. ¿Hay alguna herramienta que hayas descubierto y te haya resultado muy útil o interesante últimamente?

Dimitar Karaivanov:

Sí, no dejaría de mencionar Microsoft Teams, porque creo que es la aplicación de crecimiento más rápido en la historia de Internet. En nuestra empresa usamos mucho Teams, especialmente ahora que todos trabajamos en remoto. También paso probablemente la mitad de mi día en una herramienta llamada Flow-e. Está en flow-e.com y es sorprendentemente una herramienta de nuestra empresa. Es Kanbanize para tu correo. Es una capa de visualización sobre tu correo Outlook que convierte tu bandeja de entrada en un tablero Kanban donde puedes visualizar los emails y gestionar las conversaciones con una vista tipo Kanban. Es mi salvavidas; literalmente no podría vivir sin este herramienta, así que la recomiendo. Es gratis, así que cualquiera puede probarlo.

Ben Aston:

La probaré. Estoy viendo mi bandeja de entrada ahora mismo. Correos sin leer: 1189. Así que si no he respondido todavía, ya sabes. Eso irá en mi columna “por leer”.

Dimitar Karaivanov:

Exacto. Así nació Flow-e. Porque era demasiado doloroso mantener todos los flujos de información. La recomiendo.

Ben Aston:

La revisaré. Genial. Hablemos de Kanbanize. Eres el CEO de Kanbanize y este fue tu proyecto junto al equipo inicial. Ya nos has dado una idea de la empresa: es un tablero digital Kanban que, al ser digital, nos permite mayor previsibilidad, ofrece analíticas, datos y reglas que podemos usar. Pero, ¿a quién dirías que va dirigido? ¿Quién es vuestro mercado ideal? ¿Quiénes son los que más usan vuestra herramienta?

Dimitar Karaivanov:

Está especialmente diseñado para empresas de ingeniería, que puede ser ingeniería de software, I.T./devops y también para ingenierías fuera del I.T. como manufactura o construcción. Tenemos clientes exitosos en el sector de ingeniería, pero también lo usan equipos de marketing u operaciones, como banca o seguros. Generalmente hay dos tipos de casos: la gestión de proyectos (como mencioné, ingeniería) y la gestión de servicios (banca y seguros). Esos son los clientes ideales. Hablando de gestión de proyectos, puedo elaborar más si quieres sobre las particularidades de Kanbanize.

Ben Aston:

Por supuesto, adelante.

Dimitar Karaivanov:

Desde mi experiencia, vemos que quienes gestionan proyectos suelen planificar y estimar proyectos, y ese plan se convierte en tareas o elementos de trabajo que normalmente viven en otro sistema. Así que tenemos un plan perfecto en PowerPoint o Microsoft Project y luego el trabajo real está en JIRA o en otro lugar.

Ben Aston:

Correcto.

Dimitar Karaivanov:

Entonces, ¿cómo obtienes el estado real? Pues no hay más opción que preguntar por el estado.

Ben Aston:

Sí.

Dimitar Karaivanov:

Y tienes que molestar a la gente preguntando: ¿hasta dónde hemos llegado aquí?, ¿qué porcentaje llevamos de esta tarea? Por eso dijimos, bien, podemos resolver esto con Kanban y, específicamente, con Kanbanize, conectando la planificación con la ejecución. Hay una capa especial en Kanbanize para planificar el trabajo y otra para ejecutar el trabajo, y ambas están conectadas y se retroalimentan. Cuando el equipo comienza a trabajar en algo, la información se propaga automáticamente a la capa de gestión donde está el plan. Si vemos que el plan va a fallar, notificamos automáticamente al gestor de proyectos para que actúe antes de que sea tarde. Así que es bastante útil.

Ben Aston:

Recibes una notificación: tu proyecto va a fallar. ¡Una advertencia educada! Ese debe de ser el correo que todos temen. ¡Desastre! Vas retrasado. Pero está genial. El secreto está en el equipo y las personas. El reto con cualquier herramienta es que solo es tan buena como quienes la actualizan. Es decir, el gestor de proyectos tiene que preguntarles a todos: ¿en qué tarea estás y cuánto llevas? Así puede actualizar los diagramas de Gantt y saber el estado real. Pero para eso la gente debe actualizar las tarjetas, el estado y el seguimiento de tiempo. En mi experiencia, con herramientas como JIRA la gente suele olvidar actualizar el estado de las tareas. ¿Cómo han diseñado el sistema de Kanbanize para tener una visión en tiempo real y fomentar que el equipo mantenga actualizados los estados?

Dimitar Karaivanov:

Tienes razón, es un problema. Y la manera de resolverlo es confiando en el método Kanban. No es solo una pizarra blanca en la pared, es un cuerpo de conocimiento grande. Hay algo llamado Kanban Maturity Model que codifica más de 150 prácticas comunes. Si te interesa, consulta el KMM (Kanban Maturity Model) para entender qué implica una implementación madura de Kanban. Dicho esto, hay algo en el método Kanban llamado bucles de retroalimentación (feedback loops). Son reuniones regulares diarias, semanales, mensuales o trimestrales. Una de esas reuniones es la reunión diaria Kanban, donde el equipo se pone frente al tablero.

Si es digital, puedes poner el tablero en una gran pantalla y repasar cada tarjeta en progreso. No hablamos de personas ni de lo que hicieron, sino del trabajo. ¿Qué ha pasado con esta tarjeta? ¿Se ha actualizado? ¿Hay que moverla? Así nos aseguramos de que, al menos una vez al día, las tarjetas estén en la posición correcta. Es lo que puedo decirte.

Ben Aston:

Eso está bien. Y es interesante centrarse en el trabajo y no en la persona. A mucha gente le han preguntado en los ‘standup’ con herramientas como Standuply para Slack: ¿qué hiciste ayer? ¿Qué harás hoy? ¿Tienes algún bloqueo? Es útil para tener un ‘standup’ asíncrono. Pero muchas veces la gente simplemente responde: sigo con lo de ayer, construyendo el “widget”, sin bloqueos, y no ayuda de verdad. Así que enfocarse en el trabajo y los progresos reales, no en la persona, es un buen consejo. Ahora, tú mencionaste JIRA, que compró Trello, que también es Kanban. ¿Cómo percibes Kanbanize en comparación con otras herramientas?

Dimitar Karaivanov:

Remitiría de nuevo al KMM. El modelo de madurez Kanban tiene seis niveles de madurez, cada uno con prácticas diferentes. Herramientas como Trello solo te llevan a los niveles 1 o 2, porque carecen de funciones necesarias para una implementación completa de Kanban. Por ejemplo, Trello no tiene limitaciones de trabajos en curso (WiP) completas; solo con algunos complementos. Con una herramienta como Kanbanize puedes limitar el trabajo en curso en varias columnas, carriles, tableros, personas, etc. Realmente el énfasis está en las características propias de Kanban.

En cuanto a métricas, tampoco tienes, de serie, los flujos métricos necesarios como curvas de tiempo de ciclo, bloqueos, simulaciones Monte Carlo para previsión en base al historial, etc. Puedes obtener algunas con complementos, normalmente de pago, y rara vez funcionan bien. En resumen: Kanbanize está realmente diseñado para cubrir escenarios kanban sofisticados, incluyendo escalado en la organización y toma de decisiones informadas por la dirección. Trello es una buena herramienta de equipo, pero si vas más allá, ya no es suficiente. Con JIRA es posible, pero depende más de scrum y no tanto del mecanismo de datos subyacente de Kanban. En JIRA prevés en base a la velocidad del equipo, mientras que en Kanban prevés por throughput histórico de verdad. Es una diferencia sutil pero crítica a gran escala, porque cada equipo interpreta la velocidad de modo diferente y eso requiere normalización. En Kanban se prevé según hechos reales y ese matiz es fundamental, en mi opinión.

Ben Aston:

Tomando una visión general, lo que Dimitar dice es que uno de los principios de Kanban es aumentar el throughput minimizando la cantidad de cosas en las que se trabaja al mismo tiempo. Por eso limitar el trabajo en curso significa lograr que la gente sea más enfocada, complete una cosa y la saque antes de empezar otra.

Cuando se dividen en muchas cosas (varios proyectos o clientes simultáneamente), los plazos entran en conflicto. La idea de Kanban es reducir las cosas en las que se trabaja para aumentar el throughput y la eficiencia, haciéndolo limitando el WiP. Así simplemente centrarse en menos cosas hará que terminemos más cosas.

Dimitar Karaivanov:

Exacto. Solo que hay una advertencia: si limitas el WiP demasiado, puedes perjudicar el throughput. Hay que encontrar el equilibrio justo entre rapidez y el mejor throughput posible. No hay un límite de WiP universal: cada organización debe experimentar y ver, según sus datos, cuál es el nivel óptimo para su contexto. Se revisa cada semana si el throughput es satisfactorio y así encuentras tu límite ideal.

Ben Aston:

Interesante. ¿Hacia dónde va Kanbanize? ¿Qué tenéis en el roadmap, tanto a medio como a corto plazo?

Dimitar Karaivanov:

Cinco o diez años es mucho, pero a seis semanas puedo decirte que vamos hacia descargar cada vez más al gestor de proyectos en cuanto a decisiones. En vez de que una persona calcule estimaciones y juegue con escenarios hipotéticos, queremos responder esas preguntas de forma automática. El PM se podrá centrar en el valor generado, no en si se generará. Queremos automatizar todo el seguimiento y las notificaciones introduciendo algoritmos estadísticos específicos, incluso inteligencia artificial si es posible (con cautela, ya que muchas IA aún no mejoran a los algoritmos estadísticos en este campo). Así descargamos trabajo rutinario al software y dejamos el valor añadido para las personas.

Ben Aston:

Eso implica un cambio para el gestor de proyectos, que dejará de lado la administración y hará foco en la generación de valor. ¿Ves ese rol evolucionando hacia algo más parecido al product management?

Dimitar Karaivanov:

Sí, creo que el project manager debería ser la interfaz no solo para comunicar datos, requerimientos, plazos, sino para enriquecer esos datos, ponerlos en duda, cuestionar si se está construyendo lo correcto. Debería ser quien empuja el sistema para que evolucione, quien hace las preguntas difíciles. Ahora muchos se limitan a coger requisitos y pasarlos al equipo. Eso es útil, pero solo parcialmente. Lo ideal sería que con menos tareas administrativas y más automatización, el gestor se centre en producir el mejor resultado real para el cliente.

Ben Aston:

Eso suena bien. Hemos hablado de la evolución del rol y de la importancia de datos e IA en las herramientas. ¿Cómo ves el panorama de las herramientas de gestión de proyectos y vuestra adaptación a él? JIRA, Trello, consolidación, nuevas startups, soluciones “todo en uno” como ClickUp… ¿Cómo os adaptáis?

Dimitar Karaivanov:

Sí, hay muchísimas herramientas, sobre todo para equipos pequeños. Competir ahí es muy complicado. En Kanbanize nuestro producto no solo es una solución de gestión de equipos, estamos avanzando hacia la gestión ágil de portafolios. La funcionalidad está en parte implementada; es una tarea enorme. En ese área, la mayoría aún depende de scrum y modelos tradicionales. Creo que (aunque sea sesgado) el futuro está en lo que desarrollamos: las autopistas informacionales entre equipos y dirección. Las herramientas tienden a consolidarse para escalar la agilidad en la empresa. Las de equipos seguirán existiendo, pero quienes resuelvan el reto de escalar la agilidad triunfarán.

Ben Aston:

Has escrito un artículo, si no lo habéis leído buscad “Kanban Powered Business Agility” en thedigitalprojectmanager.com, donde das consejos para implementar Kanban. Pero primero, ¿qué significa para ti agilidad empresarial?

Dimitar Karaivanov:

Para mí, la agilidad de negocio es la capacidad de satisfacer el mercado mediante ciclos rápidos de aprendizaje, experimentación y aplicación de ese aprendizaje. No es un marco o abreviatura más, es la capacidad de experimentar rápidamente, aprender como organización y usar ese aprendizaje para dar más valor al cliente.

Ben Aston:

Eres un gran defensor de Kanbanize… perdón, de Kanban. Y hace un momento comparabas Kanban con Scrum. ¿Por qué has apostado tan fuerte por Kanban y por qué crees que es ideal para la agilidad empresarial? ¿Para qué es bueno y para qué no?

Dimitar Karaivanov:

Buena pregunta. La respuesta está en uno de los principios de Kanban: empieza donde estás y evoluciona experimentalmente. Eso no lo dice ningún otro modelo. Normalmente hay que dar un cambio enorme, reestructurar equipos, certificaciones, formación… Kanban simplemente plantea visualizar el sistema actual y preguntar ¿cómo lo mejoramos? Es un enfoque humano: menos estrés al principio, un proceso evolutivo. Si se hace bien, reduce el sobrecargar a la gente y hace que disfruten más su trabajo, centrándose en pocas cosas y haciéndolas bien, sin apagar fuegos ni cambiar de tarea constantemente. El principal problema de Kanban es pensar que es solo una pizarra en la pared, pero hay un gran cuerpo de conocimiento detrás. Recomiendo investigar más a fondo.

Ben Aston:

Eso también ayuda porque a diferencia de Scrum, Kanban es fácil de explicar e implementar como punto de entrada a agile sin modificar por completo todo el marco ni adoptar nuevas ceremonias. Es una entrada más suave para mejorar la eficiencia.

Dimitar Karaivanov:

Creo que es el método más razonable. Ir a una empresa y, sin conocer el contexto, decir “haz esto y serás mejor” es arrogante: esa empresa ya sabe cosas, ya tiene éxito, entonces mejoramos desde ahí, no les imponemos todo desde cero. Ese enfoque siempre será mejor, en mi opinión.

Ben Aston:

En tu artículo hablas de refinar el flujo de trabajo. ¿Cómo se hace realmente esa mejora?

Dimitar Karaivanov:

Normalmente lo hacemos usando colas (queues) y límites de trabajo en curso (WiP). Si empiezas con un tablero visual y eres constante, notarás que con el tiempo se acumulan muchas tarjetas en alguna parte. Ese suele ser un cuello de botella. Cuando pasa, debes pausar, reflexionar y preguntarte por qué ocurre. Lo normal es introducir nuevas columnas, como “Listo para revisión”, y ver si se acumulan allí también. Si es así, el cuello de botella es la revisión. Limita el WiP en esa columna; y si se llena, la columna anterior debe dejar de trabajar y ayudar a revisar. Así refinamos todos los días.

Ben Aston:

Con el objetivo de reducir cuellos de botella, porque el valor se produce cuando algo se termina, no solo cuando avanza.

Dimitar Karaivanov:

Correcto. Hay que hacerlo observando el ‘cycle time’, que es lo que tarda una tarjeta en completarse. Cuanto menor el cycle time, mejor. Si aumenta el cycle time, hay acumulación de trabajo, así que toca inspeccionar, refinar el flujo, limitar colas y observar de nuevo.

Ben Aston:

Otro de tus consejos es convertir hippos en hippos: La opinión de la persona mejor pagada a la opción de mayor probabilidad según datos. ¿Cómo aconsejas a tu equipo enfrentarse a las opiniones fuertes del jefe y respaldar sus posturas con datos?

Dimitar Karaivanov:

Es difícil. He cometido muchos errores hasta alcanzar ese “iluminamiento”. Siempre que alguien toma una decisión por corazonada, sin mostrar datos, yo empiezo a cuestionar y desafiar, hasta que esa persona se pregunta cómo llegó a esa conclusión y si podría decidir mejor. Es natural querer tener razón y si discutes con el CEO, suele ganar él… salvo que haya datos. Yo recuerdo a mi equipo siempre que no se trata de opiniones, sino de hechos. Esto lleva tiempo, insistencia y mucha repetición para que se grabe en el ADN de la empresa.

Ben Aston:

Acabando, tu artículo va sobre agilidad empresarial y cómo Kanban puede impulsarla. Para alguien que quiera iniciarse en Kanban, ¿cómo empezar a ser más ágil usando Kanban?

Dimitar Karaivanov:

Hay dos o tres cosas importantes. La primera es visualizar el trabajo. Todos podemos visualizar nuestro trabajo, aunque no seamos expertos: una pizarra física, post-its, imanes, y marcar columnas con rotulador. No hay excusa para no visualizar. Eso sí, solo si hay alguna insatisfacción o algo que quieras corregir. El primer paso es visualizar.

Segundo, limitar el WiP. Aunque sean 100 proyectos en marcha, pon el límite en 100; al menos reconoces la realidad y puedes ir bajándolo hasta mejorar. Y tercero, recomendaría recibir buena formación en Kanban. Somos socios de Kanban University, la autoridad de certificación. Recomiendo que, al menos personas clave, reciban formación formal.

Ben Aston:

Cierto. Lo que más valor veo es el primer paso: visualizar el flujo de trabajo y detectar los puntos dolorosos. Puede parecer difícil pero resulta muy útil mapear el proceso con el equipo: descubrirás que cada uno cree que el proceso actual es distinto. Es valioso visualizar, identificar cuellos de botella y así pensar en cómo limitar el trabajo en curso para aumentar el throughput. Así que gracias Dimitar, ha sido muy útil. Si quieres probar Kanbanize, entra en kanbanize.com, lo pondremos en las notas. Dimitar, muchas gracias por tu tiempo.

Dimitar Karaivanov:

Gracias, Ben. Lo he pasado genial, ha sido un placer. Sigamos en contacto.

Ben Aston:

Y si quieres aprender más y avanzar profesionalmente, únete a nuestra comunidad con una membresía de DPM. Dirígete a thedigitalprojectmanager.com/membership para acceder a plantillas, talleres, sesiones AMA, office hours, ebooks y más. Y si te ha gustado este episodio, suscríbete y mantente conectado en thedigitalprojectmanager.com. ¡Hasta la próxima! Gracias por escucharnos.