¿Scrum es incompatible con las licitaciones públicas?

43

Una organización pública me pidió que diera un taller informal sobre el 101 del desarrollo ágil explicando los términos y conceptos de Scrum, Kanban y similares. He trabajado en entornos ágiles durante unos cinco años, pero no me considero un evangelista de Scrum.

Después del taller les gustó la idea. Sin embargo, explicaron que el enfoque probablemente no se aplicaría a ellos, ya que necesitan encargar a las compañías de software externas que desarrollen software para ellos (solo tienen unos pocos desarrolladores). Esta actividad debe realizarse en un proceso de licitación pública que describa el resultado, el precio y el plazo. Este es un requisito legal para solicitar un presupuesto para esta organización (un instituto público de investigación).

Estas limitaciones parecen algo contradictorias con los principios fundamentales del desarrollo ágil, ¿no?

¿Scrum es simplemente incompatible en ese entorno?

¿Qué recomendarías a esta organización?

bakoyaro
fuente
1
Si el resultado, el precio y el plazo se pueden hacer por adelantado, ¿por qué molestarse con un proceso ágil?
JeffO
3
Scrum es compatible con todo, por definición. El paradigma "El equipo posee el proceso" le permite a uno alterar el proceso radicalmente, de modo que Scrum puede convertirse en Cascada, si es necesario. Ser "ágil" significa que NO debes seguir algún proceso con desviación cero. Significa que el proceso se puede adoptar según las necesidades. Tenga en cuenta que este punto es EXTREMADAMENTE impopular con la administración: quieren procesos fijos y llamarán a cualquier cosa "ágil" si se han enganchado a Agile / Scrum / Whatever.
Klaws
3
FWIW, IME, nunca, he visto algo como lo describe Sebazzz. El contrato dice específicamente lo que debe entregarse. Si no cumple con los requisitos, entonces no has terminado. Y ese es todo el problema con los métodos ágiles "entregue lo que tiene cuando se agoten los fondos". Es una rara ocasión en la que puede entregar un producto que solo hace un subconjunto de lo que el cliente necesita y que realmente es de valor para el cliente. Por lo general, es lo mismo, ya que no funciona en absoluto. Se pueden solicitar desviaciones, pero si esa desviación elimina la funcionalidad, entonces es casi seguro que se combina con menos fondos
Dunk
2
@ CortAmmon: lo que he visto hacer al gobierno es "inteligente" pero no realmente ágil. Básicamente siguen la cascada, adjudican el contrato en fases en lugar del esfuerzo de desarrollo del ciclo de vida completo como lo hicieron en el pasado. También son más propensos a contratar a más de un contratista, especialmente en la fase de ingeniería, ya que eso les permite seleccionar de manera competitiva la mejor solución que desean hacer la transición a un producto fabricable. Esa última fase es la más cara. Quieren ver qué obtienen antes de decidirse a fabricar. Un producto que funciona parcialmente no ganará.
Dunk

Respuestas:

38

Scrum probablemente no sea apropiado para esta organización.

De la Guía Scrum, "Scrum es un marco para desarrollar, entregar y mantener productos complejos". También está diseñado para un equipo de 3-9 miembros de un equipo de desarrollo que trabaja en el producto, un propietario del producto y un Scrum Master (que puede o no estar en el equipo de desarrollo) para un total de 4-11 personas en total.

Con respecto al desarrollo interno, mencionas que solo tienen unos pocos desarrolladores. Si no hay un equipo lo suficientemente grande como para formar un Equipo Scrum, entonces no tiene sentido usar todo Scrum. Sin embargo, algunas prácticas de Scrum pueden ser útiles para la organización.

Para el desarrollo contratado, es posible que una de las partes externas use Scrum. En este caso, es útil para el instituto de investigación conocer las prácticas de Scrum y comprender los roles y cómo funciona. Es posible que aún necesiten comprender los detalles de cómo la organización de desarrollo externa utiliza las prácticas Scrum, así como otras prácticas, pero puede ayudarles a comprender cómo funciona. Por ejemplo, comprender la necesidad de participar en las revisiones de Sprint o trabajar con la organización (probablemente su propietario del producto) para ordenar la cartera de productos.

Thomas Owens
fuente
Excelente respuesta Es muy difícil, aunque no imposible, lograr que organizaciones como la descrita por el OP avancen hacia un enfoque ágil.
Mister Positive
1
@MisterPositive Es posible que no necesite el instituto de investigación para volverse ágil. Sin embargo, es probable que necesiten poder interactuar con entidades externas que son ágiles cuando emiten un contrato. Pueden ver los beneficios de ágil, seguro.
Thomas Owens
La parte realmente buena de esta respuesta es en mi humilde opinión que no cae en la trampa de discutir sobre Scrum no es adecuado porque "el resultado, el precio y el marco de tiempo" son fijos.
Doc Brown
1
@DocBrown Quizás porque Scrum se puede usar donde se fija el precio y el marco temporal. En mi experiencia, cuando está entregando rápidamente y demostrando cosas a las partes interesadas, se dan cuenta de que lo que originalmente pensaron que necesitaban y lo que realmente necesitan son dos cosas diferentes. Y luego cambiarán el resultado deseado dentro del precio original y el marco de tiempo.
Thomas Owens
De acuerdo. El software no es como hacer que un arquitecto diseñe un edificio. Es inherentemente un objetivo en movimiento, con el suelo siempre deslizándose bajo sus pies. El año que viene, los esfuerzos del año pasado parecen pasados.
22

18F, una agencia de servicios digitales dentro del gobierno de los EE. UU., Ha realizado un gran trabajo sobre cómo el gobierno puede redactar contratos para permitir el uso de metodologías ágiles de manera consistente con la ley, especificando resultados generales en lugar de requisitos detallados sobre cómo funciona el trabajo está por hacerse. Algunos de sus recursos incluyen:

Una ventaja de los métodos de trabajo ágiles es que se centran en descubrir una solución a un problema después de la adjudicación del contrato, es decir, durante la ejecución posterior a la adjudicación, en lugar de especificar la solución detallada por adelantado como en la Parte 15. Un contrato ágil intenta especifique problemas que requieren soluciones detalladas, a menudo como elementos de la cartera de productos que describen áreas de entrega de contratos de alto nivel.

Al comprender este problema, la Oficina de Administración y Presupuesto y la Oficina de Política Federal de Adquisiciones ordenaron a las agencias que dejaran de usar SOW y cambiaran a usar una Declaración de trabajo de desempeño (PWS) para adquirir servicios. Un PWS "debería indicar los requisitos en términos generales de qué (resultado) se debe hacer, en lugar de cómo (método) se hace". Los buenos oficiales de contratación aconsejan a las agencias que al comprar servicios expertos, implica que usted no es el más informado en "cómo" se realiza el trabajo. Como propietario de la misión, usted es el experto en "qué" debe lograrse, pero la combinación de ambos pone en riesgo su misión y dificulta que un contrato brinde valor.

Básicamente, el enfoque es más parecido a contratar a un proveedor de servicios para que trabaje con usted para diseñar una solución, en lugar de enumerar páginas de especificaciones detalladas por adelantado. La institución no contrataría a un arquitecto para diseñar un nuevo edificio enumerando "el diseño debe ser de cuatro pisos, con una inclinación del techo de 37º. El tercer piso debe tener una cocina de 237 pies cuadrados que contenga cuatro lámparas fluorescentes, controladas por un movimiento -interruptor de luz sensible, en un falso techo ". Más bien, tendrían un contrato para que el arquitecto brinde servicios de diseño en consulta con el cliente, y confíe en su proveedor, un experto en el campo, para producir los resultados resultantes.

Si bien los detalles dependerán de la institución y las políticas y leyes de adquisiciones que apliquen, sí muestra que, en medio de todas las fallas de los grandes proyectos de TI del gobierno, hay grupos que trabajan para llevar las licitaciones públicas para el desarrollo de software a metodologías ágiles más modernas, dada suficiente voluntad política y socios de desarrollo confiables. Se necesita un cambio importante en la forma en que se conciben y gestionan dichos proyectos (incluyendo mucho tiempo continuo proporcionando comentarios de los usuarios durante todo el proceso), lo que la organización puede o no tener interés en llevar a cabo.

Zach Lipton
fuente
3
Esta es una gran respuesta, especialmente los últimos dos párrafos. Esta es realmente una excelente manera de poner las cosas que no he podido armar de manera coherente.
Thomas Owens
1
Sí, esta es la respuesta. El contrato y cómo se escribió es el problema. No puedo confirmar ni negar que en algún momento de mi vida he trabajado para una organización similar o similar, y cuando cambiaron a un contrato más orientado a los resultados, el desarrollo ágil comenzó a extenderse como un incendio forestal.
Greg Burghardt
Por lo tanto, parece que el 'arquitecto' necesita ayudar a escribir la licitación en primer lugar, antes de que pueda presupuestarse y otorgarse un plazo. Es un proceso de dos fases, con la segunda frase: "tú, construye esto, el día de apertura es ..."
12

Suena típico. Una vez que se ha escrito la licitación, las ofertas entran y uno de los contendientes ha obtenido el contrato ... en lo que respecta a los representantes de la organización pública, el proyecto está terminado.

Es por eso que muchos de estos proyectos fracasan. Después de que superaron el presupuesto.

El punto que les falta (o al menos no sienten que sea de su incumbencia) es que son partes interesadas que deberían asistir a reuniones y demostraciones.

Por lo tanto, no hay conflicto con Agile o Scrum. Es la gente que no toma sus roles. Es la forma en que funciona el gobierno lo que causa esto.

No es como "nos gustaría tener este sistema y estamos dispuestos a esforzarnos y ver hasta dónde podemos llegar".

No. Es como "nuestra democracia ha decidido que tendremos este sistema, para entonces". Lo que no deja espacio entre el 100% de éxito por un lado y el 100% de fracaso por el otro. Condenado desde el principio.

También es una invitación al mercado para pedir tarifas ridículas. No hacer el proyecto porque es demasiado costoso no es una opción, la decisión de hacerlo ya se tomó antes de que se redactara la licitación.

Es justo, incluso si las partes interesadas asumieran sus roles, serían totalmente impotentes. Ninguno de ellos tendría un palo creíble para llevar a esos demos por la misma razón.

Martin Maat
fuente
55
Esto realmente no responde la pregunta. ¿Qué recomendarías a esta organización?
Philipp
99
¿No es este un cliché contra los gobiernos responsables de todos los fracasos, más que una respuesta constructiva? No lo sé en su país, pero en mi país hay muchos proyectos gubernamentales exitosos. No podré cambiar de opinión, pero aquí hay un artículo interesante basado en hechos objetivos y observaciones independientes: mckinsey.com/industries/public-sector/our-insights/…
Christophe
66
"Es por eso que muchos de estos proyectos fracasan. Después de que superaron el presupuesto". Este tropo es reclamado todo el tiempo por personas que impulsan procesos ágiles. Y, sin embargo, hay muchas empresas de desarrollo exitosas que no utilizan ninguno de los métodos ágiles propuestos. Tienden a hacerlo sin problemas. En todo caso, el verdadero problema es la práctica de contratar al postor más barato y no poner suficiente énfasis en el desempeño pasado y la experiencia en el dominio. Culpar al proceso es un arenque rojo. Cualquier equipo competente puede lograr el éxito utilizando cualquier proceso razonable con el que tengan habilidad.
Dunk
OK, me dejé llevar un poco. Todavía recomendaría monitorear el progreso y asumir el rol de parte interesada, después de la firma del contrato, suponiendo que sea del mejor interés para todos cumplir. Y no estoy afirmando que Agile sea la clave, estoy afirmando que no hay conflicto con los principios Agile y señalé un problema subyacente común.
Martin Maat
Re: "asumiendo que es en el mejor interés de todos entregar": donde vivo tuvimos un proyecto a largo plazo muy costoso (para una expansión de servicios públicos) fracasó, con la bancarrota del constructor (una mega mega mundial de un siglo de antigüedad) empresa) y la agencia de servicio público que aprobó la legislación potencialmente ilegal, y los clientes esperaban rescatar a todos. En el gobierno, no se supone que suceda este tipo de cosas, es de interés para todos que todas las partes sigan siendo viables, éticas y cumplan lo que prometieron. No estoy seguro si los procesos pueden ayudar con eso o no.
12

No, SCRUM no es incompatible con las licitaciones públicas. Debe indicar explícitamente lo que está comprando en una licitación pública.

"El comprador está buscando comprar 10 sprints de desarrollo de 2 semanas, de un equipo SCRUM experimentado que contiene 5 desarrolladores y un maestro SCRUM certificado (el comprador cumplirá el rol de Stakeholder). Sprints se ejecutará desde marzo de 2018 hasta julio de 2018" es bastante razonable inicio de la licitación. Deberá enumerar las habilidades de equipo necesarias, por supuesto, y dar una idea sobre el proyecto en el que trabajarán, pero es perfectamente aceptable tener una licitación para contratar un equipo.

Por supuesto, estás renunciando al "alcance fijo" aquí. Eso es típico de SCRUM, después de todo. Con un poco más de redacción en la licitación (pero estamos entrando en territorio legal aquí) puede permitir una pequeña extensión de alcance, es decir, una pequeña cantidad de sprints adicionales. Pero si decide que desea 10 sprints adicionales después de los 10 sprints iniciales, es probable que deba volver a licitar.

MSalters
fuente
3
Exactamente! Esta es una respuesta excelente y precisa. En este seminario web projectmanagement.com/videos/290684/…, un funcionario del gobierno de EE . UU. Explica cómo funciona en detalle. El principio de trasladar el propósito de la licitación del producto final al servicio de desarrollo también se puede organizar bajo muchas otras legislaciones de adquisiciones de manera similar. La principal dificultad es principalmente la actitud a veces conservadora de algunas partes interesadas, y no una supuesta incompatibilidad.
Christophe
1
¿Entonces contratarían al equipo scrum más barato que puedan encontrar, y cuando el proyecto necesite más horas, contratarían al segundo equipo más barato para hacerse cargo del desarrollo medio? Este enfoque supone que el cliente evalúa la calidad del equipo de software que contrata. Si tienen tanta experiencia, me pregunto qué necesitan para externalizar el contrato en primer lugar.
Meriton - en huelga
@meriton: La mayoría de las licitaciones son del gobierno, que generalmente se requiere para usar la oferta calificada más barata . SCRUM no cambia eso. Sin embargo, SCRUM pone al propietario del producto en un rol activo, lo que ayuda aquí.
MSalters
Sin embargo, si se contrata como sugiere, SCRUM cambia los incentivos para el proveedor de servicios. Ya no pueden ser considerados responsables por no cumplir con los requisitos, su único incentivo es bajar el precio, mientras cumplen con la letra de los criterios de calificación, pero no necesariamente su espíritu. Es más fácil para el comprador evaluar si el software cumple con los requisitos, que si es probable que el equipo produzca software que lo haga. Pero sí, su enfoque es una de las mejores formas de usar SCRUM en el sector público. Solo quería mencionar por qué los compradores podrían no querer adoptarlo.
meriton - en huelga el
9

Es difícil.

Obviamente, no puede licitar el trabajo con un presupuesto abierto. Por lo tanto, debe analizar qué se debe hacer y cuánto esfuerzo se requiere para hacerlo.

Ahora, la razón por la que muchos proyectos de software fallan se debe al hecho de que la fijación, el tiempo, el esfuerzo y el alcance inicial son muy propensos a errores. Por ejemplo, una especificación dada en una licitación casi siempre tendrá cierta ambigüedad.

Por lo tanto, hay un problema fundamental no solo con el ágil, sino con el concepto de licitaciones abiertas para el desarrollo de software. Las posibilidades de que alguien se vaya y cree exactamente lo que quería, en el tiempo que especificó, son bajas.

Si permite cierta flexibilidad, puede mejorar esto.

Parece que el proceso de licitación pública no es flexible. Sin embargo, una vez que se gana el contrato, es posible que haya margen de maniobra. Podría, por ejemplo, permitir un trabajo ágil, pero tendría que aceptar (y obtener autorización legal) que esto podría afectar el alcance.

Ahora creo que esto daría como resultado un mejor producto, ya que podrá ver lo que está sucediendo temprano y realizar cambios antes de incorporarlos al producto. Los ciclos de retroalimentación ajustados y el desarrollo iterativo pueden hacer que los productos se ajusten mejor a los requisitos reales (que pueden o no ser lo que se licitó).

Jeremy French
fuente
3
+1 No puedo contar la cantidad de veces que se ha realizado el trabajo porque alguien aceptó un contrato reconociblemente deficiente y luego usó esa conexión para vender el contrato en algo más cercano a lo que el cliente realmente quería.
Cort Ammon
1
Permítanme resaltar esto: esta respuesta dice que no Scrum es incompatible con las licitaciones públicas, sino el desarrollo de software basado en contratos en general . No es que no esté de acuerdo.
Doc Brown
3

Depende, pero probablemente sí.

Estoy dispuesto a apostar dinero para que todos los que hayan trabajado con algún gobierno en cualquier proyecto relacionado con TI sepan que, en la práctica, los "límites duros" descritos en la licitación nunca se cumplen. Las cosas tienden a sobrepasar el presupuesto, retrasarse y / o cambiar el alcance. Por lo general, múltiplo de esos. Si los gobiernos están dispuestos a admitir que esta es la verdad y están dispuestos a tratarlos como las pautas que son, entonces el scrum puede funcionar realmente bien.

Por experiencia personal (tanto la mía como la de mi red profesional) sé que los requisitos cambian con frecuencia en la mayoría de los proyectos gubernamentales. Los comités responsables también tienden a recibir muchos comentarios cuando finalmente se involucran al final de un proyecto. Estos son problemas para los que Scrum es muy adecuado.

Sin embargo, esto requeriría un cambio fundamental de mentalidad por parte de los gobiernos y sus agencias. En la mayoría de los países, es muy poco probable que este cambio ocurra alguna vez. Hasta ese momento, las licitaciones públicas continuarán siendo incompatibles con el trabajo con Scrum. (De hecho, en mi opinión personal, las licitaciones públicas continuarán siendo incompatibles con cualquier práctica de desarrollo de software sostenible, pero ese es otro asunto para otro momento ...)

Cronax
fuente
Iba a escribir un comentario como su última declaración entre paréntesis, pero le dejaré obtener el crédito :)
3

¿Qué recomendarías a esta organización?

En este punto nada.

Lo que falta aquí es la historia de qué problemas les está causando su proceso actual. Scrum no es algo para recomendar a ciegas. Tiene un punto. No es de talla única.

Pregúnteles qué problemas les ha causado su proceso actual. Escucha. Solo recomiende métodos que aborden sus problemas reales. Van a estar sesgados hacia su proceso actual. Puede parecer que los Tinders dictan un proceso de desarrollo, pero no lo hacen. Dictan un proceso de entrega. Pero esa es una distinción que este equipo probablemente nunca haya tenido que hacer antes.

Agile funciona mejor cuando los requisitos cambian más del 3% durante la vida del proyecto. De lo contrario, la cascada sigue siendo muy efectiva. Todavía se usa en muchos lugares hoy. Y, por supuesto, muchos desarrolladores exitosos nunca formalizan su proceso de ninguna manera. Informal funciona bien cuando los problemas difíciles son técnicos, no sobre las personas.

Hable con ellos sobre su proceso actual y los problemas que tiene. Cuénteles sobre con qué ayudan estos métodos. Pero si no está roto, no lo arregles.

naranja confitada
fuente