Como Scrum Master, ¿cómo evito que un miembro del equipo se dé por vencido con demasiada facilidad?

Como maestro de Scrum, no es su trabajo administrar al desarrollador. Tampoco es su trabajo involucrar al propietario del producto (PO). Es el trabajo de su PO vigilar lo que está haciendo su equipo y es su trabajo asegurarse de que se mantengan en el proceso de Scrum.

Su desarrollador tiene toda la razón al no discutir los detalles del trabajo en el ticket con usted. Usted no es la persona que le asigna el trabajo o juzga si se hace el trabajo o qué tan bien se hace. El Scrum master no es el asistente-PO.

Sin embargo , si su desarrollador solo hace otra historia, tiene que comunicárselo al equipo. Es trabajo del equipo ver quién hace qué y es trabajo del equipo asegurarse de que todas las historias se hagan.

El equipo podría decidir que esta historia es más grande de lo esperado y consultar al PO. El equipo puede decidir que existe un impedimento externo (sin un entorno de prueba, por ejemplo) y delegarlo al Scrum Master para que lo resuelva. El equipo puede decidir que alguien más del equipo ayude al desarrollador porque algunas cosas son difíciles de ver con un solo par de ojos. Tal vez no terminen su objetivo de sprint. Es entonces el momento de discutir esto en la retrospectiva.

Nuevamente: en Scrum, ni los maestros de Scrum ni los PO tienen el trabajo de decirle a un miembro del equipo que haga una determinada historia o cómo hacer una determinada historia. Equipo autoorganizado significa que el equipo organiza cómo se hacen las historias. Si eso no funciona, deja que el equipo encuentre una solución.

Una parte general: no creas que Scrum es todo material sensiblero, cálido y esponjoso solo porque no hay un gerente de proyecto de antaño. No subestimes la presión de tus compañeros. Si no corrige el error, el equipo tendrá que hacer la tarea. Y ellos tampoco estarán contentos con eso. Pero necesitas realmente hacer Scrum. Como siempre, parece que le ha dado una mano de pintura Scrum, teniendo SM, PO y Team, pero no está actuando como tal. Sigues siendo "su jefe" y "administrándolo". Eso no es Scrum y no funcionará de esta manera. Scrum solo funciona si realmente haces Scrum. Dar títulos y hacerlo a la antigua no va a funcionar.

No todos se adhieren a los mismos principios con scrum, particularmente en tiendas pequeñas donde las personas usan múltiples sombreros. Por lo tanto, no es del todo inusual manejar esta situación usted mismo.

Apilar más funciones en los errores hará que su deuda técnica se dispare. Los errores no serán más fáciles de encontrar o corregir agregando más funciones.

Si estos errores se detectan temprano en el ciclo de desarrollo, no los clasifique como errores, pero rechace los elementos que ha completado como incompletos.

Es probable que necesite aumentar sus pruebas y, sin duda, su cobertura de prueba. Una inversión de uno o dos sprints en pruebas unitarias y del sistema aumentará la calidad del código. También obtendrá formas más fáciles de replicar los problemas y más confianza en las áreas de código que podrían estar causando el error, pero no lo están. Todo esto conspirará para reducir el alcance y el tiempo necesarios para corregir errores. También puede agregar revisión de código si aún no lo ha hecho.

También es posible que la alta dirección esté dando un mensaje diferente. Las características venden productos y actualizaciones; los errores enfurecen: estadísticamente, los clientes no dicen que valoren el código libre de errores en las encuestas y, por lo general, no evalúan profundamente la calidad del código antes de comprarlo. Si es así, ese es el habilitador principal. Si no, un edicto único e inequívoco desde arriba ayudará. Pedirle a la alta gerencia que básicamente exija que todos los errores se solucionen antes de que se agreguen nuevas funciones lo sacará de la lista de los malos que puedo ignorar. Preguntárselo a la alta gerencia replantearía el problema para él.

No le gusta comer verduras. Necesita comer sus verduras. :-)

"¿Respuesta corta?" ¡Delicadamente!

Aunque usted no es el gerente de esta persona, en el sentido de la palabra de recursos humanos, usted es el líder de su equipo en particular. (Se use o no terminología como "scrum". No importa qué, si se usa alguna, "filosofía de gestión"...) Usted actúa con autoridad delegada.

Por lo tanto, después de discutir en privado tu estrategia con el gerente y escuchar atentamente sus instrucciones o sugerencias, habla en privado (pero, directamente) con el desarrollador. Recuérdele que espera que se ciña a una tarea hasta que la complete, pero también que se espera que pida ayuda, asistencia y orientación. Que dichas solicitudes deben dirigirse a usted y que las aceptará. Que considere parte de su trabajo remover cualquier impedimento que se interponga en su camino.

Sin ser amenazante de ninguna manera, intente ayudar a esta persona a comprender que "el equipo necesita al equipo" y que, de hecho, se requiere su participación adecuada en estos asuntos. Como líder del equipo, y dentro del alcance del equipo que está liderando, tiene la prerrogativa y la responsabilidad (delegada) de decir tales cosas.

Después de haber tomado el tiempo para discutir su plan con el gerente, ahora tendrá el apoyo de ese gerente. "Sí, Jim o Jane, soy consciente de que bobo2000 les iba a decir esto, porque primero lo discutió conmigo. Él estaba y está efectivamente 'hablando por mí', y yo soy su gerente".

Además:   esté listo "en un abrir y cerrar de ojos" para detenerse y escuchar a esta persona. ¿Por qué podría esta persona rehuir las tareas difíciles? El comentario de que "no es divertido" (o lo que sea) podría ser una cortina de humo. ¿Puede extraer la opinión sincera de esta persona sobre la situación? Los programadores a veces ocultan sus debilidades percibidas, y es posible que perciban debilidades donde y cuando tú no las percibes. Esfuérzate mucho en hacer de esta una conversación privada (!) y bidireccional .

Practique su mejor tacto, diplomacia, poderes de persuasión y ... decisión. Sí, tienes autoridad. Si tu puedes. Pero lo que realmente quiere lograr es: (a) comprender mejor la verdadera situación desde el punto de vista de esta persona, y (b) persuadir a esta persona para que quiera cambiar para mejor.

Un compañero lo dijo una vez de esta manera: "Ofrécele mantequilla y miel en una rebanada de pan. Cuando acepte, saca tu espada y úsala para untar con mantequilla el pan. Él tomará y apreciará la miel, y no fallará también ". para notar que llevas una espada".

Al final de la reunión, y después de dejar que la persona tenga la última palabra, dar la mano, salir de esa habitación privada y dejar todo lo dicho dentro de esa habitación, "dentro de esa habitación".

A veces hay errores que son muy difíciles de encontrar para una persona específica. He visto errores que solo aparecían si su disco duro tenía un nombre determinado. O solo por la tarde. O sólo en un día del año. Eso pasa.

Parece que tienes errores que son difíciles de encontrar y corregir, pero no imposibles. Se da por vencido, tu jefe lo regaña, luego sigue trabajando y lo hace (si te entiendo bien). La parte en la que tu jefe tiene que involucrarse para que siga trabajando en el problema es francamente inaceptable. Involucrar al jefe también es algo con lo que es poco probable que su jefe esté contento.

Puede tomar la decisión gerencial de que un error no se corrija, si hay errores más importantes que son más fáciles de corregir. Pero si ese error necesita ser reparado, o se le da a otra persona (y si esa persona lo arregla, es una gran marca negra contra la primera persona a menos que haya algunas circunstancias inusuales), o le dices que continúe, y él continúa. Si no lo hace, no es problema de sus jefes, sino un problema de recursos humanos.

Solo para aclarar: si el desarrollador dice "no se puede arreglar", y el gerente piensa que es importante arreglarlo y se lo entrega a otra persona para que lo arregle, eso probablemente se recordará (escribirá) y se mencionará en el próxima revisión de desempeño. Si el desarrollador dice "no se puede arreglar" y le da una razón, y el siguiente desarrollador al que le pregunta dice "no se puede arreglar" con las mismas razones, esa es una situación completamente diferente.

PD. Noté que editaste el título a "como scrum master". Ser un maestro de scrum es un papel que desempeñas. Se trata de organizar los scrums, asegurarse de que las tareas estén bien especificadas y entren en un sprint, realizar un seguimiento del progreso, etc. La calidad de los desarrolladores no es tarea del scrum master. Desde el punto de vista puramente del scrum master, si no termina una tarea, entonces queda inconclusa a menos que alguien más la retome.

Sin embargo, hay dos roles diferentes en una empresa que sería responsable: uno sería un mentor o desarrollador senior encargado de ayudar a otros a hacer su trabajo correctamente, y otro sería el gerente del desarrollador que verá cuánto o poco contribuye esa persona. a la compañia. Usted podría estar en uno de estos roles también.

Me gustaría que cualquiera de mis desarrolladores se sintiera responsable de la calidad.

1. ¿Este desarrollador tiene algún contacto con los usuarios del producto?
   • Podría ayudarlo a comenzar a ver a sus usuarios como personas y no solo como otro grupo que lo molesta. Me gustaría que la gente viera un producto de calidad y estuviera contenta con él.
2. ¿El equipo tiene responsabilidad interna?
   • ¿Puede asignar a varios desarrolladores para que trabajen juntos a fin de abordar problemas difíciles? Por lo general, es más difícil ignorar a un compañero que ignorar un ticket de trabajo