Escéptico en un equipo Scrum

14

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?

Sorantis
fuente
44
¿Qué es wow? Buscar en Google "ágil WoW-warcraft" no apareció mucho.
Joe Daley
1
@ Joe - ¿"Forma de trabajo" quizás?
ChrisF
Manera de trabajar.
Sorantis
¡Melé! no SCRUM! ¿Guau? Ágil # 1 = WoT, no WoW. Sin el WoT, el WoW es solo SNAFU. Y una de las principales formas de pensar es derribar las barreras a la comunicación, no erigir otras nuevas.
MIA
2
Agile WoW = ¿Asaltar a un jefe o dos por noche durante una semana y despejar por completo en el camino? ¿Y emparejar asaltantes / hacer revisiones DPS? Lo siento, ex jugador de WoW aquí.
Wayne Molina

Respuestas:

21

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?"

Martijn Verburg
fuente
99
@Sorantis: ¿no es realmente un problema de Agile WoW? ¡Parece que este miembro del equipo no es bueno para trabajar en equipo! Eso es más un problema de psicología / comportamiento humano y el truco para eso generalmente es descubrir qué motiva a esa persona (tanto en su comportamiento positivo como en su comportamiento negativo).
Martijn Verburg el
44
++ Cuando se impone, es como una religión, y las personas son naturalmente resistentes. Cuando se explora característica por característica es más como sentido común, y si la gente dice "pero eso es básicamente lo que hacemos de todos modos", entonces estás ganando. Creo que parte del problema con Agile es simplemente que tiene un nombre y, por lo tanto, viene de afuera.
Mike Dunlavey
1
Ahhh programación de pares: ¿ahí es donde 1 chico lee una revista mientras los otros códigos :)?
Chris S
2
@Martijn, he realizado programación de pares donde una persona tiene el mouse y la otra tiene el teclado. De esa manera, ambos deben concentrarse;)
Benjol
1
@ Mike Dunlavey: "si la gente dice" pero eso es básicamente lo que hacemos de todos modos "entonces estás ganando". ¿O tal vez estás presentando una inútil beaurocracia? si lo hacen bien de todos modos, ¿realmente necesitan sus reglas sobre cómo hacerlo?
Imre
16

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 .


fuente
1
¿Hay alguna manera de hacer que a los escépticos les guste SCRUM? Es algo débil, simplemente no lo use si no le gusta.
Sorantis
1
@Sorantis: no hay una manera fácil de hacerlo. Usted tendrá que invertir mucho esfuerzo y tiempo a explicar cómo Scrum proporcionará beneficios a ellos . La comodidad del status quo es tan importante que harán todo lo posible para mantenerlo. Incluso obligándose a no entender los beneficios. Es lo que sucede cuando impones a otros tus ideas. Tu situación es realmente difícil de resolver.
@Sorantis: sucede todos los días. Se llama ventas. Solo sigue señalando las cosas buenas que SCRUM te ha traído. ¡Mayor comunicación! Adaptándose al cambio! ¡Manteniendo el proyecto simple! No seas demasiado bueno para usar el trabajo de Pavlov. ;-) La gente responde a que le muestren, menos a que le digan. Muéstreles qué tan bien SCRUM está trabajando para usted, y lo seguirán con el tiempo.
Steve Goodman
Eso es lo que dijo Stalin.
Trabajo
Stalin dijo qué?
5

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.

Mike Dunlavey
fuente
5

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.

Antonio2011a
fuente
-1. Incluso si Scrum no está aquí para quedarse, todavía eres parte de una organización. Si esa organización decide pasar a scrum, entonces es muy poco problema seguir adelante. Si eres un buen programador y jugador de equipo, y estás dispuesto a aceptar que alguien más sabe más sobre las prioridades comerciales, entonces scrum te permitirá exactamente hacer tu trabajo, a tu manera. Si se hace bien, el scrum no debería tomar más del 10% de su tiempo. En ese 10% también ha hecho su planificación y presentación de informes. Boohoo
Kris Van Bael
1

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.

Bill Leeper
fuente
De esta manera, perderá la última oportunidad de vender Scrum a los escépticos. Imho problema real es la metodología impuesta, como sugieren otras respuestas.
Marzo
1

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.

Dave
fuente
0

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

John Saunders
fuente
1
No creo que esta sea una solución en absoluto. Es como si me doliera la mano ... Oh, vamos a cortarlo.
Sorantis
44
Depende: si la compañía ha optado por implementar SCRUM y los miembros del personal no están dispuestos a trabajar como lo requiere la empresa, entonces eso es motivo bastante clásico para el despido.
Murph
@Sorantis: más bien, "si tu mano izquierda te ofende, córtala si está cortada", o algo así. Y, advertirle primero.
John Saunders
2
@Rob: siga el proceso, deje en claro lo que se espera del escéptico y, si no está dispuesto a hacer lo que se le pide, déjelo ir o lo despida. De lo contrario, se envía un mensaje equivocado al resto del equipo: que SCRUM no importa y que todos pueden ignorarlo, al igual que los escépticos.
John Saunders
2
Ágil es sobre el equipo. Si tiene a alguien que se niega a formar parte del equipo, la gerencia debe ponerlo a prueba o dejarlo ir. A la larga, será mejor con un equipo que funcione sin problemas que con alguien que esté causando problemas. He escuchado muchas historias de equipos ágiles destruidos por una manzana podrida.
Bill Leeper el
0

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.


fuente
El caso es que soy un nuevo empleado en la empresa. Vine cuando comenzaron a usar WoW ágil. Y mi compañero de equipo trabaja en la empresa durante 15 años
Sorantis
2
Acabo de interpretar erróneamente "caída de agua" como "falla de agua" y fue el mejor cambio de nombre de un enfoque de desarrollo que he visto. ¡Increíble!
glenatron
@glenatron: Muy bien, realmente da en el clavo.
3
El problema con el enfoque de desenterrar contraejemplos es que no son buenos argumentos a favor de otras ideas específicas. A nadie le gusta la cascada, pero eso no significa que quieran unirse a Agile.
Mike Dunlavey
0

¿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?

ElGringoGrande
fuente
No soy un gerente, solo soy un miembro del equipo. La decisión ha sido tomada por la gerencia
Sorantis
0

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.

Subu Sankara Subramanian
fuente