escéptico en un equipo Scrum

Cuando me enfrento a un escepticismo extremo, intento algunas cosas:

1.) Demuestro técnicas como TDD, Implementación continua, Programación de pares, Reuniones de requisitos con sus usuarios, breves iteraciones, etc. No llamo a esas técnicas ágil o arpa sobre el ágil Manifiesto (Hago un comentario sobre la artesanía del software, pero eso es diferente; p). Simplemente les muestro a los miembros del equipo herramientas y técnicas útiles que les facilitan la vida. Tienden a subirse al carro ágil una vez que ven los beneficios del día a día.

2.) No cambio inmediatamente a una metodología SCRUM (u otra) en toda regla. Siempre es mejor introducir pequeños aspectos de Agile a la vez.

3.) Estoy de acuerdo con los escépticos (a un punto). Agile no es una bala de plata y SCRUM, Kanban, Lean, etc. tampoco son una bala de plata. En su lugar, trabajo con ellos para ver qué aspectos podrían beneficiarlos de inmediato (un servidor de CI generalmente no es fácil de pensar) y luego pruebo el resto "Dejemos a los stand-ups durante una semana y luego los revisemos".

Como cualquier otra metodología, SCRUM y otros necesitan trabajar realmente con el equipo y la organización, no enajenarlos.

Por lo tanto, para llegar directamente a su pregunta. Críalo con el equipo:

"También soy un poco escéptico acerca de los stand-ups, pero creo que, como equipo, deberíamos intentarlo durante una semana (¡sin excusas!) y luego revisarlo para ver si funcionó para nosotros. ¿Qué piensa la gente? "

Un caso típico de mal implementado Scrum .

Scrum se ha impuesto al equipo. El equipo (completo) no lo eligió.

Cuando quiera implementarlo, debe contar con el respaldo total tanto del equipo como de la administración, o de lo contrario no funcionará.

  

La resistencia al cambio es tu enemigo aquí.

Le sugiero que vuelva a comenzar y presente Scrum al equipo y permita que hagan preguntas.

Si no puedes vender la idea, no trates de forzarlos usando una metodología que no quieren. Harán todo lo posible para sabotearlo. Llegar tarde a las citas diarias es uno de los comportamientos que obtendrás.

Tenga en cuenta que Scrum puede no ser recomendable para su empresa. Las únicas personas que pueden responder esa pregunta son las personas que trabajan en la base. El equipo .

Puede ser que el concepto de reuniones diarias no se aplique muy bien a lo que una persona está haciendo. Esas reuniones no son gratuitas.

Si lo que estás haciendo requiere mucha concentración a largo plazo, como las matemáticas pesadas, las reuniones pueden desanimarte y ser frustrante. Trabajo con alguien así, que prefiere reunirse semanalmente, lo cual es perfectamente razonable.

En realidad, para ser honesto, si estuviera en tu equipo de programación, ¡probablemente sería un escéptico! He visto una larga línea de metodologías que supuestamente debían revolucionar las cosas y hacer que los proyectos llegaran a tiempo, dentro del presupuesto y sin errores. Esto es sólo el último. ¿Por qué debería creer el aceite de serpiente? Hace 10 años, las mismas personas estaban azotando otra cosa, en unos pocos años surgirá algo nuevo. No me malinterpreten, creo que algunas de las nuevas metodologías aportan algunas ideas útiles. Desafortunadamente, también traen muchos dogmas e ideas estúpidas.

¿Realmente importa si él no se sube a bordo? Simplemente asigne algunas tareas de programación y deje que lo haga de la manera que quiera. Si su trabajo es satisfactorio, déjalo ser. Si su trabajo no es satisfactorio, reemplazarlo. ¿Por qué es tan importante que las personas sigan a Scrum?

A lo largo de los años he visto a muchos buenos programadores renunciar o enojarse porque su gerente sigue introduciendo nuevas metodologías. Solo quieren codificar y hacer el trabajo. Confía en mí dentro de unos años, estarás maldiciendo a Scrum y saltando sobre lo que sea la última moda.

Si está haciendo un trabajo ágil, entonces debería tener un trabajo con el que está trabajando. Utilice el scrum para repartir las asignaciones de la cartera.

Las asignaciones de elección (mejores) se seleccionan primero al comienzo de la reunión. Cuando llegues tarde llega solo dale lo que queda para el día.

No importa si él es el don de Dios para la programación, tiene la tarea de mierda que nadie más quería. Si intenta armar otra tarea o trabajar en otra cosa, el equipo en su conjunto necesita apoyarse en él y obligarlo a trabajar solo en su tarea "elegida". Probablemente debería tener un maestro de compilación que pueda rechazar sus cambios si no está trabajando en el trabajo elegido.

También el equipo debería estar estableciendo objetivos y potencialmente una compensación. Puede votar en equipo para no recompensar a los que no participan. Esto varía en la cantidad de propiedad que su administración le ha dado a su equipo ágil. Recuerde a la gerencia a aquellos que están perjudicando al equipo y evitando que el equipo tenga éxito.

Recuérdele que si se presenta a tiempo, puede participar en el proceso.

Se supone que los equipos de Scrum son autoorganizados. Scrum también funciona al implementar una transparencia extrema en todo.

Entonces, la respuesta obvia es que Scrum Master convoca una reunión, explica el problema (pero no se engañe, todos en el equipo ya saben exactamente cuál es el problema) y luego les dicen que tienen 1 hora para averiguar qué van a hacer al respecto. Luego se sienta en la esquina y mantiene la boca cerrada.

Obviamente, este es un equipo nuevo para Scrum. Así que la clave es que Scrum Master tiene que aceptar cualquier respuesta que el equipo tenga. Si los anula, o impone sus propias ideas a la solución, destruirá la confianza que el equipo necesita para construir con él para que puedan autoorganizarse. Es posible que el equipo decida no hacer nada.

En cualquier caso, el problema debe revisarse en la Retrospectiva de Sprint y se puede discutir la eficacia de cualquier solución que hayan encontrado.

Evitar el "conflicto de equipo" ni siquiera debería ser un factor en absoluto.

Despide al compañero de equipo, entonces él no causará controversia dentro del equipo.

Examine su trabajo anterior, extraiga múltiples ejemplos de cómo el enfoque de la caída de agua lo decepcionó muchas veces en el pasado. Luego presenta los casos a tu compañero de equipo. Con un vistazo del sentido común, verá la luz.

La programación es una actividad de precisión, por lo que un individuo raro permanecería poco receptivo a los hechos concretos. Al menos, en teoría.

¿Quién tomó la decisión de cambiar y por qué? ¿En qué se encontraban esos escépticos en la decisión o simplemente se cayó sobre ellos?

¿Está siendo demasiado rígido y / o rápido en la implementación de sus nuevos métodos? ¿Pusiste buenos productos (no necesariamente perfectos) usando tus viejos métodos? ¿Has demostrado a los escépticos cómo les beneficiará? ¿Puedes demostrarlo? ¿Los que han "visto la luz" han demostrado a los escépticos cómo los beneficia a ellos, al equipo y a la empresa?

Probablemente les está pidiendo que acepten todo solo en la palabra de los creyentes. Es más que probable que estos escépticos hayan adoptado nuevas metodologías antes y no se hayan beneficiado de ellos.

Tal vez podría hacer uno o dos proyectos con solo los creyentes trabajando en él usando sus nuevos procedimientos. Toma medidas reales y demuestra a los escépticos los beneficios reales. Tal vez incluso establecer una pequeña competencia entre los escépticos y sus viejas costumbres y los creyentes y sus nuevas formas.

Por supuesto, ¿qué haces si ganan los escépticos?

Tenga una reunión de equipo para discutir y averiguar por qué su empresa cambió a SCRUM y logró que todos identificaran lo que piensan acerca de SCRUM que agregaría valor al modo de operación actual. A veces las empresas hacen interruptores con cabeza de cabeza (he estado en reuniones de scrum donde nadie realmente escucha y todos simplemente comentan lo que hicieron ayer y se van. Estos equipos generalmente alcanzan un equilibrio como: "No te cuestionaré y no harás desorden". conmigo "y muévete allí. Eso es solo una pérdida de tiempo), así que toma lo que sea mejor para ti.

Los veteranos generalmente tienen mucha resistencia a cualquier cosa que pueda cambiar su estilo de trabajo actual, por lo que debe asegurarse de que haya suficientes zanahorias para que puedan salir de su inercia. En este caso, yo tendría un 1: 1 con esa persona o lo haría el scrum master :). Una vez que les dé la responsabilidad, encontrarán la paz con él o la eliminarán completamente porque no está agregando valor. Ambos son ganar ganar.