¿Es Agile la nueva microgestión?

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

Mi empresa 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 ser completamente ágiles para el resto de nosotros. Esto se debe al hecho de que la gerencia confía en cumplir con los requisitos comerciales con una solicitud de tipo ad hoc desde arriba.

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

La idea de todo esto o lo ágil es proporcionar un vacío completo a 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 el 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 a los equipos con agilidad y corregir el problema a medida que llegan para volver a encaminarlos.

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

En conclusión, siempre pensé que se suponía que el ágil traería armonía en los equipos de desarrollo, lo que da como resultado desarrolladores felices. Sin embargo, tengo una sensación muy opuesta cuando hablo con los desarrolladores del equipo ágil. No están contentos porque no pueden hablar más que trabajar, se sientan en silencio todo el día solo trabajando, y sienten que es solo otra forma para que la gerencia los haga trabajar más.

Dígame, por favor, si este es uno de los ejemplos de buenas prácticas utilizadas con el fin 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 donde solo respiran porque están en el trabajo.

Es una empresa en el dominio de la salud que tiene oficinas en los Estados Unidos. Definitivamente se siente como un ágil estilo vaquero, lo que me hace realmente no querer ir para ágil en absoluto, especialmente en mi empresa actual.

Todo tiene que ver con que la administración sea completamente barata. Recorte el café caro para una versión más barata, enfatice el ahorro y sea productivo mientras se mantiene lo más delgado posible.

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

Están teniendo su reunión diaria de 5 minutos. Pero no está permitido chatear o hablar con alguien fuera de su equipo. Todo el foco está en el trabajo.

Estás describiendo una dictadura gerencial, no ágil. Agile trata sobre el desarrollo incremental en un campo de requisitos cambiantes, no sobre dictar a las personas cómo hacen individualmente su trabajo.

El maestro Scrum no les permite hablar con otros desarrolladores y no pueden atender ninguna llamada telefónica en el área de trabajo.

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

Una gran motivación de las metodologías ágiles es una mayor comunicación entre los desarrolladores. Restringir la comunicación del desarrollador <-> desarrollador es un problema separado 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 problema separado de ágil (y algo en contra del espíritu de desarrollo ágil, OMI).

Eso suena como una implementación bastante perversa de ágil. Ágil, en todo caso, debería reducir la microgestión, no aumentarla. El equipo se compromete y parte del proceso es que la gerencia 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 (lo cual 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 debe estimar la complejidad relativa, no cuánto tiempo llevará una historia (otro error común). Controlar el tiempo dedicado 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 Agile.

El entorno que describe suena como una variedad de jardín pseudo-Agile bullshit .

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

El problema hoy en día, lo que explico en detalle en otra parte , es que la mayoría de las personas que adoptan "ágil" en estos días no están interesados en la mejora de nada si los hace sentir incómodos. Entonces, para ellos, "Agile" es solo un nuevo palo para vencer a los desarrolladores de la misma manera. A diferencia de, por ejemplo, una forma de aumentar radicalmente la productividad mientras se eliminan todas las tonterías que están ralentizando el desarrollo.

Ahora mismo. Estoy comenzando una compañía, y usaré muchos XP, además de otros trucos que aprendí en el mundo Ágil. Pero precisamente por historias como la suya, me estremezco cada vez que escucho sobre una adopción ágil en estos días.

Entonces, para responder a su pregunta directamente: Agile no debería ser la nueva microgestión. Debería tratarse de empoderar a las personas que hacen el trabajo real para hacer una mierda. Pero en su caso, Agile suena como la última mentira que le están diciendo mientras se complacen con sus propios malos instintos. Por lo cual realmente lo siento.

Esto no es ágil.

En primer lugar, Scrum no es ágil . Scrum, francamente, es una mierda. Fui criado en una casa de Programación Extrema (literalmente, hice que Kent Beck se sentara en el sofá de mi padre y me hablara sobre las pruebas), y puedo decirte 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 contenedor para un proceso. Un hombre sabio señaló una vez que un envoltorio es lo que se quita y desecha para llegar a lo bueno.

¡Bien, scrum despotricando!

En segundo lugar, un principio fundador de XP, que creo que es fundamental para cualquier proceso ágil, es que se centra en el desarrollador . Es una forma de dar a los desarrolladores el poder de hacer el trabajo que saben que deben hacer, y con tanta frecuencia se les impide hacerlo. Un equipo ágil puede estructurarse como una democracia o una autocracia, pero los líderes son desarrolladores. Hay roles para gerentes de proyectos y demás, roles vitales, pero no es uno de liderazgo de equipo. Tener un gerente, lo siento, 'scrum master', sentado allí dando órdenes a la gente es una señal segura de que el equipo no está siendo ágil.

Siento que debería haber un tercero. No hay

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

Todos los métodos ágiles tienen que ver con la producción de código de trabajo sin que se interfieran. Lee eso de nuevo. Y otra vez.

Cualquier cosa que se interponga en el camino de ese objetivo, independientemente de las "reglas ágiles" es malo. Si las reglas se interponen, ¡cambie las reglas f * * ! Esa es la forma ágil, eso es lo que lo hace relevante y efectivo.

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

“Ponga a 4-6 personas en una sala con estaciones de trabajo y pizarras blancas y acceso a los usuarios. Haga que entreguen software probado y en ejecución a los usuarios cada uno o dos meses, y de lo contrario déjenlos en paz "

Si eso funciona para la calidad de los chicos que tienes, entonces eso es todo lo que necesitas. No necesita un scrum master ni ninguna metodología "ágil". Si sentarse en un scrum diario funciona para usted, entonces f * * * hágalo. Hacerles ponerse de pie es simplemente una patética abrogación de su capacidad de pensar por sí mismos.

Hay una respuesta al tipo de agilidad que estás haciendo. Es esto. Imprímalo y péguelo en algún lugar cuando no haya nadie más y déjelo descubrirlo por sí mismo.

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

Ese es tu problema. Los directivos quieren algo ágil, realmente no saben qué es, y se 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 debería provenir de los desarrolladores. O al menos ser revisado y 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.

Con frecuencia se abusa de la "metodología de gestión" "ágil" y de cualquier otra para forzar la microgestión en las personas. OTOH también a veces se abusa de defender la mala mano de obra.

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

Los dos, por supuesto, a menudo están en contradicción directa, y pueden suceder en el mismo proyecto.

Para responder a su pregunta original, ¿es Agile la nueva microgestión? Yo diría que no.

En primer lugar, ir a leer esto (manifiesto ágil) y se dará cuenta de que no hablar con sus compañeros de los desarrolladores no está en la lista.

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

Ágil debería ser la nueva autogestión. Si ágil se practica correctamente, muchas de las decisiones son tomadas por un cliente y desarrollador que trabaja una historia de usuario de alcance razonable que se agrega al trabajo a medida que se identifican las tareas.

El scrum diario se trata de comunicación, no de gestión. Habrá algunas discusiones sobre prioridad y equilibrio de carga, pero es de esperar que la persona administrada en el scrum sea el maestro de scrum. Como desarrollador, asisto, digo lo que hice, lo que voy a hacer y qué ayuda necesito. Entonces, el scrum master debería ponerse en acción y eliminar los impedimentos para mi progreso.

Los equipos ágiles no deben sentir que el trabajo diario se gestiona jerárquicamente. Si las decisiones se toman desde lejos por alguien en la cima de una organización jerárquica, ¡es hora de descentralizar 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 haciéndolo y ayudando a otros a hacerlo".

Evite "Conozca al nuevo jefe, igual que el antiguo jefe". Originar Agile desde dentro del equipo tanto como sea posible. A veces esto sucede al elegir una coalición de personas dispuestas a participar en un proyecto de prueba con Agile. Si puede formar su equipo Agile a partir de voluntarios o miembros invitados que tengan un historial de buen trabajo en equipo, pueden resolverlo. Use un equipo pequeño en un proyecto corto, tal vez para un cliente interno o altamente accesible.

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

Los equipos ágiles son como los equipos de fútbol que trabajan para alcanzar un objetivo comúnmente entendido. He sido parte de equipos ágiles durante algunos años y la clave es una comunicación efectiva y eficiente entre todos los interesados. Los gerentes / maestros de Scrum son meros facilitadores del equipo y la gestión tradicional / microgestió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 del horario laboral para mejorar la camaradería entre los miembros. He recogido esos pensamientos aquí .

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

Mis pensamientos sobre el tema "Los desarrolladores no hablan 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 la gente que completara tareas. Por ejemplo, no puedo ir al azar a un probador de desarrollo y pedirle que haga algunas pruebas por mí en las próximas horas. Necesito hablar con el maestro scrum para que puedan discutir con el miembro de su equipo cómo ese trabajo encajará en el sprint si se trata de una emergencia (o si es necesario llevarlo a la cartera de pedidos para un sprint futuro).

En ese caso, entendí el concepto de "desarrolladores que no se hablan entre sí" porque realmente se tradujo en canalizar tareas a través de un punto de control para que un desarrollador en particular no trabaje demasiado o esté tan ocupado haciendo tareas de emergencia que no pueden obtener su planificado trabajo hecho.

De lo contrario, los desarrolladores DEBEN estar hablando entre ellos. Siempre. Le ayuda a resolver los problemas más rápido, 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 sesión, descubrimos que en realidad traducido a "los desarrolladores no son lo suficientemente independientes como para hacer su propio trabajo. Debido a que todo está tan fragmentado, los desarrolladores tienen que ir a otras tres personas para completar una pequeña tarea".

Entonces, cuando los gerentes decidieron pasar a ser ágiles, esperaban que eso ayudara a llevar información a los lugares correctos y frenar gran parte de la fragmentación dentro de la organización. Algunas personas estaban un poco decepcionadas de que después de que se implementara Agile, los desarrolladores aún corrían de un lado a otro. Pero, de lo que no se dieron cuenta es que eso estaba sucediendo cada vez menos. Tomó tiempo sin embargo. Por lo tanto, tal vez si eso es lo que está sucediendo en su organización, podría ser que la gente espera que sea ágil arreglar las cosas de la noche a la mañana. Esa no es la forma en que funciona.

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

1. Se supone que la mayoría de las organizaciones, desarrolladores, trabajan en proyectos múltiples, en Agile / scrum. Los sprints nunca se consideran este hecho. su Scrum Master asume que debe terminar 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 atienda una llamada telefónica o permitir una llamada telefónica.
2. He visto proyectos ágiles donde Sprint está planeado, historias incluidas en Sprint, sin estar acurrucados ... a mitad o mitad de los sprints ... desarrolladores que encuentran dependencias no resueltas, requisitos o historias no narradas ... Esto 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 dependen totalmente de TTD ... no se permite el alcance ni el tiempo para pruebas funcionales o humanas ... Otro abuso ... Muchos Scrum Masters también No sé ni entiendo la importancia de las pruebas funcionales. Su código podría funcionar perfectamente, si no sirve a la necesidad comercial ... no sirve de nada ... Esto sucede cuando las empresas no participan con mucha anticipación ... o la participación está ahí ... pero no refleja la toma de decisiones comerciales Al final, se culpa a los desarrolladores, no entregaste la funcionalidad ... o terminará con un cambio de último minuto ... horas extra largas porque tu Scrum master no quiere culpar por la historia no completada.

Abusar aquí ... ya sea una baja participación de la empresa o un participante que no tiene todos los conocimientos o una persona de negocios que abandona en medio del sprint.

1. No todos los proyectos son aptos para Agile ... La mayoría de los gerentes o maestros de scrum no lo saben. Proyectos de mantenimiento. Inicialmente se puede asumir que un defecto se puede hacer en 8 horas, aceptado en el sprint. Después de pasar 4 horas, descubrí que esto es Java / otro producto ... (recientemente me enfrenté a un defecto relacionado con el Programador de cuarzo ... dentro de nuestro proyecto) y este defecto podría conducir a la actualización del producto / paquete ... tratar con burocracia, aprobación, la financiación, la nueva versión o la actualización deben ser aprobadas por Ingeniería Interna, etc., 5.Retrospección: solo unos pocos proyectos Ágiles realizan este paso.
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 ... el calificador trata como trabajo en equipo., Aprenden unos de otros ... Otra forma de abusar de Agile / Scrum.

Ágil es definitivamente una buena metodología. A menos que su organización no siga completamente o no esté entrenada ... Se abusa ... efectos secundarios 60+ horas de trabajo / semana, juego de culpa, baja moral.

Ágil 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 gerentes incompetentes mantener el control incluso sin tener una idea desde el punto de vista técnico.