Scrum y Kanban ayudando al Help Desk

Scrum, Kanban y una gran cantidad de procesos ágiles menos conocidos han asumido (y mejorado) el desarrollo de software recientemente. ¿Qué partes de Scrum y Kanban pueden ser beneficiosas para un equipo de soporte técnico? 

Veamos nueve prácticas ágiles que pueden ayudar.

1.- Retrospectivas

Una retrospectiva es una reunión para que todos los miembros del equipo analicen cómo podrían haber mejorado los resultados desde la reunión anterior. Por lo general, se debe realizar una retrospectiva cada una o dos semanas. No recomendaría hacerlo con menos frecuencia, ya que eso hace que la reunión sea más larga y también más difícil para que todos recuerden todo lo que quieren plantear. Además, ¡reuniones más frecuentes significan oportunidades más frecuentes para mejorar!

Este es el mejor lugar para comenzar la adopción de procesos ágiles, ya que proporciona un lugar donde las personas pueden discutir cómo funcionan (o no) esas prácticas y proponer cambios. Ejecutar buenas retrospectivas es complicado. Sin embargo, aquí hay algunos consejos para comenzar:

• Abra escribiendo sugerencias del equipo sobre las cosas que salieron bien y no tan bien desde la última reunión. Durante esta fase, trate de no discutir demasiado las cosas y solo escríbalas.
• Luego, deje que el equipo analice cómo podrían abordar esas inquietudes en las próximas semanas.
• Si hay algo que el equipo necesita fuera del equipo, asegúrese de que se registre y se actúe lo antes posible. Si espera que trabajen para mejorar sus procesos, debe demostrar que usted, como gerente, resolverá los problemas fuera de su control de inmediato.
• Asegúrese de que todos estén abiertos y contribuyan, ya que esta debería ser una oportunidad para que el equipo colabore en la mejora de sus procesos, no para que un gerente o una personalidad fuerte domine la discusión.

2.- Haciendo visible el trabajo

Con demasiada frecuencia, el trabajo continúa después de que se responde la llamada (o el correo electrónico). Hacer que ese trabajo sea visible es una excelente práctica de los procesos ágiles que permite a los externos tener una visión del equipo y comprender cuánto está sucediendo (incluso si todo parece tranquilo en la superficie).

Aquí es donde pueden entrar en juego los tableros Kanban o Scrum. Recomiendo configurar un tablero Kanban para cualquier proyecto que considere lo suficientemente largo como para ponerlo. Aquí tienes un par de opciones, ya sea que uses una pizarra física en la pared o una electrónica en línea. Si todos están ubicados en la misma sala, recomendaría una pizarra física, ya que es fácil ver todo de una sola vez, y cualquier persona del resto de la empresa que ingrese a la sala también puede verlo fácilmente. Si no estáis todos juntos, uno online funcionará mejor ( Trello es un buen lugar para empezar gratis).

Crear un tablero Kanban es tan simple como crear algunas listas una al lado de la otra con títulos como «Por hacer», «En proceso» y «Terminado». Luego puede comenzar a agregar tareas, a menudo como fichas con una chincheta (si usa una pizarra física de corcho) o notas autoadhesivas tipo post-it, a las listas. La primera tarjeta de cada lista es la de mayor prioridad, en la que se trabajará a continuación, y así sucesivamente en la lista hasta la de menor prioridad. Cuando comience el trabajo en algo, arrástrelo a «Haciendo», luego a «Terminado» cuando haya terminado. Tener imágenes o avatares para los miembros del equipo para que pueda pegarlos en la tarjeta en la que están trabajando es una buena manera de mostrar quién está trabajando en qué proyectos.

Extra opcional: muestre su proceso completo: en lugar de tener una sola lista de «Hacer», divídalo en los pasos de su proceso, como «Investigar», «Implementar», «Esperar al desarrollador», «Validar», etc. Esto le da una visión de cómo viaja el trabajo (y se atasca) en diferentes partes de su proceso.

Crear un tablero Kanban simple para los proyectos de su equipo puede ser una excelente manera de obtener información rápida sobre cuánto trabajo tiene el equipo en cualquier momento. Es posible que se sorprenda de cuántas tareas están en curso al mismo tiempo. Y si no es así, puede ser una excelente manera de señalarlo a otros que no ven cuánto está tratando de hacer su equipo al mismo tiempo.

3.- Administrar las interfaces para el equipo

Una idea que me gusta de Scrum es cómo se especifican cuidadosamente las interfaces con el equipo, en lugar de cómo opera el equipo en sí mismo (que ellos mismos deben definir).

Es difícil encontrar opciones para todos los equipos posibles aquí. Mire las formas en que el trabajo puede llegar a su equipo y decida si está satisfecho con la forma en que los miembros del equipo asignan cosas en las que trabajar. ¿Debe pasar por otro paso primero? ¿Cuál es la interfaz en su equipo? ¿Y qué se espera que entreguen en el otro extremo?

Para un Help Desk, esto puede significar que una persona sea el único punto de contacto para las tareas y proyectos entrantes. En realidad, otros miembros del equipo pueden crear inicialmente la tarea como resultado de una llamada, pero luego esta persona de contacto decide cómo priorizar el trabajo y lo coloca en la lista de tareas pendientes con la prioridad adecuada. O si es simple, posiblemente lo hagan allí mismo. ¿Qué funcionaría mejor para tu equipo?

4.- Programación basada en extracción

En lugar de un proceso que empuja el trabajo a las personas, los procesos ágiles y Kanban en particular adoptan un sistema pull. De esta manera, a nadie (ni a ningún equipo) se le asigna trabajo hasta que lo incluyen en su proceso. Como tienen capacidad para algo, deciden asumirlo y tirarlo al proceso.

Esta es una práctica valiosa, ya que permite que los equipos y los miembros del equipo trabajen a un ritmo que pueden mantener en lugar de estar constantemente estresados por tener innumerables cosas en su lista de tareas pendientes que nunca podrán hacer. También permite que otros ayuden realizando tareas ellos mismos que, de otro modo, se habrían asignado a otra persona. Esto comparte conocimientos y habilidades entre el equipo y hace que el trabajo termine antes de lo que hubiera sido el caso de otra manera.

Si ha creado su tablero Kanban, el equipo solo se compromete con algo cuando pasa a «Hacer» desde «To Do». Esto debería dejar en claro lo que se ha iniciado y lo que aún queda por trabajar. Si alguien realmente quiere que el equipo actúe en algo de la lista de tareas pendientes, puede determinar si algo en la lista de tareas pendientes debe volver a la lista de tareas pendientes temporalmente.

5.- Swarming

Algo que me tomó un tiempo entender, pero que fue una gran revelación cuando lo asimilé fue que los equipos ágiles operan como equipos en lugar de grupos de individuos. Anteriormente, mi equipo tenía el trabajo asignado a individuos y si una persona se atascaba, los demás podían «echar una mano», pero en realidad no concentraban toda su energía en el trabajo de la otra persona.

Después del cambio, todo el equipo fue responsable de entregar cualquier trabajo en progreso antes de sacar más trabajo de las listas de «cosas por hacer». Si alguien podía ayudar a alguien más, siempre lo hacían. El trabajo comenzó a hacerse más rápido, la moral del equipo mejoró a medida que las personas colaboraban en las tareas durante todo el día y el conocimiento se compartía constantemente entre el equipo.

Esto puede ser un cambio de mentalidad importante, y no todas las tareas se prestan para que varias personas trabajen en ellas. Sin embargo, vale la pena pensar seriamente dónde puede aplicar el enjambre en sus proyectos para compartir conocimientos y habilidades, así como entregar el trabajo más rápido.

6.- Límites de trabajo en curso

Los límites WIP son un concepto de Kanban que dice que debe limitar la cantidad de trabajo en progreso en un momento dado y evitar activamente generar más trabajo si está en el límite acordado. Por lo general, puede establecer esto en el número de miembros del equipo (quizás menos uno para su ‘hombre/mujer de referencia’), o menos si a menudo tiene más de una persona en cada tarea.

La idea aquí es que una persona que trabaje en dos tareas de una semana al mismo tiempo las entregará al final de dos semanas (más o menos). Sin embargo, si trabajan en uno y luego en el otro, entregan el primero después de una semana y el segundo después de la segunda semana. También pueden cambiar de dirección después de la primera semana si surge algo más importante y retrasar la segunda tarea. En el escenario original, podrían cambiar de rumbo después de una semana, pero dejarían dos tareas a la mitad. Dado que su equipo puede tener más de una tarea por miembro en este momento, implementar un límite WIP para apuntar sería un experimento interesante. Una vez que se alcanza, puede discutir en su retrospectiva si ha ayudado o no. Si está utilizando Trello, puede obtener el encendido Free Agile Tools para establecer límites WIP en sus tableros.

Un ajuste al límite WIP para los equipos de la mesa de ayuda es dejar margen para lo inesperado. Por ejemplo, para su equipo de seis, puede tener un límite de trabajo en curso de dos para el trabajo planificado y un límite de trabajo en curso de cuatro para el trabajo no planificado que debe acelerarse.

7.- Talla de camiseta

Algunos equipos están contentos de tener tareas sin ninguna estimación de su tamaño. Otros quieren cuantificar el trabajo ya que este difiere y algunos son más grandes que otros. Una práctica simple de los equipos de Scrum y Kanban es usar el «tallaje de camiseta», en el que las tareas tienen un tamaño Pequeño/ Mediano/ Grande. 

Cualquier cosa más grande que eso a menudo se puede registrar como un proyecto y dividirse en múltiples subtareas del tamaño de una camiseta.

El uso de este método evita centrarse demasiado en la asignación de escalas de tiempo o fechas para el trabajo, lo que a menudo conduce a una presión improductiva para entregar el trabajo en un cierto período de tiempo (en lugar de un cierto nivel de calidad). Sin embargo, puede usarse para tener una idea de cuánto trabajo está pendiente si es necesario, y puede ser útil para que el equipo comprenda su próximo trabajo.

8.- Reuniones diarias (Daily), NO actualizaciones de estado diarias

Esto es algo en lo que muchos equipos ágiles todavía se equivocan. La idea de una reunión diaria de pie es tan omnipresente ahora, sin embargo, hay una mejora que vale la pena considerar.

Las reuniones diarias con demasiada frecuencia se convierten en una actualización de estado diaria en la que todos informan al gerente en la sala. 

Pregúntese, ¿tendría sentido esta reunión si el gerente no estuviera allí? De lo contrario, tiene una actualización de estado diaria y probablemente esté perdiendo la mayor parte del tiempo del equipo. En cambio, si se enfoca en el trabajo que el equipo tiene ese día, recorriendo la lista de «Hacer» del tablero Kanban, puede discutir cómo moverán esas tareas ese día. 

Cada tarea generalmente tiene a alguien que la dirige y puede decir dónde se encuentran y si necesitan ayuda hoy. Otros pueden ofrecer ayuda si se les pide, o posiblemente si solo ven una manera en que pueden ayudar a que algo se «Termine» antes que sin su ayuda.

Una alternativa podría ser mirar los proyectos destacados y preguntar «¿Qué nos impide mover esto a «Terminado» hoy?» Luego vea cómo el equipo puede resolver eso ese día. Si alguien está hablando de comenzar una nueva tarjeta, verifique primero que no haya nada que pueda hacer para que algo que está actualmente en progreso esté más cerca de terminar. Esto puede ser un cambio de mentalidad para las personas al principio, pero me doy cuenta de que a menudo aprenden bastante rápido.

9.- Mejora continua

Una de las mejores partes de los procesos ágiles es el enfoque en tratar de mejorar continuamente el proceso. Esto se relaciona con el primer punto sobre las retrospectivas, pero vale la pena repetirlo aquí. Si decide adoptar alguna de estas prácticas, espero que usted y su equipo adopten la idea de la mejora continua como uno de sus valores fundamentales. La idea no debe ser adoptar un nuevo proceso que sea mejor que el actual, sino adoptar un enfoque de mejora continua que pueda inspirarse en varios lugares y conducir a un mejor equipo la próxima semana, el próximo mes y el próximo año