Hablar de agilidad en áreas o departamentos no informáticos

Mi mujer trabaja desde hace años como administrativa, y a diario como todas las parejas hacen, hablamos sobre aquellas cosas que nos han pasado en la oficina. A pesar de que ella ha pasado por varias empresas, el tipo de problemas a los que se enfrenta en los departamentos de índole administrativa, más allá de las propias dificultades del negocio, siempre tienen rasgos comunes, tales como:

• Desorganización de tareas;
• Actividades que se duplican por varias personas;
• Conocimiento que solo tiene una persona o desconocimiento de tareas;
• No existe cultura de compartir información;
• No existe cultura de reutilización de elementos, artefactos o conocimiento;
• Desconocimiento del tiempo empleado en la realización de tareas;
• Excesivas reuniones que resultan la mayoría de las veces inútiles;
• Poca o ninguna planificación del trabajo;

No es la primera vez que, al hablar de todos estos temas, le he comentado en más de una ocasión que por qué no se plantea hablar con sus compañeros y responsables, y proponerles que empiecen a emplear dinámicas ágiles para intentar cambiar algo el enfoque del trabajo en el departamento, con objeto de mejorar la gestión y trabajo en equipo.

Pero claro, al hablarle de roles, metodología, backlog, entregas iterativas, deja de prestarme atención porque son conceptos que no entiende a priori dado que son muy técnicos, y que le suenan a chino. Creo que inconscientemente debe activar el modo escucha pasiva pensando que lo que le estoy contando son frikadas técnicas del mundo informático. Y, aunque parcialmente tiene razón, dado que Agile siempre ha estado vinculado y se creó orientado al mundo del desarrollo del software, sus principios y prácticas bien podrían aplicarse perfectamente a otros entornos. Como ejemplo, y para darle respuesta a aquellas personas que no son técnicas y que trabajan en un departamento que realice tareas administrativas (por ejemplo), voy a tratar de compartir mi reflexión sobre cómo aplicar la metodología Agile a un departamento no IT, utilizando un lenguaje llano y que todos entendamos y como respuesta también a las conversaciones diarias con mi mujer.

Este artículo no pretende ser un tutorial para técnicos o un curso de Agile/Scrum, sino una referencia clara y orientada para que personas ajenas al mundo informático puedan entenderlo y aplicarlo.

¿Qué es Agile?

La Metodología Ágil siempre se asocia al mundo IT (informática), dado que su nacimiento sí estuvo ligado al desarrollo software. A principios de 2001, diecisiete críticos de los modelos de mejora del desarrollo de software basados en procesos se reunieron para tratar sobre técnicas y procesos de desarrollo.

En aquellas reuniones se usó el término “Métodos Ágiles” para definir los métodos que estaban surgiendo como alternativa a las metodologías tradicionales (como CMMI) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y con fuerte dependencia de planificaciones detalladas previas al desarrollo. Y así, resumieron los principios en cuatro postulados, que han quedado denominados como Manifiesto Ágil cuyo contenido dice:

“Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

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

Los postulados del Manifiesto Ágil

Traduciendo estas palabras en otros términos que entendemos mejor, los postulados vienen a decir que:

• Uno de los principales puntos críticos del manifiesto es valorar a las personas, su conocimiento y su actitud por encima de los procesos;
• Se prioriza la realización de elementos que aporten valor o que proporcionen algo útil, por encima de realización excesiva de documentación. Si bien esto no significa que no se documente nada, sino que se documente lo suficiente como para que sea útil. Se debe emplear más tiempo en hacer cosas útiles y reutilizables, que en documentación excesivamente compleja e inmanejable;
• Se debe dar más importancia o énfasis al trabajo en equipo, recibir feedback continuo (retroalimentación), que al propio alcance completo de lo que nos están solicitando. Esto implica que los responsables de equipos deben ser conscientes de la importancia de implicarse en revisiones constantes y periódicas del trabajo con el equipo, para poder proporcionar feedback y críticas constructivas con objeto de ir aprendiendo y madurando. Aunque la idea es que los equipos sean autogestionados, esta parte implica que antes ha tenido que existir una formación o preparación de este, y una madurez y solidez en las actividades que desempeñen, con una confirmación de que los resultados obtenidos son los esperados;
• Trabajar en un entorno inestable, requiere estar preparado constantemente ante posibles cambios, dado que no existe un plan de trabajo a medio o largo plazo. La capacidad de respuesta debe estar por encima del seguimiento exhaustivo de un plan a medio o largo plazo. No estamos hablando de procesos de fabricación o construcción largos y que requieren de grandes planificaciones y estimaciones. Sino de desarrollo de tareas administrativas, normalmente bastante concretas y acotadas en el tiempo.

En resumen, lo que definieron estos críticos, fueron unas pautas prácticas de cómo enfocar el trabajo y que favorecieran disminuir tiempos, eliminar incertidumbres, mejorar eficiencias y la calidad de los trabajos, y tener capacidad de respuesta ante cambios repentinos y frecuentes, para, así como, perseguir la entrega de valor o elementos útiles para la empresa o negocio lo antes posible.

¿Qué es Scrum? ¿Qué relación tiene con Agile?

Si hablamos de Agile y Scrum, términos de moda desde hace unos años, debemos aclarar que, Scrum es un marco de trabajo Agile, un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar en equipo y de forma colaborativa, con el objetivo de conseguir el mejor resultado aportando valor lo antes posible.

Una metodología o marco de trabajo como Scrum aporta unas directrices concretas, normas y elementos ya definidos que facilitan la consecución de tareas. Aunque debe adaptarse siempre a la realidad de la empresa, cultura, entorno, personalidad del equipo y necesidades reales. Son pocos o muy específicos los entornos que admiten una implementación de Scrum “de libro”, por ejemplo: fábricas de software, empresas que ofrecen servicios gestionados y facturan con carácter mensual, empresas de diseño y prototipado, entre otras. Por lo que, en entornos no asociados al mundo IT o del desarrollo de software, se debe aplicar todavía más si cabe.

Así, vamos a ver distintos ejemplos de cómo los principios ágiles y algunas de las directrices, ceremonias o artefactos de un marco de trabajo ágil, se podrían poner en práctica en un departamento ajeno al mundo informático. No sin antes aclarar algunas confusiones típicas en las que incurren personas ajenas a la informática cuando oyen hablar de estos temas.

Errores que se cometen al hablar de trabajo ágil

• Se suele pensar que hablar de agilidad es hablar de rapidez en el trabajo. No se pueden confundir ambos términos “agilidad” con “rapidez”, dado que, aunque pudieran parecer lo mismo, tienen connotaciones diferentes:
  • Agilidad, podríamos definirlo como la habilidad de moverse con ligereza y facilidad. Habilidad de cambiar de posición de manera eficaz;
  • Rapidez, se define como aquello que es rápido, que emplea poco tiempo.

Ser ágil significa estar preparado y ser flexible para aceptar cambios en cualquier momento, aunque no implica que sean inmediatos. Ser ágil significa que, en tu forma de trabajar, cambiar de rumbo en un momento dado no es crítico para tu trabajo, ni provoca grandes pérdidas. Ser ágil significa que puedes ir abordando tareas cortas, específicas, utilizando sólo los recursos estrictamente necesarios. Ser ágil significa que tus objetivos y tareas a largo plazo debes dividirlas en tareas de corto alcance que puedan ser realizadas y evaluadas en un plazo corto (inferior a una semana, por ejemplo, incluso realizables en un solo día). Ser ágil no significa que todas tus tareas vayas a desarrollarlas en menos tiempo, o que puedan exigirte más cosas en menos tiempo. Hay que tener muy clara esta diferencia para no caer en confusiones. Ser ágil no significa ser rápido. No es lo mismo;

• La agilidad puede definirse desde diversos prismas, pero uno de ellos, sería, por ejemplo, que es una forma de orientar el trabajo en equipo para la ejecución de tareas pequeñas, fomentar el trabajo en equipo y la colaboración, y revisiones periódicas del trabajo realizado y del trabajo pendiente de realizar (de forma inmediata). Al tratarse siempre de tareas relativamente pequeñas, siempre se está en disposición de producir algún cambio sin que el impacto de este sea costoso en términos de tiempo o esfuerzo;
• La agilidad significa que debe emplearse también algo de tiempo a revisar el trabajo realizado, sacar conclusiones, aprender de lo bueno, rediseñar o corregir lo malo, re-enfocar dirección y estrategia del trabajo si es oportuno, y recibir retroalimentación (feedback) del trabajo realizado, es decir que te digan si lo estás haciendo bien, y si no, cómo mejorarlo. Y que no se vea como una pérdida de tiempo, dado que es una tarea básica de esta forma de trabajo. Es lo que se llama en jerga técnica “retrospectivas”;
• La agilidad se relaciona siempre con informática. Como ya hemos visto, se creó para la informática. Pero sus bondades, ceremonias, elementos pueden ser utilizados en cualquier ámbito. No es una herramienta exclusiva de áreas de IT.

Cómo sacar provecho al enfoque ágil

Aclaradas estas premisas, vamos a proponer directrices, actividades y formas de enfocar el trabajo de forma específica para sacarle provecho al enfoque ágil:

Dar importancia a las personas sobre los procesos

Uno de los principios de la agilidad es dar importancia a las personas sobre los procesos y herramientas (“Individuos e interacciones sobre procesos y herramientas”). Piensa que tener un buen coche no te hace buen conductor. Pero sí puedes ser un buen conductor sin tener un buen coche. Está claro que necesitas conducir aun no teniendo coche para ser un buen conductor. Esta metáfora puede traducirse de forma concreta en que las personas deben tener:

• Claros sus objetivos y lo que tienen que hacer;
• Recursos y tiempo para poder hacerlo;
• En consecuencia, si tienen claro lo que tienen que hacer, y disponen de recursos para hacerlo, estarán motivados. Uno de los errores más frecuentes es que los jefes o encargados asignan tareas a personas que o no tienen el conocimiento suficiente, bien de la tarea, contexto o entendimiento del negocio, o, por otro lado, no disponen de los medios necesarios para hacerlas. Esto provoca en las áreas administrativas (aunque aplica a cualquier ámbito) frustración y desmotivación.

Uno de los principales errores, en mi opinión, es asignar tareas a personas que no saben muy bien cómo enfrentarse a ellas, asumiendo que por “intervención divina” van a entender de forma clara y concisa lo que tienen que hacer. Todas las personas necesitan acompañamiento y explicaciones para entender los motivos que implican la realización de las diversas tareas, y posteriormente, tiempo y recursos para aprender a ejecutarlas.

Asignar tiempos específicos y periódicos

Asigna tiempos específicos y periódicos a formar al equipo en las tareas que quieres que ejecuten. Por ejemplo, 1h al día durante varias semanas, hasta que cada persona se vea con la seguridad y destreza como para ejecutar sus tareas de forma autónoma. Es necesario que se hable diariamente sobre su evolución para conocer cómo va progresando y reorientar a las personas en caso necesario.

Delegar tareas

Empieza a delegar tareas específicas y cortas a las personas nuevas en tu equipo, que les permitan introducirse en las dinámicas del departamento y que les ayuden a ir entendiendo el negocio.

Asegúrate de que el equipo entiende el impacto de las tareas que está realizando y en qué parte de tus procesos de negocio se encuentran. Les dará entendimiento de la importancia de estas, y les dará una visión para establecer caminos alternativos para conseguir el objetivo frente a dificultades o imposibilidades.

Dar importancia a las herramientas

Otro de los principios de la agilidad es dar importancia a las herramientas para que sean útiles, sobre los manuales o documentación interminable sobre las mismas (“Software funcionando sobre documentación extensiva”). En mi opinión, es un error dejar que las personas se enfrenten a las tareas con la única ayuda de documentación. La documentación siempre debe ser un apoyo, una ayuda concreta, y la formación inicial siempre debe ser de persona a persona.

• Si no es estrictamente necesario, no se debe emplear excesivo tiempo en realizar manuales exhaustivos y extensos de procedimientos. Es más práctico realizar un esquema resumido del procedimiento y asegurarte de que el esquema realizado es entendible, entendido y accesible por todo el equipo;
• Explica el procedimiento de forma personal, para dar oportunidad a que las personas interactúen, lo vean, y puedan preguntar cuando surjan dudas;
• Utiliza los documentos de procedimientos como referencias y recordatorios, y no como una biblia o enciclopedia.

La facturación por encima de todo

Uno de los imponderables en el mundo empresarial es la facturación por encima de todo. Este objetivo básico y prioritario finalmente repercute en todas las áreas de las empresas, incluidos los departamentos administrativos.

Potenciar la comunicación y colaboración con los clientes

El tercer principio de agilidad se basa en potenciar la comunicación y colaboración con los clientes, por encima de contratos, facturas y cobros (“Colaboración con el cliente sobre negociación contractual”). Orientados a un área administrativa, podríamos hablar de acciones orientadas a potenciar el conocimiento de los clientes y mejorar la experiencia de estos con la empresa.

Es necesario entender en primera persona cuáles son las necesidades, inquietudes y problemas de los clientes de la empresa, aunque el departamento administrativo no tenga un contacto directo. Ello les aportará más perspectiva y contexto en las tareas que ejecutan, así como conocimiento del impacto que tiene cada una de las tareas que ejecutan.

Cada persona del departamento debe tener claro si es el canal de entrada de comunicación con los clientes (o terceros), cuál es su función principal (entrada de comunicación u otras tareas), y los medios de los que dispone para gestionar esa comunicación.

Es un contrasentido esperar que una persona que recibe constantemente llamadas de teléfono de terceros, puede ejecutar con solidez y eficacia tareas administrativas complejas. Los cambios de contexto causan excesivas distracciones y que el trabajo no sea eficiente.

Si hay personas del área administrativa que sean responsables de la comunicación con clientes, deben tener claro que su prioridad es dar respuesta a los mismos y gestionar dicha comunicación por encima de sus tareas administrativas.

• Deben acometer tareas muy específicas, que requieran poca concentración;
• Deben tener algún tipo de soporte a la comunicación: gestor documental, centralita, correo electrónico.

Si no existe la figura de recepcionista en la empresa, sería una buena práctica establecer esa responsabilidad (entregarle el teléfono de llamadas) un día a la semana a cada persona del equipo. De esta forma penalizaría únicamente un día a cada uno, teniendo el resto de los días para un trabajo más eficiente.

Estar preparados ante los cambios y aceptarlos

El último postulado se basa en que el equipo debe estar siempre preparado para aceptar cambios (“Respuesta ante el cambio sobre seguir un plan”) lo que tiene ciertas connotaciones a la hora de afrontar y organiza el trabajo.

• Divide las tareas en subtareas todo lo posible para que no ocupe mucho tiempo su desarrollo o ejecución. Es una buena práctica no dejar cosas a medias, por lo que, si las tareas son cortas en alcance, podrán terminarse rápido;
• Si tus tareas son divididas y cortas, siempre será más fácil establecer cambios a elementos más pequeños que grandes, con lo que los desvíos en términos de esfuerzo, tiempo y coste, siempre será menor;
• No se deben planificar acciones complejas a medio o largo plazo sin dividirlas en acciones que puedan enfocarse dentro de un día o dos idealmente (o semana como máximo);
• Acciones planificadas a largo plazo implica que, si se requiere un cambio, se dejen a medias y no se acaben las tareas, produciendo en consecuencia un incremento de problemas y dificultades, así como información inconsistente.

Otras implementaciones de las metodologías ágiles

Además de una implementación práctica de los principios ágiles originales, podemos hablar de otras implementaciones más específicas.

Trabajo en equipo y coordinación diaria

• Dailies es el nombre técnico que reciben las reuniones periódicas (diaria o días alternos) de 10-15 minutos máximo, en la que cada persona del equipo debe compartir con el resto en menos de 3 minutos:
  • Qué es lo que ha hecho desde la última daily;
  • Qué es lo que tiene previsto hacer hoy (o hasta la siguiente daily);
  • Si tiene algún problema o necesidad para ejecutar su trabajo previsto.

De esta forma, exponiendo su problema o necesidad, toda el área puede aportar las ayudas necesarias en equipo, o comunicar a los responsables la necesidad existente para la consecución de las tareas asignadas.

• El conocimiento y la realización de tareas deben ser compartidas por más de una persona en el equipo. Esto no implica que todos deben saber y hacer de todo. Cada uno tiene su área de especialización y su valor, y debe seguir siendo así. Pero, todas las tareas requeridas para el funcionamiento del área administrativa deben poder ser ejecutadas siempre por un mínimo de dos personas diferentes. Esto mitiga riesgos frente a imprevistos, bajas, rotación de personal, entre otros;
• El conocimiento no debe manejarse como un tesoro en propiedad de una persona. El conocimiento se debe gestionar como un bien corporativo o del área, y debe permanecer siempre. Asimismo, debe estar presente en más de dos o tres componentes del equipo;
• Las personas del equipo no deben ser reprendidas y sí valoradas por emplear tiempo en ayudar a sus compañeros, dado que en la mayoría de las situaciones además están asumiendo que esta actividad de ayuda no puede ser una excusa o motivo de no cumplir con sus objetivos o tareas planificadas;
• Con el tiempo, los equipos serán más autosuficientes y mejorarán su excelencia en el trabajo;
• Es totalmente crítico e indispensable la implicación de quien conoce el negocio y tiene la visión completa del mismo como parte del equipo, y de su participación en algunas de las ceremonias que se proponen (retrospectivas y dailies principalmente). A este rol técnicamente se le conoce en el argot IT como “Product Owner”, o “PO”.

Entregas iterativas

En todos los trabajos a realizar siempre se debería considerar cual es la versión mínima que puede ser útil y aportar valor, aunque no sea un entregable o trabajo terminado. La primera entrega de cualquier trabajo o tarea que se realice por primera vez no será completa y perfecta. Pero sí debe ser “útil”.

Se deben realizar trabajos o tareas que puedan y deban ser madurados, ampliados, mejorados, en siguientes iteraciones, es decir, al día siguiente, a la semana siguiente o en otro momento. Obviamente habrá muchas tareas administrativas atómicas y que no puedan dividirse, y otras si podrán ser susceptibles de dividirse y trabajarse en la parte más útil (no la más crítica).

Deberán considerarse tareas de carácter rutinario y periódico, dado que será necesario realizar un pequeño análisis para ver de qué forma se puede construir o hacer algo que sirva como recurso para facilitar la ejecución y control de esta.

Es posible que cualquier artefacto (archivo Excel, procedimiento, documento, macro, desarrollo Software) requerido para un uso rutinario y periódico, la primera vez que se haga, requiera de una inversión mucho mayor en tiempo. Aunque posteriormente se recupere el tiempo invertido dado que dará soporte a la actividad rutinaria obtenido una mayor calidad de trabajo en menor tiempo.

Planificación del trabajo

La realización de tareas cortas y de entregas constantes producirá un ritmo constante de trabajo, lo que implicará que con la experiencia y con el paso del tiempo, sea posible realizar estimaciones asociadas a las distintas tareas, por lo que será más fácil planificar el trabajo con más precisión.

Es una costumbre extendida utilizar “post-it” pegados a la pantalla del ordenador o un cuaderno para apuntar las tareas pendientes que cada uno tiene que hacer. Se propone para que un área sea ágil, esta información pueda ser compartida entre todo el equipo, aunque cada uno, por su área de especialización, por su asignación o rol, sepa qué tareas son las suyas. Para ello, se emplea un elemento cuyo nombre técnico es “backlog”. Este artefacto no es más que un sitio en el que se debe realizar un listado de todas las tareas que se necesitan ejecutar en el área o departamento. Tanto tareas específicas y que se realizan una sola vez, como tareas periódicas, tareas concretas o incluso pensamientos o iniciativas que deban ser analizados con mayor profundidad.

Además, se puede utilizar desde un elemento simple como puede ser un corcho colgado en la pared del departamento con papeles y chinchetas, un fichero Excel compartido y accesible por todos, así como sistemas más sofisticados (y altamente recomendados) como herramientas software de soporte: por poner un ejemplo de una de las más extendidas, Trello, aunque no es la única. Hay infinidad de ellas, gratuitas, de pago, instalables en el ordenador, o de uso en la nube.

Es importante si se opta por el uso de herramientas de backlog software, conocer el concepto de “Kanban”. Éste se explica en la última parte de este artículo.

La dinámica de uso, aunque se puede complicar mucho, en primera instancia es bien simple: todas las tareas requeridas están identificadas (y normalmente descritas como mínimo a alto nivel). Y con el tiempo y la experiencia, en muchos casos, ya se conocerá el tiempo que implican muchas de ellas.

Las tareas deben tener algunos datos básicos, que se conservan necesarios para su definición:

• Fecha de alta;
• Descripción de la tarea;
• Debe poder establecerse una prioridad en las mismas, para que el equipo sepa cuál es que se debe resolver antes de otra. La prioridad puede darse bien por importancia o por que sea una tarea crítica que afecte a terceros, o bien por tareas planificadas y que llegue su hora o momento previsto de ejecución;
• Tiempo estimado (sólo si se conoce).
• En cada daily (esa reunión diaria de 10-15 minutos) cada integrante del área o departamento tiene que asignarse las tareas que va a ejecutar durante el día (o hasta la siguiente daily). Esta asignación debe responder a estos criterios: quién es la persona encargada de hacerlo o persona encargada en su ausencia (backup), quien tiene el conocimiento de esta (no todos tienen el mismo conocimiento), quién está disponible para hacerlo, a quién le motiva más hacerla, entre otros.

Retrospectivas

Todas las tareas realizadas (entregadas o no) deben ser puestas en común una vez cada cierto tiempo para que todos los componentes de área o departamento opinen libremente y de forma constructiva sobre las mismas, con objeto de potenciar las cosas que se hacen bien, analizar posibles mejoras, y escuchar sugerencias o propuestas de otras personas.

Esta reunión interna (de entre 2-3 horas) debe realizarse idealmente una vez al mes. La norma es que se marque un ritmo temporal y se obligue al equipo a hacerla siempre y como una parte más de su trabajo.

¿Qué es Kanban?

KANBAN es un concepto de origen japonés que significa “tarjetas visibles” (kan significa algo así como visual o visible, y ban tarjeta). Según Wikipedia, “se denomina Kanban a un sistema de tarjetas que en su implementación más sencilla utiliza tarjetas que se pegan en los contenedores de materiales y que se despegan cuando estos contenedores son utilizados, para asegurar la reposición de dichos materiales. Las tarjetas actúan de testigo del proceso de producción”.

La idea de utilizar Kanban en la gestión de tareas de un backlog (o lista de tareas), es bastante simple (aunque se puede complicar todo lo que uno quiera). De forma simple, piensa en una pizarra o panel en el que se organicen carriles verticales o columnas en las que vayas a colocar tus tareas en agrupaciones o bloques:

• Tareas pendientes o tareas que no están bien definidas y que requieren de una mayor definición;
• Tareas que están listas para poder ejecutarlas y que forman parte del trabajo planificado para esta jornada o espacio temporal hasta la siguiente daily;
• Tareas que se están ejecutando;
• Tareas terminadas.

La idea es que cada persona vaya moviendo sus tareas (las que tenga asignadas) de un carril a otro según vaya planificando, haciendo y terminando, sabiendo que además este panel o pizarra debe ser visible y accesible por toda el área en todo momento. De esta forma todos tienen conocimiento al momento de cómo están las tareas repartidas y su estado.

Lo lógico y necesario es que se establezcan algunas normas de manejo, que deben establecerse de común acuerdo entre todo el departamento. Por poner algunos ejemplos:

• Establecer un tiempo de ejecución de tareas, es decir tiempo sobre el que se van a planificar y asignar las tareas de “Pendientes” a “Listas para hacer”. Por ejemplo, 8h (diaria), de daily a daily (si se realiza en días alternos), 40h (semanal);
• Tareas simultáneas que pueden ponerse “en curso” por persona. La lógica debería decirnos que no deberíamos alternar muchos trabajos de forma simultánea para no desviar la atención. Podríamos establecer que no podemos tener más de 2 tareas asignadas a una misma persona en el carril “En curso”. En la jerga técnica, a este concepto se le conoce como WIP (Work In Progress);
• Se debe entender exactamente qué implican las tareas terminadas: reporte a un superior, formación de esta a otro compañero, dar por terminada alguna fase administrativa o iniciar otra y reubicar en “Pendientes” por tratarse de una tarea repetitiva y requerida en una fecha próxima (iteración);
• Medir los tiempos asociados al tiempo que están las tareas “en curso”, para así obtener el coste temporal de cada una y poder realizar planificaciones posteriormente;
• Dónde y cómo gestionar el listado completo de tareas pendientes, y el listado de tareas terminadas. Así como si se debe permitir la realización de consultas de tareas ejecutadas, quién la ejecutó, el tiempo que tardó (consulta de históricos);
• Privacidad de las tareas. En un departamento de RR.HH. por ejemplo, quizá alguna de las tareas tenga carácter confidencial, por lo que no pueda ser ubicada físicamente en una pizarra visible por todo el mundo, de la misma forma que no podrá ser creada en un programa que no permita un control de permisos y roles de acceso. Todo ello, dependerá del tipo de información que se maneje en el área, y de la posibilidad o no de dar visibilidad de este trabajo hacia el exterior. Por ejemplo, una PYME compuesta únicamente por 4 administrativos en oficina, no tendría mucho sentido hablar de confidencialidad de datos de negocio entre ellos, dado que los 4 quizá deberían tener acceso a toda la información.

Conclusiones

Más allá de modas y tendencias, la agilidad ofrece entre otras cosas, una forma de cómo enfocar el trabajo, que puede ser adaptado a cualquier ámbito laboral. Para ello se requiere “algún conocimiento metodológico”, experiencia laboral, y sobre todo muchísimo sentido común. En este aspecto, no existen verdades absolutas, y quien las quiera imponer como tal, en mi humilde opinión, está herrando por concepto.

Autor: Pedro J. Medina ツ, PMO Manager en Grupo Solutio