Ágil: Apropiación de Lean-Agile y Kanban

Una de las tareas del Centro de Alta Tecnología de Educación a Distancia de la UNAM en Tlaxcala, es desarrollar herramientas, plataformas y contenidos educativos así como la formación de recursos humanos en el desarrollo de tecnologías para la formación en línea. A través del Laboratorio de Investigación e Innovación Colaborativa en Tecnología Educativa (LIICTÉ) y con base en una metodología interdisciplinaria, perfiles técnicos y pedagógicos planean, diseñan, desarrollan y evalúan proyectos para el desarrollo de tecnologías y contenidos educativos.

La adopción de principios y prácticas Lean-Agile y la adaptación de la metodología Kanban para la realización de su trabajo, ha permitido optimizar tareas y mejorar el nivel de desempeño de los mismos equipos, así como la generación de productos y servicios de calidad.

Introducción

El propósito de este artículo es explicar cómo tras el análisis del marco teórico de principios y prácticas Lean-Agile junto con la metodología Kanban, se adoptaron estos principios y metodologías para el desarrollo de proyectos que realiza el CATED en el LIICTÉ y las adaptaciones requeridas para su mejor funcionamiento y aceptación por parte de los equipos de trabajo. De igual manera se trabajó conjuntamente con el Área de Proyectos Educativos Especiales del mismo CATED para unificar criterios. Cada jefatura de departamento ha trabajado en la adaptación de Kanban a la naturaleza específica de su área.

Metodología interdisciplinaria para el desarrollo de materiales educativos

Los equipos de trabajo están conformados por los siguientes perfiles:

• Líder de proyecto: experto en el diseño y gestión de proyectos educativos asistidos por tecnología.
• Experto en contenidos: experto en el área de conocimiento o campo sobre el cual se trabajan los contenidos o desarrollan los sistemas.
• Diseñador instruccional: experto en pedagogía.
• Diseñador gráfico: experto en comunicación visual.
• Integrador de tecnologías: programador y administrador de tecnologías Web.

Estos equipos diseñan y desarrollan tres diferentes tipos de proyectos:

• Desarrollo de aplicaciones: implica el análisis, diseño y desarrollo de Software Web educativo.
• Formación: involucra a expertos en contenidos con el equipo interdisciplinario para el análisis, diseño y desarrollo de programas educativos para la modalidad en línea, por ejemplo, cursos de educación continua, diplomados, licenciaturas, etc.
• Soporte: comprende la gestión de programas en línea, usuarios, aplicaciones, herramientas y plataformas, así como el seguimiento y apoyo a los usuarios finales de los sistemas.

A primera vista no parece complicado el funcionamiento del sistema, sin embargo, un detalle especial, es que en cualquiera de sus fases, intervienen de manera no controlada diferentes perfiles que realizan procesos difícilmente sistematizables por considerarse aspectos creativos o artesanales. Además, se atienden simultáneamente varios proyectos de diferente tipo, lo que en ocasiones produce confusión en el establecimiento de prioridades.

Adopción de Lean-Agile

Los principios básicos de Lean-Agile: restricción, valor, calidad e innovación, fueron conceptos clave para entender el cambio que requería la adopción de éstas prácticas. Sin embargo, cuando se empezaron a poner en práctica los conceptos -analizar los procesos, flujos de trabajo, historias de usuario, tareas, esfuerzo (o trabajo) con valor para el cliente, etc.- se vertieron diferentes puntos de vista, sobre lo que “debería ser” y lo que “realmente es”, y decidir el punto de partida para el desarrollo de los proyectos. Pese a esta diversidad de percepciones sobre el propio trabajo y la forma de organizarlo, lo que favoreció la adopción de Lean-Agile fue:

• La actitud de los equipos de trabajo: comunicación y colaboración.
• La disponibilidad al cambio: pensar diferente las tareas a realizar (atender a los requerimientos del cliente)
• El involucramiento de los líderes de equipos de trabajo y a diferentes niveles organizacionales para permitir la autogestión
• El reconocimiento de los elementos de valor (tangibles e intangibles) para el cliente: innovación de valor.

Estas actitudes permitieron generar una nueva visión del CATED, reconociendo sus fortalezas y debilidades, tanto institucionales como de las personas involucradas, asumiendo el compromiso de trabajar sobre aspectos personales que repercuten en el desarrollo de los proyectos e identificando las áreas de oportunidad para tener un ambiente laboral que:

• Incremente la productividad.
• Agilice los procesos.
• Dé seguimiento puntual.
• Responda con facilidad a los cambios.
• Innove los procesos, productos y servicios.
• Asegure la calidad.

Apropiación de Kanban

El consenso sobre los procedimientos y técnicas de la metodología Kanban fue un gran reto para los líderes de los equipos de trabajo.
A continuación, se explican los aspectos que inicialmente dificultaron la adopción de la metodología Kanban y como se llegó a una solución, inclusive realizando adaptaciones a la misma metodología.

Establecimiento de las etapas generales por las cuales transita cualquier proyecto (o un tipo de proyecto) para especificar las columnas del Tablero Kanban. Cuando se trabajó en la elaboración del Diagrama de Flujo de Valor (DFV), se hizo obvio que debía ser el mismo proceso para el desarrollo de todos los proyectos, lo cual complicó la elaboración de flujo de tareas en el tablero Kanban, ya que se pasaron por alto varios puntos medulares para su establecimiento:

• Generalmente, cada proyecto debe tener su tablero.
• No hay un tablero perfecto al inicio del proyecto, éste se va perfeccionando.
• La configuración del tablero debe permitir ser adaptativos a lo largo del desarrollo del proyecto.

Los procedimientos en el proceso de desarrollo de cualquiera de los proyectos del CATED, no son siempre los mismos y difícilmente se puede tener control de tiempos, recursos y de la participación de los expertos en contenido en la mayoría de las fases de desarrollo. Por ello, resultaba casi imposible hacer fluir las tareas en el tablero inicial, especificado de manera general, es decir, no se definió para un tipo de proyecto en particular, por lo que se decidió crear un nuevo DFV particularizado a un tipo de proyecto que reflejara los procedimientos en cada una de las fases, de tal manera que los perfiles involucrados reconocieran de inmediato su participación en alguna de las columnas (fases) del tablero.

Definición de las historias de usuario y tareas. La ambigüedad respecto a la enunciación de tareas en relación al cliente reside en que, cada integrante del equipo es cliente de los otros pues los requerimientos se hacen de manera multidireccional entre ellos.

Además, los clientes o usuarios finales de los contenidos educativos desarrollados son, generalmente: docentes, alumnos, coordinadores académicos y administradores escolares de un programa educativo. Al generar historias de usuario con base en las necesidades de estos usuarios, podemos encontrar aspectos generales, (usabilidad y accesibilidad) o específicos (ver un aviso o calificar una actividad). Ahora bien, dependiendo la fase del proyecto, para algunos miembros del equipo las historias de usuario más específicas implican la realización de muy pocas tareas, mientras que para otros involucran el desarrollo de muchas.

En consecuencia, se decidió elaborar tableros con base en tareas, ya que de ese modo fue más fácil identificar a los perfiles dentro del proceso que intervienen en cada una de las fases del tablero.

Especificación de las Tarea/Trabajo en Proceso (TEP). En un principio no fue fácil especificar el TEP en cada una de las columnas (fases del proyecto), debido principalmente a que no se encontraron fuentes documentales que aclararan el nivel de especificidad apropiado para las tarjetas en el tablero con respecto al TEP, ya sea, por historias de usuario (no épicas por supuesto) o por tareas.

Cuando se decidió especificar tareas en lugar de historias, entonces se ocupó una fórmula para asignar los TEP iniciales, resultado de multiplicar 1.5 por el número de personas involucradas en la fase correspondiente (siguiendo las recomendaciones de Kniberg y Skarin, 2010), considerando que los TEP pueden irse ajustando a lo largo del proyecto y adaptando a las circunstancias propias del desarrollo, como el surgimiento de imprevistos, el no tener información completa y la atención de requerimientos urgentes.

Definición de las clases de servicio. Una vez que los tableros tenían especificadas las columnas de manera que cualquiera podía identificar su trabajo en una o más de ellas, que en las tarjetas se podía leer claramente su valor y se entendía el trabajo que implicaba, y especificados los TEP para iniciar el proyecto, el siguiente paso fue clasificar las tarjetas por clases de servicio:

1. Se identificaron diversos criterios que determinarían la prioridad de las tareas y los tipos de servicio:
   • Fecha de entrega
   • Características del proyecto / cliente
   • Complejidad de la tarea
   • Seriación de las tareas
2. A cada tarjeta se le asignó una etiqueta de color para identificar visualmente su jerarquía. Para cada tablero, dependiendo el tipo de proyecto, se implementaron diferentes clases de servicio, como son:
   • Tareas normales
   • Tareas con fecha de entrega
   • Tareas de soporte/servicio
3. También se identificaron tres estados para cualquiera de las tarjetas:
   • Bloqueado
   • En corrección
   • Cancelado
4. Además se establecieron tres estados para los tableros generales (que identifican todos los proyectos) :
   • Pendiente
   • En proceso
   • Concluido

Especificación de las políticas para operar la metodología Kanban. Otro aspecto importante es la especificación de políticas al inicio de cada proyecto. En principio, las políticas simplemente se explicitaron de acuerdo a la metodología de trabajo que se sigue para cada proyecto y atendiendo a la normatividad institucional para la generación de productos y servicios, sin embargo, es importante tener ejercicios de retroalimentación que aclaren el seguimiento de políticas, o bien, la necesidad de cambio de éstas para un mejor flujo de trabajo.

Dentro de las políticas generales se identifican las siguientes:

• Las fases de cada de proyecto son definidas entre todos los involucrados.
• Respetar el orden jerárquico y secuencial de las tareas, al actualizar el tablero.
• Asegurar los criterios de movilidad de personal en cada una de las fases del proyecto.
• Establecer medidas de aseguramiento de la responsabilidad de cada uno de los involucrados en el proyecto.
• Asegurar la consistencia de cada uno de los tableros específicos en relación a tableros generales de control.

Adaptaciones a la metodología Kanban

Durante el proceso de apropiación de la metodología Kanban, se realizaron adaptaciones que consistieron principalmente en los siguientes aspectos:

Elaboración de Tableros de Kanban:

• Establecer tableros generales para abarcar diferentes tipos de proyectos basados en historias de usuario (tableros verticales, leídos de abajo hacia arriba respecto de los estados).
• Establecer tableros específicos con base en tareas a partir de las historias de usuario (tableros horizontales, leídos de izquierda a derecha respecto de las fases).
• Definir una dinámica de seguimiento a un nuevo requerimiento o historia de usuario en el tablero general para su desglose en los tableros específicos.
• Con base en las características del proyecto, se establecen sus fases en el tablero.

Especificación de las TEP en el tablero:

• Se toman como base para el cálculo las tareas a desarrollar por cada perfil de los equipos
• Inicialmente, se calcula con base en el número de integrantes o perfiles que intervienen en la fase o etapa y se multiplica por 1.5.

Información incluida en los tableros:

• En el tablero general se debe incluir el tipo de proyecto, las clases de servicio y los involucrados en cada proyecto, desglosando el tipo de responsabilidad asignada a cada participante dentro de cada proyecto.

Información incluida en las tarjetas:

• Nombre de los perfiles involucrados en la tarea para tener claro el número de recursos necesarios en el desarrollo de esas actividades.
• Fechas de entrada y salida en el tablero general (cambio de estado) y fecha de entrada y salida en el tablero específico (tránsito entre fases).

Otra adaptación de la metodología, en relación a la forma de trabajo, fue la elaboración de un tipo de tablero Kanban vertical que se usa para visualizar todos los tipos de servicio de soporte y al mismo tiempo cuántos se están realizando. En la primera columna, en lugar del backlog, están los nombres de los tipos de servicio de soporte (cada uno con su límite de TEP) y las siguientes tres columnas muestran las fases de atención: solicitud aceptada, en proceso y terminado.

Conclusiones

En definitiva, antes de trabajar con Lean-Agile y Kanban no se podía calcular por anticipado la cantidad de transiciones que los grupos de trabajo tenían que realizar a diario, dados los traslapes entre proyectos, servicios de soporte y análisis de nuevos requerimientos, ahora es posible reducir la cantidad de transiciones en una semana lo que significa una disminución de re-trabajo significativo.
Una beneficio importante es la alta visualización de todas las etapas y/o procesos en los que consiste un proyecto de educación a distancia y el desglose de las tareas, así como la posibilidad de ir analizando en cualquier momento la situación real del proyecto a través de los tableros, de los diagramas de flujo acumulado y de los diagramas de control. Ahora se cuenta con documentación ligera sobre el desarrollo de los proyectos, misma que agiliza tanto la incorporación de personal cuando se requiera, como la aceptación de cambios funcionales en cualquier momento.

En particular, Lean-Agile y Kanban ha proporcionado elementos suficientes para establecer un proceso de mejora continua, el cual dista mucho de ser trivial, principalmente, por la naturaleza multidisciplinaria de los procesos de producción de la educación a distancia.

No obstante los beneficios reportados, aún faltan aspectos por mejorar y aplicar, en la transición del proceso de apropiación al establecimiento de una planeación ágil para los nuevos proyectos.

El reto de homogenizar el conocimiento que significó el entrenamiento para la apropiación de las metodologías Lean-Agile y Kanban, ha valido la pena tanto en el ámbito profesional como en el personal, pues la parte filosófica de trabajo ha logrado cambiar actitudes y motivaciones en todos los niveles jerárquicos del CATED.