Dentro de las metodologías ‘agile’, la gestión de proyectos con herramientas visuales suprime reuniones innecesarias
y facilita la eliminación de cuellos de botella para agilizar las tareas.
Bajo las premisas de este tipo de modelos de gestión empresarial, los equipos multidisciplinares, con autonomía
para organizarse y capacidad de ejecución, se convierten en la base de las organizaciones. Esta forma de trabajar ayuda a garantizar la entrega constante de resultados y soluciones en tiempos más cortos.
En este contexto, uno de los instrumentos más populares de las organizaciones ‘agile’ son los tableros ‘kanban’, término que surge de combinar las palabras japonesas ‘kan’ (visual) y ‘ban’ (tarjeta). Apoyándonos en esa traducción, podríamos decir que un tablero ‘kanban’ es una herramienta visual para gestionar proyectos y procesos.
¿Pero cómo se usa exactamente?
Transformación digital
A grandes rasgos, estos tableros deben reflejar de manera gráfica el flujo de trabajo de un proyecto o proceso, con el fin de comprobar de un vistazo su estado, evolución, posibles atascos y los puntos que requieren atenderse de manera urgente. Tradicionalmente, esto se ha hecho en pizarras o corchos de madera colgados en las paredes de las oficinas, una solución que siguen prefiriendo muchos profesionales. A pesar de ello, ya existen aplicaciones que digitalizan estos tableros, una alternativa muy útil cuando se teletrabaja o cuando los miembros del equipo se encuentran físicamente en distintas localizaciones.
Un tablero ‘kanban’ es una herramienta visual para gestionar proyectos y procesos.
Construyendo el tablero
Un tablero ‘kanban’ debe tener al menos tres columnas donde se repartirán, escritas en tarjetas o ‘post-its’ y atendiendo a su evolución, todas las tareas que componen el proyecto. Estas tres grandes secciones son: tareas por hacer, tareas en curso y tareas finalizadas. Suele ser habitual encontrar los nombres de estas columnas en inglés, es decir:
‘To do’ (o ‘Planned’), ‘In progress’ y ‘Done’. En determinados casos resulta muy útil incluir también la columna ‘Backlog’,
la cual permite visualizar y aparcar tareas que están pendientes y que por el momento no están siendo atendidas.
Una vez configurado el tablero ‘kanban’, a medida que avanza el proyecto se obtienen ventajas como las siguientes:
Rápida identificación de los cuellos de botella y de las debilidades en el flujo de trabajo.
Priorización de las tareas en curso. Eliminación de reuniones innecesarias para actualizar información básica sobre el proyecto.
Visualizar y hacer más transparentes para el resto las actividades a las que está dedicado cada miembro del equipo.
Estimación de la capacidad de trabajo del equipo (WIP, por sus siglas en inglés ‘Work in Progress), moderando la carga de actividades que se realizan al mismo tiempo.
Pero para que este método realmente funcione, es necesario complementar la elaboración de un tablero ‘kanban’ con acciones como las siguientes:
1. Identificar correctamente cada fase y tareas
Resulta vital generar un modelo visual e intuitivo del flujo de trabajo y de cómo son ejecutadas las tareas, es decir, tener bien identificadas las columnas que queremos que se correspondan con cada fase del proyecto. Solo así se conocerá de un vistazo el trabajo en curso y los posibles bloqueos, con el fin de ayudar al equipo a tomar acciones correctivas.
2. Limitar el trabajo en curso
Para evitar que los miembros del equipo tengan muchos flancos abiertos, lo que puede derivar en acometer varias tareas simultáneamente y descuidar alguna de ellas, es necesario limitar la cantidad de trabajo pendiente en curso. Se recomienda que cada profesional se concentre en un número limitado de tareas y que no empiece ninguna nueva hasta haberlas culminado.
3. Programar las tareas a corto plazo
En relación con el punto anterior, planificar el trabajo en periodos cortos hace que la cantidad de tareas definidas
sea menor. Esto es importante porque permite centrarnos en pocos elementos y garantizar que se realicen con la calidad
exigida en el tiempo pactado.
Por otro lado, si en el tablero existen tareas que llevan ahí desde hace mucho tiempo, quizás no son prioritarias y será mejor apartarlas para acometerlas sólo cuando estemos seguros de su viabilidad.
4. Mejorar de manera continua
Un tablero ‘kanban’ siempre se puede perfeccionar, para lo cual es imprescindible escuchar a todos los miembros del equipo de trabajo e introducir cambios que contribuyan a que las tareas fluyan mejor de una columna a otra.
‘Scrum’, que se emplea cada vez con más frecuencia para desarrollar productos y servicios digitales, es un marco de trabajo donde los miembros de un equipo multidisciplinar colaboran en la construcción de un producto de manera que sea valioso desde sus primeras versiones. Es la forma en que se desarrollan, ciertas aplicaciones que posteriormente van ampliando sus funcionalidades en entregas sucesivas.
Para lograr esta entrega de valor tan rápida y continua, los equipos ‘scrum’ trabajan en ciclos de ejecución muy cortos -entre una y cuatro semanas- que se denominan ‘sprints’ y tienen un objetivo muy claro.
El primer paso para alcanzar este objetivo -o hito del proyecto- es la reunión de planificación, una sesión en la que debe participar todo el equipo ‘scrum’ y que supone el pistoletazo de salida del ‘sprint’. Esta reunión se divide en dos partes que tratan de dar respuesta a dos preguntas fundamentales: ¿Qué se va a entregar? y ¿cómo se va a realizar el trabajo?
Para resolver estas cuestiones, los distintos miembros del equipo asumen unas responsabilidades definidas por la metodología ‘scrum’ en función del rol que desempeña cada uno de ellos:
-‘Scrum Master’: Se centra en cómo va a trabajar el equipo. Es el responsable de conseguir que se sigan los valores y las prácticas de ‘scrum’. Ayuda a los miembros del equipo para que trabajen de forma autónoma y auto-organizada. Se ocupa también de eliminar problemas y obstáculos que puedan poner en riesgo el objetivo del ‘sprint’.
-‘Product owner’ (o propietario del producto): Su mirada está siempre puesta en el cliente, y en lo que el equipo va a desarrollar. Es responsable de que el producto vaya incrementando su valor con cada ‘sprint’. Además, es la persona encargada de marcar el objetivo de manera clara y acordada con el resto del equipo.
-Equipo de desarrollo: Es el grupo de profesionales que hace el trabajo necesario para poder entregar el incremento de valor en el producto. Se auto-organizan para realizar el trabajo y han de estar disponibles a tiempo completo en el proyecto.
Cuando el ‘sprint’ ha comenzado, cada uno de los miembros del equipo ejerce su rol, asegurándose de que se cumplan siempre las siguientes condiciones:
No se realizan cambios que pongan en peligro el objetivo.
Los estándares de calidad no disminuyen.
El ‘Product owner’ y el equipo de desarrollo trabajan conjuntamente ajustando el detalle de las funcionalidades planificadas para el ‘sprint’.
Además de construir el producto, todo equipo trabaja conjuntamente en la redefinición del proyecto. El ‘Product owner’ y los miembros del equipo aclaran y negocian entre ellos a medida que se aprende más.
Es importante enfatizar que la duración máxima recomendada de un ‘sprint’ es de un mes, puesto que, a medida que pasa el tiempo es más probable que cambie la definición de lo que se está construyendo o que aumentar la complejidad del producto y, en consecuencia, se incrementa también el riesgo de que no entreguemos lo que el cliente espera.
Al final de cada ‘sprint’ se lleva a cabo una labor de inspección y revisión del trabajo realizado, en la que el ‘Product owner’ (o incluso el propio cliente) que da ‘feedback’ al equipo. En esta sesión, el propietario del producto decide si se acepta o no como válida la funcionalidad o entregable desarrollado. La reunión debe cumplir una serie de condiciones:
Los asistentes son el equipo ‘scrum’ y otros interesados que puedan resultar clave.
Se identifica lo que se ha hecho y lo que no respecto a lo inicialmente acordado.
Se detectan los problemas y se analiza cómo se resolvieron.
Todo el equipo debe colaborar a la hora de decidir qué hacer a continuación.
Todas las metodologías ágiles buscan mejorar de manera continua la forma en la que el equipo se relaciona durante el proceso de desarrollo. En ‘scrum‘ existe otra sesión específicamente definida para lograrlo: la retrospectiva. Se trata de una oportunidad para que el equipo comparta sus impresiones y recomendaciones sobre la forma en la que han trabajado durante el ‘sprint’ que acaba de finalizar, con el objetivo de identificar las lecciones aprendidas.
orientación al cliente, adaptación al cambio, entregas rápidas a los usuarios, calidad y mejora continua de procesos de trabajo.
Sin embargo, ni son lo mismo, ni son incompatibles. Tanto ‘agile’ como ‘lean’ cuentan con herramientas muy útiles que pueden funcionar conjuntamente si se aplican de manera adecuada.
A la hora de comparar ambas filosofías, hay que tener en cuenta que ‘lean’ es una de las fuentes en las que se inspiran las diferentes metodologías ágiles. La filosofía ‘agile’ surgió a raíz del Manifiesto Ágil de 2001 que supuso un cambio total en la forma de enfocar el desarrollo de ‘software’, aunque actualmente se ha ido extendiendo a muchas otras industrias, especialmente a aquellas relacionadas con el desarrollo de productos. El término ‘lean’, sin embargo, empezó a usarse en Occidente mucho antes, concretamente en los años 80, para describir el sistema de producción de Toyota establecido en Japón desde los años 50.
Una característica que comparten ambas filosofías es la importancia que conceden a entregar rápidamente a los clientes un producto que les genere valor, es decir, que resuelva sus necesidades. De igual forma, ‘lean’ y ‘agile’, buscan adaptar constantemente sus procesos a los cambios en el mercado y a las necesidades de los clientes.
Si bien es cierto que, a pesar de compartir los mismos principios,’lean’ y ‘agile’ presentan algunas diferencias. ‘Agile’ está orientada a la entrega de producto en funcionamiento, con utilidad para los usuarios, y que permita obtener un ‘feedback’ temprano de los consumidores. ‘Lean’ se centra en lograr un proceso capaz de entregar el mayor valor posible al cliente con la mejor calidad.
‘Agile’ se basa sobre todo en las personas y sus relaciones, tanto en los equipos de trabajo como en el cliente, un respeto por los individuos que es herencia directa de ‘lean’. Por un lado, este marco de trabajo emplea equipos multidisciplinares que trabajan juntos durante todo el desarrollo del proyecto, producto o servicio, creando valor de manera incremental; y, por otro, se centra en el contacto con el cliente, que está presente en todo momento. La cultura del ‘feedback’ se vuelve esencial, pues el objetivo es entregar valor al cliente desde el principio, conseguir adaptarse a sus necesidades, y hacerle partícipe del avance en el desarrollo de su producto para que pueda introducir los cambios que considere necesarios.
‘Lean’, sin perder de vista esta atención a los individuos, otorga una mayor importancia a la calidad y la eficiencia. Su objetivo es eliminar desperdicios y quedarse únicamente con aquello que aporte valor al proceso y, por tanto, al cliente. Es decir, hacer más con menos.
Así como ‘agile’ busca más el desarrollo de un nuevo producto que resuelva una necesidad del cliente, ‘lean’ se centra más en mejorar el proceso para reducir tiempos de entrega y mejorar la calidad de los productos. Por ejemplo, en el lanzamiento de un producto en ‘agile’ se busca lanzarlo rápido y aprender de él a través de los comentarios de los clientes, mientras que en ‘lean’, se tiene en cuenta lo que el mercado demanda en ese momento y se elimina del proceso todo aquello que no sirve en pro de la calidad, es decir, que el producto no tenga ningún defecto.
Metodología Scrum
El núcleo central de la metodología de trabajo ‘scrum’ es el ‘sprint’. Se trata de un miniproyecto de no más de un mes (ciclos de ejecución muy cortos -entre una y cuatro semanas), cuyo objetivo es conseguir un incremento de valor en el producto que estamos construyendo. Todo ‘sprint’ cuenta con una definición y una planificación que ayudará a lograr las metas marcadas.‘Scrum’, que se emplea cada vez con más frecuencia para desarrollar productos y servicios digitales, es un marco de trabajo donde los miembros de un equipo multidisciplinar colaboran en la construcción de un producto de manera que sea valioso desde sus primeras versiones. Es la forma en que se desarrollan, ciertas aplicaciones que posteriormente van ampliando sus funcionalidades en entregas sucesivas.
Para lograr esta entrega de valor tan rápida y continua, los equipos ‘scrum’ trabajan en ciclos de ejecución muy cortos -entre una y cuatro semanas- que se denominan ‘sprints’ y tienen un objetivo muy claro.
El primer paso para alcanzar este objetivo -o hito del proyecto- es la reunión de planificación, una sesión en la que debe participar todo el equipo ‘scrum’ y que supone el pistoletazo de salida del ‘sprint’. Esta reunión se divide en dos partes que tratan de dar respuesta a dos preguntas fundamentales: ¿Qué se va a entregar? y ¿cómo se va a realizar el trabajo?
Roles
Para resolver estas cuestiones, los distintos miembros del equipo asumen unas responsabilidades definidas por la metodología ‘scrum’ en función del rol que desempeña cada uno de ellos:
-‘Scrum Master’: Se centra en cómo va a trabajar el equipo. Es el responsable de conseguir que se sigan los valores y las prácticas de ‘scrum’. Ayuda a los miembros del equipo para que trabajen de forma autónoma y auto-organizada. Se ocupa también de eliminar problemas y obstáculos que puedan poner en riesgo el objetivo del ‘sprint’.
-‘Product owner’ (o propietario del producto): Su mirada está siempre puesta en el cliente, y en lo que el equipo va a desarrollar. Es responsable de que el producto vaya incrementando su valor con cada ‘sprint’. Además, es la persona encargada de marcar el objetivo de manera clara y acordada con el resto del equipo.
-Equipo de desarrollo: Es el grupo de profesionales que hace el trabajo necesario para poder entregar el incremento de valor en el producto. Se auto-organizan para realizar el trabajo y han de estar disponibles a tiempo completo en el proyecto.
Durante el ‘sprint’
Cuando el ‘sprint’ ha comenzado, cada uno de los miembros del equipo ejerce su rol, asegurándose de que se cumplan siempre las siguientes condiciones:
No se realizan cambios que pongan en peligro el objetivo.
Los estándares de calidad no disminuyen.
El ‘Product owner’ y el equipo de desarrollo trabajan conjuntamente ajustando el detalle de las funcionalidades planificadas para el ‘sprint’.
Además de construir el producto, todo equipo trabaja conjuntamente en la redefinición del proyecto. El ‘Product owner’ y los miembros del equipo aclaran y negocian entre ellos a medida que se aprende más.
Es importante enfatizar que la duración máxima recomendada de un ‘sprint’ es de un mes, puesto que, a medida que pasa el tiempo es más probable que cambie la definición de lo que se está construyendo o que aumentar la complejidad del producto y, en consecuencia, se incrementa también el riesgo de que no entreguemos lo que el cliente espera.
Revisión del ‘sprint’
Al final de cada ‘sprint’ se lleva a cabo una labor de inspección y revisión del trabajo realizado, en la que el ‘Product owner’ (o incluso el propio cliente) que da ‘feedback’ al equipo. En esta sesión, el propietario del producto decide si se acepta o no como válida la funcionalidad o entregable desarrollado. La reunión debe cumplir una serie de condiciones:
Los asistentes son el equipo ‘scrum’ y otros interesados que puedan resultar clave.
Se identifica lo que se ha hecho y lo que no respecto a lo inicialmente acordado.
Se detectan los problemas y se analiza cómo se resolvieron.
Todo el equipo debe colaborar a la hora de decidir qué hacer a continuación.
Todas las metodologías ágiles buscan mejorar de manera continua la forma en la que el equipo se relaciona durante el proceso de desarrollo. En ‘scrum‘ existe otra sesión específicamente definida para lograrlo: la retrospectiva. Se trata de una oportunidad para que el equipo comparta sus impresiones y recomendaciones sobre la forma en la que han trabajado durante el ‘sprint’ que acaba de finalizar, con el objetivo de identificar las lecciones aprendidas.
Agile y Lean
Estas dos metodologías de trabajo pueden resultar muy parecidas si se tiene en cuenta que ambas comparten los mismos principios fundamentales:orientación al cliente, adaptación al cambio, entregas rápidas a los usuarios, calidad y mejora continua de procesos de trabajo.
Sin embargo, ni son lo mismo, ni son incompatibles. Tanto ‘agile’ como ‘lean’ cuentan con herramientas muy útiles que pueden funcionar conjuntamente si se aplican de manera adecuada.
A la hora de comparar ambas filosofías, hay que tener en cuenta que ‘lean’ es una de las fuentes en las que se inspiran las diferentes metodologías ágiles. La filosofía ‘agile’ surgió a raíz del Manifiesto Ágil de 2001 que supuso un cambio total en la forma de enfocar el desarrollo de ‘software’, aunque actualmente se ha ido extendiendo a muchas otras industrias, especialmente a aquellas relacionadas con el desarrollo de productos. El término ‘lean’, sin embargo, empezó a usarse en Occidente mucho antes, concretamente en los años 80, para describir el sistema de producción de Toyota establecido en Japón desde los años 50.
Cambios en la organización
La disrupción vendrá de la mano de grupos de trabajo más reducidos para innovar no es necesario implicar a un gran número de empleados. Diferentes estudios publicados en ‘Harvard Business Review’ revelan que los grupos más pequeños son los más originales.Una característica que comparten ambas filosofías es la importancia que conceden a entregar rápidamente a los clientes un producto que les genere valor, es decir, que resuelva sus necesidades. De igual forma, ‘lean’ y ‘agile’, buscan adaptar constantemente sus procesos a los cambios en el mercado y a las necesidades de los clientes.
Si bien es cierto que, a pesar de compartir los mismos principios,’lean’ y ‘agile’ presentan algunas diferencias. ‘Agile’ está orientada a la entrega de producto en funcionamiento, con utilidad para los usuarios, y que permita obtener un ‘feedback’ temprano de los consumidores. ‘Lean’ se centra en lograr un proceso capaz de entregar el mayor valor posible al cliente con la mejor calidad.
‘Agile’ se basa sobre todo en las personas y sus relaciones, tanto en los equipos de trabajo como en el cliente, un respeto por los individuos que es herencia directa de ‘lean’. Por un lado, este marco de trabajo emplea equipos multidisciplinares que trabajan juntos durante todo el desarrollo del proyecto, producto o servicio, creando valor de manera incremental; y, por otro, se centra en el contacto con el cliente, que está presente en todo momento. La cultura del ‘feedback’ se vuelve esencial, pues el objetivo es entregar valor al cliente desde el principio, conseguir adaptarse a sus necesidades, y hacerle partícipe del avance en el desarrollo de su producto para que pueda introducir los cambios que considere necesarios.
‘Lean’, sin perder de vista esta atención a los individuos, otorga una mayor importancia a la calidad y la eficiencia. Su objetivo es eliminar desperdicios y quedarse únicamente con aquello que aporte valor al proceso y, por tanto, al cliente. Es decir, hacer más con menos.
Así como ‘agile’ busca más el desarrollo de un nuevo producto que resuelva una necesidad del cliente, ‘lean’ se centra más en mejorar el proceso para reducir tiempos de entrega y mejorar la calidad de los productos. Por ejemplo, en el lanzamiento de un producto en ‘agile’ se busca lanzarlo rápido y aprender de él a través de los comentarios de los clientes, mientras que en ‘lean’, se tiene en cuenta lo que el mercado demanda en ese momento y se elimina del proceso todo aquello que no sirve en pro de la calidad, es decir, que el producto no tenga ningún defecto.
No hay comentarios:
Publicar un comentario