Lidando com horizontes de planejamento mais longosEditar
As equipes de desenvolvimento normalmente refinam seu backlog em até duas a três iterações à frente, mas em organizações maiores a equipe de marketing de produto precisa planejar mais à frente para seus compromissos com o mercado e discussões com os clientes. Freqüentemente, eles trabalharão com um roteiro de 12 a 18 meses de nível muito alto e, em seguida, farão um planejamento colaborativo com as equipes durante três meses de trabalho. As equipes de desenvolvimento ainda entrarão em refinamento detalhado 2-3 iterações à frente, apenas entrando em planos de tarefas detalhados para a próxima iteração.
Mantendo a agilidade em níveis abstratos de responsabilidade Editar
Enquanto as equipes de desenvolvimento tem uma série de frameworks que definem como eles devem ser ágeis, há muito pouco que descreve isso para gerenciamento. O SAFe entrega muitos dos mesmos princípios, como equipes multifuncionais, aos grupos que lidam com os níveis mais abstratos de responsabilidade e planejamento (produto e portfólio). O SAFe também foi criticado por agregar muitas práticas díspares.
Lidando com a autoridade delegadaEditar
No Scrum, espera-se que o proprietário do produto assuma a responsabilidade por todo o ciclo de vida do produto, incluindo o retorno sobre o investimento das decisões de desenvolvimento, bem como o desempenho no mercado. Em desenvolvimentos em grande escala, a organização deseja uma visão de vários backlogs da equipe, como os fornecidos por um gerente de produto. Embora o SAFe assuma que a função de proprietário do produto fica com o gerenciamento do produto, ele foi criticado por separar os proprietários do produto na organização de desenvolvimento.
Sincronizando DeliverablesEdit
Os frameworks Agile são projetados para permitir o desenvolvimento equipe para ser autônoma e livre para projetar como eles funcionam. A SAFe reconhece que, na escala de muitas dezenas ou centenas de equipes de desenvolvimento, torna-se cada vez mais caótico para as equipes se auto-organizarem totalmente. Portanto, impõe algumas restrições sobre isso, de modo que, onde as equipes estão trabalhando no mesmo produto, seus produtos podem ser melhor sincronizados para lançamento juntos, embora esta seja uma área na qual o SAFe foi criticado.
Permitindo tempo para inovação e planningEdit
O ciclo de planejamento SAFe recomenda incluir uma iteração adicional após um lançamento, para que as equipes possam melhorar suas práticas e estejam prontas para o próximo incremento de planejamento. As edições anteriores do SAFe também projetaram isso para ser uma iteração de endurecimento, ou seja, para estabilizar ou endurecer o produto antes de liberá-lo. Isso se baseava nas complicações de trabalhar com grandes ambientes de integração em que dependências significavam que você não podia testar tudo até o final. O SAFe foi criticado por isso, pois representava um elemento anti-ágil ou em cascata, mas estava em linha com incrementos enxutos de 90 dias que perfazem 13 semanas, e se fizer sprints de duas semanas, você precisa de seis deles mais um planejamento de uma semana ou ciclo de endurecimento. Isso não está incluído nas edições recentes do SAFe.