project management - manager - ¿Scrum solo=ágil?

project management methodologies comparison (14)

Estoy escuchando sobre muchas compañías que actúan como si fueran ágiles, pero lo único ágil que hacen es el proceso de Scrum. ¿Es esto suficiente para ser considerado ágil? Usar Scrum solo parece ser la excusa perfecta para que un mal administrador obtenga más reuniones con más frecuencia. ¿Debería estar cansado de tales compañías?

Usar SCRUM solo no es necesariamente una excusa para obtener más reuniones. Poder rastrear el trabajo que se realiza todos los días y tomar decisiones sobre cómo modificar (cortando o reequilibrando el trabajo) el resto del sprint es bastante útil por sí mismo y me parece ágil. :-)

Por supuesto, si no tiene los otros componentes del proceso ágil, tendrá más dificultades para medir el éxito de su trabajo, por lo que puede pensar que está en camino con el sprint, pero de hecho no está ni cerca del punto deberías ofrecer un producto de calidad a tiempo.

Actualización : no debe despedir a esa empresa solo en esa premisa. Sin embargo, durante la entrevista, debe aprovechar la oportunidad de comprender por qué están utilizando solo SCRUM. Si se trata de no tener personas para defender cosas como TDD o CI, de lo que podría ser una buena opción para ti, si estás dispuesto a convertirte en el líder técnico. Si es porque descartan estos procesos como "gastos generales" o "estúpidos" o "innecesarios", entonces debe tener cuidado con la empresa.

Scrum es una metodología de gestión de proyectos, ante todo. Sí, si está haciendo Scrum, probablemente esté empezando a pensar más sobre ser ágil y ofrecer valor a su cliente. Pero no necesariamente te hace ágil. Para empezar, Scrum no habla sobre cómo se desarrolla el software. Aquí es donde entran en juego cosas como XP: otras metodologías e ideas que lo obligan a revisar y cambiar sus prácticas de trabajo para volverse más eficiente y efectivo.

Entonces, en lugar de preguntar "¿usted hace Scrum / XP / lo que sea?" Les preguntaría a estas compañías sobre sus procesos generales y tomaría una visión holística. ¿La compañía se está enfocando en la entrega del máximo valor comercial e impulsada por un espíritu de mejora continua? Si es así, entonces probablemente sean mucho más ágiles que uno que dice que sí lo es Scrum.

Sí, estaría de acuerdo con algo del sentimiento aquí. Be Agile está siguiendo el manifiesto y asegurando que tiene la alineación correcta de prioridades. SCRUM es solo otra variante con piezas específicas escritas. Es, en todo caso, una "herramienta" de gestión.

Dicho esto, recuerde, las herramientas son secundarias, su gente es su prioridad. No se centre demasiado en el estilo de gestión, concéntrese en las personas y el producto.

Scrum le proporciona un marco para corregir / mejorar su proceso de desarrollo. Se debe considerar como un punto de partida para el " equipo jelled " y un equipo más productivo. Lo más probable es que vaya más allá de las prácticas estándar de Scrum pronto, pero como punto de partida tiene algunas propiedades atractivas:

Es muy fácil de entender
Se puede aplicar a casi cualquier proyecto y equipo
Hay muchas personas que hacen dinero y ayudan a las empresas con la adopción de Scrum

También allí realmente no es tan importante saber si Scrum = agile . Es mejor enfocarse en una mejor productividad y no se moleste con tales preguntas.

No es posible decir si un equipo es ágil solo porque alguien dice que está haciendo scrum.

Hay implementaciones de scrum buenas y malas, pero las principales cosas sobre agile son:

la capacidad del proyecto y del equipo para pensar de manera flexible
qué tan autoorganizado está el equipo (¿tienen un "fanático" de control o "administrador" o hay una cantidad considerable de decisiones por consenso?)

Es muy fácil ajustarse a los requisitos mínimos de lo que un equipo necesita hacer para estar haciendo scrum sin ser realmente ágil. Esos requisitos mínimos solo están ahí para generar una determinada actitud y forma de trabajar.

Es posible que la toma de decisiones en un proyecto sea ridículamente inflexible y controlada de arriba hacia abajo y, sin embargo, se ajuste a los requisitos mínimos del scrum. Lamentablemente, cuando busco contratos de contratación, encuentro que las implementaciones de scrum-in-name superan a las reales por un margen considerable.

Personalmente, elegiría implementar una programación extrema dentro del scrum. (De hecho, Jeff Sutherland dice que nunca ha visto un equipo de scrum de productividad superior que no hiciera las prácticas de XP.) Sin embargo, estoy bastante seguro de que la gente podría implementar XP realmente mal también ... ;-) Realmente se reduce a la actitud en el equipo.

La organización que practica solo Scrum seguramente verá mejoras en la gestión del software y la visibilidad del proyecto. Sin embargo, lo más probable es que no logren una mayor calidad de ingeniería y potencial de rendimiento al no incorporar los principios de XP como Pruebas Unitarias, Integración Continua, Programación de Pares, etc., dejando su final de producto Sprint NO "Potencialmente Enviable".

Agile! = Scrum.

Agile se trata de estar listo para los cambios.

Agile muchas veces se presenta como un paraguas, conjunto de diferentes técnicas, métodos, para trabajar en un entorno que respalda un cambio. Scrum es para administración de proyectos, para técnicas de desarrollo hay xp, para un mejor proceso de requisitos puede usar BDD, para TDD de prueba.

Comenzar con scrum es el primer paso en su camino de agilidad. Considera otras técnicas también. Tomará tiempo, pero hay beneficios reales. Y no hay nada mejor que la comprensión común y el buen espíritu de equipo. Alcanza eso como el primero.

scrum solo es igual a ágil es totalmente un error. Agile es el paraguas bajo el cual hay varios métodos como scrum master, kanban, lean, XP. Ahora dices cómo puede una parte del paraguas cumplir con la idea de un paraguas como un todo. Por lo tanto, scrum es una parte de ágil.

Las personas son víctimas de sus perspectivas subjetivas. Lo que creo que es Agile y Scrum, otra persona puede pensar de manera diferente. Afortunadamente, tenemos un conjunto de pautas en el manifiesto y los principios de Agile y los valores de Scrum, pero a menudo las empresas terminan fijándose en seguir el proceso en lugar de entenderlo y sus objetivos.

Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
Software de trabajo sobre documentación completa
Colaboración del cliente sobre la negociación del contrato
Respondiendo al cambio sobre seguir un plan
Es decir, mientras haya valor en los artículos de la derecha, valoramos más los artículos de la izquierda.

Valores de Scrum

Puede aprender mucho sobre una compañía que usa Scrum preguntándoles sobre los valores y cómo se adhieren a ellos. Esto puede darle una idea si el proceso de Scrum simplemente se aplica sin considerar realmente los valores que están vinculados a él.

Todo el trabajo realizado en Scrum necesita un conjunto de valores como base para los procesos e interacciones del equipo. Y al adoptar estos cinco valores, el equipo los hace aún más instrumentales para su salud y éxito. - Ver más en: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles#sthash.qsmCTxdU.dpuf

Atención
Valor
Franqueza
Compromiso
El respeto

Gol

El objetivo es lanzar software de calidad al final de cada iteración .

Con la influencia correcta, los valores dentro de la empresa pueden cambiar. Lamentablemente, las personas son impredecibles, por lo que las empresas pueden volver a caer en malos hábitos cuando se introducen otros cambios. Esto es lo que hace que el software sea más desafiante y emocionante. Está encontrando formas de crear el equilibrio dentro de las fuerzas entre la tecnología y el producto.

banderas rojas

Si una empresa está más centrada en el proceso que en el objetivo.
Si tiene que pasar por todo tipo de aros y procedimientos para firmar el cambio más pequeño.
La empresa no tiene que hacer que el proceso sea 100% correcto, pero si no se está adaptando y mejorando continuamente para alcanzar su objetivo, en lugar de simplemente seguir un proceso , probablemente terminará con una implementación "a medias" de Agile:

Hemos escuchado sobre nuevas formas de desarrollar software pagando consultores y leyendo informes de Gartner. A través de esto nos han dicho que valoremos:
Individuos e interacciones sobre procesos y herramientas, y tenemos procesos y herramientas obligatorias para controlar cómo esos individuos (preferimos el término ''recursos'') interactúan
Software de trabajo sobre documentación completa, siempre que ese software esté ampliamente documentado
Colaboración con el cliente en la negociación de contratos dentro de los límites de contratos estrictos, por supuesto, y sujeto a un riguroso control de cambios
Respondiendo al cambio sobre seguir un plan siempre que exista un plan detallado para responder al cambio, y se sigue con precisión
Es decir, aunque los elementos de la izquierda suenan bien en teoría, somos una empresa empresarial, y no hay forma de que dejemos de lado los artículos de la derecha.

Conformidad

Algunas empresas pueden tener procedimientos de cumplimiento estrictos que dificultan ser ágiles. Esto puede incluir la gobernanza y otras regulaciones que no se pueden escapar. Esto puede tener un impacto en la metodología Agile al hacer que se sienta más engorroso y pesado, pero eso no significa que esos procesos no puedan simplificarse para ser más complacientes.

"Estoy escuchando sobre muchas compañías que actúan como si fueran ágiles, pero lo único ágil que hacen es el proceso de Scrum. ¿Es esto suficiente para ser considerado ágil?"

Respuesta corta - si. En mi opinión de todos modos :-)

Por supuesto, tienen que estar realmente haciendo Scrum, en lugar de simplemente poner el nombre en la pared. Hay mucho más en Scrum que los enfrentamientos diarios ... y si eso es todo lo que hacen, no lo están haciendo bien.

Hecho correctamente Scrum obliga a las empresas a identificar los cuellos de botella en la forma en que se está ejecutando la organización. Al configurar los sprints de tiempo regular, obtener un ciclo de retroalimentación decente y dividir la responsabilidad entre el propietario y el equipo del producto de forma adecuada, en realidad se obtiene información básica útil sobre cómo mejorar su proceso.

La organización tiene que escuchar esos comentarios y actuar en consecuencia.

Ciertamente no es la única manera de hacer ágil. Puede que ni siquiera sea la mejor forma de introducir ágil a una organización. Soy más fanático de XP y descubro que las prácticas adicionales proporcionan un marco útil para poner en marcha esas mejoras de procesos.

Dicho eso, para muchas organizaciones, el mayor problema es la mala división de responsabilidades y la completa falta de un bucle de retroalimentación sano y rápido. Scrum corrige eso fuera de la puerta.

Las reuniones son una parte muy pequeña de eso :-)

Agile es un concepto grande y vago. Muchas cosas son ágiles.

Scrum es un conjunto específico de técnicas para hacer sprints y lanzamientos. Es ágil porque se ajusta al Manifiesto Ágil.

Hay muchas otras técnicas ágiles específicas (todas las xDD, por ejemplo).

En caso de duda, compare las prácticas reales de las empresas con el Manifiesto Ágil .

Los administradores malos serán descubiertos por la transparencia que promueve Scrum. Realmente vale la pena echarle un vistazo a las compañías que verdaderamente adoptan Scrum.

Me di cuenta de que el solo hecho de utilizar las reuniones de Scrum es una señal bastante clara de que la empresa no ha implementado correctamente los conceptos de Agile.

Piense en lo fácil que son las reuniones de Scrum, simplemente inicie Outlook y ofrezca a todos una reunión diaria de 15 minutos. Pero, dividir todo en iteraciones rápidas y asegurarse de que los nuevos usuarios prueben funcionalmente los nuevos, requiere mucho más trabajo.

Supongo que la mayoría de los gerentes dejan de leer justo después de la parte de Scrum y pierden interés. Sin embargo, sus solicitudes de reuniones diarias viven para siempre.

El manifiesto Ágil es realmente una filosofía que se refiere a una mejor forma de trabajar. Scrum es una metodología ágil, así que sí, una compañía que use Scrum normalmente se considerará ágil.

Sin embargo, es muy posible olvidarse de la filosofía ágil al intentar implementar Scrum. Puede ser fácil quedar atrapado en la búsqueda del proceso de scrum perfecto y descuidar a los individuos y sus interacciones.

Debería estar cansado de las compañías que descuidan las personas y las interacciones, y en cambio favorecen ciegamente procesos y herramientas estrictos. Sin embargo, esto es cierto independientemente de su metodología establecida.