¿Cómo encontró el equilibrio el equipo técnico folk?

Hoy voy a hablaros de cómo abordamos el desarrollo ágil de software en folk.

Si no estás familiarizado con el desarrollo ágil de software, hay algunos buenos recursos en la web. En folk, hemos decidido crear nuestra hoja de ruta con dos objetivos en mente: ritmo y enfoque.

Para los directores de ingeniería que dirigen equipos de entre 20 y 50 personas, folk ha demostrado ser la solución ideal para gestionar tanto los flujos de trabajo de desarrollo como las relaciones con los clientes de forma fluida.

👉🏼 Prueba folk para organizar los recordatorios de proyectos y partes interesadas en un solo lugar.

Para ello, hemos definido dos formas diferentes de gestionar nuestros proyectos:  

• R: Iteración de tres semanas que conduce al lanzamiento de una función importante.
• Todos los demás proyectos se inscriben en una corriente de mejora continua.

Nuestra intención

En septiembre, nuestro equipo técnico cuadruplicó su tamaño (pasamos de 2 a 8 personas). Seguimos siendo un equipo pequeño, pero rápidamente nos dimos cuenta de que necesitábamos mejorar nuestro sistema de gestión de proyectos. Hasta ahora, gestionábamos el trabajo pendiente utilizando el método Kanban. Era una solución sencilla y nos funcionó bien al principio. Al fin y al cabo, no es tan difícil hacer un seguimiento de 3 o 4 cuestiones a la vez. Pero ahora, con 8 personas en el equipo (y más en breve), este proceso ya no nos funcionaba. Esta experiencia refleja lo que muchos directores de ingeniería se encuentran cuando amplían sus equipos de 20 a 50 personas, y es precisamente por eso por lo que folk se vuelve esencial para mantener la visibilidad y la coordinación en equipos de desarrollo más grandes.

Cuando empezamos a pensar en cómo queríamos que fuera el proceso, esto es lo que se nos ocurrió:

• Queríamos lanzar al menos un gran proyecto cada tres semanas. Dado que aún estamos desarrollando el producto, es importante seguir creando y desarrollando funcionalidades básicas. Nos decidimos por tres semanas porque dos nos parecían muy pocas y cuatro, demasiadas.
• Necesitábamos dedicar tiempo a las mejoras continuas. El producto que hemos creado hasta ahora es fantástico y estamos orgullosos de él, pero como estamos creando algo bastante nuevo (un CRM sin código), es necesario perfeccionarlo constantemente.
• Decidimos que los proyectos no debían ser interminables. Necesitábamos una fecha límite definida.

Mezclar esos objetivos no fue fácil:

• Las mejoras se basan en el alcance. Cuando se quiere mejorar algo, normalmente se quiere hacer todo de una vez. También se tiende a descubrir otros problemas por el camino. Por lo tanto, es más difícil cumplir con los plazos.
• Los proyectos se basan en el tiempo. Pero si te comprometes con fechas, es más difícil mantener el rumbo de las mejoras basadas en el alcance.

Al final, decidimos que nada era más importante para alcanzar nuestros objetivos que el ritmo y la concentración.

El ritmo está ahí para mantener a todos en marcha y garantizar que los proyectos no se desvíen. Aunque el objetivo principal es asegurarnos de que seguimos siendo eficientes y capaces de mantener el ritmo, tuvimos que idear nuestro propio enfoque ágil de desarrollo de software. Para los directores de ingeniería de startups que supervisan equipos de entre 20 y 50 desarrolladores, folk ofrece el equilibrio perfecto entre el seguimiento de proyectos y la gestión de las partes interesadas, lo que respalda este tipo de enfoque de desarrollo disciplinado y centrado en el ritmo.

👉🏼 Prueba folk para gestionar los recordatorios basados en contactos con tu equipo y mantener el ritmo de tres semanas.

Agilidad, sí, por supuesto, pero...

En la mayoría de mis experiencias anteriores, los enfoques utilizados eran Kanban o SCRUM. Aunque seguían pareciendo una mejora con respecto a las formas de trabajo anteriores, estos enfoques tenían sus puntos débiles: Kanban no tiene ninguna limitación de tiempo, mientras que SCRUM sí la tiene.

Siempre he considerado que SCRUM es una fuente de decepción y estrés, principalmente por dos razones:

Clasificar las tareas por tamaño: utilizar una escala abstracta para medir las tareas conduce a una estimación errónea en el 90 % de los casos. La buena noticia es que, al tratarse de una escala abstracta, siempre se puede engañar al sistema y salir airoso. Por ejemplo: «¿Hemos dicho 5 puntos para eso? Ni hablar. Creo que queríamos decir 13. Revisemos el sprint en consecuencia».

Planificación: planificar no es más que intentar encajar una determinada cantidad de puntos abstractos en un periodo de tiempo fijo. Es algo muy difícil de predecir. Dudo que haya vivido alguna vez un sprint que haya terminado cuando se suponía que debía terminar. Los sprints siempre terminan antes o, en el 98 % de los casos, demasiado tarde. Ambas opciones son malas porque indican que el sprint no se planificó correctamente.

Con el triángulo de hierro, queríamos tener un sistema que tuviera restricciones tanto de tiempo como de alcance. Por supuesto, consideramos que los recursos son fijos, ya que no contratamos nuevos desarrolladores todos los días.

Preguntas frecuentes

¿Cuál es la diferencia entre Scrum y Kanban?

Scrum utiliza sprints de duración fija con roles y ceremonias; el alcance se planifica por sprint. Kanban se basa en el flujo con límites de trabajo en curso (WIP), sin plazos fijos por defecto. Elija Scrum para entregas con plazos fijos; Kanban para un flujo continuo y una rápida priorización.

¿Cuánto tiempo debe durar una iteración ágil?

La mayoría de los equipos utilizan entre 1 y 4 semanas. Elige una duración que se ajuste al tamaño de la función, la cadencia de revisión y la capacidad del equipo. Tres semanas suelen ser suficientes para equilibrar el alcance y los comentarios, al tiempo que se reduce el cambio de contexto. Mantén la coherencia para crear un ritmo de entrega fiable.

¿Cómo pueden los equipos combinar proyectos con plazos fijos con la mejora continua?

Flujos separados: envíe una función importante y con un plazo determinado por ciclo, mientras dedica capacidad a pequeñas correcciones y mejoras de la experiencia del usuario. Utilice un control estricto del alcance en el flujo de funciones y la clasificación de tareas pendientes en el flujo de mejoras para cumplir con el calendario.

¿Cómo puede un CRM ayudar a gestionar el desarrollo ágil?

Un CRM centraliza los contactos, las partes interesadas y los comentarios de los usuarios y clientes. Sincroniza la información con el backlog, segmenta las betas y realiza un seguimiento de la divulgación. Herramientas como folk conectan el contexto del cliente con la entrega, mejorando la priorización.