Escéptico en un equipo Scrum

Mi empresa ha cambiado recientemente a una forma de trabajo ágil y, como parte de ella, comenzamos a usar SCRUM. Si bien me siento muy cómodo con esto y siento que esta forma es superior a la tradicional, algunos de mis compañeros de equipo no comparten la misma opinión. De hecho, son muy escépticos acerca de "todas esas cosas ágiles", y no lo toman en serio. Como ejemplo, uno de los compañeros de equipo siempre llega tarde a las reuniones y realmente no le importa. La administración de la OMI trata de no darse cuenta de esto (tal vez porque es nuevo, y lleva tiempo que las personas se acostumbren).

Mi pregunta es, ¿cómo abordar este problema sin generar un conflicto dentro del equipo?

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

1.) demuestran técnicas como TDD, distribución continua, la programación en parejas, recopilación de requisitos con sus usuarios, etc. iteraciones cortas que no llamar a esas técnicas ágiles o arpa en aproximadamente el manifiesto ágil (hago arpa en acerca de Software Artesanía - pero eso es diferente; p). Simplemente muestro a los miembros del equipo herramientas y técnicas útiles que les hacen la vida más fácil. Tienden a subirse al tren ágil una vez que ven los beneficios día a día.

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

3.) Estoy de acuerdo con los escépticos (hasta cierto punto). Ágil no es una bala de plata y SCRUM, Kanban, Lean, etc. tampoco son una bala de plata. En cambio, trabajo con ellos para ver qué aspectos podrían beneficiarlos de inmediato (un servidor de CI suele ser obvio) y luego pruebo el resto "Vamos a probar los stand-ups por una semana y luego lo reviso".

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

Entonces, para llegar directamente a su pregunta. Elevarlo con el equipo:

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

Un caso típico de Scrum implementado incorrectamente .

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

Cuando desee implementarlo, debe contar con el apoyo total tanto del equipo como de la administración, o no funcionará en absoluto.

La resistencia al cambio es tu enemigo aquí.

Le recomiendo que comience de nuevo y presente Scrum al equipo y deje que hagan preguntas.

Si no vende la idea, no intente forzarlos utilizando una metodología que no desean. Harán todo lo posible para sabotearlo. Llegar tarde a las paradas diarias es uno de los comportamientos que obtendrá.

Tenga en cuenta que Scrum puede no ser aconsejable 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á haciendo requiere mucha concentración a largo plazo, como matemáticas intensas, las reuniones pueden desanimarlo y ser frustrante. Trabajo con alguien así, que prefiere reunirse semanalmente, lo cual es perfectamente razonable.

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

¿Realmente importa si no se sube a bordo? Solo tiene que asignarle algunas tareas de programación y dejar que lo haga como quiera. Si su trabajo es satisfactorio, que lo sea. Si su trabajo no es satisfactorio, reemplácelo. ¿Por qué es tan importante que las personas sigan scrum?

A lo largo de los años, he visto a muchos buenos programadores renunciar o molestarse 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 ágil, entonces debe tener una acumulación de trabajo desde el que está trabajando. Use el scrum para repartir las tareas del trabajo atrasado.

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

No importa si es el regalo de Dios para la programación, tiene la tarea horrible que nadie más quería. Si intenta forjar otra tarea o trabajar en otra cosa, el equipo en su conjunto debe 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.

Además, el equipo debe establecer 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 administración de 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 Scrum se autoorganizan. Scrum también funciona implementando una transparencia extrema en todo.

Entonces, la respuesta obvia es que el 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 dice 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. Entonces la clave es que el Scrum Master tiene que aceptar cualquier respuesta que el equipo presente. Si los anula o impone sus propias ideas en la solución, destruirá la confianza que el equipo necesita para construir con él y que se les permite 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 se les ocurra.

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

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

Examine su trabajo anterior, descubra varios ejemplos de cómo el enfoque de caída de agua le ha decepcionado muchas veces en el pasado. Luego presente los casos a su compañero de equipo. Con un atisbo de sentido común, verá la luz.

La programación es una actividad de precisión, por lo que una persona rara no se mostraría receptiva a los hechos concretos. Al menos, en teoría.

¿Quién tomó la decisión de cambiar y por qué? ¿Dónde estaban esos escépticos en la decisión o la decisión simplemente se les cayó?

¿Estás siendo demasiado rígido y / o rápido en la implementación de tus nuevos métodos? ¿Sacaste productos buenos (no necesariamente perfectos) usando tus viejos métodos? ¿Has demostrado a los escépticos cómo los beneficiará? ¿Puedes demostrarlo? ¿Los que han "visto la luz" han demostrado a los escépticos cómo les 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 obtenido beneficios.

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

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

Tenga una reunión de equipo para discutir y descubrir por qué su empresa cambió a SCRUM y hacer que todos identifiquen lo que piensan acerca de SCRUM agregaría valor al modo de operación actual. A veces las empresas hacen interruptores descabellados (he estado en reuniones de scrum donde nadie realmente escucha y todos simplemente dicen lo que hicieron ayer y se van. Estos equipos generalmente alcanzan un equilibrio como: "No te cuestionaré y no te metas" conmigo "y caminar 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, tendría un 1: 1 con esa persona o lo convertiría en el maestro scrum :). Una vez que les dé responsabilidad, encontrarán la paz o la eliminarán por completo porque no está agregando valor. Ambos son ganar ganar.