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?

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.

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:

• Mejora de los resultados del gobierno a través de un formato de contrato ágil
• Acuerdo de compra de manta ágil
• Contratación modular (división de proyectos grandes en modulares más pequeños con desarrollo ágil)
• ¿Su proyecto utiliza "agilefall"?

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.

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.

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.

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ó).

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 ...)

¿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.