Disciplined Agile Delivery (DAD) vs Scrum vs SAFe

Já abordamos o Disciplined Agile Delivery (DAD) em posts anteriores, e um resumo de como está estruturado – em três fases: Inception, Construção e Transição. Os aspectos de arquitetura e design (Inception) e DevOps (Transição) são alguns dos pontos interessantes do DAD.

Também fornece mais flexibilidade nas recomendações do projeto, através dos melhores processos para cada tipo de projeto (dependendo do que será construído), ao invés de prover um plano prescritivo. O DAD possui quatro modelos de ciclo de vida: agile/basic, lean/advanced, continuous delivery, and exploratory.

Outros frameworks muito conhecidos e utilizados em agilidade são: o Scrum para desenvolver, entregar e manter produtos complexos e o SAFe (Scaled Agile Framework), que sincroniza o alinhamento, a colaboração e a entrega para um grande número de equipes.

Papeis

O DAD atribui o Team Lead como responsável por manter o time focado no cumprimento dos objetivos, remoção de impedimentos e a expertise em processos ágeis. Também inclui o Architecture Owner para decisões e prioridades técnicas. Os papeis secundários geralmente ocorrem em necessidade de escala.

DAD

Papeis primários
• Team Lead
• Product Owner
• Architecture Owner
• Team Member
• Stakeholders

Papeis secundários
• Independent Testers
• Specialists
• Domain  Expert
• Technical Expert
• Integrator

 

 

 

SAFe

Time
• Product Owner
• Scrum Master
• Time de desenvolvimento

Programa
• Product Management
• Release Train Engineer
• System Architect

Large Solution
• Solution Management
• Solution Train Engineer
• Solution Architect

Portfolio
• Lean Portfolio Management
• Epic Owners
• Enterprise Architect

Scrum

Time Scrum
• Product Owner
• Scrum Master
• Time de desenvolvimento

 

 

 

 

 

 

 

 

 

Artefatos

Enquanto o Scrum possui artefatos direcionados ao time (backlog do produto e da sprint, burn down e incremento), o DAD e SAFe são mais abrangentes em relação a perspectiva do projeto.

DAD

• Business and Technology Roadmap
• Initial Requirements and Architectural Vision
• Iteration Backlog

 

 

 

 

SAFe

Portfolio
• Investment Themes
• Business and Architecture Epics
• Portfolio Backlog and Vision

Programa
• Product Roadmap
• Program Backlog
• Architecture Runway
• Business and Architecture Features

Time
• Team Backlog
• Team PSI Objective
• Sprint Goals

Scrum

• Product Backlog
• Sprint Backlog
• Gráfico Burn Down
• Incremento

 

 

 

 

 

 

 

Processos

Em processos, o Scrum também possui uma boa estrutura a nível de time, enquanto o DAD e SAFe são mais abrangentes, por considerarem custos, sincronização entre times e estratégia de priorização de projetos.

DAD

Inception
• Formação de time, visão comum, escopo inicial, estratégia técnica, de custos, riscos e release plan

Construction
• Desenvolver a Potentially Consumable Solution, endereçando necessidades dos stakeholders (e mudanças) considerando a qualidade e uso da arquitetura acordada

Transition   
Deploy e o uso da solução
• Melhorias nos processos, ambientes e infraestrutura

SAFe

Portfolio
• Temas estratégicos, épicos, portfólio e budget aos value streams

Large Solution
• Capabilities, Large Solution (Backlog e Kanban)
e Solution Planning / Demo

Programa
• Features, Program Backlog, WSJF, PI (Program Increment) – System Demos e Inspect and Adapt

Time
• User Stories, Team Backlog, Sprint Backlog e conduzir as Sprints

Scrum

•  User Stories, Sprint Backlog e Sprints (Planning, Daily, Review e Retro) e criação do incremento

 

 

 

 

 

 

 

Por fim, vimos acima uma breve explicação e comparação entre DAD, SAFe e Scrum, que podemos resumir da seguinte forma:

  • DAD: é híbrido entre os métodos existentes e fornece flexibilidade para usar várias abordagens. Considera aspectos de iniciação e implementação (full delivery lifecycle). É people-first, learning-oriented e Hybrid agile.
  • SAFe: é mais prescritivo e fornece uma estrutura em diferentes níveis (time, programa e portfólio) que pode facilitar a transição para uma estrutura ágil, além de ser aplicável a um grande número de times (ágil em larga escala).
  • Scrum: aplicável a times individuais, usado para gerenciar o trabalho em produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras.

DevOps, Ikigai, Gamificação e F4P – despertando o propósito no CI/CD

O acordo do time é essencial para alavancar as entregas contínuas orientadas a valor. Como orquestrar então “processos – pessoas – ferramentas” neste contexto? Utilizando conceitos do Ikigai, Gamificação e Fit For Purpose (F4P), este trabalho demonstra como equilibrar o compromisso das entregas com o que gostamos de fazer. Também compartilha os resultados obtidos com a transformação cultural, envolvendo as boas práticas de desenvolvimento, o comprometimento com CI/CD e a gestão ágil.

Link de acesso do material: Agile Trends 2019 – Leonardo Matsumota.

  • Ikigai: contextualização da filosofia e correlação entre o ser humano e seu trabalho, em busca do propósito entre paixão, missão, profissão e vocação.
  • F4P: utilização do F4P Card (adaptado), Fitness Box Score e Matriz (aderência x identidade) para identificar a satisfação dos colaboradores com a empresa.
  • Hard Skill Canvas: traz alinhamento, transparência e melhoria contínua ao time, conhecendo as competências técnicas que o time precisa para os produtos da organização.
  • Engajando CI/CD: senso de pertencimento, cadência e gestão.
  • Gamificação: ampliando as boas práticas com senso de colaboração e conhecimento.
  • Formato de trabalho: Squads, OKRs e camadas de engajamento.

 

SAFe 5.0 – uma prévia do novo Scaled Agile

Com o ritmo acelerado das mudanças nos negócios, as organizações precisam ajustar seus modelos atuais de negócio, habilitando a inovação tecnológica e a entrega contínua de valor aos clientes. Devido à forte concorrência no mercado, os usuários estão cada vez mais exigentes, encontrando várias opções de produtos e ferramentas que auxiliam na hora da compra. As empresas precisam compreender melhor seus pensamentos e atitudes, conectando-se a seus valores.

Se antes, as organizações eram estruturadas com modelos de trabalho a longo prazo, na atualidade, o objetivo é tornar a organização mais flexível a mudanças (capacidade de adaptação rápida) com base na entrega contínua de valor, cultura, pessoas e modelo operacional. Tudo isso resume o conceito do Business Agility.

Na semana de 29/Set à 04/Out aconteceu o Global SAFe Summit 2019, onde foi apresentada a nova versão do SAFe (Scaled Agile Framework), o framework SAFe 5.0. Esta nova versão conecta o propósito do Business Agility, propagando práticas de Lean e Agile a toda organização para habilitar a entrega contínua de valor (citada anteriormente) com produtos e serviços inovadores.

E como ficou o SAFe 5.0? Ele foi estruturado com base em sete competências da Lean Enterprise, consideradas essenciais para implementação do SAFe. Cada competência é formada pelo conjunto de habilidade, conhecimento relacionado e comportamentos que habilitam as empresas no Business Agility. Em resumo, as competências ficaram seguinte forma:

Cinco competências
Introduzidas desde o SAFe 4.6, permanecem, mas com ajustes importantes. São elas:

  • Lean-Agile Leadership: possui foco na mudança organizacional, descrevendo como os líderes conduzem e capacitam indivíduos/equipes a maior produtividade e inovação.
  • Team and Technical Agility: o que as equipes precisam para criar soluções de alta qualidade? Esta competência descreve as habilidades e os princípios e práticas Lean-Agile para obter aumento da produtividade e qualidade.
  • Agile Product Delivery: abordagem centrada no cliente para criar produtos ou serviços de valor.
  • Enterprise Solution Delivery: descreve como aplicar os princípios e práticas Lean-Agile ao processo de desenvolvimento de software.
  • Lean Portfolio Management: visa o alinhamento da estratégia com a execução, aplicando conceitos de Lean e Systems Thinking aos investimentos da empresa.

Duas competências (adicionais)

  • Organizational Agility: descreve como os times otimizam seus processos de negócio (também utilizando Lean Thinking) e estruturam rápida adaptação a mudanças para aproveitar novas oportunidades.
  • Continuous Learning Culture: a promoção da cultura de aprendizado, descrevendo valores e práticas que incentivam os colaboradores a buscar continuamente novos conhecimentos e competências para contribuir com a inovação organizacional.

Outras mudanças

A estrutura anterior (SAFe 4.6) possuía o nível Program Level (coordenação das ARTs – Agile Release Train) e o nível Team (times multifuncionais que construíam e entregavam valor na ART) que foi unificado em um único nível Essential no SAFE 5.0. O nível Essential contém o conjunto mínimo de papeis, eventos e artefatos (agora com o time de negócios fazendo parte do trem) necessários para fornecer soluções de negócios continuamente através das ARTs. Utiliza três competências principais: Team and Technical Agility, Agile Product Delivery eLean-Agile Leadership.

Também adicionado um novo princípio #10 Organize around value que representa a vantagem competitiva na qual a organização pode responder as necessidades dos clientes e soluções inovadoras. Isso exige alta colaboração entre as áreas afim de gerenciar desperdícios, atrasos, dependências e handoffs.

Técnicas de estimativas ágeis

Neste post, vamos abordar técnicas de estimativas ágeis, conceitos de planejamento adaptativo e recomendações de uso, baseado nas fases do ciclo de vida de gestão de projeto ágil. Também como prover visibilidade do projeto em múltiplos níveis da empresa.

O planejamento adaptativo, utilizado na gestão ágil, adota um processo contínuo (realizado ao longo do projeto) que oferece mecanismos de atualizações frequentes. Esta flexibilidade permite reduzir os riscos, entregar valor de negócio antecipadamente e maior visibilidade.

waterfall-agil-01

Na iniciação do projeto, as estimativas são feitas em alto nível para apoiar as análises de investimento. E são refinadas continuamente durante todo o projeto. As técnicas de estimativas são colaborativas, e assim, todas as pessoas apropriadas devem ser incluídas no processo.

A maioria das técnicas utilizam unidades relativas, por exemplo o uso de pontos facilita a comparação entre os itens que estão sendo estimados (ao invés de estimar em “dias” diretamente), evitando “prever o futuro”, onde algumas leituras sinalizam que é uma dificuldade do ser humano.

T-Shirt Sizes

Abordagem de estimativa em alto nível para backlog grande com muitos itens a serem avaliados. Os itens são estimados em PP, P, M, G e GG, de acordo com as discussões e decisão comum/colaborativa das equipes. É uma forma rápida de ter uma ideia do tamanho total do backlog.


Planning Poker

Recomendado para estimar user stories (ou das tarefas) em quantidade relativamente pequena de itens (até 10). Os participantes, em geral, realizam votações utilizando a Sequência de Fibonacci. Quando há grande divergência nas pontuações, a votação é repetida até o time obter um consenso sobre a precisão da estimativa. A boa prática é trabalhar com até 13 pontos.


Affinity Mapping

É uma técnica que envolve agrupar os itens em categorias ou coleções similares. Utilizada para garantir que as unidades de story points se mantêm consistentes ao logo de todo o projeto.

A forma de triangulação oferece uma visão comparativa das estimativas e permite verificação. Pode ser uma alternativa quando há um grande número de histórias a serem estimadas, acelerando o processo de estimativas consideravelmente.

Manifesto Ágil: valores e princípios

A História

O Manifesto Ágil foi escrito em 2001 por 17 profissionais de software que já praticavam Scum, Extreme Programming, Crystal Clear e outros frameworks. Embora os participantes não tenham concordado com frequência, encontraram um consenso em torno de quatro valores principais.


Os Autores

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
Robert C. Martin
Steve Mellor
Dave Thomas
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Ken Schwaber
Jeff Sutherland


Valores do Manifesto Ágil

“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:”

https://www.manifestoagil.com.br/
  1. Indivíduos e interações mais que processos e ferramentas
  2. Software em funcionamento mais que documentação abrangente
  3. Colaboração com o cliente mais que negociação de contratos
  4. Responder a mudanças mais que seguir um plano


Os 12 princípios do Manifesto Ágil

Nós seguimos os seguintes princípios:

  • Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
  • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
  • Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.
  • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
  • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  • Software funcional é a medida primária de progresso.
  • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  • Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
  • As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
  • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Link: http://agilemanifesto.org/

Assessment Ágil – Avaliação de maturidade

Com a disseminação das práticas ágeis nas organizações, vieram também ajustes nos frameworks, novas discussões e conceitos da aplicabilidade. Alguns marcos importantes desta linha do tempo:

  • 2000/2001 Agilidade nos times de TI: uso de práticas ágeis no departamento de TI.
  • 2010/2011 Escala ágil além da TI: outros departamentos também utilizam agilidade.
  • 2015/2016 Business Agility – Enterprise: capacidade da organização responder rapidamente às mudanças do mercado, orientada a valor.
  • 2018/2019 Digital Decoupling: trabalha com elementos de valor de forma desacoplada (não mais produtizado).

E assim, as empresas precisam conhecer e monitorar estas práticas continuamente para maximizar seus benefícios. Vale mencionar que being agile x doing agile não deve ser uma meta em si. Medir o rigor de uso dos princípios ágeis também não é o ponto. Avalie a equipe em relação aos princípios ágeis que fazem sentido como propósito para obtenção do sucesso.

Claro que a aplicação dos modelos de maturidade exige alguns cuidados, por simplificarem demais algumas áreas complexas e não lineares. Por exemplo, consideram o crescimento como uma progressão linear, marcado por fases e características únicas. Também a impressão de que o que ficou a direita da maturidade é “bom”, enquanto a esquerda é considerada “ruim”.

Alguns modelos de assessment amplamente utilizados no mercado para avaliar a maturidade ágil dos times são:

1. Agile Assessment tool – Agile Maturity Model (AMM)

Umas das primeiras ferramentas de avaliação ágil, muito direcionada a maturidade na adoção de valores, princípios e práticas ágeis. Os atributos de cada nível buscam ser claramente definidos e o mais discricionários possível, concentrando na capacidade de alterar práticas (não avalia o progresso da mudança de cultura)

Agile Maturity Model 

Com a adição da ferramenta Agile Health Radar, as equipes incluíram a visão da cultura em relação às suas próprias iniciativas e ao portfólio.

Agile Health Radar

2 – Agile Maturity Curve

Neste modelo, há a adição de três áreas que ajudam a habilitar a gestão ágil nos times: arquitetura, release planning e governança. No “one size fits all” – a implementação bem sucedida de frameworks pode exigir ajustes de acordo com as camadas e necessidades do negócio.

Agile Maturity Curve
Agile Maturity Curve

3 – Maturity Model

Propõe cinco categorias para a organização atingir o Agile Maturity, com objetivos claros e específicos para cada uma. O primeiro desenho representa o guia para implementação do modelo, seguido do exemplo dos cinco níveis (Level 1 – Level 5) de maturidade da liderança (leadership).

Agile Maturity Categories
Maturity Model Guide
Agile Maturity Example
Maturity Model Guide Example

4 – The Agile Principles Checklist

Avalia a maturidade ágil da equipe em relação aos 12 princípios do Manifesto Ágil. A ferramenta surgiu com base no livro Scrum Mastery (de Geoff Watt), devido a simplicidade da abordagem de uma equipe se mapeando com os 12 princípios ágeis.

How Agile is my Team
The 12 Agile Principles

5 – Agile Maturity Assessment

Baseado principalmente no Scrum e priorização da pontuação da avaliação MoSCoW. Ajuda a fornecer a visão as is e to be de agilidade.

Agile Maturity Assessment

6 – Roda Ágil

Dinâmica de avaliação da maturidade ágil com pontuação de 1 a 5 para cada item, baseado nos quatro valores do Modern Agile (pessoas sensacionais, valor a todo instante, segurança um pré-requisito, experimente e aprenda rápido).

Roda Ágil

Modern Agile

Nos últimos anos, em meio a adoção de métodos ágeis nas organizações, além da conhecida notoriedade e benefícios obtidos (time to market, adaptação as mudanças, previsibilidade, colaboração, etc.), também está presente em muitas discussões os ajustes ou aspectos em que o manifesto ágil, criado em 2001, não aborda em sua plenitude.

Alguns valores e princípios ágeis devem então ser atualizados? O princípio ‘Working software is the primary measure of progress’, por exemplo, não menciona o valor entregue com o software em funcionamento. O que muitas vezes pode direcionar o time a entrega de software “pronto” ao invés do resultado desejado.

Além do Google, Amazon, Etsy e AirBnB, outras empresas já consideram utilizar o Modern Agile? O criador do Modern Agile sugere que sim, por ser muito leve e muito mais amplo que o Manifesto Ágil. Eis a definição:

Modern Agile is ultra-light, the opposite of mainstream Agile, which is drowning in a bloated tangle of enterprise tools, scaling frameworks and questionable certificates that yield more bureaucracy than results.

Joshua Kerievsk

O Modern Agile não prescreve papeis, responsabilidades ou práticas específicas. É definido por quatro princípios orientadores:

  • Torne pessoas sensacionais
  • Faça da segurança um pré-requisito
  • Experimente e aprenda rápido
  • Entregue valor a todo instante

E como ficam estes princípios se compararmos com o Manifesto Ágil:

Torne pessoas sensacionais

Não é uma prescrição de como tornar as pessoas sensacionais, e sim levar isso como objetivo. Kathy Sierra traz ótimos insights no livro Badass: Making Users Awesome, como por exemplo, descobrir o que está impedindo nossos usuários a fazerem mudanças essenciais para ajudá-los a obter resultados impressionantes.

A Modern Agile sugere a dedicação de esforço para tornar todos em nosso ecossistema impressionantes – equipe, clientes, fornecedores, entre outros. Claro que não é uma tarefa fácil, e por isso exige esforços para inovações disruptivas ou Big Hairy Audacious Goals.

Faça da segurança um pré-requisito

A segurança vem como princípio fundamental para tornar as pessoas sensacionais, criando ambientes propícios aprendizado contínuo e tolerância a falhas. Seth Godin dizia que “as pessoas não tem medo do fracasso, elas tem medo da culpa”. A culpa traz negatividade e não ajuda ninguém.

Por isso que em um famoso caso da Google, onde o engenheiro do time Adwords assumiu o erro em um serviço que custou U$ 1 M da receita, não houve demissão, e sim aprendizado sobre o causa do problema, reforçando a cultura aprendizagem contínua. Sim, a colaboração é essencial.

Experimente e aprenda rápido

E certamente não há pessoas sensacionais ou ambientes seguros como pré-requisito se não houver aprendizado. Nós aprendemos rápido fazendo experimentações contínuas, e isso, deve ser “seguro a falhas”, já que validação de hipóteses exige tempo de verificação e alguns descartes no que não faz mais sentido.

Este item é vital para diferenciá-lo dos concorrentes, experimentando com frequência e aprendendo com tudo isso para entregar valor aos usuários, que pode deixá-los sensacionais.

Entregue valor a todo instante

Trata-se de entregar valor ao usuário continuamente de forma rápida. Verifique seu processo interno e como ele habilita a entrega de valor rapidamente ao mercado. Em caso de desenvolvimento de aplicações, mantenha o software em working state o tempo todo.

Orientação a valor é bem diferente de número de itens entregues. Então, veja o que está sendo criado em termos de valor e não em % de entrega.