¿Por qué la gerencia tiene que "comprar" Scrum?

Hablando por experiencia...

Una vez intenté llevar Scrum a una situación en la que:

• Actualmente teníamos poco o ningún proceso definido para el desarrollo: a las personas solo se les asignaba trabajo, lo hacían y luego obtenían más trabajo.
• Nuestro gerente directo se mostró indiferente/ligeramente hostil (piensa: "No me gusta esta forma novedosa de hacer las cosas, pero te dejaré trabajar como quieras. Solo mantenme al margen").
• El equipo estaba relativamente entusiasmado pero acostumbrado a una mentalidad no ágil
• El CEO estaba muy orientado a las cascadas (y se comunicaba solo con otros ejecutivos, que también tenían mentalidad de cascadas).
• Yo, alguien que tenía 3 meses de experiencia como desarrollador en Scrum, fui elegido como Scrum Master (ya que nadie más sabía nada al respecto), sin presupuesto para capacitarme ni contratar un Agile Coach.

Ahora bien, si bien esto puede sonar como un desastre, no fue... terrible. Completamos nuestro gran proyecto de 2 años solo con medio año de retraso y habiendo completado todas las funciones.

Sin embargo, podríamos haberlo hecho mejor.

Tratamos de mantener al gerente al tanto de nuestro proceso y estado, pero se sentía cada vez más incómodo (debido a lo extraño que lo encontraba) y, finalmente, simplemente no quería saber nada de él... y luego se molestó por haber sido tomado por sorpresa por un cierta demora en el proyecto que, de haber estado involucrado, podría haber mitigado.

Como señalé, completamos todas las funciones... porque una vez que se acepta una función, debe incluirse... incluso si los usuarios realmente nunca la quisieron en primer lugar. Había algunas características que, años después, nunca se habían utilizado ni una sola vez. Si hubiéramos comenzado desarrollando un Producto Mínimo Viable y luego solicitando requisitos adicionales, esas características se habrían marchitado y muerto. Pero se nos prohibió mostrar el producto incompleto a los usuarios.

No obstante, tanto mi equipo como yo sentimos, al final, que nuestro enfoque destrozado y medio Scrum era mejor que el que habíamos tenido antes. No nos arrepentimos de intentarlo, incluso sin la aceptación de las partes interesadas. Podría haber sido mucho más .

Tu agregaste:

¿Qué es lo que la Dirección no ve que no les gusta no ver? ¿No tienes plazos y presupuestos usando Scrum?

en respuesta a:

Muchos gerentes tradicionales están acostumbrados a "saber" el alcance, el presupuesto y la fecha límite al comprometerse con un proyecto.

El punto es que en una mentalidad de cascada, la idea es planificar lo suficiente como para ser capaz de adivinar el futuro y, por lo tanto, una vez que ha comenzado el desarrollo, obtiene un alcance fijo , un costo fijo y un cronograma fijo . Porque no van a cambiar, porque lo planeaste perfectamente y el futuro nunca cambia.

En una mentalidad ágil, solo puede tener, como máximo, 2 de esos siendo reparados. Porque nunca puedes predecir con precisión el futuro, porque el futuro cambiará . Así que debe haber espacio para adaptarse. Si se fijan las tres restricciones del triángulo de hierro , entonces no hay espacio para adaptarse.

Sí, pero no puedes posponerlos para siempre. ¿Qué dices, "Oh, por cierto, esto cambiará y no podemos saber cuándo estará completo?"

Si tiene un costo fijo y un alcance fijo, entonces sí, no puede saber cuándo se completará una función, hasta que lo esté. A medida que te acercas a ese punto, el cono de incertidumbre se estrecha, pero solo se convierte en un punto una vez que se realiza la función.

Cualquier otra cosa es cegarte a la realidad fingiendo que sabes cuándo se hará algo, cuando en realidad no lo sabes .

Muchos gerentes tradicionales están acostumbrados a "saber" el alcance, el presupuesto y la fecha límite al comprometerse con un proyecto. Scrum elimina todo eso y promete hacer lo mejor posible.

Ahora obtienes uno de estos resultados:

• La gerencia dice: En ese caso no estás haciendo Scrum. Resultado: Sin Scrum.
• La gerencia dice: Seguro que haces Scrum, nosotros hacemos cascada y lo que hacemos cuenta. Resultado: El doble de esfuerzo administrativo y sin Scrum.
• La gerencia dice: OK, pero remodelaremos Scrum para que aún tengamos alcance, presupuesto y plazos fijos. Resultado: Scrum pervertido.
• La gerencia dice: Vemos los beneficios y acordamos apoyar este enfoque. Resultado: Eventualmente, con suerte Scrum.

Editar: Scrum no se preocupa por los presupuestos. Ese es el trabajo de las partes interesadas/clientes/administración para determinar si el progreso realizado vale la pena el financiamiento invertido. Los plazos tampoco tienen sentido en Scrum. En principio, puede enviar o archivar el proyecto después de cualquier iteración y simplemente marcharse. El argumento de Scrum es que, si bien no puede predecir qué tan lejos llegará para la fecha X o cuándo se completará el nivel de función Y, puede decirle que en cualquier momento tendrá el mejor producto que se pueda tener. la inversión que has hecho.

Hay un concepto erróneo enorme (o diferencia de percepción) de los gerentes de los equipos de programación.
Lo que piensan: "Nosotros establecemos el proyecto, las funciones y el cronograma, y ​​se hará en ese tiempo"
Lo que piensan los programadores: "Tenemos un cierto ritmo al que podemos trabajar, el trabajo no se hará más rápido independientemente de la gestión está haciendo.

En la gestión de cascadas, se establecen las especificaciones y el cronograma. En scrum, la gestión solicita funciones y los programadores dan una estimación de cuándo se realiza una función.

Los gerentes piensan que pasar de la cascada al scrum les da menos poder sobre cuándo y cómo se hacen las cosas. Una vez más, sin embargo, solo darle a un programador una fecha límite sobre cuándo se deben hacer las cosas no hace que el programador termine con la función dentro de la fecha límite.

Cuando la gerencia no compra Scrum, no están involucrados en el proceso. No dan la retroalimentación necesaria, pueden dictar plazos. Todo esto podría generar más gastos generales, más reuniones y funciones innecesarias.

Scrum puede entregar software más rápido, mejor y más barato. Pero para darse cuenta de los posibles ahorros de tiempo y costos, las partes interesadas deben comprender el proceso y comprometerse a cumplir su función en él.

Comprender el proceso significa dejar de lado la idea de que todo se puede planificar por adelantado. La gente de negocios está acostumbrada a tener planes detallados y contratos grabados en piedra al comienzo de un proyecto. En mi experiencia, el principal obstáculo para que los gerentes que no son desarrolladores acepten Scrum es que solo se realiza una planificación mínima por adelantado, y el plan no solo está permitido, sino que se espera que evolucione con el tiempo. Esta idea es fundamental para Scrum. Un plan detallado requiere mucho tiempo y esfuerzo para producirlo, pero es inevitablemente inferior a un plan dinámico porque incluso alguien íntimamente familiarizado con el dominio no puede imaginar cómo debería funcionar todo o anticipar cada oportunidad de mejora.

TL;RD:

• A la gerencia le gustan los planes detallados e inflexibles.
• Si está siguiendo un plan detallado e inflexible, no está haciendo Scrum.

Para agregar a las respuestas existentes, usando la experiencia de mi novia en su lugar de trabajo actual...

El desarrollo ágil depende de los sprints. Una característica clave de un sprint es que tú decides al principio qué vas a entregar, y eso es todo lo que entregas. La fecha de entrega y el contenido entregable están bloqueados desde el principio, todos saben cuáles son y están configurados para ser alcanzables. Si surgen nuevos requisitos, van en el siguiente sprint. Claro, puede cancelar un sprint si resulta ser fundamentalmente incorrecto, pero de lo contrario, el objetivo es entregar el trabajo en pequeñas partes. Los sprints son intencionalmente cortos porque los requisitos están destinados a cambiar, por lo que retrasar los cambios hasta el próximo sprint no es un problema.

Lo que no hace como gerente cuando un cliente solicita un cambio es decir "Hola chicos, tengo un nuevo requisito aquí, agregue esto al sprint". Y se asegura de que ninguno de los miembros de su equipo acepte de forma independiente nuevos requisitos durante el sprint, de nadie, ni invente nuevos requisitos por sí mismo. Se supone que el Scrum Master debe asegurarse de que esto no suceda. Sin embargo, si el Scrum Master no tiene la autoridad para decirle al gerente que siga el proceso, o para escalar si el gerente se niega a hacerlo, entonces tiene un problema.

El mejor de los casos cuando se equivoca de esa manera es que sobrecarga a los miembros del equipo que de repente tienen trabajo adicional que hacer, o los configura para que fracasen, porque el trabajo planificado que se puede lograr ya no se puede lograr.

En el peor de los casos, el equipo en su conjunto ya no sabe cuáles son los entregables. Los codificadores pueden agregar características que los probadores no conocen, u omitir o cambiar características definidas previamente. Las pruebas fallarán, y descubrir por qué ocurrieron las fallas como resultado puede llevar mucho tiempo. Peor que eso, es posible que las nuevas funciones no se prueben, por lo que es posible que se publiquen sin que nadie verifique que realmente funcionan correctamente.

Según el diccionario de Cambridge, "comprar" es un verbo compuesto que significa "creer en un conjunto de ideas" .

A menudo sucede que cuando una empresa o un equipo migra los procesos a scrum, es posible que el rendimiento general o los resultados no se vean bien, especialmente al principio. Esta declaración significa que la gerencia debe creer en scrum y estar lista para esperar los resultados, incluso si no se demuestra un valor instantáneo.

En la mentalidad de gestión de proyectos más tradicional, las personas están más preocupadas por sus presupuestos y cronogramas para un proyecto que por producir un producto utilizable. Quieren saber cuánto costará algo, cuánto tiempo llevará y cuánto obtendrán por su inversión, todo antes de que se realice el trabajo real. También supone que las personas que solicitan el producto realmente saben lo que quieren antes de tener algo que ver o probar. Esto conduce a una gran cantidad de documentación, a la mitad del proceso de retroalimentación mínima o nula y a una falta de flexibilidad. Hay un énfasis excesivo en los informes de estado y en asegurarse de que todo coincida con el plan tal como se presentó originalmente, y las asignaciones insuficientes para las incertidumbres y ambigüedades.

Scrum, y Agile en general, reconoce que el mundo real no está tan estructurado y rígido, y que las personas que elaboran los requisitos no sabrán lo que realmente quieren hasta que lo tengan en sus manos. Adopta el enfoque de centrarse en lo más urgente del momento, terminarlo y pasar a lo siguiente. También se basa en mostrar el trabajo completado a las partes interesadas y a los usuarios finales lo antes posible, solicitando sus comentarios y ajustando el plan en consecuencia. El objetivo general es tener siempre el producto más útil para el esfuerzo invertido hasta la fecha.

Esto no va bien con la mentalidad tradicional porque no tenemos plazos fijos y rara vez tenemos un plan firme para algo que está a más de un par de semanas. Podemos informar sobre las cosas que se han completado, en qué estamos trabajando actualmente y en qué planeamos comenzar a continuación. Pero no podemos decirle cuándo terminará el proyecto, en qué orden aparecerán las características, o incluso garantizar que nuestro plan de "lo que sigue" no cambiará antes de llegar a él.

Para dar un ejemplo un poco extenso, una vez trabajé para una agencia gubernamental, primero como desarrollador, luego como líder y gerente de equipo. También soy Scrum Maser certificado y Agile Coach, y he usado sombreros BA y PM bastante en el pasado.

Hubo una fase en la que estábamos tratando de "hacer ágiles" sin ningún apoyo real de nuestra administración o partes interesadas. Esencialmente, los desarrolladores adoptaron algunas ceremonias "ágiles", pero todos los demás seguían produciendo documentos de requisitos de más de 30 páginas sin involucrar a los desarrolladores, exigiendo estimaciones para los proyectos con meses de anticipación a cuando realmente trabajaríamos en ellos, esperando que cumpliéramos con los plazos que se establecieron sin nuestro aporte, apuntando a la documentación cuando planteábamos preguntas y lanzando ataques cada vez que los resultados del proyecto se desviaron de los requisitos, el cronograma o el presupuesto, independientemente del motivo.

En el peor de los casos, lo que debería haber sido un proyecto de seis meses tomó casi 2 años y tuvo que reescribirse dos veces porque las partes interesadas cambiaron, lo que cambió los requisitos, e incluso después de la primera reescritura, lo que se incluyó en los documentos de requisitos todavía no era lo que los usuarios finales realmente necesitaban.

Poco después de asumir el cargo de gerente, convencí a la gente para que me dejara ejecutar un proyecto sin interferencias. Al principio me entregaron uno de esos documentos de 30 páginas, con la expectativa de que demos una estimación inicial del costo y el tiempo de finalización para que pueda pasar por el proceso de aprobación. Normalmente, esto habría involucrado al gerente (yo) y posiblemente a un líder de equipo o un desarrollador senior revisando el documento en un día más o menos, y devolviendo algunos números que eran 2 o 3 veces más de lo que pensamos que deberían ser para dar cuenta de las cosas. no sabíamos y no tuvimos tiempo de averiguarlo.

En lugar de eso, involucré a todo el equipo para revisar el documento, dividirlo en características de un tamaño que pudiéramos dar estimaciones significativas y conectarlo a nuestro sistema de seguimiento. Tuve que pelear contra nuestra PMO y otros gerentes repetidamente porque estábamos tardando demasiado y usando demasiados recursos para llegar a dicha estimación (varias reuniones de 1 a 2 horas durante un par de semanas). Sin embargo, al final, teníamos un mapa aproximado del trabajo que se necesitaba, cada desarrollador estaba al tanto de la dirección y las decisiones que habíamos tomado, y todos tuvieron la oportunidad de dar su opinión sobre las estimaciones. Cuando terminamos, presentamos un cronograma de aproximadamente 10 meses con un costo que se calculó en función de qué desarrolladores y otros recursos esperábamos que trabajaran en él, y durante qué porcentaje de su tiempo.

Cuando dicho proyecto recibió luz verde unos meses más tarde (nunca hubo ninguna duda real de que lo haríamos), lo primero que hicimos fue desempolvar nuestro desglose anterior, decidir dónde debemos comenzar para tener algo que mostrar, verificar nuestro estimaciones para ese bloque de trabajo, y tirar el documento de requisitos a un lado. Luego configuré el equipo con un enfoque cercano a Scrum, realizamos sprints de 1 semana, con un lanzamiento cada 4 semanas. Tuvimos una reunión de partes interesadas cada 2 semanas.

Cuando la reunión de partes interesadas se alineó con nuestro lanzamiento, presentamos las nuevas características, solicitamos comentarios iniciales y establecimos nuestros objetivos para el próximo lanzamiento. Para las reuniones fuera de ciclo, solicitamos y discutimos informes de errores y ajustamos el plan de lanzamiento en función de los comentarios de las pruebas del usuario final. Una vez más, me propuse tener no menos de tres desarrolladores en la sala para cada reunión de partes interesadas, con la expectativa de que hicieran y respondieran preguntas según fuera necesario, pero principalmente para que el equipo tuviera más de una perspectiva sobre lo que se decía. Y nuevamente me criticaron porque estaba "desperdiciando" el presupuesto al hacer que los desarrolladores asistieran a las reuniones en lugar de programar.

Al principio fue un poco difícil lograr que las partes interesadas asistieran a nuestras reuniones, hasta el punto en que sugerimos que se archivara el proyecto ya que aparentemente no era lo suficientemente importante como para exigir su atención. Pero después de que los lleváramos a tres o cuatro reuniones, donde pudieron ver el progreso realizado y ver cómo se incorporaban sus comentarios, comenzaron a estar más dispuestos a reservar tiempo para nosotros. Después de la segunda vez que alguien salió diciendo "esto es genial, pero lo que realmente necesitamos es" acerca de una función y vio que el problema se corrigió en la próxima versión, se vendieron.

Durante todo el proyecto, también libré una batalla constante con la PMO sobre mis informes de estado. Querían ver los mismos tipos de cronogramas de proyectos e informes a los que estaban acostumbrados, con características marcadas en un orden preestablecido y según el cronograma, y ​​poder hacer coincidir nuestros gastos con sus proyecciones presupuestarias. En cambio, les estaba dando un informe sobre los puntos de la historia que se habían completado y aceptado, estimaciones sobre los puntos en progreso y cuándo deberían realizarse, y revisiones de las estimaciones originales y los cronogramas en función de los problemas que surgieron durante el desarrollo o la prueba.

Se enfadaban cada vez que volvíamos a estimar una historia en función de nueva información, añadíamos historias para rastrear errores o dividíamos las cosas en segmentos de trabajo más granulares, especialmente si el cambio terminaba cambiando la cantidad de puntos en el proyecto, quejándose que estábamos cambiando de ámbito. También odiaban que mis estimaciones estuvieran en puntos en lugar de horas, y querían saber cómo traducir entre los dos. Eventualmente armé una herramienta que vinculaba las horas de tareas con las historias y los lanzamientos, y les di un promedio móvil de puntos por lanzamiento y horas por punto, pero aún así no les gustó que no fuera un número fijo y nos negamos a comprometernos. una fecha de finalización difícil hasta que entramos en nuestro último par de ciclos de lanzamiento, y era obvio cuándo terminarían las cosas.

Al final, terminamos el proyecto en 11 meses, superamos en un 20 % nuestro presupuesto original y teníamos personas que usaban activamente el producto el día del lanzamiento, sin una enorme lista de defectos que retrasaran la implementación. Fue, con mucho, el proyecto más exitoso jamás completado por esa agencia en términos de cumplimiento de cronograma, presupuesto y funciones utilizables. Para dar cierta perspectiva, la norma para ese departamento antes de este proyecto era terminar a tiempo hasta en un 50 %, al menos duplicar el presupuesto y tener una adopción inicial baja porque el producto final no satisfacía las necesidades reales de la organización o los usuarios.

En este caso, yo, como gerente directo, había aceptado y tenía suficiente influencia y apoyo de mi cadena de supervisión para proteger a mi equipo y salirme con la mía intimidando a personas de otros silos para que siguieran el juego, pero la organización en su conjunto no estaba a bordo. . En el transcurso del proyecto, reunimos a la mayoría de las partes interesadas del lado comercial para que apoyaran la metodología, pero la PMO solo nos toleró en lugar de apreciar lo que estábamos haciendo.

Scrum o agilidad se trata de responsabilidad inversa cuando se trata de gestión.

Un gerente tradicional dice qué, cómo, cuándo. El equipo es responsable. Si falla, es culpa del equipo.

Un gerente moderno dice por qué y qué, luego apoya a su equipo de cualquier manera posible. El gerente es responsable. Si falla, es su culpa.

Al introducir Scrum (o agilidad), sus gerentes tradicionales deben renunciar al mando y control y pasar a los gerentes modernos de "confianza y soporte". Por lo general, no quieren ceder el mando y el control.

Si no lo hacen, lo que sea que le preguntes al equipo "oye, este es nuestro objetivo", luego le preguntas al equipo "oye, necesitamos que seas eficiente", el equipo responde "bien, necesitamos A, B y C", y les dices "lo siento, no es posible, tendrás que prescindir de ellos" (generalmente porque amenaza su posición/política/objetivos, o simplemente porque piensan que esos empleados deberían simplemente trabajar más duro en lugar de pedir apoyo) y luego se quejan de la eficiencia de todos modos porque necesitan justificar por qué es tan caro.

Es por eso que deberían participar, porque un equipo se vuelve eficiente si la organización se forma en torno a su eficiencia, y ¿quién puede dar forma a la organización?

Entonces surge la pregunta aún más interesante: ¿cómo es posible lograr la aceptación de la gerencia?

nota al margen: sobre los plazos y el presupuesto: sí, Scrum los tiene, y Scrum se toma muy en serio, mucho más que el "estilo tradicional", porque en realidad se centra en asegurarse de que algo se entregará y debería ser tan eficiente como sea posible ( que significa rentable), a diferencia del "estilo tradicional" que no es mucho más que una simplificación ingenua que quiere convencerse de que "las cosas complejas no son mi problema".

Scrum está diseñado para funcionar como "equipos autoorganizados" .

Para muchos gerentes convencionales que asignan trabajo a los empleados, este es un cambio colosal.

Esto requiere que la gerencia confíe en que el equipo seleccionará su propio trabajo y lo hará sin la ayuda del gerente.

El nuevo rol de un gerente en un entorno basado en Scrum es el de un líder , asegurándose de que su empleado tenga las habilidades y la capacitación adecuadas para ayudar al equipo a desempeñarse al más alto nivel.

Responder

"La gerencia tiene que aceptar Scrum". ¿Puedes decirme por qué es eso?

Hacer Scrum (real) significa que la gerencia está cediendo mucho control. La gerencia necesita saber eso, aceptarlo y realmente vivir ese espíritu. Esto es muy, muy difícil, especialmente porque los gerentes de proyectos experimentados tienden a tener un carácter más agresivo/controlador, y esto tiende a ser más a medida que asciendes (al menos en mi experiencia, y al menos por lo general, a pesar de las excepciones) .

Una de las partes más importantes que notará si observa detenidamente Scrum es que Scrum tiene solo tres roles: Propietario del producto, Scrum Master, Miembro del equipo. ¡No hay un líder/gerente de proyecto!

En esencia, la gerencia tiene que comprar Scrum porque tienen que confiar mucho en el proceso , sin tener el control en absoluto .

¿De qué gestión están hablando?

Literalmente, todos en su propia empresa y en la empresa del cliente que no sean el propietario del producto, el Scrum Master o un miembro del equipo.

¿Qué sucede cuando se usa Scrum, pero la gerencia no lo ha aceptado?

Esto es lo que sucede todo el tiempo: el proyecto comienza, durante los primeros sprints todo parece estar bien. Luego, la gerencia se impacienta y solicita cronogramas a largo plazo, conjuntos de funciones garantizados y precios/presupuesto (todo lo cual está ausente en el proceso Scrum). De ahí en adelante, desconfianza, infelicidad, fracaso.

La razón de esto es, por lo general, según mi experiencia, que la gerencia simplemente no sabe lo suficiente sobre el proceso y (al no ser un desarrollador, un Scrum Master o un PO) realmente no lo ha experimentado. Este es un verdadero enigma y no solo culpar a la gerencia. Es fácil decir "claro, cederé el control", pero es muy difícil ver lo que eso significa realmente.

Si la gente de Scrum dice que no sabe y que no le importa lo que suceda después del sprint actual, lo dicen en serio . Muchos gerentes (lo sabía) de alguna manera pensaron que todo esto era solo una farsa feliz para hacer que los desarrolladores se sintieran empoderados. Muchos se sentaron con el PO o el SM de inmediato y comenzaron a elaborar planes de hitos mensuales o anuales, estableciendo expectativas que, por diseño, Scrum simplemente no puede cumplir.

¿Por qué eso importa?

Debido a que la gestión clásica centrada en el tiempo, el presupuesto y la calidad está gestionando activamente en contra de los principios de Scrum, por ejemplo, que solo el sprint actual tiene un conjunto de funciones fijas y todo lo demás depende de la orden de compra para priorizar; o que el tiempo = presupuesto requerido para completar los elementos de trabajo más allá del sprint actual no se planifique con anticipación.

¿Qué es lo que la Dirección no ve que no les gusta no ver?

Les faltan promesas confiables y garantizadas sobre hitos a largo plazo, pronósticos de presupuesto y conjuntos de características.

Además, un punto importante de Scrum es proteger al equipo de desarrollo (durante un sprint) de las decisiones de gestión arbitrarias. Si bien esto es bueno para el equipo de desarrollo, también le estás quitando poder a la administración => no es bueno para ellos, al menos psicológicamente.

Sé que esta es una edición tardía, pero me parece que la conclusión es confiar en el equipo de desarrollo y darles lo que necesitan y lo harán bien.

Mas o menos. Si está hablando de la confianza de la gerencia, realmente debe incluir al propietario del producto, que tiene algunas partes de las responsabilidades que tiene un gerente de proyecto en un proyecto clásico. La gerencia tiene que confiar en el PO y el proceso Scrum.

panorama

Es fácil caer en la trampa de pensar que la gerencia es simplemente tonta (el "jefe de pelo puntiagudo" de Dilbert) o que la gente de Scrum está tratando de vivir en una granja de ponis. La respuesta está en el medio. Tiene que haber mucha educación. O, si la empresa (o los clientes, o el software en particular) simplemente no es tan adecuado para un enfoque estricto de Scrum, se deben encontrar (y se pueden encontrar) mezclas que devuelvan cierta cantidad de control y transparencia a largo plazo a administración. Siempre que todos sepan exactamente lo que está pasando, hay muchas variables para modificar.

Sugerencias

A algunos Scrum Masters les gusta presentar Scrum a nuevos equipos y gerentes con un enfoque muy visible, es decir, omitir a Jira et al y pasar al enfoque basado en pizarra/papel. Es bastante educativo cuando las personas se ponen de pie y mueven notas adhesivas en una pared.

Prefiero no comenzar con Scrum en absoluto (en entornos donde las personas no están acostumbradas a ningún método Agile, o donde no está claro si Scrum es exactamente lo correcto, necesariamente). En cambio, un Kanban muy ligero. Esto significa elegir algunos instrumentos (tablero, carriles, concepto de WIP, introspección, etc.) que se pueden transferir a Scrum más tarde, pero donde los carriles se pueden ajustar para tener los títulos que desee y cambiar más libremente que en estricto. Scrum, pero te saltas los sprints por primera vez (la introspección, etc. debe ser regular, por supuesto). Esto hace que todos se acostumbren a los "instrumentos" generales, y gradualmente puedes hacer que el proceso sea más riguroso si así lo deseas. Esto tampoco le quita nada a la gerencia, incluso pueden poner un plan de proyecto real encima de todo;

Es muy similar al hecho de que el patrocinador/ejecutivo del proyecto debe ser parte del taller 'planificar cómo planificar' al comienzo del proyecto. En esencia, debe establecer sus expectativas y ellos deben ponerse de acuerdo sobre los entregables y el enfoque del proyecto.

Agile es una mentalidad muy diferente a la cascada. No es fácil traducir un enfoque Agile en plazos firmes y términos presupuestarios, y la gestión (y los contratos) tienen que ver con los plazos, el alcance y el presupuesto.

Todos los softwares de gestión de proyectos están al servicio del gestor de proyectos. Fueron creados para ayudar al gerente a reducir el costo, aumentar los ingresos y obtener ganancias en el desarrollo de un producto. Eso parece simple escrito así, pero no lo es. Muchos gerentes siguen su instinto sobre la relación costo/ingresos, pero en proyectos complejos no es suficiente. Es la fecha límite de cada paso del desarrollo del producto lo que es importante controlar. Un plazo no respetado en la fase 1 repercute en la fase 2 y tan larga, limitando o haciendo desaparecer el beneficio. Los softwares de gestión de proyectos se utilizan para limitar los errores humanos; pero hay que conocerlos bien y usarlos correctamente y lleva tiempo y el tiempo es dinero. Si entendí bien su pregunta, algunos gerentes por esa razón han comprado el uso de Scrum.

Ley de Conway:

Cualquier organización que diseñe un sistema (definido ampliamente) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.

Esto fue documentado por primera vez por Melvin Conway hace medio siglo y se denominó Ley de Conway en el libro de Fred Brooks: "The Mythical Man-Month". Desde entonces, la Ley ha sido respaldada por más investigaciones positivas .

Al desarrollar sistemas de software, las estructuras organizacionales tienden a dictar cómo se desarrollará el software. Esta es la razón por la que si una organización jerárquica y monolítica desarrolla software, tenderá a querer que se produzca de la misma manera: con diagramas de GANTT, sesiones de planificación, muchos meses de planificación anticipada, etc.

En esencia, si la gerencia no compra Scrum y ajusta la organización para que funcione de una manera más plana, tipo servidor-líder, cualquier intento de introducir prácticas de Scrum encontrará tantos obstáculos que, en el mejor de los casos, será de corta duración. ¡Estuve allí, compré esa camiseta!

Si la gerencia no "acepta" el scrum, entonces la gerencia solicitará cambios en un proyecto durante la prueba de control de calidad del proyecto el día antes de que entre en producción. Estos cambios retrasan la entrada en producción del proyecto. Esto le da a la gerencia más tiempo para pensar en más cambios. Estos cambios adicionales provocan retrasos adicionales en la entrada en producción del proyecto. Eventualmente, la alta gerencia observa cuánto tiempo ha estado funcionando el proyecto y que nada ha entrado en producción todavía y cancela todo el proyecto.