Inicio: ¿es hora de dividirse en dos equipos?

Trabajo en una startup donde comencé como único desarrollador hace 3 años y ahora dirijo el equipo de desarrollo. Hay 15 empleados en total, 8 de los cuales son ingenieros:

  • 5 desarrolladores de iOS
  • 3 desarrolladores back-end

Actualmente solo estamos creando una aplicación para iOS.

Estamos empezando a crecer un poco y ahora tenemos un diseñador de UX, un jefe de producto, un jefe de marketing, etc. Después de un largo período de descifrar el producto y algunos ciclos de lanzamiento muy largos, queremos comenzar a iterar más rápido.

Mis objetivos son:

  1. para poder hacer que el equipo trabaje en 2 o 3 cortes verticales de características, en paralelo.

  2. para poder liberar esas funciones en cada sprint

  3. para aumentar la responsabilidad y la rendición de cuentas dentro del equipo

Problemas que estoy viendo:

  1. Se siente 'de arriba hacia abajo': gran parte de la comunicación del equipo parece venir a través de mí. es decir. si un desarrollador de back-end tiene un problema con algún componente de ios, es posible que me pregunte, y luego hablaré con el desarrollador de iOS y luego le devolveré la información

  2. Los standups se sienten desenfocados, porque tenemos 8 desarrolladores que trabajan en diferentes "partes" de las cosas, los standups no parecen muy útiles porque no hay realmente un esfuerzo unificado entre el equipo como un todo.

  3. Lanzarlo por encima de la valla: después de la planificación de Sprint, todos tienden a ir a sus silos. Discutimos lo que debe completarse, pero los desarrolladores tienden a entrar en sus propios mundos y, por ejemplo, no toman la iniciativa para discutir las interfaces entre el front-end y el back-end, lanzando cosas por todas partes para el control de calidad (que generalmente viene a mí nuestro producto propietario), etc

Pregunta: Me pregunto si en este momento tiene sentido dividir el equipo en dos grupos multifuncionales. Espero que esto logre lo siguiente:

  1. Cada "equipo" tendrá un objetivo de sprint que puede consistir en 1 o 2 segmentos de características verticales para lograr. Creo que puede ser más fácil autoorganizarse en el contexto de un grupo más pequeño y descubrir qué debe suceder para alcanzar las metas. Además, creo que esto podría ayudar en la rendición de cuentas, ya que el equipo tendrá objetivos muy específicos.
  2. Los standups pueden ocurrir dentro de cada equipo y, por lo tanto, se centrarán en desbloquear y avanzar en el progreso en relación con sus objetivos de sprint específicos.
  3. Debido a que cada equipo tiene objetivos y responsabilidades específicos, serán más responsables de cosas como el control de calidad, la precisión de las maquetas, los casos de borde funcionales, etc. antes de entregarlo al propietario del producto para la prueba de aceptación final.

Supongo que lo anterior se puede lograr dentro del contexto de un solo equipo más grande, pero aún no he podido encontrar una buena manera de hacer que eso suceda.

Parece que tiene un problema de adopción ágil, no un problema de tamaño del equipo. Es probable que dividir su equipo antes de solucionar los problemas subyacentes duplique sus problemas de integración en lugar de reducirlos.
¿Los que no son desarrolladores (Diseñador de UX, Jefe de Producto, Jefe de Marketing, etc.) también forman parte del equipo o trabajan por separado? ¿El equipo tiene una Definición de Listo que incluye pruebas e integración? ¿Cuál sería la respuesta del equipo si dijeras "esto se publicará en una hora" una vez que informen una historia como terminada?

Respuestas (2)

Hay algunas cosas que se destacan de su pregunta:

poder hacer que el equipo trabaje en 2 o 3 cortes verticales de características, en paralelo

¿Por qué ve trabajar en paralelo como una meta? Por lo general, hacer el trabajo en paralelo le cuesta en términos de eficiencia, debido a la sobrecarga del cambio de contexto.

si un desarrollador de back-end tiene un problema con algún componente de ios, es posible que me pregunte, y luego hablaré con el desarrollador de iOS y luego le devolveré la información

Este es un problema de comunicación. ¿El equipo lo ha discutido?

Standups se siente fuera de foco

¿El equipo ha discutido esto? ¿Han intentado algo para mejorar los stand-ups?

Después de Sprint Planning, todos tienden a entrar en sus silos

Arreglar los problemas con el stand-up debería ayudar aquí.

Sugeriría que la mejora más grande que puede hacer en este momento es comenzar a discutir las cosas como equipo.

Puede ser que dividirse en dos equipos tenga sentido, pero esa decisión es mejor impulsada por el equipo mismo y no por un individuo.

Actualmente discutimos las cosas como equipo durante las reuniones de planificación y demás. Pero a partir de entonces, la gente tiende a entrar en sus propios mundos.
Similar al comentario que publiqué en la respuesta anterior, ¿cómo trabajaría un equipo de 8 en una sola característica? Mi experiencia hasta ahora es que está un poco cerca. Así que pensé que si trabajábamos en 2 o 3 porciones a la vez, habría menos de eso y esencialmente 2 o 3 desarrolladores serían responsables de cada uno.
Entiendo absolutamente que a veces es práctico trabajar en más de una cosa a la vez. Pero no me convertiría en un objetivo hacer esto, es solo algo que debería desaparecer naturalmente de la planificación. El equipo discutirá el trabajo propuesto y luego decidirá cuál es la mejor manera de dividirlo. El punto es hacer que el equipo tome estas decisiones para que estén menos inclinados a trabajar en silos.
Si yo entiendo. El equipo es el que toma las decisiones en cuanto a qué abordar, cuáles son los casos extremos, posibles preguntas de alcance, pero luego descubro que cada persona más o menos toma sus boletos y hace su trabajo. Entonces, después de la planificación, todavía parece haber una desconexión en la operación continua basada en el equipo.
Entonces esa es la conversación que debes tener con el equipo. ¿Por qué quieren trabajar de esa manera? También podría hacer algunas sugerencias, ¿quizás podrían probar la programación en pareja, por ejemplo? La clave es que el equipo tiene que querer hacer las cosas de otra manera. Haz que hablen de ello, descubre cuál es su motivación.

por lo que describes, no creo que tengas problema con el tamaño de tu equipo. 5 + 3 parece bastante bien. Tal vez debería agregar algunos comentarios a tus puntos para que entiendas por qué creo que tu problema es otro:

Meta 1 y 2: ¿Por qué crees que necesitas manejar 2 o 3 cortes verticales a la vez? Si sus ciclos de lanzamiento son actualmente demasiado largos, la forma de acelerar el ciclo es manejar menos subprocesos a la vez. También es una buena práctica no manejar un hilo por una sola persona.

Creo que es un problema común y generalizado manejar demasiadas historias al mismo tiempo y esperar que eso acelere las cosas. No es asi. Dará como resultado la división de su equipo en desarrolladores individuales, cada uno haciendo cosas propias.

Problema 1 : ¿Están sus desarrolladores en un solo equipo? En caso afirmativo, ¿por qué un tipo de back-end debería preguntarle sobre algo que hizo el desarrollador de iOS? ¿Tienen un objetivo común? Deben tratar de cumplir su objetivo común juntos. Si luego descubren que algo no está claro y necesitan comentarios del PO, deben preguntarle. Juntos.

Problema 2 : Véase el comentario de los Objetivos 1 y 2. Si todos están trabajando en partes diferentes de algo, en realidad no tiene una estructura de equipo. También tenemos un equipo aquí que lo está haciendo de esa manera, sin trabajo en equipo y construyendo un departamento técnico porque necesitan ser "rápidos".

Problema 3 : Sí, también falta el espíritu de equipo. Parece el típico problema de un restaurante. El servicio y los cocineros no están trabajando juntos, en el peor de los casos peleando sus pequeñas guerras y averiguando quién es el culpable y empujando el trabajo al otro lado.

Espero que mis comentarios dejen claro que dividir el equipo no es la solución. Por lo que estás describiendo, no puedo darte una solución fácil aquí. Por lo general, los desarrolladores de iOS y back-end deben comprometerse con una historia, todos juntos. Y si no llegan a eso, los dos juntos fracasan.

Además, si su trabajo se divide para que cada uno haga su propia pequeña historia, también puede ser un problema de gustos y disgustos personales. Después de una ronda de empujar la culpa, las personas se predisponen entre sí. Esto empeora aún más si las mismas personas manejan el mismo tema una y otra vez.

Gracias por su respuesta. Supongo que tengo curiosidad: si tenemos 8 desarrolladores y no están trabajando colectivamente en 2 o 3 cortes verticales y solo están trabajando en una función, ¿cómo funcionaría eso?
@djt Esto depende de la característica a implementar. Puede tener sentido en algunas situaciones trabajar en 2 o 3 rebanadas. Pero si es posible, el equipo debe concentrarse en una función (que podría tener varias historias). Lo que quiero decir es que trabajar en diferentes cortes puede tener sentido pero no debe ser un objetivo.
Inicio: ¿es hora de dividirse en dos equipos?
RespuestasAquíPolítica de privacidad1y, 0v