Como Scrum Master, ¿debería decidir yo o el equipo decidir si necesitan un probador?

Se hacen muchos comentarios sobre el tamaño del equipo y los roles dentro de él, así que me lo saltaré.

Mi consejo (con la mayoría de las preguntas, problemas o lo que sea): llévelo al equipo

El equipo está haciendo el trabajo real y pueden decir lo que creen que necesitan o deberían hacer o lo que sea. Luego puede tener una discusión sobre la situación y llegar a una solución con el equipo.

No hables del equipo y sus necesidades, habla con el equipo

Como Scrum Master, ¿debería decidir yo o el equipo decidir si necesitan un probador?

Así es como hablan los gerentes de proyectos tradicionales, no los scrum masters.

Si los miembros de su equipo consideran que un probador ayudaría y quieren un probador, entonces deberían tener un probador. El equipo decide.

Esto responde directamente a su pregunta de título. Ahora diré algunas cosas sobre lo que mencionas en el resto de tu publicación.

Tiene un Gerente de Producto, un Gerente de Producto Asociado, un Analista de Negocios, un Investigador de Usuario, un Diseñador de Interacción y un Diseñador de Contenido en (lo que usted considera) su equipo, pero de alguna manera cree que un probador sería demasiado. ¿Un probador ayudará al equipo a proporcionar más o mejor valor? Entonces consigue un probador. Si no, no.

El equipo parece estar manejando bien las pruebas sin ella y esta es la dirección de la organización, es decir, que cada equipo se apropie colectivamente de las pruebas. Cuál es mi preferencia.

¿La dirección de la organización? ¿La organización decide si los desarrolladores necesitan probadores o no? Los equipos de Scrum deben organizarse por sí mismos. Ellos deciden si necesitan probadores o no para hacer su trabajo correctamente.

Estoy seguro de que el equipo aceptará tener un probador, pero esto va en contra de construir multifuncionales.

La funcionalidad cruzada no significa que todos hagan todo. La funcionalidad cruzada en Scrum significa que el equipo tiene todas las habilidades necesarias para construir el producto. El equipo en su conjunto. No significa que los desarrolladores también deban hacer el trabajo de un probador. Pueden, pero no debería ser obligatorio. Piénselo, un investigador de usuarios que no programa ni prueba va en contra de la creación de multifuncionales también. ¿Qué vas a hacer al respecto ahora para construir multifuncionales?

Como historia personal, a menudo me he encontrado en la posición de ser un espectáculo de un solo hombre y, aunque podría manejar muchas cosas por mi cuenta, desde muchas áreas diferentes (ser un funcionalista cruzado, si lo desea), todo habría sido más eficiente y resultaría mejor si alguien con habilidades más especializadas hubiera manejado algunas de las cosas que hice. Entonces, si su equipo necesita un probador, déjelos tener un probador. De esa manera, las pruebas se pueden manejar de una manera más enfocada y eficiente que otros que cambian constantemente de un rol a otro.

Es responsabilidad del Scrum Master asegurarse de que el equipo siga Scrum, pero agregar un probador al equipo no entra en conflicto con la Guía Scrum .

Sin embargo, la Guía Scrum recomienda mantener el tamaño del equipo en 9 o menos, por lo que valdría la pena discutirlo con el equipo. Un buen enfoque sería estar atento a los problemas relacionados con el tamaño del equipo, como las fallas en la comunicación.

Estoy seguro de que el equipo aceptará tener un probador, pero esto va en contra de construir multifuncionales.

No hay ninguna razón por la que no pueda tener un probador en un equipo de personas multifuncionales. Los evaluadores pueden involucrarse en el análisis y algunos también pueden realizar tareas de codificación o configuración. Pueden tener tanto perfil de habilidades en forma de T como un desarrollador.

Lo que un buen probador puede aportar a un equipo es una mentalidad de calidad. Pueden observar la funcionalidad del producto de formas inusuales, detectando problemas potenciales que otros no pueden detectar.

Tal vez sea útil reformular la pregunta. En su lugar, podemos preguntar: "¿ Mi equipo tiene las habilidades en torno a la calidad necesarias para entregar el incremento del producto? " Puede pensar que sabe la respuesta a esta pregunta, incluso puede tener razón. Sin embargo, esta es una pregunta para el equipo.

La Guía Scrum tiene esto que decir sobre el equipo de desarrollo:

Se autoorganizan. Nadie (ni siquiera el Scrum Master) le dice al Equipo de Desarrollo cómo convertir el Product Backlog en Incrementos de funcionalidad potencialmente liberable;

Esto no da permiso al equipo para crear incrementos que no sean potencialmente liberables debido a problemas de calidad. Entonces, aunque podríamos decir que no es su función como SM decirles si poseen o no las habilidades necesarias para producir un incremento de calidad, absolutamente debe compartir lo que ve que puede indicar que no están cumpliendo con ese estándar. . Por ejemplo, si ve una gran cantidad de defectos devueltos o incrementos que se declaran no aptos para el envío debido a que no se realizaron las pruebas.

Ahora la pregunta para el equipo es cómo cumplir con este estándar. Tal vez sea un problema de proceso: tienen las habilidades pero necesitan aplicarlas. Tal vez no tengan las habilidades, pero apréndalas de alguien en otro equipo. Tal vez decidan que agregar a otra persona sería la mejor manera de adquirir esa habilidad. Realmente, este es el mismo proceso de pensamiento para cada habilidad que el equipo pueda necesitar.

La bandera roja que tengo sobre la necesidad de otra persona es doble:

1. No deberíamos confundir a las personas con las habilidades. Lo que necesita el equipo es habilidad. Simplemente agregar personas para cada habilidad puede resultar costoso y puede reforzar los cuellos de botella.

2. Para la mayoría de los equipos, esto simplemente no es algo que esté bajo su control. Hay un proceso de aprobación del presupuesto, un período de contratación, un período de capacitación (donde todo el equipo reducirá la velocidad para capacitar a la nueva persona). ¿Cómo producirá algo el equipo en ese período de tiempo? ¿Son esos meses solo un lavado?

Teoría vs Práctica

De acuerdo, todo eso fue mucho teoría y pensamiento de fondo. Entonces, ¿cuál es la respuesta práctica? Si yo estuviera en tu lugar, seguiría estos pasos:

1. Determinar si hay un problema de calidad. Comparta sus observaciones con el equipo. Ayúdelos a verificar el nivel esperado de calidad con la OP y la organización (y el cliente si es posible).

2. Si la respuesta es "Sí, hay un problema de calidad", determine qué habilidades y comportamientos se necesitan para resolverlo. Nuevamente, este es un ejercicio que facilitamos con el equipo.

3. Determine cómo podemos cumplir con el estándar en este sprint . Comenzaría aquí porque a través de la conversación aprenderemos lo que es posible ahora, lo que podría ser posible con otra persona y si nos quedamos atrapados sin otra persona con un conocimiento más profundo.

4. Espacio libre para que suceda. Aquí es donde su trabajo se vuelve difícil. A menos que el #3 descubra algo conveniente, su equipo puede necesitar ayuda de otros equipos, otras partes de la organización o una variedad de otras cosas, incluso si no necesita a otra persona (y si la necesita, hay un proceso para comenzar por eso también).

   El equipo no debe estar trabajando para parecer ocupado, debe estar creando un producto. Si no tienen lo que necesitan, no pueden hacer que el producto se incremente y no deberían estar trabajando en nada liberable. Por supuesto, en el mundo real, a mucha gente no le gustará esa respuesta. Aquí es donde entrenar a otros en su organización es muy importante para que entiendan lo que está en juego y lo que necesita el equipo sin solo sonar como un fanático.

   Espero que esto no sea demasiado contundente, pero hacer que eso suceda es la razón por la cual el equipo tiene un Scrum Master. Es una gran parte de lo que hace que Scrum funcione. Y cómo hacerlo es prácticamente imposible de poner en una respuesta de Stack Exchange (lo siento).

5. ¡Haz productos increíbles! Celebrar un trabajo bien hecho.

Este artículo de Mike Cohn responde en gran medida a mi pregunta:

https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

“La dirección ejerce un sutil control sobre la autoorganización

En el documento original que describe Scrum, Takeuchi y Nonaka identificaron el "control sutil" como uno de sus seis principios. Enumeran las decisiones de dotación de personal como una responsabilidad clave de gestión.

Seleccionar a las personas adecuadas para el equipo del proyecto mientras se monitorean los cambios en la dinámica del grupo y se agregan o eliminan miembros cuando sea necesario [es una responsabilidad clave de la gerencia]. “Agregaríamos un miembro mayor y más conservador al equipo si el equilibrio cambiara demasiado hacia el radicalismo”, dijo un ejecutivo de Honda. “Elegimos cuidadosamente a los miembros del proyecto después de una larga deliberación. Analizamos las diferentes personalidades para ver si se llevarían bien.

Conseguir las personas adecuadas en el equipo ágil

Si usted es gerente de personal o influye en la composición del equipo de su organización, estos son algunos de los factores a considerar.

Incluya todas las disciplinas necesarias en equipos ágiles

Como equipo multifuncional, es importante que todas las habilidades necesarias para pasar de la idea a la característica implementada estén representadas en el equipo. Inicialmente, esto puede significar que el tamaño del equipo es un poco más grande de lo deseado. Pero, con el tiempo, los miembros de un equipo Scrum aprenderán algunas de las habilidades que poseen sus compañeros de trabajo. Este es un resultado natural de estar en un equipo Scrum. A medida que algunos miembros del equipo desarrollan habilidades más amplias, otros individuos pueden pasar a otros equipos.

Combinación de niveles de habilidades técnicas en equipos ágiles

Sujeto a las consideraciones del tamaño del equipo, debe esforzarse por equilibrar los niveles de habilidad en el equipo. Si un equipo tiene tres programadores senior y programadores no menos experimentados, los programadores senior necesitarán codificar algunas características de baja criticidad que podrían resultar aburridas. Un programador junior no solo podría haber encontrado agradable trabajar con estas características, sino que también se beneficiaría del aprendizaje a través de la asociación con los programadores senior.

Equilibre el conocimiento del dominio en equipos ágiles

Así como nos esforzamos por equilibrar las habilidades técnicas, debemos esforzarnos por lograr un equilibrio entre aquellos con un conocimiento profundo del dominio en el que estamos trabajando o el problema que estamos tratando de resolver. Esto no quiere decir que si tenemos la oportunidad de reunir un equipo completamente de expertos en el dominio, no deberíamos aprovecharla. Más bien, debemos considerar los objetivos a largo plazo de nuestra organización. Uno de esos objetivos es probablemente la acumulación de conocimiento del dominio en toda la organización. Le resultará difícil lograrlo si reúne a todos los expertos del dominio en un solo equipo.

Busque la diversidad en los equipos ágiles

La diversidad puede significar muchas cosas diferentes: el género, la raza y la cultura son solo tres de ellas. Quizá sea igualmente importante cómo piensan las personas acerca de los problemas, cómo toman decisiones, cuánta información necesitan antes de tomar una decisión, etc. La investigación muestra que los equipos homogéneos alcanzan el consenso más rápidamente que los equipos heterogéneos, pero lo hacen al no considerar todas las opciones.

Considere la persistencia al formar equipos ágiles

Se necesita tiempo para que los miembros ágiles del equipo aprendan a trabajar bien juntos. Por lo tanto, esfuércese por mantener juntos a los miembros del equipo que han trabajado bien juntos en el pasado. Al formar un nuevo equipo, considere cuánto tiempo los miembros podrán trabajar juntos antes de que algunos o todos se dispersen a otros compromisos”.

Estoy totalmente de acuerdo en que "los equipos no se forman al azar". Ya sea que su equipo esté compuesto estrictamente por los principios organizacionales detallados en "algún libro" o no, y ya sea que usted se llame a sí mismo por un título contenido en "algún libro", la conclusión es que su trabajo es asegurarse de que el equipo produce software de calidad, de manera constante y consistente.

Por tanto: ¿percibes que hay un problema de calidad? ¿Piensan los desarrolladores que se beneficiarían de tener una persona dedicada cuyo trabajo es hacer nada más que probar? ¿ Tu?

Cuando el equipo completa y aprueba un hito, ¿el trabajo permanece estable posteriormente?

Ya sea que tenga o no una persona separada que esté probando lo que otros han hecho, las pruebas siempre deben integrarse en el proceso de desarrollo de software. No basta con escribir un bloque de código fuente: hay que demostrar que funciona. Y, debe poder realizar pruebas continuamente para asegurarse de que lo que solía funcionar no se rompa posteriormente. Los desarrolladores deben tener la primera y principal responsabilidad de esto: "usted escribe el código y escribe las pruebas". Mientras tanto, en un equipo grande como el suyo, me gusta tener a alguien más cuyo trabajo de tiempo completo sea tener una visión más amplia, buscar regresiones, presionar cada botón y hacer clic en cada campo, mientras los desarrolladores continúan.

Realmente no creo que los equipos de desarrollo sean, deban ser o realmente puedan ser "autodirigidos". Necesitan orientación y eso significa usted.