¿Usando Scrum en proyectos de longitud fija/precio fijo?

Question

Soy un novato de Scrum y busco implementar Scrum en mi compañía. Obtener un buy-in no es un problema, es mi empresa y los desarrolladores están más que felices de trabajar así.

El problema es que el 75% de nuestros ingresos provienen de proyectos de precio fijo/fijo.

Ken Schwaber en su libro, Gestión de proyectos ágiles con Scrum, cubre el tema de las ofertas en proyectos de longitud fija/precio fijo en un apéndice al final del libro.

Después de mucha búsqueda espiritual, Ken dedujo que Scrum solo es útil en esta situación cuando puedes convencer al cliente potencial para que piense de manera diferente. El cliente debería estar bien con mucha incertidumbre (sobre el costo final y la fecha de entrega final) a cambio de obtener algo mucho antes que pueda ser útil y la posibilidad de no tener que implementar todas las características podría ahorrarles dinero.

No estoy seguro de que esta sea la única forma de implementar Scrum en proyectos de longitud de reparación/precio fijo.

Quiero saber cómo otros han pujado con éxito y se han beneficiado de proyectos de longitud de reparación/precio fijo.

Answer 1

Sí. Yo creo que puedes. Ver The Waterfall's Not Working.

El "salir del cuadro de precio fijo" no es una conversación difícil de tener. Los clientes también han visto fallas. Han visto las largas demoras al llegar a un documento de requisitos. Han visto las infinitas órdenes de cambio. Tampoco les gusta.

Pero, si está convencido de que el cliente no quiere administrar las cosas de manera diferente, debe adoptar un enfoque híbrido.

Hacer un precio no es Agile - no puede ser. Para compensar a los clientes intransigentes, debe compensar el precio. Claramente, tendrás algún tipo de plan maestro aquí para justificar el precio. En su mayoría, todo lo que desea de este plan maestro es la acumulación. Otros detalles no son más que hipotéticos supuestos de planificación. [Son siempre supuestos de planificación, pero algunos PM creen que el plan inicial es un oráculo divino que debe seguirse. No lo es.]

Luego, ejecuta en incrementos pequeños, Agile, pasos. Debe involucrar a los usuarios de manera temprana y frecuente, y debe permitir que las conversaciones sucedan. ¡Pero! Cada cambio en la acumulación tiene que examinarse como un cambio potencial en el alcance, el costo o el cronograma.

Al final de cada sprint, cualquier cambio en el retraso acumulado será potencialmente un alcance del proyecto y cambios en el contrato.

Agile reduce los riesgos porque está trabajando activamente en los cambios de alcance antes y de forma más productiva con el cliente. Intentar definir (y congelar) el alcance no es una actividad de valor agregado, así que simplemente deja de hacerlo. Trata el alcance como supongo y trabaja los cambios de alcance en cada sprint.

Answer 2

No estoy seguro acerca de las pujas y los beneficios, pero la metodología scrum ciertamente se puede aplicar a un proyecto de longitud fija/precio. Si los requisitos son conocidos y sólidos, pueden colocarse en la cartera de pedidos del producto y los sprints se pueden planificar de acuerdo con los requisitos y el límite de tiempo. Todavía puede aprovechar los beneficios de las reuniones diarias de melé, tablas de quemado, etc. para asegurarse de que el proyecto se mantenga en buen camino.