¿Está Scrum, en la práctica, yendo en la dirección opuesta del Manifiesto para el Desarrollo de Software Ágil y sus Doce Principios?

Scrum es un muy buen punto de partida para los equipos que desean implementar y mejorar la agilidad en su organización. El problema es que muchas personas en la industria (que, como una feliz coincidencia ganan dinero haciendo consultoría y capacitación) no se centran en el hecho de que es solo un punto de partida . El objetivo principal de los principios ágiles es entregar el producto en pequeños incrementos, validar las soluciones que se están construyendo y ajustar para mejorar todo lo que está haciendo. La evolución natural de Scrum es “Scrum-but”, que se burla casi universalmente de las personas que siguen y predican “Scrum de libros de texto”. Parecen haber olvidado por completo que el manifiesto (y los principios) valoran a las personas y las interacciones sobre procesos y herramientas. . ¿Adivina qué es Scrum? Es un proceso Por lo tanto, siempre debe quedar en segundo plano ante las necesidades de las personas y las interacciones dentro de la organización, donde Scrum entra en conflicto con la mejora continua de la organización, debe doblegarse .

Cuando se aborda de esta manera, Scrum es un gran marco al que las personas pueden hacer referencia y probar para ver cómo fomenta su movimiento hacia una mayor agilidad. Pero no es suficiente en sí mismo ser “ágil”, ni es la “única palabra verdadera” ser ágil como lo ven muchas personas.

Escribí un artículo hace un tiempo sobre esto, tal vez lo encuentres interesante: Scrum es solo un punto de partida.

IME, aproximadamente el 95% de las implementaciones de Scrum van en una dirección muy diferente a la de Agile. Scrum es solo un punto de partida, como señala Cliff. Sin embargo, también es básicamente una herramienta que expone incansablemente sus problemas para que todos los vean. Las organizaciones tienen una gran elección, pueden solucionar sus problemas o pueden “doblar” Scrum para que se sientan cómodos en presencia de esos problemas. Scrum es un motor diseñado para la velocidad, no para la comodidad, por lo que las organizaciones que eligen Scrum solo para cambiarlo * en lugar de * a sí mismos * claramente han tomado una decisión desinformada de Scrum, y sentirán la necesidad de cortar todas las partes afiladas de Scrum, hasta que normalmente se convierte en una herramienta de microgestión. Cuando se usa adecuadamente, Scrum es una gran herramienta para crear equipos de alto rendimiento. Desafortunadamente, Dark Scrum parece ser la norma, especialmente en las tiendas PMI donde Scrum es visto como una técnica más de gestión de proyectos.

Para responder a esta pregunta, creo que debe diferenciar cómo Scrum se implementa comúnmente en la práctica de la intención detrás del Manifiesto Ágil.

No hay nada malo con Scrum en sí; Sin embargo, no hay duda de que algunas de las implementaciones de Scrum han sido decepcionantes. Por ejemplo, estos son algunos de los problemas que he visto:

• Algunas personas hacen Scrum “mecánicamente” sin comprender realmente los principios y valores detrás de él
• Algunas personas ven a Scrum como una solución a casi cualquier problema que pueda tener e intentan forzar todo a Scrum cuando el enfoque correcto es adaptar la metodología a la naturaleza del problema
• Algunas personas hacen Scrum rígidamente “según el libro” y no logran adaptarlo a una situación dada. A veces, por ejemplo, es posible que deba implementar Scrum en un entorno orientado a proyectos en el que es importante algún nivel de gestión general del proyecto, como un contrato ágil. Eso requiere algo de adaptación
• Algunas personas no toman una visión holística cuando intentan escalar el uso de Scrum a un nivel empresarial. En lugar de comprender cómo integrar un enfoque Scrum y Agile con el entorno empresarial de la empresa, el enfoque típico es tratar de obligar a toda la empresa a convertirse en Agile basándose en el supuesto de que todo lo que sea bueno para el proceso de desarrollo también debe ser bueno para la empresa. como un todo

Chuck Cobb
Autor de “La guía del administrador de proyectos para dominar Agile”
Echa un vistazo: Academia de gestión de proyectos ágil

Donde estoy actualmente, sí, está ayudando a los equipos.

Mis equipos (soy un Scrum Master) son bastante maduros y motivados. Trabajamos en aplicaciones bastante complejas, en un entorno de caos controlado (vagamente).

La capacidad de los equipos para ser altamente colaborativos, tener una excelente visión bidireccional de las necesidades comerciales, adaptar continuamente nuestros procesos (TDD / CICD) y, en general, estar más en contacto / sintonía.

Cualquier cosa que aumente nuestra eficiencia como grupo de desarrollo es buena.

Agile ha aumentado nuestra eficiencia general de manera cuantificable.

No me puedo imaginar cambiar a cascada, etc. en este punto.