Elaboração de um Product Backlog Efetivo

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente  com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

  1. Como chegar ao Backlog?
  2. Como construir algo que tenha valor?
  3. Como encontrar a real necessidade do cliente?
  4. Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

Tem como objetivo vivenciar na prática a construção de um Backlog através do Product Backlog Building (PBB) um processo de construção do Product Backlog que utiliza o Backlog Canvas como ferramenta. Essa dinâmica leva todos envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog Efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais objetivos:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.
  5. Priorizar por alinhamento de expectativas e metas.
  6. Ter como resultado um Product Backlog totalmente alinhado com o valor de negócio do cliente.

PBB é representado por um canvas (Backlog Canvas) que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreenção e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Portfólio, Requisitos, Scrum

The Backlog Grooming Flow

Para as pessoas interessadas em entender melhor a prática de Backlog Grooming, segue uma espécie de BigPicture (estilo Visual Thinking)  sintetizando o funcionamento do conceito Grooming. Essa Big Picture sintetiza a aplicação da técnica para fazer o refinamento de Product Backlogs em times Scrum.

O post com o texto original (em inglês) está publicado aqui. Nesse texto você poderá entender melhor o funcionamento e os benefícios  da prática de Backlog Grooming para tornar os Backlogs mais Detalhados, Estimados, Emergentes e Priorizados. Em outras palavras, basicamente a intenção do Backlog Grooming é tornar os backlogs mais organizados e palatáveis para todo o ciclo de geração de valor do Scrum.

 

The Backlog Grooming Flow

Nenhum comentário »

Categorias deste post

Agile, Scrum

Posso mudar o tamanho de uma Sprint?

O Roberto Pereira, Product Owner, nos mandou a seguinte dúvida:

O timebox da Sprint pode variar no decorrer do projeto? Exemplo: Sprint1: 2 semanas, Sprint2: 3 semanas, Sprint3: 2 semanas e assim por diante…

Nossa Resposta

Caro Roberto,

Uma Sprint pode mudar de tamanho quando não iniciada, em alguns momentos isso é recomendável mas na maioria das vezes isso é danoso.

É interessante quando o time percebe que não consegue entregar incremento de software no tempo pré-determinado de uma Sprint. Desta maneira, o time aumenta o tamanho da próxima Sprint e segue assim por um bom tempo.

Todavia alterar o tamanho da Sprint possui como trade-offs a perda do referencial de timing e de velocidade de uma Sprint, e demorar mais para se adaptar as mudanças.

A perda de noção de timing de Sprint, ocorre quando o time perde a ideia de quando deve começar a fazer processos importantes dentro de uma Sprint, como quando deve implantar no ambiente de homologação master ou quando deve obter assinaturas que autorizam a subida em produção.

Já a perda de referencial de velocidade ocorre porque ao aumentar o tempo de Sprint em 1/3 não ocorre um aumento na produtividade de 1/3. Na prática a velocidade pode tanto aumentar como diminuir…

Ops, como assim diminuir?

A famosa síndrome de estudante pode atacar o seu time… Ou seja, o seu time pode operar como nos tempos de faculdade no qual deixava para fazer as atividades perto do prazo de entrega.

Aumentar o tamanho da Sprint também significa demorar mais para escutar o PO, e por consequência o software muda de maneira mais lenta. Isso pode ser mais danoso que os dois itens acima juntos.

Para finalizar, no coração do Scrum encontra-se o conceito de trabalhar com timebox… E o seu time deve aprender a trabalhar com uma timebox definida.

Se vocês acordarem que vai ter um incremento de software a cada duas semanas, todos vão ter que gastar massa cinzenta para conseguir este objetivo.

O time de desenvolvimento vai aprender a ser mais objetivo, o que envolve organizar melhor as tarefas, os processos, e a eliminar o desperdício com supérfluos técnicos.

O Product Owner vai aprender a granularidade correta das atividades para caber na Sprint. De início ele vai achar impossível quebrar as tarefas, mas depois de um tempo ele vai conseguir acertar a granularidade.

Não sei por qual motivo você quer mudar, mas agora que já sabe alguns trade-offs, você pode tomar uma decisão bem fundamentada.

Em caso de dúvidas sobre metodologias ágeis mande um sinal de fumaça ou envie sua dúvida por e-mail.

1 Comentário »

Categorias deste post

Adaptworks Responde, Product Owner, Scrum, Sprint, Timebox

SAFe – Dicas para um AgilePMO

Nesse vídeo, Manoel Pimentel compartilha sua experiência e visões acerca de AgilePMO. Esse vídeo de cerca de 17 minutos, foi gravado para uma breve participação especial no Learning Shot da HappyMelly Brazil realizado em outubro de 2014 e apoiado pela Adaptworks.

Nenhum comentário »

Categorias deste post

Agile, SAFe, Scrum

Um exemplo prático de SCRUM em uma Campanha de Marketing (Parte II)

Leia a Parte I aqui

Planeje, fracasse, itere…

Enfim, chegamos na Sprint1 e como já sabemos, o SCRUM permite que a equipe tenha um nível de interação muito alto, principalmente pela característica de autogerenciamento e é exatamente por isso que certas regras quando combinadas entre todos de forma antecipada, tornam o ambiente mais amigável e estimulam a disciplina e organização.

Para a campanha foram necessárias algumas definições importantes previamente combinadas com o time na reunião Sprint Planning.

Sprint Planning

Definition of Ready

Aqui descrevemos o que é importante estar pronto em relação aos itens do Product Backlog para que a Sprint seja iniciada:

Definições de pronto para iniciar: à construção da Landing Page finalizada; o e-mail que será enviado devidamente finalizado com as configurações prévias do software de disparo prontas; os anúncios do Google Adwords validados; assim como os Banners finalizados e toda a configuração do Google Adwords feita e pronta para inicio da Sprint.

Definition of Done

Aqui descrevemos o que é importante estar pronto após a execução da Sprint em relação aos itens do Product Backlog:

Definição de pronto após finalizada a Sprint: as Estatísticas de acesso do Google Adwords; do Google Analitycs; dos e-mails enviados; das ligações realizadas; das oportunidades abertas; dos registros de visitas e dos faturamentos. Ainda consta desta lista, a relação de e-mails sensibilizados que foram encaminhados para a pessoa de Telemarketing para ações de Follow-up.

Meta

A meta definida para a Sprint 1 foi baseada na quantidade de Contatos mapeados considerados efetivos (quando há um contato com chances reais de virar uma oportunidade), que no caso foi de 25 Contatos efetivos, no índice de CTR 1 do Google ADwords superior a 1% e no índice de e-mails clicados superior a 15% do total dos e-mails lidos.

1  O CTR é o número de cliques recebidos pelo anúncio dividido pelo número de vezes que ele é exibido.

Conforme o SCRUM há alguns cerimoniais que são utilizados como reuniões de feedback e que suportam o conceito de Inspeção e Adaptação, no caso:  Daily Meetings, Reviews e Retrospectives.

 Sprint 1

Basicamente o conceito de iniciar a Sprint da campanha foi:

– Disparar o Mail Marketing
– Ativar as Campanhas no Google Adwords (Pesquisa Orgânica e Rede de Display)
– Iniciar o trabalho de “cold call”

Há quem pergunte sobre o Sprint Backlog da campanha e a resposta é: “Os itens do Product Backlog estavam tão bem definidos que não tivemos problemas em utilizá-los na integra sem precisar decompô-los, até porque, essa seria uma tarefa bem difícil no nosso caso”.

Daily Meeting e Review

Uma vez que os dados foram gerados diariamente ao longo da Sprint, qualquer pessoa do time podia acompanhar o desempenho dos resultados, e encaramos isso como a nossa Daily Meeting, onde cada membro opinou sobre o andamento da campanha e sugeriu mudanças no decorrer do dia que foram implementadas ao longo da Sprint.

A partir da Daily Meeting muitas mudanças e ajustes foram realizados no Google ADwords.

Veja algumas importantes mudanças que ocorreram durante a Sprint 1:

– Rapidamente identificamos a necessidade de incrementar o valor unitário de cliques para algumas palavras chaves do Google ADwords com maior probabilidade de sucesso e revisão de outras com menos impressões entre outros ajustes em anúncios;

– Foram sugeridas novas possibilidades de mensagens do Mail Marketing e outras estratégias devido a baixa taxa de abertura;

– Foram apresentadas algumas dúvidas levantadas por clientes sobre produtos e soluções que acabaram por demandar um treinamento para a Analista de Telemarketing ministrado junto a nossa Parceira Oracle;

– E por último foi discutido possíveis ajustes no script de Prospecção para melhorar o discurso e a qualidade dos contatos efetivos.

Já a Review tratamos como o encontro realizado ao final da Sprint com o objetivo de apresentar os resultados, então foi apresentado um quadro resumo (com gráficos) com todos os números de desempenho e estatísticas de acesso e cliques realizados ao longo da Sprint.

Retrospective

As retrospectivas são as reuniões destinadas a entendimentos e esclarecimentos a respeito do processo de trabalho de uma Sprint, tendo como base o aprendizado necessário para a promoção das possíveis adaptações para as próximas Sprints.

Em nossa 1ª retrospectiva foram levantados alguns pontos de melhoria descritos baixo:

– Entendimento sobre o conceito de Oportunidade entre Prospecção e Vendas;

– Melhora no formato de apresentação do relatório de oportunidades e do quadro resumo;

– Detalhamento do fluxo de suporte da Oracle com relação às dúvidas técnicas levantadas nas atividades de prospecção;

– Solicitação de suporte do Google para aperfeiçoar algumas configurações do Google Adwords e esclarecer algumas dúvidas;

E tudo isso depois de apenas uma semana de campanha!

As metas foram parcialmente alcançadas:

Contatos Efetivos: 25 realizados
CTR: 0,08
E-mails clicados: 14,29%

Demais Sprints e Campanhas

As demais Sprints seguiram por mais três semanas e contribuíram positivamente para a melhora dos indicadores da campanha, forneceu subsídios valiosos sobre o comportamento dos clientes e reforçou a experiência e confiança do time em busca de resultados mais concretos.

Após duas Campanhas (Logística e Indústria), de acordo com os resultados gerados, conseguimos um aumento de 85% de incremento de novas Oportunidades e demos um importante passo no reforço da nossa marca junto ao mercado, especificamente para os dois segmentos abordados.

E depois…

Atualmente estamos trabalhando em nossa terceira campanha e o que eu posso registrar até o momento é que o SCRUM realmente nos trouxe uma perspectiva diferente de trabalho, totalmente baseada em um maior engajamento e colaboração do time, em prol de resultados mais satisfatórios para todos e para a empresa.

Também não posso deixar de considerar o aprendizado que todos nós tivemos em conjunto, embora não tenha trabalhado em todas as frentes, posso garantir que aprendi muito sobre várias atividades que se delegadas individualmente e gerenciadas de forma centralizada, não estariam tão expostas e suscetíveis as contribuições do grupo.

O efeito alcançado de melhoria contínua também foi notável, principalmente pelos erros e desencontros gerados pelas escolhas mal sucedidas, ou seja, quanto mais cedo você errar, mais perto de acertar nas próximas tentativas você estará, e com essa prática os resultados apareceram em questão de tempo.

Enfim, é preciso separar bem o Método ou Modelo de Trabalho de resultados positivos, é certo que o SCRUM não resolve tudo e nem é garantia de sucesso, porém através desse exercício empírico, se é que eu posso chamar assim, para minha empresa e para o meu grupo de trabalho ele funcionou adequadamente e trouxe resultados satisfatórios.

Agora só resta você testar também e lembre-se que para começar é preciso não se esquecer de Planejar, Fracassar e Iterar!

Boa sorte!

1 Comentário »

Categorias deste post

Agile, Gestão de Produtos, Mudança organizacional, Scrum

Um exemplo prático de SCRUM em uma Campanha de Marketing (Parte I)

Planeje, fracasse, itere…

Desde 2002 atuo na área de negócios com foco em vendas de soluções e serviços para tecnologia e agora nos últimos anos comecei a desbravar a área de marketing, foi então que resolvi colocar em prática algumas experiências adquiridas com o tempo.

Métodos Ágeis tem revolucionado a área de tecnologia, sobretudo área de desenvolvimento de software e mais recentemente a área de gestão.

E é exatamente com o foco mais em gestão do que em tecnologia que escrevo este artigo com o objetivo de apresentar de forma prática e direta o uso de uma Metodologia Ágil aplicada a Área de Marketing, onde a intenção aqui não é explicar o que é o SCRUM e sim demonstrar o seu uso no dia a dia de uma campanha de marketing recentemente lançada pela empresa.

A ideia partiu da necessidade de trabalharmos uma campanha para a venda de licenças Oracle que servisse de modelo para as demais campanhas de marketing da Unidade de Negócios responsável pela venda de produtos e soluções.

O desafio foi imenso, pois não sabíamos por onde começar, então tomamos por base iniciar pelo caminho mais lógico e óbvio, a Visão:

Vision – É melhor começar por aqui!

Antes de tudo, é muito importante sabermos para onde queremos ir ou onde queremos chegar.  Por isso, antes de iniciarmos os trabalhos efetivamente, conversamos com todo o grupo envolvido a respeito dos objetivos da campanha e o resultado dessa conversa foi a descrição abaixo sobre a Visão:

“Reforçar a presença da Unidade de Negócios junto ao mercado e clientes da empresa como fornecedores de soluções Oracle através de quatro campanhas para segmentos diferentes com duração de aproximadamente 1 mês cada uma e consequentemente incrementar em 80% o Pipeline de Oportunidades do time de vendas. “

Pre-game – Antes de iniciar o jogo.

Trabalhar com Métodos Ágeis exige muita disciplina e planejamento ao contrário do que se prega por aí, a diferença é que o planejamento realizado é pragmático e o feedback das ações e acontecimentos são rápidos, diferente da dinâmica utilizada em métodos tradicionais.  Sendo assim, foram definidos previamente a título de Pre-Game algumas premissas importantes e vitais para a campanha:

– Principais Canais a serem utilizados:
– Google Adwords;
– Mail Marketing disparado através de uma ferramenta específica;
– Ligações (Telemarketing Ativo) realizadas por um membro da equipe com experiência neste tipo de abordagem;
– Visitas e atendimento comercial realizado por um Vendedor especializado;

– Os papéis:
– Eu como Scrum Master;
– O Gerente de operações da Unidade de Negócios como o  Product Owner ;
– O time de execução: Vendedor,  Analista de Telemarketing e Analista de Marketing .

– Definição de uma meta por campanha expressa em quantidade de licenças por tipo de produto. Essa meta não é a mesma meta da Sprint sugerida pelo SCRUM que será comentada mais adiante, é apenas uma diretriz e definição de “norte” para a equipe de vendas;

– Como medição dos resultados, decidimos utilizar os Relatórios Gerenciais das ferramentas utilizadas (Google Adwords, Google Analitycs, e-Goi e Sistema de CRM);

– Embora a literatura do SCRUM sugira um tempo de Sprint entre 2 a 4 semanas como ideal, o tempo de duração utilizado nas Sprints foi de 1 semana, pois de acordo com o negócio em questão, foi considerado um tempo suficiente para a percepção das mudanças e geração de resultados.

Product Backlog – É hora de exercitar sua criatividade!

Após a etapa de Pre-game, montamos uma lista de itens com todas as informações que tínhamos disponíveis e que de alguma forma poderiam ajudar a formar a nossa lista final do Product Backlog:

– Informações bem detalhadas sobre os Produtos e Soluções ofertadas
– Cases de Sucesso sobre os segmentos que estávamos abordando
– Uma pesquisa simples sobre os segmentos desejados considerando alguns números de mercado e os principais desafios para Área de Tecnologia para o próximo ano para cada um deles
– Política de descontos dos nossos Distribuidores
– Base de e-mails exportada a partir do CRM

A partir dessas informações “idealizamos” o nosso próprio Product Backlog conforme os seguintes itens:

– Landing Page da campanha
– Banners publicitários
– Anúncios
– Script para Prospecção (Telemarketing Ativo)
– E-mail

A escolha de cada item acima foi decidida com base em “peças” que poderiam ser trabalhadas quanto à forma, estética e conteúdo e que também poderiam ser facilmente estressados ao longo das Sprints, considerando testes e medições. Em outras palavras, o conceito de Inspeção e Adaptação foi levado ao extremo, pois os resultados das medições ficaram disponíveis em tempo real o tempo todo e as alterações e mudanças foram realizadas ora balizadas pelos resultados até então atingidos, ora como testes que se provaram ou foram abandonados nas Sprints futuras.

Na Parte II deste texto você verá o que aconteceu na Sprint 1, não deixe de ler aqui!

2 Comentários »

Categorias deste post

Agile, Gestão de Produtos, Mudança organizacional, Scrum

SAFe – Uma visão inicial de como escalar Agile

Imagine uma pessoa solteira por opção, que acredita que é uma péssima decisão casar e ter filhos. Imagine essa pessoa tentando aconselhar as ações e decisões de um casal com 4 filhos e que está tendo todos aqueles desafios típicos de uma grande família. Nesse cenário é fácil visualizar o solteiro emanando críticas, que no fundo, vão na linha de “vocês estão errados! Vocês deveriam era ter adotado a filosofia de não de ter filhos! É melhor para a sociedade etc.”.

O que você acha de uma abordagem como essa? Você há de concordar comigo que é, no mínimo, nada produtiva uma eventual discussão entre o solteiro e esse casal.  Baseados nessa metáfora, vamos analisar uma situação do mundo corporativo.  Tomando como referência uma empresa grande (casal com vários filhos) e um  time de desenvolvimento de software (solteiro),   seria igualmente pouco produtivo tentar ajudar a empresa grande, apenas com as ferramentas voltadas ao dia-a-dia do time e/ou do desenvolvimento de um produto. O ponto central da incongruência não é que uma empresa é mais importante ou mais complexa que um time, mas sim, os problemas de ser ágil em uma empresa inteira, com vários times, com diferentes partes de produtos, são diferentes (não melhores) de ser ágil em apenas um time autossuficiente.

É com o reconhecimento de que precisamos de uma abordagem apropriada para os desafios de adotar ágil em larga escala, que o SAFe vem ganhando um considerável número de experimentações ao redor do mundo.

Mas afinal, o que é o SAFe?

SAFe é um acrônimo para Scaled Agile Framework. É um modelo criado por Dean Leffingwell e mantido e evoluído pela Scaled Agile Academy . O SAFe é baseado em Scrum, XP (Extreme Programming), Lean e muita experiência de campo,  para a implementação de práticas ágeis em grande escala. Ele reconhece o que tipicamente tem funcionado bem no trabalho de times ágeis, na forma de fazer gestão de programa e na maneira  ágil tratar um portfólio de demandas organizacionais.  O SAFe fornece um conjunto de práticas para ajudar grandes organizações a responderem perguntas do tipo:  Como rodar ágil em contextos envolvendo vários times? Como sincronizar o trabalho desses times? Como coordenar o resultado do trabalho de times distribuídos geograficamente?  Como priorizar demandas em produtos robustos e dinâmicos? Como escalar uma arquitetura ágil? Como tratar, de maneira ágil, os riscos de um projeto complicado? Como ser ágil e estar em conformidade com modelos de governança?

SAFeBigPicture 

Um modelo de transformação respeitando o jeito de ser das empresas

Uma das características mais fortes do SAFe, é que o mesmo reconhece o jeito de ser de uma organização.  Isso dentro de uma empresa de grande porte, significa que o SAFe introduz a filosofia ágil na cultura organizacional e ajuda a empresa a gerar resultados, sem bater de frente com a estrutura e papéis existentes ou até mesmo, com a cola social vigente na organização.  Então, do ponto de vista estratégico, por ser um modelo que respeita o jeito de ser e a cultura das organizações, o SAFe tem ajudado o movimento ágil a chegar em empresas e em esferas que nunca conseguimos chegar antes.

O que difere o SAFe das demais abordagens ágeis. 

Como falei anteriormente, o SAFe bebe da fonte do Scrum, adota o XP com abordagem padrão para o time e, é fortemente inspirado pelo pensamento Lean para uma abordagem mais enxuta do portfólio de produtos. Então muito mais do que diferenças, o SAFe tem coisas complementares à todas essas abordagens.

Mas claro que o SAFe não é apenas um mix dessa práticas/abordagens. O SAFe oferece em encadeamento lógico de como ligar a estratégia da empresa (alto nível) à um ciclo de desenvolvimento realmente ágil (e vice-e-versa). Lembra da diferença entre os problemas e soluções de um casal com filhos para os problemas e soluções de um solteiro? Então, o SAFe obviamente introduz uma série de atividades, regras e papéis diferentes ao da abordagem pura do Scrum ou XP.   Essas peculiaridades, estão distribuídas principalmente nos níveis de Programa e Portfólio.  Por exemplo, se olharmos para maneira como o SAFe faz a gestão de portfólio, veremos que temos papéis mais específicos para o trabalho nesse nível,  então além de um trabalho forte de Program Portfolio Management,  também há o papel de Epic Owners. De uma maneira resumida, entenda que um Epic Owner é o responsável por grandes assuntos de negócio dentro um determinado objetivo de negócio (tema de negócio).

Mas o SAFe tem várias outras peculiaridades,  que em breve, escreverei com mais detalhes.

SAFe e Scrum

Note que na “cebola” do SAFe organizada em Portfolio Level, Program Level e Team Level,  o último nível (Team Level) é baseado em Scrum. No nível de time, ele trabalha com tudo aquilo que estamos acostumados no Scrum, então elementos como auto-organização, empoderamento da micro-gestão e colaboração são partes essenciais para o funcionamento do SAFe. Assim como o Scrum é um framework para a gestão do trabalho de times em ambientes complexos, o SAFe também é um framework para ajudar na gestão  ágil de vários programas organizacionais, de forma a fornecer para a empresa, uma maneira enxuta (maximização de valor e eliminação de desperdício) de gerar resultados em todo o seu portfólio de produtos.

SAFeScrumAndXP

Orientado à produto

O SAFe, ao contrário do que pode se imaginar, eleva ao máximo o conceito de organizar o trabalho por um forte senso de geração de valor. Uma das provas disso, é que dentro do SAFe, a disciplina clássica de gestão  de projetos (aquele conceito com início, meio e fim) praticamente desaparece.  No lugar dessa disciplina, o SAFe introduz fortemente a disciplina de gestão de produtos. Isso representa um salto gigantesco na maturidade com o qual as empresas devem lidar com a gestão de portfólio de seus produtos.   Para o SAFe, a forma de organizar a execução dessas demandas de trabalho sobre os produtos, é através de um conceito chamado ART.

ART – O coração do SAFe.

Na verdade, espero produzir vários e vários pequenos posts explicando os principais detalhes do SAFe, mas no momento, vamos entender o elemento central de todo o funcionamento do SAFe.

Esse elemento, nos termos do SAFe chama-se ART. ART é um acrônimo para Agile Release Train. ART é a forma do SAFe organizar a entrega de um épico de negócio (grande assunto em nível de Portfólio) dentro de um conjunto cadenciado e sincronizado de várias ações envolvendo diferentes times.

Sem entrar (ainda) nos pormenores de como funciona o ART, vamos nos ater na metáfora principal dele: O trem (train, em inglês).

A metáfora vem da ideia de: Um trem parte de uma estação e chega na próxima estação com um confiável agendamento.  Nesse caso, em termos práticos, teremos uma cadência fixa, uma velocidade “normalizada” e releases previsíveis.

Para colocar em prática essa metáfora, é necessário uma abordagem específica para organizar pessoas e processos ao redor da construção do ART.

Pessoas, pois um ART pode ser trabalhado por vários e diferentes times (cada um com sua respectiva Sprint). Então, vamos precisar de novos papéis para suportar a integração técnica e processual desses diferentes times. Essa é missão de um RTE (Release Train Engineer) – Em breve escreverei sobre esse papel também.

Processos, pois para entregar o incremento de produto gerado por um trem, que tem vários times trabalhando nele, será preciso trabalhar com mais de uma Sprint com a mesma cadência de início de fim para todos os times. Além de claro de outros detalhes que em breve escrevei aqui no blog.

Apenas uma coceira no cérebro

Bom, a ideia desse breve texto, foi gerar apenas uma pequena coceira no seu cérebro sobre o SAFe. Por tratar de um assunto crítico para as organizações (Agile em larga escala),  SAFe é um assunto realmente vasto. Portanto, conto com  feedbacks vindos por comentários, e-mails, tweets para me ajudar a compor um norte dos próximos assuntos que escreverei sobre o mesmo.

Também aproveito para convida-lo, a fazer parte do grupo SAFeBrazil (grupo de discussões no facebook – http://www.facebook.com/groups/SAFeBrazil).  Lá poderemos trocar mais figurinhas sobre o assunto e até mesmo esclarecer mais alguns detalhes sobre o SAFe e sobre o assunto Agile em larga escala de maneira geral.

Mais referências:

scaledagileframework.com

1 Comentário »

Categorias deste post

Agile, Mudança organizacional, Portfólio, SAFe, Scrum

O Julgamento do Scrum – Agile Brazil 2013

Vídeo e slides da famosa palestra que Alexandre Magno fez no Agile Brazil 2013. Essa e outras palestras do evento já estão disponíveis em: http://vimeo.com/agilebrazil .

Vídeo

Slides utilizados na apresentação

Nenhum comentário »

Categorias deste post

Agile, Mudança organizacional, Scrum, Scrum Executivo

Planejamentos ágil e tradicional — Um é de marte, outro de vênus

agile vs tradicional planning

Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect.
Andy Hunt – signatário do Manifesto Ágil

Vira e mexe ouve-se a famigerada acusação de que no Agile não há planejamento.

Arrrrrg! Não é bem assim, isso é um mito. O que o Agile faz é dar mais ênfase no planejamento que no plano em si, mas vamos ver um pouco mais sobre as diferenças.

Um mundo de incertezas

Os dois tipos de planejamento são de mundos diferentes, mais ou menos como naquele livro “Homens são de marte, mulheres são de vênus”.

O Agile assume que estamos em um ambiente de grande incerteza e, portanto, tentar planejar previamente todo o projeto traria consigo um alto grau de especulação, já a abordagem tradicional acredita em um mundo linear com causas e efeitos muito claros e que assim, seria possível planejar com exatidão o projeto antes mesmo do início de sua execução.

Dessa forma, poderíamos dizer que “O Agile é do complexo e caótico, o tradicional do simples e complicado“.

O método cascata

O método cascata
Primeiro vamos tirar a confusão que existe entre gerência de projetos tradicional e método cascata: Apesar dos dois andarem costumeiramente de mãos dadas, o primeiro está mais relacionado com o PMBOK (Project Management Body of Knowledge)  e o segundo com uma forma recomendada pela engenharia de software tradicional.

Como na mentalidade tradicional existe a presunção de que todas as funcionalidades levantadas são indispensáveis e serão, portanto, implementadas, pouco importaria para o cliente a ordem como seriam implementadas. Dessa forma, opta-se por fazer o que parece, à primeira vista, a maneira mais inteligente e eficiente de se fazer software: por meio de etapas bem definidas, com grandes “entregas” de artefatos intermediários de uma fase para a outra.

Um dos problemas dessa abordagem é o tempo prolongado para se obter qualquer feedback, fazendo com que os problemas sejam descobertos tardiamente. Só para exemplificar, imagine que na fase de Análise um primeiro trabalho pode servir como base para completar todo o resto do trabalho antes de haver uma entrega para a próxima fase. Ao entregar o trabalho para a equipe que trabalhará na fase de Codificação, descobre-se que há um problema em todo o material entregue, devido a um problema que poderia, se houvesse um ciclo maior de feedback, ser descoberto mais cedo.

Como se não bastasse, um outro problema comum com essa abordagem é a propensão a gerar silos e pouca responsabilidade compartilhada da equipe pelo projeto. É comum nesse cenário se ouvir a “querida” frase “Fiz minha parte!”.

O planejamento tradicional

A primeira coisa que salta aos olhos no planejamento tradicional é o foco no plano, ou seja, uma vez estabelecido existe uma grande dificuldade em mudá-lo. A busca não é pelo valor para o cliente, e sim em entregar no prazo e no custo tudo que o cliente imaginou de antemão ser necessário para resolver seu problema.

Dado que vamos seguir um plano idealmente sem alterá-lo, e que todas as funcionalidades requisitadas pelo cliente precisam ser feitas, pouco importaria para o cliente a ordem em que serão desenvolvidas. Dessa forma, acaba-se dando enfoque em atividades. Você se lembra dos processos da fase de planejamento do PMBOK? Vou citar só alguns dos envolvidos com levantamento de escopo e definição do cronograma para exemplificar isso:

Coletar os requisitos;
Definir o escopo;
Criar a EAP (Para quem não sabe, EAP é a WBS, algum louco decidiu chamar de estrutura analítica de projeto);
Definir as atividades;
Sequenciar as atividades;
Estimar os recursos das atividades;
Estimar as durações das atividades;

Deu para perceber que o planejamento tradicional foca em atividades, não em funcionalidades? O problema é que normalmente não se produz valor para o cliente a cada atividade concluída, mas sim a cada funcionalidade entregue.

Ok, não é só isso, acontece que em geral as atividades não terminam antes do planejado, por algumas razões como a Lei de Parkinson (não, não é o mal de Parkinson), a Síndrome do estudante e uma extraordinária falta de incentivo para tal.

Lei de Parkinson: Diz que o trabalho ocupará o tempo disponível para ele.
Síndrome do estudante: Se houver um prazo para concluir algo, o aluno ou estudante (ou no caso o desenvolvedor) deixará para a última hora.
Falta de incentivo: Quando alguém termina cedo, costuma-se culpar essa pessoa por supostamente adicionar muito padding à estimativa ou, então, querer exigir que termine as demais atividades mais cedo também. Ou seja, em geral não há qualquer incentivo para o desenvolvedor dizer que terminou algo antes do prazo.

Outro ponto é que os atrasos são transferidos no encadeamento de atividades. A ideia de que um atraso se compensa, na média, com atividades entregues mais cedo quase nunca é verdade. Um dos motivos disso é que apenas uma combinação de resultados permite que uma atividade possa começar mais cedo, enquanto um único problema pode atrasar o começo de uma atividade. Aliás, há outro motivo para os atrasos não se compensarem na média, é que  as atividades não são eventos independentes.
Jogar uma moeda múltiplas vezes é uma atividade independente. Já no desenvolvimento de software as variações nos tempos de conclusão das atividades tendem a se repetir. Por exemplo, se criar um interface gráfica demorou mais que o estimado, há uma tendência de que outras atividades similares também levem mais tempo que o esperado.

O foco em atividades ainda leva a um outro problema: devido às atividades não serem desenvolvidas por prioridade, normalmente leva-se muito tempo para se ter algo em funcionamento e, mesmo assim, dificilmente serão as funcionalidades de maior valor para o negócio. Caso o dinheiro acabe antes do tempo ou seja preciso adiantar a data de lançamento do produto, não haverá algo muito útil para se entregar, nem tampouco é dada a oportunidade ao negócio para encerrar o projeto antes da hora se a maior parte do valor já foi entregue.

Esse último não está ligado às atividades, mas talvez seja o problema mais irritante em relação ao planejamento tradicional, as estimativas tornam-se compromissos. Estimativas são probabilidades; e compromissos não devem ser tomados sobre probabilidades. É quase como pedir para um meteorologista se comprometer com a previsão de um dia específico num futuro mais distante que um mês.

[youtube http://www.youtube.com/watch?v=RVjpVCwvnFg]

O planejamento ágil

Dada a premissa que estamos em um ambiente de incertezas (mundo da complexidade), todo ato de planejar e estimar é um ato de especulação. Isso não significa que o Agile entenda que estamos completamente no escuro, apenas que nossa visão é limitada e cada vez menos nítida conforme nos lançamos a “ver o futuro”.

Outro ponto de fundamental diferença é o foco, não mais no triângulo de ferro, escopo, prazo e custos, mas na entrega de valor. É óbvio, contudo, que prazo, escopo e custo não são desprezados, apenas deixam de ser o objetivo principal do projeto.

O que é diferente, afinal, no planejamento ágil?

Encoraja mudanças. Como o enfoque está na entrega de valor, é necessário aceitar e encorajar as mudanças caso entreguem mais valor que o planejado.

Um dos primeiros efeitos desse entendimento é que o foco passa a ser no plajenamento e não mais no plano. Isso facilita que o plano possa ser facilmente alterável.

Planejamento por funcionalidade e não por atividade. Como o Agile visa a entrega de valor, não importa a ordem pela qual as atividades são executadas, mas importa a ordem pela qual as funcionalidades são entregues, afinal, as que entregam mais valor deveriam ser priorizadas e entregues antes.

A incerteza é aceita como “parte do processo”.

O planejamento é iterativo. deve ser feito em níveis de Release, Sprint (Iteração timeboxed e incremental) e dia; evoluindo o plano de forma incremental. Em outras palavras, o planejamento é diluído pelo projeto, afinal, conforme o projeto progride, aprendemos mais sobre o projeto (o como) e sobre o produto (o que).

Estimativas não são compromissos, são estimativas.

Medida primária do progresso do projeto é software funcional (Entrega real). Consequentemente há uma contribuição maior para uma evolução apurada do planejamento.

Estabelece confiança. Entregas constantes de software funcional ajudam a estabeler a confiança entre o negócio e o desenvolvimento.

É importante saber em que mundo você está antes de escolher um tipo de planejamento, mas nunca perca de vista o foco na entrega de valor. É muito triste entregar um projeto no prazo, no escopo e no custo se no final das contas o projeto falhar no mais importante que é resolver o problema do seu cliente.

They had “achieve failure” — successfully, faithfully, and rigorously executing a plan that turned out to be utterly flawed.

Eric Ries, no Livro “Lean Startup”

Sobre o autor:

Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, Atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando como Scrum Master e agente de mudanças na Editora Abril. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é graduado em Direito pela Universidade Presbiteriana Mackenzie e aprovado pela OAB.  E também é instrutor associado na Adaptworks treinamentos, onde ministra o treinamento de EPC (Estimating, Planning and Contracting).
LinkedIn: @leonardocampos

2 Comentários »

Categorias deste post

Agile, Release, Scrum

Rally Live Webinar – Acelerar adoção de SCRUM e Gerenciar Equipes Ágeis na prática

rally1Na quarta-feira, 17 de julho, acontecerá mais uma edição do Rally Live Webinar.

O encontro virtual contará com a apresentação de Andreano Lanusse, da Rally Software, que mostrará ao vivo práticas que aceleram a implantação da metodologia ágil como SCRUM, XP e Kanban, além de possibilitar a visão e o status dos projetos em tempo real.

É a oportunidade ideal para esclarecer dúvidas e conhecer técnicas que aprimoram os métodos ágeis.

Podem participar do encontro:

• Aqueles que gerenciam equipes de desenvolvimento ágil.
• Aqueles que buscam mais visibilidade e gerenciamento de equipes distribuídas.
• Aqueles que buscam acelerar a adoção de SCRUM em sua equipe.
• Aqueles que buscam gerenciar portfólio de projetos baseados em equipes ágeis.
• Qualquer pessoa responsável pelo processo de transformação da empresa para ágil integrando práticas Ágeis e Lean.

Informações
Rally Live Webinar
Data: 17 de Julho de 2013
Horário: 11h00 (Horário de Brasília)
Inscrição: Clique aqui para fazer seu cadastro e participar

*Ao final haverá respostas de todas as perguntas ao vivo.

Nenhum comentário »

Categorias deste post

Agile, Parcerias, Scrum