Seu processo de desenvolvimento é tão bom quanto o link mais fraco , então ambos são importantes.
Uma boa equipe que tem um processo desastroso infligido a eles, que sufoca o desenvolvimento ao invés de facilitá-lo, pode acabar menos produtivo do que uma equipe de pobres desenvolvedores ajudados por um bom processo (já vi isso acontecer).
Na minha experiência, no entanto, bons desenvolvedores tendem a gravitar em direção a um fluxo de trabalho mais eficiente, se eles tiverem a autonomia para fazer isso. Ineficiências ou burocracia sem sentido tendem a ser impostas de cima, então um bom gerente / líder de equipe pode ser crítico para evitar que as equipes sejam sufocadas pelo processo.
Outro ponto é que mudar uma equipe é algo que leva tempo, enquanto mudar um processo geralmente é algo que você pode fazer a qualquer momento.
Em peopleware , Tom DeMarco e Timothy Lister falam muito sobre como colocar as equipes em gel , falando sobre crescimento de equipes, em vez de construí-las . Diferentes processos podem colocar barreiras nas equipes gelling ou podem incentivar a equipe a crescer, o que é uma consideração ao desenvolver um processo.
A otimização de um fluxo de trabalho pode ser um processo contínuo, no entanto - problemas ou ineficiências no processo podem ser discutidos e resolvidos à medida que você avança. Se eles funcionam, você pode procurar outras maneiras de melhorar o seu processo, se não, você pode voltar ao modo antigo. Você só precisa ter em mente que o processo é um meio para um fim, não um fim em si .
Em seu ponto final, somente você e sua equipe podem determinar se o Scrum, ou qualquer outra metodologia, atende às suas necessidades. Se você estiver trabalhando em um ambiente de strong queda, a introdução de técnicas ágeis pode apenas causar atrito com outras equipes com as quais você precisa interagir. Da mesma forma, se outras equipes estiverem usando o Scrum, você pode descobrir que adotar isso pode ajudar a interação com essas equipes.