Es probable que Scrum 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 a 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 a 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 deban entender los aspectos específicos de cómo la organización de desarrollo externo utiliza las prácticas de 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 el propietario del producto) en el pedido de la cartera de productos.

18F, una agencia de servicios digitales dentro del gobierno de EE. UU., ha trabajado mucho en cómo el gobierno puede redactar contratos para permitir el uso de metodologías ágiles de manera compatible con la ley, especificando resultados generales en lugar de requisitos detallados para Cómo se debe hacer el trabajo. Algunos de sus recursos incluyen:

• Mejorando los resultados del gobierno a través de un formato de contrato ágil
• Acuerdo de compra de manta ágil
• Contratación modular (dividiendo grandes proyectos en pequeños proyectos modulares con desarrollo ágil)
• ¿Está su proyecto utilizando "agilefall"?

  

Una ventaja de los métodos de trabajo ágil es que se centran en descubrir una solución a un problema después de adjudicarse el 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 ágil el contrato trata de especificar 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 de Adquisiciones Federales ordenaron a las agencias que dejaran de usar los SOW y pasaran a usar una Declaración de desempeño laboral (PWS) para adquirir servicios. Un PWS "debe establecer los requisitos en términos generales de qué (resultado) se debe hacer, en lugar de cómo (método) se hace". Los buenos contratistas aconsejan a las agencias que al comprar servicios expertos, esto implica que usted no es el que más sabe. en “cómo” se realiza el trabajo. Como propietario de la misión, usted es el experto en "qué", debe lograrlo, pero la combinación de ambos pone en riesgo su misión y dificulta que un contrato proporcione valor.

Fundamentalmente, el enfoque es más como contratar a un proveedor de servicios para que trabaje con usted para diseñar una solución, en lugar de enumerar las páginas de especificaciones detalladas con anticipación. La institución no contrataría a un arquitecto para diseñar un nuevo edificio al enumerar "el diseño debe tener cuatro pisos, con una inclinación de 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 techo abatible. Más bien, tendrían un contrato para que el arquitecto proporcione servicios de diseño en consulta con el cliente, y confíe en su proveedor, un experto en el campo, para producir los entregables resultantes.

Si bien los detalles dependerán de la institución y de las políticas y leyes de adquisiciones que se apliquen, sí muestra que, en medio de todos los fracasos de los grandes proyectos de TI del gobierno, hay grupos que trabajan para hacer que las licitaciones públicas para el desarrollo de software pasen a ser más modernas. Metodologías ágiles, dada la suficiente voluntad política y socios de desarrollo confiables. Se requiere un cambio importante en la forma en que se conciben y administran dichos proyectos (incluido un montón de tiempo continuo para proporcionar comentarios de los usuarios a lo largo del proceso), que la organización puede o no tener interés en continuar.

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

Es por esto que muchos de estos proyectos fallan. Después de que pasaron por encima del presupuesto.

El punto en el que faltan (o al menos no se sienten preocupados por ellos) es que son partes interesadas que deberían asistir a reuniones y demostraciones.

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

No es como "nos gustaría tener este sistema y estamos dispuestos a ponerle un poco de esfuerzo y ver hasta dónde podemos llegar".

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

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

Lo suficientemente 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 esas demostraciones por la misma razón.

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 experimentado de SCRUM que contiene 5 desarrolladores y un maestro SCRUM certificado (el comprador cumplirá el rol de partes interesadas). Los Sprints se ejecutarán desde marzo de 2018 hasta julio de 2018" es Un comienzo bastante razonable de la oferta. Por supuesto, deberá enumerar las habilidades de equipo necesarias y dar una idea sobre el proyecto en el que trabajarán, pero es perfectamente aceptable tener una oferta 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 llegando a territorio legal aquí) puede permitir una extensión de alcance pequeño, es decir, un pequeño número de sprints adicionales. Pero si decide que desea 10 sprints adicionales después de los 10 sprints iniciales, es probable que tenga que volver a licitar.

Es difícil.

Obviamente, no puede ofertar el trabajo con un presupuesto abierto. Por lo tanto, debe ver qué se necesita 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 corrección, el tiempo, el esfuerzo y el alcance por adelantado son muy propensos a errores. Por ejemplo, una especificación como se da en una licitación casi siempre tendrá cierta ambigüedad.

Por lo tanto, existe un problema fundamental no solo con Agile, sino con el concepto de licitaciones abiertas para el desarrollo de software. Las posibilidades de que alguien se vaya y creen exactamente lo que querías, en el tiempo que especificaste, son bajas.

Si permites cierta flexibilidad, puedes mejorar esto.

Parece que el proceso de adjudicar el trabajo a una licitación pública no es flexible. Sin embargo, una vez que se gane el contrato, es posible que haya espacio de maniobra. Por ejemplo, podría permitir el trabajo ágil, pero tendría que aceptar (y obtener la 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 antes y realizar cambios antes de que se incorporen al producto. Los circuitos de retroalimentación ajustados y el desarrollo iterativo pueden hacer que los productos se ajusten mejor a los requisitos de actual (que pueden o no ser lo que se licitó).

Depende, pero probablemente sí.

Estoy dispuesto a apostar dinero para que todos los que hayan trabajado con cualquier gobierno en cualquier proyecto relacionado con TI sepan que en la práctica, los "límites estrictos" descritos en la licitación nunca se cumplen. Las cosas tienden a sobrepasar el presupuesto, se retrasan y / o se cambia el alcance. Por lo general, múltiples 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, el scrum puede funcionar realmente bien.

Por experiencia personal (tanto mía como en 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 tener muchos comentarios cuando finalmente se involucran al final de un proyecto. Estos son problemas para los que Scrum es adecuado.

Sin embargo, esto requeriría un cambio fundamental en la mentalidad de los gobiernos y sus agencias. En la mayoría de los países, es muy improbable que este cambio se lleve a cabo. Hasta ese momento, las licitaciones públicas continuarán siendo incompatibles con el trabajo con Scrum. (En este sentido, en mi opinión personal, las licitaciones públicas continuarán siendo incompatibles con cualquier prácticas de desarrollo de software sostenible, pero eso es otro asunto para otro momento ...)

  

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

En este punto nada.

Lo que falta aquí es la historia de los problemas que 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 se recomiendan métodos que aborden sus problemas reales. Van a estar sesgados hacia su proceso actual. Los tinders pueden parecer que 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 tuvo 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 utiliza en muchos lugares hoy en día. Y, por supuesto, muchos desarrolladores exitosos nunca formalizan su proceso de ninguna manera. El trabajo informal funciona bien cuando los problemas difíciles son técnicos, no sobre las personas.

Entonces hable con ellos sobre su proceso actual y los problemas que tiene. Dígales sobre qué ayudan estos métodos. Pero si no está roto, no lo arregles.