Loading Likes...

En Habitissimo, como en cualquier empresa de tamaño medio-grande, tenemos varios equipos de desarrollo que afrontan diferentes verticales de negocio.

En nuestra empresa, cada equipo tiene libertad para elegir cómo trabaja: tenemos equipos trabajando con implementaciones de Scrum bastante avanzadas; tenemos equipos que experimentan con diferentes metodologías e incluso equipos entrando en el mundo de la Agilidad mediante Kanban. Esto puede chocar, pero va en la línea de la manera en que por ejemplo elegimos nuestras tecnologías: así como nuestro proyecto principal está desarrollado en PHP y Symfony, tenemos proyectos en Python, React, Kotlin, etc; nos gusta elegir la tecnología y metodología adecuada a cada necesidad.

Hoy os hablaré de mi equipo actual, Marketplace, desde mi punto de vista de Fullstack Developer. Trabajamos basándonos en  Scrum:

 

Trabajamos por Sprints

  • Duran 2 semanas y son consecutivos.
  • Nos esforzamos por marcar una “meta” singular en cada sprint, y la alineamos con el objetivo trimestral actual de la empresa (para nosotros, la relación negocio – tecnología es algo que nunca hay que descuidar).
  • Se identifican con letras y tras acabárnoslas todas, volvemos a empezar NON STOP.
  • Cada ronda de letras lleva asociada una temática para elegir títulos humanizados para el Sprint. Ahora estamos con platos de comida (Álbondigas, Bocata de Calamares … :P); pero también hicimos Ciudades Exóticas del Mundo, Flores… ya pilláis la tónica.

 

Experimentamos a menudo

  • Siempre estamos dispuestos a replantearnos nuestra forma de trabajar, por lo que a menudo probamos pequeños cambios de nuestros procesos y observamos si nos cortan las alas o nos molan de verdad. Por ejemplo, comenzamos a dividir desarrollos grandes en bloques más pequeños para poder estimar mejor, trabajar en paralelo en un mismo objetivo, etc; siguiendo el mítico dicho que tan bien se aplica al desarrollo: “Divide y vencerás”.

 

 

Nos reunimos en cada Sprint

  • Acuden todos los miembros del equipo: desarrolladores, PO y UX; pero no dejamos de reunirnos aunque falte alguien.

 

Daily

  • La mantenemos breve (15 min máximo)
  • La mantenemos lo menos técnica posible (debates técnico-filosóficos a parte please: son importantes pero no es el momento)
  • Nos centramos en pedir ayuda e informar de novedades que afecten al resto, más que como un simple reporte al PO.

 

Daily Tech

  • Disclaimer: no es un evento definido en SCRUM, por lo que lo defino aquí: es una reunión diaria entre los desarrolladores de diferentes equipos que se centra en visibilizar posibles conflictos, dependencias y fomentar la colaboración: algo así como una reunión horizontal.
  • Actualmente tiene la forma de un reporte asíncrono: un bot nos pregunta cada día por mensajería si tenemos que informar a otros equipo de algo, y luego se publica en un canal exclusivo. We live in the future.

 

Refinamentos (varios, según necesidad)

  • Estamos migrando de un formato fijo de un refinamiento por Sprint a refinamientos orgánicos: cuando UX/Producto tiene listo el diseño o idea para un desarrollo, nos reunimos 15 minutos para analizarlo con el equipo técnico. Stand-ups como manera de estirar las piernas y fomentar la circulación: os lo recomiendo.
  • Intentamos hacerlos al final del día, como algo más distendido.

 

 

Planning

  • La reunión más larga, donde se configura el nuevo Sprint y se abordan los refinamientos que por las circunstancias no se hayan podido realizar antes.
  • El PO nos explica las prioridades de ese Sprint.
  • Tratamos de trabajar en un máximo de 2 épicas con respecto a nuevos desarrollos, que deben ir alineados con los objetivos trimestrales de la empresa.
  • La duración aproximada recomendable es de 2h para sprints de 1 semana. Como los nuestros son de 2 semanas, nuestras plannings se alargan hasta las 4h.
  • Hemos notado que podemos reducir su duración si sacamos más provecho del resto de eventos de Scrum: no nos guardemos los problemas, y comentemos nuestras ideas lo antes posible!
  • Los desarrolladores usamos cartas para estimar las horas que llevaría realizar cada desarrollo sin influenciarnos. Son muy guays, incluso tenemos una carta de “infinito”.

 

Retrospectiva

  • Nos reunimos todo el equipo para comentar el Sprint que se está finalizando y buscar oportunidades de mejora.
  • Recientemente estamos focalizando en obtener acciones de mejora de cada retrospectiva y analizar su realización en la retro del siguiente sprint: está guay la terapia de grupo, pero también hay que comprometerse.
  • Nos conduce la retro con dinámicas de grupo divertidas un voluntario de otro grupo, que ejerce de Agile Coach.
  • Nuestro Agile Coach invitado en cada ocasión es tan amable de escribirnos un output de la reunión con las acciones acordadas, e incluso nos monta un evento del “Calendar” para acordarnos la semana siguiente de poner en práctica esas mejoras que nos harán la vida más fácil a todos.
  • Ponle hora, hora y media. Estamos pensando en acortarla por eficiencia.

 

Review

  • Como soy de decirlo todo, sin rodeos: actualmente no hacemos Reviews de Scrum.
  • La realidad es que tenemos muchos Stakeholders (personas que actúan como nuestros “clientes” y nos plantean necesidades para que nosotros las suplamos con desarrollos) por lo cual es un gran reto gestionar reuniones en las que puedan asistir todas las personas implicadas en nuestros sprints.
  • Estamos experimentando con un formato de “Level 10”  al que acudimos el equipo Scrum y un representante del área de negocio. El formato nos facilita el detectar acciones a realizar y evaluarlas en la siguiente reunión, y la estamos enfocando también a definir KPIs (objetivos) para nuestros equipo y recibir feedback de cómo están afectando nuestros desarrollos al negocio realmente.
  • No descartamos seguir buscando la manera de implantar las Reviews siguiendo lo que marca Scrum, pero siempre bajo la condición que no nos afecte demasiado negativamente como equipo a nuestra productividad.

 

  • Pero, todas las reuniones son para hablar de problemas y necesidades? No! también tenemos los Kudos!, de lo que ya hablaremos en un futuro en más en profundidad en otro post, pero que se centran en abrir un espacio en el que dar las gracias a todos aquellos compis que nos hacen la vida más fácil 😀 .

 

Cosas que vamos a implementar pronto

  • Estimación por puntos, en lugar de horas. La estimación por horas nos resulta artificial, porque en verdad lo que estamos estimando es el esfuerzo que conlleva cada desarrollo.
  • Queremos estar empoderados para realizar nuestros propios deploys, y para ello nuestro equipo de Innovations está haciendo un trabajo excelente; por lo que en paralelo queremos asumir poco a poco el rol como equipo de realizar deploys y afrontar bugs en producción con Agilidad.
  • Queremos extender la Agilidad por toda la empresa, pues creemos que como equipo de producto nunca podremos llegar a un alto estándar de Agilidad si no somos los primeros que evangelicemos sobre nuestra manera de trabajar y sus bondades a todos los departamentos de nuestra empresa.
  • Buscamos más personas a las que le interese trabajar de manera ágil 😉 😉 .
  • Tenemos como meta disponer de UXs asignados únicamente a un equipo.
  • UX está empezando a adentrarse en el mundo Ágil en su gestión interna, por lo cual podremos ir más alineados.
  • Es obvio, pero siempre se puede mejorar: comunicación, comunicación y más comunicación.

 

¡Gracias por leer y hasta pronto! 😀

 

Loading Likes...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *