IEBSchool - La Escuela de los Negocios y los Emprendedores

Contenido destacado del mes

Quiero ser Ágil: ¿mejor Scrum o Kanban? [Parte 1]

En los tiempos que corren todas empresas que quieran llegar al éxito (o mantenerlo) necesitan actualizar su metodología de trabajo con el fin de aumentar su productividad y así su competitividad en el mercado. Independientemente del sector de pertenencia no … [ leer más ]

Lo más leído

Tags

Quiero ser Ágil: ¿mejor Scrum o Kanban? [Parte 1]

5 enero, 2015, en Agile, Kanban, Project Management, Scrum por Simone Brighina
Tags: , , , , , , , , , ,

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 2,00 out of 5)
Loading...

Diapositiva1En los tiempos que corren todas empresas que quieran llegar al éxito (o mantenerlo) necesitan actualizar su metodología de trabajo con el fin de aumentar su productividad y así su competitividad en el mercado.

Independientemente del sector de pertenencia no hay mejor elección que la introducción de las metodologías Agiles y su implementación gracias al utilizo del proceso de Mejora Continua.

He aquí la primera duda: ¿mejor Scrum o Kanban?

Hay similitudes y diferencias, pero no hay una respuesta univoca a esta pregunta, habrá que sopesar ventajas y desventajas en relación a la estructura de nuestra empresa y al sector de pertenencia.

1 – ROLES y REUNIONES

1.1 – Scrum

Para implantar Scrum hay que crear dos figuras esenciales (Product Owner y Scrum Master) y unas reuniones obligatorias.

 

  • el Product Owner (PO) es el nexo entre cliente y equipo de desarrollo.Es el único punto de contacto del cliente con la empresa, recopila sus necesidades y las convierte en “Historias de Usuario” para que el equipo de desarrollo pueda trabajarlas.



  • el Scrum Master (SM) es el facilitador del equipo. Se encarga de remover todos los obstáculos que puedan ralentizar el trabajo del equipo o desviarlo de su foco esencial. También es el responsable de velar sobre la utilización de los artefactos necesarios e imprescindibles para la correcta aplicación de la metodología



  • Reuniones necesarias:

– Sprint Planning: planificación del ciclo de Sprint, incluyendo rellenado del tablero y asignación tareas. Al empezar de cada ciclo de Sprint.

– Daily Scrum o Stand-up Meeting: análisis diaria sobre el estado del proyecto. Análisis visual del tablero y su actualización. 15 minutos cada mañana.

– Scrum de Scrum: análisis de los obstáculos y los próximos pasos. Se utiliza solo en caso de equipos muy grandes. Se divide el equipo y se eligen representantes por cada sub-equipo. Participan solamente los representantes.

Sprint Demo o Review Meeting: cierre de Sprint. Presentación resultados (MVP) al cliente, recopilación feedback cliente, re-definición necesidades cliente, re-direccionamiento del desarrollo para el siguiente Sprint

Sprint Retrospective: análisis del Sprint cerrado y oportunidades de mejora a aplicar en el siguiente Sprint

1.2 – Kanban

Utiliza principios y artefactos propios pero, diferentemente de Scrum, no indica cuales roles o reuniones hay que aplicar para llevar a cabo la gestión. Esto implica un menor impacto debido al cambio introducido, mayor flexibilidad y un menor coste de implantación.

Por otro lado al introducir Kanban en una empresa, nos encontraremos con una estructura organizativa preexistente con la cual debemos convivir, por lo menos en un primer momento.

Los mismos roles y la misma estructura organizativa podrían ser un elemento que genere cuellos de botella (elementos que ralentizan el flujo) y, en este caso, deberían ser objeto de revisión gracias a las Reuniones de Retrospectivas: reuniones donde se analiza lo que ha funcionado, lo que no ha funcionado, lo que se ha hecho bien y lo que se debería hacer en futuro.

No todas las organizaciones puede que se adapten a la utilización de la metodología Kanban, habrá casos donde una estructura poco flexible y unos roles con un reparto de poderes no complementario al sistema Kanban puedan crear problemas adicionales con consecuente coste añadido. En este caso no habrá, entonces, otra solución que poner en la mesa la redefinición de estos roles y, si necesario, de toda la estructura organizativa.

Ejemplo de implantación metodología Kanban: definiciones y tablero

2 – FLUJO vs SPRINT

2.1 – Scrum

Utilizando ciclos de trabajo denominados Sprint, tiene como fin último la creación de un MVP (Producto Mínimo Viable). Cada ciclo es un proceso interactivo completo (normalmente limitado entre 2 y 4 semanas) que se cierra con una reunión (Sprint Demo) para presentar el MVP al cliente.

  • Tablero Scrum: en cada Sprint Planning el tablero se llena de las tarjetas necesarias para acabar un ciclo de Sprint. Al final del Sprint todas las tarjetas deberán (o deberían) estar en la última columna “Done” (trabajo acabado y verificado por el PO). Las otras columnas deberían quedar completamente vacías. Para volver a llenar el tablero habrá que esperar la siguiente reunión de Sprint Planning donde se decidirán las tareas a completar en el siguiente Sprint.

Diapositiva2Diapositiva3Tablero Scrum: al final de cada Sprint

 

 
                                                                                                                                                                  Durante la Sprint Demo el cliente puede tocar con mano el producto parcial (MVP) que, también si limitado en funcionalidades, es operativo y utilizable. Esto le permite aportar su valioso feedback para pivotear el desarrollo hacia lo que realmente desea.
En la mayoría de los casos el mismo cliente no sabe lo que realmente quiere, así que la utilización de Sprints es una de las mayores ventajas de Scrum: permite al cliente entender lo que es importante y lo que realmente quiere que se desarrolle mientras el producto va tomando forma.
Además en caso de desacuerdo o cambio de opinión de cliente, solamente se “tirará a la basura” el trabajo de un Sprint, con el consíguete ahorro de coste respecto a deber eliminar un producto acabado y desarrollado durante mucho tiempo.

2.2 – Kanban

El fin último de Kanban es establecer un Flujo de trabajo continuo y constante, para esto hay que ir evolucionando en el tiempo hasta identificar los cuellos de botella y trabajar para eliminarlos o mejorarlos gracias a la utilización de Buffers.

Este proceso pasa para analizar y mejorar continuamente nuestro Lead Time (tiempo necesario para acabar una tarea desde cuando se empieza a trabajar en ella), con el fin de obtener un proceso eficiente y un flujo basado en Lead Times mejorados y estables. El lead Time seguirá siendo mejorable, pero nunca tiene que empeorar: lo que importa es mantener la mejora de manera continua y seguir hasta alcanzar los limites de cada proceso.

  • Tablero Kanban: el concepto de Flujo se hace visible en la utilización del tablero Kanban: las tarjetas se mueven por el tablero, de izquierda a derecha, siguiendo el flujo y el ritmo natural de trabajo. El tablero nunca se vacía, sino entrarán nuevas tarjetas en cuanto las tareas se darán por terminadas y las respectivas tarjetas salgan del tablero.

Diapositiva5

El articulo sigue en “Quiero ser Ágil: ¿mejor Scrum o Kanban? [Parte 2]”

 

 

Fuentes: toda la información necesaria para la redacción de este articulo ha sido extraída desde el material de estudio del "Postgrado en Gestión Ágil de Proyectos con Scrum, Kanban, Lean y XP"  de Iebs. 

5 comentarios para Quiero ser Ágil: ¿mejor Scrum o Kanban? [Parte 1]
  • Creo que son complementarias, y en especial debe casi usarse como obligatorio Kanban cuando se está desarrollando con SCRUM, porque todo lo que se genera y pone operativo, requiere o puede requerir mantenimiento, que por lógica es más performante que lo haga el mismo equipo.
    Por eso Scrumban es casi la forma perfecta de incorporar metodologías ágiles, con esa bolsa de horas disponibles que menciona Simone para las urgencias.
    En cuanto a la selección de una de ellas, se me hace difícil porque están orientadas a cosas que creo son diferentes, una es para proyectos con una colección de entregables conocidos que conforman un todo y por lo tanto se puede y es útil programar una iteración, y la otra es para una lista cambiante de urgencias o problemas a resolver. Ambas útiles pero para distintas cosas, y esto se ve especialmente a la hora de reportar los avances o considerar la salud de un proyecto.
    Gracias por compartir!

  • Es un interesante resumen. Está muy bien sintetizado, y es muy recomendable para los que estamos empezando con temas de gestión de proyectos.
    Gracias.

    Por otra parte, ¿que opinas sobre un uso combinado de ambos dentro del ciclo de vida de un proyecto?¿Puede el cambio confundir o empeorar el rendimiento del equipo de trabajo?
    Por ejemplo: En proyectos de larga duración, usar Scrum en una primera fase de definición y desarrollo (sobre todo al usar nuevas tecnologías o elementos desconocidos para el equipo) y una vez alcanzado una cierta madurez, pasar a utilizar algo como Kanban.

    • Hola Jon,
      gracias por tu comentario.

      En un primer acercamiento Scrum y Kanban pueden parecer metodologías distintas y puede que se te plantee la duda de elegir una u otra o de cambiar durante la marcha, pero hay una solución mejor y más eficiente, que elimina las consecuencias del cambio que te preocupan.

      Tal como comenta Daniel, una vez asimilados los punto fuertes y las limitaciones de cada una, te sentirás casi obligado a pasar al siguiente nivel, o sea juntar lo mejor de ambas en lo que se conoce como Scrumban.

      Agradeciendo a Daniel por su aportación, con la que estoy de acuerdo, te reporto la respuesta a un comentario/pregunta que me hicieron en Linkedin donde a grandes rasgos introduzco Srumban, esperando así poderte dar más informaciones para que te puedas hacer tu propia idea sobre el tema.

      “En efecto Scrumban es una metodología que escoge lo mejor de Scrum y Kanban.

      Scrum maximiza la utilización de la capacidad productiva dentro del Sprint: aumenta la eficiencia pero en casos de tener tareas urgentes (que surjan dentro del Sprint ya empezado) no habrá espacio para insertarlas en el tablero hasta que el Sprint no se haya acabado. Habrá que esperar que se abra una nueva reunión de Sprint Planning para rellenar el Sprint Backlog de un nuevo tablero virgen.

      En cambio con Scrumban puedes añadir un tablero Kanban en la parte baja del tablero Scrum y dedicarlo para estas tareas urgentes, ya que Kanban no necesita de Sprint Plannig y permite añadir tarjetas en cada momento.

      El truco está en no utilizar toda la capacidad productiva en la parte Scrum: si hay capacidad 10 deberás cargar Scrum solo hasta 8 y dejar 2 para Kanban, de modo de reservar siempre espacio para estas tareas urgentes.

      Ejemplo: en una empresa de desarrollo de software llevarás el desarrollo con Scrum, pero dejarás espacio dedicado a Kanban para que los técnicos puedan participar en el proceso de preparación de presupuestos. Dichos presupuestos no se pueden predecir con antelación adecuada para un Sprint además de tener una tasa de urgencia elevada y la necesidad de un equipo técnico que estime el coste.”

      Si te interesa profundizar el tema puedes también acceder al debate completo en Linkedin (deberás acceder y unirte al grupo): https://www.linkedin.com/groupItem?view=&item=5960756511708844036&type=member&gid=855957&trk=eml-group_discussion_new_comment-discussion-title-link&midToken=AQEYWwssRkMn3Q&fromEmail=fromEmail&ut=1kOjetDAPMK6A1

      Así que, volviendo a tu pregunta, opino que no sea necesario el cambio de una metodología a otra, sino hay que entender las características del trabajo que quieras gestionar con metodologías Ágiles con el fin de elegir la más apropiada.

      – Si en tu empresa (o mejor dicho en el equipo dedicado al proyecto) no hay posibilidad que surjan urgencias durante el Sprint, además puedes permitirte la reorganización de estructura y roles, será mejor elegir Scrum por su eficiencia y su MVP
      – Si hay que gestionar una carga de trabajo que incluya tareas urgentes imprevisibles será mejor Kanban y utilizar herramientas como las Clases de Servicio en las tarjetas para mejorar el flujo
      – Si tu empresa necesita un trabajo optimizado al máximo a nivel de eficiencia, la posibilidad de un MVP cada “X” tiempo o Sprint, pero además poder gestionar tareas urgentes imprevisibles entonces Scrumban es la solución a tus problemas

  • Buenos días a todos,
    He leido el artículo y mi conclusión es así: el Scrum y el Kanban son la misma herrmienta y la única diferencia entre ellos es su posición en el proceso de producción. Yo uso, como el lider, el tablero Kanban, una herramienta del método Kanban y creo que es posible convertirla en una herramienta de SCRUM. ¿Qué opináis?

    • Buenos días Renato y gracias por tu aportación.

      Estoy perfectamente de acuerdo contigo: la herramienta es la misma, lo que cambia es la manera de utilizarla.

      Hay que saber elegir si aplicar Kanban o Scrum en base a la necesidad primaria del proyecto al cual se aplicará la metodología: trabajar con Sprint cerrados o tener la ventaja de insertar tarjetas urgentes trabajando en un flujo continuo.

      La herramienta en si es un simple tablero, hasta una pizarra física en blanco, dibujada a mano con marcadores y unos Post-it son suficientes.

      Lo importante es elegir las columnas de manera adecuada al tipo de proyecto y sector donde se aplica la metodología. Podría haber alguna limitación (pocos software lo permiten) en el caso de aplicar Scrumban, donde se juntan dos tableros en uno y hay necesidad de dividir el tablero de manera horizontal (arriba Scrum y abajo Kanban).

      Muchas gracias por compartir tu herramienta, conozco http://kanbantool.com pero todavía no lo he utilizado. Yo normalmente utilizo https://trello.com o http://leankit.com/

Deja un comentario

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

comentarios para esta entrada