O Scrum provavelmente não é apropriado para esta organização.

Do Scrum Guide, "o Scrum é uma estrutura para desenvolver, entregar e sustentar produtos complexos". Ele também é projetado para uma equipe de 3-9 membros de uma equipe de desenvolvimento trabalhando no produto, um dono do produto e um Scrum Master (que pode ou não estar na equipe de desenvolvimento) para um total de 4 a 11 pessoas no total.

Em relação ao desenvolvimento interno, você menciona que eles têm apenas alguns desenvolvedores. Se não houver uma equipe grande o suficiente para formar um Time Scrum, então não faz sentido usar todo o Scrum. No entanto, algumas práticas do Scrum podem ser úteis para a organização.

Para o desenvolvimento contratado, é possível que uma das partes externas use o Scrum. Neste caso, é útil para o instituto de pesquisa conhecer as práticas do Scrum e entender os papéis e como ele funciona. Eles ainda podem precisar entender os detalhes de como a organização de desenvolvimento externa usa as práticas do Scrum, bem como outras práticas, mas pode ajudá-los a entender como ela funciona. Por exemplo, entender a necessidade de participar das Revisões da Sprint ou de trabalhar com a organização (provavelmente o Dono do Produto) ao solicitar o Backlog do Produto.

A 18F, uma agência de serviços digitais do governo dos EUA, trabalhou muito na maneira pela qual o governo pode redigir contratos para permitir o uso de metodologias ágeis de maneira consistente com a lei, especificando resultados gerais em vez de requisitos detalhados. como o trabalho deve ser feito. Alguns de seus recursos incluem:

• Melhorando os resultados do governo por meio de um formato de contrato ágil
• Contrato de compra do Agile Blanket
• Contratação modular (dividindo grandes projetos em modulares menores com desenvolvimento ágil)
• Seu projeto está usando “agilefall”?

An advantage of agile work methods is that they focus on discovering a solution to a problem after the contract is awarded, that is, during post-award execution, rather than specifying the detailed solution up front as with Part 15. An agile contract tries to specify problems requiring detailed solutions, often as Product Backlog Items that describe high level contract delivery areas.

Understanding this problem, the Office of Management and Budget and Office of Federal Procurement Policy directed agencies to stop using SOWs and shift to using a Performance Work Statement (PWS) for acquiring services. A PWS “should state requirements in general terms of what (result) is to be done, rather than how (method) it is done” Good contracting officers advise agencies that by buying expert services, it implies that you’re not the most knowledgeable in “how” work is done. As the mission owner, you are the expert in “what,” must get accomplished, but conflating the two puts your mission at risk and makes it harder for a contract to provide value.

Fundamentalmente, a abordagem é mais como contratar um provedor de serviços para trabalhar com você para projetar uma solução, em vez de listar páginas de especificações detalhadas com antecedência. A instituição não contrataria um arquiteto para projetar um novo prédio listando "o projeto deve ser de quatro andares, com uma inclinação de 37º. O terceiro andar deve ter uma cozinha de 237 pés quadrados contendo quatro luminárias fluorescentes, controladas por um movimento Interruptor de luz sensível à luz, em um teto suspenso ". Em vez disso, eles teriam um contrato para que o arquiteto fornecesse serviços de projeto em consulta com o cliente e confiasse em seu fornecedor, um especialista na área, para produzir as entregas resultantes.

Embora os detalhes dependam da instituição e das políticas de aquisição e leis que se aplicam, mostra que, em meio a todos os fracassos dos grandes projetos de TI do governo, há grupos trabalhando para mover propostas públicas para desenvolvimento de software para mais modernas. metodologias ágeis, com suficiente vontade política e parceiros de desenvolvimento confiáveis. É necessária uma grande mudança na forma como esses projetos são concebidos e gerenciados (incluindo muito tempo contínuo fornecendo feedback do usuário durante todo o processo), que a organização pode ou não ter interesse em buscar.

Parece típico. Uma vez que o concurso foi escrito, as ofertas estão em e um dos candidatos foi concedido o contrato ... no que se refere aos representantes da organização pública, o projeto está feito.

É por isso que muitos desses projetos falham. Depois que eles superaram o orçamento.

O ponto que eles estão perdendo (ou pelo menos não sentem que é de sua preocupação) é que eles são partes interessadas que deveriam participar de reuniões e demonstrações.

Portanto, não há conflito com Agile ou Scrum. São pessoas que não assumem seus papéis. É o modo como o governo trabalha que causa isso.

Não é como "gostaríamos de ter este sistema e estamos dispostos a nos esforçar e ver até onde podemos levá-lo".

Não. É como "nossa democracia decidiu que teremos esse sistema, até então". Que não deixa espaço entre 100% de sucesso, por um lado, e 100% de falha, por outro. Condenado desde o começo.

É também um convite ao mercado para pedir taxas ridículas. Não fazer o projeto porque é muito caro não é uma opção, a decisão de fazê-lo já foi feita antes da redação do concurso.

Justo, mesmo que as partes interessadas assumissem seus papéis, elas seriam totalmente impotentes. Nenhum deles teria um palpite crível para as demonstrações pela mesma razão.

Não, o SCRUM não é incompatível com os concursos públicos. Você precisa declarar explicitamente o que está comprando em um concurso público.

"A Compradora pretende comprar 10 sprints de 2 semanas de desenvolvimento, de uma experiente equipe SCRUM contendo 5 desenvolvedores e um certificado SCRUM master (o comprador preencherá o papel de Stakeholder). Os Sprints serão executados de março de 2018 a julho de 2018" um início bastante razoável da proposta. Você precisará listar as habilidades de equipe necessárias, é claro, e dar uma idéia sobre o projeto em que elas trabalharão, mas é perfeitamente aceitável ter uma proposta para contratar uma equipe.

Claro, você está desistindo do "escopo fixo" aqui. Isso é típico do SCRUM, afinal. Com um pouco mais de redação na proposta (mas estamos chegando ao território legal aqui), você pode permitir uma pequena extensão de escopo, ou seja, um pequeno número de sprints adicionais. Mas se você decidir que gostaria de mais 10 sprints após os 10 sprints iniciais, provavelmente precisará fazer uma nova proposta.

É difícil.

Você obviamente não pode oferecer o trabalho com um orçamento em aberto. Então você tem que olhar para o que precisa ser feito e quanto esforço é necessário para fazer isso.

Agora, a razão pela qual muitos projetos de software falham é devido ao fato de que a correção, o tempo, o esforço e o escopo são muito propensos a erros. Por exemplo, uma especificação como dada em uma proposta quase sempre terá alguma ambiguidade.

Portanto, há uma questão fundamental não apenas com o ágil, mas com o conceito de licitações abertas para o desenvolvimento de software. As chances de alguém sair e criar exatamente o que você queria, no tempo que você especificou, são baixas.

Se você permitir alguma flexibilidade, poderá melhorar isso.

Parece que o processo de colocar o trabalho em concurso público não é flexível. No entanto, uma vez que o contrato é vencido, você pode achar que há espaço de contorção. Você poderia, por exemplo, permitir um trabalho ágil, mas teria que aceitar (e obter autorização legal) que isso poderia afetar o escopo.

Agora, acredito que isso resultaria em um produto melhor, pois você poderá ver o que está acontecendo no início e fazer alterações antes que elas sejam incorporadas ao produto. Os apertados ciclos de feedback e o desenvolvimento iterativo podem tornar os produtos mais adequados aos requisitos reais (que podem ou não ser o que foi lançado).

Depende, mas provavelmente sim.

Estou disposto a apostar que todos que já trabalharam com qualquer governo em qualquer projeto relacionado a TI saberão que, na prática, os "limites rígidos" descritos na proposta nunca serão cumpridos. As coisas tendem a ultrapassar o orçamento, atrasam e / ou o escopo é alterado. Geralmente vários desses. Se os governos estão dispostos a admitir que esta é a verdade e se dispõem a tratá-los como as diretrizes que são, então o scrum pode funcionar muito bem.

A partir da experiência pessoal (tanto minha como da minha rede profissional), sei que os requisitos mudam frequentemente na maioria dos projetos do governo. Os comitês responsáveis também tendem a ter muito feedback quando finalmente se envolvem no final de um projeto. Estes são problemas para os quais o Scrum é bem adequado.

No entanto, isso exigiria uma mudança fundamental de mentalidade por parte dos governos e suas agências. Na maioria dos países, é muito improvável que essa mudança ocorra alguma vez. Até lá, os editais continuarão a ser incompatíveis com o trabalho com o Scrum. (Na verdade, na minha opinião pessoal, os concursos públicos continuarão a ser incompatíveis com qualquer práticas de desenvolvimento de software sustentáveis, mas isso é outra questão para outro momento ...)

What would you recommend to this organization?

Neste ponto nada.

O que falta aqui é a história de quais problemas o processo atual está causando. Scrum não é algo para recomendar cegamente. Tem um ponto. Não é um tamanho único para todos.

Pergunte quais problemas o processo atual causou a eles. Ouço. Apenas recomende métodos que resolvam seus problemas reais. Eles vão ser inclinados para o seu processo atual. Tinders podem parecer que eles ditam um processo de desenvolvimento, mas não ditam. Eles ditam um processo de entrega. Mas essa é uma distinção que essa equipe provavelmente nunca teve que fazer antes.

O Agile funciona melhor quando os requisitos mudam mais de 3% ao longo da vida do projeto. Caso contrário, a cascata ainda é muito eficaz. Ainda é usado em muitos lugares hoje. E, claro, muitos desenvolvedores de sucesso nunca formalizam seu processo de qualquer maneira. O informal funciona bem quando os problemas difíceis são técnicos, não sobre as pessoas.

Então fale com eles sobre o processo atual e os problemas que tem. Diga-lhes sobre o que esses métodos ajudam. Mas se não está quebrado, não conserte.