it-swarm-es.com

¿Cómo evito que Scrum convierta a grandes desarrolladores en desarrolladores promedio?

Encontré que esto también sucedió en mi equipo, aunque puede haber exagerado un poco la situación.

Scrum es una forma de tomar un desarrollador por debajo del promedio o deficiente y convertirlo en un desarrollador promedio. También es excelente para tomar grandes desarrolladores y convertirlos en desarrolladores promedio.

Todo el mundo solo quiere sacar algo fácil del tablero que puede hacer en un día para tener algo que informar en el scrum diario de mañana. Es solo que todos están tratando de recoger la fruta baja. No hay incentivo para ser inteligente y tomarse el tiempo para pensar en soluciones, si nada se mueve, ¿qué está haciendo? ¡Estás decepcionando al equipo! ¡La velocidad está cayendo!

Creo que si tiene problemas difíciles de resolver, resuélvalos dándolos a personas inteligentes y luego dejándolos solos. No los hostiga constantemente todos los días exigiendo saber lo que hicieron ayer y lo que planean hacer hoy. Con actualizaciones diarias, ¿dónde está el incentivo para que las personas inteligentes trabajen en los problemas difíciles? Ahora tienen el mismo incentivo que el desarrollador junior; encuentra las entradas más fáciles para moverte en todos los ámbitos.

A veces querré estar solo y pensar en una solución por unos días. Si hago eso, no tendría nada que decir en el scrum. Entonces, en su lugar, elegiré la historia del usuario donde el color en el front-end era el tono de verde incorrecto o un error ortográfico. ¡Mira, eliminé 2 historias en un día, antes del almuerzo! Ve a mi

...

No estoy totalmente de acuerdo con sus palabras. Por ejemplo, estoy de acuerdo con un comentario dicho, no es que ellos (los gerentes) no confíen en ellos, es que no hacen las cosas sin supervisión constante.

Cuando un gran desarrollador se convierte en un desarrollador promedio, siempre hay múltiples razones, pero creo que el scrum diario podría ser una de las razones. Entonces, ¿cómo puedo evitar este efecto secundario de las reuniones de scrum?

También me di cuenta de que es más fácil decirlo que hacerlo, pero me gusta ver cómo otros ven este problema.

----- actualización -----

Después de leer todas las respuestas que he recibido hasta ahora, me doy cuenta de que necesito agregar información para que mi pregunta sea más relevante.

Pero antes de entrar en eso, quiero repetir las palabras Martin Maat dio en su respuesta, "El simple hecho de que tanta gente sienta la necesidad decir algo al respecto es un indicador de la frustración que causa Scrum ".

¡Estoy totalmente de acuerdo! Cuando hice la pregunta por primera vez, ya esperaba que algunas respuestas fueran " ¡oh, no haces scrum bien! "

Algunas correcciones que quiero hacer a mi pregunta original son,

  1. Usé la palabra " gran desarrollador " y probablemente debería decir un desarrollador decente/bueno porque he visto esas respuestas desviadas. Además, a lo largo de mi carrera nunca trabajo con grandes desarrolladores, por lo que no debería usar eso en primer lugar. Lo que quise decir es que veo de vez en cuando que scrum ha hecho que un buen desarrollador tenga un rendimiento inferior.
  2. Algunas respuestas se centran en la oración "es que no hacen las cosas sin supervisión constante" y creían que era un problema de microgestión. Pero este no fue mi caso, p. Yo no microgestión. El problema que experimenté (nuevamente de vez en cuando) es bueno/los desarrolladores expertos en tecnología no son necesariamente expertos en negocios. A veces se centrarán en perfeccionar demasiado su solución técnica sin darse cuenta de que al final tenemos un producto que ofrecer. Otras veces es una función de función cruzada que necesita coordinación, especialmente cada equipo puede tener su propia prioridad/horario. Por eso necesitan supervisión. Pero supongo que no debería simplemente copiar la palabra " supervisión constante " de la publicación original y no debería usar constante en primer lugar. Pero, de nuevo, si alguien argumenta que los "grandes desarrolladores" y el "gran equipo" no hacen eso, entonces no tengo argumentos en contra.
  3. Una respuesta decía "el scrum diario de alguna manera se convirtió en una competencia que ha completado la mayor cantidad de boletos". Yo nunca experimenté eso. Un equipo maduro no hace eso (aunque un maduro no es necesariamente un gran equipo). ¿Alguien ha experimentado eso?
  4. Para aquellos que me sugirieron que leyera el manifiesto ágil, mi argumento en contra es: na larga reseña de un libro Escribí en 2008 (hace 12 años) para el libro "The Enterprise and Scrum (Developer Best Practices)" de Cofundador de scrum Ken Schwaber. Enumeré mi reseña aquí, no para presumir, sino para mostrar (1) Creo que he hecho scrum el tiempo suficiente para ver su fuerza y ​​debilidad. (2) Sé de qué se trata ágil.
183
Qiulang

La cita citada refleja un malentendido fundamental sobre cómo funciona el scrum en un equipo saludable. Todo el punto de scrum es "¿cómo podemos funcionar mejor como equipo?" Definitivamente es no "¿cómo podemos competir entre nosotros para lucir mejor?" Competir entre sí para verse mejor no funciona como parte de un equipo, es exactamente lo contrario de eso.

Si la conclusión principal del standup es que tienes que mover algo a través del tablero todos los días, entonces algo ha salido muy mal. Lo principal es si estás en camino de completar el trabajo al que te has comprometido en el sprint a tiempo y si tienes algún impedimento para hacerlo. Esperaría que la gente informara algún tipo de progreso en la posición de pie todos los días, pero si el único objetivo es "cerrar muchas cosas para que nuestra velocidad se vea bien", entonces ese es el enfoque equivocado. Dicho de otra manera, ¿qué es lo que realmente te importa: mirar bueno o en realidad ser bueno?

El hecho de que esto esté sucediendo también sugiere que la planificación del sprint no va bien. Si las personas se tropiezan unas con otras para tratar de obtener la fruta que cuelga y evitar las tareas complicadas, entonces ese es un problema grave. ¿Por qué el propietario del producto no prioriza sus historias correctamente? Seguramente, su fruta de bajo perfil no puede tener prioridades más altas que las tareas complicadas.

Para el caso, ¿por qué incluso escribir historias de "fruta baja" en primer lugar? Las historias deben reflejar algunas entregas que agreguen valor al cliente final, no solo cosas que brindan fruta de bajo perfil para que sus desarrolladores cierren todos los días. De nuevo, ¿qué es más importante: verse bien o ser realmente bueno?

Finalmente, ¿por qué las personas no toman el trabajo en función de sus capacidades? Un ingeniero más experimentado/calificado debe asumir más trabajo, y un trabajo de mayor complejidad, que un ingeniero más joven. Si no lo están, el scrum master debería presionar sobre eso.

En Agile, como lo practicaba, una reunión diaria es el momento de indicar si necesita ayuda, especialmente si está bloqueado en su tarea. Está completamente bien tener una reunión diaria donde nadie tenga nada interesante que decir (y luego reconocer eso y detener la reunión ...). No es el momento de informar lo que terminó al día siguiente. Francamente, a nadie debería importarle lo que hiciste, esta información ya está allí en el tablero, y solo es relevante para alguien que quiere asumir una nueva tarea. Ciertamente no es una reunión donde la jerarquía está presente, aunque es común plantear un elemento de acción que involucra a un gerente como resultado de la discusión.

Las preguntas sobre la velocidad deben discutirse después de un largo período, en una reunión retrospectiva.

El punto de la forma formal en que se manejan las tareas es asignar el esfuerzo donde se necesita esfuerzo. Debe exigir que el propietario de un producto priorice claramente el trabajo y cambie la prioridad lo menos posible. Algo que está a medio camino no tiene valor, por lo que es completamente normal tener grandes tareas también. Si divide una tarea grande en partes más pequeñas del tamaño de un sprint (o peor aún, del tamaño de un día), corre el riesgo mucho mayor de hacer algo a la mitad, especialmente si la forma en que divide una tarea implica dividirla en pasos de un proceso de desarrollo tradicional (generalmente, desarrollo y prueba).

Si Scrum está presionando a todos los desarrolladores para que eviten tareas complejas, probablemente significa que el propietario del producto no está asignando esas tareas a la prioridad que merecen. El objetivo del sprint es alcanzar puntos bien definidos de funcionalidad y corrección de errores, no "hacer cosas por puntos" indiscriminadamente. En la práctica, significa que tiene una acumulación de tareas y al comienzo de un sprint, el propietario del producto y el equipo negocian un subconjunto de tareas de esa acumulación. que se hará al final del sprint. Trabajar en tareas que no están en ese subconjunto mientras quedan tareas en él es una disfunción. Seleccionar constantemente más tareas de las que el equipo puede manejar en un sprint también es una disfunción.

0
Kafein