¿Cómo equilibrar mejor los recursos en un equipo ágil multifuncional?

No creo que haya una respuesta fácil a esta pregunta.

Desde mi perspectiva, los factores críticos son:

1. El equipo no está cumpliendo con los objetivos de desarrollo.
2. El control de calidad se retrasa, pero no quiere la ayuda de los desarrolladores , ya que actualmente se ofrece/suministra
3. Los desarrolladores completan el trabajo que consideran necesario y no perciben ninguna necesidad de realizar trabajo adicional.

Tengo un par de preguntas:

1. ¿Cuáles son las consecuencias de los plazos retrasados ​​y la deuda técnica de QA? ¿Ha evaluado el impacto de este problema en los plazos finales?
2. ¿Qué retroalimentación está recibiendo de sus partes interesadas? ¿Están contentos? ¿Están lo suficientemente molestos por los plazos retrasados ​​que apoyarán los cambios? ¿Le comunicarán ese apoyo al superior jerárquico?

Si estuviera en su lugar, primero evaluaría las consecuencias y me aseguraría de que las partes interesadas sientan suficiente dolor para apoyar algunos cambios. (si no, entonces tenemos que discutir un problema diferente).

Entonces empezaría a medir la deuda técnica. En un resbalón promedio resbalamos x tareas de control de calidad; la tarea de control de calidad promedio tarda X horas en resolverse. Cree una métrica breve para las partes interesadas/administración de línea en esa métrica semanalmente/mensualmente/(período apropiado para sus sprints).

Ahora necesitamos cambiar la actitud de los desarrolladores y probadores. No están trabajando juntos como un equipo. Primero, debemos asegurarnos de que nosotros, el PM, hayamos proporcionado motivación/liderazgo. ¿Hemos comunicado el valor de trabajar en equipo? ¿Existen incentivos para el juego en equipo?

QA necesita cambiar su actitud. A QA no le gusta la ayuda que brindan los desarrolladores; está bien, enséñeles cómo brindar ayuda útil o dígale al PM que les proporcione capacitación que les permita brindar ayuda útil. Preguntar al control de calidad si cambiar al desarrollo basado en pruebas ayudaría. QA aparentemente tiene algunos procesos que necesitan mejoras. Saque un control de calidad y un par de desarrolladores fuera de línea y pídales que rediseñen el proceso de control de calidad para que sea (a) más rápido (b) facilite el trabajo en equipo efectivo y (c) más efectivo. Pregunte a los desarrolladores con qué persona de control de calidad fue más fácil trabajar. ¿Qué control de calidad tiene el mejor código-fu? Esa persona tiene habilidades que necesitan ser transferidas al resto del equipo.

¿Los desarrolladores no quieren hacer control de calidad? Esta bien. Trabaje con el gerente de línea para obtener desarrolladores que tengan las habilidades adecuadas y quieran trabajar como miembro de un equipo. Pregúntele al departamento de control de calidad: "¿Quién fue el desarrollador más útil en este sprint?" PM puede reconocer a esa persona y asegurarse de que la gerencia de línea sepa que usted valora a esta persona como un jugador de equipo y que querrá a esta persona en proyectos futuros. El comportamiento de este desarrollador está directamente relacionado con la capacidad de sus proyectos para cumplir con los plazos y mantenerse dentro del cronograma/alcance/calidad.

En última instancia, la única herramienta que tiene es el deseo de su parte interesada de cumplir con la fecha límite. Los plazos retrasados ​​crean dolor para las partes interesadas; su trabajo es redirigir ese dolor de una manera que motive el cambio.

Por lo que ha dicho, tiene un problema importante que necesita cambios en la motivación, las habilidades y los procesos. Los detalles particulares de su situación harán que esos cambios sean por lo menos un orden de magnitud más difíciles de lo que he descrito alegremente arriba. Si fuera tan fácil, estarías ganando el salario mínimo.

Asegúrese de que sus partes interesadas sepan que hay un problema, que está tomando medidas para resolverlo y que no espera que el problema se resuelva en este sprint o en el próximo sprint. Lo mejor que puede prometerles es que la tasa de crecimiento de la deuda técnica se reducirá en un x% cada sprint.

El resultado más directo de esto es que QA está constantemente atrasado. Cuando empezamos un sprint ya hay varios elementos listos para QA. Mientras trabajan en estos elementos, las cosas se acumulan y al final del sprint tenemos un conjunto gigante de elementos en control de calidad y los desarrolladores dicen que no tienen nada que hacer. Por supuesto, si los elementos no se terminan en un sprint, llega el siguiente sprint y el problema empeora cada vez más, ya que el control de calidad no puede seguir el ritmo.

Otra forma de ver esto es que sus desarrolladores están constantemente por delante. En cualquier caso, tiene recursos excesivos en términos de desarrolladores y/o recursos insuficientes en términos de control de calidad.

Puede resolver esto cambiando los niveles de recursos. Hable con el patrocinador de su proyecto y descubra cuán importante es el cronograma general del proyecto desde una perspectiva comercial. En base a eso, obtenga el acuerdo de su patrocinador para:

• Brindarle recursos de control de calidad adicionales para que pueda mantener o mejorar su ritmo actual ayudando a que el control de calidad se ponga al día con los desarrolladores; o
• Vuelva a implementar el exceso de desarrolladores en otros proyectos para que su control de calidad pueda seguir el ritmo de sus desarrolladores, aunque existe el riesgo de que su proyecto tarde más en completarse.

Desafortunadamente, te enfrentas a uno de los errores en Scrum. De manera predeterminada, asume que las personas están ansiosas por trabajar juntas independientemente de sus funciones o ambiciones anteriores, y están más que felices de renunciar a ellas por el bien común. No estoy seguro de que exista una solución genérica, pero aquí hay algunas ideas:

Si quieres mantener Scrum

1. Lo más probable es que el equipo tenga algunos problemas para comprender los principios básicos detrás de Scrum. La solución recomendada es entrenar al equipo y ser paciente, y tratar de vivir temporalmente con la situación actual hasta que se entiendan esos principios.

2. Existe una buena posibilidad de que los desarrolladores sean más rápidos que los probadores, por lo que puede eliminar los probadores innecesarios y usarlos en otro lugar, o puede crear dos equipos a partir del equipo actual. Con este enfoque, crea un cuello de botella artificial, el número de probadores, que le proporcionará más información sobre la situación.

3. Hable con su Scrum Master, porque ella es quien debe escalar este problema e intentar encontrar soluciones y entrenar al Equipo Scrum. Algo no está bien aquí.

Si quieres algo más que Scrum

1. He visto configuraciones donde había dos iteraciones cambiadas: una iteración para desarrollo y prueba y otra solo para prueba; esta comenzó más tarde. La idea era que los desarrolladores se comprometieran en exceso e hicieran más trabajo del que pueden probar en una iteración, y el trabajo adicional se había probado en la iteración de solo prueba. Esta no era una solución óptima, pero todos tenían algo que hacer y los equipos cumplieron: las historias de usuario completamente probadas se demostraron al propietario del producto.

2. Puede comenzar a aprender un poco más sobre Scrumban y cambiar lentamente de un enfoque basado en iteraciones a un enfoque continuo como XP + Kanban.

Ya hay una excelente respuesta de Mark C. Wallace, pero pensé en agregar una cosa más.

Trate de equilibrar un poco el sistema usando límites de trabajo en progreso.

En este momento, el desarrollo está produciendo trabajo a un ritmo más rápido de lo que QA puede probar. Intente establecer un límite de trabajo en progreso en el proceso de desarrollo que alimentará el trabajo en control de calidad a una velocidad en la que puedan completarlo, evitará tener un montón de trabajo respaldado en su etapa de control de calidad. También puede agregar un límite de trabajo en curso al paso de control de calidad para que quede claro cuándo el control de calidad está sobrecargado.

Por ejemplo, si tiene 4 pares de desarrolladores, intente establecer un límite de trabajo en progreso de 3 en el paso de desarrollo y un límite de trabajo en progreso de 2 en el paso de control de calidad (1 en proceso, 1 en cola).

Esto significará que sus desarrolladores tendrán poco tiempo ya que solo 3 pares pueden estar haciendo desarrollo a la vez. Esto puede parecer una mala idea, pero generalmente es mejor dejar espacio libre en el sistema en lugar de seguir produciendo trabajo que luego no se puede mantener con los pasos posteriores.

Los desarrolladores en el tiempo de inactividad podrían estar analizando cosas como la eliminación de la deuda técnica, los picos, el soporte en vivo, el análisis de las historias que se avecinan, etc., que aún son productivos pero no obstruirán el paso de control de calidad.

Además, al obligarlos a no hacer nada para contribuir al sprint mientras sus colegas trabajan en sus proverbiales para completar las historias, ¡espero que la integridad profesional los aliente a ayudar con alguna prueba!

Un excelente conjunto de respuestas hasta ahora. Solo quiero agregar esto:

Recomiendo el libro Cómo prueba Google el software . Esta cita resume su objetivo de equilibrar el desarrollo y el control de calidad:

La calidad no es igual a la prueba. La calidad se logra poniendo el desarrollo y la prueba en una licuadora y mezclándolos hasta que uno sea indistinguible del otro.

Esta ha sido mi experiencia. En mi función en YouView, donde estábamos construyendo la interfaz de usuario para un decodificador, teníamos un excelente equipo de prueba, pero hasta que los hicimos parte del equipo de desarrollo; trabajando con ellos en los talleres de especificación antes de que comenzara el desarrollo y brindándoles la funcionalidad temprano y, a menudo, para recibir comentarios, tuvimos una relación disfuncional similar a la que usted describe.

Según mi experiencia, lograr la relación de colaboración adecuada entre desarrolladores y evaluadores ha sido fundamental para elevar la calidad del software que se produce.

Me pregunto qué tan sofisticadas son sus instalaciones de pruebas automatizadas. Si no es particularmente bueno, puede haber un beneficio real al invertir tiempo y esfuerzo en esta área, ya que la recuperación será rápida y sustancial. Usted indica en uno de sus comentarios que tiene un período de prueba de regresión de un mes antes de cada lanzamiento: esto suena muy significativo, y aunque no conozco su entorno, parece que esto podría reducirse, mediante la automatización agresiva de su prueba ciclos, obtendrá beneficios reales.

En su libro "Gestión de proyectos ágiles", Jim Highsmith habla mucho sobre "pruebas automatizadas despiadadas" y afirma que "la experiencia ha demostrado que la mayor diferencia entre los equipos ágiles maduros e inmaduros radica en su compromiso con las pruebas automatizadas despiadadas". Puede que no esté del todo de acuerdo, pero vale la pena considerar las implicaciones de esta afirmación.

Otro tema del mismo libro se refiere a conseguir a las personas adecuadas. Es un punto difícil de hacer y más difícil de cumplir, pero parece que tiene algunos problemas con su gente. Tal vez esa sea otra área clave en la que centrarse, al menos a corto plazo.

Buena suerte...

Creo que encontrará que este es un problema estructural y no está relacionado con las actitudes individuales o la comprensión de scrum. Cada vez que me he encontrado con desarrolladores que no hacen pruebas, probadores que quieren que les entreguen el código en bandeja, etc., es porque están haciendo lo que se les dice o lo que implican las circunstancias de su empleo.

Si los desarrolladores no quieren probar, puede ser su gerente o la cultura de la empresa. "Los desarrolladores cuestan más que los probadores, por lo que deberían estar desarrollando, no probando". He escuchado esto dicho por los propios desarrolladores, por su gerente, por los gerentes de proyecto y por los altos ejecutivos. "El control de calidad es el responsable último de la calidad". He escuchado esto dicho por probadores, por su gerente, por gerentes de proyecto y por altos ejecutivos.

Hasta que el liderazgo senior (y superior) de su organización de desarrollo pueda comprometerse con una organización orientada al equipo, usted estará peleando esta batalla.

En su caso, los directores de personal parecen ser comprensivos. En ese caso, sugeriría probar su apoyo... pedirles que restablezcan las expectativas de todo el personal hacia una colaboración más orientada al equipo en lugar del cumplimiento de roles individuales. Tienes la oportunidad de detallar las expectativas, y lo venden. O si no, se acercó más a la fuente del problema y puede tener otros recursos disponibles para abordarlo allí.

Google prueba la forma en que lo hace porque su cultura refuerza la agilidad de arriba hacia abajo. La mayoría de los talleres en los que he trabajado o entrenado no tienen ese lujo: terminamos impulsando la agilidad en la organización. Es lento pero a veces funciona.

Como ha dicho mi propio entrenador, Richard Lawrence: primero trate de alcanzar el hito en el que el equipo cumple consistentemente con lo que se compromete. Luego construye sobre eso. Agregaré que puede llevar bastante tiempo llegar allí.