Cómo gestionar un subequipo fallido dentro de un equipo scrum

Preguntaste en términos de scrum, así es como responderé. Sin embargo, hay una serie de señales de alerta en su pregunta que me llevan a creer que en realidad no está haciendo scrum (y estoy lejos de ser un purista de scrum).

La respuesta de scrum sería:

• como PO, usted es responsable de la acumulación de productos y las prioridades, no de la mejora del proceso. Si ve un problema, puede mencionarlo en retro, o (lo que recomendaría dada la naturaleza persistente del problema) hable con el SM y obtenga su consejo sobre si debe mencionarlo en retro, o si preferirían sacar el tema.

• el SM es responsable de plantear cualquier problema de proceso observado que vea y de orientar al equipo hacia la mejora del proceso. Esto se hace típicamente en el retro.

• tener claro el problema. El problema como lo describe no es "no pueden lanzar código sin errores". Ese es un ideal inalcanzable al que todos deberíamos aspirar, pero en realidad no es alcanzable. El problema real que describe suena como "los errores complejos se descubren tarde y no se pueden solucionar dentro del sprint".

• el primer paso en cualquier pregunta del tipo "¿por qué sucede esto?" es llevarla al equipo: preguntarles por qué sucede esto. (Nuevamente, esto está propiamente en la esfera del SM, no en el PO). El SM puede necesitar entrenar más allá de la primera respuesta.

• en esta discusión, piense de manera amplia y creativa: tal vez el problema esté más arriba, en los requisitos y la especificación de aceptación. Tal vez esté en el refinamiento de la cartera de pedidos (y si lo está, esa parte está en su esfera como PO). Tal vez realmente necesite invertir en algunas pruebas automatizadas. Tal vez necesite fallar temprano. Tal vez necesite hacer algunos picos para reducir la incertidumbre y aclarar los requisitos. Seguro que hay más posibilidades.

• Además, piense de manera incremental: haga una lluvia de ideas sobre un montón de posibilidades, luego el equipo selecciona un elemento para probar, para ver si hace una diferencia incremental. Es muy poco probable que encuentre una bala de plata grande.

• ¡Finalmente, por Dios, deja de hacerlos trabajar horas extras y noches y turnos dobles! Se supone que Scrum es un ritmo sostenible... e independientemente de la metodología que esté utilizando, esto es totalmente contraproducente. Agota a su equipo y espera que resuelvan problemas complicados mientras están agotados.

Editar: respondió a una edición adicional anterior

Qué sucede en las retrospectivas

Estamos en un ciclo de señalar los problemas -> El equipo lo registra -> en el próximo sprint, los mismos problemas -> Retrospectiva

Este es el lugar para comenzar, entonces. No se detenga simplemente registrando el problema. El retro no se trata solo de identificar problemas de proceso; se trata de hacer una lluvia de ideas sobre las causas/factores y las posibles soluciones correspondientes para probar, y comprometerse a probar al menos uno de ellos en el próximo sprint.

Además, si "nosotros" que señalamos los problemas no somos los mismos que "Equipo" que los registra... ese es otro problema.

Aumente su colaboración con el equipo Scrum

Sin embargo, en este caso particular no es una opción.

No es una opción es generalmente el lenguaje comercial para: "Queremos resultados diferentes, pero nos negamos a cambiar cualquiera de los factores subyacentes". Eso no es ágil y, por lo general, conduce a señalar con el dedo y otros antipatrones comerciales no constructivos.

El equipo front-end produce muchos errores (defectos) dentro de un ciclo de sprint.

Scrum no es una capa delgada de palabras de moda sobre la gestión de productos de comando y control. Necesitas un cambio de paradigma.

Los defectos y el trabajo incompleto son síntomas de problemas de proceso. Por lo general, esto se debe a que el equipo de desarrollo es:

1. "Hacerse responsable" del trabajo que se incluye en el Sprint, en lugar de que el Equipo de Desarrollo lo lleve al Sprint en función de sus propios pronósticos de capacidad y nivel de esfuerzo.
2. No colaborar en una Definición de Listo que incluya el desarrollo de prueba primero, o no incorporar suficientes medidas de control de calidad al estimar y planificar el trabajo.
3. No utilizar metodologías de prueba adecuadas o herramientas de integración continua. Esto es un poco más difícil para el trabajo de front-end que para el trabajo de back-end, pero en su caso, es probable que la implementación de Scrum carezca por completo.

Debe asociarse con Scrum Master y colaborar con el Equipo de desarrollo para abordar los problemas subyacentes del proceso. Puede comenzar por no asumir que están "fallando" o teniendo un bajo rendimiento, y dejar de tratarlos como si fueran un "subequipo". En Scrum, solo hay un Equipo Scrum, y todos ustedes están juntos en ese equipo .

Como propietario del producto, es su trabajo averiguar qué necesita el equipo de desarrollo para colaborar con éxito con usted en el desarrollo del producto. También es su trabajo capturar los requisitos previos necesarios en el Product Backlog como trabajo que todo el equipo pueda rastrear. Por ejemplo, configurar un servidor de integración continua que pueda procesar y probar JavaScript es probablemente un requisito previo que actualmente no se rastrea como un elemento de la cartera de productos de primera clase. Está en su poder arreglar eso, porque usted es el custodio del Product Backlog, con la autoridad para priorizar los elementos del backlog (y, por lo tanto, asignar los recursos del equipo) para facilitar el éxito del proyecto.

Estoy recibiendo muchos sentimientos de "nosotros" contra "ellos" de su pregunta, que es una señal de alerta importante. Como PO, eres parte del equipo, solo hay "nosotros".

Otros han comentado cómo sería mejor no tener "subequipos" separados, sino solo un equipo de habilidades cruzadas, por lo que no daré más detalles al respecto.

Creo que su principal problema es que el equipo está siendo presionado para entregar cosas, en lugar de que ellos mismos se comprometan con un objetivo.

el equipo debe

1. Calcule cuánto tiempo les tomará terminar cada historia (en sesiones colaborativas de refinamiento). Lo ideal es que hagas esto en storypoints.
2. Use datos de sprints anteriores para decidir cuánto trabajo pueden manejar en un sprint. Mire los últimos 2 a 6 sprints, vea cuántas historias pudo cerrar (aún no queda trabajo, por lo que se probó completamente y se resolvieron todos los errores) dentro del sprint de tiempo limitado (¡sin extensiones!). Esta es su velocidad.
3. Use esa velocidad para seleccionar un nuevo conjunto de historias para trabajar en el próximo sprint

Esto significa que nadie fuera del equipo de desarrollo puede decirles en qué trabajar y cuánto tiempo les llevará terminarlo. Ni siquiera tú. Debe decirles cuál es la prioridad comercial de cada una de las historias, y definitivamente deben tener eso en cuenta al seleccionar las historias. Pero si tienen buenas razones para no comprometerse con un elemento de alta prioridad (por ejemplo: porque no se ajusta al próximo sprint, de acuerdo con su velocidad), está totalmente bien.

Si eso significa que no pueden cumplir con los plazos externos, significa que los plazos no son realistas. Debe retrasar los plazos, reducir el alcance del producto lanzado o buscar formas de mejorar la eficiencia del equipo o la capacidad del equipo. Sin embargo, su equipo ya es bastante grande, así que no lo ampliaría.

Es perfectamente normal tener personas con diferentes habilidades y capacidades trabajando en un equipo Scrum. Por lo tanto, es normal tener roles de Back-end, Front-end y QA por separado en un equipo.

El éxito del equipo depende de no tratar a un pequeño grupo de personas dentro del equipo como un subequipo . El concepto de subequipo va en contra del concepto de equipo scrum.

Está perfectamente bien que cada individuo del equipo posea una habilidad específica y, por lo tanto, desempeñe un papel específico que coincida con la habilidad.

Sin embargo, no es una buena práctica agrupar a las personas con habilidades similares y llamarlas un subequipo dentro del equipo.

La creación de sub-equipos conducirá al escenario de un sub-equipo culpando al otro.

Los individuos por lo general no culpan a los demás individuos. Sin embargo, los subequipos generalmente tienden a culpar a los otros subequipos.

Los subequipos también introducen invariablemente un falso sentido de jerarquía y un proceso de escalamiento dentro del equipo, lo que reduce la eficiencia general del equipo.

Evitar los subequipos, permitir que los individuos tengan una buena relación con los demás miembros del equipo y eliminar el falso sentido de jerarquía hará que el equipo se autogestione automáticamente. Esto definitivamente allanará el camino para el éxito.

Creo que pediría una "parada y reagrupación de todos los proyectos". Este equipo obviamente está en una Marcha de la Muerte, y eso nunca funciona. Debe ayudar al equipo, y a la gerencia, a comprender qué está impulsando al equipo a intentar esto.

¿Son realistas las expectativas? ¿Es bueno el proceso de análisis? ¿El equipo, bueno, realmente sabe lo que se supone que debe hacer? ¿Están tratando de asumir más trabajo del que obviamente pueden lograr, y si es así, por qué?

No se puede superponer scrum, ni ningún otro paradigma de gestión de proyectos, "sobre" cualquier marcha de la muerte. Tienes que intervenir para detener la marcha, primero.

Sí, y "volveré en círculo y agregaré otra respuesta" para decir que los problemas de causa raíz aquí son muy obviamente externos al equipo.

• Si a los programadores se les ha dicho que deben suicidarse para producir el software necesario ... ¡ no (!) ... nunca (!!) ... van a "producir el software necesario".

Por lo tanto – (poniéndome aquí mi duro sombrero de consultor…) – “no puedes resolver un problema hasta que confrontes lo que realmente es”. Y en este caso, claramente involucra a alguien, en un nivel mucho más alto dentro de la estructura corporativa que rodea a este equipo, que aprendió de "Más barato por docena" y no del mundo del software real.

Los " trabajadores de software (!)" no son "empleados de línea", simplemente responsables de ver girar una manivela. Son trabajadores calificados que fácilmente pueden tener tanto "impacto en su resultado final "... si no más... como cualquier abogado pagado en exceso. Y – el producto de su trabajo diario es "absolutamente inútil" a menos que (!) "¡¡Es absolutamente (!!) (!!) (!!) correcto!"

Entonces, es por eso que dije: "primero, debes detener la Marcha de la Muerte". Debe dejar de someter a este equipo de trabajadores a expectativas poco realistas. Debe detener cualquier expectativa de la gerencia (!) de que "azotar" hará algún bien.

Porque: precisamente lo contrario es cierto.

Ejemplo simple: *"Dígales a nuestros abogados corporativos que no solo deben reducir su facturación en un 50%, sino también producir sus abogados en la mitad del tiempo".

No. Los trabajadores del software, exactamente (!) como los abogados, se ganan el pan todos los días con su experiencia. No se puede simplemente contar, digamos, "la cantidad de páginas [de código fuente] [de informes legales] que producen". Ese no es el punto.

Hágase un favor y aléjese de los procesos y las herramientas (si quiere hablar en términos ágiles).

Reúna a todos en un taller de ejercicios de pizarra y descubra cómo todos juntos pueden mejorar el status quo. Te sorprenderá lo que obtendrás.