Introdução

O framework SAFe 5.0 possui quatro configurações diferentes para prover a solução mais adequada para cada empresa. A Big Picture abaixo mostra a configuração Full SAFe, que é a mais abrangente, direcionada a soluções complexas com dezenas de equipes trabalhando para entregar o produto. Também há a configuração Essential, Large Solution e Portfolio SAFe.

O SAFe implementation roadmap descreve uma estratégia e um conjunto de atividades recomendadas para implementação do SAFe, com base em outros casos bem sucedidos. O Reaching the Tipping Point é o ponto inicial, pois não é nada fácil promover a mudança na maneira de trabalhar em uma grande organização.

1. Thriving in the Digital Age with Business Agility

O SAFe for Lean Enterprises concentra conhecimento, principios, praticas e competências para atingir Business Agility, implementando Lean, Ágil e DevOps em escala. As sete competências core do Business Agility:

• Lean-Agile Leadership: direciona e mantém a mudança organizacional e excelência operacional, empoderando os times e pessoas.
• Continuous Learning Culture: valores e praticas para continuamente aumentar o conhecimento, competência, performance e inovação.
• Team and Technical Agility: descreve os skills, principios e práticas Lean-Agile usadas pelos times para criar soluções aos clientes.
• Agile Product Delivery: abordagem customer-centric para definir, construir e entregar um fluxo contínuo de produtos e serviços de valor.
• Enterprise Solution Delivery: como aplicar principios e práticas a especificação, desenvolvimento, operação e evolução de aplicações, redes e sistemas ciber-físicos.
• Lean Portfolio Management: alinha estratégia e execução aplicando Lean e Systems Thinking
• Organizational Agility: otimiza o processo de negócio, evolui estratégia e adapta rapidamente a organização a capitalizar novas oportunidades.

2. Becoming a Lean-Agile Leader

Embrace the Lean-Agile Mindset. Os principais tópicos dessa parte:

SAFe Core Values: Alignment, Built-in Quality, Transparency e Program Execution.

SAFe House of Lean: Respect for people and culture, flow, innovation e Relentless improvement. Value and Leadership.

SAFe Lean-Agile Principles

#1 – Take an economic view
#2 – Apply systems thinking
#3 – Assume variability; preserve options
#4 – Build incrementally with fast, integrated learning cycles
#5 – Base milestones on objective evaluation of working systems
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7 – Apply cadence, synchronize with cross-domain planning
#8 – Unlock the intrinsic motivation of knowledge workers
#9 – Decentralize decision-making
#10 – Organize around value

Um destaque para o principio #10 – Organize around value que recomenda dedicar os esforços de desenvolvimento em torno do fluxo de valor de ponta a ponta. O dual operating system potencializa os benefícios da hierarquia existente, e também cria uma rede de fluxo de valor (as pessoas que precisam trabalhar juntas, alinhadas às necessidades da empresa e do cliente).

3. Establishing Team and Technical Agility

Estruturar times cross-functional, otimizados para comunicação e entrega de valor é o principal objetivo. A definição de roles e responsabilidades, Build quality in, e a organização dos ARTs (Agile Release Trains) acerca dos fluxos de valores são os principais itens dessa etapa.

4. Building Solutions with Agile Product Delivery

A abordagem customer centricity foca na experiência positiva ao cliente e por isso, apoia as empresas a entregarem soluções ou produtos com profundo entendimento das necessidades do cliente. As práticas de Design Thinking, criação de personas, mapa de empatia e journey maps são usados nesse contexto de melhorar a experiência do cliente.

Outra etapa é a criação do Program Backlog que endereça as necessidades dos usuários e entrega valor ao negócio através da implementação de Features (e user stories). A priorização utiliza critérios como ROI, CoD (Cost of Delay) e WSJF.

A PI (Program Increment) Planning é o principal evento do SAFe, baseado na cadência e que alinha todos ARTs (Agile Release Train) a uma missão e visão compartilhadas.

O Develop on cadence, release on demand é sobre criar eventos (nível do time e programa) para manter o ART on track, coordenando dependências e progresso entre os times. Release on demand é o processo de implementação de novas funcionalidades para os clientes com base na demanda. As práticas DevOps e o Continuous Delivery Pipeline habilitam o fluxo de valor para entregar e validar continuamente a necessidade dos usuários.

5. Exploring Lean Portfolio Management

O LPM (Lean Portfolio Management) provê três essenciais colaborações para realizar suas responsabilidades:

• Strategy & Investment Funding: assegurar que o portfólio e o budget  das soluções estejam alinhados com a estratégia organizacional.
• Agile Portfolio Operations: coordenar as value streams, apoiar a execução do programa e promover a excelência operacional. Atuação do LACE (Lean-Agile Center of Excellence), CoPs (Communities of Practices) e RTEs.
• Lean Governance: medir a performance do portfólio; ajustar o budget dinamicamente e aderência a compliance. Atuação do Enterprise Architect, Business Owners e APMO.

6. Leading the Change

Descreve como os líderes Lean-Agile conduzem e mantém a mudança organizacional e a excelência operacional ao capacitar indivíduos e equipes. Fazem isso liderando pelo exemplo (leading by example); aprendendo e modelando valores, princípios e práticas Lean-Agile; e liderando a mudança para uma nova forma de trabalhar.

• Leading by example: autenticidade, aprendizado contínuo, inteligência emocional, cultivando outros e descentralizando a tomada de decisão.
• Lead the change: estabelecer o senso de urgência, visão e estratégia, comunicar a visão, empoderamento de colaboradores, conquistas de curto prazo e ancorar novas abordagens na cultura organizacional. O SAFe Implementation Roadmap (mencionado anteriormente) traz as principais atividades para a implementação do SAFe.

Leitura recomendada

Se por um lado, as startups (modelo enxuto e pouca dependência com sistemas legados) tiveram muita facilidade em adotar um modelo experimental e empírico, muitas outras organizações ainda enfrentam dificuldades em alavancar a transformação ágil, em razão da estrutura atual, competências, sistemas fortemente acoplados, aplicabilidade, entre outros.

Enquanto o Lean Startup, Lean UX e Lean Enterprise propõem o modelo experimental, baseado em validação de hipóteses e MVPs para lidar em domínios de extrema incerteza, o modelo projetizado enfatiza o processo linear, documentações e o upfront planning. A tríplice restrição em projetos tradicionais é estruturada com o tempo e custo variáveis, já o escopo fixo (com alterações via change request).

Software projects are a popular way of funding and organizing software development. They organize work into temporary, build-only teams and are funded with specific benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams working on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their end-to-end cycle time, and allows validation of actual benefits by using short-cycle iterations while maintaining the architectural integrity of their software to preserve their long-term effectiveness.

https://martinfowler.com/articles/products-over-projects.html

As principais diferenças entre a estrutura projetizada e “produtizada”:

Não é o objetivo desse post discutir a melhor abordagem. O foco é compartilhar alguns drivers que ajudam a quebrar paradigmas na reestruturação organizacional (e viabilizar o trabalho as abordagens).

• Qual é a melhor estratégia para transformar uma organização projetizada em produtizada? É aplicável a minha empresa?
• É possível conviver com ambas na mesma organização?
• Qual seria a função do PMO e outros departamentos nesse contexto?

O Cynefin framework é muito utilizado para entender e distribuir os projetos e portfólios no domínio de acordo com a sua complexidade e evitar os problemas que surgem quando seu estilo de gerenciamento preferido os leva a cometer erros. A gestão e distribuição adequada é fundamental.

Ok. Agora você já distribuiu os projetos nos domínios adequados e viu que a sua organização pode precisar de mais de um modelo (ágil e phase gate) para gerenciar o portfólio organizacional da melhor forma. Se for aplicável o uso de métodos Ágeis em todos os projetos, mas ainda necessária a transição, saiba que ela não pode acontecer somente a nível de time. Priorize a entrega de valor! A gestão estratégica de portfólio é essencial para alcançar o Business Agility, alinhando a estratégia e execução, baseado no Lean e systems thinking.

Descubra quantos flight levels existem na sua organização. Muitas possuem três níveis – operacional, coordenação e estratégico. Traga o top management on board e comece pelo nível estratégico de portfólio com foco nos problemas que precisam ser resolvidos e time to market. O TTM precisa incluir a nível de projetos, e não somente nas tarefas dos times.

A gestão da dependência entre os times (e não do time) é essencial no fluxo do produto. Também a criação de value streams, que são as etapas necessárias para prover serviços ou produtos aos clientes. Evite a gestão em silo com os times, controlando somente suas atividades interna.

Para as organizações que não se aplicam a transição ágil total, os projetos podem ser estruturados conforme a distribuição citada anteriormente. Em cenários preditivos, o modelo tradicional (waterfall) será utilizado com planejamento detalhado na fase inicial e requisitos claros. O escopo é fixado e o time trabalha para cumprir as datas de entrega no prazo.

Mesmo com a fase de planejamento realizada no modelo tradicional (custo, escopo, tempo, riscos, etc.), nada impede o time de adotar práticas ágeis na fase de execução para obter alguns benefícios, conforme a figura abaixo. A simples adoção de Sprints e cerimônias ágeis já trariam mais visibilidade e redução de riscos na execução. Claro, que a maioria dos benefícios vem da cultura/mindset (being agile), e não apenas de práticas (doing agile).

Como ficam os times nesse contexto? Para atender projetos gerenciados em modelos diferentes. Muitas vezes, não há como capacitar ou modifcar a estrutura hierarquica de imediato, o que dificulta a execução, já que não terá times totalmente dedicados e estruturado para entrega contínua. Sem contar os demais benefícios que being Agile poderia trazer.

A adequação é o único caminho nesse caso. Ajustar a capacidade do time, as responsabilidades, as cerimônias, entre outros. Não deixe atribuições sem um responsável. Por exemplo, no Scrum, o Product Owner é o responsável pelo backlog e priorização. Na ausência desse papel, essa atribuição deve estar com alguém no time.

A cadência em múltiplos níveis é uma opção a ser utilizada, permitindo a execução (a nível de Squads) com práticas ágeis e a sincronização dos times no nível intermediário (Scaled). A camada executiva é voltada ao report do projeto em nível estratégico.

Muitas empresas ainda possuem o portfólio com mais de um modelo de gerenciamento e utilizam o PMO para ajudar a priorizar e dar visibilidade ao nível estratégico. O SAFe prescreve muita coisa boa a nível de portfólio. Também sugiro a leitura de livros e artigos sobre como o PMO se modificou em meio a transformação ágil.

Nesse cenário, a FBS (Feature Breakdown Structure) é um recurso que representa o produto (Epic – Feature – User Story) e facilita a comunicação com os times. Também apoia na prorização baseada em valor de negócio e acompanhamento do trabalho realizado vs valor produzido.

No status report executivo, uma página que consolide os resultados da Sprint, com os dados qualitativos e quantitativos, além dos riscos e melhorias discutidos na retrospectiva do time.

* sabemos que há muitos contrapontos em reportar story points como medição de performance do time. Trata-se de uma sugestão (mediante o contexto de maturidade do time).

Conclusão
Mesmo que a organização “produtizada” tenha características, propósito, fundamentação e aplicabilidade bem distintas da projetizada, vimos que a transição ágil não é algo trivial, e por isso, deve-se distribuir os projetos em domínios de complexidade e avaliar a melhor forma de gerenciá-los para obter êxito nas entregas de cada um.

Em cenários complexos, em que os problemas são difíceis de serem previstos, utilizamos métodos ágeis por ser fundamentado no empirismo, onde é realizada uma pequena quantidade de trabalho para adquirir experiência (iteração) e mudança rápida, se necessário. Em cenários preditivos, segue o conceito de Big Design Up Front (BDUF).

Quando há ambos, e não é feita a criação de uma Business Unit dedicada a inovação ou outros meios para gerar independência de recursos e formato de atuação, pode-se ainda utilizar as recomendações feitas nesse post.

Leitura recomendada