Para que los equipos de ingeniería vayan como la seda, deben organizarse de forma autónoma. Son equipos con funciones y responsabilidades claras y que se comprometen a ejecutar los proyectos siguiendo un plan bien diseñado.
El año pasado creamos un nuevo equipo llamado Micros Scale que se centra en crear la plataforma como servicio (PaaS) interna de Atlassian, nuestra plataforma de experiencia para desarrolladores. Como nuestro trabajo tiene un alcance fijo y plazos claros, nos comprometimos a completar más trabajo incremental, centrarnos más, orientarnos más a los objetivos y ser más proactivos.
Sin embargo, anteriormente nuestro equipo recibía muchos trabajos operativos ad hoc que nos impedían planificar los sprints correctamente. Se asignó un mínimo del 55 % de la capacidad del equipo a las rotaciones de actividades de mantenimiento esenciales. Por todo ello, kanban se convirtió en la metodología más adecuada para nosotros.
Cabe señalar que, según el modelo de Tuckman, el equipo Micros Scale estaba en la fase de formación y había algunas áreas de mejora, como la planificación de la capacidad, la planificación de sprints, el establecimiento de objetivos, la reflexión del equipo, la preparación y la elaboración de historias, la estimación, el desglose de proyectos, etc.
¿Qué metodología ágil era la adecuada para nosotros?
Micros Scale tiene dos proyectos importantes que son muy complejos y tienen una fecha límite anunciada públicamente a nuestros clientes. Por ello, entregar más rápido es crucial. Necesitábamos contar con un enfoque de entrega de confianza y queríamos trabajar en nuestra planificación como profesionales ágiles. Queríamos que nuestro equipo se organizara de forma autónoma, lograra objetivos comunes y tuviera una perspectiva empírica.
Reevaluamos nuestro enfoque ágil haciéndonos las siguientes preguntas:
- ¿Es posible fijar una meta en cada iteración para cumplir un objetivo con un tema específico?
- ¿Podemos comprometernos con el alcance de las entregas durante una o dos semanas?
- ¿Podemos aportar más detalles y fijar los requisitos en los que tenemos que trabajar?
- ¿La frecuencia de las solicitudes ad hoc para cambiar la prioridad de las tareas es baja? ¿Es menos probable que tengamos cambios drásticos?
- Nuestro equipo es nuevo. ¿Carece de experiencia en procesos ágiles?
Como las respuestas a estas preguntas fueron afirmativas, nos dimos cuenta de que scrum era la mejor metodología ágil para nuestro equipo. Estos son otros puntos en los que basamos nuestra decisión:
| | | | |
|---|---|---|---|
| Metodología ágil | ¿De qué se trata? | ¿Nos está ayudando? | ¿Por qué? |
| Scrum | Scrum consiste en establecer una hoja de ruta clara y en asignar prioridades a las tareas, mientras que kanban consiste en visualizar el trabajo, que se presenta al equipo de forma ad hoc. | Sí | Tenemos un backlog claro y predefinido que hay que perfeccionar y clasificar según su prioridad. Nuestro trabajo es predecible, a diferencia del de nuestro equipo anterior, que estaba repleto de sorpresas y solicitudes de prioridad alta. |
| Las historias no deberían cambiarse a mitad del sprint. | Sí | Podemos adoptar un enfoque más flexible; en este caso, scrumban (un híbrido de scrum y kanban). | |
| Scrum es más fácil de adoptar para los equipos ágiles que aún están aprendiendo a liderar funciones. Scrum es más prescriptivo, con rituales y plazos que actúan como puntos de apoyo. | Sí | Tenemos un nuevo equipo con nuevos miembros, aún en la fase de formación y lluvia de ideas, así que tener scrum nos ayuda a ganar experiencia. Lee un artículo sobre el modelo de Tuckman. | |
| Kanban | Limitar el trabajo en curso y centrarse en reducir la duración del ciclo de los proyectos. El caso práctico es cuando tu equipo no tiene un límite de tiempo para trabajar ni se ha comprometido a un cronograma específico. La solicitud llega al equipo y se tramita lo antes posible (como el SLA que tienen los centros de asistencia). | No | Otros equipos dependen de nosotros, por lo que necesitamos plazos estimados para ayudar a los demás a planificar en consecuencia. Algunos de nuestros compromisos se anuncian públicamente a los clientes de Atlassian, por lo que debemos planificar con cuidado. No tenemos muchas solicitudes a corto plazo, como un centro de asistencia. |
| Ideal para los equipos que reciben muchas solicitudes operativas que varían en cuanto a prioridad y tamaño. | Sí | No tenemos una gran carga de actividades de mantenimiento esenciales y el flujo de trabajo lo gestiona una persona en rotación. Podemos organizar esa función con kanban si queremos. |
Adoptamos scrum
Soy perfectamente consciente de que actuar como "director de orquesta" es una de las principales funciones de los responsables de ingeniería, además de ser punto de conexión, brújula y orientador. Por lo tanto, tuve que desarrollar mis habilidades de directora de orquesta. Así es como lo logré:
Profundizando en la metodología ágil
Los recursos de aprendizaje internos de Atlassian me ayudaron a aumentar mis habilidades en cuanto a prácticas ágiles. Hice cursos detallados de metodología ágil y consulté a un orientador de agilidad. Me entrevisté con otros responsables de ingeniería para conocer su experiencia en otras organizaciones y equipos.
Usando el marco DACI
Utilizamos el marco de toma de decisiones DACI, que son las siglas de Driver (Impulsor), Approver (Aprobador), Contributors (Contribuidores) e Informed (Destinatarios de la información), para tomar decisiones eficaces en grupo. Expliqué a mi equipo la propuesta de cambio al marco DACI para asegurarme de que contaba con su opinión, su aceptación y su apoyo.
Usando una plantilla de sprint
Se me ocurrió un proceso para gestionar nuestros sprints y creé una plantilla para cada sprint que nos ayudara a planificarlos de forma más razonable. La plantilla de planificación de sprint incluía:
- Cómo evaluar el sprint anterior para tener claro lo que hemos conseguido y celebrarlo.
- Cómo reflexionar de forma retrospectiva sobre el sprint anterior y aplicar lo que hayamos dilucidado al siguiente.
- ¿Cuáles son la cadencia, el nombre, las metas y los objetivos del sprint?
- ¿Cuántas historias nos comprometemos a ofrecer? ¿Cuál es el alcance del sprint?
- Cómo planificar la capacidad en función de la disponibilidad del equipo.
- ¿Qué actividades necesitamos llevar a cabo a mitad del sprint para estar completamente preparados para el próximo?
- Cómo escribir historias, determinar los requisitos y encontrar una solución para abordarlos.
- Cómo hacer un seguimiento del estado de las historias con las que nos comprometimos y qué hacer con las historias inconclusas.
También tenemos un estupendo tutorial sobre cómo hacer sprints en Jira Software.
Valió la pena cambiar a scrum
Estas son las mejoras que hemos conseguido al cambiar a scrum:
Mayor velocidad
En la metodología ágil, uno de los factores para medir la productividad de un equipo es la velocidad, que es la cantidad media de trabajo que un equipo de scrum realiza durante un sprint. Usamos una gráfica de velocidad para entender con qué se comprometió nuestro equipo y lo que se cumplió. En la tabla de velocidad de abajo, la columna gris muestra el número de puntos de historia con los que el equipo se comprometió en función de su capacidad. Lo comparamos con la columna azul, que es el número de puntos de historia que consiguieron. El equipo puede usar esta información para ajustar las predicciones de futuros sprints.
Identificamos los riesgos a tiempo
Ser capaz de identificar los riesgos de forma temprana y proponer una solución es la clave del éxito de los proyectos.
Al definir los objetivos y los temas del sprint, elegimos historias cohesionadas para lograr los objetivos. En las sesiones de mitad del sprint, nuestro equipo limpió, mejoró y elaboró historias. Durante la elaboración, nos preguntamos:
- ¿Qué hay que hacer?
- ¿Por qué lo hacemos?
- ¿Qué valor empresarial podría aportar?
Esto ayudó a nuestros ingenieros a identificar las dependencias y priorizar los tickets de mayor impacto para eliminar obstáculos. También nos llevó a cambiar la forma en que trabajábamos y a centrarnos mejor en cada proyecto.
Celebramos los lanzamientos
La planificación de la capacidad y el establecimiento de objetivos nos proporcionaron una motivación significativa y el desafío de ser transparentes en cuanto a nuestros compromisos. Hemos lanzado correctamente una fase crucial del particionamiento de cuentas PaaS de Atlassian. También estamos a punto de entregar la primera fase de nuestro proyecto de residencia de datos para cubrir más regiones de AWS con fines de fiabilidad, resistencia y cumplimiento.
Pasamos de formarnos a consolidarnos
Como he mencionado anteriormente, el equipo Micros Scale es relativamente nuevo y tiende a estar en la fase de formación del modelo de Tuckman.
Definir un objetivo unificado para el equipo inspiró a todos a coordinarse y apoyarse unos a otros para lograr los objetivos y aumentar la motivación. Tuvimos fallos, reflexionamos, aprendimos y mejoramos. Después de tres meses y medio, contratamos un 50 % más de personal para Micros Scale, y me complace decir que sigo evaluándolo como equipo que se está consolidando.
Mejoramos la comunicación
Tener un plan y esforzarnos por cumplirlo durante cada sprint nos aportó una mayor visibilidad sobre lo que teníamos previsto hacer en todo el equipo y nos permitió coordinarnos. Además, a los responsables de ingeniería y las partes interesadas les resulta mucho más fácil hacer un seguimiento de los impedimentos y del progreso de los proyectos.
Cómo elegir tu metodología ágil
- No dudes en evaluar tus procesos cuando detectes un problema. Piensa en las personas, los procesos y las herramientas desde una perspectiva ágil.
- Evalúa el proyecto y las responsabilidades de tu equipo para encontrar los métodos ágiles que mejor se adapten a él. Consulta nuestra página de comparación de kanban y scrum para obtener más información sobre estos métodos.
- Si decides pasarte a scrum, te sugiero que utilices un tablero de scrum de Jira o que crees una plantilla en Confluence o en tu herramienta favorita.
Para cada sprint, crea una página de planificación que te permita revisar y reflexionar sobre el último sprint y planificar el siguiente, en función de la capacidad del equipo y el objetivo del sprint. Esta es mi plantilla personal de Confluence:
Esta es mi plantilla de planificación de la capacidad, que está incluida en mi plantilla general de scrum:
Aquí tienes también mi plantilla de objetivos y alcance del sprint:
Para la mitad del sprint, es útil tener otra página que permita hacer un seguimiento del rendimiento del equipo durante la semana anterior, las historias que hay que pasar al siguiente sprint teniendo en cuenta el progreso actual del sprint (lo que se llama "limpieza") y aportar detalles sobre las historias que se han limpiado (mejora de historias). Esta es mi plantilla de limpieza y mejora del backlog a mitad del sprint:
Cada equipo es diferente. Lo que nos funcionó a nosotros puede que no funcione para otros equipos. Puede que convenga utilizar scrum, kanban o una combinación de ambos, como scrumban y kanplan. Es fundamental evaluar las necesidades particulares de tu equipo y entender qué metodología funciona para ellos.
