¿Es Agile la nueva microgestión?

76

Esta pregunta ha estado cocinando en mi cabeza por un tiempo, así que quería preguntar a aquellos que están siguiendo prácticas ágiles / scrum en sus entornos de desarrollo.

Mi compañía finalmente se aventuró a incorporar prácticas ágiles y comenzó con un equipo de 4 desarrolladores en un grupo ágil a modo de prueba. Han pasado 4 meses con 3 iteraciones y continúan haciéndolo sin volverse totalmente ágiles para el resto de nosotros. Esto se debe al hecho de que la confianza de la administración para cumplir con los requisitos comerciales con un poco de solicitud de tipo ad hoc desde arriba.

Recientemente, hablé con los desarrolladores que forman parte de esta iniciativa; Me dicen que no es divertido. No se les permite hablar con otros desarrolladores por su maestro Scrum y no se les permite realizar llamadas telefónicas en el área de trabajo (lo que quizás esté bien hasta cierto punto). Por ejemplo, si quiero hablar con mi amigo para saber quién está en el equipo ágil, no se me permite sin la aprobación del maestro Scrum; quién está sentado justo al lado del equipo ágil.

La idea de todo esto o de lo ágil es proporcionar un vacío completo para los desarrolladores ágiles de cualquier interrupción y hacer que pasen más de 6 horas productivas. Bueno, muchachos, no soy un gurú ágil, pero lo que he leído es un documento de despliegue ágil de Yahoo y similar para otras organizaciones, me da la sensación de que ágil no es barato. Requiere recursos y presupuesto para inculcar de forma ágil en los equipos y corregir el problema a medida que llegan para volver a encarrilarlos.

Para empezar, se requiere capacitación para desarrolladores y capacitación para gerentes, etc, etc. El maestro Scrum actual era un gerente que tomó un par de días en una clase de capacitación ágil pagada por la gerencia que ahora dirige este equipo ágil. También he escuchado en la reunión que el manifiesto ágil no dicta que ágil no está escrito en piedra y se personaliza de manera diferente para cada empresa. Bueno, todo suena bien y razón.

En conclusión, siempre pensé que se suponía que Agile traería armonía a los equipos de desarrollo, lo que se traducía en desarrolladores felices. Sin embargo, tengo una sensación muy opuesta al hablar con los desarrolladores en el equipo ágil. No están contentos de no poder hablar más que de trabajar, sentarse tranquilamente todo el día trabajando, y sienten que es solo otra forma en que la administración puede hacer que trabajen más.

Dígame, por favor, si este es uno de los ejemplos de buenas prácticas utilizadas con el propósito de obtener una ventaja egoísta por más dólares. O tal vez, solo somos nosotros, los desarrolladores como yo, y este equipo ágil siente que no les gusta trabajar en un entorno en el que solo respiran porque están trabajando.

Es una empresa en el ámbito de la salud que tiene oficinas en todo EE. UU. Definitivamente, se siente como un estilo de vaquero ágil, lo que realmente hace que no quiera ir por el ágil, especialmente en mi empresa actual.

Todo tiene que ver con que la administración sea completamente barata. Recortar el café caro para obtener una versión más barata, hacer hincapié en los ahorros y ser productivo mientras se mantiene lo más magro posible.

Mi sensación es que alguien de la gerencia detrás de la puerta rechazó esta idea, que ágil te hace producir más para que podamos demostrar a nuestros jefes que estamos produciendo más con el mismo personal. O, tal vez, nos permitirá reducir el número de empleados si ese es el caso.

Tienen su reunión diaria de 5 minutos. Pero no se le permite chatear o hablar con alguien fuera de su equipo. Todo el enfoque está en el trabajo.

    
pregunta 5 revs, 4 users 68%Smith James 16.08.2018 - 21:23

14 respuestas

87

Usted está describiendo la dictadura gerencial, no ágil. Agile tiene que ver con el desarrollo incremental en un campo de requisitos cambiantes, no se trata de dictar a las personas cómo deben hacer su trabajo individualmente.     

respondido por el Sami Lehtinen 15.03.2011 - 18:08
46
  

No tienen permitido hablar con otros desarrolladores por su Scrum master y no tienen permitido hacer llamadas telefónicas en el área de trabajo

Esto realmente no es parte de las prácticas ágiles, y es un tema aparte.

Una gran motivación de las metodologías ágiles es mayor comunicación entre desarrolladores. La restricción de la comunicación entre desarrolladores y lt; - > es un problema aparte de las prácticas ágiles. No estoy diciendo que esto no esté sucediendo; obviamente lo está, y está siendo etiquetado como parte del despliegue "ágil" en su organización, pero este es realmente un tema separado del ágil (y algo en contra del espíritu de desarrollo ágil, OMI).

    
respondido por el Reed Copsey 15.03.2011 - 18:04
31

Eso suena como una implementación bastante perversa de ágil. Agile, en todo caso, debería reducir la microgestión, no aumentarla. El equipo se compromete y parte del proceso es que la administración confía en que el equipo lo logrará. El scrum diario es una forma para que los desarrolladores se comuniquen entre sí y una forma de informar lo que hicieron, no cómo pasaron su tiempo (que es un error que he visto en algunos lugares). Incluso el proceso de estimación debería eliminar el tiempo explícito de las estimaciones, ya que debería estimar la complejidad relativa, no cuánto tiempo tomará una historia (otro error común). Controlar el tiempo empleado por los desarrolladores es el sello distintivo de la microgestión, y eliminar el tiempo del proceso es uno de los principios básicos de ágil.

    
respondido por el jjb 15.04.2015 - 17:05
23

Esto no es ágil.

En primer lugar, Scrum no es ágil . Scrum, francamente, es una tontería. Me criaron en una casa de Programación Extrema (literalmente, he hecho que Kent Beck se siente en el sofá de mi papá y me hable sobre las pruebas), y puedo decirle que Scrum no lo es. Scrum es una herramienta de gestión de proyectos, un ritmo definido para un proyecto de desarrollo. Pero no tiene nada que decir sobre el desarrollo en sí, y muy poco que decir sobre los requisitos, la planificación y la relación con el cliente. XP tiene mucho que decir sobre todo eso; Cualquier otra metodología que quiera llamarse ágil debe tener algo que agregar a la conversación. Los defensores de Scrum lo han descrito no como un proceso, sino como un envoltorio para un proceso. Un sabio señaló una vez que un envoltorio es lo que quitas y descartas para llegar a lo bueno.

Está bien, ¡scrum rant over!

En segundo lugar, un principio fundamental de XP, que creo que es fundamental para cualquier proceso ágil, es que está centrado en el desarrollador . Es una forma de darles a los desarrolladores el poder de hacer el trabajo que saben que necesitan hacer, y se les impide con tanta frecuencia. Un equipo ágil puede estar estructurado como una democracia o una autocracia, pero los líderes son desarrolladores. Hay roles para los gerentes de proyecto y demás, roles vitales, pero no es uno de liderazgo de equipo. Contar con un gerente, lo siento, 'scrum master', es una señal segura de que el equipo no se está haciendo ágil '.

Siento que debería haber un tercero. No hay.

    
respondido por el Tom Anderson 16.03.2011 - 00:24
23

El entorno que describe suena como una variedad de jardín mierda pseudo-ágil .

Me involucré con Agile antes de que fuera Agile. Alrededor del año 2000 me estaba quemando la codificación, escuché sobre Programación Extrema, lo probé y me gustó. Como desarrollador, me dio un contexto en el que producir software sólido era lo más importante, y me dio herramientas para minimizar gran parte de las tonterías que me estaban volviendo loco. Me encantó.

El problema actual, que explico en detalle en otra parte , es que la mayoría de las personas que "adoptan Agile" en estos días no están interesadas en mejorar nada si les incomoda. Así que para ellos, "Agile" es solo un nuevo palo para vencer a los desarrolladores de la misma manera. A diferencia de, digamos, una forma de aumentar radicalmente la productividad mientras se eliminan todas las tonterías que ralentizan el desarrollo.

Ahora mismo. Estoy empezando una empresa y usaré muchos XP, además de un montón de otros trucos que me apoyé en el mundo ágil. Pero precisamente por historias como la tuya, me estremezco cada vez que escucho sobre una adopción Agile en estos días.

Entonces, para responder directamente a tu pregunta: Agile no debería ser la nueva microgestión. Se debe tratar de capacitar a las personas que realizan el trabajo real para que hagan la mierda. Pero en tu caso, Agile suena como la última mentira que te están contando mientras se entregan a sus propios malos instintos. Por lo que realmente lo siento.

    
respondido por el William Pietri 16.03.2011 - 00:39
16

Scrum es el hijo bastardo de Agile. Es la metodología más ágil de todas las metodologías ágiles, y por eso es la más popular entre los gerentes.

Todos los métodos ágiles consisten en producir código de trabajo sin que la basura se interponga. Lea eso otra vez. Y otra vez.

Cualquier cosa que se interponga en el camino de esa meta, independientemente de las "reglas ágiles" es mala. Si las reglas se interponen, cambia las reglas f * * . Esa es la forma ágil, eso es lo que la hace relevante y efectiva.

El mejor ejemplo de esto lo da Alistair Cockburn (uno de los creadores del manifiesto ágil):

  

“Poner 4-6 personas en una habitación con   estaciones de trabajo y pizarras y   Acceso a los usuarios. Haz que entreguen   Ejecutando, software probado para los usuarios.   cada uno o dos meses, y de otra manera   déjalos en paz ”.

Si eso funciona para la calidad de los hombres que tienes, entonces eso es todo lo que necesitas. No necesitas un scrum master o cualquier metodología "ágil". Si sentarse en un scrum diario funciona para ti, entonces f * * * hazlo. Hacer que te pongas de pie es una abrogación patética de tu capacidad de pensar por ti mismo.

Hay una respuesta a la clase de ágil que estás haciendo. Es esto. Imprímalo y fíjelo en algún lugar donde no haya nadie más y déjelos descubrirlo por sí mismos.

    
respondido por el gbjbaanb 11.06.2011 - 02:01
11
  

El maestro Scrum actual era un gerente que tomó un par de días en una clase de capacitación ágil pagada por la administración y ahora está liderando este equipo ágil.

Ese es tu problema. Las administraciones quieren algo de Ágil, realmente no saben qué es y lo imponen a los equipos. Eso es más o menos lo que debe hacer cuando desea disminuir significativamente la productividad de sus desarrolladores;)

La nueva propuesta de proceso debe provenir de los desarrolladores. O al menos debe ser revisada & aprobado por ellos si es una idea de la gerencia.

En cualquier caso, si los desarrolladores lo rechazan, no lo implemente . O será el desastre que describas.

    
respondido por el user2567 15.03.2011 - 18:23
9

"Agile" y todas las demás "metodologías de gestión" se utilizan con frecuencia para forzar la microgestión en las personas. OTOH también se abusa a veces para defender la mano de obra deficiente.

"Somos ágiles" es la excusa más frecuente que escucho por falta de planificación, falta de pensamiento sobre el diseño, las características, la calidad, los ciclos de lanzamiento. Esto por lo general de los desarrolladores y una gestión inferior Es también la excusa más frecuentemente usada que escucho de los gerentes intermedios, arquitectos, vendedores, etc. para la microgestión, las fechas límite siempre cambiantes y las listas de características, lo que obliga a las personas a realizar horas extraordinarias (las fechas límite siempre cambiantes y las listas de características aseguran que, por supuesto), etc. .

Por supuesto, los dos a menudo están en contradicción directa, y pueden ocurrir en el mismo proyecto.

    
respondido por el jwenting 16.03.2011 - 12:55
7

Para responder a tu pregunta original, Agile es la nueva microgestión, diría que no.

Primero, ve a leer this (manifiesto Agile) y notarás que no hablar con tus co-desarrolladores no está en la lista.

En realidad, "Personas e interacciones" es exactamente lo contrario de no hablar con tus co-desarrolladores.

    
respondido por el Ian 15.03.2011 - 20:07
2

Agile debe ser la nueva autogestión. Si ágile se practica correctamente, muchas de las decisiones las toma un cliente y un desarrollador que trabajan en una historia de usuario de alcance razonable que se agrega a la acumulación como tareas son identificados.

El scrum diario tiene que ver con la comunicación, no con la administración. Habrá algunas discusiones sobre la prioridad y el equilibrio de carga, pero la persona administrada en el scrum es, con suerte, el scrum master. Como desarrollador, asisto, digo lo que hice, lo que voy a hacer y la ayuda que necesito. Luego, el scrum master debería entrar en acción para eliminar los impedimentos de mi progreso.

Los equipos ágiles no deben sentir que el trabajo del día a día se administra jerárquicamente. Si alguien que está en la cima de una organización jerárquica toma las decisiones desde lejos, ¡es hora de que se descentralice la toma de decisiones! Para algunas personas y algunas organizaciones, esto puede ser un puente demasiado lejos. Si lo siguiente no es cierto para su organización:

Vive el Manifiesto ágil

  

"Estamos descubriendo mejores formas de desarrollar software al hacerlo y   ayudando a otros a hacerlo ".

Evita "Conoce al nuevo jefe, Igual que el antiguo jefe" Genera Agile desde dentro del equipo tanto como sea posible. A veces esto sucede al elegir una coalición de los que desean participar en un proyecto de prueba con Agile. Si puede formar su equipo Agile a partir de voluntarios o miembros invitados que tienen un historial de buen trabajo en equipo, pueden resolverlo. Utilice un equipo pequeño en un proyecto corto, tal vez para un cliente interno o altamente accesible.

Adopte el cambio. Tal vez pueda tomar algo de entrenamiento, pero quizás su presupuesto sea ajustado y el dinero simplemente no esté allí. Otras oportunidades pueden proporcionar mejoras también. Lea un poco, haga que los miembros del equipo aprendan lo que puedan sobre Agile y se enseñen unos a otros. Es posible que pueda encontrar personal nuevo o existente calificado para modelar y liderar la adopción Agile.

    
respondido por el DeveloperDon 20.12.2012 - 05:40
1

Los equipos ágiles son como los equipos de fútbol que trabajan para alcanzar un objetivo común. He sido parte de equipos ágiles durante algunos años y la clave es la comunicación efectiva y eficiente entre todos los interesados. Los administradores / Scrum masters son simples facilitadores del equipo y la administración tradicional / micro gestión matará el espíritu del equipo.

En los equipos en los que he trabajado, se nos anima a jugar juegos de equipo después de las horas de trabajo para mejorar la camaradería entre los miembros. He recopilado esos pensamientos aquí .

    
respondido por el Vinod R 11.06.2011 - 08:58
0

Para responder a su pregunta: No. Agile no es una forma de microgestión. Pero como cualquier herramienta, la gente puede usarla incorrectamente. Agile es maravilloso cuando se implementa correctamente y cuando las personas son coherentes con él.

Mi opinión sobre el tema "Devs no habla con nadie más que con el scrum master":

He trabajado en un lugar donde antes era una regla. SIN EMBARGO, la regla se relacionó más con pedirle a las personas que completen tareas. Por ejemplo, no puedo acudir aleatoriamente a un probador de desarrollo y pedirles que realicen algunas pruebas en las próximas horas. Necesito hablar con el scrum master para que puedan discutir con el miembro de su equipo cómo encajará ese trabajo en el sprint si se trata de una emergencia (o si es necesario enviarlo al backlog para un sprint futuro).

En ese caso, entendí el concepto de "los desarrolladores no se hablan entre ellos" porque realmente se tradujo en canalizar tareas a través de un punto de control, por lo que un desarrollador en particular no está sobrecargado de trabajo o está tan ocupado haciendo tareas de emergencia que no pueden hacer su trabajo planeado.

De lo contrario, los desarrolladores DEBERÍAN estar hablando entre ellos. Siempre. Le ayuda a resolver los problemas con mayor rapidez, a acercarse como equipo y a entregar más rápido.

Solo para ofrecer otra perspectiva: También he estado en un entorno donde la gente pensaba que los desarrolladores "hablaban demasiado". Después de una reunión, descubrimos que en realidad se traducía a "los desarrolladores no son lo suficientemente independientes para realizar su propio trabajo. Debido a que todo está muy fragmentado, los desarrolladores tienen que ir a otras tres personas para completar una pequeña tarea".

Entonces, cuando los gerentes decidieron cambiar a Agile, esperaban que eso ayude a llevar la información a los lugares correctos y detenga gran parte de la fragmentación dentro de la organización. Algunas personas se sintieron un poco decepcionadas de que, después de la implementación de Agile, los desarrolladores siguieran corriendo entre ellos. Pero, lo que no se dieron cuenta es que estaba pasando cada vez menos. Aunque tomó tiempo. Entonces, tal vez si eso es lo que está sucediendo en su organización, podría ser que las personas esperen ágil para arreglar las cosas de la noche a la mañana. Esa no es la forma en que funciona.

    
respondido por el JustBlossom 16.08.2018 - 22:43
-1

El autor original Smith Janes podría haber dado experiencia. Pero estos son los problemas típicos que encontré en el proyecto Agile.

  1. La mayoría de las organizaciones, los desarrolladores deben trabajar en proyectos múltiples, en Agile / scrum. Los Sprints nunca se consideran este hecho. su Scrum Master asume que debería haber terminado con sus historias al final del sprint. Su Scrum master podría estar dedicado a un solo proyecto, pero no a los desarrolladores. ESTA ES LA DISTRACCIÓN: no es necesario que solo esté tomando una llamada telefónica o permitiendo una llamada telefónica.
  2. He visto proyectos ágiles en los que se planea Sprint, Historias incluidas en Sprint, sin estar amontonado ... en la mitad o la mitad de los sprints ... los desarrolladores encuentran dependencias no resueltas, los requisitos o la historia no se completan narrados ... .. Este es uno de los Abusos en los proyectos más ágiles.
  3. Pruebas: TTD ... sí, es muy bueno ... pero he visto que la mayoría de los proyectos Agile se basan totalmente en TTD ... no se permite el alcance ni el tiempo para las pruebas funcionales o humanas. Otro abuso ... Mucho Scrum Masters tampoco sabe ni comprende la importancia de las pruebas funcionales. Su pieza de código podría estar funcionando a la perfección, si no satisface las necesidades de la empresa ... no sirve de nada ... Esto sucede cuando las empresas no participan con mucha antelación ... o la participación está ahí ... pero no refleja la toma de decisiones de negocios .. Al final, se culpa a los desarrolladores, usted no entregó la funcionalidad ... o terminará con un cambio de última hora ... horas extra largas porque su maestro Scrum no quiere responsabilizarse por la historia no completada.

Abuso aquí ... ya sea una baja participación de la empresa o un participante que no tenga un conocimiento completo o una persona de negocios que abandona la escuela en medio del sprint.

  1. No todos los proyectos son adecuados para Agile ... La mayoría de los gerentes o scrum masters no lo saben. Los proyectos de mantenimiento ... Se puede asumir inicialmente que un defecto puede hacerse en 8 horas, aceptado en el sprint. Después de pasar 4 horas, encontré que este es Java / otro producto ... (Recientemente me enfrenté a un problema relacionado con Quartz Scheduler ... dentro de nuestro proyecto) y este defecto podría llevar a la actualización del producto / paquete ... con burocracia, aprobación, La financiación, la nueva versión o actualización debe ser aprobada por Ingeniería interna, etc. 5.Retrospección: solo un puñado de proyectos ágiles realiza este paso ... Si se hace ... Administración, Scrum Master nunca se responsabilizó de las historias fallidas.
  2. Emparejamiento ... Muchos desarrolladores tratan el emparejamiento como un lugar para abusar de los compañeros de trabajo ... critican otros diseños, prácticas de codificación ... los tratan como un trabajo en equipo, aprenden unos de otros ... Otra forma de abusar de Agile / Scrum.

Definitivamente, Agile es una buena metodología ... A menos que su organización no siga completamente o no esté capacitada ... Se maltrate ... efectos secundarios más de 60 horas de trabajo / semana, juego de culpas, baja moral.

    
respondido por el mukunda 10.03.2013 - 21:31
-3

Agile es la microgestión disfrazada. No hay lugar para la iniciativa o la creatividad en Agile, ha eliminado la diversión de la programación para permitir a los administradores incompetentes mantener el control incluso sin tener una idea desde el punto de vista técnico.

    
respondido por el geo 02.05.2013 - 00:41

Lea otras preguntas en las etiquetas

Comentarios Recientes

Antes de comenzar mi propia comparación de personajes, tomemos un minuto para hablar sobre las palabras "agencia" y "método". Bueno, siento que una cucharadita de jabón es suficiente para hacer el trabajo aquí. Básicamente, la tecnología significa que tienes el trabajo correcto y privilegiado. Tal vez no ganes las decenas de miles de dólares que gana un líder tradicional, pero obtienes todas las cosas geniales que generalmente tratamos como privilegios. En ese sentido, la agilidad, en este momento, todavía... Lee mas