Do Waterfall ao Scrum - Gestão Ágil de Projetos

Prévia do material em texto

DO WATERFALL AO SCRUM
 
Um guia para uma transição segura
 
 
 
 
 
Leandro da Costa Gonçalves
© Copyright 2019 por Leandro da Costa Gonçalves – Todos os
direitos reservados.
Biografia
Introdução
Capítulo 1: A Definição de Agilidade
Agile x Waterfall
Fazendo a mudança de paradigma
Agile e margem de lucro
Capítulo 2: A Avaliação de Viabilidade
Agile pode ser aplicado na minha empresa?
Definindo suas metas
Avaliando seu ambiente
Testando práticas ágeis
Capítulo 3: Obtendo Apoio
Engajando Apoiadores
Lidando com detratores
Obtendo apoio da alta gestão
Padrinho ágil
Capítulo 4: Iniciando a mudança
Selecionando o projeto correto para um piloto
Montando o time
Os papéis certos para o projeto
Preparando-se para perguntas difíceis
Definindo a visão
Capítulo 5: Fundamentos básicos do Agile
Preparação tática
Planejamento antecipado
Noções básicas de planejamento
A primeira Sprint
Planejando a Sprint
Execução da Sprint e métricas
Demos e retrospectivas
Capítulo 6: Transcendendo o Agile
Retrospectiva do projeto piloto
Inibidores Ambientais
Incentivadores ambientais
Conclusão
Referências
Biografia
 
 
Eu sou Leandro Costa, Analista De Sistemas e desenvolvedor, bacharel em Sistemas de
Informação com pós-graduação em Engenharia de Software. Trabalho a mais de 9 anos como
analista desenvolvedor back-end e sou um entusiasta apaixonado pela área. Em todos esses anos
eu acertei e errei bastante, e claro aprendi muito com esses erros.
Comecei minha carreira com manutenção de computadores, impressoras e monitores - arriscava
fuçar em tudo que tivesse um CHIP dentro. Comecei a programar em Delphi e logo depois iniciei
a faculdade onde me dediquei à aprender Java e GNU/Linux. Como desenvolvedor eu iniciei
trabalhando com Delphi, depois Java com JSF e Spring, Groovy, depois AngularJS e me
apaixonei por JavaScript. Atualmente trabalho com .NET Core e C#.
Já trabalhei em diferentes tamanhos de projetos nacionais e internacionais, em setores como
varejo, farmacêutico, atacadista, marketing, governo, ERP e fintechs. Participei de projetos Agile,
"Fake Agile", Cascata, RUP e claro me deparei com muito Extremme Go Horse e confesso que
tive que fazer algumas gambiarras ao longo da carreira.
Nos diferentes projetos em que trabalhei utilizei diversas tecnologias como Java, Spring,
Hibernate, JSF, C#, Entity Framework, ASP.NET, Groovy, Grails, JavaScript, AngularJS, Docker,
Docker Compose, MySQL, Postgree, SQL Server, Oracle dentre outras.
Em 2012 tive o prazer de criar dois cursos gratuitos de Groovy e JSF no Youtube, são eles:
 
- Curso De JavaServer Faces (JSF) Do Zero À Nuvem
- Curso Básico de Grails
 
Atualmente além de ser analista desenvolvedor de sistemas sou também instrutor na Udemy onde
desenvolvi 10 cursos. São eles:
 
- Agile desmistificado com Scrum, XP, Kanban, Spotify e Trello
- Spotify Engineering Culture Desmistificado
- Do Waterfall ao Scrum: Acerte na Mudança do Modelo de Gestão
- Trello: Gestão Otimizada de Equipes e Projetos Pessoais
- RESTFul API's do 0 à Nuvem Com ASP.NET Core 2.0 e Docker
- RESTFul API's do 0 à Nuvem Com Spring Boot 2.1.3 e Docker
- Docker do Zero à Maestria - Contêinerização Desmistificada
- Docker para Amazon AWS Implante Aplicações Java e .NET com Travis CI
- Kindle Desmistificado: Publique seu livro na Amazon
https://www.youtube.com/playlist?list=PL18bbNo7xuh9d1AyAeC77O8xRz6hPD3iJ
https://www.youtube.com/watch?v=zSe78G8n-7s&list=PL18bbNo7xuh_dvHiIjegSsbwRq9JPmZL2
https://www.udemy.com/course/agile-no-mundo-real-scrum-xp-kanban-e-spotify-desmistificados/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/spotify-engineering-culture-desmistificado/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/do-waterfall-ao-scrum-acerte-na-mudanca-do-modelo-de-gestao/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/trello-gestao-otimizada-de-equipes-e-projetos-pessoais/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/restful-apis-do-0-a-nuvem-com-aspnet-core-e-docker/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/restful-apis-do-0-a-nuvem-com-springboot-e-docker/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/docker-do-zero-a-maestria-conteinerizacao-desmistificada/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/docker-para-amazon-aws-implante-aplicacoes-java-e-net/?couponCode=ENGSOFT_ESSENCIAL_KD
https://www.udemy.com/course/kindle-desmistificado-publique-logo-seu-livro-na-amazon/?couponCode=ENGSOFT_ESSENCIAL_KD
- Organize Suas Finanças Pessoais com Excel Passo a Passo
 
Sou apaixonado por transmitir conhecimentos e contribuir para que as pessoas se desenvolvam e
alcancem o melhor de si. E me sinto muito gratificado em fazer parte da jornada de aprendizado
da vida de muitos alunos e por essa razão eu estou empenhando em dar o meu melhor entregando
conteúdos cada vez melhores e mais relevantes.
https://www.udemy.com/course/como-organizar-sua-vida-financeira-com-excel-do-zero/?couponCode=ENGSOFT_ESSENCIAL_KD
Introdução
 
 
Agile já é sem sombra de dúvidas o modelo de gestão mais comumente utilizado. E o
Scrum tornou-se o mais poderoso e popular framework de gestão ágil adotado pelas empresas
permitindo o desenvolvimento de times poderosos e que entregam resultados sólidos e eficientes.
Concebido inicialmente no mundo do desenvolvimento de software expandiu-se por diversas
outras áreas do conhecimento. E hoje existem times ágeis no marketing, na educação, no
jornalismo e até mesmo no lançamento de foguetes ou corridas de Fórmula 1.
O State Of Agile Report de 2019 mostra claramente que mais de 70% dos projetos são
tocados usando uma abordagem Ágil. Nos últimos anos deixou de ser exclusividade de empresas
como Spotify, Nubank, Twitter, Google, Facebook, dentre outras e cada vez mais tem sido
adotado por diferentes tamanhos e tipos de organização.
Neste livro, irei mostrar como você pode manipular as variáveis tempo, qualidade e
custo em um modelo de gerenciamento ágil de projetos. Este livro ajudará você a entender a
diferença entre as metodologias tradicionais como o Cascata e o modelo Ágil e o que é
necessário para uma transição bem-sucedida entre as duas. Irei fornecer dicas sobre como obter
apoio para um projeto piloto: identificando apoiadores desde o início e mantendo-os engajados
durante todo o projeto. Mostrarei também como lidar de maneira convincente com os detratores.
Posteriormente iremos lidar com o processo de escolha do projeto piloto,
selecionando a equipe certa e definindo a visão. Fornecerei também uma breve visão geral dos
frameworks ágeis para você começar. Finalmente, aprenda como realizar uma revisão
retrospectiva do piloto e identificar os pontos a serem melhorados para continuar a difundir o
Agile em toda a organização.
Capítulo 1: A Definição de Agilidade
 
 
As metodologias tradicionais são também chamadas de pesadas ou orientadas a
documentação. Elas foram muito utilizadas no passado em um contexto de desenvolvimento de
software muito diferente do atual, baseado apenas em um mainframe e terminais burros. Naquela
época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos
computadores eram limitados e não existiam modernas ferramentas de apoio ao desenvolvimento
do software, como depuradores e analisadores de código. Por isso o software era todo planejado
e documentado antes de ser implementado. Uma das metodologias tradicionais mais utilizadas até
hoje é o modelo Clássico ou Cascata (SOARES, 2004). Nesse livro iremos generalizar, por
questões de simplificação, todas essas metodologias sob o termo Waterfall.
Ao longo das últimas décadas a evolução computacional barateou e acelerou o
processo de desenvolvimento de softwares. Por outro lado, os modelos de gestão não evoluíram
na mesma velocidade. Apenas no final dos anos 80 e início dos anos 90 algo que mais tarde seria
definido como Agile começou a ser desenvolvido. No início dos anos 2000 o Agile passou
gradativamente a ser o modelo mainstream. E atualmentemais e mais empresas buscam migrar
para o modelo Ágil. Entretanto antes de virar a chave é fundamental entender os conceitos chave
de cada um deles.
 
 
Agile x Waterfall
 
 
A adoção de práticas ágeis na gestão de projetos está se tornando cada dia mais no
modelo padrão de gestão. Crescendo cerca de 10% ao ano de acordo com o State of Agile Report
(STATE OF AGILE REPORT, 2019). Diante disso algumas perguntas são inevitáveis:
 
Por que isso acontece?
Por que todos pensam que terão ganhos simplesmente mudando o modelo de gestão?
O modelo tradicional (Cascata, RUP ou processo unificado) “atendeu às
necessidades” por tantos anos por quê mudar justo agora?
 
Figura 1 – O Ciclo de Vida da Metodologia Cascata
Fonte: PRESSMAN, 2006
 
O modelo tradicional é efetivo, não há nada de errado nele, muitas empresas
continuam a usá-lo. A diferença chave entre os modelos Waterfall e Agile é forma do controle de
processos usado em cada um deles. Conforme se pode ver na Figura 1 no modelo Waterfall
procura-se controlar todo processo através de etapas bem definidas e que devem ser executadas
de modo sequencial. Onde é possível mover para a etapa seguinte somente após a conclusão e
aprovação da fase imediatamente anterior. O escopo e os requisitos são definidos no início do
projeto e depois que o desenvolvimento for iniciado não podem mais serem alterados.
Figura 2 – O Ciclo de Vida da Metodologia Scrum
Fonte: http://www.semeru.com.br/blog/o-ciclo-de-vida-do-framework-scrum/
 
A Figura 2 ilustra o ciclo de vida do Scrum, o mais popular framework Ágil. E a
diferença principal entre os dois modelos é que o escopo e as prioridades são redefinidos à cada
nova Sprint. Isso é feito para garantir que a implementação está alinhada às reais necessidades do
cliente e que está sempre entregando o máximo de valor de negócio ao seu cliente. Vamos
exemplificar imagine que sua empresa está desenvolvendo um aplicativo mobile para delivery de
comida. Como nós sabemos existem diversos aplicativos desse tipo no mercado por isso é
fundamental se diferenciar e agir tão rápido quanto possível.
 
Usando o modelo Waterfall você vai precisar:
 
1. Escrever o contrato do projeto;
2. Definir em detalhes como será o aplicativo mobile;
3. Obter aprovação;
4. Definir o calendário com precisão;
5. Obter aprovação novamente;
6. Definir o time;
7. Iniciar o desenvolvimento.
 
Além disso cada uma dessas etapas sozinha, vai levar pelo menos 30 dias cada uma.
Esse é o controle de processos claro e bem definido do modelo Waterfall. No modelo ágil seria
mais ou menos assim:
 
1. Discutir com os stakeholders do projeto;
2. Definir a visão do aplicativo mobile;
3. Definir o time;
4. Iniciar o desenvolvimento.
 
Acho que você já conseguiu perceber a principal diferença entre os dois modelos de
gestão. A sobrecarga de reuniões e “mudanças de mão” em um projeto Agile é menor. Isso faz com
que o time ganhe tempo para a execução do projeto e construção do produto propriamente dito.
Esse é um processo de controle empírico.
Seu compromisso no Agile deve ser se perguntar se o que está fazendo está agregando
valor ao negócio de seu cliente. Nesse modelo de gestão você deve inspecionar e adaptar o seu
produto e modelo de trabalho com frequência para garantir que cada entrega agregue valor ao
cliente. Imagine por exemplo que o stakeholder responsável pelo projeto de delivery de comidas
resolveu disponibilizar a funcionalidade de pagamentos via PayPall para seus clientes. Há algum
problema em não disponibilizar essa funcionalidade nas primeiras releases? Provavelmente não.
Nesse caso como cada modelo de gestão lida com esse processo?
 
No modelo Waterfall você vai:
 
1. Preencher um formulário de solicitação de mudanças;
2. Reunir seu time de desenvolvimento;
3. Medir os custos da mudança;
4. Estimar o tempo adicional necessário;
5. Solicitar aprovação das mudanças;
6. Revisar o calendário, o custo e o escopo;
7. E claro! Todos os envolvidos precisarão assinar alguns documentos.
 
Essa nova etapa adiciona mais quatro semanas de trabalho extra ao calendário de seu
time. No Agile isso ficaria um pouco diferente quando o stakeholder decide disponibilizar
pagamentos via PayPall no seu aplicativo você apenas precisará decidir o que priorizar. Todo o
processo seria mais ou menos assim:
 
1. Definir prioridades;
2. Adicionar a mudança ao backlog;
3. O time continua o desenvolvimento;
 
No modelo ágil você tem a liberdade para redefinir as prioridades de negócio a todo
momento. O Agile se baseia em um processo de controle empírico. Ao invés de procurar definir
um processo para cada situação possível. Você inspeciona frequentemente o trabalho executado e
as necessidades de negócio e foca no que realmente agrega valor ao produto no momento atual do
projeto.
A diferença chave número 1 entre Waterfall e Agile é justamente a habilidade de
responder às necessidades de negócio de forma imediata. Este é o grande trunfo, e é por isso que
cada vez mais as empresas tem mudado do Waterfall para o modelo Agile.
 
 
 
 
Fazendo a mudança de paradigma
 
 
Se você decidiu mudar para o modelo ágil isso não significará somente uma mudança
em processos, isso significa mudar como as pessoas pensam. E essa é a grande mudança de
paradigma. Isso é tão revolucionário quanto trocar de um carro de câmbio manual para um de
câmbio automático.
Qualquer metodologia de gestão de projetos lida com três restrições: Tempo, custos e
escopo. A Figura 3 representa esse cenário. Como se pode ver cada uma dessas variáveis estão
dispostas nos cantos de um triângulo. A definição de sucesso é manter essas três variáveis o mais
equilibrado possível durante todo o projeto.
No modelo Waterfall as funcionalidades ou features ficam no topo desse triângulo. E
por isso qualquer mudança no escopo exige supervisão regular e acarreta em mudanças no tempo
e no custo. Na base do triângulo temos as variáveis tempo e custo que precisaram ser ajustadas a
cada mudança no escopo. Por esse motivo qualquer mudança impacta imediatamente no custo e no
tempo. Como sabemos o custo e o prazo não são muito flexíveis e nem facilmente manipulados.
Para ser honesto no modelo Waterfall qualquer mudança se torna um grande sacrifício.
Figura 3 – As três Restrições de um Projeto sob a óptica Waterfall
Fonte: Criada pelo Autor
 
Em um cenário assim devem passar por sua cabeça perguntas como:
Como o seu projeto pode ser realmente bem-sucedido com todas essas mudanças?
Qual será a percepção dos stakeholders?
Você precisará fazer uma nova reunião toda vez que surgir a necessidade de alterar
uma dessas variáveis?
Provavelmente sim!
Conforme podemos ver na Figura 4 no modelo Ágil o triângulo é invertido e o tempo e
custo vão para cima. E isso representa uma imensa mudança de paradigma. Nesse modelo o tempo
e o custo são fixos, mas o escopo não e isso dá uma tremenda flexibilidade. Uma única pessoa de
negócio pode decidir por você e se responsabilizar por todo o projeto além de se dedicar ao time.
Essa pessoa é o Product Owner, sua função é garantir o tempo e o custo.
Figura 4 – As três Restrições de um Projeto sob a óptica Ágil
Fonte: Criada pelo Autor
 
Já o papel do time é garantir a entrega de alto valor de negócio ao seu cliente. Eles
têm total liberdade para decidir quais funcionalidades serão priorizadas. Podendo adicionar
novas funcionalidades ou remover outras. Nesse processo eles se preocupam unicamente em
garantir que estão focando em entregar o máximo de valor. Isso em si já é uma grande mudança,
mas é apenas o topo do iceberg!
O Manifesto Ágil define quatro mudanças de paradigma que você precisa fazer em sua
empresa (BEEDLE, 2001):
 
O primeiro desses princípios é “Indivíduos e interações mais que processos e
ferramentas”. Isso significa que os membros do time e suas interações tornou-se um
parâmetro de sucesso. E isso também significa que o processo de controle é menos
importante.
O próximo princípio é “Software em funcionamento mais que documentação
abrangente”. Nesse ponto a definiçãode sucesso não é mais atingir um millestone
predifinido em um documento. É bem mais simples que isso. É apenas entregar
software funcionando a cada final de Sprint.
O terceiro princípio é “Colaboração com o cliente mais que negociação de
contratos”. O time continua comprometido com a entrega de valor ao negócio, mas
agora os clientes tornam-se seus parceiros, colaborando com o time durante todo o
projeto. Eles se tornam parte do time e colaboram para o sucesso do mesmo.
Por fim o quarto princípio é “Responder a mudanças mais que seguir um plano”.
Planos ainda são criados no modelo ágil, entretanto eles são mais imediatos e
diretamente vinculados às mudanças que vão surgindo ao longo do projeto.
 
Essas mudanças de paradigma quando implementados podem trazer à sua organização
grande potencial competitivo. Produzindo grandes mudanças e não apenas pequenas realizações.
Você pode imaginar o quão isso pode ser impactante na sua organização? Está preparado para
seguir em frente e mudar radicalmente de paradigma?
 
 
Agile e margem de lucro
 
 
Não importa qual é o negócio da sua companhia ela precisa lucrar e se manter
lucrativa. Nesse sentido o Agile pode ajudar ou é apenas mais uma despesa? Bom todos os anos
mais e mais empresas mudam seu modelo de gestão para modelos ágeis. Cada uma delas tem seus
próprios objetivos e metas para iniciar esse processo de mudança.
Muitos dos benefícios não são imagináveis quando elas iniciam o processo de
mudança. E um deles é justamente o aumento nos lucros. Como isso é possível? Por que esse
padrão sempre emerge em empresas que fazem essa mudança?
Analisando os principais componentes responsáveis pela margem de lucro as coisas
ficam um pouco mais claras:
 
Retenção de clientes – quando os clientes existentes têm suas expectativas bem
atendidas tendem a renovar seus contratos e indicar novos clientes. E isso claro
indiretamente contribui positivamente com seu time de marketing.
Entregas dentro do prazo – reter e melhorar o relacionamento com seus clientes é o
mesmo que atender de forma eficiente suas demandas e necessidades. Entregas dentro
do prazo contribuem justamente para manter seus clientes satisfeitos e renovar seus
contratos.
Inovação – reter e melhorar o relacionamento com seus clientes lhe ajuda a antecipar
quais necessidades eles irão precisar no futuro. Você não pode começar a entregar
funcionalidades aos seus clientes sem eles necessitarem.
Entregas rápidas – você precisa começar a entregar aos seus clientes o que eles
precisam no momento em que eles precisam e não depois da necessidade. Sua meta
deve ser entregar antes.
Motivação dos times – pessoas felizes com o seu trabalho são mais produtivas. Tenha
certeza de que o seu time está engajado e feliz com o trabalho que eles lhe darão mais
produtividade e competitividade.
 
Isso é fascinante sobre transformar a sua companhia em Agile. Os fundamentos sobre
os quais o Agile se baseiam são reais, táticos e de grande impacto. O Manifesto Ágil nos diz que
(BEEDLE, 2001):
– Indivíduos e interações mais que processos e ferramentas – existe uma conexão direta entre
essas duas variáveis e um time motivado e a obtenção e manutenção dos lucros. Você ainda usa
processos críticos e ferramentas, mas agora seu foco está mais direcionado ao lado humano. Tenha
como centro da mudança, essa palavra que está meio na moda, empoderar e motivar as pessoas.
– Software em funcionamento mais que documentação abrangente – esse princípio também
tem uma conexão direta com a margem de lucro. Entregas rápidas e no prazo ajudam a construir
mais conexão com seus clientes. Agile requer entrega de software funcionando com regularidade.
Este é sem dúvida um dos pontos mais importantes para se medir o sucesso em projetos ágeis e
leva a empresa em direção aos lucros.
– Colaboração com o cliente mais que negociação de contratos – para se certificar de que está
fazendo Entregas dentro do prazo a colaboração com o cliente deve ser tão eficiente quanto
possível. Para se ter certeza de que está no caminho certo loops de feedback com o cliente devem
ser frequentes. Isso significa que seus clientes se tornam parte do seu time. Isso é um trabalho
voltado para o lado humano focado nas suas necessidades e compromissos.
– Responder a mudanças mais que seguir um plano – lucros requerem inovação. Prepare o seu
time para responder e antecipar as necessidades de negócio do seu cliente.
Perceba que esse é um caminho para lucros sustentáveis. Mudar para o Agile é bem
mais do que mudar um processo, é mudar sua forma de pensar.
Capítulo 2: A Avaliação de Viabilidade
 
 
Esse é o momento de avaliarmos se o Agile pode ou não ser aplicado na nossa
organização. Se for o caso então é a hora de estabelecer metas claras dos resultados esperados e
testar pouco a pouco algumas práticas ágeis mais flexíveis.
 
 
Agile pode ser aplicado na minha empresa?
 
 
Agora que temos em mente a definição do que é agilidade e suas diferenças em
relação ao modelo Waterfall vamos avaliar se é possível adotar o modelo Ágil na nossa
organização. Sim existem alguns cenários em que não é uma boa idéia mudar o modelo de gestão.
Quais são esses cenários?
Um desses cenários é em organizações em que os desenvolvedores recebem uma
bonificação extra por produtividade. Trabalhei em uma empresa em que os executivos deram um
carro zero para o desenvolvedor mais produtivo. Eles tinham um projeto para entregar e queriam
garantir que todo mundo fizesse hora extra. Como forma de garantir o engajamento e que o projeto
fosse entregue rápido decidiram aplicar essa abordagem. Em mais ou menos dois ou três meses
começaram a surgir desentendimentos no time. Começaram a questionar os critérios e a
meritocracia do bônus ou não. O resultado disso no relacionamento entre os membros do time foi
desastroso. Se for esse o seu caso é melhor colocar o Agile na gaveta pelo menos por hora.
Em um cenário de escopo fechado em que não se pode mudar nada e o cliente não abre
mão dessa abordagem mais uma vez esqueça Agile. Agile também não é adequado quando o
cliente quer uma montanha de documentação. Alguns projetos de órgãos do governo se encaixam
nessa categoria. Em outros casos seu cliente segue uma norma alguma norma ISO que exige um
monte de documentação. No fim das contas toda essa papelada não agrega nenhum valor, mas seu
cliente não pode fugir dessa burocracia. Nesse caso também não é uma boa idéia adotar o modelo
Ágil por que você certamente vai ter muitos problemas.
Figura 5 – Escritório que dificulta a comunicação
Fonte: http://bit.ly/36X8waI
 
A Figura 5 ilustra muito bem um outro cenário que pode limitar a adoção do modelo
ágil. Como se pode ver o próprio escritório limita fisicamente a comunicação entre as pessoas.
Em um escritório como esse apertado e cheio de baias onde você mal vê o colega do lado? Pois é!
Você sabe muito bem que muito provavelmente a empresa não vai mudar a sua disposição física.
Então esqueça. Agile também não é para você!
Outro cenário em que é complicado adotar Agile é quando a sua empresa está
passando por um processo de mudanças bruscas. Por exemplo a empresa foi com para da por uma
outra empresa. Você simplesmente não consegue prever como as coisas estarão daqui a dois
meses. Pode estar no meio de uma fusão, novos projetos podem estar em iniciação e outros sendo
encerrados. Se está nesse cenário esquece não é um bom momento para tentar migrar para o
modelo Ágil. Talvez o mais correto em um cenário desses seria atualizar seu Linkedin.
Mais um cenário em que o Agile não é uma opção é quando você não tem apoio da sua
gerência. Como veremos adiante e fundamental ter o apoio da alta gestão para poder seguir para o
Agile. Se ao longo do processo você perceber que não vai conseguir esse apoio então não vai
valer a pena entrar nessa briga. Talvez seja o momento de dar uma recuada estratégica e iniciar
pelo Kanban a fim de fundamentar os seus argumentos junto à gerência.
Figura 6 – Hierarquia organizacional desfavorável ao Agile
Fonte: https://raphaelmolesim.github.io/spotify-model/#/A Figura 6 ilustra muito bem um outro cenário em que uma migração ágil não é a
melhor das idéias. Em organizações altamente hierarquizadas onde a simples com para de PostIts
precisa de uma série de aprovações você precisará travar uma “guerra de guerrilhas” e sem um
apoiador forte de preferência no topo da pirâmide suas chances de sucesso não são altas.
O último cenário em que também não é uma boa idéia uma tentativa ágil é se você
estiver trabalhando com código legado. Nesse cenário você simplesmente não tem controle sobre
o que pode acontecer. Nesse caso primeiro será necessário um longo processo de refactory dos
sistemas centrais da organização antes de virar a chave.
Se a sua empresa se encaixa em algum desses cenários sua jornada será para ticamente
impossível mas tenha em mente que gradualmente as coisas podem mudar.
 
 
Definindo suas metas
 
 
Muitas pessoas se mudam para novas casas todos os anos. E honestamente ninguém
gosta de se mudar, é caro, leva tempo e é estressante. Então por que as pessoas fazem isso? Por
espaço, por maior proximidade do trabalho, por uma piscina ou por todos os anteriores? Toda
pessoa que se muda tem uma lista única de razões pelas quais decidiu se mudar. Antes de iniciar
um processo de mudanças é necessário que você descubra quais são as suas metas ou precisará se
mudar novamente em poucos anos.
Até certo ponto trocar de metodologias ou de casa é mais ou menos similar. Cada
empresa que decide fazer a mudança para os modelos ágeis tem uma lista única de razões. Não há
uma solução pronta e pré-definida para todos os casos. É importante que você reconheça as razões
pelas quais sua empresa precisa mudar e esteja preparado para explicar por que e como a
agilidade pode ajudá-lo.
Vamos explorar algumas das razões mais comuns para uma migração para o modelo de
gestão Agile, explorando as razões situacionais que acabam por tornar uma mudança necessária.
Algumas das razões mais comuns para uma mudança para o modelo de gestão ágil são:
 
Entrega pontual;
Falta de qualidade ;
E o prazo para disponibilização em produção.
 
Vamos começar explorando a entrega pontual. Muitas vezes ouço de analistas de
negócios e gestores dizendo que eles iniciam um projeto e um time é formado para fazer o
trabalho. Não raramente o projeto continua por meses ou até anos e no final nada é entregue. Eles
ficam frustrados e muitas vezes o projeto é até mesmo encerrado antes do fim. Em alguns casos as
coisas foram tão mal que não adianta gastar mais dinheiro tentando consertar.
Da mesma forma, os executivos dizem que raramente sabem quando algo será
entregue. Eles relutam em abandonar seus esforços e continuam mesmo sem uma luz no fim do
túnel. Com o tempo, algo mais importante surge e o projeto deve ser descartado. Todo o trabalho
foi em vão e nenhum valor foi entregue. O Agile oferece uma solução para essas situações.
As práticas ágeis concentram todos os esforços em torno da entrega de software
funcionando a cada duas ou quatro semanas. Esses intervalos curtos de entrega são conhecidos
como iterações ou Sprints. Todo o software desenvolvido durante a Sprint é demonstrado para os
stakeholders e é concedida permissão para continuar. Se um valor suficiente foi entregue, o
projeto pode ser encerrado. Se forem necessárias funcionalidades adicionais, o time continuará
repetindo o ciclo iterativo de Sprints e adeus projetos sem fim.
Outro problema comum é a falta de qualidade. Quando algo é finalmente entregue
apenas se parece vagamente com o que o cliente tinha em mente quando o projeto foi iniciado. Ou
pior ainda, se parece com o que eles queriam, mas simplesmente não funciona direito. Na Figura
7 podemos ver famigerado desenho do balanço na árvore que representa bem essa situação.
Figura 7 – O projeto contratado x O projeto entregue
Fonte: http://bit.ly/34UAthr
 
Se você acha esse desenho engraçado, provavelmente é por que já passou por essa
desagradável experiência. O Agile aborda as coisas de maneira diferente para garantir que o que
foi pedido é o que será entregue. A abordagem de desenvolvimento iterativo resolve o problema
da qualidade. A empresa não só vê o software em funcionamento a cada poucas semanas como
também é representada no time através do Product Owner ou PO.
O Product Owner é um especialista em Agile e também é uma pessoa de negócios.
Pelo menos 60% do seu tempo é dedicado ao trabalho no time. Todos os dias, o Product Owner
está trabalhando junto do time, definindo os requisitos garantindo que eles sejam claramente
compreendidos. Ele também acompanha a evolução do produto durante todo o ciclo de vida do
desenvolvimento. As várias demonstrações do produto ao final de cada Sprint ajudam a garantir
que o produto certo está sendo desenvolvido e que possui alta qualidade.
Outra razão para as empresas migrarem para o Agile é acelerar a disponibilização de
novas funcionalidades em produção. Essa razão está intimamente relacionada à necessidade de
inovação.
Atualmente o mercado é muito competitivo e precisamos ser bastante consistentes com
o ciclo de vida da entrega. Quando seu time se compromete com as tarefas da Sprint e não faz
mais nada além disso, sua empresa pode disponibilizar novas funcionalidades em produção com
muita rapidez. Vendo novas funcionalidades em produção com tanta frequência gera novas idéias,
novas inovações que um time focado pode facilmente implementar com rapidez e passar para a
próxima Sprint.
Com isso você mata dois coelhos com uma única cajadada funcionalidades
disponibilizadas mais rapidamente em produção e o aumento da capacidade de inovação. Uma
eventual desvantagem sua em relação aos seus concorrentes não vai durar muito.
Finalmente, todas essas razões situacionais para se tornar ágil têm uma coisa em
comum. Todas essas razões podem custar caro se durante o desenvolvimento do projeto forem
adotadas apenas partes do que era necessário. Entregas demoradas e com baixa qualidade pode
estar lhe custando muito dinheiro. O Agile propõe que resolvendo esses problemas seus custos
gerais possam ser reduzidos. Se você puder entregar produtos de alta qualidade mais rapidamente
e com frequentes inovações, o seu negócio ganhará uma enorme vantagem competitiva.
Portanto não mude sua metodologia de gestão de projetos sem antes entender
claramente quais são as razões para isso em seu ambiente. Tome um tempo perguntando quais
problemas os outros estão vendo. Converta resolver esses problemas em metas. Em seguida,
mapeie todos os problemas identificados de volta para o que você sabe sobre o Agile e as
soluções que ele oferece. 
 
Avaliando seu ambiente
 
 
Avalie seu ambiente de trabalho. Como é onde você trabalha? Você gosta de ir
trabalhar todos os dias? Por que você gosta ou o que você mudaria? Parece um conjunto bastante
estranho de perguntas a considerar, mas não é. As coisas que você gosta na sua empresa são as
coisas que você precisará para capitalizar em sua transformação ágil. Do outro lado da moeda,
estão todos os elementos de que você não gosta, são coisas que você terá que resolver ou, pelo
menos, se preparar para resolver. Vamos falar sobre algumas das restrições ambientais comuns
que você poderá encontrar.
Algumas das restrições mais comuns são a o estilo de gestão, a aceitação da mudança,
foco intenso no processo e confiança. Vamos ver cada um deles individualmente. O estilo de
gerenciamento da sua empresa pode contribuir ou atrapalhar uma transformação Agile. O estilo de
gestão de sua empresa é baseado em comando e controle? Muitas empresas a nossa volta estão
nessa categoria. As decisões são tomadas no topo da hierarquia e executadas nos níveis abaixo
dos líderes.
Isso também é bastante comum em algumas empresas familiares ou em empresas
individuais. O desafio para a sua transformação nesse ambiente é que o Agile depende da
colaboração. Colaboração é o oposto de comando e controle.
Figura 8 – A autonomia alinhada no “Modelo Spotify”
Fonte: http://bit.ly/2nSo8KB
 
A Figura 8 mostra um conceito bastante interessante propostono “modelo Spotify”
que certamente vale a pena dar uma conferida. Ele propõe a idéia de Autonomia Alinhada em que
os colaboradores têm total autonomia para tomar decisões desde que elas estejam de acordo com
a visão de produto e da empresa.
A colaboração exige que as decisões sejam conduzidas a partir do nível mais baixo
possível. E isso significa que serão as pessoas mais próximas da execução do trabalho tomarão as
decisões. Estar tão perto do trabalho significa que eles estão melhor preparados para orientar de
forma ágil e inovadora quando os obstáculos forem encontrados.
Mudar do comando e controle para a colaboração é essencial e a mudança da sua
empresa depende do nosso próximo fator ambiental a aceitação de mudança. Quais são as
respostas mais comuns para sugestões de mudança na sua empresa? É algo como:
 
– Mas sempre fizemos assim.
 
Ou é algo como:
 
– Parece que pode funcionar vamos tentar.
 
A primeira resposta é bastante comum em ambientes de comando e controle, enquanto
a última resposta é comum em ambientes colaborativos. Você pode ver como a vontade de abraçar
a mudança irá corroer o paradigma de comando e controle.
Se o seu ambiente não tiver uma disposição para adotar a mudança, sua abordagem
para se transformar em ágil incluirá convencer os que estão no topo da hierarquia a fazer um teste.
Se você tiver alguma liberdade para fazer alguma experimentação em seu ambiente de trabalho ou
projeto, você pode ao menos convencê-los de que precisará de um tempo para experimentação.
Posteriormente você poderá usar os resultados dessas experiências para fundamentar seus
argumentos.
Outra restrição comum é o alto foco nos processos. Você trabalha em um lugar onde há
um processo para tudo, desde conseguir suprimentos, fazer uma pausa para o café e claro gerir um
projeto. O Agile requer que os processos sejam leves e limitados apenas o suficiente para que a
próxima etapa do trabalho seja concluída. O Agile foca em dar às pessoas envolvidas exatamente
o que elas precisam para concluir seu trabalho nem mais nem menos.
Muitos ambientes focados em processos possuem procedimentos pesados que criam
discussões intermináveis e muita documentação. Se houver procedimentos para cada etapa, você
precisará desmontar algumas expectativas sobre o que será produzido nos times ágeis. Esta não é
uma tarefa impossível embora seja difícil. Você simplesmente precisa se preparar para isso e
explicar como menos é mais.
Nesse caso, a velocidade de disponibilização em produção e a redução de custos são
o resultado natural de uma transformação ágil, porque o tempo não é desperdiçado em processos
pesados e excessiva documentação. Isso é chamado de a arte do trabalho não feito.
Finalmente vamos falar de confiança. Embora isso possa parecer um pouco delicado,
todos nós exibimos confiança todos os dias de maneiras práticas. Por exemplo nós guiamos nossos
carros confiando que todos os outros na rua seguirão as mesmas regras que nós. O mesmo
acontece no trabalho. Trabalhamos confiando que todos farão o que se comprometeram a fazer. A
confiança mantém as coisas funcionando.
A confiança também é um elemento essencial para uma transformação ágil. Mesmo
quando você trabalha em ambientes com pesados processos de comando e controle, quando a
confiança está presente, a liderança sairá do caminho para que você possa fazer o trabalho. Isso é
exatamente o que você precisa ao iniciar sua transformação ágil. Você precisará que seus líderes
confiem em você e acreditem que você está fazendo algo novo que pode revolucionar a maneira
como sua empresa trabalha. Eles precisam sair do seu caminho ao mesmo tempo em que você
precisará sair do caminho do seu time ágil. Esteja presente e disponível para ajudar e remover
obstáculos, mas confie neles para fazer o trabalho com o melhor de suas habilidades.
Então, o que você acha da sua empresa agora? Espero que você esteja animado para
avaliar seu ambiente e se preparar para sua transformação ágil.
 
 
Testando práticas ágeis
 
 
Você compraria um carro sem um test drive? Por que não? Você pode procurar o
manual com todas especificações do fabricante e ver se o veículo atenderá às suas necessidades,
quatro portas, quatro cilindros ou seis, conversível ou não. Por que se preocupar com um test
drive? Bem, o test drive diz muito sobre o comportamento do carro como é sua direção, sua
aceleração, os freios e muitos outros detalhes. As empresas sabem que precisam fazer algo similar
e testar práticas ágeis antes de assumir o compromisso de implantar em toda a organização.
Então vamos falar um pouco sobre como você pode fazer isso sem precisar parar tudo.
As duas práticas ágeis mais leves e eficazes são a reunião diária e as retrospectivas. Vamos falar
um pouco sobre como você pode introduzi-las facilmente em qualquer processo existente. Uma
das maneiras mais fáceis de introduzir o Agile é através da introdução da reunião diária em um
time existente. A reunião diária é comumente chamado de reunião em pé – stand up meeting.
Encontre 15 minutos de manhã quando todos estiverem disponíveis e reúna o time em
uma sala de conferência, em um corredor tranquilo ou de preferência em frente a um quadro de
tarefas. Uma vez iniciada a daily ninguém se senta daí vem o nome stand up meeting que significa
exatamente reunião de pé. Cada membro do time responde então a três perguntas.
 
1. O que eles fizeram ontem?
2. O que eles planejam fazer hoje?
3. E se houverem os impedimentos quais são eles?
 
Seu trabalho é apenas garantir que todos respondam às três perguntas sem interrupção.
Uma vez que todos tenham respondido às perguntas, incentive a discussão entre os membros do
time no que é conhecido como uma discussão pós-stand up. Um ponto importante é que essa
discussão deve acontecer após todos terem falado e visa facilitar o trabalho do time e eliminar
dúvidas sejam de negócio ou técnicas.
Outra prática ágil simples de introduzir é a retrospectiva. A retrospectiva é
normalmente realizada no final de cada Sprint. O time leva de 30 a 60 minutos para analisar o
trabalho que concluíram na última Sprint e identificar maneiras pelas quais eles podem ser mais
eficientes buscando melhorar seus projetos, seus processos ou qualquer outra coisa que esteja
incomodando. Esta é uma reunião muito fácil de introduzir, mesmo que seu time ainda não seja
ágil. Uma vez por mês, agende uma reunião com o time e faça uma discussão detalhada usando as
seguintes perguntas. Primeiro, pergunte o que fizemos bem? É essencial reconhecer e celebrar
sucessos. Não encurte seu tempo neste tópico, realmente agradeça o time pelo que realizou. Então
comece a olhar para o que não correu tão bem.
As pessoas podem relutar em admitir erros que cometem ou verificar de perto coisas
que podem fazer melhor. Talvez você precise ser o primeiro nesse exercício para estabelecer
confiança e demonstrar que o ambiente é seguro e que todos estão juntos no mesmo barco.
Por fim: O que queremos melhorar? E quais desses itens queremos nos comprometer
em melhorar na próxima Sprint? Realmente faça um brainstorm e crie uma lista de itens de
melhoria para o time. Peça ao time que escolha um ou dois nos quais focar. Não tente abraçar o
mundo. Apenas ajude-os a selecionar algo que eles possam melhorar. E claro salve a lista para
conferir durante a próxima retrospectiva. Nela você verificará seu progresso nas mudanças
selecionadas e adicionará ou removerá itens da lista no final da retrospectiva. Você terá o
compromisso de cada membro do time de melhorar os itens selecionados antes da próxima
reunião.
O foco na melhoria não é intimidar ninguém. É simplesmente um reconhecimento de
que podemos fazer melhorias incrementais o tempo todo. Tentando esses pequenos itens com o
time do projeto atual você estará testando alguns dos principais componentes do Agile.
Transparência, comunicação aberta e honesta e disposição para inspecionar como você está
fazendo as coisas e adaptá-las para torná-las mais eficientes e eficazes. Experimente e veja como
sua produtividadee de seu time irá melhorar. Posso lhe garantir que ficará surpreso.
Capítulo 3: Obtendo Apoio
 
 
Selecionar as pessoas certas para o projeto piloto e obter apoio de alguém da alta
gestão é algo essencial para o sucesso do projeto. Além disso lidar com eventuais “sabotadores”
e pessimistas de plantão é algo que não pode ser desconsiderado. Nesse capítulo veremos pontos
importantes a serem considerados ao lidar com esses fatores.
 
 
Engajando Apoiadores
 
 
Você já viu um alpinista escalando o Everest sozinho? Isso talvez até possa ser feito,
mas os alpinistas profissionais jamais recomendariam que você tentasse. Antes é necessário
adquirir bastante experiência em atividades menores. Primeiro te recomendariam fazer escalada
indoor, depois uma montanha ou rocha próxima a sua cidade, depois um pico como o da Neblina,
depois você poderia tentar o Aconcágua na Argentina enfim você precisaria cumprir uma série de
desafios menores antes de encarar o Everest.
Isso faz total sentido e apesar de o Agile não ser uma questão de vida ou morte, é algo
que você realmente só tem uma chance se sua primeira tentativa for mal. É meio improvável que
você tenha outra chance de tentar novamente. Bom, pelo menos não tão cedo. Em termos de
agilidade isso significa que você precisa de um time de entusiastas e apoiadores. O que não
significa que você precise de um time de especialistas em Agile. Na verdade, significa que você
precisa de um grupo de pessoas ao seu redor que também esteja insatisfeito com a maneira como
as coisas estão indo agora.
Você provavelmente já conversou com seus colegas sobre o Agile. Que pessoas
parecem mais entusiasmadas do que as outras. Aquelas que chegam para você e te falam por
exemplo que estão lendo um livro, fazendo uma pesquisa ou treinamento em Agile. Em que nível
essas pessoas existem em sua organização? Essa é a grande pergunta.
O segredo para o sucesso não é integrar todo mundo ao projeto, mas sim escolher as
pessoas certas e aí sim integrá-las ao projeto. Como isso pareceria?
Figura 9 – As camadas hierárquicas de uma organização
Fonte: Criada pelo Autor
 
 
A pirâmide acima ilustra muito bem essa situação. Na camada inferior estão os
colaboradores individuais. É nessa camada que que as coisas acontecem. São estas pessoas que
estarão nas “trincheiras fazendo Agile”. Você precisará de uma boa sustentação nessa camada.
Certamente, aqui se encontra o maior número de pessoas que em qualquer outro nível. Você
precisará identificar os líderes em cada de tecnologia que seriam representados em um projeto
piloto. Uma boa idéia identificar um apoiador de cada categoria da TI como por exemplo, um de
análise de negócios, um de desenvolvimento, um de testes, um de banco de dados e por aí vai.
A próxima camada da pirâmide é mais importante do que os colaboradores
individuais. Por que esse grupo é tão importante? Bom, normalmente, nas organizações
tradicionais, para cada colaborador individual que integra seu time existe alguém na camada
intermediária a quem devem reportar. Essas pessoas por sua vez escrevem relatórios, preenchem
planilhas, mandam e-mails e tem um peso considerável na tomada de decisões. Até mesmo o
colaborador individual mais forte fará o que seu gerente quer que ele faça. Esse é o modo como
eles mantêm suas posições.
Finalmente na camada superior da pirâmide estão os executivos. É nessa camada que
o suporte de que você precisa se torna crítico. É essa camada que pode autorizar um projeto piloto
ágil. É nessa camada que você precisará de um padrinho muito influente. Neste caso, influente não
é necessariamente sinônimo de popular. Você precisará obter apoio de um executivo que tenha
interesse no sucesso de novos projetos. O ideal é que esse executivo seja visto por seus pares
como um líder entre eles, alguém em quem eles confiam para trazer grandes ideias para a mesa e
acompanhá-las até a implementação bem-sucedida.
Depois de identificar todos os principais apoiadores da sua organização, seu próximo
passo é simplesmente começar a conversar com eles. Fale sobre o que você aprendeu sobre o
Agile. Isso é um processo, então não espere que todos entrem na onda imediatamente. Seja
paciente e saiba que você precisará realizar pesquisas durante esse processo para responder às
perguntas de todos. Se você fizer isso, eles gradualmente se juntarão a você no movimento ágil
 
 
Lidando com detratores
 
 
O Manifesto Ágil foi um documento revolucionário quando foi escrito em 2001. Ele
definiu a base e o framework para novas práticas de desenvolvimento ágeis. Ele diz (BEEDLE,
2001) “estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos
e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
 
1. Indivíduos e interações mais que processos e ferramentas
2. Software em funcionamento mais que documentação abrangente
3. Colaboração com o cliente mais que negociação de contratos
4. Responder a mudanças mais que seguir um plano
 
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda”.
Revolucionário? Sim! Polêmico? Sim, naquela época e hoje. Por que as pessoas
pensam assim. Bom, a maioria dos detratores do Agile pegam o meio da expressão de valorizar
uma coisa em detrimento de outra e assume o extremo, mas acredite o Agile não é nada disso.
Sendo assim as dúvidas mais comuns que você precisará refutar são:
 
Agile não usa nenhum processo ou ferramenta!
Agile não produz documentação!
Ou ainda Agile não assume compromissos com os clientes e não planejam!
 
Essa certamente não é a intenção do manifesto, mas os detratores podem não entender
isso. Então, eu irei ajudá-lo a se preparar para explicar. Primeiro o Agile tem processos e propõe
o uso de ferramentas, a diferença é que o foco está mais nas pessoas e suas interações entre si do
que nos próprios processos e ferramentas. Na prática isso significa que ágil é querer as pessoas
certas e os clientes certos no time. Eles querem que essas pessoas trabalhem em conjunto para
garantir que o sistema entregue seja realmente o que se espera. Os processos e ferramentas usados
para realizar o trabalho são menos importantes do que as pessoas e as interações que definem o
trabalho em todo o projeto.
O próximo ponto é a preocupação de que os times ágeis não produzem nenhuma
documentação. Mais uma vez a resposta é muito simples, claro que agilistas criam documentação.
A grande diferença é que o time Agile não gastará horas para documentar um projeto antes de
tentar construí-lo. Os times ágeis usam ferramentas de design leves que podem ser tão simples
quanto um desenho num quadro branco antes de começarem a tentar a criar a solução. A maioria
dos trabalhos em um time ágil incluem documentar o design e documentar como usar o que está
sendo implementado. A grande diferença aqui é que todos os documentos de design não foram
escritos com antecedência e nunca mais atualizados para corresponder ao que foi construído. O
Agile reúne os dois para que o desenvolvimento e a documentação do projeto aconteçam ao
mesmo tempo.
O próximo tópico que também pode surgir gira em torno do compromisso do cliente
com o processo. Por exemplo nas metodologias tradicionais, os clientes vinham até o time e
diziam, que queriam um balanço na árvore. Depois disso eles se afastavam por 6, 9 ou 12 meses
antes de voltar a ver o que foi construído. E o que geralmente acontece nesses casos é que o
resultado nunca correspondia ao esperado. Este método é conhecido como negociação de contrato.
O cliente descreve o que ele precisa e, em seguida ele sai até que o projeto seja finalizado. Já o
Agile pede que o cliente esteja envolvido durante todo o processo. Por esse motivo o resultado
final do trabalho costuma corresponder exatamente o que eles necessitam. A única maneira de
garantir isso é pedir a eles que se comprometam em colaborar e refinar o design junto com o time.
O time ainda se compromete com o trabalho. Os agilistas sabem que seu trabalho será facilitado
se o cliente estiversentado lado a lado do time lhe ajudando a acertar na primeira vez.
Finalmente, meu preferido e o alvo mais fácil dos pessimistas ágeis é que agilistas não
planejam seu trabalho e tudo é desenvolvido como em um Velho Oeste sem nenhuma organização.
Esses argumentos geralmente vêm de executivos gerentes de projetos, clientes e, às vezes,
analistas de negócios. Na verdade, existem cinco níveis de planejamento ágil. Agilistas adoram
planejar e eles gostam tanto de planejar que eles fazem isso em intervalos regulares.
No velho modo, tudo é planejado antecipadamente e não revisitado. Os agilistas
entendem que você só pode planejar com algum grau de precisão, somente aquilo que você pode
ver. Isso é conhecido como planejamento de horizonte. Os times começam com uma visão de
produto para que saibam para onde estão indo. A partir da visão eles então podem definir o
roadmap de produto. No roadmap a visão é dividida em grandes tarefas a serem cumpridas ao
longo do tempo. Estimando aproximadamente quando eles acham que esses itens serão feitos.
Depois disso, eles pegam uma fatia vertical das funcionalidades a cada trimestre e
isso se torna seu plano de release. Em seguida, eles pegam o primeiro trimestre do plano de
release e o dividem em Sprints. Isso é necessário para que saibam o que precisam entregar em
cada Sprint para mantê-los sempre na direção correta até o “alvo”. Finalmente, todos os dias o
time se reúne e discutem o trabalho que eles completaram naquele dia. Essa reunião é muito
importante para que eles possam se manter alinhados com o que se comprometeram.
É fácil entender por que alguns detratores podem não entender o que o Manifesto Ágil
realmente significa à primeira vista. Seu trabalho como um líder ágil é prever e refutar seus
argumentos com fatos. Pode ser frustrante em ambos os lados do mal-entendido. Seja paciente e
eles serão convencidos.
 
 
Obtendo apoio da alta gestão
 
 
O que eu ganho com isso? Comumente chamado de fator de fator determinante. Aplica-
se a todos, incluindo os executivos que você está tentando atrair para o seu lado, a fim de obter a
luz verde para uma transição ágil. Você precisa entender como eles pensam, como eles são
avaliados e como o Agile pode agregar valor às suas necessidades.
Você pode simplificá-lo um pouco antes de começar a atender exatamente às suas
necessidades. Você precisa “desenhar” todo o cenário do motivo de uma mudança. Qualquer
alteração que seja necessária. Desde o que o levou às suas investigações iniciais do Agile e por
quê ele é uma solução para o problema que você está tentando resolver. Comece com a premissa
desse problema e resolva isso primeiro. Antes de apresentar a solução ágil você precisa obter
suporte para enfrentar o problema.
Se você tem seis executivos e cada um deles tem uma ideia diferente do problema, é
improvável que eles concordem com uma solução. Se você puder juntá-los por trás de um
problema comum, será muito mais fácil obter uma solução comum. Por exemplo, se você não tem
uma metodologia em vigor hoje, você precisa fazer com que todos concordem que isso é um
problema. Geralmente, é possível fazer isso com bastante facilidade, demonstrando resultados de
projetos anteriores que variam muito em termos de custo e qualidade. Talvez sua metodologia
atual não possa acompanhar o volume de trabalho. Ou talvez você esteja apenas em uma empresa
que precisa de tempos de resposta mais rápidos.
Faça sua lição de casa com antecedência e você encontrará alguns ótimos exemplos
que você pode usar. Talvez seu problema seja uma frustração geral dos clientes que nunca
recebem o que querem como resultado ou que quando finalmente conseguem algo não é nem de
perto o que eles realmente precisavam. Gastar tempo obtendo esse feedback pode ajudar muito a
estabelecer um problema comum.
Uma vez que você tenha estabelecido um problema e os custos desse problema para
sua empresa você precisará focar na sua solução. Certifique-se de mapear como a solução ágil
resolve o problema específico de que você está falando. Uma vez que você tenha feito isso agora
é o momento de entender com ele é exatamente e o quanto resolvê-lo irá custar. Quais são os
riscos e quais são as recompensas.
Comece com o custo. No mínimo, os custos altos incluirão pelo menos três a dez dias
de treinamento para o time piloto. Você deve decidir se um Agile Coach será necessário por um
período de tempo. Tenha todos esses números em mãos. Você também precisa ser capaz de falar
dos baixos custos da transição para um novo modelo de gestão. Estes custos incluem redirecionar
todo o time para um novo esforço. Esse processo diminui a produtividade do time durante o início
da transição até que todos estejam habituados aos novos processos.
O próximo tópico é exatamente o risco e quando falo em migrar para ágil usando um
projeto piloto esses riscos são muito pequenos. No entanto, alguns riscos comuns são insuficientes
para obter o apoio do time de executivos. Um time pode se desencaminhar rapidamente e fracassar
se não obtiver treinamento suficiente ou mesmo se tiver um acompanhamento mal feito. Ao
abordar os riscos com os executivos, certifique-se de incluir um plano para eliminar ou mitigar
cada risco que você apresentar. Seu objetivo é expor honestamente todos os riscos que você puder
imaginar e oferecer garantias de que cada um pode ser gerenciado. Enfim construa a confiança de
que o apoio dado estará em boas mãos.
Fale sobre as recompensas que o Agile pode trazer para a empresa e para eles como
indivíduos. É improvável que os executivos lhe digam o que eles acreditam que será positivo para
eles então você precisará descobrir isso sozinho. Tenha certeza de que a maioria dos executivos
tem o mesmo faro por necessidades que você e eu temos. Eles querem ser importantes e obterem
promoções, a nova linguagem e as habilidades que o Agile pode lhes dar irão ajudá-los nesse
processo. Eles querem demonstrar suas habilidades de liderança e uma mudança organizacional,
como essa, pode ajudá-los nisso.
Por fim mostre o dinheiro. Uma transição para o Agile resultará em menor tempo para
uma implantação, com custos mais baixos, aumentando assim os lucros. Muitos executivos
recebem participação nos lucros como parte de sua remuneração. O Agile também pode atingir os
objetivos pessoais dos executivos se você apresentar o que eles podem ganhar com essa mudança.
Se você fizer o seu dever de casa certinho certamente terá a luz verde para uma transição ágil em
pouco tempo. 
 
 
Padrinho ágil
 
 
Uma transformação para o ágil pode ser muito complicada. Levar isso adiante sem o
líder correto não o levará ao sucesso. Você vai precisar de um apoiador entre os executivos da
organização que Nesse livro eu o chamarei simplesmente de “padrinho ágil”. Seu papel é agir
como o capitão do seu “navio”. Ele ou ela irá definir o destino e garantir que o navio está no
caminho certo. O papel do padrinho é crítico para o sucesso do time e de toda a transformação
ágil. O padrinho precisa passar atualizações para o time executivo com regularidade. Isso
significa que as atualizações não são relegadas às reuniões semanais do time. O que quer dizer
que o padrinho está fazendo contato regularmente sobre como as coisas estão andando e
compartilha regularmente essas informações de modo informal com seus pares.
Mas como encontrar o padrinho adequado na sua empresa? Dê uma olhada no seu time
de executivos. Geralmente, há um executivo envolvido em vários dos projetos mais importantes da
empresa. Esta pessoa é muito acessível entre os seus pares e eles trabalham duro para manter
esses relacionamentos. Este seria um grande executivo para apadrinhar e apoiar o seu projeto
piloto.
O padrinho é também a pessoa que irá obter financiamento necessário para
treinamento e se necessário para contratar um Agile Coach para o time. Eles também podem
incentivar o treinamento de todo o time de executivos. À medida que você começa a
transformação ágil todos se lembram de treinar os indivíduos do time, mas muitas vezes se
esquecemde treinar o time de executivos. Não esqueça esse ponto. Esse treinamento ajuda a
preparar os executivos para os altos e baixos de uma transformação ágil. Nas mãos de um bom
Agile Coach eles estarão preparados quando os inevitáveis “mares revoltos” surgirem. Seu
padrinho ágil, é a pessoa responsável por vender o valor e a necessidade de treinamento em todos
os níveis. Então, olhe novamente para seu potencial padrinho ágil e se certifique de que ele tem
ótimos relacionamentos entre seus pares.
O padrinho ágil é o representante de todo o empreendimento ágil para o time de
executivos. Eles definirão a visão de como e por que é necessária uma investida rumo à agilidade.
Eles desenvolverão um conjunto importante de pontos de discussão que atendem às necessidades e
preocupações de todos que serão impactados pela migração. À medida que você procura seu
padrinho certifique-se de que ele tenha uma boa noção do quadro geral. Esse é um ponto crítico
para o sucesso no gerenciamento de uma mudança cultural necessária para se chegar ao Agile.
Convenhamos, apenas a mudança cultural para o Agile já é um negócio complicado
por si só. Isso pode incluir o realinhamento de recompensas para incentivar o comportamento ágil.
Isso também significa desenvolvimento e publicação de critérios de sucesso e métricas, bem como
gerenciamento das mensagens sobre o que está mudando e quando. Eles também precisam estar
dispostos a reconhecer abertamente e publicamente o sucesso e aumentar o moral do time.
Finalmente, o padrinho é aquele que remove os impedimentos táticos ao sucesso do
time. Por exemplo, se seu time precisa de treinamento adicional ou coaching, por qualquer motivo,
o padrinho é o indivíduo responsável por conseguir isso. Sendo assim, quando estiver buscando
por um padrinho ágil procure por alguém que fique à vontade com pessoas de todos os níveis da
organização. Seu time precisará ficar à vontade para compartilhar um feedback honesto com o
padrinho ágil, a fim de ajudá-lo a obter ajuda.
Não assuma que seu padrinho precisa ser uma pessoa técnica. Os principais traços de
um padrinho de sucesso são: sua influência, sua liderança e sua acessibilidade. Como o capitão de
um navio o padrinho ágil precisa inspirar os outros a seguir em uma mesma direção e estar aberto
a sugestões de todos. Se você procurar essas qualidades, tenho certeza de que identificará
facilmente o padrinho ágil certo para seu time.
O que você está achando do livro até aqui?
 
CLIQUE AQUI PARA DEIXAR SUA QUALIFICAÇÃO NA AMAZON
 
Se você estiver indeciso, deixe sua qualificação para mais tarde...
https://www.amazon.com.br/review/create-review?asin=B081DPGW3N
Capítulo 4: Iniciando a mudança
 
 
Do mesmo modo que é crucial ao sucesso da “empreitada” selecionar as pessoas
certas. O mesmo é válido em relação ao projeto. Existem fatores importantes que você deve levar
em conta ao selecionar um projeto. Nesse capítulo veremos cada um desses pontos em detalhes
para que sua decisão seja a mais acertada possível.
 
 
Selecionando o projeto correto para um piloto
 
 
Em se tratando de projetos não existem falhas de pequeno impacto. Isso é verdade
tanto se você estiver usando uma metodologia existente quanto introduzindo uma nova. Não
escolher o seu piloto ágil sem isso em mente brincar com o perigo. Antes de selecionar o projeto
piloto certifique-se de que você e seu padrinho ágil estão na mesma página quando se trata dos
objetivos do projeto piloto.
O objetivo é testar todos os fundamentos ágeis do início ao fim e coletar feedback
sobre sua adequação ao seu ambiente. Como um benefício colateral, pode se tornar uma ótima
propaganda para sua transformação geral. A seleção do projeto-piloto correto pode prepará-lo
para o sucesso e te ajudar a “matar os dois coelhos com uma única cajadada”.
Os principais critérios a serem observados em um projeto piloto são tamanho,
prioridade e riscos, complexidade e abrangência e envolvimento do cliente. Vamos olhar um
pouco mais para cada um desses pontos.
Primeiro considere o tamanho. Você deve encontrar um projeto que será executado
pelo menos quatro semanas e não mais que 12. Por quê? Bem, qualquer coisa menor que quatro
semanas não dará tempo suficiente ao seu time piloto para realmente se aprofundar e compreender
os novos processos. Eles simplesmente não terão tempo suficiente para repetir as principais
práticas. Você também quer que eles façam sugestões para adaptações em seu ambiente. Por outro
lado, 12 semanas retarda o ciclo de feedback e, finalmente, torna-se um impedimento para o
release final.
Em seguida, pense em prioridade e risco. Você quer um projeto que seja importante,
mas que não seja de missão crítica, portanto, não de alto risco. O objetivo é testar a agilidade com
alguma pressão de tempo, mas não muita pressão ou então as pessoas irão voltar suas antigas
formas de fazer as coisas. Também tenha em mente o custo do fracasso, não selecione algo que é
crucial para os projetos de sucesso da empresa. Em projetos desse tipo não é recomendável
experimentar algo novo. Afinal de contas você não quer testar suas novas práticas em algo que
poderia causar sua demissão.
Agora, considere a complexidade e abrangência. Você precisa de um projeto com
complexidade suficiente para engajar todos os papéis típicos de um projeto. Os gerentes de
projetos, desenvolvedores, arquitetos, testadores e analistas de negócios. Isso não quer dizer que
você precisa de vários de cada papel no projeto. Na verdade, você só precisa de um de cada. Por
quê? Bem, seu projeto piloto e as novas práticas precisam se adaptar ao seu ambiente de trabalho
ou deixarão de fazer sentido. Você quer um feedback de todas as áreas de especialização sobre o
que funcionou bem e o que precisa ser adaptado. Pois é isso te permitirá se preparar para um
release maior e mais complexo.
Outra consideração para a abrangência é que você precisará de um projeto que
passará por todas as fases de implementação de um projeto. Iniciação, desenvolvimento, testes,
implantação e transição para o suporte. Qualquer projeto que não se encaixe nessas características
e que não passe por todas as fases não é um bom candidato para ser um projeto piloto.
Por fim, pense no envolvimento do cliente. Este pode ser um ponto complicado se
você tiver sorte talvez seu padrinho ágil possa escolher um de seus próprios projetos para usar
como piloto. Se for esse o caso, o padrinho ágil desempenhará o papel de cliente. Já se o seu
padrinho ágil não tiver um projeto que se encaixe nesses critérios, ele precisará fazer parceria
com outro executivo para usar um de seus projetos. O truque aqui é obter apoio desse outro
executivo para que seu padrinho ágil possa desempenhar o papel de cliente para ele. Por quê?
Bem, você não quer expor diretamente seus clientes às dores de crescimento de um projeto-piloto
desde o início. Se o seu cliente é aberto a mudanças, ele não precisará de um proxy, mas mesmo
assim é mais seguro que seu padrinho ágil atue como cliente por procuração durante o projeto
piloto.
A seleção do projeto piloto é tão simples quanto verificar a lista de projetos
pendentes e estreitá-la filtrando o projeto mais adequado com base nesses critérios. Tenha sempre
em mente que não existe uma falha num projeto privado. O sucesso do seu projeto piloto ágil pode
determinar a chance de promover seus objetivos de transformação ágil. Então escolha sabiamente.
 
Montando o time
 
 
Você trabalha em uma empresa que emprega apenas pessoas brilhantes e fáceis de
lidar. Somente pessoas que trabalham pela alegria de fazer o trabalho. Somente pessoas que são
100% cooperativas e adotam todas as mudanças que surgem. Se sim, você provavelmente deve ser
o único funcionário da sua empresa. Se não você está trabalhando para uma empresa como a de
todo mundo. Assim como seu projeto piloto precisa representar um projeto típico de sua empresa,
as pessoas de seu time também precisam representar as pessoas de sua empresa.
Geralmente, existem quatro tipos de pessoas que você encontrarádurante a sua
transformação ágil. Brilhantes e colaboradoras, brilhantes e difíceis de lidar, pessoas que
desafiam todas as iniciativas, pessoas que odeiam mudanças e as evitam a todo custo. Eu não
estou defendendo que você monte seu time com detratores Ágeis e mude o comportamento de seus
inimigos. Estou encorajando você a considerar o que vai levá-lo mais longe em sua jornada ágil.
Considere o seguinte se você construir seu time apenas em torno dos entusiastas ágeis você
perderá uma oportunidade de trazer alguns opositores.
Aqueles que se opuseram originalmente ou eram céticos quanto ao Agile podem se
tornar proponentes, uma vez expostos à verdade das práticas ágeis. Ter uma seção transversal
dessas atitudes pode levar sua transformação adiante mais rapidamente. Embora pareça uma
excelente abordagem criar um time que se tornará seus defensores, você também precisa garantir
que o time contenha pessoas com as habilidades necessárias para levar seu projeto piloto a um
final bem-sucedido. Ao criar seu time, misturar essas habilidades e atitudes pode levar a um
grande sucesso. Tenha em mente que todos os membros do time precisarão se dedicar 100 por
cento do seu esforço ao projeto. Não vai funcionar se os membros do time ficarem alternando de
contexto entre metodologias. Se você quiser que o seu piloto resulte em um projeto de sucesso e
em um feedback concreto sobre aplicação prática do Agile você precisará do time com os dois
pés nos novos processos ágeis.
 
 Front End Banco de Dados Gerente de Projetos Analista de Negócios Testador Arquiteto
Brilhantes e colaboradoras Pessoa 5 Pessoa 3 
Brilhantes e difíceis de lidar Pessoa 4 
Desafiadores Pessoa 1 
Odeiam Mudanças Pessoa 2 
 
Tabela 1 – Tabela de competências x personalidades
Fonte: Criada pelo Autor
 
Uma maneira fácil de realizar essa definição de time é criar uma matriz similar à
Tabela 1, representando as habilidades necessárias e as atitudes em relação à agilidade.
Conforme você for propondo membros do seu time os adicione à sua matriz e garanta que você
tenha a abrangência que precisa para o sucesso.
Você precisará encontrar um lugar onde todos os membros do time possam se sentar e
colaborarem uns com os outros durante todo o tempo do projeto. Para um projeto piloto, isso
geralmente significa que uma grande sala de conferência pode ser reaproveitada para atender às
suas necessidades.
Assim como você analisa cuidadosamente os projetos em potencial para o seu piloto,
você também precisa ter muito cuidado com a configuração do seu time. Isso demandará muito
tempo e foco para você e seu padrinho ágil. Mas no final, será recompensado com um projeto
piloto muito bem-sucedido.
 
 
Os papéis certos para o projeto
 
 
Em um projeto ágil você precisará das ferramentas e das habilidades certas para ter
sucesso em atender a essas necessidades e habilidades. Você precisará de pessoas com
habilidades nas seguintes funções em período integral: Scrum Master, Product Owner,
desenvolvedores, analista de negócios, testador, analista de banco de dados ou DBA e claro
especialistas no assunto. Esses membros do time podem ser divididos em duas unidades. A
unidade do cliente e a unidade de desenvolvimento. Enquanto servem à propósitos separados eles
são um time coeso.
O Product Owner, o analista de negócios e o especialista no assunto formam a
unidade do cliente. Eles são responsáveis pela visão do produto, o que precisa ser feito e o
roadmap do projeto e como levá-lo adiante. À medida que o projeto progride, este grupo
fornecerá os detalhes dos requisitos e os critérios de aceitação. Os critérios de aceitação são
detalhes essenciais para a unidade de desenvolvimento. Os critérios de aceitação informam à
unidade de desenvolvimento o que deve ser feito para que o requisito seja considerado concluído.
A unidade de desenvolvimento inclui o Scrum Master, os desenvolvedores, os
testadores e o DBA. Uma das únicas funções de meio período em sua unidade de desenvolvimento
é o arquiteto. O arquiteto examinará a necessidade geral de negócios e determinará, em um nível
macro, quais tecnologias se adequarão à infraestrutura técnica de sua empresa. O arquiteto será
necessário no início do projeto para definir a visão técnica. Então ele poderá se afastar e sua
unidade de desenvolvimento assumirá e determinará os detalhes do que será entregue. Mais
especificamente, esse grupo pegará o roadmap do cliente e guiarão os detalhes técnicos do que
precisa ser desenvolvido para fornecer a visão.
Garanta que a unidade de desenvolvimento tenha as ferramentas certas para serem
bem-sucedidos e obtenham todo o treinamento necessário. Finalmente, o Scrum Master guiará o
time através de seus compromissos atuando como um facilitador durante todas as reuniões ágeis.
Ele é o responsável pela comunicação do time, incluindo o quadro de tarefas, o gráfico de burn
down, release e Sprint Planning. Eles removem impedimentos e isolam o time das distrações.
Basicamente, o Scrum Master é o responsável pelos processos e pela “saúde” do
time. Quando as unidades de desenvolvimento e de cliente estiverem totalmente formadas, você
terá as ferramentas e as habilidades necessárias para atender à visão estabelecida para a seu time.
Agora você está pronto para iniciar o desenvolvimento do seu projeto.
 
 
Preparando-se para perguntas difíceis
 
 
Durante a minha carreira eu passei por diversas situações bem embaraçosas e com
perguntas bem difíceis. Participei de algumas reuniões para as quais eu não me preparei bem o
suficiente. Simplesmente não investi tempo suficiente antecipando as questões difíceis que seriam
jogadas para mim. Certamente você teve esse tipo de experiência também ou talvez não. O fato é
que enquanto estiver se preparando para lançar seu projeto-piloto ágil, precisará estar pronto para
responder a algumas das perguntas mais difíceis que aparecerão em seu caminho.
Aqui estão algumas das mais comuns. Teremos treinamento em Agile? A empresa está
contratando um Agile Coach para nos ajudar? E quanto às tentativas de mudanças fracassadas
pelas quais passamos anteriormente? Antes de encarar o time do seu projeto piloto certifique-se
de que você está pronto para explicar como eles terão treinamento em Agile e quando. Não há
nada mais intimidante do que ser solicitado a concluir um projeto com uma metodologia que você
não entende e sobre a qual você não teve nenhum treinamento. É uma receita quase certa para o
desastre. Ser capaz de responder a esta pergunta imediatamente ajuda a acalmar esses medos.
A próxima pergunta está intimamente relacionada. Certifique-se de que você está
pronto para explicar se você irá usar um Agile Coach. Eu sei que naturalmente os Agile Coach
quase sempre são contratados de fora da empresa, por isso certifique-se de selecionar um Agile
Coach com quem você pode construir um relacionamento de longo prazo. Química importa a
pessoa que você escolhe para ser seu Agile Coach não apenas precisa ter experiência. Eles
também precisam ser capazes de motivar as pessoas em todos os níveis da organização. O Agile
Coach capaz de fazer isso será diferente para cada ambiente. Nesse ponto, você pode considerar a
utilização de seu time piloto juntamente com seu padrinho ágil na seleção do Agile Coach em
potencial.
Existem vantagens e desvantagens em usar Agile Coach. No lado positivo, eles são
capazes de olhar para o seu ambiente e para as pessoas como uma terceira parte neutra e dar bons
conselhos. Por outro lado, como eles não estão diretamente envolvidos com o projeto eles podem
ser desafiados pelos stakeholders como alguém que não tem nada a perder. Na maioria dos casos,
o Agile Coach é um ótimo investimento para seu projeto piloto e durante os releases iniciais de
seu time. Depois disso, sua implementação ágil deve se estabilizar o suficiente para que você
tenha alguns especialistas internos que lhe permitam seguir sozinho sem o Agile Coach.
Por fim se prepare para enfrentar as questões difíceis sobre os fracassos do passado.
É provável que suaempresa tenha tentado fazer alterações no processo e na metodologia antes,
mas falhou. Esteja preparado para falar sobre o porquê desses fracassos e por quê este é
diferente. Um dos fatores de diferenciação para essa mudança pode ser seu padrinho ágil. Por
isso, não hesite em explicar que seu padrinho ágil garantirá o apoio e o alinhamento dos
executivos. Ele será seu braço direito em toda a organização e seu apoio será fundamental para o
sucesso.
Como você já se preparou para o início do seu projeto piloto você já sabe quais tipos
de perguntas que você enfrentará. Essas conversas prepararam você para conhecer seu time piloto
e responder suas perguntas. Tendo feito toda essa preparação, você não será pego de surpresa.
 
 
Definindo a visão
 
 
Assim que todos os pontos levantados anteriormente estiverem acertados e você
estiver pronto para começar precisará realizar uma reunião de kickoff. Nessa reunião a sua agenda
deve ser afinada e deve cobrir quem, o que, onde, quando, por que e como. Os participantes
devem deixar sua reunião de kickoff sabendo que seu piloto terá sucesso com o que você disse a
eles.
É uma ótima idéia envolver todos desde o começo. Assim que você começar, conte
sua estória. É sempre uma idéia interessante abrir e fechar a reunião de kickoff com seu padrinho
ágil. O padrinho ágil envolverá seu público na visão. No mínimo ele sozinho vai cobrir o que,
quando e porquê. Ao lidar com esses tópicos cruciais no kickoff, seu padrinho ágil não apenas
responderá a essas perguntas literalmente, mas também demonstrará fisicamente seu apoio
executivo. Essa demonstração pode ajudar muito a evitar a subversão ou sabotagem de fontes
externas ao seu time. Dois coelhos com uma cajadada.
Qual é o seu projeto piloto? Seu padrinho ágil deve também cobrir porque esse foi o
projeto selecionado. Quais critérios foram usados na seleção e quaisquer riscos identificados e
quais medidas de mitigação já foram tomadas.
Quando? Esse é bastante simples, é o cronograma com as estimativas do projeto. Esta
é a reunião de kickoff, por isso, certifique-se de fornecer as melhores projeções de uma data final.
Como? É onde o padrinho ágil fala sobre sua estrutura ágil. Todos os bons projetos
pilotos começam com uma implementação ágil esse é o momento de explicar por que essa é uma
ótima maneira de começar. Certifique-se de incluir informações sobre como o time terá o poder de
flexibilizar ou se adaptar de forma ágil para melhor atender às suas necessidades. Esta parte da
reunião de kickoff deve cobrir o porquê da agilidade para sua empresa e difundir os conceitos
sobre uma implementação rígida de agilidade.
Quem? Agora é a hora de apresentar o time que fará parte do projeto piloto.
Certifique-se de apresentar cada um dos integrantes, suas habilidades básicas e por que eles foram
escolhidos para o time. Eles serão os pioneiros, portanto, “não os venda” para o seu público.
Onde? Quando todos os membros do seu time piloto estiverem reunidos então deixe
que todos saibam onde irão trabalhar no projeto. Certifique-se de dizer a todos que um preceito
chave do Agile é a transparência. E que eles são bem-vindos para parar a qualquer momento e ver
o que o time está fazendo e como o piloto está indo. Finalmente o por quê?
Peça ao seu padrinho ágil para reiterar por que o time executivo escolheu a tentativa
pela abordagem ágil. Ele deve pedir o apoio de todos os presentes e recebê-los com qualquer
dúvida ou preocupação. Agora que a execução do projeto está sendo iniciada. Você e seu time
criaram uma ótima base para um piloto de sucesso.
Capítulo 5: Fundamentos básicos do Agile
 
 
Uma vez que as pessoas certas estejam no time e que o projeto esteja selecionado é
hora de dar o primeiro passo da “maratona”. Obviamente existem preparativos mínimos que se
mal feitos podem comprometer suas chances de sucesso. Nesse capítulo veremos como fazer esse
planejamento e como adotar algumas práticas ágeis fundamentais.
 
 
Preparação tática
 
 
Não há nada mais frustrante do que receber um projeto e não receber tudo que você
precisa para ter sucesso. Seu time piloto é novo no mundo ágil e você e seu padrinho ágil
precisam trabalhar para fortalecê-lo rapidamente. As preparações táticas essenciais que você
precisa fazer para abrir caminho para um piloto bem-sucedido são treinamento, disponibilizar o
acesso à processos e ferramentas e o espaço de colaboração.
Você precisará enviar todo o time. Sim, todos eles juntamente com o seu padrinho ágil
para um treinamento individual em frameworks ágeis ou para um bootcamp ágil.
Alternativamente, você pode trazer um instrutor para realizar o treinamento em sua organização.
Normalmente aulas introdutórias de Agile levam cerca de três dias enquanto um bootcamp dura
quatro ou cinco.
O importante é que os bootcamps tendem a ser treinamentos imersivos, o que significa
que os membros do time realizarão processos e cerimônias ágeis durante a aula. Isso é o ideal. A
melhor maneira de aprender Agile é fazer Agile e nessas aulas o seu time irá aprender. Isso
significa que eles aprenderão a fazer todos os conceitos chave do Agile tal qual como foram
originalmente projetados.
Eles não aprenderão como adaptar ou flexibilizar Agile para melhor se adequar ao seu
ambiente e isso é bom. Ainda não é a hora deles adaptarem o Agile. É muito cedo. Se eles
começarem a adaptar o Agile tão cedo, provavelmente voltarão ao que lhes é familiar os
processos antigos. Aqueles que não funcionam muito bem e você está tentando substituir. Sim.
Neste ponto, não faça nada para se adaptar ao Agile. Qualquer adaptação necessária ocorrerá
naturalmente no decorrer do projeto. No final, você decidirá se essas mudanças poderão ser
adotadas por outros times ou se elas são simplesmente benéficas no time atual. No treinamento
ágil o time aprenderá o que precisa para entregar softwares com frequência no final de cada
Sprint.
Depois do treinamento é o momento do time avaliar como suas ferramentas e
processos podem ajudar ou prejudicar nesse esforço. Agora é a hora de avaliar as ferramentas de
desenvolvimento e implantação existentes. Como regra geral a maioria das ferramentas e
processos podem ser adaptados para atender às necessidades de agilidade. No entanto, antes de
prosseguir, você precisará entender como esses processos e ferramentas serão usados por seu
time. Você precisará trabalhar com os indivíduos que possuem ou gerenciam os processos e as
ferramentas necessários. E precisará prepará-los para as mudanças e obter seu apoio para o que
seu time estará fazendo. E você precisará ser paciente nessas conversas. Seu time está inovando,
portanto, certifique-se de que eles se sintam parte da solução.
Finalmente determine onde seu time irá trabalhar. Você aprenderá no treinamento que é
essencial que todo o seu time se sente no mesmo local e não é brincadeira. Encontre um lugar onde
todo o seu time possa se sentar e trabalhar juntos o dia todo, todos os dias. Isso inclui todo o time
inclusive os membros do time de negócios. Você precisará de um espaço de colaboração no qual
todos se sentarão em torno de uma mesa e discutirão o trabalho, o planejamento e o design. Assim
que você fizer essas preparações táticas o seu time estará pronto para começar. Eles serão
preparados para o sucesso graças a todo seu trabalho duro.
 
 
Planejamento antecipado
 
 
Um equívoco comum sobre o Agile é que os times não fazem planejamento. Na
verdade, você já completou um elemento do planejamento da sua visão do produto. Você está
pronto para o próximo passo e agora está construindo seu roadmap. Isto é simplesmente uma
estimativa de alto nível de quando as features do projeto serão entregues. O roadmap cobre
apenas os próximos três a seis meses. Isso porque você não pode efetivamente estimar ou planejar
muito além desse horizonte de tempo.
Um dos principais valores do Agile é “Responder a mudanças mais que seguir um
plano”. Portanto, seu roadmap deve ser considerado uma estimativa. Ele deve ser atualizado à
medida que seu time executa