Anda di halaman 1dari 55

Transformação

e Adoção Agile
Um Guia de Sobrevivência
por Michael Sahota

Prefácios por Jurgen Appelo


e Henrik Kniberg
Adoção e Transformação Agile
Um Guia de Sobrevivência
Trabalhando com a cultura organizacional

por Michael Sahota


Copyright © 2012, 2013, 2014 Michael Sahota. Todos os direitos reservados.
Nenhuma parte deste livro pode ser reproduzida, gravada em um sistema de recuperação
ou transmitida de nenhuma forma, seja eletrônica, mecânica, fotocópia ou gravação, ou
qualquer outro meio, sem autorização por escrito do autor.
ISBN 978-1-105-73572-1

InfoQ Brasil Adoção e Transformação Agile 2


Adoção e Transformação Agile: Sobre o autor
Guia de Sobrevivência
"Como o principal consultor da Agilitrix, minha
por Michael Sahota
missão é fazer a diferença nas vidas das pessoas e
empresas com as quais
trabalho. Apesar de ser
um líder de
pensamento, utilizo
abordagens inovadoras
Tradução para português e revisão e uma variedade grande
de ferramentas, meu
Leonardo Campos
ponto forte é a energia
Rafael Buzon
e paixão que trago como um artista de mudanças
Paulo Rebelo
para ajudar meus clientes a perceberem seus
Marcelo Costa
objetivos. Obviamente o objetivo é tornar-se
Daniel Wildt
melhor, mas podemos fazer isso e ainda ter um
Leonardo Galvão sorriso no rosto de todos."

Como um Coach, Consultor e Instrutor de


Coordenação de tradução Agile/Lean em Toronto, trabalho com empresas
para acelerar a entrega de valor.
Leonardo Campos
Com equipes de software, isso pode incluir a
introdução de frameworks modernos para entrega
Edição e Revisão Final de software como o Scrum ou o Kanban. Ajudo
gerentes de produto a colaborar com os
Leonardo Galvão
stakeholders e clientes a obter resultados por meio
Marcelo Costa
de Jogos de Inovação.
André Campanini
Grupos operacionais podem se beneficiar mais das
aplicações de práticas Lean como o Mapeamento
da Cadeia de Valor, Kaizen e Kanban para melhorar
a eficiência.

Minha paixão no momento é a utilização de jogos


para liberar a criatividade e alcançar resultados
revolucionários. Somada à variedade de jogos e
simulações, sou treinado em StrategicPlay com
SERIOUS PLAY da Lego para resolução de
problemas complicados. Também facilito
© InfoQ Brasil, C4Media Inc.
workshops de Espaço Aberto (Open Space)
Todos os direitos reservados. trazendo grandes grupos para trabalhar na
http://infoq.com/br resolução de problemas difíceis.

InfoQ Brasil Adoção e Transformação Agile 3


Prefácio por Jurgen Appelo
Todos os modelos são úteis, mas alguns falham mais rapidamente que outros. Essa é minha
própria adaptação da frase muito mais famosa de George Box "Todos os modelos são errados,
mas alguns são úteis."
Nesse pequeno e valioso livro, Michael Sahota oferece ao leitor vários modelos úteis de como
trabalhar com empresas ágeis e empresas que querem se tornar ágeis. O livro me ensinou que
normalmente isso significa a necessidade de uma transformação, algo muito mais difícil que
uma simples adoção. Aprender como fazer café de qualidade é uma adoção, tornar-se um
barista é uma transformação. Uma adoção muda apenas o que se faz, uma transformação muda
quem se é.
É claro que a distinção é apenas mais um modelo – porém um modelo muito útil. Quando
queremos mudar o mundo do desenvolvimento de software, queremos aprender como
transformar culturas organizacionais; não é suficiente apenas adotar algumas práticas. Tenho
escutado quase todos os dias, em meus cursos e em conferências, que as pessoas não costumam
ter muitas dificuldades com a adoção de práticas ágeis, mas costumam ter enormes dificuldades
em uma transformação para o pensamento ágil, pois várias culturas organizacionais resistem
ativamente a esse pensamento.
Aprendi, com os melhores livros sobre gestão de mudanças, que mudanças da cultura
organizacional não podem ser feitas com um plano simples de cinco passos. Muito trabalho é
necessário, como entender a cultura atual, utilizando modelos diferentes, adaptar ideias novas
para contextos tradicionais, encurtar os ciclos de feedback; pensar tanto nas pessoas quanto no
ambiente, alternar entre mudança contínua e radical, e fazer experiências de forma que se possa
falhar com segurança.
Michael escreveu esse livro para facilitar um pouco nossas vidas. Os modelos descritos por ele
podem não ser sempre corretos, mas da perspectiva da área de complexidade, podemos
aprender que a única forma de entender bem um problema complexo é considerá-lo de várias
perspectivas incompletas. Vários modelos incompletos, em conjunto, podem dar grande
impulso à nossa capacidade de entender o significado das coisas.
A história contada por Michael nesse livro faz muito sentido. Já adotei algumas de suas ideias em
minhas aulas; posso dizer até que ele transformou um pouco meu próprio pensamento.
—Jurgen Appelo

InfoQ Brasil Adoção e Transformação Agile 4


Prefácio por Henrik Kniberg
Quando participei pela primeira vez de uma conferência sobre Agile, fiquei maravilhado com a
presença de gurus que haviam construído o Agile e escrito os principais livros sobre o assunto.
Mas, para minha tristeza, percebi que diziam coisas diferentes e por vezes discordavam uns dos
outros. O grande aprendizado para mim foi, "Tenho que pensar por mim mesmo". Ouça os
gurus, leia os livros, mas pense por si mesmo.
Mas pensar por si mesmo não quer dizer desprezar anos de sabedoria acumulada. Significa
construir um conjunto pessoal de ferramentas — um repertório de modelos e técnicas para
ajudar a entender o mundo à nossa volta. Sem isso, estamos à mercê do puro instinto, que é
uma excelente ferramenta, mas tem suas limitações.
Michael nos fez um grande favor – extraiu a essência de uma variedade de modelos e livros
sobre mudanças organizacionais e os condensou em uma visão geral "pé no chão",
imediatamente aplicável por qualquer coach, gerente ou outro agente de mudanças. O livro vai
direto ao ponto e, em vez de mergulhar nos mínimos detalhes de cada modelo, o oferece uma
descrição de alto nível — do que trata o modelo e quando aplicá-lo — e referências para
conhecer mais.
É um livro renovador, pois Michael desafia premissas consideradas por muitos como corretas
entre coaches ágeis, e diz "Aqui estão os motivos porque somos péssimos e como podemos ser
um pouco melhores". Às vezes, uma pancada amigável é o que precisamos para permanecer
alertas.
Para manter tudo dentro da realidade, o autor oferece vários exemplos concretos e casos de
estudo — até mesmo um checklist muito útil. Há um ótimo equilíbrio entre teoria e prática.
Uma coisa que aprendi como coach e como agente de mudanças é que as coisas dificilmente
saem como esperado (e quando saem, isso em si é inesperado...). Algumas vezes, o trabalho de
coach “no local”, por tempo prolongado, acaba sendo revertido para o estado anterior em
menos de um ano. Da mesma forma, algumas vezes, um seminário curto mas inspirador pode se
tornar uma semente que por fim muda toda uma organização. Às vezes, um almoço com a
pessoa certa, no momento certo, tem um impacto maior que anos de trabalho de um coach.
O livro de Michael Sahota oferece uma maneira de encontrar o sentido em meio ao aleatório.
Isso porque não é aleatório; é apenas complexo. Obrigado Michael, por tornar o mundo um
pouco menos aleatório.
—Henrik Kniberg

InfoQ Brasil Adoção e Transformação Agile 5


Agradecimentos
"Se vi além, foi por me apoiar sobre os ombros de gigantes."
— Isaac Newton
Gostaria de agradecer a Henrik Kniberg que contribuiu muito com tanto material de domínio
público para a comunidade ágil, e que me inspirou a escrever um e-book gratuito. Também
agradeço-lhe por ter investido tempo para escrever um dos prefácios.
Gostaria de agradecer aos participantes dos workshops que possibilitaram a criação desse
material — XPToronto, SoCal Lean Kanban, Agile Tour Toronto e Agile New England. Seus
comentários, desafios e reflexões ajudaram de forma imensurável.
Agradeço a todas as pessoas que leram meu blog sobre esse tema ao longo de 2011 e
forneceram comentários valiosos. Obrigado a Michael Spayd por apresentar-me o modelo
cultural Schneider, além de conduzir uma pesquisa de Agilistas. E, com certeza, este trabalho
não teria existido sem a distinção proposta por Mike Cottemeyer entre a adoção e a
transformação para o Agile.
Agradeço à equipe de revisão pelo feedback: Chris Williams, Irene Kuhn, Armond Mehrabian,
Krishan Mathis, Bernie Jansen, Ed Willis, Eric Willeke, Karl Scotland, Sabine Canditt, Todd Charron,
Bob Sarni. Particularmente, Olaf Lewitz merece um mérito maior por ter contribuído com uma
extraordinária quantidade de comentários, questões e desafios valiosos.
Gostaria de agradecer àqueles que contribuíram diretamente para este trabalho, bem como na
revisão: Gourment Olivier, pela contribuição com um estudo de caso; Jeff Anderson, Olaf Lewitz,
Jon Stahl, e Karl Scotland e Alexei Zheglov, pela colaboração de seus desafios e visões
alternativas no apêndice.
Também agradeço a Alistair McKinnell, Jason Little, Declan Whelan, pelo feedback sobre o artigo
de Métodos e Ferramentas que constituíram um capítulo deste livro e a John McFadyen e Dave
Snowden, pelo feedback sobre a seção Cynefin.
Sou muito grato a Jurgen Appelo por abrir um espaço em sua agenda ocupada, a fim de
escrever o prefácio.
E obrigado à minha filha Scarlett, que forneceu a arte original com o quebra-cabeças e os
desenhos de transformação da borboleta.
—Michael Sahota

InfoQ Brasil Adoção e Transformação Agile 6


Conteúdo
Introdução .................................................................................................................................... 9
Parte 1: O Agile em Crise............................................................................................................ 10
Falhas com Agile são generalizadas .................................................................................................................................. 10
O Agile está fadado ao fracasso .......................................................................................................................................... 11
A cultura é o desafio número 1 para as adoções ágeis .............................................................................................. 13
Parte 2: Cultura ágil.................................................................................................................... 14
O Agile não é um processo — ele define uma cultura ............................................................................................... 14
Entendendo a cultura por meio do Modelo Schneider.............................................................................................. 15
A cultura ágil se trata de Colaboração e Cultivo ........................................................................................................... 17
O Manifesto Ágil e seus princípios definem a cultura ágil ................................................................................... 17
A abordagem da análise (para os curiosos)............................................................................................................... 17
O modelo cultural permite a formulação de perguntas úteis ............................................................................ 18
A cultura Kanban é alinhada com Controle .................................................................................................................... 19
Mas o Kanban é Agile, não é? ......................................................................................................................................... 20
O Kanban é uma boa ferramenta .................................................................................................................................. 20
O Kanban como cavalo de Tróia ou droga de entrada ......................................................................................... 20
Kanban + Agile = Agile ..................................................................................................................................................... 21
O Artesanato de Software se baseia na competência ................................................................................................ 21
Por que deveríamos nos importar? .............................................................................................................................. 22
Trabalhando com sua cultura .............................................................................................................................................. 22
Entendendo a cultura ........................................................................................................................................................ 23
Trabalhando com outras culturas ................................................................................................................................. 24
Adaptadores culturais ....................................................................................................................................................... 24
Alterar culturas é outra história ..................................................................................................................................... 27
Resumo ........................................................................................................................................................................................ 27
Parte 3: Adoção e transformação: Guia de sobrevivência ...................................................... 28
Definindo adoção e transformação ................................................................................................................................... 28
Ferramentas para o entendimento da adoção e transformação ............................................................................ 28
Adoção de práticas ágeis em uma cultura incompatível .......................................................................................... 29
Evitando o Manifesto Ágil e o Scrum ........................................................................................................................... 30
O Scrum como tecnologia de transformação radical ............................................................................................ 30
Padrões da adoção do Agile ........................................................................................................................................... 30
Tornando-se Agile em um mundo imperfeito ......................................................................................................... 31
Estudo de Caso: Grande organização financeira ..................................................................................................... 31
Adoção e transformação em uma cultura compatível ............................................................................................... 32
Lidere com o Manifesto Ágil e o Scrum ...................................................................................................................... 33
Mudança destemida .......................................................................................................................................................... 33
Inspecione e adapte com uma equipe de transição empresarial ..................................................................... 34
Quando utilizar Inspeção e Adaptação ....................................................................................................................... 34
Quando usar o ADAPT ...................................................................................................................................................... 35

InfoQ Brasil Adoção e Transformação Agile 7


Containers, Diferenças e Trocas..................................................................................................................................... 35
Quando utilizar o CDE ....................................................................................................................................................... 36
O framework Cynefin ........................................................................................................................................................ 36
Quando utilizar o modelo Cynefin ............................................................................................................................... 37
Estudo de caso da adoção do Agile em culturas compatíveis ........................................................................... 37
Transformação para o Agile ................................................................................................................................................. 38
É possível uma transformação para o Agile? ............................................................................................................ 38
Cirurgia Radical .................................................................................................................................................................... 39
Transformação — uma pessoa de cada vez.............................................................................................................. 40
Transformações acidentais para o Agile são prejudiciais às empresas ........................................................... 40
Muitos agentes de mudança agem com um nível de habilidade "acidental" .............................................. 40
O modelo Kotter para mudanças organizacionais ................................................................................................. 42
Liderança de transformação ........................................................................................................................................... 43
Os líderes ágeis dão o exemplo ..................................................................................................................................... 44
Retiro Temenos de liderança .......................................................................................................................................... 44
Outras abordagens para mudança organizacional ..................................................................................................... 44
Para onde ir agora? .................................................................................................................... 46
Checklist para agentes de mudança ................................................................................................................................. 46
Referências ................................................................................................................................. 47
Apêndice I: visões e opiniões alternativas ............................................................................... 50
Cultura como contexto para a adoção e a transformação para o Agile ............................................................... 50
Seu Kanban não é o meu Kanban ...................................................................................................................................... 51
O Kanban é mais que apenas Cultura de Controle ...................................................................................................... 51
O Kanban também é transformação ................................................................................................................................. 52
Scrum x Kanban ........................................................................................................................................................................ 53

InfoQ Brasil Adoção e Transformação Agile 8


Introdução
A comunidade ágil sofre com uma grande confusão quanto à diferença entre adoção e
transformação. Infelizmente, os agentes de mudança falam da adoção do Agile e não da
transformação da cultura de uma empresa para apoiar a mentalidade ágil. A triste
consequência dessa miopia é que os agentes de mudança tentam empreender uma
transformação completa sem o apoio das pessoas ou a compreensão das consequências
organizacionais. O resultado típico é o fracasso.
Existem poucos modelos em nossa comunidade que orientam os agentes de mudança
ágeis a compreender quando usar adoção e quando usar transformação. Certamente, há
um conjunto de conhecimentos substanciais sobre técnicas específicas para a adoção e para
a transformação, mas que pouco informam o que e porque fazer.
Esse guia de sobrevivência fornece uma estrutura simples que pode ser usada para
entender e planejar o trabalho para uma mudança ágil. Essa estrutura também pode ser
útil, caso se esteja trabalhando com Kanban ou com Artesanato de Software. Essa
estrutura me ajudou a sair da "incompetência inconsciente", como um agente de mudanças
e a me tornar consciente das escolhas que estou fazendo, o que me permitiu começar a
escalada rumo à competência.
O primeiro passo para atenuar um problema é reconhecer que ele existe. O problema em
questão são os níveis elevados de insucesso nas empresas que estão adotando ou
transformando para o Agile. Algumas das causas que motivaram a necessidade de um
guia de sobrevivência são discutidas na primeira parte desse livro.
Se a cultura não for gerenciada, ela gerenciará você. Grande parte dos fracassos na adoção do
Agile é resultado da não compreensão da cultura organizacional. A segunda parte desse
livro explica como utilizar a cultura organizacional para entender o Agile, o Kanban e os
movimentos do Artesanato de Software. O livro também aborda como utilizar o modelo
cultural Schneider para avaliar a cultura da sua organização e propõe algumas maneiras
de se trabalhar eficazmente com ela.
A terceira parte deste livro oferece um framework ou estrutura para a compreensão e
seleção de abordagens, para a adoção e para a transformação apropriadas a diversos
contextos. Uma visão geral dos principais métodos de transformação e de adoção é
apresentada. A estrutura proposta fornece o conhecimento básico necessário para abordar
a mudança ágil nas organizações.

InfoQ Brasil Adoção e Transformação Agile 9


Parte 1: O Agile em Crise
Falhas com Agile são generalizadas
Os esforços de adoção e transformação para o Agile estão se deparam com altas taxas de
insucesso em muitas indústrias e organizações. 84% dos entrevistados na pesquisa "Estado
do Desenvolvimento Ágil" relataram fracasso em pelo menos um projeto ágil. Apenas 16%
dos entrevistados não experimentaram nenhum fracasso.
Conduzi minha própria pesquisa informal sobre o tema, pedindo que pessoas avaliassem,
em uma escala de 0 a 5 quanto sucesso obtiveram com o Agile, onde a nota zero indica
nenhum sucesso e 5 indica que todos os projetos foram bem sucedidos. A média obtida
com cerca de 130 participantes em quatro sessões diferentes foi de 2,7, o que não é bom.
Veja os resultados a seguir, referentes à minha “Pesquisa Informal de Fracassos”. Observo
que as pessoas avaliaram com base em suas próprias definições de "sucesso" e "fracasso".

Onde Quando 0 1 2 3 4 5 Qtde. Média

Play4Agile 02/2010 1 6 5 1 13 2,5

XP Toronto 05/2011 1 3 7 10 5 26 2,6

Agile Tour Toronto 09/2011 5 12 23 4 44 2,6

Agile New England 12/2011 1 8 30 10 49 3,0

É possível perceber uma consistência nos resultados médios, pois apresentam


baixas variações. Não acredito que uma conclusão clara possa ser tirada da variância ou
das tendências apresentadas.

InfoQ Brasil Adoção e Transformação Agile 10


O Agile está fadado ao fracasso
Consideremos algumas das razões mais comuns de fracasso e por que o Agile parece estar
fadado a apresentar problemas.
Na curva de adoção de tecnologia proposta por Geoffrey Moore, no seu livro
Atravessando o Abismo, o Agile atravessa atualmente “o abismo” e visionários oferecem
grande suporte gerencial. Têm também alta tolerância a mudanças, como mostra a figura a
seguir. Um requisito fundamental para o sucesso, para a maioria dos adeptos iniciais é um
"produto completo", que consiste em ter a ideia central cercada por tudo o que é necessário
para torná-la bem sucedida. Alguns elementos desse "produto completo" estão presentes;
outros estão ausentes ou indefinidos. A contínua ausência de um "produto completo" é um
indicador de que o Agile não está suficientemente maduro para ser aceito como padrão.

InfoQ Brasil Adoção e Transformação Agile 11


Mas um problema ainda maior é pensar no Agile como um produto; essa é uma metáfora
perigosa, que não traduz o Agile como sistema cultural ou mentalidade/filosofia.

Martin Fowler define a Difusão Semântica como o processo no qual uma palavra (Agile
por exemplo) cunhada por uma pessoa ou grupo, se espalha pela comunidade de forma
que enfraquece a definição original. Esse enfraquecimento cria o risco de se perder
completamente a definição — e com ela qualquer utilidade do termo. Realmente, conheci
pessoas que alegavam ser ágeis e que entendiam as práticas, mas não a mentalidade ágil. É
cada vez mais comum encontrar praticantes ágeis que entendem as práticas, mas falham
em entender os valores e os princípios. O Agile estaria fadado ao fracasso se sua
mensagem e significado se tornarem sem difusas ou distorcidas.
A popularização do termo Agile seguiu também um padrão comum, como o observado
em diversas adoções tecnológicas, que está fundamentada no hype e na desilusão, como
ilustrado no diagrama a seguir (da Wikipedia). O Agile já passou o ponto das super
expectativas e ruma agora para cruzar a barreira da desilusão (veja no Stack Overflow, "O
desenvolvimento ágil está morto?"). Pode-se considerar o atual livro como passo no
sentido de acelerar este processo ao chamar a atenção para os erros comumente cometidos
e ao oferecer um guia na escalada em direção ao esclarecimento e compreensão.

InfoQ Brasil Adoção e Transformação Agile 12


A cultura é o desafio número 1 para as adoções ágeis
Os resultados da pesquisa sobre o estado do desenvolvimento ágil são surpreendentes, em
termos da gravidade e da amplitude das dificuldades que as empresas enfrentam com a
adoção do Agile.
A maior barreira na continuidade das adoções ágeis nas empresas é a mudança cultural
(veja o diagrama a seguir). O problema é reportado por 52% dos participantes, e o número
pode estar subdimensionado devido à dificuldade de se identificar problemas culturais.
Qual a importância, então, da cultura da empresa? Edgar Schein, professor do MIT, diz
que "se a cultura não for gerenciada, ela lhe gerenciará, e é possível que nem se perceba o
o grau com que isso está acontecendo."

InfoQ Brasil Adoção e Transformação Agile 13


Parte 2: Cultura ágil
O Agile não é um processo — ele define uma cultura
Qual a relação disso com o Agile?
O que é o Agile, afinal? A definição consensual é oferecida pelo Manifesto Ágil, que já tem
mais de dez anos: O Agile é uma ideia apoiada em um conjunto de valores e crenças. Em
outras palavras, o Agile define uma cultura a se atingir, para a entrega bem sucedida de
software. Esse livro aprofundará o tema do modelo cultural ágil mais adiante.
O Agile é frequentemente descrito como um processo ou uma família de processos. Isso é
verdade, mas é também uma abstração perigosa e incorreta. Infelizmente, já passei essa
mensagem enganosa diversas vezes, por pura ignorância. Se o Agile fosse apenas uma
família de processos, não veríamos a cultura como um dos principais problemas
enfrentados na sua adoção.
Também é muito comum a "venda" do Agile como um produto. As empresas têm
problemas com prazos de entrega ou com baixa qualidade, e procuram uma solução. Os
benefícios do Agile são alardeados e um projeto é iniciado tendo o Agile como a solução.
Dave Thomas cunhou a ideia da Fada dos Dentes Agile, que os coaches ágeis poderiam
apanhar e espalhar "pó mágico" em projetos problemáticos para corrigir anos de atrofia e
negligência. Trata-se de um mito, claro: o Agile não é uma bala de prata que pode resolver
todos os problemas.
O Agile se trata de uma alteração fundamental na forma de pensar. Tobias Mayer escreveu
que o Scrum é muito mais mudar a forma de pensar do que um processo. Bob Hartman
tem uma ótima apresentação sobre o assunto: Utilizar o Agile não significa ser Ágil.
Estamos "usando o Agile" quando seguimos práticas e "sendo ágeis" quando agimos com
mentalidade ágil. Praticantes experientes do Agile sabem que as práticas são apenas meios
para um fim.
Mike Cottmeyer escreveu uma série de ótimos posts sobre como as empresas estão
adotando o Agile, e não se transformando em ágeis. Ele contribuiu muito ao separar
claramente os significados do termo adoção do termo transformação, pois esses eram e ainda
são usados como a mesma coisa. Mike faz a seguinte distinção:
• O termo adoção está ligado ao lado "Utilizando o Agile" da equação
• Já o termo transformação está no lado "Ser ágil" da equação
Em outro fórum, Israel Gat falava sobre a relação entre a cultura e o Agile, em Como
fazemos as coisas por aqui para ter sucesso. Sua observação é que a adoção do Agile
provoca um conflito devido às incompatibilidades culturais entre grupos internos na
organização. Gat sugere que precisamos ficar atentos a esses problemas para podermos
mitigá-los. Pete Behrens documentou estudos de caso sobre utilização da cultura como
uma forma de dar apoio à agilidade.
Para se obter sucesso, precisamos começar a pensar sobre o Agile como uma cultura e não
como um produto ou família de processos.

InfoQ Brasil Adoção e Transformação Agile 14


Na proxima seção, mostro um modelo que pode ser utilizado para entender a cultura da
sua organização. As seções seguintes explicam as culturas únicas do Agile, do Kanban e
do Artesanato de Software. Na última seção, ofereço um guia para avaliar como uma
abordagem específica se encaixa na cultura da sua organização.

Entendendo a cultura por meio do Modelo Schneider


Precisamos definir o que se quer dizer com cultura antes de explorar mais o Agile. Nessa
seção, apresento o Modelo Cultural Schneider inspirado no livro de William
Schneider (Schneider – The Reengineering Alternative: A plan for making your current
culture work). Apesar de haver muitas formas distintas de se pensar sobre culturas
corporativas, esse modelo foi selecionado por levar a planos que podem ser seguidos na
prática.
Um modelo cultural nos mostra os valores e normas de um grupo ou de uma empresa. O
modelo identifica o que é importante, e como as pessoas abordam o trabalho e interagem
com outras pessoas. Em uma determinada cultura, por exemplo, a estabilidade e a ordem
podem ser bastante valorizadas. Nesse caso, processos claramente definidos são
valorizados e há forte expectativa de conformidade ao processo em vez de em valores
como inovação e criatividade.
O Modelo Cultural de Schneider define quatro grupos distintos de cultura:
1. Cultura de colaboração representa o trabalho em conjunto;
2. Cultura de controle significa a obtenção e manutenção do controle;
3. Cultura de competência representa a busca por ser o melhor;
4. Cultura de cultivo representa o aprendizado e o crescimento com propósito
claro.
O diagrama a seguir resume esse modelo. Os quatro tipos de cultura são demonstrados
em quadrantes, com o respectivo nome, "citação descritiva", uma imagem e algumas
palavras que o caracterizam. Vale a pena ler o diagrama, entendê-lo e exercitar onde sua
empresa se encaixa no modelo.

InfoQ Brasil Adoção e Transformação Agile 15


Outro aspecto do modelo Schneider são os eixos que indicam o enfoque de uma
organização:
1. Eixo horizontal: Orientado a pessoas (Pessoal) vs. Orientado à empresa
(Impessoal)
2. Eixo vertical: Orientado à realidade vs. Orientado a possibilidades
Essa disposição oferece uma forma de ver as relações entre as culturas. Uma cultura de
Controle, por exemplo, é mais compatível com culturas de Colaboração ou de
Competência que com uma cultura de Cultivo. O aprendizado e o crescimento são opostos
à segurança e à estrutura. De maneira semelhante, Colaboração é oposta a Competência.
Todos os modelos são uma aproximação da realidade e é importante lembrar que estamos
ignorando pequenas discrepâncias, para que possamos realizar análises e fazer
argumentos. Também podemos querer considerar outros modelos, tais como Dinâmicas
Espirais para entender a evolução cultural.
No modelo de Schneider, nenhum tipo de cultura é considerado melhor que outro.
Dependendo do tipo de trabalho, um tipo cultural pode ser uma escolha melhor que outra.
Schneider sugere que a maioria das empresas tem uma única cultura dominante, com
elementos dos outros três quadrantes culturais. Outros elementos culturais são
encorajados, desde que sirvam à cultura dominante. Departamentos ou grupos diferentes
(ex. desenvolvimento vs. operações) tipicamente possuem subculturas. Essas diferenças
podem levar a conflitos.

InfoQ Brasil Adoção e Transformação Agile 16


A cultura ágil se trata de Colaboração e Cultivo
Michael Spayd fez um grande serviço para a comunidade ao realizar uma pesquisa
cultural entre os agilistas. O diagrama a seguir exibe os resultados, cujo principal marco
mostra que os praticantes ágeis têm um perfil cultural particular tendo como elementos
fundamentais a Colaboração e o Cultivo. Os resultados indicam que o Agile é intimamente
relacionado às pessoas. A pesquisa incluiu praticantes do Scrum, do XP, assim como do
Kanban.

O Manifesto Ágil e seus princípios definem a cultura ágil


O Manifesto Ágil e seus doze princípios — mesmo depois de mais de dez anos — ainda
são a referência para o que é considerado ágil. Veja o diagrama a seguir, em que os valores
e princípios são mapeados para o modelo de Schneider.
Percebe-se que há uma alta densidade de valores e práticas alinhados com a Colaboração e
com o Cultivo. Repare, por outro lado, que não existem elementos ligados à cultura de
Controle e há apenas um ligado à cultura de Competência. É um resultado muito
semelhante ao obtido por Michael Spayd em sua pesquisa com Agilistas.

A abordagem da análise (para os curiosos)


O leitor pode ficar curioso sobre como obtive esses e outros resultados mostrados nesse
livro.
Para cada valor ou princípio, analisei quanto cada um estava alinhado com cada uma das
culturas. Se houvesse grande afinidade, o valor/princípio era associado àquela cultura.
Por exemplo, não houve dificuldades com Colaboração com o Cliente, pois esse valor
claramente identifica que o sucesso é obtido por meio de pessoas trabalhando juntas.

InfoQ Brasil Adoção e Transformação Agile 17


Alguns itens pareceram transversais ao modelo cultural de Schneider, como “Software em
Funcionamento”, que não parece sugerir nenhuma das culturas em detrimento das outras.
Talvez indique a cultura da Competência, mas muito timidamente. Como resultado, esse
valor não foi apresentado no diagrama anterior. Outras conclusões foram “melhores
palpites”, que pude estabelecer com meu entendimento atual.
Alexei Zhegloz comparou essa abordagem a jogar dardos em um alvo. Cada valor ou
princípio é um dardo individual e o alvo seria o modelo de Schneider. Alguns dardos
acertarão o alvo em uma área específica de um quadrante cultural; outros errarão
completamente. Após jogar alguns "dardos", podemos notar como se espalham, mas não
precisamos nos atentar demais se cada dardo individual está corretamente localizado. Esse
método de análise é comumente utilizado para ilustrar o viés cognitivo de um sistema de
pensamento.

O modelo cultural permite a formulação de perguntas úteis


Quando começamos a pensar sobre o Agile como uma cultura específica, podemos formular
perguntas interessantes como:
• Qual é a cultura na minha empresa agora?
• quanto essa cultura está alinhada com o Agile?
• Quais problemas posso esperar devido a esse desalinhamento?
Veja mais sobre esse assunto na seção “Trabalhando com sua cultura”, adiante.

InfoQ Brasil Adoção e Transformação Agile 18


A cultura Kanban é alinhada com Controle
Escolhi um post esclarecedor de David Anderson como base e inspiração para uma
análise. David é sem dúvida o principal líder da escola Kanban em software, com seu
livro, além de uma lista de discussão muito ativa e o Lean System Society (antigo Lean
Software and Systems Consortium). O texto foi escolhido por se tratar de um resumo dos
princípios apresentados em seu livro Kanban.
Assim como feito para o Manifesto Ágil, alinhei os princípios do Kanban com o modelo
cultural de Schneider. Como pode ser notado no diagrama a seguir, o Kanban é, em
grande parte, alinhado com a cultura de Controle, tendo a cultura de Competência como
influência secundária.

As culturas de Controle respiram políticas e processos, coisas que o Kanban tem de sobra.
A cultura de Controle também busca criar uma estrutura clara e ordenada para gerenciar a
empresa — exatamente o que o Kanban faz bem. As culturas de Controle têm enfoque na
empresa/sistema (não nas pessoas) e no estado atual (não no futuro). Essa é uma boa
descrição como ponto de partida para o Kanban.
O que é realmente interessante da perspectiva da análise cultural é o princípio: “Melhore
colaborativamente utilizando modelos e um método científico”. De acordo com o modelo
de Schneider, esses dois conceitos não se misturam, pois fazem parte de culturas opostas.
A pergunta então é: como isso pode funcionar? Segundo Schneider, outros elementos
culturais podem estar presentes, desde que apoiem a cultura central. Ter algum foco em
“pessoas” não tem problema, desde que seja apoiado o controle/rastreamento do trabalho.

InfoQ Brasil Adoção e Transformação Agile 19


O conceito de mudanças evolucionárias, ou controladas, também pode ser compatível com
uma cultura de Controle, caso seja utilizada para manter a estrutura e hierarquia
organizacional existentes.
Karl Scotland defende um conjunto alternativo de princípios do Kanban. Esses princípios
também se enquadram nas culturas de Controle e Competência no modelo.

Mas o Kanban é Agile, não é?


Mike Burrows escreveu um post bastante influente no qual argumenta que o Kanban
satisfaz cada um dos princípios ágeis. Mas analisado de uma perspectiva cultural, parece
ser um argumento sem muito fundamento.
O Agile e o Kanban compartilham, certamente, uma comunidade comum, e muitas
práticas podem ser adotadas tanto de um lado quanto de outro. Contudo, perspectivas
fundamentalmente diferentes são promovidas de cada lado. O Agile dá grande enfoque a
pessoas e o Kanban, nos sistemas. As pessoas também são sim importantes no Kanban,
mas de forma subsidiária ao sistema.
Pode-se entender, então, que o Kanban é ágil também? Deixei de acreditar nisso. Entendo
agora que a crença de que o Kanban é ágil é prejudicial, uma vez que o viés cultural do
método é muito diferente.

O Kanban é uma boa ferramenta


Algumas vezes, quando apresento a análise do Kanban de forma vinculada à cultura de
Controle, há fortes reações negativas, pois a cultura de Controle é vista como uma
abominação para o trabalho do conhecimento. Para evitar qualquer mal-entendido, vamos
explicar alguns pontos:
• Adoro o Kanban e o considero ótimo. Precisamos de mais Kanban no mundo. Veja
um post em meu blog sobre o assunto mostrando que há situações em que o
Kanban é uma escolha mais adequada que o Scrum.
• Não estou acusando os que preferem o Kanban de supercontroladores ou de que
preferem a estrutura de comando e controle. O que afirmo é que se sua empresa
tem uma cultura de Controle, então o Kanban é uma ferramenta que lhe ajudará
mais que o Scrum.
Veja o apêndice para visões alternativas do Kanban oferecidas pelos revisores.

O Kanban como cavalo de Tróia ou droga de entrada


Nesse contexto, a teoria da droga de entrada (Gateway Drug) diz que a droga mais leve
(Kanban) pode levar a drogas mais fortes (Scrum, XP). É uma ótima metáfora, pois a teoria
foi tanto provada quanto refutada. Citando David Anderson: "estamos apenas começando
a entender as diferenças entre o Scrum e o Kanban".
Há casos documentados de equipes trabalhando com o Kanban que têm espontaneamente
colaborado, aprendido e observado/resolvido os problemas. Essa também tem sido minha
experiência, que confirmaria a hipótese do Kanban como cavalo de Tróia (pois contém o
Agile dentro dele).
É excelente quando se trabalha para melhorar ambientes em ritmo constante. Isso porque
muitas empresas não estão prontas para uma mudança radical (mesmo que precisem

InfoQ Brasil Adoção e Transformação Agile 20


desesperadamente disso). Para empresas como essas, o Kanban é um ótimo começo. Sair
do sofá direto para uma maratona (Scrum) pode causar um ataque cardíaco; para muitos
pode ser melhor começar com uma corrida leve em torno do quarteirão (Kanban).
Aprofundaremos o assunto por meio da exploração da adoção e transformação.

Kanban + Agile = Agile


É possível praticar uma mentalidade ágil tendo o Kanban como um ponto de partida para
evoluir o processo. Nessa situação, o foco está nos valores e princípios ágeis, nos quais
políticas e processos dão apoio ao trabalho das pessoas. Essa abordagem pode ser
apropriada sempre que o Scrum ou o XP não forem boas escolhas para o ambiente atual.
Veja CrystalBan como opção para integrar pessoas ao Kanban (Scotland: Crystalizando o
Kanban).
Olaf Lewitz argumenta que o Kanban poderia e deveria ser utilizado da mesma forma
que o Agile — para provocar mudanças no status quo. O propósito primário é oferecer um
ciclo de sentir-agir, que possa ser utilizado para impulsionar mudanças nas organizações.
Lewitz também argumenta que "as pessoas são o sistema" e que qualquer programa de
mudanças envolve as pessoas como componente central.

O Artesanato de Software se baseia na competência


O crescimento do Scrum anêmico causou desânimo na comunidade ágil. Uncle Bob
cristalizou o problema ao sugerir o quinto valor para o Manifesto Ágil, Craftmanship over
Crap (Execution).
Já estabeleci que a comunidade ágil coloca em foco a Colaboração e o Cultivo, em
detrimento da Competência. Como comunidade de profissionais de software, precisamos
prestar atenção à Competência e à excelência técnica, para conseguir sustentabilidade no
longo prazo. Para mais informações sobre esse tópico, veja o artigo do Uncle Bob, A terra
esquecida pelo Scrum.
O diagrama a seguir relaciona as partes do Manifesto do Artesanato de Software às
culturas do modelo de Schneider.
Não é de se surpreender que no Artesanato de Software haja grande enfoque na cultura de
Competência, uma vez que a proposta para se alcançar o sucesso é que os
desenvolvedores sejam os melhores que for possível.
O valor parcerias produtivas aparece sozinho no quadrante da Colaboração, cuja ideia
central é trabalhar junto com os clientes na produção de software de valor, resolvendo
realmente os problemas, em vez de gerar apenas código sem sentido.

InfoQ Brasil Adoção e Transformação Agile 21


Por que deveríamos nos importar?
O Artesanato precisa existir para garantir que as práticas promovidas pelo XP apoiem o
desenvolvimento sustentável, mantendo vivas práticas como refatoração sem piedade;
fazer a coisa mais simples que funcione; Desenvolvimento Orientado a Testes (TDD);
Desenvolvimento Orientado a Testes de Aceitação (ATDD); integração contínua;
implantação contínua; propriedade coletiva de código; código limpo; etc. Dessa forma, não
nos perdemos em uma cultura ágil de faz-de-conta.
A criação e a existência de um movimento separado do Agile, que apoia a cultura de
Competência, reforça a impressão de que a cultura ágil valoriza mais a Colaboração e o
Cultivo que a cultura de Competência.
Uma nota final: o manifesto do Artesanato de Software não reflete com precisão um
aspecto fundamental, o alto comprometimento com o aprendizado e o crescimento (Cultura de
Cultivo). Esse é um valor que existe para apoiar o objetivo central do movimento, que é a
excelência na construção de software.

Trabalhando com sua cultura


Considere o diagrama a seguir, que ilustra como os princípios do Agile, do Kanban e do
Artesanato de Software se alinham com as diferentes culturas. Os formatos mostram a
cultura dominante de acordo com a análise realizada nas seções anteriores.
O diagrama pode ser utilizado como guia para determinar qual a abordagem que melhor
se adapta à cultura dominante da sua empresa.

InfoQ Brasil Adoção e Transformação Agile 22


• Cultura de Controle –> Comece com o Kanban
• Cultura de Competência –> Comece com o Artesanato de Software
• Cultura de Colaboração ou de Cultivo –> Comece com aspectos do Agile que se
alinham com a cultura organizacional. Ex. Visão e Retrospectivas para culturas de
Cultivo.
Observe que não se pretende que este guia seja utilizado sem considerar outros aspectos
da cultura e do contexto organizacional.
Muitos leitores devem estar interessados em saber como mudar de uma cultura
organizacional de Controle para uma cultura de Colaboração, Cultivo ou Competência.
Isso será discutido em detalhes na seção sobre Transformação.

Entendendo a cultura
O primeiro passo para trabalhar com sua cultura é entendê-la. Schneider descreve uma
pesquisa que pode ser realizada com os funcionários, cujo resultado serviria como ponto
de partida para workshops de cultura com um grupo diversificado de funcionários. Na
minha experiência, considero que workshop sozinho é mais preciso (como reportado pelos
participantes); ele gera entendimento mais profundo e uma melhor aceitação.
O guru da gestão Peter Drucker afirma que a "cultura … é extremamente persistente … Na
verdade, mudar o comportamento só funciona se tiver como base uma 'cultura' existente".
A implicação dessa afirmação é que não é possível mudar de uma cultura de Controle
para uma cultura Agile.
Um premissa central no livro de Schneider é a afirmação de que é essencial trabalhar com
a cultura existente, ao invés de lutar contra ela. Existem diversas sugestões de como
utilizar informações culturais para guiar a tomada de decisões:

InfoQ Brasil Adoção e Transformação Agile 23


• Avaliar problemas fundamentais sob um contexto cultural, pois algumas vezes
mudanças são necessárias para alinhar a cultura com a cultura central.
• Às vezes, a cultura é muito extrema (ex. Cultivo demais sem nenhum controle, ou
vice-versa) e elementos de outras culturas podem ser necessários para trazê-la de
volta ao equilíbrio.
• Avalie a possibilidade de criar interfaces/adaptadores/fachadas para mitigar
possíveis desalinhamentos entre departamentos ou grupos.

Trabalhando com outras culturas


Considere o diagrama a seguir, que ilustra algumas formas eficazes de lidar com a cultura.

A Opção 1, "Permaneça aqui", ilustra que é mais fácil se manter na cultura dominante
(Controle, nesse caso). Já a Opção 2 sugere explorar cuidadosamente culturas adjacentes
de maneiras que deem apoio à cultura central. A cultura secundária já estabelecida na
organização pode indicar a escolha da cultura para a qual se direcionar. A ideia,
novamente, é trabalhar com a cultura e não contra ela.

Adaptadores culturais
Uma forma interessante de se introduzir uma nova cultura em uma organização é por
meio de um modelo celular (com base em células). Considere, por exemplo, uma
transformação bem-sucedida para o Agile em uma equipe.
Vamos supor que essa equipe esteja bastante entusiasmada com a nova forma de
trabalhar. Contudo, não está tão satisfeita com as barreiras organizacionais e com os
limites à produtividade e ao sucesso. Neste cenário, a equipe mais motivada muitas vezes
começa a rejeitar demandas de outros grupos que não estejam adicionando valor.

InfoQ Brasil Adoção e Transformação Agile 24


O resultado lembra um filme B: "O Ataque dos Anticorpos Organizacionais". De forma
parecida com os anticorpos humanos, as empresas reagem à introdução de um sistema
cultural "estranho" como o Agile, lutando para manter o status quo.

O filme, no entanto, pode ter final feliz. Um modelo comum é a criação de adaptadores ou
de tradutores, que permitam que a nova cultura introduzida se encaixe na cultura geral
predominante. Os adaptadores/tradutores são ilustrados no diagrama a seguir. Cercam e
protegem a equipe, permitindo que ela se misture com a cultura organizacional atual, sem
disparar reações do “sistema de defesa” organizacional e de seus anticorpos.

InfoQ Brasil Adoção e Transformação Agile 25


Na prática, um adaptador poderia ser, por exemplo, a elaboração de um plano no
Microsoft Project, que pode não ter nenhum valor para o cliente nem para a equipe, mas
que é exigido pela organização. Outro exemplo seria a realização de avaliações para
ganhos de promoções por mérito, que ainda assim são submetidas à gerência, pois o
sistema exige esse passo.
Será que todo esse esforço vale a pena? O que deve ser levado em conta são os benefícios
do Agile, descontados os custos da manutenção do adaptador. Se consideramos que o
novo estado de funcionamento da equipe traz muito valor, então uma parte dessa
produtividade, infelizmente, será gasta para manter os adaptadores. É uma situação
melhor que a de ser atacado pelos anticorpos organizacionais. Os adaptadores são parte
do custo de se fazer negócios, a exemplo dos impostos.
A filosofia Lean diferencia alguns tipos de desperdício nas organizações. O tipo I de Muda
(desperdício), um conceito do sistema Toyota, constitui tarefas que não adicionam valor,
mas que são exigidas naquele momento. O tipo II de Muda são tarefas que não adicionam
valor, mas que podem ser removidas imediatamente. Está claro que a manutenção dos
adaptadores é do tipo de desperdício (tipo I), uma vez que o ambiente os exige.
Caso de estudo: Ao introduzir Scrum em uma organização, o PMO requisitou que fosse
produzido um plano de projeto que não adicionaria valor e minha resistência em produzi-
lo gerou uma batalha com o PMO. Apesar de a briga ter economizado um pouco de
trabalho, a transição para o Agile ganhou um inimigo na empresa. A equipe, felizmente,
foi muito bem-sucedida e o próprio gerente agiu como adaptador, trabalhando para
proteger a equipe, e para satisfazer todas as exigências organizacionais externas. Após
dois anos de luta e desgaste, porém, gerente estava esgotado.
Caso de estudo por Olivier Gourment: Para introduzir programação em pares em uma
organização em que as revisões de código eram obrigatórias, foi melhor apresentar a
programação em pares como uma "revisão melhorada" de código. De um ponto de vista, a
programação em pares consiste em um piloto e copiloto colaborando prontamente na

InfoQ Brasil Adoção e Transformação Agile 26


revisão. Para quem via de fora, parecia apenas uma revisão de código. A programação em
pares é algo que deve ser experimentada antes de se entender seus benefícios.
O modelo apresentado aponta uma forma de se ter sucesso em uma transformação para o
Agile — é possível transformar uma equipe ou um grupo, desde que se tenha cuidado e
atenção para satisfazer as exigências da organização. Pode parecer que a estratégia dos
adaptadores não seja sustentável no longo prazo, mas pode ser um primeiro passo numa
iniciativa de mudança organizacional mais abrangente.
Joseph Pelrine tem uma discussão profunda sobre o problema do desalinhamento entre
equipes ágeis e seus respectivos ambientes. Trata-se também de boa explicação do estudo
da "complexidade social".

Alterar culturas é outra história


Mudar culturas é muito difícil. Veremos mais sobre o assunto no próximo capítulo, sobre
Transformação Ágil.

Resumo
Parabéns, agora você conhece mais sobre o Modelo Cultural de Schneider — uma
ferramenta para avaliar a cultura em sua empresa. Uma vez conhecida essa cultura, será
possível entender como melhor influenciar muitos aspectos do trabalho do dia-a-dia.
Ainda mais importante, pode-se utilizar o modelo para tomar a decisão de qual
abordagem se encaixa melhor na cultura da empresa — o Agile, o Kanban ou o Artesanato
de Software. Mas se o interesse for desafiar o status quo para ajudar a construir grandes
equipes e organizações, continue lendo!

InfoQ Brasil Adoção e Transformação Agile 27


Parte 3: Adoção e transformação: Guia de
sobrevivência
Definindo adoção e transformação
Adoção, como sabemos, é um termo aplicado tanto a um produto quanto a um processo.
Por exemplo, "estamos adotando o Google Docs como substituto do Microsoft Office" ou
"estamos adotando um novo processo de contratação de terceiros".
Vê-se o uso frequente da expressão "estamos adotando o Agile". Como estabelecemos, o
Agile é uma mentalidade e uma cultura, e não pode ser adotada. Por outro lado, pode-se
seguramente dizer que se está adotando o Scrum ou que se está adotando práticas ágeis.
Transformação significa uma mudança de uma forma de ser para outra, ou seja é uma
mudança de grande porte, como a criação de um ambiente onde as pessoas tenham prazer
em trabalhar.
"Estamos nos transformando para o Agile" é uma maneira precisa de descrever o esforço
empreendido em ambientes onde as mudanças representam uma alteração importante nos
comportamentos e valores.
A palavra transição significa "movimento, passagem; mudança de uma posição, estado,
estágio, conceito etc, para outro(a)". O termo transição pode ser utilizado tanto para
descrever uma adoção quanto uma transformação. Desse modo, como a palavra transição
é ambígua, é melhor evitá-la.

Ferramentas para o entendimento da adoção e transformação


Considere a estrutura a seguir, que permite analisar e planejar com eficiência os esforços
de mudança. Há três categorias principais:
• A adoção de práticas ágeis em uma cultura incompatível (à esquerda);
• A adoção e a transformação em uma cultura que oferece apoio (no centro);
• Transformação para o Agile (à direita).
O diagrama mostra uma série de abordagens e em quais contextos elas se mostram mais
úteis. Não se pretende que a visão seja completa, mas sim ilustrativa, para ajudar a
comparar se a abordagem se comporta melhor para uma adoção ou para uma
transformação. O diagrama oferece um esquema para se pensar sobre as abordagens e
objetivos em um esforço de mudança, de forma que permita a um agente de mudanças
escolher a melhor abordagem para dado contexto.

InfoQ Brasil Adoção e Transformação Agile 28


Adoção de práticas ágeis em uma cultura incompatível
O objetivo desta seção é explicar abordagens para a adoção de práticas do Agile, do
Kanban ou do Artesanato de Software, em uma empresa com cultura incompatível com a
abordagem escolhida. Um exemplo seriam as práticas ágeis de cultura de colaboração em
uma cultura hierárquica centralizada, ou práticas de Artesanato de Software ligadas à
cultura de competência em uma cultura de colaboração.
Antes de embarcar nesse caminho, porém, vale a pena considerar algumas perspectivas
sobre os méritos desse tipo de abordagem.
A orientação dada por Schneider é identificar práticas que apoiem a cultura dominante da
empresa em vez de tentar mudá-la. Schneider descreve essa abordagem como "fazer sua
cultura funcionar".
O Agile seria visto, por exemplo, como um cardápio de práticas, não uma proposta que
contém um sistema de valores. Poderíamos utilizar iterações ou timeboxes para oferecer
mais estrutura e controle para a entrega do projeto, ou ainda introduzir o conceito de
velocidade, para adicionar mais controle empírico e assim melhorar a previsibilidade das
entregas.
Muitos defensores do Agile acreditam que reduzi-lo a um conjunto de práticas é uma
completa falta de compreensão do que é o Agile. O Agile é uma forma de ajudar as
organizações a serem mais bem sucedidas, não um conjunto de práticas em um cardápio.
Do ponto de vista cultural, o Agile tem como objetivo se afastar de uma cultura de controle
e não oferecer meios para apoiá-la.

InfoQ Brasil Adoção e Transformação Agile 29


Outro ponto de vista a se considerar é o da súplica [Sirajuddin]. Trata-se de uma forma de
se envolver com alguém ou com um sistema com um profundo respeito e apreço. Por
exemplo, ao invés de dizer: "Esse departamento está mal das pernas", seria mais adequado
pensar, "O sistema está funcionando, neste momento, da melhor forma que poderia; as
pessoas estão conseguindo trabalhar, apesar dos obstáculos." Com uma postura de súplica,
pode-se perceber que talvez uma organização não seja capaz de aceitar ou mesmo querer a
mentalidade ágil. Dessa forma, seria melhor apoiar a organização no seu estágio atual de
aprendizado e crescimento (ou seja, cultura).

Evitando o Manifesto Ágil e o Scrum


Quase tão importante quanto o que fazer é o que não fazer. Um exemplo é evitar qualquer
coisa que possa sugerir ou encorajar uma mudança na mentalidade ou na cultura. A razão
é que, pela minha experiência, conduzir mudanças de mentalidade durante a adoção das
práticas ágeis parece mais confundir e desorientar, do que trazer qualquer benefício. Dar
enfoque, por exemplo, na colaboração profunda não funciona bem quando o grupo está
distribuído geograficamente.
Como discutido antes, o Manifesto Ágil é uma declaração de valores que se propõe a
formar uma cultura específica. Trata-se, portanto, de uma boa ideia evitar mencioná-lo ou
mesmo tê-lo com objetivo na adoção do Agile. No mínimo, pode-se dizer que é irrelevante,
chegando a causar mudanças acidentais no comportamento das pessoas e gerando atritos
no ambiente. Vale a pena, por outro lado, conversar com a equipe gerencial sobre a cultura
Agile, juntamente com os valores e princípios do Manifesto. Isso apoia decisões
embasadas sobre a adoção ou a transformação.

O Scrum como tecnologia de transformação radical


O Scrum é uma tecnologia de transformação bastante poderosa, projetado para romper
com o poder e estruturas de controle ao criar novos papéis (Product Owner, Scrum Master
e a Equipe). O Scrum também propõe equipes auto-organizadas como pilares
fundamentais das organizações. Dessa forma, o Scrum deve ser evitado, se possível, na
adoção de práticas ágeis em uma cultura incompatível. Isso porque, pela sua própria
natureza, forçará uma transformação cultural ao invés de permitir somente a adoção de
práticas ágeis. Não há problemas em se adotar práticas do Scrum, mas é recomendável
utilizar termos ágeis mais genéricos (ex. Iteração, em vez de Sprint).
A filosofia Lean diferencia kaizen (melhoria contínua) e kaikaku (mudança radical). O
Kanban promove o kaizen, ao passo que o Scrum é uma forma de kaikaku (veja meu texto,
"O Kanban é uma droga de acesso"]. Em uma situação em que existam forças suficientes
para uma abordagem de mudança radical, o Scrum é uma ótima escolha para a
transformação, mas sua adoção em uma cultura incompatível não é recomendada.

Padrões da adoção do Agile


Outra ótima fonte para a adoção de práticas ágeis é o livro "Agile Adoption Patterns: A
Roadmap to Organizational Success" (Padrões da adoção do Agile: Um roteiro para o
sucesso organizacional), de Elssamadisy. O livro propõe a adoção de práticas com base em
sinais de dificuldade no negócio (ex.: funcionalidades não são utilizadas) e em relação ao

InfoQ Brasil Adoção e Transformação Agile 30


processo (ex.: falta de visibilidade). Cada sinal ou tipo de problema pode ser tratado com
um conjunto de práticas. Veja um exemplo:
Problema: Uma fase de amadurecimento é necessária ao final de cada ciclo de lançamento.
Práticas aplicáveis: Testes automatizados dos desenvolvedores, integração contínua, testes
funcionais, definição de pronto e entregas frequentes.
A abordagem delineada aqui é inteiramente relacionada a práticas ágeis — perfeita para
uma adoção do Agile em uma cultura incompatível.

Tornando-se Agile em um mundo imperfeito


O livro “Becoming Agile in an Imperfect World” (Tornando-se ágil em um mundo
imperfeito), por Smith e Sidky, oferece muitos conselhos práticos sobre a adoção do Agile.
Os autores partem da premissa de que muitas empresas não estão prontas para o Agile em
várias dimensões: ferramentas, cultura, gerência de projetos, processos de software e
ambiente físico. Defendem que o melhor é se tornar o mais ágil possível dadas as
limitações ambientais do momento e as necessidades mais importantes.
Apesar de reconhecerem que o Agile representa uma mudança na forma de pensar, os
autores apoiam a adoção incremental orientada a práticas, que é conveniente para a
adoção de práticas ágeis em uma cultura incompatível.

Estudo de Caso: Grande organização financeira


Considere a seguinte situação: um projeto "ágil" fora de controle em uma grande empresa
de serviços financeiros. As pessoas
trabalhando no projeto estão localizadas em
diversas partes da América do Norte; a
empresa mantém várias localidades off-
shore, reporte matricial cruzado e uma
cultura de controle/competência. O Agile
era visto como uma forma de "se conseguir
que as coisas fossem feitas"e não havia
nenhum apoio organizacional para uma
mudança de mentalidade ou para dar mais
autonomia às pessoas.
Foi realizada uma pesquisa cultural cujo
resultado é mostrado ao lado. Vale reparar
que durante um grupo de discussão de
cultura, tornou-se claro que a cultura de competência era dominante, tendo-se a cultura de
controle como secundária.
No passado (sem a minha compreensão da cultura), certamente tentaria encontrar
maneiras de ajudar o cliente a tornar-se mais ágil ou a realizar mudanças organizacionais.
E os resultados provavelmente teriam sido desastrosos. Trabalhei como coach, em uma
empresa de telefonia, onde um cenário semelhante surgiu. Nessa ocasião, que infelizmente
não foi a única, acabei contribuindo para o fracasso do Agile ao propor a mentalidade ágil.

InfoQ Brasil Adoção e Transformação Agile 31


Buscando ter maior sucesso, apliquei a adoção de práticas contextualizadas e voltadas à
solução das dificuldades atuais na organização — algumas eram ágeis, outras nem tanto.
Um problema era que ninguém sabia qual escopo poderia ser concluído até a data de
entrega. As práticas ágeis adotadas foram: conversa cara a cara por meio de um workshop
de três dias para "ajuste" do projeto. Outra foi um gráfico de burndown, estilo Scrum, de
seis semanas até a entrega. (Vale frisar que, com seis semanas apenas, as iterações foram
abandonadas, pois pareciam não entregar os benefícios de costume.) Um exemplo de
prática não-ágil foi a utilização da Pesquisa Gallup de engajamento dos empregados para
medir o desempenho da unidade de negócio.
Após um processo intensivo de planejamento estratégico utilizando a Técnica A3 tornou-
se claro que impedimentos organizacionais, tais como estratégia geográfica/local e
reportes matriciais, dificultariam muito sair de uma cultura de controle e competência, ou
mesmo montar equipes que pudessem apoiar o processo de mudança. O ambiente era tão
restritivo que qualquer coisa além da adoção de práticas ágeis não era factível naquele
momento.

Adoção e transformação em uma cultura compatível


Nessa seção iremos analisar o que significa adotar o Agile ou transformar para o Agile em
uma cultura compatível (que apoie a mudança), na qual as culturas dominantes são a de
colaboração e a de cultivo, ou talvez a de competência para uma adoção voltada ao XP.
Apesar de as ideias e abordagens serem apropriadas para o Kanban ou o Artesanato de
Software, o Agile será utilizado para ilustrar as ideias principais dessa seção.
Como já vimos, o modelo Schneider oferece uma boa visão para a validação da cultura
organizacional. Uma abordagem ingênua seria confirmar um alinhamento cultural de uma
organização e dar prosseguimento a uma adoção simples das práticas ágeis, considerando
que a mentalidade ágil é fortemente apoiada pela cultura. Infelizmente, a situação é mais
complexa que isso. O modelo Schneider limita-se a ajudar a entender em que cenário a
organização se encontra, sem fornecer orientações adicionais.
No livro "Organizational Culture and Leadership" (Cultura organizacional e liderança),
Schein argumenta que "devemos evitar os modelos superficiais de cultura e se apoiar
sobre modelos antropológicos mais profundos e complexos.". São citadas no livro diversas
dimensões da cultura, como costumes, tradições, normas do grupo, valores adotados,
filosofia formal, regras do jogo, barreiras culturais etc.
Além disso, a cultura de um grupo é o conjunto das visões individuais, de forma que
geralmente haverá pessoas que não se adaptam à cultura geral. O Agile tende a fazer essas
discrepâncias muito visíveis e promove comportamentos como a colaboração e a
visibilidade.
Está claro que mesmo que se esteja trabalhando com o Agile em uma cultura compatível,
pode acontecer que haja necessidade de algum nível de transformação individual ou de
grupo. Iremos explorar tais abordagens para ressaltar seus benefícios e desafios.

InfoQ Brasil Adoção e Transformação Agile 32


Lidere com o Manifesto Ágil e o Scrum
Ao se trabalhar com uma cultura já alinhada com os valores ágeis, é útil utilizar os valores
e princípios do Manifesto Ágil como pilar para a iniciativa de mudança. Quando as
pessoas estão focadas no objetivo da mudança (o porquê), evitam distrações nos detalhes
do processo (o que e o como).
O Scrum funciona bem nessa situação, já que é concebido como tecnologia de
transformação radical. O enfoque em equipes autônomas e auto-organizadas é
particularmente poderoso ao se mudar para uma mentalidade ágil.

Mudança destemida
O livro "Fearless Change: Patterns for Introducing New Ideas" (Mudança destemida:
Padrões para introdução de novas ideias), de Manns e Rising, oferece uma grande
variedade de técnicas e dicas para a adoção de novas ideias em uma organização. A
imagem a seguir, de Mihai Iancu, mostra padrões que podem ser aplicados para dar apoio
à adoção de uma nova tecnologia ou ideia. Tenho utilizado esses padrões e têm sido muito
úteis — especialmente quando alguém está se sentido sem saída e em busca de alguma
ideia. Os padrões foram incluídos no final da escala de adoção, pois o objetivo é introduzir
novas ideias, não transformar a cultura organizacional.

(Para obter uma imagem maior, veja o original.)


Veja também o jogo Fearless Journey (jornada destemida), criado por Deb Harmann para
ajudar no aprendizado e aplicação desses padrões.

InfoQ Brasil Adoção e Transformação Agile 33


A técnica de Mudança Destemida inclui ferramentas para auxiliar em uma iniciativa de
mudanças, sendo também apropriada para apoiar a adoção do Agile.

Inspecione e adapte com uma equipe de transição empresarial


O livro "The Enterprise and Scrum" (A Empresa/Corporação e o Scrum), de Schwaber,
descreve como realizar uma "transição" (não uma transformação) para o Scrum. Observe
que esta abordagem não deixa claro se trata de uma adoção ou de uma transformação. Os
passos principais são descritos dessa forma:
• Crie uma equipe de transição empresarial — uma equipe Scrum responsável pela
transição da organização para o Scrum.
• Crie um backlog de transição para a empresa.
• As equipes de transição realizam o Scrum, inspecionando e adaptando a transição
para alcançarem o sucesso.
Embora reconheça que o Scrum requer uma nova Cultura Empresarial além de enorme
esforço para executá-lo, o livro não passa informações específicas de como fazer para que
isso aconteça. Pode-se inclusive fazer uma observação simplista de que tudo o que
precisamos fazer é "inspecionar e adaptar" nosso caminho para o sucesso. Para minha
surpresa, este é o padrão mais comumente aplicado pela comunidade. Veja também o
livro "A CIO’s Playbook for Adopting the Scrum Method of Achieving Software Agility"
(Um guia dos CIOs para Adoção do método Scrum para obtenção da agililidade no
desenvolvimento de software), de Schwaber, Leffingwell e Smits.
É interessante notar o uso da palavra transição que, como observado anteriormente, é
ambígua em relação à adoção e transformação. A imprecisão do termo é uma fonte grande
de confusão na comunidade de coaching do Agile.

Quando utilizar Inspeção e Adaptação


Inspeção e adaptação com uma equipe de transição empresarial é uma abordagem
razoável na adoção do Agile, em situações muito simples e diretas. Em casos onde o
esforço para mudanças seja maior, uma abordagem transformacional, mais poderosa, deve
ser considerada.
O ADAPT é o modelo de adoção do Scrum proposto por Mike Cohn:
• Atenção/Consciência — Ter consciência de que o processo atual não está
produzindo resultados aceitáveis.
• Desejo — de adotar Scrum como uma forma de tratar os problemas atuais.
• Aptidão — Capacidade de ter sucesso com Scrum.
• Promoção — do Scrum por meio do compartilhamento de experiências, permitindo
o aprendizado e possibilitando que o sucesso seja visto por outros.
• Transferência — das implicações do uso de Scrum em toda a empresa.
Veja o livro de Mike Cohn ou sua apresentação para mais detalhes.

InfoQ Brasil Adoção e Transformação Agile 34


É interessante observar que o modelo se move na direção da transformação, mas não
totalmente nesse sentido. Veja, por exemplo, como isso se compara a um modelo completo
de transformação como o modelo Kotter, no qual "desejo" é substituído por um "sentido
de urgência", sendo este último um critério muito mais exigente. Pode-se ter consciência e
vontade de perder peso, por exemplo, mas o esforço pode ser considerado tão grande que
não haja a sensação de urgência necessária.
Uma ideia que está alinhada com a transformação é o reconhecimento de que a
transformação é sobre indivíduos: "Todos os indivíduos terão de percorrer as fases de
consciência, desejo e a fase de capacidade em ter sucesso com Scrum". Por outro lado, os
mecanismos básicos para a execução desta mudança estão alinhados com o que foi
descrito anteriormente em "Inspeção e adaptação com uma equipe de transição
empresarial".
O ADAPT pode ser visto como um complemento para o modelo de inspeção e adaptação,
que oferece algumas orientações em torno de como alcançar o alinhamento organizacional
na mudança para o Agile. É por essa razão que é disposto mais à direita (na direção da
transformação) no diagrama de visão geral.

Quando usar o ADAPT


O ADAPT é adequado para cenários de adoção do Agile em que o esforço necessário para
mudar para uma mentalidade ágil é relativamente baixo. Esforços de mudança
significativos se beneficiariam de uma abordagem mais explícita de transformação.

Containers, Diferenças e Trocas

Containers, Diferenças e Trocas (CDE), defendido por Olson e Eoyang, é um modelo para
apoiar o pensamento sobre como
efetuar mudanças em um sistema
complexo. Não é propriamente um
modelo de adoção, mas sim uma
abordagem para efetuar mudanças
nas organizações. O CDE é um
componente central em uma
abordagem que utiliza o
pensamento da complexidade para
mudança organizacional.

InfoQ Brasil Adoção e Transformação Agile 35


O CDE é uma forma de entender o contexto de uma equipe ou de um grupo, destacando
maneiras de efetivar as mudanças. Uma equipe, por exemplo, é um Container poderoso
para a organização de pessoas. O mesmo pode ser dito do ambiente físico (ex.: a sala da
equipe). As Trocas (Exchanges) são pontos de interação entre os containers: podem ser
emails ou transações financeiras. As Diferenças (ou diferenciais), como o poder ou
conhecimento técnico, são fundamentais para entender o alinhamento e a diversidade.
Esther Derby escreveu um excelente post e realizou uma apresentação em vídeo sobre o
CDE, chamado Alterando Padrões Organizacionais. O CDE também é discutido no livro
Succeeding with Agile, de Cohn, como um amplificador dos esforços de mudança ágil.

Quando utilizar o CDE


O CDE ajuda a pensar sobre como influenciar um sistema. Considere a utilização do CDE
como ferramenta de apoio para o tratamento da complexidade e para uma abordagem
emergente para a mudança.

O framework Cynefin
O Cynefin (lê-se Quenévim) é uma framework que reconhece as diferenças nas relações de
causa e consequência existentes entre os tipos de sistema e oferece novas abordagens para
a tomada de decisões em ambientes sociais complexos. Alguns argumentam que o modelo
Cynefin pode ser utilizado para auxiliar na adoção do Agile; outros o utilizam como
modelo de análise para chegar a um entendimento compartilhado do tipo de ambiente,
para que a abordagem mais apropriada possa ser escolhida.
O modelo Cynefin descreve cinco domínios distintos: Simples, Complicado,
Complexo, Caótico e Sem Ordem (a parte escura no centro do diagrama). Os primeiros
quatro estão listados em ordem decrescente nas relações de causa e consequência
(causalidade), sendo que o domínio "sem ordem" é um espaço humano no qual
simplesmente não sabemos com qual tipo de sistema estamos trabalhando.
Em um domínio Simples a causa está diretamente conectada com sua consequência, ao
passo que em um domínio Caótico, não existem padrões e quaisquer relações de causa e
consequência são pouquíssimo ou nada claras. Consideraremos a seguir os domínios
Complicado e Complexo, pois são os mais relevantes ao se trabalhar com organizações.
Em ambientes complexos, as causas podem ser entendidas após seu acontecimento, de
forma que uma abordagem adaptativa é apropriada.
As implicações para a adoção do Agile ou para a transformação para o Agile são claras —
argumenta-se que muitos ambientes organizacionais são complexos. Portanto, a
abordagem de transformação precisa refletir essa realidade ou irá fracassar. Em um
ambiente complexo, não se sabe quais ações levarão ao resultado desejado; ao invés disso,
precisamos avaliar o ambiente, sentir o resultado da ação e escolher a resposta mais
adequada. O modelo conceitual implica que o ambiente pode oferecer muito menos
clareza se comparado a um backlog para transição empresarial.
Alguns aspectos dos contextos organizacionais são simplesmente complicados, sendo
passíveis de análise. O Pensamento Sistêmico é um exemplo de prática que requer um

InfoQ Brasil Adoção e Transformação Agile 36


ambiente complicado para funcionar (veja a obra de Senge). Uma ferramenta
particularmente útil de análise são os diagramas de causa-e-consequência (Kniberg).
Como parte do meu processo A3, utilizei os diagramas de causa-e-consequência para
gerar análises significativas e utilizá-las como base para geração de contramedidas.
John McFadyen, um dos defensores do modelo Cynefin, sugere que os contextos
organizacionais são normalmente dependentes de pessoas e que, sendo humanos, querem
tornar tudo que tocam em algo complexo. Apesar disso, muitos preferem agir como se
estivessem em um ambiente "apenas"complicado, por terem tendência de tomar atitudes
mais adequadas a esse tipo de ambiente.
O modelo Cynefin oferece uma linguagem para entender e raciocinar sobre o tipo de
ambiente no qual se está inserido. Um vídeo curto explica o modelo Cynefin, assim como
uma apresentação sobre sua utilidade. Um exemplo é o caso relacionado a Sistemas
Complexos Adaptativos (de Schenk). Se estiver interessado em experimentar o modelo
Cynefin, considere experimentar o jogo criado com esse propósito, que faz uso de peças de
Lego.

Quando utilizar o modelo Cynefin


O modelo Cynefin ajuda a pensar sobre a relação de causa e consequência em um sistema,
e a escolher uma abordagem cognitiva adequada para mudar a forma de trabalhar. Não é
uma abordagem de adoção ou de transformação, mas sim uma ferramenta para ajudar
agentes a entender suas posturas e abordagens. Dessa forma, é complementar a outras
abordagens.

Estudo de caso da adoção do Agile em culturas


compatíveis
O propósito desse estudo de caso é ilustrar
que o alinhamento de uma cultura com as da
colaboração e do cultivo não é suficiente para
determinar sua compatibilidade e seu sucesso.
A organização em estudo é um grupo de
dimensões mundiais com práticas
independentes. Os resultados da pesquisa
sobre cultura exibidos ao lado mostram essa
organização como candidata razoável para
uma transformação para o Agile. Os
resultados dessas pesquisas foram confirmadas por um workshop de grupo.
Fui convidado para "otimizar" uma equipe que já praticava Scrum e a ajudar duas outras
equipes pequenas a adotar práticas ágeis.
Parte da fase de avaliação/planejamento, realizada antes do treinamento, deixou claro que
havia uma forte cultura de heroísmo, e que o trabalho individual era valorizado e
favorecido pela alta gerência.
Nesse cenário, o Scrum não seria uma boa escolha, posto que é muito mais disciplinado do
que o ambiente se mostrava. Como resultado dessas e de outras análises, a equipe de

InfoQ Brasil Adoção e Transformação Agile 37


gestão decidiu usar parte do tempo do treinamento para apresentar o Kanban, além do
Scrum. Assim, decidimos deixar a cargo das equipes adotarem o Scrum, o Kanban ou uma
mistura de ambos.
Ao final do treinamento, as três equipes elegeram o Kanban no lugar do Scrum. É
interessante destacar que as mesmas equipes também adotaram o uso de histórias de
usuário, estimativas e velocidade para gerenciar a comunicação com os stakeholders e
para planejar e acompanhar o lançamento das versões. Um workshop sobre programação
em pares também foi solicitado para apoiar as metas de transferência de conhecimento.
Apenas uma equipe possuía um Product Owner. Nenhuma outra estava pronta para
investir em um ScrumMaster ou coach de processos.

Transformação para o Agile

O verbo transformar significa,segundo o Dicionário Merriam-Webster: Alterar a


composição ou estrutura; Alterar a forma externa ou a aparência; Mudar características ou
estado.
A imagem de uma lagarta se transformando em uma borboleta é comumente utilizada
para ilustrar as profundas mudanças que ocorrem em uma transformação.
No contexto do modelo cultural Schneider, uma transformação seria uma mudança a partir
de uma cultura fundamental para outra. Em termos ágeis, a transformação é uma mudança
para uma mentalidade ágil — que implica em uma mudança de cultura.

É possível uma transformação para o Agile?


Acredito que o Agile sozinho não é suficiente para induzir uma transformação
organizacional. Uma ideia relacionada é que as abordagens e a adoção do Agile discutidas
nas seções anteriores são insuficientes para a transformação organizacional.

InfoQ Brasil Adoção e Transformação Agile 38


Kotter e Heskett (veja as referências) documentam dez grandes empresas que
transformaram suas culturas corporativas. Isso indica que uma mudança cultural é difícil,
mas possível.
Existem casos documentados sobre transformação para o Agile? Escuto pessoas falarem
sobre o Agile ou o Kanban terem levado a mudanças culturais. No entanto, até a escrita
deste texto, não tenho conhecimento de estudos de casos que apóiem qualquer uma dessas
hipóteses.
Algumas pessoas podem citar o sucesso de empresas como a SalesForce.com como
exemplo de como mudou sua cultura. Por outro lado, o artigo "Seis erros comuns que a
Salesforce não cometeu", de Denning, declara que "a liderança viu a transformação não
tanto como abordagem completamente nova, mas sim como um retorno aos valores
essenciais da empresa".
Portanto, o caso da SalesForce já não serviria como exemplo, uma vez que os valores na
equipe de liderança não mudaram. Parece que o Agile, nesse caso, foi usado para tratar
um desvio na cultura causado pelo crescimento e pela introdução da média gestão.
Lembro-me de uma história semelhante sobre voltar à cultura original com o Yahoo, que
também fez uma transição empresarial para o Scrum.
Andrea Tomasini da Agile 42 e Hendrik Esser da Ericsson apresentaram um estudo de
caso no Scrum Gathering 2012, em Atlanta, no qual o Scrum foi utilizado para guiar uma
unidade de negócios de 2 mil pessoas a encontrarem seu caminho depois de abandonarem
um modelo hierárquico e reportes matriciais.
O Scrum foi fundamental no aumento da sensibilização e em mostrar o que era possível,
ao mesmo tempo que executava uma transformação para o Agile. A administração estava
sofrendo demais com condições voláteis de mercado, reclamações, insatisfações e
frustrações dos funcionários para considerar mudanças. Assim, uma parte fundamental da
transformação foi quando a equipe de gestão parou de dar enfoque às preocupações
operacionais, para passar seis meses trabalhando sobre a remodelação do futuro da
empresa.
Parece que esse tipo de liderança de "atravessar o oceano e queimar os barcos" é essencial
para uma transformação bem sucedida. O Scrum atuou como catalisador para a mudança
nesse caso, mas não foi o processo de mudança em si.

Cirurgia Radical
A NUMMI (New United Motor Manufacturing) é um empreendimento conjunto no qual a
Toyota e a GM trabalharam para mudar a cultura em uma das fábricas da GM. Observe
esses trechos sobre o resultado e as modificações feitas:
• "Levamos a qualidade da fábrica da GM de pior para a melhor — não apenas de
ruim para ótimo, foi do pior possível para o melhor — em apenas um ano".
• "Sempre saliento que a força de trabalho da NUMMI foi a mesma que havia antes. E
apesar de os trabalhadores serem os mesmos, todos os gerentes eram novos. Podiam
ser da GM, da Toyota ou mesmo contratados de fora, mas eram novatos com
relação à NUMMI."

InfoQ Brasil Adoção e Transformação Agile 39


Nesse caso, a mudança cultural foi obtida com a troca de toda a equipe de gestão, o que,
em muitos contextos, não é factível nem desejável. Trata-se de algo consistente com os
relatórios que mostram a resistência da média gestão como um dos principais obstáculos
para a transformação para o Agile.

Transformação — uma pessoa de cada vez


Qual o significado de uma transformação para uma empresa?
Vamos tomar emprestada a definição fornecida por Jurgen Appelo do que é uma
organização: um conjunto de redes de aprendizado compostas por pessoas criando valor.
Uma organização está limitada à transformação que as pessoas estão dispostas a passar.
Cada pessoa em uma organização necessita vivenciar a transformação em seu próprio
ritmo. Quando uma organização exige mudanças em velocidade maior do que aquela que
os indivíduos conseguem entregar, isso resultará na mudança do quadro de pessoas, ou
seja, algumas delas abandonam e outras se juntam ao grupo.
Penso no Agile, ou em qualquer outro sistema de cultura organizacional, como um vírus
que se espalha e contamina as pessoas. Quando realizo o coaching com equipes ágeis,
posso perceber quando as pessoas finalmente entenderam e internalizaram o pensamento,
passando a terem uma mentalidade ágil. A resistência ao vírus do Agile (e à mudança) é
diferente de organização para organização, e também varia de indivíduo para indivíduo.

Transformações acidentais para o Agile são prejudiciais às empresas


Antes de avançar, é importante frisar que a maior parte das empresas não quer se
transformar. Ainda não tive a oportunidade de trabalhar para uma empresa que
entendesse de verdade o que era uma transformação e ainda assim a quisesse. Durante o
ano passado, quando esclareci aos praticantes do Agile o que significava e o que
representava o termo transformação, apenas empresas muito pequenas com lideranças
visionárias ficaram interessadas. Normalmente, os líderes e gerentes gostam de ver seus
problemas resolvidos com o menor esforço e risco possíveis, mas transformações exigem
esforços monumentais e riscos significativos.
Imagine o típico gerente que gostaria de ver o Scrum adotado para melhorar os processos
de software de sua equipe. Ele está provavelmente pensando no Scrum como processo ou
framework, e não como sistema de valores e uma nova mentalidade. É pouco provável
que esteja ciente de que o Scrum é uma forma radical de mudança, que exige apoio
significativo da gerência para que não fracasse.
Ainda mais alarmante é que muitos praticantes do Agile/Scrum e coaches ainda não estão
conscientes da distância entre o que é entendido sobre o Scrum (um processo) e o que de
fato o Scrum representa (uma mudança radical). Uma discussão clara sobre cultura e as
ferramentas apresentadas nesste livro poderia suprir essa lacuna e diminuir o
desentendimento.

Muitos agentes de mudança agem com um nível de habilidade "acidental"


Com base na minha investigação sobre os fracassos do Agile, é nítido que, como
comunidade, não temos certeza suficiente acerca do que significa uma adoção do Agile ou
da transformação para o Agile. Sem dúvida, muitos praticantes possuem um

InfoQ Brasil Adoção e Transformação Agile 40


entendimento razoável sobre a mecânica, e ainda menos sobre a mentalidade do Agile e
do Scrum. É alarmante a falta de um entendimento sobre a diferença entre adoção e
transformação. Veja o diagrama a seguir.

Vamos considerar a questão do nível de habilidade que os agentes de mudança do Agile


têm em "ajudar as organizações com o Agile". Pode-se argumentar que muitos agentes de
mudanca estão apenas no nível Shu do Shu-Ha-Ri (um conceito vindo das artes marciais
que trata dos passos para dominar conhecimentos e técnicas). Mas há um passo anterior
ao Shu — em que alguém não sabe ou não tem interesse sobre uma habilidade em
particular — chamado de acidental na terminologia de Chapman e de incompetência
inconsciente no Modelo de Competência Consciente.
Afirmo que a ampla maioria dos agentes de mudança do Agile está no nível acidental, e as
principais razões são as seguintes:
• Fracasso no entendimento do Agile como sistema cultural e de valores
• Fracasso no entendimento do poder de mudança radical do Agile em geral e do
Scrum, em particular
• Falta de entendimento da diferença entre adoção e transformação
• Ausência de uma estrutura para adoção ou transformação
• Pouco ou nenhum alinhamento com as metas e objetivos da gestão
A curva em vermelho no gráfico anterior ilustra o nível atual de habilidade na adoção do
Agile ou na transformação para o Agile. Note que a linha não é exata, pois se baseia
apenas em informação qualitativa para dar apoio a essa conclusão. A maior parte da
comunidade não está no nível de "incompetência inconsciente"; apenas alguns poucos
estão fora desse grupo.

InfoQ Brasil Adoção e Transformação Agile 41


Apesar de existirem alguns especialistas compartilhando ideias valiosas, não há
mensagem coerente com a qual as pessoas possam concordar. Precisamos mudar a curva
para a direita.
Acabou o tempo em que nós, como comunidade, podíamos alegar que o Agile era a
melhor coisa que já aconteceu e implementá-lo em qualquer empresa. Os dados sobre os
fracassos não dão apoio a essa ideia, então vamos agora considerar alguns modelos para
realmente ajudar na transformação para o Agile.

O modelo Kotter para mudanças organizacionais


Uma verdadeira transformação de uma organização exige o empenho consistente,
mantido por um longo período de tempo. Kotter apresenta oito passos que devem
acontecer em sequência para se estabelecer uma mudança positiva, real e duradoura. Esses
passos têm sido observados em uma grande quantidade de empresas nos últimos vinte
anos:
• Estabelecer um senso de urgência
• Formar um grupo de orientação
poderoso
• Criar uma visão
• Comunicar a visão
• Dar poder às pessoas para agir sobre a
visão
• Planejar e criar vitórias de curto prazo
• Consolidar as melhorias e produzir mais mudanças
• Institucionalizar novas abordagens
O modelo é poderoso, mas difícil de executar. Por exemplo, o critério proposto para o
senso de urgência é que 75% da gerência acredite verdadeiramente que a situação atual é
inaceitável. Pela minha experiência, a gerência pode até querer e acreditar no Agile, mas
fica bem longe de atender a esse critério. Os praticantes do Agile sofrem ao compreender
totalmente esse "critério mínimo", pois sabem que as empresas para as quais trabalham
estão longe de atingir tal ponto. A falta de atendimento desse critério ajuda a explicar os
altos níveis de fracasso vividos até o momento.
Vamos pensar em um objetivo pessoal, como fazer exercícios físicos. Pode-se querer cuidar
do corpo, sabendo-se que é uma boa decisão para a saúde. É sabido que você terá mais
energia, que não sofrerá os impactos negativos do sedentarismo, mas tudo isso não será
suficiente para tirar alguém do sofá para a academia. Para melhorar a saúde, é necessário
perceber que a situação atual não é aceitável e assim se comprometer a investir de forma
contínua na saúde.
Outro aspecto essencial do modelo é que não é possível ter progresso de verdade, a não
ser que cada passo seja concluído na sequência proposta. Assim, sem um senso de
urgência, um esforço de mudança está fadado ao fracasso. Para saber mais, o livro

InfoQ Brasil Adoção e Transformação Agile 42


"Leading Change" de Kotter é uma excelente fonte. Outra fonte interessante é de Olivier
Lafontan, que criou baralhos para implementação do modelo de Kotter.
A implicação desse modelo sobre a transformação para o Agile é surpreendente. Indica
que deve haver um esforço de mudança explícito e bem apoiado para se obter sucesso.
Muitas das sugestões mencionadas precisam de "forte apoio gerencial", mas fazer as
pessoas sentirem a urgência é um requisito muito mais claro e estimulante.
Em meu treinamento CSM em 2004, Ken Schwaber citou empresas que estavam em
situações desesperadoras (em termos de sobrevivência) como boas candidatas à adoção do
Scrum, uma vez que não tinham nada a perder. Fica claro, em tais situações, que o
primeiro passo – um senso de urgência – estaria plenamente satisfeito. Infelizmente, é
comum ver a "adoção" do Scrum acontecer em empresas sem esse senso de urgência.
Em minha experiência, muitos agentes de mudança do Agile realizaram um mau serviço
ao, não intencionalmente, levar adiante uma transformação sem o completo entendimento e
aceitação das pessoas sobre as consequências organizacionais. Acredito que a quase totalidade
dos agentes de mudança do Agile estão buscando fazer um bem ao mundo.
Eu mesmo, em diversas ocasiões, quis que um cliente fosse totalmente para o Agile para
que as pessoas fossem empoderadas e pudessem produzir excelentes resultados, mas era
meu desejo e sonho, não o dos clientes. A desconexão entre as boas intenções e as
transformações acidentais ajudam a entender uma das causas raízes de muitos fracassos
que vemos com as transformações para o Agile.

Liderança de transformação
Edgar Schein fala sobre as maneiras chave que líderes incorporam uma cultura em suas
organizações [Schein]. Veja a seguir os principais mecanismos para incorporação, pelo
modelo de Schein:
• O que os líderes prestam atenção, medem, e controlam regularmente
• Como os líderes reagem a incidentes críticos e crises organizacionais
• Como os líderes alocam os recursos
• Como os líderes discutem a modelagem de papéis, o ensino e o treinamento
• Como os líderes distribuem as recompensas e o status
• Como os líderes recrutam, selecionam, promovem e demitem
É possível para um líder, em qualquer nível gerencial hierárquico, introduzir
transformação em seu espaço de controle. É crítico que os líderes de transformação deixem
claro a todos no sistema que precisarão mudar seus comportamentos ou deixar a empresa
ou o departamento para que a transformação ocorra.
"O importante no Agile são as pessoas e, portanto, tendem a ser o principal obstáculo.
Precisaremos ter uma conversa séria se quisermos realmente avançar para o Agile."
– Johnny Scarborough
Estudo de caso: Em uma grande empresa financeira, logo no meu primeiro dia de
trabalho, tive uma conversa franca com o VP que havia me contratado. Argumentei que a

InfoQ Brasil Adoção e Transformação Agile 43


equipe com a qual iria trabalhar era um sistema complexo e que o próprio VP era parte
desse sistema. Era importante lhe dar feedback direto sobre como suas ações poderiam
apoiar ou não a equipe. O VP concordou e no dia seguinte precisei testá-lo, se saindo
muito bem, e, assim, desenvolvemos uma ótima relação de trabalho. Por fim, o VP estava
realmente pronto para apoiar o Agile, mas a organização ainda não.

Os líderes ágeis dão o exemplo


Jon Stahl relata uma abordagem chamada "Agile de cima para baixo: Executivos e
Lideranças vivenciando o Agile" [Stahl], uma abordagem de como incubar lideranças de
transformação.
Os líderes dão o exemplo ao:
• Viverem os valores
• Liderarem por exemplo
• Buscarem entender realmente a sua cultura
• Serem tão transparentes quanto as equipes que lideram
Antes de embarcar em uma transformação para o Agile, Jon mostra um vídeo que exibe
um ambiente altamente criativo para ilustrar a mentalidade ágil [ABC Nightline], para só
então perguntar aos executivos:
• É dessa forma que você realmente quer ser?
• Você está preparado para mudar seu próprio comportamento para apoiar isso?
• Você está pronto para servir como exemplo e agir primeiro?

Retiro Temenos de liderança


Temenos é o nome dado por Siraj Sirajuddin para um retiro intensivo que ajuda as pessoas
a entenderem suas mais profundas visões e como querem influenciar suas vidas
organizacionais, sociais e familiares. O ponto mais importante do workshop é que as
pessoas reconheçam e gostem de si mesmas como seres humanos. Uma ideia central é que
a equipe de liderança tenha como um objetivo primário a manutenção de sua própria
saúde e de seu bom funcionamento. Assim como na abordagem de John Stahl os líderes
devem "ser a mudança que eles querem ver", a principal diferença é que Temenos abre um
caminho para uma mudança de mentalidade em um período muito curto de tempo.

Outras abordagens para mudança organizacional


Não é o intuito que este livro cubra completamente todas as abordagens conhecidas sobre
mudanças organizacionais utilizadas pela comunidade ágil. Assim, esta seção servirá
como um guia de leitura muito breve para aqueles interessados em explorar mais.
• Bob Marshall criou um modelo que descreve um caminho evolutivo para
organizações, chamado de rightshifting [pdf], que visa melhorar a efetividade.
• Jurgen Appelo possui um excelente conjunto de slides e um pequeno livro sobre
"Como mudar o mundo" [Appelo]. Nele está descrito um supermodelo composto de

InfoQ Brasil Adoção e Transformação Agile 44


quatro modelos sobre 1) Interação com o sistema, 2) Cuidando das pessoas, 3)
Estimulando a rede de adoção e 4) Mudando o ambiente. Isso inclui: Plan-Do-Check-
Act (PDCA — Planejar-Fazer-Verificar-Agir) e o modelo do abismo de Moore. Vale
notar que Appelo contrasta esses modelos com outros modelos de mudança como
Fearless Change (Mudança destemida) e Switch [Heath].

InfoQ Brasil Adoção e Transformação Agile 45


Para onde ir agora?
Como comunidade, nosso entendimento do Agile e de suas implicações está em processo
de construção. Esse livro é um primeiro passo no rumo de entender os vieses culturais do
Agile, do Kanban e do Artesanato de Software. Apresentei aqui um guia para trabalhar
com sua cultura atual, assim como um framework para o entendimento de abordagens
chave para adoção e transformação.

Checklist para agentes de mudança


Checklists são comumente utilizados para evitar erros em rotinas. Segue um checklist para
a adoção do Agile ou transformação para o Agile. Esta lista serve tanto para agentes de
mudança externos quanto internos, considerando que para os agentes internos, o cliente é
o grupo que se está ajudando a adotar ou transformar.
• Sei qual problema meu cliente quer que eu resolva
• Entendo tanto as culturas dominantes quanto as secundárias, assim como as forças
impulsionadoras no ambiente do meu cliente
• Meu cliente e eu concordamos tanto sobre os objetivos quanto sobre as abordagens
— se vamos adotar práticas ou se vamos passar por uma transformação cultural.
• Estou seguindo uma abordagem explícita para a adoção/transformação
• Meu cliente tem um bom entendimento das implicações da abordagem proposta
• Meu cliente e eu concordamos sobre o escopo das pessoas incluídas e das
impactadas
• Meu cliente está totalmente dedicado a conseguir que as mudanças necessárias
aconteçam e tem o apoio organizacional necessário para ter sucesso na execução
• O alcance da influência e do controle do meu cliente é suficiente para que o sucesso
seja possível
• Meu cliente entende que ao se trabalhar com sistemas complexos, o caminho
escolhido é uma propriedade emergente que não pode ser definida de antemão.

InfoQ Brasil Adoção e Transformação Agile 46


Referências
ABC Nightline. IDEO Shopping Cart, 1999, YouTube, Web,
<http://www.youtube.com/watch?feature=player_embedded&v=M66ZU2PCIcM>.
Anderson, David. The Principles of the Kanban Method. Web. 10 Dec. 2010.
<http://agilemanagement.net/index.php/Blog/the_
principles_of_the_kanban_method>.
Appelo, Jurgen. How to Change the World (slides). Web. 2011.
<http://www.noop.nl/2011/09/how-to-change-the-world.html>
Appelo, Jurgen. How to Change the World. Lulu. eBook. 2012.
Appelo, Jurgen. Stoos Network (part 3): Core Idea. Web. 10 Jan. 2012. <http://www.noop.nl/2012/01/stoos-
network-part-3-core-idea.html>.
Beck, Don Edward., and Christopher C. Cowan. Spiral Dynamics: Mastering Values, Leadership and Change.
Oxford: Blackwell, 2006. Print.
Behrens, Pete. The Culture of Agility, Web. 2011, <http://trailridgeconsulting.com/culture-of-
agility.html?view=slide>
Block, Peter. Flawless Consulting: A Guide to Getting Your Expertise Used. San Francisco: Jossey-Bass/Pfeiffer,
2000. Print
Buckingham, Marcus and Coffman, Curt. First, Break All the Rules, What the World's Greatest Managers Do.
Simon & Schuster,, 1999. Print. <http://www.studergroup.com/newsletter/Vol1_
Issue1/gallups12questions.htm>.
Burrows, Mike. Kanban and the Twelve Principles of Agile Software. Positive Incline. Web. 21 Jun. 2010.
<http://positiveincline.com/?p=727>.
CognitiveEdge. “The Cynefin Framework.” YouTube. YouTube, 11 July 2010. Web. 09 Mar. 2012.
<http://www.youtube.com/watch?v=N7oz366X0-8>.
Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Upper Saddle River, NJ: Addison-
Wesley, 2010. Print.
Cohn, Mike. ADAPTing to Agile for Continued Success (Keynote). Web. 2010.
<http://www.mountaingoatsoftware.com/
presentations/137-adapting-to-agile-for-continued-success-keynote>.
Cottemeyer, Mike. Untangling Adoption and Transformation. Web. January. 2011.
<http://www.leadingagile.com/2011/01/untangling-adoption-and-transformation>.
Denning, Steve. “Six Common Mistakes that Salesforce.com Didn’t Make.” Web. 18 April. 2011.
<http://www.forbes.com/sites/stevedenning/2011/04/18/six-common-mistakes-that-salesforce-
com-didnt-make/>.
Derby, Esther. “Shifting Organizational Patterns.” Web. March. 2011.
<http://www.estherderby.com/2011/03/shifting-organizational-patterns.html>.
Elssamadisy, Amr. Agile Adoption Patterns: A Roadmap to Organizational Success. Upper Saddle River, NJ:
Addison-Wesley, 2009. Print.
Fowler, Martin. “SemanticDiffusion.” Web. 14 Dec. 2006.
<http://martinfowler.com/bliki/SemanticDiffusion.html>.
Gat, Israel. “How We Do Things Around Here in Order to Succeed.” Web. Aug. 2010.
<http://www.agilitrix.com/2010/08/how-we-do-things-around-here-in-order-to-succeed/>.
Hartmann, Bob. “Doing Agile Isn’t The Same As Being Agile.” SlideShare. Web. 12 Feb. 2010.
<http://www.slideshare.net/lazygolfer/doing-agile-isnt-the-same-as-being-agile>.
Hartmann, Deborah. Fearless Journey. <http://fearlessjourney.info/>.
Heath, Chip and Heath, Dan. Switch: How to Change Things When Change Is Hard. 2010. Print.

InfoQ Brasil Adoção e Transformação Agile 47


Iancu, Mihai, Web. <http://agilitrix.com/wp-content/uploads/2010/03/
Fearless-Change-Mindmap-by-Mihai-Iancu.jpg>.
Kotter, John and Heskett, James. Corporate Culture and Performance. 1992. Print.
Kotter, John P. Leading Change. Boston, MA: Harvard Business School, 1996. Print.
Kniberg, Henrik. Cause-Effect Diagrams. Web. 09 Mar. 2012.
<http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000>.
Lafontan, Olivier. “Card Decks for Agile Transitions.” Web. 08 June. 2010.
<http://leanpizza.net/?page_id=63>.
“Manifesto for Agile Software Development.” Web. 2001 <http://www.agilemanifesto.org/>.
“Manifesto for Software Craftsmanship.” Web. 2009. <http://manifesto.softwarecraftsmanship.org/>.
Manns, Mary Lynn, and Linda Rising. Fearless Change: Patterns for Introducing New Ideas. Boston: Addison-
Wesley, 2005. Print.
Marshall, Bob. The Marshall Model of Organisational Evolution. Web. 2010
<http://fallingblossoms.com/opinion/content?id=1006>
Martin, Robert. “Quintessence: the Fifth Element for the Agile Manifesto.” Web. 14 Aug. 2008.
<http://blog.objectmentor.com/articles/2008/08/14/quintessence-the-fifth-element-for-the-agile-
manifesto>.
Martin, Robert. “The Land that Scrum Forgot.” Scrum Alliance. Web. 14 Dec. 2010.
<http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot>.
Mayer, Tobias. “The People’s Scrum.” Web. 06 Dec. 2009
<http://agileanarchy.wordpress.com/2009/12/06/the-peoples-scrum/>.
Mayer, Tobias. “Scrum: A New Way of Thinking.” Web. 22 Mar. 2008.
<http://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/>.
Merriam-Webster Dictionary, Web. 2012. <http://www.merriam-webster.com/dictionary/>.
Moore, Geoffrey A. Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream
Customers. New York, NY: HarperBusiness Essentials, 2002. Print.
Olson, Edwin and Eoyang, Glenda. Facilitating Organizational Change: Lessons from Complexity Science.
Jossey-Bass/Pfeiffer, 2001. Print.
Pelrine, Joseph “InfoQ.” : Dealing With the Organizational Challenges of Agile Adoption. Web. 09 Mar. 2012.
<http://www.infoq.com/presentations/Agile-Adoption-Joseph-Pelrine>.
Sahota, Michael. “A3 Technique”. Serious Problems? Use A3 Technique to Nail ‘em!
<http://agilitrix.com/2010/07/use-a3-technique-to-solve-serious-problems/>
Sahota, Michael. Kanban is a Gateway Drug. Web 2010. <http://agilitrix.com/2010/06/kanban-is-a-
gateway-drug>
Sahota, Michael. Scrum or Kanban? Yes! Web. May. 2012. <http://agilitrix.com/2010/5/scrum-or-kanban-
yes/>.
Sahota, Michael. Vacation Stealth Scrum. Web. May. 2005.
<http://www.slideshare.net/mobile/michael.sahota/vacation-stealth-scrum>.
Sahota, Michael, Workshop Results on Culture. Web. November 2011,
<http://agilitrix.com/2011/11/workshop-results-on-culture/>,
Scarborough, Johnny, 2011, Private communication
Schein, Edgar. Organizational Culture and Leadership. Print. 1996.
Schenk, Mark. The Case for Complexity. Web. 16 July. 2009.
<http://www.anecdote.com.au/archives/2009/07/the_case_for_co.html>.
Schneider, William E. The Reengineering Alternative: A Plan for Making Your Current Culture Work. Burr
Ridge, IL: Irwin Professional Pub., 1994. Print.
Schneider, William. Schneider Culture Survey. SurveyMonkey. Web.
<http://www.surveymonkey.com/s/VVNT5FB>.

InfoQ Brasil Adoção e Transformação Agile 48


Schwaber, Ken. The Enterprise and Scrum. Redmond, WA: Microsoft, 2007. Print.
Schwaber, Leffingwell and Smits: A CIO’s Playbook for Adopting the Scrum Method of Achieving Software
Agility. Web. Published 2005.
<http://www.leffingwell.org/Document_Store/CIO_Playbook_For_Adopting_Scrum_080805.pdf>.
Scotland, Karl. Thoughts on Kanban Thinking. Web. Dec. 2011.
<http://availagility.co.uk/2011/12/03/thoughts-on-kanban-thinking/>.
Scotland, Karl. Crystallising Kanban with Properties, Strategies and Techniques. Web. Aug. 2011.
<http://availagility.co.uk/2011/08/03/crystallising-kanban-with-properties-strategies-and-
techniques/>.
Senge, Peter M. The Fifth Discipline: The Art and Practice of the Learning Organization. New York:
Doubleday/Currency, 2006. Print.
Shook, John. “How NUMMI Changed Its Culture.” Lean.org. Web. 30 Sept. 2009.
<http://www.lean.org/shook/displayobject.cfm?o=1166>.
Shook, John. Managing to Learn: Using the A3 Management Process to solve problems, gain agreement,
mentor and lead. Web. July. 2010. Lean Enterprise Institute and Ocapt (in Canada).
Sirajuddin, Siraj. Private communication. 2010.
Smith, Greg, and Ahmed Sidky. Becoming Agile: --in an Imperfect World. Greenwich, CT: Manning, 2009.
Print.
Spayd, Michael. Agile & Culture: The Results. Web. 06 July. 2010.
<http://collectiveedgecoaching.com/2010/07/agile__culture>.
Stack Overflow, Is Agile Development Dead? Web. 19 Nov. 2008,
<http://stackoverflow.com/questions/301993/is-agile-development-dead>.
Stahl, Jon. Agile From the Top Down: Executives & Leadership Living Agile. SlideShare. Web. 09 Aug.
2011. <http://www.slideshare.net/LeanDog/agile-from-the-top-down>.
Thomas, Dave, “Dave Thomas Unplugged” Web. Aug. 2010. <http://agilitrix.com/2010/08/agile-2010-
keynote-by-dave-thomas>.
Tomasini, Andrea and Lewitz, Olaf. “Cynefin Lego Game.” Web. 25 Dec. 2011.
<http://www.agile42.com/blog/2011/12/25/cynefin-leg-game/>.
VersionOne, State of Agile Development Survey Results. Web. 09 Mar. 2012.
<http://www.versionone.com/state_of_agile_development_survey/11/>.
Wikimedia Foundation. “Hype Cycle.” Wikipedia. 08 March. 2012. Web.
<http://en.wikipedia.org/wiki/Hype_cycle>.

InfoQ Brasil Adoção e Transformação Agile 49


Apêndice I: visões e opiniões alternativas
Esta seção oferece um canal para as pessoas que possuem visões alternativas daquelas que
foram apresentadas neste livro.
Vale lembrar que, como Henrik levantou no prefácio, ninguém possui todas as respostas e
que devemos pensar por nós mesmos.

Cultura como contexto para a adoção e a transformação para o Agile


por Olaf Lewitz
Contexto é mais que cultura
Concordo plenamente que para "sobreviver a uma transformação para o Agile"
precisamos prestar mais atenção à cultura, ainda assim, depositar um foco quase que
exclusivo nela como o desafio mais importante em uma transformação para o Agile é
arriscado. A cultura não passa de um aspecto do contexto, o sistema com o qual
trabalhamos, outras sendo as mentalidades dominantes (ad-hoc, analítica, sinérgica,
caórdica), situação do negócio, "situação" técnica (dívidas técnicas, excelência técnica...),
situação organizacional (silos, desarticulação, …). Qual desses (a lista não está completa) é
o desafio número um para sua transformação para o Agile dependendo do seu contexto e
de seus objetivos.
O que leva a minha premissa pessoal de que o desafio número 1 é: objetivos errados.
Muitas organizações buscam se transformar ou adotar o Agile e o fazem pelos motivos
errados (custos, fazer as coisas certas), subestimar os efeitos nas pessoas quando são
emancipadas e/ou falhar logo de início em entender as razões pelas quais o Agile
funciona, e como funciona.
O Agile não é uma boa/melhor prática
O Agile é uma forma de encontrar uma solução emergente em um domínio complexo.
Trata-se de uma abordagem evolutiva para a inovação e o crescimento, respeitando as
pessoas que criam valor. Essa abordagem, caso feita de forma correta, inspira e facilita a
transformação da cultura e da mentalidade de organizações do trabalho do conhecimento.
Já a adoção de algumas (boas) práticas, como as reuniões diárias e um quadro para dar
visibilidade, pode ser vista como um catalisador, que contribui para mudar a forma como
as pessoas colaboram entre si e que ajuda a inspirar as pessoas a repensar sobre seus
ambientes de trabalho. Novas práticas irão emergir se esse processo de melhoria contínua
seguir em frente, mas algo a ressaltar é que essas práticas nunca serão iguais em duas
organizações diferentes, pois o Agile não pode ser padronizado.
Escolha do método: indicadores
Existem muitos aspectos em um sistema que podem influenciar na escolha de um dos
"sabores" do Agile (o Scrum, o Kanban, o XP, …) como um ponto de partida. Apesar de
existirem muitos fatores a se considerar, o que dou mais relevância é o modelo de
negócios para o serviço ou o produto sendo desenvolvido.

InfoQ Brasil Adoção e Transformação Agile 50


É importante ter interesse pela cultura, sentir as influências contrastantes nela
(comumente haverá uma mistura dos quatro tipos de Schneider) e encontrar possíveis
disarmonias. Como o Agile desafia o status quo, é recomendável saber o que está sendo
desafiado, pois desafiar uma cultura exige respeito a ela, não submissão.
Alguns exemplos para ilustrar minha opinião: uma cultura de Competência (o Google
vem a mente), talvez precise apenas de algo como o Scrum para inspirar as pessoas a
colaborar, já uma cultura de Controle talvez se beneficie de algo radical para realmente
provocar mudanças, ao passo que em uma cultura onde a colaboração já é uma
característica forte, o Kanban pode ser útil para visualizar e melhorar o fluxo
(identificando gargalos causados por alguma competência que ainda precisa ser
desenvolvida).
As organizações são seres multi-facetados, de forma que é preciso prestar atenção a mais
aspectos do que "apenas" à cultura dominante ou aparente.

Seu Kanban não é o meu Kanban


Karl Scotland escreveu:
Isso me fez pensar a respeito de como poderiam ser organizados os vários elementos do
pensamento Kanban.
• O Pensamento Sistêmico — provavelmente abrange todo o framework;
• Fluxo — Cultura de Controle (estar sob controle [estável] ao invés de ter controle);
• Valor — Cultura de Cultivo, mas provavelmente próximo a competência;
• Capacidade - Cultura de Competência, mas provavelmente próximo à de Cultivo;

• Estudo — Cultura de Colaboração (entender o estado atual de forma coletiva);


• Compartilhamento — Cultura de Colaboração (visualização é uma forma de
compartilhar conhecimento);
• Limites — Cultura de Controle (limites são meios de estabilizar um sistema);
• Senso — Cultura de Competência (como estamos agora);
• Aprendizado — Cultura de Cultivo (como podemos melhorar).
• O que, de forma interessante, nos mostra dois em cada quadrante.

O Kanban é mais que apenas Cultura de Controle


Alexei Zheglov escreve:
Discordo de uma série de pontos em relação ao conteúdo do capítulo "A cultura Kanban é
alinhada com Controle". Vejo o diagrama da cultura Kanban disposto (p. 18) de forma
bem diferente.
Acredito que “visualizar o fluxo” deva estar no quadrante de Colaboração. Os quadros
visuais são ferramentas essenciais para a colaboração e são o oposto do "visualizar" coisas

InfoQ Brasil Adoção e Transformação Agile 51


no MS Project. O Kanban visualiza o fluxo de itens de trabalho ao longo dos fluxos de
valor, o que é diferente de outras visualizações comuns a organizações voltadas ao
controle, como gráficos de organização e quadros de monitoramento de KPIs.
O autor, Michael Sahota, disse concordar parcialmente, argumentando que no diagrama,
estaria na extremidade, próxima ao quadrante de colaboração.
Já limitar o trabalho em progresso (WIP), é o que a ciência nos diz para fazer, então associo
com o quadrante da Competência. “Peter, se você puder fazer X até o final do dia, isso
seria ótimo” acontece muito na cultura de controle. Trata-se de algo empurrado e que não
respeita os limites de WIP. Trabalhar de forma puxada e limitando WIP é o oposto. Por
ciência, estou me referindo à teoria das filas (lei de Little) e psicologia (existem efeitos
psicológicos em se limitar WIP).
O autor, Michael Sahota, diz tratar-se de um boa observação. Segundo ele, existe uma
tensão em aspectos do processo e da eficiência, de forma que atualizará o diagrama para
refletir um balanço entre estes dois.
“Tornar as políticas do processo explícitas", "processo" e "políticas" são atributos do
quadrante Controle, mas "explícito" sugere visualização e propriedade da equipe. O que
indicaria um posicionamento mais próximo à borda.
A prática de “Gerenciar fluxo”, à qual David Anderson faz referência em um mesmo
artigo do blog como “meça o fluxo”.
(http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method/).
Esse princípio também é referenciado como “meça e gerencie o fluxo.” “Medir” é uma
palavra importante aqui, porque significa medir alguma coisa de uma forma similar à
medição em um experimento científico. E então gerenciamos o fluxo baseado no que
medimos. O que me faria colocar esse princípio na extremidade ou talvez completamente
no quadrante de Competência.
O autor diz ser outra boa observação e que atualizará o diagrama para refletir isso.
De maneira geral, minha versão do diagrama da cultura Kanban seria em formato de um
L, esticando de Colaboração para Controle e depois para o quadrante da Competência —
ao invés de ficar centrado em Controle. Não muda sua conclusão geral, no entanto — O
Kanban como uma ferramenta complementar ao "tradicional" uso de métodos ágeis e do
artesanato de software.

O Kanban também é transformação


Jeff Anderson escreve:
Acredito que o Kanban tem mais chances de ser atraente para culturas de controle que o
Agile. Mas isto é um comentário sobre marketing, não sobre o que é requisitado para o
método funcionar, ou mesmo onde funciona melhor.
A maior preocupação é o fato que distribuir os principais métodos ágeis nos quadrantes
culturais pode requerer muita generalização. As organizações com as quais trabalho
parecem desafiar essa primeira opção de escolha de um quadrante, e acredito que o
Kanban, o Agile, entre outros, têm vários pedaços em sobreposição para poderem ser

InfoQ Brasil Adoção e Transformação Agile 52


dispostos em um quadrante de forma adequada. Acredito que isso pode passar pela nossa
cabeça quando aplicamos métodos ágeis sem considerar um contexto, e também tenho a
impressão de que várias pessoas nem percebem o que precisam aprender. Foi necessária
coragem da sua parte para informar que foi um bom trabalho.
Minha afirmação final é acreditar que uma transformação para o Agile é muito possível,
mas a melhor chance de sucesso é por meio de uma adoção incremental.
Minha opinião é que a cultura é um subproduto da prática e da forma como as pessoas
trabalham (entre elas, seus clientes e seus chefes). Portanto, se você quer mudar a forma de
trabalho, no final, a cultura vai acompanhar, e a transformação pode ocorrer. Trata-se,
contudo, de um processo realmente lento.
A tendência é concordar que uma mudança radical e rápida é reservada a organizações
próximas da falência, tornando este tópico não tão interessante para mim.

Scrum x Kanban
Jon Stahl escreve:
Usamos Kanban em equipes que estão tentando praticar Scrum, mas devido a essas
equipes estarem mal estruturadas, não atingem o sucesso como uma equipe auto-
organizada. O Kanban permite à equipe:
• Expor políticas que são um desperdício e precisam ser desafiadas;
• Utilizar limites e dados para validar que as pessoas possam estar em papéis errados
para apoiar um fluxo consistente;
• Garantir que a equipe é responsável por todo o processo, não apenas por sua parte.
O Kanban nos permite iniciar a aplicação do pensamento sistêmico como uma equipe
coesa, de forma a identificar e remover desperdícios. Ver todo o sistema ajuda a reduzir a
necessidade de barreiras de proteção e torna a comunicação com outras equipes mais fácil.
Então, para mim, o Kanban não é tanto sobre comando e controle quanto é para o
entendimento do fluxo como uma equipe. Uma vez que é entendido o valor das partes e
de como o sistema funciona, a equipe pode mover de forma adaptativa para um processo
melhor.

InfoQ Brasil Adoção e Transformação Agile 53


Sobre o InfoQ Brasil
O InfoQ é uma comunidade global voltada a líderes técnicos, desenvolvedores sênior e
gerentes de projetos que lideram a inovação em suas equipes. Com objetivo de disseminar
a inovação no desenvolvimento corporativo, o InfoQ tem versões em inglês, chinês,
japonês, francês e português.
O InfoQ Brasil publica palestras, entrevistas, artigos aprofundados, notícias e livros. Além
de traduções do site em inglês, o portal publica grande quantidade de conteúdo
produzido por desenvolvedores e arquitetos nacionais, assim como palestras de
importantes eventos brasileiros de desenvolvimento e arquitetura de software.
O site que mais cresce entre todos os InfoQs mundiais, o InfoQ Brasil hoje recebe
mensalmente mais de 50 mil usuários e tem 45 mil leitores cadastrados.

Conheça outros dos nossos livros


http://www.infoq.com/br/minibooks

Cadastre-se e assine nossa newsletter


http://www.infoq.com/br/reginit.action

InfoQ Brasil Adoção e Transformação Agile 54