¿Qué has visto salir mal al presentar SCRUM?

¿Cuál fue el único punto de falla encontrado cuando su empresa decidió reemplazar los procesos actuales con SCRUM?

¿Me puede dar algunos ejemplos de cosas que han salido realmente mal cuando una empresa intentó introducir SCRUM? Me gustaría escuchar sus anécdotas, algo que experimentó usted mismo, el gran fracaso que vio venir pero que no pudo evitar.

Escucho mucha preocupación sobre la falta de documentación sobre decisiones sobre los detalles de implementación, y sobre el tamaño de las historias y el nivel de detalle de las historias.

El mayor problema es la incomprensión. Las fallas comunes son:

• Solo un equipo está haciendo Scrum, pero el resto de la empresa (incluidas las ventas, la administración, los recursos humanos) todavía piensan a la antigua usanza. Ejemplos:

  La interacción continua con el cliente y la participación del cliente es muy importante.

  RR.HH. debe comprender que el desempeño del equipo es más importante que el desempeño de las personas. KPI debe cambiar a eso.

  La definición de características es un proceso continuo. La definición del proyecto evolucionará durante el desarrollo por los comentarios de los clientes. Debido a la fecha límite del proyecto, el presupuesto requerido o el conjunto de características de resultados pueden cambiar (después de la aprobación de las partes interesadas).

  El cambio es parte del proceso.

  La estimación es un proceso continuo que no puede decir al comienzo del proyecto que terminará con todas las funciones (muchas de ellas desconocidas al principio) dentro de los 5 meses.

  El equipo está facultado para tomar decisiones. El equipo se compromete a la cantidad de características entregadas durante el próximo sprint. Esto no se puede exigir ni ordenar.

  Sprint es zona segura para el equipo. Una vez que el equipo se compromete con algunas historias de usuario definidas, el compromiso no puede modificarse fuera del equipo.

  Parte de la antigua estructura de la organización no tiene sentido cuando se cambia a Scrum. Scrum define tres roles: Scrum master, Product owner, team. Hay otros roles, pero estos tres suelen ser suficientes para entregar la aplicación. El sentido común es tener Scrum master, líder de equipo, propietario de producto y uno o más gerentes de proyecto. El gerente de proyecto y el líder del equipo son roles redundantes en Scrum.

• El tipo asignado al maestro Scrum no está haciendo Scrum master. Scrum master resuelve impedimentos. Cualquier cosa que moleste al equipo es un impedimento que debe resolverse lo antes posible. La falla más común es asignar este rol al desarrollador sin ninguna experiencia previa con Scrum. Este rol reemplaza parcialmente al gerente de proyecto común, pero Scrum master no tiene poder sobre el equipo y Scrum master no exige que se implemente ninguna característica. Scrum Master protege al equipo incluso contra el propietario del producto con requisitos irrealizables.

• El tipo asignado al propietario del producto no lo está haciendo el propietario del producto. El propietario del producto tiene la responsabilidad financiera del producto. Es muy específico y un papel clave para el éxito. El rol tiene algo en común con analítico, gerente de proyecto y gerente de producto. El propietario del producto recopila y mantiene los requisitos (generalmente en forma de historias de usuarios). Su responsabilidad es proporcionar información al equipo y definir la prioridad de las historias de los usuarios. Debería estar en el sitio con el equipo porque la cooperación entre PO y el equipo es continua.
• Cambiando el nombre del proceso a Scrum pero dejando la mayor parte del proceso como estaba en la forma anterior. El escenario más común es que cambiará de cascada a Scrum y el cambio más significativo es que ya no realiza análisis y documentación y dice que Scrum.
• A los requisitos / historias de usuarios les falta la definición de hecho, muy común. Si no tiene una definición de hecho (criterios de aceptación), no puede asumir nada sobre la complejidad de la historia del usuario durante la planificación del sprint. Si no los tiene durante el sprint, no puede marcar la historia del usuario como completada porque no puede validarla.
• La calidad se considera opcional. La calidad en Scrum es ciudadano de primera clase. Podemos decir que cada criterio de aceptación debe estar cubierto por una prueba automatizada de extremo a extremo. Una vez que comience a reducir la calidad y a agregar características no probadas, perderá el control sobre el producto porque las características consideradas como hechas pueden dejar de funcionar en cualquier momento debido a la regresión.
• El resultado del sprint debe ser un incremento enviable (= funcionando y probado) al producto.

Editar:

Estoy agregando una nota importante. Cuando se utiliza un enfoque ágil, el punto principal es entregar la mayor cantidad de valor comercial al cliente lo más rápido posible. Pero el cliente (representado por el Propietario del producto) describe cuál es el valor comercial. Por lo tanto, generalmente no es cierto que no tenga análisis ni documentación cuando use Scrum. Si el cliente solicita análisis o documentación y lo marca como valor comercial (por ejemplo, debido a un proyecto a gran escala oa largo plazo que debería mejorarse en los próximos años), también lo creará. El enfoque más básico incluye análisis y documentación en los criterios de aceptación de las historias de los usuarios. El análisis en tal caso es comunicación documentada con el propietario del producto de alguna manera estandarizada.

El mayor problema que he notado en más de 10 años de xp y scrum, es cuando los equipos que aún no se "agilizan", deciden "ser flexibles con respecto a lo ágil" y comienzan a personalizarlo, dejando caer ciertas partes, etc., sin Una comprensión clara de lo que hace cada parte y por qué está allí.

He visto que los equipos tienen más éxito con scrum cuando hacen las cosas según el libro al principio, que los equipos que cambian lo que todavía no "entienden".

Ahí es cuando obtienes cosas como "primer sprint, haremos todos los requisitos. Segundo sprint todo el diseño, etc., etc., último sprint todas las pruebas". También conocido como cascada. O incluso cosas simples como "vamos a sentarnos de todos modos, ¿qué pasa con este negocio standup?".

Algo que ver con Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).

El mayor problema es siempre la aceptación. Si algún equipo o personas clave no han comprado (gestión de proyectos, control de calidad, desarrollo, etc.), entonces el fracaso está casi asegurado.

Otro problema relacionado es hacer que todos los involucrados sean conscientes de qué es el scrum real y qué no.

He visto entornos en los que la gestión de proyectos realmente ha tomado esto como un boleto para llegar directamente a los desarrolladores con los cambios y espero que se haga mañana, ya que estamos utilizando el gran proceso nuevo. Cualquiera que haya estado en esta situación o en otros intentos fallidos de implementar Scrum y tenga un sabor amargo en la boca. Estas personas a veces tratarán de descarrilar el proyecto también.

Otro problema que he visto son las reuniones de pie. Siempre obtendrá al tipo que quiere sentarse durante una reunión de stand ... "Tengo problemas de espalda" o lo que sea. Siempre parece ser el mismo tipo que no tiene idea de cuál es el objetivo detrás del enfrentamiento, y no se callará sobre política o lo que hizo ese fin de semana. Las reuniones de pie, he descubierto, son la clave para una comunicación efectiva. Es importante no dejar que nadie envenene estas reuniones.

Tratando de hacer todo el análisis para el código que estábamos desarrollando en el mismo sprint, en realidad lo estábamos codificando.

Nos mudamos a scrum hace un tiempo y, francamente, la administración que lo maneja trató cada scrum como un proceso de cascada de 2 semanas. ¡Hubo tal adherencia a las reglas de scrum que se convirtió en un proceso en sí mismo!

Este es el problema que encuentro, todas las metodologías ágiles deberían tener que ver con la flexibilidad para trabajar eficazmente de la manera que funcione para usted. No es la forma en que está proscrito por los procesos. Por ejemplo, teníamos scrums de 2 semanas, y un equipo dijo que sentían que 2 semanas no eran suficientes para hacer un buen trabajo (no con el tiempo de inactividad causado por el final de la demostración de scrum y la revisión de los requisitos iniciales), por lo que querían pasar a 3 semana. Shock horror! La gerencia se negó porque habían decidido que 2 semanas por scrum eran ideales y eso ahora estaba documentado en los procedimientos de calidad.

Scrum es el menos ágil de los métodos ágiles, y quizás por eso ha sido tan popular: es más fácil de vender a la vieja guardia. se supone que debes eliminar cosas que no te gustan, pero no creo que eso suceda. Mi consejo es ir con una más flexible, menos basada en reglas y agregar las reglas que necesita en su lugar. Prefiero Crystal por esto.

En última instancia, solo recuerda el manifiesto ágil medio arsed .

El mayor problema es que también su cliente necesita aceptar el proceso SCRUM y volverse ágil también. La mayoría de los clientes quieren escuchar esto al comienzo del proyecto:

• Cuanto costará
• Cómo se verá
• Cuando se hará

Suena razonable, pero es absolutamente incompatible con ágil. Debe explicarle a su cliente por qué es ágil bueno para él en lugar de cascada.

Tuvimos dos grandes problemas en mi primer intento en SCRUM:

1) Realmente no teníamos un dueño del producto. Nuestro jefe tuvo que desempeñar el papel porque nadie que debería haber sido dueño del producto estaría de acuerdo en hacerlo. Esto hizo que las cosas se enredaran porque en realidad no siempre sabía las respuestas.

2) Fuimos malos contando componentes externos. Nuestros primeros sprints involucraron la realización de pruebas automáticas completas y en repetidas ocasiones tuvimos problemas para automatizar los simuladores que estábamos usando. De alguna manera, nunca mejoramos al darnos cuenta de que esto iba a suceder.

El principal problema que enfrento en mi proyecto es que la recopilación de requisitos se lleva a cabo después de que hayamos estimado para el próximo sprint. Estimamos en base a los criterios de aceptación. Durante la recopilación de requisitos, descubrimos que la CA ajustada es mucho más grande, por lo que la tarea inicial estimada para 8 horas ¡ahora es realmente 24 horas! Entonces, ¿puedo cambiar mi reserva de sprint y revisar las estimaciones y reducir mis historias? ¡No señor! ¡Agile requiere que no puedas cambiar el retraso del sprint! Eso es lo que dice mi TL. ¡No debería también estar codificando según los criterios de aceptación originales para los cuales había estimado el tiempo como 8 horas! ¡Dios! ¡No! No puedes hacer eso! ¡Eso no sería ágil, verdad!