¿Es Agile la nueva microgestión?

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.     

  

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).

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.

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.

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.

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.

  

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.

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

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.

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.

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í .

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.

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.

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.