O Scrum é incompatível com os concursos públicos?

43

Fui convidado por uma organização pública a dar um workshop informal sobre os 101 do desenvolvimento ágil, explicando os termos e conceitos de Scrum, Kanban e similares. Trabalho em ambientes ágeis há cerca de cinco anos, mas não me considero evangelista do Scrum.

Após o workshop, eles gostaram da ideia. No entanto, eles explicaram que a abordagem provavelmente não se aplicaria a eles, pois eles precisam contratar empresas de software externas para desenvolver software para elas (elas têm apenas alguns desenvolvedores). Essa atividade precisa ser realizada em um processo de licitação pública que descreva o resultado, preço e prazo. Este é um requisito legal para solicitar um orçamento para esta organização (um instituto público de pesquisa).

Essas restrições parecem um tanto contraditórias aos princípios fundamentais do desenvolvimento ágil, não são?

Scrum é apenas incompatível em tal ambiente?

O que você recomendaria para esta organização?

bakoyaro
fonte
1
Se o resultado, o preço e o prazo puderem ser feitos antecipadamente, por que se preocupar com um processo ágil?
21818 JeffO
3
Scrum é compatível com tudo, por definição. O paradigma "A equipe é dona do processo" permite alterar radicalmente o processo, para que o Scrum possa se tornar Waterfall, se necessário. Ser "ágil" significa NÃO que você precise seguir algum processo com desvio zero. Isso significa que o processo pode ser adotado de acordo com as necessidades. Observe que esse ponto é EXTREMAMENTE impopular com o gerenciamento - eles querem processos fixos e chamarão qualquer coisa de "ágil" se tiverem sido ligados ao Agile / Scrum / Whatever.
Klaws
3
FWIW, IME, nunca vi nada como Sebazzz descreve. O contrato diz especificamente o que deve ser entregue. Se não atender aos requisitos, você não estará pronto. E esse é todo o problema com os métodos ágeis "entregue o que você tem quando os fundos acabarem". É uma ocasião rara em que você pode entregar um produto que apenas faz um subconjunto do que o cliente precisa e é realmente de valor para o cliente. Normalmente, é o mesmo que não funciona. Os desvios podem ser solicitados, mas se esse desvio remove funcionalidade, então, que quase certamente é combinado com menos fundos
Dunk
2
@ CortAmmon - O que eu vi o governo fazer é "inteligente", mas não muito ágil. Eles ainda seguem basicamente a cascata, eles concedem o contrato em fases, em vez de todo o esforço de desenvolvimento do ciclo de vida, como fizeram no passado. Eles também são mais propensos a contratar mais de um contratado, especialmente na fase de engenharia, pois isso permite que eles selecionem competitivamente a melhor solução que desejam fazer a transição para um produto fabricável. Essa última fase é a mais cara. Eles querem ver o que estão recebendo antes de decidirem fabricar. Um produto parcialmente funcional não vencerá.
Dunk

Respostas:

38

Provavelmente, o Scrum não é apropriado para esta organização.

No Guia Scrum, "Scrum é uma estrutura para o desenvolvimento, fornecimento e manutenção de produtos complexos". Também foi desenvolvido para uma equipe de 3 a 9 membros de uma Equipe de Desenvolvimento que trabalha no produto, um Dono do Produto e um Scrum Master (que podem ou não estar na Equipe de Desenvolvimento), totalizando de 4 a 11 pessoas.

Com 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 uma equipe Scrum, 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. Nesse caso, é útil que o instituto de pesquisa conheça as práticas do Scrum e compreenda os papéis e como ele funciona. Eles ainda podem precisar entender as especificidades de como a organização de desenvolvimento externa usa as práticas do Scrum, bem como outras práticas, mas isso pode ajudá-los a entender como funciona. Por exemplo, entendendo a necessidade de participar das Revisões da Sprint ou de trabalhar com a organização (provavelmente o Dono do Produto) no pedido do Backlog do Produto.

Thomas Owens
fonte
Excelente resposta. É muito difícil, embora não impossível, que organizações como a descrita pelo OP avancem para uma abordagem ágil.
Mister Positive
1
@MisterPositive Você pode não precisar que o instituto de pesquisa se torne ágil. No entanto, eles provavelmente precisarão interagir com entidades externas que são ágeis quando emitem um contrato. Eles podem ver os benefícios do ágil, com certeza.
Thomas Owens
A parte realmente boa sobre essa resposta é IMHO, que ela não cai na armadilha de argumentar sobre o Scrum que não é adequado porque "resultado, preço e prazo" são fixos.
Doc Brown
1
@DocBrown Talvez porque o Scrum possa ser usado onde o preço e o prazo são fixos. Na minha experiência, quando você está entregando rapidamente e demonstrando coisas às partes interessadas, elas percebem que o que originalmente pensavam que precisavam e o que realmente precisam são duas coisas diferentes. E então eles mudarão o resultado desejado dentro do preço e prazo originais.
Thomas Owens
Aceita. Software não é como ter um arquiteto projetando um edifício. É inerentemente um alvo em movimento, com o chão sempre escorregando sob seus pés. No próximo ano, os esforços do ano passado parecem ultrapassados.
22

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

Uma vantagem dos métodos de trabalho ágeis é que eles se concentram na descoberta de uma solução para um problema após a adjudicação do contrato, ou seja, durante a execução pós-adjudicação, em vez de especificar a solução detalhada antecipadamente, como na Parte 15. Um contrato ágil tenta: especifique problemas que exijam soluções detalhadas, geralmente como Itens do Backlog do Produto que descrevem áreas de entrega de contratos de alto nível.

Entendendo esse problema, o Escritório de Gerenciamento e Orçamento e o Escritório de Política Federal de Compras determinaram que as agências parassem de usar SOWs e passassem a usar uma Declaração de Trabalho de Desempenho (PWS) para a aquisição de serviços. Um PWS “deve declarar requisitos em termos gerais do que (resultado) deve ser feito, e não como (método) é feito”. Os bons contratantes aconselham as agências que, ao comprar serviços especializados, isso implica que você não é o mais conhecedor. em "como" o trabalho é feito. Como proprietário da missão, você é o especialista em "o quê", deve ser cumprido, mas a fusão das duas coloca sua missão em risco e dificulta o fornecimento de valor por um contrato.

Fundamentalmente, a abordagem é mais como contratar um provedor de serviços para trabalhar com você para projetar uma solução, em vez de listar antecipadamente páginas de especificações detalhadas. A instituição não contrataria um arquiteto para projetar um novo edifício 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 sensível à luz, em um teto suspenso. " Em vez disso, eles teriam um contrato para o arquiteto fornecer serviços de design em consulta com o cliente, e confiariam em seu fornecedor, um especialista na área, para produzir os resultados resultantes.

Embora os detalhes dependam da instituição e das políticas e leis de compras aplicáveis, ele mostra que, em meio a todas as falhas de grandes projetos de TI do governo, há grupos trabalhando para mover licitações públicas para desenvolvimento de software para metodologias ágeis mais modernas, dada vontade política suficiente e parceiros de desenvolvimento confiáveis. É preciso uma grande mudança na maneira como esses projetos são concebidos e gerenciados (incluindo muito tempo em andamento, fornecendo feedback do usuário ao longo do processo), que a organização pode ou não ter interesse em prosseguir.

Zach Lipton
fonte
3
Esta é uma ótima resposta, especialmente os dois últimos parágrafos. Essa é realmente uma ótima maneira de reunir coisas que não consegui reunir de maneira coerente.
Thomas Owens
1
Sim, esta é a resposta. O contrato e como foi escrito é o problema. Não posso confirmar nem negar que, em algum momento de minha vida, trabalhei para uma organização como essa ou semelhante, e quando eles mudaram para um contrato mais orientado a resultados, o desenvolvimento ágil começou a se espalhar como fogo.
precisa
Parece que o 'arquiteto' precisa ajudar a redigir a proposta em primeiro lugar, antes de poder ser orçada e ter um prazo. É um processo de duas fases, com a segunda frase sendo: "você, construir este, dia de abertura é ..."
12

Parece típico. Uma vez redigida a proposta, as ofertas são recebidas e um dos concorrentes recebe o contrato ... no que diz respeito aos representantes da organização pública, o projeto está concluído.

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

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

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

Não é como "gostaríamos de ter esse sistema e estamos dispostos a colocar algum esforço nele e ver até onde podemos levá-lo".

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

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

Justo, mesmo que as partes interessadas assumissem seus papéis, elas seriam totalmente impotentes. Nenhum deles teria um bastão credível para levar a essas demos pelo mesmo motivo.

Martin Maat
fonte
5
Isso realmente não está respondendo à pergunta. O que você recomendaria para esta organização?
Philipp
9
Isso não é um clichê contra governos que seria responsável por todas as falhas, mais que uma resposta construtiva? Não sei no seu país, mas no meu país existem muitos projetos governamentais bem-sucedidos. Eu não será capaz de mudar de idéia, mas aqui um artigo interessante baseada em fatos objetivos e observações independentes: mckinsey.com/industries/public-sector/our-insights/...
Christophe
6
"É por isso que muitos desses projetos fracassam. Depois de ultrapassarem o orçamento". Esse tropo é reivindicado o tempo todo por pessoas que pressionam processos ágeis. E, no entanto, existem inúmeras empresas de desenvolvimento de sucesso que não usam nenhum dos métodos ágeis propostos. Eles tendem a fazê-lo sem problemas. Na verdade, o problema real é a prática de contratar o licitante mais barato e não colocar ênfase suficiente no desempenho passado e nos conhecimentos do domínio. Culpar o processo é um arenque vermelho. Qualquer equipe competente pode obter sucesso usando qualquer processo razoável com o qual tenha habilidade.
Dunk
OK, fiquei um pouco empolgado. Eu ainda recomendaria monitorar o progresso e assumir esse papel de partes interessadas, após a assinatura do contrato, assumindo que é do interesse de todos entregar. E não estou afirmando que o Agile é a chave, estou afirmando que não há conflito com os princípios do Agile e apontou um problema subjacente comum.
Martin Maat
Re: "supondo que seja do interesse de todos entregar": onde eu moro, tivemos um projeto de longo prazo muito caro (para uma expansão de serviços públicos) falhar, com a falência do construtor (uma mega- empresa) e a agência de serviço público que foram aprovadas leis potencialmente ilegais, e os clientes esperavam socorrer a todos. No governo, esse tipo de coisa não deveria acontecer, é do interesse de todos que todas as partes permaneçam viáveis, éticas e cumpram o que prometeram. Não tenho certeza se os processos podem ajudar com isso ou não.
12

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.

"O comprador deseja comprar 10 sprints de desenvolvimento de duas semanas, de uma equipe experiente do SCRUM, com 5 desenvolvedores e um mestre certificado do SCRUM (o comprador assumirá o papel de partes interessadas). Os sprints serão executados de março de 2018 a julho de 2018" é bastante razoável início do concurso. Você precisará listar as habilidades de equipe necessárias, é claro, e dar uma idéia sobre o projeto em que trabalharão, mas é perfeitamente aceitável ter uma proposta para contratar uma equipe.

Claro, você está desistindo do "escopo fixo" aqui. Isso é típico para o SCRUM, afinal. Com um pouco mais de redação no concurso (mas estamos entrando em 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 deseja 10 corridas adicionais após as 10 corridas iniciais, provavelmente precisará repetir o concurso.

MSalters
fonte
3
Exatamente ! Esta é uma resposta excelente e precisa. Neste seminário on-line projectmanagement.com/videos/290684/…, um funcionário do governo dos EUA explica como funciona em todos os detalhes. O princípio de mudar o objetivo do concurso do produto final para o serviço de desenvolvimento também pode ser organizado sob muitas outras legislações de compras de maneira semelhante. A principal dificuldade é principalmente a atitude às vezes conservadora de algumas partes interessadas, e não a dita incompatibilidade.
Christophe
1
Então eles contrataram a equipe de scrum mais barata que puderam encontrar e, quando o projeto precisa de mais horas, contratam a segunda equipe mais barata para assumir o desenvolvimento intermediário? Essa abordagem pressupõe que o cliente avalie a qualidade da equipe de software que contratar. Se eles têm essa experiência, eu me pergunto o que eles precisam para terceirizar o contrato em primeiro lugar?
meriton - em greve 7/0318
@meriton: a maioria das propostas é do governo, que geralmente é necessária para usar a oferta de qualificação mais barata . SCRUM não muda isso. No entanto, o SCRUM coloca o proprietário do produto em uma função ativa, o que ajuda aqui.
MSalters
No entanto, se contratado como você sugere, o SCRUM altera os incentivos para o provedor de serviços. Eles não podem mais ser responsabilizados por não atenderem aos requisitos, seu único incentivo é diminuir o preço, enquanto cumprem a letra dos critérios de qualificação, mas não necessariamente seu espírito. É mais fácil para o comprador avaliar se o software atende aos requisitos do que se a equipe provavelmente produzirá o software. Mas sim, sua abordagem é uma das melhores maneiras de usar o SCRUM no setor público. Eu só queria mencionar por que os compradores podem não querer adotá-lo.
meriton - em greve 8/0318
9

É difícil.

Obviamente, você não pode oferecer o trabalho com um orçamento em aberto. Portanto, você precisa analisar o que precisará ser feito e quanto esforço é necessário para fazer isso.

Agora, a razão pela qual muitos projetos de software falham se deve ao fato de que a fixação, o tempo, o esforço e o escopo são muito propensos a erros. Por exemplo, uma especificação apresentada 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 concursos abertos para o desenvolvimento de software. As chances de alguém sair e criar exatamente o que você queria, no tempo especificado, são baixas.

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

Parece que o processo de abertura de concurso público não é flexível. No entanto, uma vez que o contrato seja vencido, você poderá descobrir que há espaço para se esquivar. Você poderia, por exemplo, permitir um trabalho ágil, mas precisaria 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 cedo e fazer alterações antes de serem inseridas no produto. Loops de feedback apertados e desenvolvimento iterativo podem tornar os produtos mais adequados aos requisitos reais (que podem ou não ser o que foi licitado).

Jeremy French
fonte
3
+1 Não consigo contar o número de vezes que o trabalho foi realizado porque alguém aceitou um contrato reconhecidamente ruim e depois usou essa conexão para vender o contrato em algo mais próximo do que o cliente realmente queria.
Cort Ammon
1
Deixe-me destacar isso - esta resposta diz que o Scrum não é incompatível com os concursos públicos, mas o desenvolvimento de software baseado em contrato em geral . Não que eu discorde.
Doc Brown
3

Depende, mas provavelmente sim.

Estou disposto a apostar dinheiro para que todos os que já trabalharam com qualquer governo em qualquer projeto relacionado à TI saibam que, na prática, os 'limites rígidos' descritos no concurso nunca são cumpridos. As coisas tendem a exceder o orçamento, atrasam e / ou o escopo é alterado. Geralmente vários deles. Se os governos estiverem dispostos a admitir que essa é a verdade e a tratá-los como as diretrizes, então o scrum pode funcionar muito bem.

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

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

Cronax
fonte
Eu estava indo para escrever um comentário como a sua última declaração parênteses, mas eu vou deixar você obter o crédito :)
3

O que você recomendaria para esta organização?

Neste ponto nada.

O que falta aqui é a história de quais problemas o processo atual deles está causando. Scrum não é algo que se recomenda cegamente. Isso tem razão. Não é um tamanho único.

Pergunte a eles que problemas o processo atual lhes causou. Ouço. Apenas recomende métodos que resolvam seus problemas reais. Eles serão direcionados para o processo atual. Os Tinders podem parecer que ditam um processo de desenvolvimento, mas não o fazem. 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 útil do projeto. Caso contrário, a cachoeira ainda é muito eficaz. Ainda é usado em muitos lugares hoje. E, é claro, muitos desenvolvedores de sucesso nunca formalizam seu processo de qualquer maneira. Informal funciona bem quando os problemas difíceis são técnicos, não sobre as pessoas.

Portanto, converse com eles sobre o processo atual e os problemas que ele tem. Diga a eles sobre o que esses métodos ajudam. Mas se não estiver quebrado, não conserte.

candied_orange
fonte