Gestión Ágil de Equipos

Tradicionalmente, los equipos de desarrollo de software tienen una estructura jerárquica, con la fuerte presencia del jefe de proyecto y alto énfasis en la asignación de roles y especializaciones a personas, que solo se dedican a efectuar el trabajo de su rol o especialización. Este tipo de estructura restringe la interacción entre los miembros del equipo.

 La utilización de Kanban & Lean se orienta a generar equipos auto-organizados, en donde se alinea el alto empoderamiento con el alineamiento de objetivos comunes: alta flexibilidad, sin tendencia al caos.

 La gestión tradicional de los equipos visualizados como recursos intercambiables y renovables, puede lograr resultados a cierto grado, pero tiene un alto costo humano, la motivación y autovaloración del desarrollador van mermando, generando un alto riesgo de abandono laboral y la incapacidad de generar equipos fuertemente de alto rendimiento, debido a que nunca se genera un equipo fuerte y permanente, sólo personas que vienen y van.

Un intento fallido

Alguna vez colaboré en un proyecto con una empresa dedicada a las microfinanzas. El proyecto era de gran relevancia, y mi jefe directo tenía una fuerte intención de utilizar metodologías ágiles. Al ingresar detecté en los miembros del equipo un alto interés en aprender y trabajar de forma diferente. Les expliqué que utilizaríamos Kanban, que con sus principios básicos era suficiente para partir e iniciar el proceso de mejora continua (Kaizen).

 Aprovechamos cuando el jefe de proyectos se fue de vacaciones para hacer un tablero Kanban. Nuestro tablero contaba con columnas para agrupar los elementos en Pila, Seleccionado, En curso, Listo para revisión, Revisión y Terminado. Iniciamos las Stand-Up Meeting diarias. Si bien existía una Gantt como guía de actividades y tiempos, debido a los altos cambios que sufría el proyecto, la stand-up meeting nos permitían organizarnos día a día balanceando las cargas de trabajo, aumentando el rendimiento de equipo y lo más importante, el ánimo y cohesión generado al ser los únicos trabajando en forma distinta al resto de los equipos.

 Al regresar nuestro jefe, en un inicio se interesó bastante en la forma de trabajar. Sin embargo, conforme pasó el tiempo el interés fue mermando, haciendo más hincapié en el seguimiento y re-planificación de la Gantt que poseía. El equipo no se juntaba si nuestro jefe no participaba o no invocaba, el tablero se dejó de actualizar y dejó de tener sentido utilizarlo.

Una nueva situación

En mi nuevo trabajo me comentaron inmediatamente la urgencia de estructurar y gestionar las actividades de cada desarrollador del equipo. El problema observado en primera instancia era la sobrecarga de tareas a cada desarrollador, sin tener una priorización clara o planificación.

Adicionalmente teníamos los siguientes impedimentos:

• Bajo nivel técnico del equipo.
• Restricción inicial de contratación de analista QA.
• Restricción inicial de contratación de nuevo desarrollador.

 Cuando el desarrollador estimaba e iniciaba una tarea, se le asignaban 2 o 3 tareas más (además de retrabajos), generando retrasos y grandes problemas de calidad ya que no estaba controlado el trabajo que tenía en curso. Esto generaba una gran frustración, sobrecarga emocional y estrés, además de existir un mal ambiente interno, generando diferencias técnicas y de calidad en el trabajo. Esto generaba una división y un quiebre interno (entre los que trabajaban bien, y los que no).

 Existía una fuerte desconfianza de parte del cliente sobre nuestros desarrollos, por carecer de calidad e innovación tecnológica. Si bien los desarrollos eran entregados en un corto tiempo, el tiempo destinado a hacer retrabajos era aproximadamente un 30% de tiempo involucrado en desarrollar, tiempo que era tomado de estimaciones de otros desarrollos, por lo cual el desarrollador debía efectuar esta corrección y además continuar con los desarrollos asignados y en el tiempo comprometido. En el equipo esto generaba una frustración, ya que se sentían “malos desarrolladores”.

Para abarcar y solucionar esta problemática, se definieron las siguientes metas:

1. Mejorar motivación y compromiso del equipo.
2. Optimizar el trabajo en curso (WIP).
3. Mejorar la calidad de los desarrollos.
4. Recuperar la confianza del cliente.

A continuación describo las acciones realizadas para lograr estas metas.

Visualización del trabajo

Lo primero que se realizó fue la creación del tablero Kanban (ver figura 1) para el equipo completo, con las siguientes columnas: Pila, Seleccionado, Análisis, Desarrollo (restricción de WIP, que puede tener el estado de “en progreso” o “listo”), Revisión y Terminado.

Tabla 1. Tablero Kanban

 La visualización del trabajo nos permitió inmediatamente detectar y visualizar en conjunto la carga de trabajo que tenía el equipo, y los tipos de tareas que existirían (mantenimientos, requerimiento nuevo, soporte, error, urgencia o documentación.). Fue el inicio del cambio. Adicionalmente, cuando creamos el tablero Kanban acordamos limitar el trabajo en curso y cumplirlo con total rigidez, no superando nunca el límite establecido.

Hitos y documentación

Se definieron ciertos criterios e hitos a cumplir en la transición de cada tarea en el tablero, que incluían la generación de documentación simple. A continuación la documentación que acordamos generar:

• Identificación de necesidades: Descripción de las necesidades de los clientes, validadas por un representante del cliente.
• Documento de evidencia de pruebas: Generación de pruebas unitarias y revisión completa del desarrollo, permitiendo detectar el máximo de problemas antes de pasar a producción.
• Documento de entrega: documento en donde el desarrollador enumera todos los fuentes creados o modificados y su descripción, permitiendo detectar posibles alteraciones al sistema por un desarrollo nuevo (impacto a la funcionalidad en producción).
• Setup: El documento de Setup está orientado a generar un instalable de uno o más desarrollos que se solicitan instalar en producción. Eso se debe a que cada desarrollador puede generar uno o más entregables, pero estos se pueden efectuar en una sola instalación.

 La utilización de estos documentos permitió al desarrollador y al equipo dedicar tiempo a la comprensión de los requerimientos y a la revisión más exhaustiva de los desarrollos terminados.

TimeBoxing

De un universo limitado de funcionalidades, se pueden escoger un subconjunto de estas que sean inmediatamente prioritarias y determinar una fecha de entrega fija. Se negocian las funcionalidades que podemos asegurar entregar para esa fecha. Esto elimina los retrasos de entrega, logrando entregar lo prioritario primero, ganando tiempo y permitiendo limitar y enfocar nuestro trabajo en curso.

 En nuestro caso, cada requerimiento recibido de parte del cliente contenía varios “sub-requerimientos” que eran específicamente las funcionalidades que el cliente requería, por lo tanto, lo que efectuamos es definir conjuntamente con el cliente las funcionalidades más prioritarias e indicar una fecha de entrega de ese subconjunto de funcionalidades priorizadas y una segunda fecha para entregar el resto de funcionalidades. Claramente, una vez entregado el primer subconjunto de funcionalidades existía una re-priorización, lo que nos permitía nuevamente re-planificar y adecuarnos a las necesidades y prioridades del cliente, permitiéndonos entregar las funcionalidades de mayor importancia a su negocio.

 Esto nos permitió directamente establecer un marco de mayor confianza con el cliente y priorizar nuestro trabajo, limitando nuestro trabajo en curso a lo priorizado, eliminando la sobrecarga laboral y canalizándola de una manera más estratégica.

Stand Up Meeting

Se iniciaron las reuniones diarias, en donde se presentaba la tarea asignada y el progreso que se tenía de esta, además de los impedimentos (qué estoy haciendo, qué haré y qué problemas he tenido) poco a poco se va “barriendo” el tablero de derecha a izquierda, iniciando por las tareas inconclusas, hasta las que se planean efectuar (para de iniciar, empieza a terminar).

Planificaciones semanales.

Con el tiempo las reuniones diarias se alargaban, planificando y analizando nuevos requerimientos recepcionados, por lo cual empezamos a efectuar planificaciones semanales de máximo 2 horas los lunes. Estas reuniones nos permitían generar metas concretas, específicas y priorizadas, lo que permitiría al equipo cuantificar sus avances y sentir que han logrado nuevas y mejores cosas. Esto nos permitía elegir e iniciar aquellas tareas más prioritarias según los objetivos definidos al iniciar la semana.

Entrega continua

La entrega continua de los desarrollos permitió inmediatamente alinearlos con las necesidades del cliente y recuperar su confianza. Definimos dos tipos de entregas:

 Entrega parcial: Nos permite informar al cliente de un avance en ambiente de revisión interna, pero con riesgos de mal funcionamiento o problemas de escritura en los desarrollos. El objetivo de una entrega parcial es montar un ambiente de integración, rectificación de un requerimiento completo o netamente para disminuir la angustia del cliente ante cortos tiempos de desarrollo.

 Entrega total: Es la entrega de una funcionalidad completa en los tiempos planificados, con documento de evidencia de funcionamiento y entrega. Esto quiere decir que con el visto bueno del cliente, se procedía a la instalación de esa funcionalidad o de otras.
 

Enseñanza para mejorar la calidad.

Basándonos en el Libro de Kanban de David J. Anderson, rescatamos la siguiente receta para permitir aumentar la calidad de nuestros desarrollos:

Aplicar desarrollo dirigido por pruebas (TDD). Pedirle a los desarrolladores que escriban pruebas unitarias y las automaticen para proporcionar pruebas de regresión automatizadas también tiene un efecto dramático. Esto aún no ha sido 100% implementado, ya que trabajar con TDD es duro y requiere un cambio mental fuerte.

 Realizar inspecciones de Código. Establecimos una práctica de revisión por terceros, lo cual nos ayudó a mejorar la calidad del código que generamos. Esto nos ha permitido detectar deficiencias de código, corregirlas y que todo el equipo aprenda para no replicarlas.

 Hacer análisis y diseño en colaboración. La calidad se incrementa cuando se les pide a los equipos que trabajen juntos para analizar problemas y soluciones de diseño. Decidimos analizar todos los requerimientos en conjunto (todo el equipo) identificando riesgos, dependencias y dudas, para luego definir ítems de trabajos (subconjunto de funcionalidades), que pueden ser priorizadas y paralelizadas. Esto permitió distribuir el trabajo en el equipo completo, balanceando la carga de trabajo, aumentando la comunicación en el equipo y disminuyendo la especialización, además de permitirnos compartir conocimiento y estrategias de implementación.

 Apoyarse en patrones de diseño. Aplicar patrones de diseño facilita y acelera el diseño, además de que ayuda a reducir errores.

 Utilizar herramientas modernas de desarrollo. Muchas de las herramientas modernas incluyen funciones para realizar un análisis estático y dinámico de código. No poseemos herramientas modernas de desarrollo, pero esta dentro de nuestro próximo objetivo.

Conclusiones

El uso de Kanban, sumado con conceptos de gestión ágil, nos ha permitido aumentar la calidad de nuestros desarrollos, permitiendo el retorno de confianza de nuestros clientes. Gracias a esto, uno de nuestros clientes recientemente nos evaluó como una de las empresas proveedoras Top Ten en confianza, calidad y responsabilidad.

 Por otra parte, el trabajar con una metodología ágil, limitar el trabajo en curso, definir hitos o explicitar el proceso, y llevar a cabo las reuniones definidas (stand-Up meeting, planificación semanal y análisis en conjunto) ha permitido al equipo conformar una identidad única en la empresa, mejorando su ánimo, motivación y empoderamiento, ya que se ha logrado con una simple guía y políticas puntuales, una auto-organización fuerte, entendida y compartida por todo el equipo. Los miembros del equipo no nos sentimos como recursos genéricos, sino como una fuente de mejora, innovación y orgullo por las metas conseguidas en conjunto: calidad de los desarrollos, optimización de nuestro trabajo, retorno de la confianza del cliente, y lo mejor, motivación y compromiso por parte del equipo.

 Los recursos no tienen capacidad de auto-organización, las personas sí.