¿Scrum es realmente adecuado para todo tipo de proyectos?

A su pregunta general, si bien Scrum se puede aplicar en la mayoría de los proyectos, no es necesariamente el mejor enfoque para algunos proyectos. Dicho esto, se adapta bien a problemas complejos que requieren el descubrimiento de la solución y la adaptación a nueva información. Su proyecto suena exactamente como el tipo de proyecto para el cual Scrum fue diseñado. Sin embargo, planteas algunos puntos importantes y trataré de abordarlos:

1) El propietario de un producto debe comprender el dominio en el que está trabajando a un nivel en el que pueda identificar y discutir de manera inteligente los problemas clave que deben resolverse para crear valor. Por ejemplo, el PO para el gran colisionador de hadrones conoce mejor su física cuántica. Es completamente posible que tenga la orden de compra incorrecta para su trabajo. Sin embargo, vale la pena señalar que no es necesario que entiendan cómo resolver el problema para ser efectivos; ese es el trabajo del equipo. De hecho, a veces es mejor que no lo hagan para que no estorben al equipo.

2) Si bien los elementos de la cartera de productos pueden provenir de cualquier persona, el PO debe comprenderlos lo suficiente como para hablar de su valor y ser capaz de priorizar. ¿Son sus elementos de backlog expresiones de problemas a resolver o tareas en la solución? Si es lo primero, es posible que desee ver una orden de compra diferente. Si es lo último, es posible que tenga elementos incorrectos en su cartera de pedidos.

3) Primero, no necesita usar historias de usuario. Sin embargo, tienes alguna persona o grupo de personas que se benefician de tu trabajo. Cada uno de los elementos de su cartera de pedidos debe proporcionarles valor. Si un producto no proporciona valor a nadie, debe cancelarlo. (Estoy, por supuesto, siendo hiperbólico. En realidad, nunca me he encontrado con un proyecto que no haya proporcionado ningún valor a nadie)

4) La estimación relativa está diseñada para poder manejar la incertidumbre o las incógnitas y ayuda en la mayoría de los proyectos. Sin embargo, algunos proyectos tienen tanta incertidumbre que hacen inútiles las estimaciones. Afortunadamente, Scrum no los requiere. Una recomendación que haría es que si no usa estimaciones, use cuadros de tiempo. Un cuadro de tiempo establece la cantidad de tiempo para trabajar en algo antes de volver al grupo para ver si vale la pena seguir dedicando tiempo o si algo más es más importante.

5) Este es un desafío común. La solución es simple, pero requiere práctica para ser bueno. La solución es a) dividir el problema en problemas más pequeños o b) realizar un experimento para obtener un aprendizaje validado en lugar de largos procesos de aprendizaje de investigación. El primero se utiliza en los casos en que el ciclo de investigación es largo debido simplemente a intentar investigar muchas cosas. El segundo se usa cuando el ciclo de investigación es largo debido a muchos factores complicados que deben tenerse en cuenta en problemas complejos. Por supuesto, es mucho más fácil escribir este párrafo que hacerlo, así que no te sientas mal si te encuentras con algunos problemas que no sabes cómo abordar en un sprint.

6) ¿Quién quiere un mayor rendimiento, cuánto quieren y cómo les afectará? Eso es lo que tienes en tu revisión. El espacio de su problema suena muy limitado, por lo que no me sorprendería saber que sus revisiones son muy directas.

¿Scrum es realmente adecuado para todo tipo de proyectos?

Al igual que con muchas cosas en la industria del software, Scrum no es una panacea. Funciona bien para algunos tipos de proyectos, y menos para otros. A menudo he visto que Cynefin Framework se menciona al tratar de identificar los tipos de proyectos en los que se podría usar Scrum, así que tal vez eche un vistazo y vea en qué categoría podría caer su proyecto.

Otra cosa que he visto muchas veces es que Scrum se impone a los equipos sin considerar el tipo de trabajo que se está realizando. De su pregunta parece que este podría ser el caso. ¿Quién eligió Scrum para usted y su equipo? ¿Por qué? ¿Has buscado otras formas de organizar tu trabajo? ¿Kanban parecería más prometedor?

El problema con la forma en que redactó la pregunta es que menciona cosas contra la adopción de Scrum, pero no dice nada sobre el resto. ¿Son estas cosas importantes "no go" o simplemente algo que identificó? Lo que digo es que cualquier proyecto tiene sus desafíos. Así que trata esto como un desafío, analízalo y busca soluciones, ya sean Scrum, Kanban u otra cosa.

Luego, si Scrum puede abordar el trabajo, utilícelo. Pero si encuentra algo mejor, es mejor no "doblar" su trabajo para que se ajuste a Scrum, simplemente use lo mejor que haya encontrado. Si, por otro lado, no tiene un dicho para elegir la forma en que trabaja y necesita usar Scrum porque una entidad superior lo dice, entonces tiene problemas mayores que Scrum no es lo mejor para usar para su trabajo.

Agregando un poco a la excelente respuesta de Daniel.

Tu dices:

todo el trabajo es profundamente técnico y no tiene consecuencias para el usuario

Pero también dices:

centrado en mejorar el rendimiento del producto como un todo

Puedo pensar en dos razones por las que podría mejorar el rendimiento del producto:

1. Para mejorar la experiencia del usuario (tiempos de respuesta más rápidos, etc.)
2. Para reducir la cantidad de hardware que necesita para obtener el mismo nivel de rendimiento

Si es la razón 1, entonces tiene consecuencias para el usuario y esas definirán sus historias. Por ejemplo, algo como:

Como usuario, quiero que el producto responda más rápido para poder hacer más

Si es el motivo 2, es probable que el cliente sea interno y quiera ahorrar dinero. Por ejemplo, algo como:

Como CIO, quiero reducir mi presupuesto de hardware recurrente para poder aumentar la rentabilidad.

Tenga en cuenta que estas historias son perfectamente comprensibles para alguien que no sea técnico, como una persona de negocios o un propietario del producto. Describen lo que se desea, en lugar de cómo se entregará.

TL;DR

El marco Scrum generalmente se puede adaptar a cualquier producto o servicio que pueda beneficiarse del esfuerzo de tiempo limitado y la entrega incremental. Eso no significa que sea la mejor opción para cada proyecto, pero la pregunta original no describe nada que no pueda encajar en una implementación de Scrum.

Análisis de preguntas

La pregunta, tal como está constituida actualmente, describía una serie de olores de implementación del marco que, en conjunto, son demasiado amplios para abordarlos en una sola pregunta y respuesta. Tal como se describe, este proyecto no parece articular claramente una necesidad comercial medible que se ajuste al modelo de control de procesos empíricos de muchos marcos ágiles. Eso no es una falla de Scrum o Agile, sino una falla en uno o más de los siguientes:

• iniciación del proyecto
• conceptualización o selección de controles de proyecto
• comunicaciones organizacionales o de proyectos

La pregunta, tal como está redactada actualmente, también se presenta más como una solicitud de apoyo de sesgo de confirmación que como un problema concreto a resolver. Como tal, ese aspecto de la pregunta está fuera del alcance y no se abordará en esta respuesta.

Para qué fue diseñado Scrum

El marco Scrum tiene solo tres roles claramente definidos y cuatro eventos prescritos . Aparte de los elementos del marco obligatorios mencionados en el marco, las organizaciones son libres de adaptarlo a sus necesidades específicas.

Scrum está pensado principalmente como un marco de entrega de productos. La propia guía menciona una serie de usos concretos:

1. Investigar e identificar mercados, tecnologías y capacidades de productos viables;
2. Desarrollar productos y mejoras;
3. Lanzar productos y mejoras, tantas veces como sea posible al día;
4. Desarrollar y mantener la nube (en línea, segura, bajo demanda) y otros entornos operativos para el uso del producto; y,
5. Mantener y renovar los productos.

Siempre que un proyecto se pueda descomponer en unidades iterativas o incrementales que se puedan dividir en tiempo, Scrum se puede adaptar para el caso de uso. La pregunta original implica fuertemente que las fallas percibidas del modelo Scrum para el caso de uso actual tienen más que ver con las dificultades para conceptualizar el proyecto como un conjunto de incrementos de tiempo limitado que contienen una cohesión central. Lo más probable es que se trate de una brecha de implementación o experiencia en lugar de un caso de uso negativo para la aplicabilidad de Scrum a un dominio de problema específico.

Cuándo no usar Scrum

Ciertamente, existen alternativas al uso de Scrum formal cuando el dominio del problema no cumple con la teoría o los valores del marco. Tal lista nunca puede ser exhaustiva. Sin embargo, ciertamente hay casos de uso negativos comunes, que incluyen:

1. Procesos abiertos de soporte o prestación de servicios.
2. Procesos bajo demanda (la mesa de ayuda o el centro de llamadas son dos ejemplos frecuentes).
3. Cuando la planificación de incrementos justo a tiempo no es factible o deseable.
4. Proyectos extremadamente cortos.
5. Proyectos de colaboradores individuales.
6. Equipos muy pequeños o muy grandes.
7. Entregables que carecen de cohesión central.
8. Entregables que carecen de una Definición medible de Hecho.
9. Proyectos sin la colaboración activa de las partes interesadas.

Si el dominio de su problema no se ajusta fundamentalmente al modelo Scrum, otros marcos o metodologías pueden encajar mejor. Qué marco es "mejor" va a ser subjetivo, pero cualquier marco establecido debe tener objetivos de diseño claramente definidos que pueda usar para guiar su proceso de selección.

Scrum es una palabra de moda entre los gerentes, especialmente aquellos que nunca realizan codificación/análisis/prueba. Se adapta a algunos proyectos específicos, pero no a todos. No es apto para muchos, estos que tratan temas muy técnicos es uno de ellos. Scrum es realmente conocido por acumular deuda técnica (es fácil simplemente barajar estas tareas 'no agradables' en algún lugar del trabajo pendiente). Creo que la mejor manera para cada proyecto es usar un kanban básico y luego adaptarlo de acuerdo con el desarrollador y las necesidades del proyecto para que sea más ágil o más rígido (lo que no es malo en sí mismo, especialmente para los de alto riesgo). proyectos). Eso sí, cascada no es una mala palabra como todos estos entrenadores, maestros y gurús de scrum quieren que creamos.