Lean Change Management vem aí…

lean change managementNos dias 04 e 05 de Maio de 2017, nosso Chief Learning Officer Roberto Baptista teve o prazer de participar do treinamento Lean Change Management (LCM) em Washington, DC. Nosso conterrâneo João Gama foi quem conduziu a turma, um facilitador nato, transpira agilidade na essência. Foi interessante notar que todos os participantes (assim como o Roberto) eram SAFe Program Consultants (SPCs) ativos no mercado.

O treinamento Lean Change Management foi criado por Jason Little (autor do livro Lean Change Management) e tem como base ideias de Lean Startup, Agile, Change Management (Kotter 8-steps, ADKAR) e Organizational Development.

MVC/MVT (Minimum Viable Change ou Transformation) é apenas uma das contribuições fantásticas dessa fusão. As práticas do Lean Change Management realmente podem contribuir e facilitar muito uma transformação ágil (que é uma mudança enorme), tanto para agile teams quanto agile release trains, PPM´s, etc.

Após compartilhar essa experiência com os outros Adaptworkers, entendemos que tanto para Agile Coaches quanto outros perfis que estão participando de transformações ágeis em grandes organizações, as práticas do Lean Change Management são indispensáveis. E como não poderia ser diferente, a Adaptworks reforçando seu pioneirismo no país, inovou com mais este tema em seu portfólio.

Aproveite esta chance para participar da primeira turma de Lean Change Management Certified Agent no Brasil. Conheça mais e inscreva-se!

Nenhum comentário »

Categorias deste post

Certificação, Coaching, Facilitação, Lean, Mudança organizacional

Maior Escalabilidade de Agile com o SAFe 4.0

Hoje foi liberado pela Scaled Agile Academy a versão 4.0 do SAFe (Scaled Agile Framework).  O SAFe é um framework que vem evoluindo desde 2011 e nos últimos anos, tem se tornado uma importante referência para apoiar grandes organizações no processo de adoção de métodos ágeis em larga escala.
Essa versão 4.0, assim como suas antecessoras, é fruto da observação de como que as grandes organizações estavam endereçando algumas questões específicas do desafio de escalar métodos ágeis. De maneira geral, a versão 4.0 é baseada numa abordagem muito mais escalável do que as versões anteriores, como é de se esperar. Isso se deve ao fato de que tem sido muito frequente a adoção de SAFe em ambientes de larguíssima escala que rodam vários ARTs (Agile Release Train) de forma simultânea e integrada.  Por esse tipo de contexto, se fez necessário incorporar algumas importantes mudanças do framework.
SAFe40-BigPicture
(Clique para ver imagem em tamanho grande)
Dentre as várias mudanças, destaca-se aqui as  mais significativas:
  1. Adição do Value Stream Level –  Este novo nível enfatiza  o conceito de Value Stream, que já estava presente nas versões anteriores mas, que era pouco explorado/detalhado na BigPicture. Dessa forma, a versão expandida da BigPicture passa a contar com 4 níveis (Portfolio, Value Stream, Program e Team). Este novo nível se faz importante para organizações que estejam adotando Agile em cenários de alta escala (vários ARTs, adoções envolvendo milhares de pessoas, diferentes produtos, diferentes linhas de negócios etc). Vale reforçar que esse novo nível é opcional. Para muitos casos, a estrutura baseada em Portfolio, Program e Team será suficiente.
  2. Nesta nova versão existe a possibilidade de usar os sistemas Kanbans em todos os 4 níveis.  Nas versões anteriores, Kanban oficialmente constava apenas para apoiar a gestão de Portfólio. Mas na versão 4.0, é possível gerenciar o fluxo de trabalho usando Kanban nos 4 níveis (Portfolio, Value Stream, Program e Team).
  3. Spanning Palete – Alguns artefatos e papéis que já constavam nas versões anteriores, agora, (oficialmente) compõem um tipo de repositório de ferramentas opcionais, que podem ser usadas (ou não) em diferentes níveis e em diferentes formas.  Isso amplia as possibilidades de customização do framework.
  4. E por final, uma das mudanças que mais se destacou positivamente: o conceito de Community of Practices (Comunidade de Práticas) que agora foi incorporado oficialmente à BigPicture. Para quem não conhece esse conceito, vale a pena destacar que, trata-se de um grupo informal composto por representantes de diferentes times, que tem como principal objetivo, trocar figurinhas sobre problemas e soluções acerca de um assunto específico.
Tive a honra de acompanhar de perto o processo de discussão e validação da aplicabilidade das mudanças do framework. Por essa razão, vejo de uma forma extremamente positiva toda a forma como framework tem evoluindo buscando aumentar ainda mais a sua congruência com a realidade de grandes organizações.
Para entender mais sobre as mudanças, leia esse post que explica mais detalhes sobre melhorias desta nova versão.
Nenhum comentário »

Categorias deste post

Kanban, Mudança organizacional, SAFe

As 2 lições que eu te ensinaria sobre Liderança – Parte 1

Calma, não tenho pretensão nenhuma de ser um grande exemplo de líder, referência no estudo ou sequer trazer uma definição completa do tema. O título foi motivado pela pergunta do meu coach: “Willi, o que você ensinaria sobre liderança a alguém?”

Depois de umas 2 semanas matutando, o resultado foi dois posts sobre o tema. Aqui vai o primeiro:

 

Parte 1 – Liderança é overrated

image01

 

Há um tempo atrás, liderança era a grande característica mágica que os profissionais deveriam buscar para serem contratados e evoluírem em suas carreiras. O termo foi tão usado e acabou tão banalizado, que você precisava ter liderança até para trabalhar sozinho. Talvez estivessem procurando por iniciativa na verdade mas, convenhamos, falar liderança é bem mais legal.

O fato é que liderança por si só não é uma qualidade assim tãaao exclusiva. A palavra vem de antigos condutores de grupos a pé por trilhas sinuosas e perigosas, e eram “responsáveis por todos e por cada um”. [CBN Max Gehringer] Ou seja, eram os que conheciam melhor os caminhos e as pessoas, capazes de orientar o passo conforme as condições particulares de tempo, terreno e das pessoas em direção ao destino desejado (muito Lean, Kanban e Teoria das Restrições na veia!).

Então o líder é esse que conduz um grupo em direção a um objetivo, de acordo com as características dos indivíduos desse grupo. Mas o que é preciso pra ser esse líder?

O que a gente lê por aí é que o líder é alguém que sabe inspirar/motivar, é íntegro/honesto, orientado a resultados, resolve problemas, se comunica bem, colabora e promove ‘teamwork’, tem iniciativa, ambição, energia, autoconfiança, conhecimento, iniciativa, vontade de liderar entre outras características [Post HBR] [Post Cultura Colaborativa].

Você acha que tem várias dessas habilidades? Muita gente acha que tem, e muitos têm mesmo! Mas nem todos são líderes. E mais, você provavelmente conhece quem não tenha essas habilidades mas tenha uma “posição de liderança”. Por que?

Uma empresa fez uma experiência: levou 5 pessoas escolhidas ao acaso para uma canoa num rio, deu a todos um remo e os largou. Depois de uma confusão inicial (Lembra de Forming, Storming, Norming, Performing? [Wikipedia Tuckman]), um dos integrantes começou a coordenar e direcionar os demais em direção à outra margem. Este se tornou o líder.

Depois o experimento continuou. A empresa retirou este líder do barco, voltou o barco ao ponto de partida e o soltou novamente com as 4 pessoas restantes.

Novamente um dos 4 assumiu a liderança e conduziu o barco ao destino. [CBN Max Gehringer]

Moral da história: a posição de liderança nunca fica vaga.

Outra moral: qualquer um tem potencial pra se tornar líder, a diferença entre o líder e o liderado é a velocidade com que um aproveita a oportunidade.

Talvez eles já estivessem arranhando outro entendimento de liderança, pertencente a ambientes complexos adaptativos, que descrevemos hoje como liderança situacional, em que cada um exerce liderança no momento e no contexto em que tem maior competência para liderar. Por exemplo, o desenvolvedor mais experiente ou mais respeitado pelo resto da equipe é o líder quando o assunto é desenvolvimento. Já quando se tratar de uma negociação com o cliente, talvez seja o momento do gerente ou vendedor assumir a liderança. Não há só um líder o tempo todo para todo tipo de situação. Na verdade, nesses tipos de ambientes (ou sistemas), estamos líderes, ao invés de sermos líderes. 

E é por isso que disse que liderança é supervalorizada (ou overrated – que é mais marqueteiro).

image00

As qualidades e habilidades que são citadas para o líder são desejáveis para qualquer bom profissional, e qualquer um em um momento pode “estar” líder. Basta aproveitar a oportunidade primeiro. No fundo, desejamos trabalhar com grandes pessoas.

Mas isso não é suficiente, certo? E sobre o líder formar um “time de alta performance”? Como liderar melhor quando estiver líder? Isso eu continuo no próximo post.

Enquanto isso, deixe aí suas opiniões nos comentários, ou me contate no Twitter, Facebook ou LinkedIn para continuarmos a conversa!

Grande abraço!

Willi 

PS: Acabei achando esse post depois de escrever o meu.
Fica de bônus: http://customerthink.com/why_your_leadership_is_overrated/

 

 

 

1 Comentário »

Categorias deste post

Coaching, Management 3.0, Mudança organizacional

Management 3.0 em 20 minutos!

No TDC São Paulo 2014, André Faria e Manoel Pimentel nos contaram, em uma palestra de 20 minutos, o que é o Management 3.0.

Confiram a palestra publicado no SlideShare

Deixem seus comentários, participem do nosso blog!

Nenhum comentário »

Categorias deste post

Agile, Eventos, Management 3.0, Mudança organizacional

Por que Kanban? – com Rodrigo Yoshima – Parte III

Por que Kanban?

Acompanhe mais um episódio da série “Por que Kanban?” com Simone Pittner e Rodrigo Yoshima.
O tema dessa semana é Princípios e Práticas do Kanban.
Como inserir o Kanban no seu dia a dia e adaptar-se a novas práticas para otimizar o seu fluxo de trabalho?
Descubra nesse novo episódio do #Videocast Adaptworks.

Obrigada por estar nos acompanhando, e na próxima semana mais #VideoCast, confiram!

Inscreva-se no treinamento “Kanban”: http://www.adaptworks.com.br/TreinamentoDetalhes/kanban/

Conheça os outros treinamentos da Adaptworks: http://www.adaptworks.com.br/Treinamentos/.

Nenhum comentário »

Categorias deste post

Agile, Kanban, Mudança organizacional, Videocasts

Por que Kanban? – com Rodrigo Yoshima – Parte II

Por que Kanban? – Parte II

No segundo episódio da série “Por que Kanban”, Simone Pittner e Rodrigo Yoshima conversam sobre Visualização e Limites.
Como gerenciar o fluxo e combater as filas de trabalho? Saiba um pouco mais neste episódio.

Obrigada por estar nos acompanhando, e na próxima semana mais um #VideoCast, confiram!

Inscreva-se no treinamento “Kanban”: http://www.adaptworks.com.br/TreinamentoDetalhes/kanban/

Conheça os outros treinamentos da Adaptworks: http://www.adaptworks.com.br/Treinamentos/.

Nenhum comentário »

Categorias deste post

Agile, Kanban, Mudança organizacional, Videocasts

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

Videocast Adaptworks #2: Niels Pflaeging – Organizar para a Complexidade

Durante a última turma do curso Organizar para a Complexidade (Beyond Budgeting) realizada pela Adaptworks, fizemos mais uma edição de nosso VideoCast. Nesse vídeo, conversamos com o Niels Pflaeging (autor do treinamento e referencia mundial no assunto) sobre cultura organizacional, processos, hierarquias, modelos de gestão, higienização de ideias e práticas antigas, liderança, motivação e outros detalhes inerentes às novas formas de pensar e organizar empresas. O conteúdo ficou realmente muito legal, com muitos insights ricos e cheio de histórias inspiradoras sobre essas mudanças que estão ocorrendo nas empresas.

Nenhum comentário »

Categorias deste post

Beyond Budgeting, Management 3.0, Mudança organizacional, Videocasts