MELHORES PRTICAS NA ADOO DO SCRUM1

Bruno Giobini Micaela2

Isabella Fonseca3
Instituto de Gesto em Tecnologia da Informao, Belo Horizonte, MG

RESUMO
As metodologias geis tm ganhado muito espao entre as empresas que querem
fornecer um software com entregas curtas e avaliao frequente aliado ao maior retorno
de investimento e maior qualidade. Entre as metodologias geis, existe um framework
que se destaca e vem ganhando muitos adeptos ultimamente, o Scrum. Esse framework
trata o problema de instabilidade dos requisitos de software e o planejamento de
entrega. Mas a adaptao a essa nova forma de trabalho ocorre de forma gradual e
envolve toda a organizao. Vrias empresas de software tm tido problemas na adoo
do framework e algumas delas acabam desistindo. Assim, esse estudo visa analisar e
propor possveis alternativas para solucionar os principais problemas enfrentados pelas
empresas de software que adotam metodologias geis. Os resultados mostram as
melhores prticas a serem utilizadas pelas empresas de software na adoo de Scrum.
PALAVRAS-CHAVE: Gesto gil. Prticas geis. Scrum. Desenvolvimento de
Software. Management 3.0.
ABSTRACT
Agile methodologies adoption has enhanced between companies who want to provide
software with shorter and frequent deliveries combined with bigger return of investment
and quality. Among agile methodologies, Scrum or Scrum variants are the most popular
being used and has gained many fans lately. This framework tries to solve the problem
of software requirements instability and delivery plan. However, the adaptation of
these new ideas occurs gradually and extends to the entire organization. Several
software houses have had problems in the adoption of the framework and some of them
end up quitting the use of use because of it. Thus, this research aims to analyze and
propose possible alternatives to solve the main problems faced by software houses that
adopt agile methodologies. The results show the best practices to be used by the
software houses in the adoption of Scrum.
KEYWORDS: Agile Management. Agile Practices. Scrum. Software Development.
Management 3.0.
1

Trabalho de Concluso de Curso apresentado na ps-graduao latu sensu Engenharia de Software com
Mtodos geis ministrada pelo Instituto de Gesto de Tecnologia da Informao, nos dias 12 e 13 de
setembro de 2014 em Belo Horizonte MG.
2
Bacharel em Engenharia de Computao pela Universidade Federal do Esprito Santo - UFES e psgraduando em Engenharia de Software com Mtodos geis pelo Instituto de Gesto e Tecnologia da
Informao - IGTI, e-mail: brunomicaela1@gmail.com.
3
Bacharel em Cincia de Computao pela Pontifica Universidade Catlica PUC-MG com
especializao em Redes de Telecomunicaes, e-mail: isabella.afonseca@gmail.com.

1. INTRODUO
Desenvolvimento de software o ato de transformar a necessidade de algum em um
produto de software. As atividades de concepo desse software podem se tornar bem
complexas dependendo do objetivo do software, exigindo um processo coordenado para
a correta execuo e a gerao de um produto de qualidade. Dessa forma, surgiram as
metodologias de desenvolvimento de software, sendo essas um conjunto de mtodos,
regras e postulados que orientam uma equipe de desenvolvimento durante o processo de
construo do software.
Nesse cenrio abordagens diferentes e outras complementares de desenvolvimento de
software foram sendo discutidas e aprimoradas. A chamada metodologia tradicional
nasceu primeiro com o objetivo de organizar o processo de construo e ainda
bastante utilizada e, um pouco mais tarde, as metodologias geis. A primeira, baseada
no projeto, procurava definir e documentar tudo antes do incio do desenvolvimento do
software, assim, o processo dividido em etapas que geram documentao para
acompanhar o produto que est sendo produzido. Os problemas comeam a aparecer
quando os requisitos mudam por algum motivo, demandando a alterao do software e
da sua documentao, o que consome mais tempo que o previsto e envolve retrabalho.
Mudanas em desenvolvimento de software so comuns e, portanto, parte inerente a
este processo. Ocorrem mudanas de requisitos do cliente, de tecnologia, de pessoas
envolvidas, de softwares concorrentes, etc. Alm disso, software pouco tangvel, o
cliente s consegue visualizar sua demanda atravs do prprio software finalizado ou de
prottipos que simulam a demanda solicitada. E, quando conseguem abstrair neste
momento, sua opinio acerca do software tambm pode alterar. Como a construo de
um software envolve essas mudanas, os mtodos geis vieram como uma proposta
diferente. Essa nova metodologia rompe com a cultura tradicional desfazendo o modelo
hierrquico top-down e cria um ambiente de criatividade dentro da construo do
software. A metodologia gil, orientada ao cdigo, utiliza menos documentao, tem
facilidade de lidar com mudanas de requisitos e preza pela qualidade final do produto,
satisfazendo, assim, o cliente.
Essas qualidades despertaram um grande interesse entre as empresas e os
desenvolvedores de software, que tm aderido nova metodologia sem realmente
entender a mudana de cultura que isso representa, no tendo assim as reais vantagens
que um desenvolvimento gil poderia prover para a equipe de desenvolvimento e
consequentemente alta gesto da empresa e seus clientes.
1.1. Objetivos
Este trabalho ir focar em um framework gil chamado Scrum e abordar os principais
problemas encontrados por empresas que desejam mudar dos mtodos tradicionais para
os mtodos geis de desenvolvimento de software analisando e propondo diferentes
tipos de abordagens para cada tipo de problema que a empresa possa estar tendo durante
2

esse processo. E ao final, espera-se que esse trabalho possa contribuir para a formao
de um guia das melhores prticas geis na adoo do Scrum.
1.2. Metodologia
Para a realizao deste trabalho, pretende-se realizar uma pesquisa bibliogrfica
exploratria sobre os problemas enfrentados pelas empresas na adoo do Scrum como
framework e as melhores prticas para minimizar o impacto da nova metodologia
adotada. Tambm sero abordados aspectos do desenvolvimento gil e como os seus
valores podem agregar equipe de desenvolvimento. Por fim, sero estudados conceitos
do Management 3.0 que esto fortemente ligados ao desenvolvimento gil e a nova
forma de gerir pessoas. O universo da pesquisa realizada neste trabalho compreende a
rea de Desenvolvimento de Software. A coleta de dados ocorrer por meio de busca
em livros, artigos cientficos e sites especializados com o tema da pesquisa. Os
resultados sero alcanados por meio da anlise e integrao dos casos de empresas
relatados na base bibliogrfica. O texto ser elaborado com as concluses tiradas a partir
das leituras citadas.
1.3. Estrutura do Texto
O restante do trabalho est dividido da seguinte forma: Na seo 2 ser explicado o que
o Scrum, os nmeros de sua adoo nas empresas e por fim as vantagens de sua
adoo. Na seo 3 so expostos os principais problemas e causas de falhas durante a
adoo da metodologia e as melhores abordagens para esses problemas. Tambm so
explorados os mitos acerca do Scrum e do desenvolvimento gil, por fim,
demonstrado como os valores geis e o management 3.0 so importantes durante esse
processo. Na seo 4 ser feito uma discusso sobre o trabalho desenvolvido.
2. SCRUM
Scrum um framework gil utilizado para o gerenciamento de projetos e no
desenvolvimento de produtos. Por meio dele, as pessoas podem resolver problemas
complexos e adaptativos enquanto entregam produtos com o mais alto valor possvel
(SCHWABER e SUTHERLAND, 2013). O Scrum se caracteriza por ser simples, leve,
extremamente difcil de se colocar em prtica e tem como premissa a existncia de um
processo iterativo e incremental para o desenvolvimento de software, podendo, assim,
responder de maneira gil s mudanas e se adaptar a elas. Assim, o Scrum se aplica
perfeitamente a projetos de novos produtos ou de evoluo de produtos j existentes,
mesmo que possuam certo grau de complexidade.
O nome Scrum originado de uma jogada de Rgbi, caracterizado fortemente pelo
sentido de equipe multidisciplinar e colaborativa. O framework advm de conceitos do
Lean, da teoria das restries, do desenvolvimento iterativo e incremental, da teoria de
sistemas adaptativos complexos (Teoria dos Jogos) e do The New New Product
Development Game (TAKEUCHI e NONAKA) um artigo de dois japoneses que
estuda as caractersticas comuns de sucesso de empresas nos anos 80 e que tem como
base a gesto do conhecimento, alm das experincias de desenvolvedores de software
em seus projetos.
3

O Scrum, enquanto framework, no define prticas especficas e detalhadas a serem

seguidas, pois entende que cada projeto nico e tm solues que no podem ser
prescritas. Assim, ele no uma metodologia que define o que deve ser feito em cada
tipo de situao, mas sim uma base onde cada empresa ir empiricamente construir seu
processo. Desse modo, comum encontrar o Scrum sendo combinado com alguma
outra metodologia que tenha prticas que possam ser inseridas e complementadas nesse
processo, o Extreme Programming (XP) uma dessas metodologias.
O Scrum consiste de trs pilares principais que emergem do processo emprico: a
transparncia, a inspeo e a adaptao. A transparncia diz que os aspectos do processo
que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados. A
inspeo trata da vistoria permanente que deve existir sobre os artefatos Scrum e a
deteco de varincias inaceitveis no processo. Por fim, a adaptao aplica os devidos
ajustes nos pontos de discrepncias encontradas na inspeo, evitando que o produto
final seja inaceitvel. muito importante que esses trs pilares sejam respeitados para o
correto funcionamento do processo emprico.
No Scrum temos o Time Scrum (composto pelo Product Owner, Scrum Master e Time
de Desenvolvimento), trs artefatos bsicos (Backlog do Produto, Backlog da Sprint e
Incremento do Produto) e cinco eventos (Sprint, Reunio de Planejamento da Sprint,
Reunio Diria, Reviso da Sprint e Retrospectiva da Sprint). O Time Scrum
responsvel por entregar produtos de forma interativa e incremental, maximizando o
retorno de investimento do produto para o cliente. Os artefatos definidos so
especificamente projetados para maximizar a transparncia das informaes chave de
modo que todos tenham o mesmo entendimento dos artefatos (SCHWABER e
SUTHERLAND, 2013). Os eventos do Scrum so definidos de forma a manter os
pilares da inspeo e da adaptao e todos so time-boxed, ou seja, possuem uma
durao mxima definida. A Figura 1 ilustra o funcionamento de uma iterao no
Scrum, com seus artefatos e eventos.

Figura 1: Ciclo de uma iterao no Scrum (MARCIEL).

2.1. ADOO DO SCRUM PELAS EMPRESAS

Os mtodos geis so uma resposta forma de trabalho dos mtodos tradicionais que
so considerados demasiadamente burocrticos para a produo de um software. Sua
construo exige um processo menos engessado que possa ser construdo s vistas do
cliente, de modo que este possa verificar se o que est sendo construdo est de acordo
com suas expectativas. Em funo desta caracterstica, crescente a adeso dos mtodos
geis pelas empresas fornecedoras de software. Segundo o relatrio tcnico do IMEUSP (MELO, SANTOS, et al., 2012), 88,6% dos entrevistados disseram que existe pelo
menos um projeto na empresa utilizando alguma metodologia gil (Figura 2), e estes
nmeros so confirmados quando estendemos a pesquisa a nvel global, onde 88% dos
entrevistados disseram que esto utilizando prticas geis na empresa (VERSIONONE,
2013).

Figura 2: Percentagem de projetos usando alguma Metodologia gil nas empresas do Brasil (MELO,
SANTOS, et al., 2012).

Figura 3: Experincia das Empresas com Mtodos geis no Brasil (MELO, SANTOS, et al., 2012).

Nessa mesma pesquisa, ainda pode-se observar que 66,7% das empresas utilizam
mtodos geis h menos de 2 anos (Figura 3) e que 77,9% das empresas tm o Scrum
ou alguma variao dele como metodologia adotada (Figura 4).

Figura 4: Metodologias geis mais utilizadas nas Empresas (MELO, SANTOS, et al., 2012).

Diante desses nmeros, pode-se constatar que a maioria das empresas esto em processo
de adoo do Scrum e devem estar passando por algum processo de adaptao com as
novas prticas para desenvolvimento de seus produtos.
Pode-se constatar ainda que o Scrum est sendo bem difundido dentro das empresas e
estas esto dispostas a tentarem uma maneira diferente de construir produtos, j que o
mtodo tradicional no tem se mostrado atraente nem para o fornecedor ou mesmo para
o cliente.
2.2. VANTAGENS
Se bem entendido, o Scrum uma ferramenta que pode trazer diversos benefcios em
comparao a outros modelos de gerenciamento de projetos de desenvolvimento de
software. Muitas equipes esto aproveitando essas vantagens para produzir softwares
mais adequados e de maneira mais rpida.
Entre vrias vantagens pode-se destacar:
Entregas Frequentes O Scrum iterativo e incremental, o que significa que a cada
ciclo uma parte do produto funcionando disponibilizada para o cliente que poder
verificar se necessrio alguma mudana ou adio ao produto. As primeiras partes
desenvolvidas so as mais importantes para o cliente e isso representa uma introduo
do produto no mercado em um curto prazo de tempo proporcionando um rpido retorno
sobre o investimento. Em metodologias tradicionais isso s seria possvel depois de
alguns meses.
Visibilidade do Progresso Para que a equipe possa se adaptar durante o
desenvolvimento do produto necessrio que todos vejam o progresso do mesmo,
inclusive os clientes, que participam ativamente do processo de criao do produto.
Vrias prticas, como reunies com o time e com as partes interessadas, e artefatos,
como o quadro de progresso, visam garantir essa visibilidade do andamento do projeto.
Tal transparncia ajuda na mitigao dos riscos do projeto, j que qualquer no
conformidade pode ser rapidamente verificada e corrigida, evitando que o erro possa ser
visto somente no final do projeto.

Receptivo a Mudanas Scrum no se limita a seguir o plano risca. A mudana

inevitvel durante o processo de desenvolvimento e o Scrum utiliza essa mudana como
uma vantagem. Enquanto o cliente recebe novas partes do produto, novas ideias surgem
e outras, que haviam sido descritas anteriormente, acabam perdendo importncia. E essa
uma oportunidade para inserir novas funcionalidades, melhorar processos ou
solucionar problemas, mantendo assim o foco na entrega de maior valor ao negcio.
Qualidade do Produto A parte do produto gerada a cada ciclo de desenvolvimento
deve possuir a qualidade necessria para poder ser entregue para os clientes do projeto
(SABBAGH, 2013). Dessa forma, o time gil sempre tem em mente a preocupao com
a qualidade do produto adotando prticas que garantam alta qualidade tcnica. O
feedback do cliente um parmetro fundamental para anlise da qualidade do produto.
Aumento da Produtividade Os times geis so auto organizveis e tm autonomia
para escolher a melhor forma para realizar o trabalho e o quanto possvel fazer em um
ciclo de entrega. Dessa forma, todos so responsveis pelo resultado final, fato que
estimula o coletivo e, consequentemente, o aumento da produtividade.
3. MELHORES PRTICAS
Nesse captulo sero apresentados os principais problemas encontrados por equipes
geis no incio do processo de adoo e at mesmo em equipes j experientes, pois cada
projeto desenvolvido se difere do anterior, o que torna o processo de adaptao uma
constante dentro de uma equipe Scrum. Tambm passaremos por mtodos para
diagnsticos de problemas que so comumente encontrados e, em seguida, sero
apresentados os principais mitos acerca do Scrum e suas dificuldades. Por fim, ser
explicado a importncia da insero dos valores geis com o objetivo de ajudar uma
equipe a obter melhores resultados e ser bem sucedida utilizando processos geis,
mudanas essas que podem afetar o comportamento e a cultura de toda a empresa.
3.1. PRINCIPAIS BARREIRAS E CAUSAS DE FALHAS
Ao mesmo tempo que cresce a quantidade de empresas que esto adotando mtodos
geis, cresce tambm a dificuldade das organizaes em se envolver com as novas
formas de construo propostas. Na Figura 5, pode-se verificar que 51,3% dos
entrevistados disseram ter tido problemas com a capacidade de mudana cultural da
empresa, este nmero ainda aumenta se somarmos os 42,1% que disseram ter tido
resistncia mudana ou os 28,8% que no tiveram o apoio da gesto. Ou seja, os
maiores problemas na adoo do Scrum nas empresas so inerentes ao framework em si
e esto em sua grande parte vinculados s pessoas nos projetos e a forma como o Scrum
apresentado aos envolvidos.

Figura 5: Barreiras na adoo dos Mtodos geis (MELO, SANTOS, et al., 2012).

Na Figura 6 pode-se verificar que grande parte dos entrevistados (36,3%) no tiveram
falhas em projetos que utilizam metodologia gil, mas foram relatadas falhas referentes
a outros itens, como falta de experincia na metodologia, cultura da empresa e presso
externa para o retorno da metodologia tradicional. Estes itens se assemelham s
principais barreiras na adoo de uma metodologia gil.

Figura 6: Causas de falhas nos projetos que usam Scrum (MELO, SANTOS, et al., 2012).

Diante desses dois indicadores, pode-se concluir que aqueles que no tiveram problemas
de resistncia a mudana e cultura da empresa no momento da adoo da metodologia,
provavelmente o ter em algum momento durante a execuo do projeto gil.
Existem alguns sinais que podem indicar que um projeto gil no est indo muito bem
ou que no est tendo os resultados esperados, so os chamados Scrum Smells. Ainda
no quer dizer que o projeto gil falhou ou que no ser entregue um produto de valor, e
sim de que necessrio algum tipo de interveno para ajustar as prticas utilizadas
pelo Time Scrum. Nessa seo iremos detalhar alguns desses itens e as melhores formas
de ajustar o caminho do projeto.
Perda de ritmo
Tem como principal caracterstica os Sprints com tamanhos variveis. Se todo Sprint
tem um tamanho diferente do outro, ou seja, o primeiro tem duas semanas, o prximo
tem quatro e ainda um terceiro com tamanho diferente dos dois primeiros, fica muito
difcil a equipe conseguir chegar a um ritmo natural de trabalho. muito importante que
se busque duraes recorrentes todos somos guiados por tempo em nossa vida
cotidiana (hora de acordar, dias teis, final do ms, hora do almoo, etc.). Por isso, essa
disciplina tem que ser um objetivo perseguido pelo Scrum Master. A falta de ritmo cria
dificuldades por parte da equipe no momento de selecionar o Sprint Backlog j que no
se sabe ao certo a durao da interao e essa dificuldade acaba contribuindo para com a
falta de compromisso do time com os itens da Sprint.
Para esse caso, necessrio avaliar quais so os motivos dessa constante mudana no
tamanho da Sprint e se est existindo presso externa nesse processo. Em ambos os
casos, o Scrum Master deve agir e tentar contornar a situao.
Scrum Master delegando trabalhos
Ocorre quando o Scrum Master comea a determinar quem deve fazer alguma atividade
dentro da equipe, processo esse que tem como origem a metodologia tradicional.
O maior problema existente nesse caso a interferncia externa na auto-organizao do
time fazendo com que o desenvolvedor se sinta sem o controle do prprio trabalho,
afetando diretamente um dos princpios bsicos do Scrum que discorre sobre autoorganizao e responsabilidades exigidos dos desenvolvedores. Esta atitude de
delegao, vem, novamente, contribuir negativamente no necessrio comprometimento
da equipe reforado acima.
Isso est realmente pronto?
Esse tipo de pergunta aparece em equipes que ainda no tm uma definio de Pronto
(Done). Isso faz com que a equipe no saiba ao certo se um incremento de software est
realmente pronto para ser disponibilizado para o cliente. E, por vezes, essa indefinio
causa a falsa sensao de que a equipe est tendo um bom desempenho, quando na
verdade o que est sendo entregue no satisfaz os testes de aceitao, causando dbito

tcnico, apario de Bugs para o cliente e causando dificuldades no planejamento das

entregas.
Desse modo, necessrio que todos saibam exatamente o que um incremento pronto e
tudo o que necessrio para que ele possa ser liberado corretamente ao final da Sprint.
Deve-se lembrar que mais importante que a equipe ande mais devagar, mas que ande
no caminho certo do que entregar vrias partes no prontas de um software.
Falta de compromisso no Sprint
Ocorre em Times Scrum que frequentemente no conseguem alcanar o objetivo do
Sprint, ou seja, aceitam uma quantidade de estrias maiores do que a capacidade de
trabalho do time. Esse tipo de comportamento causado por falta de conhecimento da
velocidade do time e por no considerar o tempo que eventualmente algum membro
possa perder por vrias circunstncias alheias ao projeto.
Como consequncia desse problema temos a impreviso com relao aos releases, j
que fica quase impossvel determinar quantos os incrementos estaro prontos e alm
disso o produto pode sofrer com a diminuio da qualidade, j que a equipe vai comear
a espremer os itens para tentar cumprir a meta do Sprint.
Com isso, necessrio que a equipe saiba exatamente qual sua velocidade e se
comprometa a entregar somente aquilo e nada mais, e cabe ao Product Owner a
inspeo dos itens entregues ao final do Sprint, pois nunca se deve abrir mo da
qualidade do produto.
No agir como um Time
A base do Scrum a interao e a colaborao entre as pessoas. Se as tarefas de uma
Sprint comeam a ser designadas para certos membros independentemente, ou nenhuma
das pessoas esto ajudando as outras, ou at mesmo no est havendo discusso acerca
das solues sobre um determinado item, porque alguma coisa est comeando a dar
errado. Sem conversa, ajuda ou compartilhamento de conhecimento entre os membros
da equipe, o Scrum perde grande parte de seus benefcios.
Geralmente esse tipo de comportamento est relacionado a estruturas ruins de empresas
que premiam o individualismo e o herosmo, sem perceber que isso est prejudicando a
ela mesma. Aliado a isso, tambm podemos encontrar membros que acreditam que
retendo o conhecimento garantem sua segurana no trabalho e assim se fecham em seus
postos de trabalho. Atitudes que prejudicam todo o grupo.
Nesses casos, necessrio muito trabalho com as pessoas para que entendam a
importncia do trabalho em grupo e que s assim conseguiro chegar entrega de um
produto altamente confivel. A estrutura do ambiente de trabalho tambm influencia em
muito a forma como as pessoas interagem, retirando as pessoas de suas zonas de
conforto. Tambm necessrio que a empresa se adeque para que passe a privilegiar os
trabalhos feitos pelo grupo e no somente para os heris.

10

3.2. IDENTIFICAO DE PROBLEMAS

Como exposto nas sesses anteriores, existem muitas situaes que podem contribuir
para a adoo do Scrum dar errado. Ele um framework voltado para as pessoas e as
interaes entre elas e isso pode gerar alguns desentendimentos dentro da equipe
fazendo com que no se alcance os resultados esperados quando se planejou a mudana
da metodologia tradicional para a metodologia gil.
Primeiro deve-se lembrar que o Scrum no a salvao de todos os problemas e se
alguma coisa no est dando certo, no quer, necessariamente, dizer que o framework
est sendo usado errado, j que cada projeto de software diferente e os resultados
tambm o so. Desse modo, necessrio investigar qual ser o real problema do
projeto no estar funcionando para que a soluo seja resolvida na sua raiz e no
postergada para um momento em que j possa ser tarde demais.
Outro erro comum de times inexperientes culpar o Scrum pela apario de problemas
que antes no aconteciam. Como dito na seo 2, um dos pilares do Scrum a
transparncia, logo, ele projetado para expor os problemas to logo eles apaream.
Desse modo, o foco do time deve ser como resolver o problema, se que possvel, e
no ficar culpando o framework.
Os problemas geralmente aparecem com maior frequncia nas primeiras Sprints de uma
equipe novata, por isso que se diz que a implantao do Scrum no fcil. uma
mudana de cultura que nem todos esto preparados para encarar. Desse modo,
necessrio que se tenha pacincia com o time Scrum, deixando a equipe errar e aprender
com esses erros para que eles possam achar o padro ideal de trabalho e crie uma
maturidade com o uso do framework.
Supondo que uma equipe seguiu adoo ao Scrum exatamente como est escrito no
manual e mesmo assim depois de alguns Sprints os mesmos problemas continuam
acontecendo est na hora de colocar em prtica um dos pilares do Scrum que a
adaptao. No pode existir o medo de fazer as adaptaes necessrias por estar sendo
diferente do que o framework recomenda. Como descrito na Seo 2, o Scrum tem
como base um processo emprico, onde cada equipe deve analisar o que est ajudando e
o que est atrapalhando a alcanar o sucesso, para que seja possvel adaptar o processo
de uma maneira que agregue valores para o time e para o produto que est sendo
desenvolvido. Deve-se apenas tomar os cuidados necessrios para que no se perca os
valores geis, pois esses delineiam o ambiente organizacional, a satisfao dos
envolvidos e o produto final gerado. Deve-se, desse modo, fazer uso da tentativa e
erro, para saber o que funciona para essa equipe sem medo de desfigurar o Scrum,
mesmo que em determinado momento exista uma mistura de mtodos geis sendo
utilizados. preciso lembrar que o processo perfeito para uma equipe pode no ser a
melhor para uma segunda equipe.
Mesmo tomando todos os cuidados descritos nos pargrafos anteriores pode ser que o
Scrum no melhore os resultados de uma empresa e nessa hora necessrio avaliar se
compensa continuar tentando, se o contexto da empresa permite a adoo do Scrum ou
11

at mesmo se a empresa tem o que necessrio para fazer essa mudana. Existem
contextos em que o Scrum pode no ser a melhor opo, equipes de manuteno, por
exemplo, teriam muitos problemas com o time-boxed do Scrum, pois um contexto
onde as prioridades do trabalho mudam em todo momento, forando a equipe a ser
reativa a essa demanda, desse modo a anlise de outras metodologias geis seria uma
melhor opo para esse cenrio.
Sempre necessrio tentar diagnosticar os problemas que esto aparecendo em uma
equipe gil antes de culpar a metodologia de desenvolvimento para que se busque o real
problema envolvido e como possvel resolv-lo, seja tendo pacincia, seja adaptandoo ou, se for o caso, at mesmo abandonando o processo. Henrik Kniberg ressalta em seu
artigo (KNIBERG, 2011) que o no o Scrum que tem sucesso ou que falha e sim as
pessoas, pois so elas que escolhem onde, quando, como e porque aplicar o Scrum.
3.3. MITOS
Muitas empresas afirmam adotar metodologias geis quando na verdade simplesmente
desenvolvem de forma desordenada, sem planejamento, sem regras e sem
documentao, usando o termo gil como disfarce para projetos caticos. Junte-se a isso
o fato das empresas no entenderem os valores e os princpios geis por trs das prticas
adotadas, gerando um processo sem objetivo. Sem os valores, as prticas se quebram.
Elas se tornam atividades feitas por si s, sem um propsito ou direo. (BECK e
ANDRES, 2004).
O mau entendimento de que em projetos geis no h planejamento e no h
documentao acabam freando uma maior adoo do Scrum nas empresas. Sendo que
na verdade, Scrum no restringe quaisquer outros tipos de atividades que podem e
devem ser realizadas (OLIVEIRA, 2013).
Algumas dessas confuses sero elucidadas e exploradas nas prximas sees.
3.3.1. Projetos geis so pouco planejados
Esse mito surgiu devido a comparao entre processos geis e processos tradicionais.
Neste ltimo determina-se desde o incio o escopo e todas as atividades necessrias para
o desenvolvimento do projeto, assumindo que este tipo de planejamento torna o
resultado previsvel. Nesse cenrio, mudanas no so bem vistas, pois desviam do
planejamento inicial e geram retrabalho. O planejamento Processos geis seguem
premissas diferentes, assumindo que haver mudanas ao longo do projeto e que no
interessante detalhar todo o planejamento. Ainda assim, existem metas de prazos, custo,
esforo, qualidade e escopo como no processo tradicional.
Uma vez que o Scrum adota uma abordagem experimental, aceitando que o problema
no pode ser totalmente entendido ou definido e foca na entrega rpida e na resposta s
necessidades emergentes, seu planejamento feito ento de forma a guiar o projeto
rumo a uma viso maior do produto, mas de uma forma que permita bastante
flexibilidade para as mudanas que, certamente, iro ocorrer (BORGES, 2013).

12

O Scrum trabalha com um planejamento de curto prazo, seus Sprints, e um de longo

prazo, os releases, que so marcos considerados importantes para o projeto.
Dessa forma, o fundamental tentar no planejar tudo no incio, deixando para fazer
esse planejamento de forma incremental e se adaptando s mudanas e s informaes
que iro surgir ao longo do projeto. Tambm importante ter sempre em mente a viso
do produto, pois ela que ir determinar os itens mais importantes e que devem ser
desenvolvidos primeiro, diminuindo assim o risco do projeto e garantindo que, se no
for possvel entregar todo o escopo esperado, pelo menos o mais importante ser
entregue.
3.3.2. Projetos geis so pouco controlados
O gerenciamento tradicional de software possui diversas mtricas que buscam comparar
o estgio atual do projeto com o que foi planejado em seu incio e, assim, podem
determinar o desempenho do projeto. Isso no pode ser feito na gesto gil, j que o
estgio atual pode ter sofrido diversas mudanas em relao ao que foi idealizado
inicialmente. Mas no por isso que a empresa pode ser omissa com o controle do
projeto. O Scrum apenas utiliza outra forma de controlar e o principal indicador de
progresso o prprio produto e seus incrementos que so entregues ao final de cada
sprint, onde cada interessado pode ter contato direto com o produto e saber exatamente
o que j foi produzido. Dessa maneira, o Scrum foca na visibilidade e na transparncia,
onde todos podem verificar o andamento do projeto e tomar as medidas que julgarem
ser necessrias para o alcance do objetivo ao final do projeto.
Para anlise de desempenho, o Scrum faz uso da velocidade da equipe. Velocidade a
quantidade de story points - estimativa de tamanho (ou em horas ou quantidade de
histrias ou qualquer outra medida de tamanho ou esforo que se adapte melhor ao
time) entregues por sprint. Conhecendo a velocidade da equipe, o Product Owner
poder projetar, atravs do grfico de Burnup (Figura 7), quando certas funcionalidades
presentes no Product Backlog sero entregues pela equipe. O grfico de Burnup plota a
quantidade acumulada de story points entregues pela equipe ao final de cada Sprint.

13

Figura 7: Grfico Burnup (GOMES, 2013)

Outros artefatos que podem ser usados para controlar e dar visibilidade ao
desenvolvimento do projeto o quadro de tarefas e o grfico de Burndown.
3.3.3. Em projetos geis no h documentao
Algumas empresas fazem uma leitura errada do segundo item do manifesto gil que diz
que software em funcionamento mais importante que ter uma documentao
abrangente e acabam por criar projetos caticos sem nenhuma documentao. O item do
manifesto gil no diz que a documentao no tem importncia e sim que ela no pode
ser mais importante que o software funcionando, j que esse principal indicador de
andamento do projeto. A documentao permite a transferncia de conhecimento, ajuda
na manutenibilidade, preserva informaes histricas e, quando necessrio, satisfaz
necessidades legais.
necessrio apenas diferenciar a documentao gil da documentao tradicional, onde
ela a base para todos os estgios do desenvolvimento (requisitos, anlise, soluo,
testes, ...) e atravs dela que a comunicao entre as pessoas feita. Os projetos geis
tendem a reduzir a necessidade de documentao e busca uma comunicao mais direta
entre os envolvidos, face a face, documentando somente aquilo que for realmente
necessrio e de uma forma que agregue valor ao projeto, ou seja, se o custo para fazer
uma certa documentao for maior que o benefcio que ela ir gerar para o projeto
aconselhvel que no se faa essa documentao. Do mesmo modo, documentao que
no so mais necessrias para o projeto deve ser descartada, j que a mesma gera um
custo de manuteno.
Uma outra caracterstica da documentao gil o momento em que ela feita.
Recomenda-se documentar quando a soluo estiver o mais estvel possvel, evitando
fazer documentao de especulaes sobre algo que no foi definido. Para esses casos, a
comunicao direta e informal deve ser privilegiada. Dessa forma, a documentao
um resultado e no um insumo do desenvolvimento (BORGES, 2013) na forma de
14

documentos, rascunhos, anotaes, etc., que podem ou no ser utilizados como um

registro permanente.
3.3.4. Mtodos geis s se aplicam a projetos pequenos
Um dos princpios dos mtodos geis a auto-organizao e a comunicao direta entre
os integrantes da equipe de desenvolvimento. Um time de Scrum, normalmente, tem de
5 a 11 integrantes, incluindo o Product Owner e o Scrum Master, e muito importante
respeitar esse princpio gil. Mas no quer dizer que no pode ser aplicado o Scrum em
projetos grandes e com grande nmero de colaboradores, apenas que necessria uma
abordagem um pouco diferente do padro.
Segundo Beck e Andres (BECK e ANDRES, 2004) uma das abordagens que deve ser
adotada transformar o problema grande em vrios problemas menores, cada um
compatvel com uma equipe pequena. Essa diviso do projeto em vrios projetos
menores exige um esforo extra da gesto de projetos de modo que mantenha o correto
sincronismo entre as equipes. Um dos principais mtodos para tratar esse tipo de projeto
gil o Scrum of Scrum (SofS).

Figura 8: Scrum of Scrum (HEYS, 2011)

SofS uma reunio adicional que pode acontecer diariamente ou semanalmente e bem
parecida com a Daily Scrum, onde os representantes de cada equipe se juntam para cada
informar o status atual de sua equipe, ou seja, o que fizeram desde a ltima SofS, o que
pretendem fazer at a prxima e quais so os impedimentos. A diferena aqui que o
15

foco principal da conversa so os itens de interdependncia, aqueles itens que afetam ou

podem afetar a outra equipe de alguma maneira. O reprensentante de cada time deve ser,
necessriamente, um membro do time de desenvolvedores. Nesse tipo de cenrio
normalmente o Backlog compartilhado entre as equipes e cabe aos Product Owners a
responsabilidade de mant-lo. A Figura 8 ilustra um modelo de uso do SofS.
3.4. VALORES GEIS
Os valores geis divulgados no Manifesto da Agilidade (Figura 9) em 2001 so
responsveis por embasar o comportamento da organizao de uma forma geral. Ainda
so bem atuais e devem continuar guiando as decises que se fazem necessrias. So o
que devem direcionar as aes no dia-a-dia das organizaes.

Figura 9: Princpios do Manifesto gil (BECK, COCKBURN, et al., 2001).

A leitura correta dos valores geis tambm se faz importante. Os valores da esquerda
so considerados os de maior valor. No entanto, os valores da direita tambm so
importantes e devem ser considerados. No uma questo de ruptura e sim de nfase.
1o valor: Indivduos e interao entre eles mais que processos e ferramentas
necessrio destacar que o Scrum considera essencial o foco nas pessoas. Acredita-se
que a gerncia das pessoas, se efetiva, a principal responsvel pelo sucesso nos
projetos. Dado isso, o foco no cliente, nos colaboradores (desenvolvedores, testadores,
documentadores, etc.), nos gestores de uma forma geral, dentre outros participantes e
suas interaes um ponto que no pode ser opcional. Ao contrrio, deve ser trabalhado
fortemente durante todo o projeto. Aliado a isso, a comunicao entre eles deve
tambm ser clara e frequente. dada preferncia a comunicao frente-a-frente, tcita
no lugar de comunicao por papel considerada a forma menos efetiva e menos rica
como canal de comunicao. O sexto princpio do Manifesto da Agilidade retrata esta
preocupao: O mtodo mais eficiente e efetivo de repassar informao entre uma
equipe de desenvolvimento atravs de conversao cara-a-cara e ainda sobre a
preocupao com as pessoas: Construa projetos com indivduos motivados, d a eles o
ambiente e suporte que precisam e confie neles para ter o trabalho realizado princpio
5. O grfico de "temperatura da comunicao", de Alistair Cockburn um dos Agilistas
16

do Manifesto da Agilidade, abaixo reproduzido, representa as principais formas de

comunicao existentes:

Figura 10: Grfico de Temperatura da Comunicao (COCKBURN, 2007).

Seguindo as recomendaes do grfico, duas pessoas conversando em frente a um

quadro branco a forma mais efetiva de comunicao, uma vez que coloca os
envolvidos no projeto trocando informaes de forma sncrona (com perguntas e
respostas dadas ao mesmo tempo) e cada um olhando diretamente para o outro
interagindo e transmitindo confiana e comprometimento. Tudo parece muito simples,
mas no dia-a-dia de projetos a troca entre os envolvidos tem se mostrado, por muitas
vezes, o grande entrave. Realmente promover uma boa relao entre seus pares deve ser
uma busca constante dos gestores. O projeto no deve ser encarado como
responsabilidade somente do fornecedor ou do cliente. Ambos tm participao direta
no sucesso. E o fracasso de uma das partes tambm se constitui o fracasso da outra
parte. Por isso, buscar a manuteno de contratos do tipo ganha-ganha de extrema
importncia.
Outro ponto em relao a comunicao a manuteno do cliente prximo da equipe de
desenvolvimento. Alistar Cockburn destaca que manter todos os envolvidos (internos e
externos) em um espao comum e com poucos obstculos comunicao tcita uma
ao considerada fundamental em mtodos geis. demonstrado na Figura 10 que
ocorre uma depreciao considervel na efetividade da comunicao quando so
introduzidas divisrias, separao da equipe em salas diferentes, andares, prdios, etc. A
Figura 11 representa as bolhas como a comunicao em experimentos reais para cada
configurao de ambiente.
Ainda a consonncia entre o 1o. valor e um dos princpios do Manifesto: Mantenha as
pessoas dos negcios e os desenvolvedores trabalhando juntos a maior parte do tempo
do projeto quarto princpio e Processos geis promovem desenvolvimento
17

sustentado. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter

conversao pacfica indefinidamente oitavo princpio.

Figura 11: Diferentes configuraes de Comunicao (COCKBURN, 2007).

Um artefato bastante difundido pelas metodologias geis em geral que contribui para
uma comunicao efetiva com transparncia so os quadros (Figura 12) de
acompanhamento de projetos, como abaixo. Eles tornam as informaes relevantes de
um projeto mais visveis e de fcil acesso. um controle visual para acompanhamento
do trabalho, expondo gargalos, filas e desperdcio atravs da disposio das atividades
realizadas e faltantes.

Figura 12: Quadro de Acompanhamento do Projeto (KNIBERG, 2007).

18

O quadro da Figura 12 possibilita o acompanhamento efetivo do projeto, pois no h

como mascarar o real andamento. Alm disso, o quadro leva em considerao a regra
de priorizao dos itens dispostos no quadro. Post-its localizados no topo so de maior
prioridade que os posicionados no rodap do quadro branco.
A priorizao uma das premissas do Scrum que devem ser respeitadas, pois vai ao
encontro do primeiro princpio do Manifesto da Agilidade: A mais alta prioridade a
satisfao do cliente atravs da liberao mais rpida e contnua de software de valor.
O grfico da Figura 13 nos mostra um exemplo de utilizao de duas variveis de um
projeto na frmula de priorizao de itens do Backlog demanda e facilidade de
implementao. A demanda traduz a viso externa, do cliente. Ela pode ser representada
pela sigla BV = Business Value que reflete a importncia estratgica de uma
funcionalidade do produto para o mercado. Com isso, o Product Owner pode classificar
os itens de maior valor e ainda obter maior retorno sobre o investimento para o negcio.

Figura 13: Priorizao de Product Backlog (POWERLOGIC).

J a facilidade de implementao traduz a viso interna, dos desenvolvedores. Ela pode

ser representada pelo tamanho (fornece o valor a ser gasto na construo que independe
de recurso alocado. No tem unidade) e consequente esforo (medido em horas, advm
da relao entre tamanho x esforo) para implementar tal funcionalidade.
Os itens que ficam dispostos no quadrante mais direita e no topo so os que
preferencialmente devem ser implementados primeiro, pois possuem maior demanda e
tambm so mais fceis de implementar. Os itens que se localizam no topo e mais
esquerda so os prximos, pois ainda se caracterizam como maior demanda, apesar de
apresentarem maior dificuldade de implementao. Depois so os que esto no
quadrante de baixo mais direita maior facilidade e menor demanda e, por ltimo, os
que esto no quadrante de baixo e mais esquerda. Estes ltimos so os indesejveis,
uma vez que so difceis de implementar e ainda possuem demanda baixa. claro que
este exemplo de frmula de implementao ainda pode ter outras variveis para
19

influenciar a ordem da pilha de itens do Backlog. O importante notar claramente a

busca incessante pela real entrega de valor de software ao cliente.
2o valor: Software em funcionamento do que documentao abrangente
Este valor diz respeito a forma tida como mais importante em determinar o percentual
de entrega do projeto. Ele tem relao direta com o princpio 7 do Manifesto da
Agilidade: Software funcionando a principal medida de progresso.
Em contraposio ao mtodo cascata que preconiza grandes fases de anlise e projeto
do software a ser construdo, e, por isso, possui artefatos extensos como resultado de
cada uma. Normalmente, eram descries e diagramas detalhados, modelos que
tentavam prever e cobrir todos os aspectos do desenvolvimento que estaria por vir.
Quando esta fase chegava, as mudanas tambm estavam presentes mudanas de
diferentes tipos: de tecnologias, de pessoas envolvidas, de softwares concorrentes, de
demandas do mercado, etc. Por isso, a documentao extensa a abrangente que havia
sido feita, fatalmente e rapidamente se tornava obsoleta. Muito esforo demandado
desta fase havia sido perdido. Outro princpio do Manifesto tambm relacionado a este
2o. valor Receba bem as mudanas de requisitos, mesmo em estgios tardios do
desenvolvimento. Processos geis devem admitir mudanas que trazem vantagens
competitivas para o cliente princpio 2. O princpio 3 tambm auxilia no ponto em
que refora a presena do cliente em validar o que est sendo construdo, participar
ativamente do projeto e ainda planejar continuamente (com mudanas que trazem ROI
para o projeto): Libere software com a frequncia de um par de semanas at um par de
meses, com preferncia para a escala de tempo mais curta.
3o valor: Colaborao com o cliente mais do que negociao de contrato
Este valor complementa os dois anteriores no sentido de destacar a indispensvel
presena e participao ativa do cliente no projeto atravs da busca de solues em
conjunto com o fornecedor e na tomada de decises em prol do sucesso. No h busca
de culpados. Quem nunca foi a uma reunio de projeto armado o cliente com o
contrato debaixo do brao para cobrar o que foi assinado no incio do projeto,
enquanto o fornecedor rene todas as informaes possveis (novos requisitos
implementados, mudanas que foram solicitadas, etc.) para tentar justificar o atraso do
projeto. Este o tipo de situao que no resolve o real problema e que s tende a se
estender durante todo o projeto.
O oitavo princpio refora: Processos geis promovem desenvolvimento sustentado. Os
patrocinadores, desenvolvedores e usurios devem ser capazes de manter conversao
pacfica indefinidamente.
4o valor: Responder a mudana mais do que seguir um plano
Em uma abordagem tradicional, os contratos firmam as trs restries presentes no
tringulo das restries da Engenharia de Software escopo, prazo e custo. O escopo
acordado entre as partes. A partir do escopo determina-se prazo e custo. Em funo

20

disso, o que se consegue manipular (uma vez que as trs restries foram fixadas) a
qualidade.
Mtodos geis admitem mudanas que trazem vantagens competitivas para os clientes.
Dado isso, no se fixa as trs restries. Tem-se o prazo definido (time-boxed)
restrio fixa obrigatria. Em funo do prazo, tem-se o custo fixo, admitindo-se no se
fazer horas extras de projeto. A qualidade tida como inegocivel. Portanto, o que se
consegue manipular o escopo atravs de uma priorizao das demandas.

Figura 14: Tringulo das Restries Tradicional e gil (FONSECA, 2014).

Mais do que fazer um grande planejamento BRUF (Big Requirement Up Front) e/ou
BDUF (Big Design Up Front), cronogramas detalhados, definir tarefas predecessoras e
sucessoras, etc., necessrio fazer um planejamento constante. Este planejamento
executado atravs dos marcos naturais do Scrum, suas reunies de Sprint Planning,
Sprint Review e Retrospective. sabido que para o ambiente complexo de
desenvolvimento de software, o grande plano detalhado no garante a previsibilidade
desejada. Por isso, saber responder a mudana to importante para o sucesso do
projeto.
3.5. MANAGEMENT 3.0
Um time de desenvolvimento de software um sistema complexo adaptativo, pois so
pessoas que formam um sistema e o sistema apresenta comportamento complexo
enquanto se adapta a um ambiente em constante mudana. Nesse contexto, a gesto tem
que fazer parte desse sistema para que possa restringir e dirigir ao resultado esperado.
No basta que a mudana gil acontea somente nos papis envolvidos no Scrum,
necessrio que toda a organizao entenda os conceitos expostos e a nova filosofia para
que o time tenha o respaldo necessrio para desempenhar um bom trabalho.
Assim, surge o Management 3.0, um conjunto de teorias e tcnicas, divididas em seis
vises de gesto, que visa fornecer a gestores e lderes os conhecimentos necessrios
para levar a Agilidade para a alta gesto da organizao (SABBAGH, 2013). Isso
possibilita que surjam times altamente eficientes, motivados e inovadores em um
ambiente agradvel em todas as camadas da organizao.
21

Diferentemente das Gestes 1.0 e 2.0, que consideravam que os trabalhadores no

gostavam e no sabiam executar bem as suas funes e, por isso precisavam de uma
gesto controladora, o chamado comando e controle, a Gesto 3.0 Management 3.0 se concentra mais na viso sistmica da empresa, pois entende que as pessoas gostam do
seu trabalho e tem o conhecimento necessrio para a execuo de suas tarefas. Assim, a
gesto tenta garantir um ambiente onde o profissional possa desempenhar o seu trabalho
com excelncia.
As seis vises do Management 3.0 so descritas a seguir:
Energizar Pessoas Trata da parte motivacional das pessoas e de como ajud-las a
realizar bem o seu trabalho. As pessoas so a parte mais importante da organizao e
gestores devem fazer tudo o que puderem para manter as pessoas ativas, criativas e
motivadas (SABBAGH, 2013). A motivao no se trata apenas de dinheiro, preciso
verificar o que motiva cada pessoa, dando oportunidade para que elas possam estar
prximas desses desejos. Para isso necessrio que o gestor esteja prximo do time.
Existem profissionais que precisam de motivao extrnseca para realizar o seu trabalho,
essa motivao pode ser uma promoo ou o aumento do salrio. J outros profissionais
gostam do seu trabalho e este por si s j o motiva. Ou seja, h a diferena entre querer
fazer a coisa certa e ter que fazer a coisa certa. Assim, o gestor deve entender que cada
pessoa reage a motivaes de forma diferente e deve identificar o que motiva cada um
dos funcionrios e no tratar todos de forma igual.
Empoderar Times Empoderar a capacidade de transmitir a responsabilidade para os
times. Nos processos tradicionais sempre se trabalhou com delegar responsabilidades ou
no, sendo um processo binrio - sem um meio termo. A gesto 3.0 sugere nveis de
empoderao, ou seja, dependendo da deciso que deve ser tomada decide-se o que
deve ser delegado e no somente o que no sabe fazer bem ou o que no gosta, como
mostra a Figura 15. O gestor tem que ter a pacincia e a capacidade de tratar essa
delegao como um investimento, j que as pessoas provavelmente iro errar no incio,
mas pode ser que no futuro podero estar fazendo at melhor que o prprio gestor.
importante no confundir delegao com negligncia. necessrio verificar se a pessoa
que ir receber a tarefa tem capacidade para faz-la e quando necessrio fornecer o
treinamento adequado para este recurso.

22

Figura 15: Os setes nveis de autoridade (APPELO, 2014).

Times empoderados, com autorizao e com confiana do gestor se auto-organizam

melhor e trazem melhores resultados, fazendo seus gerentes tambm serem bem
sucedidos. Todos saem ganhando, pois o controle delegado aos times se transforma em
motivao e comprometimento, trazendo reais ganhos para a empresa. Delegar no
torna a gesto mais fraca, no um jogo ganha-perde. ganha-ganha. Times poderosos
fazem seus gerentes ainda mais poderosos.
Alinhar as Restries A auto-organizao pode levar a qualquer coisa, e por isso
preciso proteger as pessoas, os recursos compartilhados e dar as pessoas um propsito e
metas claras. As restries determinam os espaos e os limites que o time tem para se
auto-organizar, e essas restries devem ser respeitadas.
Nesse contexto uma das atividades do gestor balancear o sistema entre a ordem e o
caos, trabalhando as restries do sistema e direcionar o time a um objetivo proposto.
Dessa maneira, o gestor deve fazer uso da auto-organizao de uma maneira que ela
gere valor para a empresa, dando liberdade para a equipe e guiando ela atravs das
restries. No se trata de ser um gestor do trabalho das pessoas e sim do sistema como
um todo, fazendo uma distribuio real de um propsito claro e metas compartilhadas
alinhadas pela gesto da organizao.
Desenvolver Competncias Equipes no podem atingir suas metas se seus membros
no estiverem suficientemente capacitados. Embora times auto-organizados possam
lidar com suas lacunas tcnicas, funo da gesto garantir que as pessoas estejam
capacitadas e tm o que necessrio para alcanar as metas estabelecidas.
necessrio prover todo o conhecimento que o time possa necessitar, planejar
desenvolvimento de competncias ou participao em cursos. A prpria equipe tem que
23

ter a responsabilidade de disseminar o conhecimento entre os integrantes de maneira

que o conhecimento do time se torne uniforme e todos possam ter o que necessrio
para desempenhar bem o seu trabalho.
Crescer a Estrutura Organizacional O desenho da estrutura organizacional impacta
de forma significativa em como a organizao funciona (SABBAGH, 2013).
Considerando esse contexto complexo necessrio criar estruturas melhores que
facilitem a comunicao e a auto-organizao do time. Os gestores precisam saber
diferenciar equipes funcionais e multifuncionais.
importante dar preferncia a equipes que sejam multifuncionais em relao a equipes
especialistas, tendo, assim, equipes com habilidades variadas propiciando autoorganizao de forma mais fcil, como mostra a Figura 16. No quer dizer que no
possam existir especialistas em determinadas reas, mas esse especialista deve ser capaz
de desempenhar atividades que sejam necessrias para o time em um determinado
momento e no ficar limitado a somente a sua rea de atuao.
Tambm necessrio ter em mente que equipes menores so mais fceis de administrar
e de manter a comunicao entre eles.

Figura 16: Organizao de equipes multifuncionais (APPELO, 2014).

Melhorar Continuamente Sempre necessrio ter um tempo para parar e pensar em

como melhorar. E esse um dos maiores desafios dentro das empresas. Os gestores
devem abordar a mudana de maneira sistmica e agir como agentes da mudana
tentando sempre melhorar os sistemas complexos que so as organizaes.
Segundo Kurt Lewin (LEWIN, 1943), o comportamento uma funo da personalidade
do indivduo e de seu ambiente (B = f (P, E)). Dessa maneira, possvel forar uma
mudana no ambiente de forma que as pessoas tendam a se adequar a esse ambiente e se
24

enquadrar nele. Assim, importante ter um ambiente que motive a pessoa a estar
sempre em melhoria contnua.
necessrio reconhecer que algo possa estar errado para despertar a vontade de
melhorar e os relacionamentos entre as pessoas favorecem essas mudanas.
Para auxiliar as empresas nesse processo de mudana e adaptao a essas seis vises do
Management 3.0, o autor Jurgen Appelo (APPELO, 2012) aconselha o uso de alguns
modelos para lidar com a gesto de mudanas. O primeiro modelo o ciclo PDCA que
corresponde a Planejar, Executar, Verificar e Agir, onde possvel planejar uma
mudana no sistema, implementar essa mudana e analisar os seus efeitos, fazendo
correes para o prximo ciclo de mudanas. O segundo modelo o ADKAR (HIATT,
2006), que trata do aspecto das pessoas e possui cinco dimenses: Conscincia, Desejo,
Conhecimento, Habilidade e Incentivo. O terceiro modelo a Curva de Adoo, que
aborda a interao entre as pessoas e como cada uma aceita as mudanas, dividindo-os
entre: primeiros adeptos, primeira maioria, segunda maioria e retardatrios. E por fim, o
quarto e ltimo modelo dos Cinco Is, que trata o tema da auto-organizao dos times
geis abordando os temas: informao, Identidade, Incentivos, Infraestrutura e
Instituies.
O Management 3.0, com essas abordagens geis de relacionamento e gesto de pessoas
auxilia de forma contundente na adoo do Scrum pelas empresas de software, fazendo
com que a organizao como um todo no sofra os impactos da mudana de
metodologia e ainda garante a liberdade e a confiana no time de desenvolvimento.
4. CONCLUSO
Neste trabalho foram apresentadas melhores prticas a serem incorporadas por empresas
fornecedoras de software durante a transio da metodologia tradicional para a
metodologia gil.
Foi discutido os principais problemas encontrados na adoo da nova metodologia de
gesto e as melhores formas de se abordar cada situao, sendo possvel sugerir aes
de contorno e minimizar os seus riscos inerentes.
Como a maioria dos problemas que envolvem uma adoo gil est ligado a barreiras
culturais ou resistncia das pessoas, viu-se que grande o esforo na rea de gesto de
recursos humanos, onde se deve investir uma quantidade maior de energia para que a
equipe possa assimilar o necessrio para um bom rendimento, j que podemos
considerar que o Scrum muito mais mudar a forma de pensar do que realmente um
processo.
O Scrum j se consolidou entre equipes de desenvolvimento de software, sendo
fortemente utilizado nos setores operacionais das empresas. Organizaes de diferentes
portes j evoluem seus produtos baseado no framework. Faltava um maior alinhamento
entre o setor operacional e o setor estratgico e ttico da empresa. A equipe de
desenvolvimento de software aplicar os conceitos do framework enquanto a rea
25

comercial est vendendo de forma tradicional ou o presidente est se comprometendo

com conceitos contrrios ao Scrum no colabora para uma efetiva adoo. Dado isso,
viu-se o quanto importante a expanso do conceito para as camadas mais altas da
organizao. As sees Management 3.0 e Valores geis buscam resolver esse gap de
entendimento entre as diversas camadas da organizao.
Os processos geis se adaptam a diversos tipos de empresas fornecedoras de software e
seu foco principal deve estar nas pessoas, na reao s mudanas e na colaborao com
os clientes. Com isso, necessrio a contnua inspeo do que a equipe est fazendo,
adaptar o que for necessrio e procurar melhorar sempre para garantir um produto de
qualidade e um bom ambiente de trabalho para as pessoas envolvidas.
Por fim, pode-se concluir que no existe uma soluo nica para todos os problemas
que seja aplicvel a qualquer equipe ou qualquer empresa de modo que ela possa
alcanar os resultados esperados. necessrio que se exercite ao mximo o empirismo
para que a equipe possa determinar o que funciona e o que no funciona com ela,
respeitando sempre a limitao da cultura da empresa e das pessoas que nela trabalham.
5. REFERNCIAS
APPELO, J. How to Change The World. [S.l.]: [s.n.], 2012.
APPELO, J. Management 3.0 Workout. Rotterdan, The Netherlands: Happy Melly Express,
2014.
BECK, K. et al. Manifesto for Agile Software Development, 2001. Disponivel em:
<http://manifestoagil.com.br/>. Acesso em: 25 Julho 2014.
BECK, K.; ANDRES, C. Extreme Programming Explained: Embrace Change. 2. ed. Boston:
Addison-Wesley, 2004.
BORGES, E. Mtodos geis em Engenharia de Software. Belo Horizonte: IGTI. 2013.
COCKBURN, A. Agile Software Development. Crawfordsville, Indiana: Pearson Education, Inc,
2007.
FONSECA, I. Gesto gil de Projetos com Scrum. Belo Horizonte: IGTI. 2014.
GOMES, A. F. Agile: Desenvolvimento de software com entregas frequentes e foco no valor de
negcio. So Paulo: Casa do Cdigo, 2013.
HEYS, B. Branching for Scrum, 2011. Disponivel em:
<http://blogs.msdn.com/b/billheys/archive/2011/01/18/branching-for-scrum.aspx>. Acesso
em: 13 Agosto 2014.
HIATT, J. M. A Model for Change in Business, Government and Our Community. Loveland,
Colorado: Prosci Learning Center Publications, 2006.
KNIBERG, H. Scrum and XP from the Trenches. USA: C4Media, 2007.
KNIBERG, H. What to do When Scrum Doesn't Work, 2011. Disponivel em:
<https://www.scrumalliance.org/community/articles/2011/february/what-to-do-when-scrumdoesn%E2%80%99t-work>. Acesso em: 24 Agosto 2014.
26

LEWIN, K. Defining the "Field at a Given Time." Psychological Review, n. 50, p. 292310, 1943.
MARCIEL. Disponivel em: <http://blog.marciel.org/wpcontent/uploads/2009/09/scrum_fluxo.jpg>. Acesso em: 18 Agosto 2014.
MELO, C. D. O. et al. Mtodos geis no Brasil: Estado da Prtica em Times e Organizaes.
IME-USP. So Paulo, p. 9. 2012. (RT-MAC-2012-03).
OLIVEIRA, R. L. D. F. Adoo de Agilidade: Scrum, 2013. Disponivel em:
<http://www.devmedia.com.br/adocao-de-agilidade-scrum/21518>. Acesso em: 21 Julho
2014.
POWERLOGIC. Disponivel em: <www.powerlogic.com.br>. Acesso em: 20 junho 2014.
SABBAGH, R. Scrum: Gesto gil para Projetos de Sucesso. So Paulo: Casa do Cdigo, 2013.
SCHWABER, K.; SUTHERLAND, J. Scrum Guide. Scrum.org. [S.l.]. 2013.
TAKEUCHI, H.; NONAKA, I. Disponivel em: <http://hbr.org/1986/01/the-new-new-productdevelopment-game/ar/1>. Acesso em: 25 Setembro 2014.
VERSIONONE. 8th Annual State os Agile Survey. VersionOne Inc. [S.l.]. 2013.

27