Sie sind auf Seite 1von 108

2 Agilidade nas empresas. Guia Scrum para quem no de TI.

Agilidade nas empresas. Guia Scrum para quem no de TI. VOLUME I

Roberto NAVAS Pinheiro

PMP, PRINCE2, Agile, Coach, Trainer, Mentor, PMO-CC, ...

Baseado na verso do Guia Scrum atualizada em Julho/2016.


Indice 3

Direitos autorais do texto original 2017.

Roberto NAVAS Pinheiro

Todos os direitos reservados.

Foto da capa obtida no Wikipedia, referente ao feito de Ashrita Furman quando bateu o
recorde Guinness de maior distncia percorrida com uma bicicleta subaqutica (3,03 km) em
uma piscina em Coimbra, Portugal em Setembro de 2011.

3
4 Agilidade nas empresas. Guia Scrum para quem no de TI.

Para o pessoal de casa, esposa e filhos a quem eu muitas vezes deixei na


sala, vendo TV, enquanto no escritrio eu escrevia mais este livro para somar-se aos 2
anteriores. Bom, para ser sincero, tem tambm os Webinrios e os Workshops do
PMRAD, do Projetando VOC, e dos Nossos Comportamentos RADIOATIVOS, os
happy-hours, palestras, congressos, imerso de 2 a 8 dias em algumas formaes
profissionais de Gesto de Projetos e Pessoas e, 120 livros lidos em 5 anos. + ou -
isso.

Fiz isto para ser congruente com meus propsitos.

Sei que bonito falar de propsito, etc. Mas para se praticar o que se fala (ou
neste caso, se escreve), tem de ser congruente.

Meu muito obrigado minha famlia pela pacincia, muito acima da mdia
Indice 5

Indice

Indice ............................................................................................................................................. 5
Prefcio de Vitor L. Massari .......................................................................................................... 6
Introduo ao tema Agilidade nas empresas ................................................................................ 7
Glossrio de termos em Ingls .................................................................................................... 11
Notao usada neste livro ........................................................................................................... 12
Imagens falam mais que palavras ............................................................................................. 13
O Propsito do Guia Scrum ......................................................................................................... 20
Definio do Scrum ..................................................................................................................... 21
Teoria do Scrum .......................................................................................................................... 23
Transparncia .............................................................................................................................. 24
Inspeo ...................................................................................................................................... 28
Adaptao ................................................................................................................................... 29
Valores do Scrum ........................................................................................................................ 31
O time Scrum ............................................................................................................................... 33
O Product Owner......................................................................................................................... 40
O Time de Desenvolvimento ....................................................................................................... 44
O tamanho do Time de Desenvolvimento .................................................................................. 47
O Scrum Master .......................................................................................................................... 49
Eventos Scrum ............................................................................................................................. 55
A Sprint ........................................................................................................................................ 57
Planejamento da Sprint ............................................................................................................... 63
Reunio Diria ............................................................................................................................. 71
Reviso da Sprint ......................................................................................................................... 73
Retrospectiva da Sprint ............................................................................................................... 75
Artefatos do Scrum / Backlog do Produto .................................................................................. 78
Artefatos do Scrum / Backlog da Sprint ...................................................................................... 86
Incremento .................................................................................................................................. 91
Transparncia do Artefato .......................................................................................................... 92
Definio de Pronto .................................................................................................................. 93
Notas finais .................................................................................................................................. 95
Concluso .................................................................................................................................... 97
CV do autor, Roberto NAVAS Pinheiro ........................................................................................ 98
PLA Solutions ............................................................................................................................... 99
VCPRO training .......................................................................................................................... 100
CAPIE Mentoring ....................................................................................................................... 101
PMO encontros geis / tech Talks / People sharing toughts .................................................... 103
PMO Global Alliance & PMO VALUE RING ................................................................................ 105

5
6 Agilidade nas empresas. Guia Scrum para quem no de TI.

Prefcio de Vitor L. Massari

Como um grande entusiasta e praticante da metodologia gil sempre uma


enorme honra poder contribuir com algumas palavras de abertura, ainda mais quando
se trata de um querido amigo como o NAVAS.

Pude acompanhar de perto a trajetria gil do amigo NAVAS, desde uma das
primeiras edies do PMO Encontros (evento muito bacana organizado por ele), onde
mostrei alguns conceitos bsicos e iniciais de Agilidade em um quase papo de bar, at
encontr-lo em treinamentos, palestras e ouvir com muita alegria os resultados que
vinha obtendo ao explorar este mtodo de trabalho.

Mais alegria ainda quando vi que o amigo se tornou um entusiasta como eu,
ajudando pessoas e empresas a darem estes passos rumo a este universo de muito
trabalho, pouco desperdcio, que foca em pessoas e entregas rpidas de valor.

E agora o amigo NAVAS proporciona a voc leitor um timo livro que servir
como guia para voc dar seus primeiros passos rumo agilidade. Neste livro em
especfico, o foco no framework Scrum, mas NAVAS se preocupa em te revelar logo
no incio do livro a grande essncia, o grande tempero dos mtodos geis: o Lean
Management e o trabalho atravs de ciclos PDCAs (Kaizen) curtos.

Incorporando Lean e Kaizen curto na sua forma de pensar e no seu mtodo de


trabalho, torna-se mamo com acar incorporar as sopas de letrinhas ou os
chamados frameworks/mtodos geis (Scrum, XP, FDD) em qualquer rea de trabalho
e no somente TI. Neste livro, a bola da vez o Scrum que, como o prprio NAVAS
mencionar daqui a pouco fcil de entender e difcil de dominar.

Ento do fundo do corao espero que, com este livro, voc comece a
entender e a praticar para valer! Tenho certeza que muito em breve no ser mais
difcil de dominar e voc obter grandes resultados em seus projetos!

Vitor L. Massari

CEO e Agile Coach da Hiflex Consultoria


Introduo ao tema Agilidade nas empresas 7

Introduo ao tema Agilidade nas empresas

Quando eu li o livro a 5 Disciplina de Peter Senge na dcada de 90, ficou para


mim a importncia do pensamento sistmico. O pensamento sobre o qual como que
existem sistemas (relacionamentos) em todos os lugares, todos os lados e de todos os
tipos, como somos influenciados por estes sistemas e como podemos usar destes
sistemas em nosso benefcio. Serviu para entender que podemos atuar em um ponto
aqui do sistema, para influenciar outros lados e resultados nos quais tenhamos
interesse. Isto me lembra tambm a Teoria das Restries (TOC) de Eliyahu Goldrat,
corrige uma restrio aqui, aparece outra l.

Pessoalmente, sou praticante (ser praticante mais que ser favorvel, certo?)
do pensamento ecolgico, digo, no ecolgico, saudvel e sustentvel, voc ir
contra os sistemas no qual voc est inserido, por que voc acha que seria saudvel e
produtivo defender algo que s voc faz num grupo que caminha unificado para outra
direo? fcil nadar contra a correnteza? correto ser desrespeitoso com nossos
pais, no sermos exemplo nas aes da vida pessoal e cobrarmos atitudes corretas
dos nossos filhos? Isto no sistmico, no ecolgico.

Ainda, as direes mudam conforme alguns ciclos terminam e outros


comeam, os perodos de adoo, uso e descontinuidade de algo so cclicos e no
so infinitos. A adoo a novos jeitos de fazer as mesmas coisas ou coisas
completamente novas, disruptivas, acontecem em ondas, quando novas ondas
chegam, voc tem 2 opes, ou pega uma prancha e surfa a onda ou pega uma
estaca, finca no cho e torce parar continuar ali e respirando depois que o Tsunami
passar. A primeira opo, adaptar-se e seguir o fluxo alinhada, ecolgica, sistmica
e saudvel. A segunda opo, resistir mudana e permanecer esttico no ponto que
est, contraproducente, conflitante e pode no ser saudvel, muitas vezes, pode no
ser possvel.

Outro ensinamento da dcada de 90 novamente, agora de um dos bons


professores que tive, alguns oriundos da indstria automotiva do ABC, sobre a
sndrome do sapo fervido, uma metfora, mas que ficou comigo at hoje como toda
boa metfora por favor, neste momento, convido voc a suspender o julgamento de
valor quanto a fritar sapos. Diz-se que se voc colocar um sapo numa panela com
gua em temperatura ambiente ele ficar tranquilo l. Se esta panela for levada ao
fogo, a temperatura da gua vai subir aos poucos e o sapo no vai perceber as
evolues na temperatura. Quando a temperatura subir mais, o sapo vai continuar l,
resistindo, at que a gua entre em ponto de fervura e o sapo seja frito. Agora, se
voc jogar o sapo em gua fervente de uma vez s, ele vai sentir o choque e vai sair
pulando para fora da panela no mesmo momento, salvando a sua vida, digo, a vida
dele.

Trazendo para o nosso tema, nas nossas profisses, empresas e vidas,


precisamos estar atentos s mudanas que acontecem todos os dias no mercado,
nas tecnologias, nas empresas, na profisso, na vida. Elas podem ser pequenas (nem
sempre) tal como constantes mudanas de temperatura que se ns no percebemos
como ramos, como estamos e qual a projeo para como seremos, podemos ficar
estticos, como o sapo, e quando a gua ferver, a j ser tarde demais para reagir.

7
8 Agilidade nas empresas. Guia Scrum para quem no de TI.

Voltando ao tema indstria automotiva como cone da era industrial, este foi
(me arrisco a dizer assim, com um foi) um tempo fundamentado em produtos fsicos e
coisas analgicas, onde a noo de servio agregado aos produtos era mais
insipiente que hoje e a concorrncia era muito, muito, muito menor. Pense por um
minuto em quantas fbricas de automveis tnhamos no Brasil na dcada de 80 e
quantas temos hoje. Em ordem de grandeza, 5 antes e 25 agora?

Lembro-me da clebre frase atribuda a Henry Ford de que o cliente pode ter o
carro da cor que quiser, contanto que a cor seja preto, oriunda do pensamento da
poca de ganho de escala pela padronizao de tudo. Nesta poca os lanamentos de
novos carros ou novos modelos aconteciam em ciclos longos, se no me engano, da
minha poca de Volkswagen na dcada de 90, chegava-se a gastar uma dcada para
lanar um carro novo e uns 4 anos para uma remodelao de um j em linha de
produo.

No rastro deste cenrio de quando o mercado te dava tempo de sobra para


lanar novos produtos (com menos concorrncia) e sendo estes produtos fsicos e
analgicos, as tcnicas de planejamento foram evoluindo junto, ficando cada vez
melhores em dar preciso de longo alcance para o lanamento de produtos, com a
possiblidade de altos nveis de detalhamento e preciso no planejamento nos mnimos
detalhes. WBS, Gant e PERT so termos conhecidos dos especialistas em gesto de
projetos. At porque a demanda no era to alta, mas principalmente, porque a
concorrncia era baixa, a indstria tinha a oportunidade de ter tempo de planejar os
prximos produtos com alto nvel de detalhe, desde a concepo dos produtos, e at
de certo modo, desacoplado dos servios que circundavam os produtos.

Convido voc a pensar agora, em empresas de classe mundial famosas que


seguem se reinventando e se transformando para sobreviver num mercado muito,
muito, muito diferente e, algumas que at nem existem mais em ordem alfabtica
(novamente, sem julgamento de valor Ok?):

- Atari, Bamerindus, BCP, BlockBuster, Compaq, Ford, GM, Gurgel, GVT,


Honda, Kodak, Kolynos, Manchete, Mappin, Mesbla, Nacional, Orkut, Telefnica,
Toyota, VARIG, VASP, Volks, Volvo.

Esta lista me remete uma outra lista de empresas, empresas da era do


conhecimento (de novo, sem julgamento de valor, Ok? s um brainstorming rpido e
superficial).

- Airbnb, Alibaba, Amazon, eBay, Facebook, Google, Tesla, Uber, Zappo.

Pense em como tem sido o desenvolvimento de carros eltricos (Tesla1), e


autnomos (Google entre outros players) nos ltimos tempos. Como podem gigantes
de hospedagem (Airbnb), vendas (Alibaba), contedo (Facebook) e transporte (Uber)
no terem em seus ativos, imveis, centros de distribuio, redaes e veculos?

Para estas empresas e outras que no surgiram nesta minha lista super
reduzida, talvez os Produtos possam ser considerados Commodities e o seu grande
diferencial competitivo ou at mesmo seu core business sejam os Servios. Seja pela

1
Tesla, comumente conhecida com Tesla Motors, retirou a palavra Motors do seu nome e agora
denomina-se uma empresa com foco em projetos de inovao em tecnologia energtica. Veja mais em
http://tesla.com
Introduo ao tema Agilidade nas empresas 9

sua incrvel capacidade de se colocar no lugar dos clientes e resolver seus mais
importantes problemas, at criar necessidades que ns nem sabamos que tnhamos e
criar mercados inteiros do zero. Pense 1 minuto nisto.

Nesta nossa era de conhecimento e informao digital, os Servios e as suas


facilidades so to ou talvez at mais importantes que os Produtos (Airbnb e Uber so
empresas que s tem Servios! Nenhum produto fsico tipo tijolo, cimento, metal,
borracha e combustvel voc encontra l).

Ainda, a concorrncia brutal hoje em dia. Ideias inovadoras so copiadas


rapidamente. Algumas cpias conseguem ser at melhores que as ideias originais.
Ento a chance de uma inovao ser superada pela prxima cpia uma realidade,
cruel, mas real.

Quer seja porque voc tem uma grande operao e precisa fazer melhoria
contnua sempre (Kaizen) e prover melhor eficincia operacional sendo sempre uma
operao mais enxuta (Lean Manufatura ou Lean Transacional). Quer seja porque
voc est desenvolvendo um Produto ou Servio diferente, inovador e precisa testar
rpido suas ideias, obter feedback do mercado e adaptar as suas prximas aes
(Lean Startup).

Seja l por qual das razes sistmicas acima for (ou por todas as outras razes
e coisas que voc acredita, conhece, sabe e percebe que esto acontecendo na sua
panela), o imperativo responder s mudanas, adaptar-se. J dizia Darwin, que
no o mais forte que sobrevive, mas o que melhor se adapta s mudanas.

neste contexto de agilidade em inovar e responder s mudanas, que o


Scrum se apresentou na dcada de 90 como um conjunto de regras, papis,
responsabilidades e formas de fazer as coisas no TI das empresas. Virtualmente,
qualquer empresa.

Vamos explorar neste livro o Guia do Scrum atualizado para a sua verso mais
nova (de Julho/2016), traduzido oficialmente para o Portugus aqui no Brasil pelo
colega Fbio Cruz autor de best sellers sobre Scrum. Comento e fao uma ampliao
pessoal do Guia neste livro com contedo fortemente relacionado aos benefcios do
Scrum para os negcios. Como o ttulo diz, um livro para quem no de Tecnologia.

No espere um texto preparatrio para certificaes de Scrum Master ou


mesmo Product Owner, ou um texto tcnico sobre desenvolvimento e operao de
ambientes de TI de forma gil (DevOps), que embora sejam pilares importantes da
Agilidade, no o foco do livro.

Fao votos que voc possa perceber valor, em um texto que ajuda voc a
entender como extrair o melhor resultado possvel dos seus investimentos em
Tecnologia da Informao TI. O grande foco deste Guia Scrum para quem no de
Tecnologia, para com os Donos de Produtos, sobre como ser beneficiado pelo
ganho de performance, produtividade e qualidade que seus times de TI vo lhe
proporcionar, quando usando Scrum.

Tem o texto, objetivo de ser uma traduo para quem no de tecnologia


entender alguns termos tcnicos sobre os quais podem eventualmente haver dvidas.

Vamos ao Guia?

9
10 Agilidade nas empresas. Guia Scrum para quem no de TI.
Glossrio de termos em Ingls 11

Glossrio de termos em Ingls

Alguns termos do Guia do Scrum foram mantidos original em Ingls por falta de
uma equivalncia direta do seu significado em Lngua Portuguesa. A lista abaixo d uma
explicao geral destes termos (a maior parte traduzida do Cambridge Dictionary) e
todas as vezes que estes termos em Ingls aparecerem no texto, estes sero grafados,
em itlico. Vale citar que Scrum no um termo em Ingls, uma sigla ou um acrnimo.
Seu significado ser explicado no texto.

Termo em Ingls Significado em Portugus (traduzido do Cambridge Dictionary)

Framework Um conjunto de regras, ideias ou crenas que usado para planejar ou


decidir algo

Sprint Correr a toda velocidade uma distncia curta ou em um tempo


determinado

Stakeholder Uma pessoa ou um grupo de pessoas tais como empregados, clientes


ou cidados que so envolvidos com uma organizao, sociedade ou
assunto e, portanto, tem responsabilidades sobre este, interesse no
sucesso de algo, sendo impactado positiva ou negativamente.
Comumente traduzido como partes interessadas (em algo sobre o qual
se est fazendo) nas publicaes de projetos

Backlog Uma certa quantidade de coisas aguardando para serem feitas, uma
lista de coisas a fazer numa certa prioridade

Container Algo vazio, tal como uma caixa, que pode ser usado para acomodar
algo de modo especial, para fins de transportar ou armazenar. Algo que
serve para encaixar outras coisas dentro

Time-box ou time- Um termo comum ao meio gil com significado de atividades com
boxed durao fixa (tal como Sprint), nem mais nem menos que o previsto, de
modo que o time de trabalho possa, de modo repetvel, fixo e previsvel,
finalizar atividades sempre num tempo programado e tornar-se mais
produtivo cada novo time-box. A lgica (adiantando um pouco o livro)
que o tempo permanece o mesmo, mas a quantidade de trabalho
produzido no mesmo tempo, time-box, aumenta, significando um
aumento da velocidade, da produtividade

11
12 Agilidade nas empresas. Guia Scrum para quem no de TI.

Notao usada neste livro

Em todos os captulos do livro, considere que o texto principal em fonte Arial


(utilizada at agora neste ponto) o texto padro do Guia Scrum 2016, traduzido da
verso Ingls pelo amigo autor Fbio Cruz, sem acrscimos, nem alteraes.

Nos trechos identados direita e escritos em fonte Times New Roman e


cor azul, considere que so as minhas contribuies para o seu entendimento do
Guia Scrum caso voc no seja de TI.

Por motivos de diagramao e para nem sempre interromper uma narrativa


e facilitar o seu entendimento, a sua linha de raciocnio, tambm poder ser feito
uso de Notas de Rodap2.

Recado dado, vamos ao Guia!

2
Por exemplo, assim ...
Imagens falam mais que palavras 13

Imagens falam mais que palavras

Opa, alarme falso, antes de iniciar nosso mergulho no Guia propriamente


dito, vamos usar um conjunto de imagens, para voc passear pelo Scrum numa
rpida passada de olhos. Dizem que imagens so autoexplicativas, ento vamos
fazer uso delas.

Agora sim, ficou bem claro tudo. Scrum isso! Pronto! Da esquerda para a
direita, um conjunto de papis, responsabilidades, eventos e artefatos, um
refinamento constante das coisas e tarefas que h para fazer, um tempo
determinado para ter algo pronto, um acompanhamento dirio e prximo do
trabalho, uma aceitao do produto por quem o pediu e o definiu e oportunidades
recorrentes de melhorar a tudo e a todos e, comear de novo.

Onde tudo comea?

13
14 Agilidade nas empresas. Guia Scrum para quem no de TI.

1 papel envolvido o Product Owner, uma pessoa que representa outras


pessoas na organizao ou ainda fora dela clientes finais, interessadas num certo
assunto (um produto ou um servio, uma caracterstica ou funcionalidade). Esta
pessoa mantm atualizado uma lista de coisas para fazer neste momento, algo
to simples quanto isso. Uma lista em ordem de prioridade, no topo da lista, em
detalhes est o que h de mais importante e prioritrio, pois o que mais agrega
valor para o seu negcio, produto, operao, servio, etc.

Este Product Owner atendido por uma equipe de trabalho, ento vamos a
ela.
Imagens falam mais que palavras 15

Uma equipe dedicada para atender a tal lista de coisas para fazer
chamada de Product Backlog, seleciona alguns dos itens da lista e desdobra em
uma lista com tarefas, chamada Sprint Backlog, com as partes de produto que a
equipe se compromete como sendo possvel deixar pronto num espao
determinado, e curto, de tempo (time box). Isto um trabalho chamado
planejamento da Sprint.

15
16 Agilidade nas empresas. Guia Scrum para quem no de TI.

Chegamos ao 3 papel, o Scrum Master, que como o prprio nome j


autoexplicativo, algum com Master domnio e conhecimento deste modo de atuar
chamado Scrum, da Scrum Master, e vai ajudar as pessoas anteriores (Product Owner e
Equipe Dedicada - Team) a fazer o seu trabalho de forma aderente ao que est dito como
o jeito Scrum de ser.

Como colocado antes, uma Sprint (uma fora-tarefa de tiro curto, digamos)
acontece com uma durao de tempo fixa, algo entre a cada 1 ou 4 semanas uma
Sprint encerra-se comeando outra. Ou seja, em 1 ou 4 semanas a equipe Dedicada
(Team) executa todas as tarefas com a qual ela havia se comprometido compor a
Sprint Backlog. importante que no ocorram alteraes do contedo da Sprint
Backlog, durante a Sprint, digo, nem encurtar nem prorrogar a durao, ou incluir
coisas novas que no estavam previstas de fazer.
Imagens falam mais que palavras 17

Uma das atribuies do Scrum Master na busca por manter o jeito Scrum
de ser ativo, proporcionar que o planejamento feito pela Equipe Dedicada
Team, no incio da Sprint, possa ir sendo acompanhado diariamente pelo Time.
Este acompanhamento dirio seguido de perto pelo Product Owner (interessado
no produto final, lembra-se?) e, normal que aconteam refinamentos daquele
Product Backlog definido de forma mais alto nvel no incio. Isto no significa
trazer novas prioridades de outros temas, mas significa refinar as definies dos
assuntos j priorizados e j programados para serem entregues num horizonte de
tempo de 1 a 4 semanas (time box).

17
18 Agilidade nas empresas. Guia Scrum para quem no de TI.

Quase no final da Sprint, o Time obtm do Product Owner uma avaliao


final do que ficou pronto. Com a aprovao do Product Owner, o que est
finalmente considerado pronto encaminhado para ser liberado, ajustes finais
pontuais so feitos. Se o novo pedao de produto (incremento de produto)
apresentado for recusado pelo Product Owner, o item volta, ..., l para a Product
Backlog, a lista de coisas para fazer.
Imagens falam mais que palavras 19

Bom, de posse destes 2 possveis feedbacks, um bom, de aceitao do


incremento de produto (de mais uma parte pronta do produto) e outro ruim, de
rejeio do trabalho feito e a necessidade de retrabalho, o Scrum Master ajuda o
Time a resgatar em forma de retrospectiva (olhando pelo retrovisor sobre os fatos
incorridos durante a Sprint), o que que foi feito de bom, gerou bons resultados e
precisa ser repetido mais vezes e at compartilhado com outros times geis da
empresa e, o que que no foi bom, no funcionou e precisa ser evitado repetir at
mesmo no prprio time, j na prxima Sprint que agora vai comear, reiniciando os
trabalhos com os novos itens mais prioritrios da Product Backlog, planejando e
combinado outra Sprint Backlog, j levando em considerao as lies aprendidas
na anterior e assim por diante nas demais Sprints.

Agora que voc entendeu tudo de forma rpida e clara , agora sim,
vamos em definitivo ao Guia do Scrum!

19
20 Agilidade nas empresas. Guia Scrum para quem no de TI.

O Propsito do Guia Scrum

Scrum um framework para desenvolvimento e sustentao de produtos


complexos. Este Guia contm a definio do Scrum. Esta definio consiste dos
papis, eventos, artefatos e regras que ligam tudo isso junto. Ken Schwaber e Jeff
Sutherland desenvolveram o Scrum; o Guia do Scrum originalmente escrito por eles.
Juntos, Ken e Jeff so as pessoas que apoiam o Guia do Scrum.

Ken Schwaber e Jeff Sutherland difundiram o Scrum no desenvolvimento


de software em empresas de TI nos Estados Unidos na dcada de 90, baseado no
estilo de gerenciamento de produtos em empresas automotivas Japonesas partir
de um estudo publicado pelos professores Hirotaka Takeuchi e Ikujiro Nonaka, no
artigo The New New Product Development Game (Harvard Business Review, de
Janeiro/1986).

Scrum derivado do pensamento Lean Manufacturing surgido do Sistema


Toyota de Produo. Em tempo, Scrum no uma sigla, um acrnimo. Scrum o
nome da formao do Rugby usada para reiniciar o jogo em certos casos.
Falaremos mais disso mais frente.

Importante destacar aqui a citao de aplicabilidade do Scrum para o


desenvolvimento de produtos complexos, quando no se tem uma viso clara e
completa de tudo que se deseja alcanar. Veja mais abaixo.
Definio do Scrum 21

Definio do Scrum

Scrum (substantivo): Um framework dentro do qual pessoas podem tratar e


resolver problemas complexos de forma adaptativa3, enquanto entregam produtos com
o mais alto valor possvel, de forma produtiva e criativa.

Scrum algo:

Leve;
Simples de entender e
Difcil de dominar4

Scrum um framework estruturado de forma processual, que vem sendo usado


para gerenciar o desenvolvimento de produtos complexos desde o incio da dcada de
90. Scrum no um processo ou uma tcnica para construir produtos; em vez disso,
um framework dentro do qual voc pode empregar vrios processos ou tcnicas. O
Scrum deixa claro a eficcia relativa s prticas de gerenciamento e desenvolvimento
de produtos, de modo que voc possa melhorar.

O framework Scrum consiste de Times Scrum e seus papis, eventos, artefatos


e regras associadas. Cada componente dentro do framework serve a um propsito
especfico e essencial para o uso e o sucesso do Scrum.

As regras do Scrum integram de forma unificada os eventos, os papis e os


artefatos e governam os relacionamentos e interaes entre eles. As regras do Scrum
so descritas ao longo do texto.

Tticas especficas para uso do framework Scrum variam e so descritas em


outros documentos.

Neste ponto, mora uma complicao. O termo framework amplo, um


monte de coisas encaixa-se como framework, ento at aqui foi possvel
entender que o Scrum fcil de entender por no ser prescritivo difcil de
dominar pelas mudanas culturais (voc vai entender bem isto). Ateno seja dada

3
A forma adaptativa tem relao com a necessidade de adaptar-se rpido em resposta s mudanas que
ocorrem.
4
Leve significa ser pouco profundo e no prescritivo (no diz como fazer). Por no ser profundo, ele
simples de entender os princpios, regras, papis, eventos. Por no ser prescritivo e, como o jeito Scrum
ou gil de fazer pode ser uma ruptura no modo que voc e seu time fazem hoje o trabalho, ele ser
naturalmente difcil de dominar num primeiro momento. O fato de voc aceitar isto, j um 1 passo
importante na direo de aprender. Faa algo diferente na prxima chance que voc tiver de fazer algo.
A mudana movimento.

21
22 Agilidade nas empresas. Guia Scrum para quem no de TI.

ao ponto, de que one size does not fits all no considere que existam respostas
prontas e sempre iguais para todos os problemas.
Teoria do Scrum 23

Teoria do Scrum

Scrum fundamentado nas teorias de controle emprico5 de processos. O


controle emprico afirma que o conhecimento vem da experincia e a tomada de
decises baseada no que conhecido. O Scrum emprega uma abordagem iterativa
e incremental para otimizar a previsibilidade e o controle de riscos. Trs pilares apoiam
toda implementao de processo emprico de controle: transparncia, inspeo e
adaptao.

Este pargrafo traz consigo um mundo de diferenas, pois controle emprico e


adaptao so inversamente opostos s estruturas tradicionais de gesto preditivas e de
comando e controle. No modelo preditivo todo o plano previsto em detalhes e com
antecedncia, predominando a partir da o modelo de comandar e controlar a realizao
das atividades conforme planejado antes de iniciar a execuo.

Bom, ser emprico e adaptativo o oposto de preditivo, acreditar em no fazer


toda a projeo do futuro, mas concentrar-se em realizar partes do todo, de modo a
aprender na prtica sobre o que se est fazendo, como se est fazendo e com quais
capacidades se conta no time e ento, ir adaptando tudo (a expectativa de produto final
pronto, utilizvel e rentvel seja l qual for sua medio de sucesso; o modo de
trabalho e principalmente a capacidade das pessoas envolvidas com o trabalho).

Esta mudana de paradigma no acontece por decreto, mas pelo uso


consistente de 3 pilares do Scrum, a transparncia, a inspeo e a adaptao. Vejamos.

5
Emprico, significa dizer que algo baseado do que foi experimentado ou visto ao invs de um dado
terico, presumido ou projetado

23
24 Agilidade nas empresas. Guia Scrum para quem no de TI.

Transparncia

Transparncia diz respeito ao fato de que aspectos significativos do processo


devem ser visveis para aqueles que so responsveis pelos resultados.
Transparncia requer que aspectos sejam definidos por um padro comum de modo
que os observadores compartilhem um mesmo entendimento do que est sendo visto.

Por exemplo:

Uma linguagem comum referindo-se ao processo de ser


compartilhada por todos os participantes e;
Uma definio comum de Pronto deve ser compartilhada por
aqueles que realizam o trabalho e por aqueles que aceitam o resultado do
trabalho.

Transparncia de aspectos importantes (o progresso de um trabalho em


andamento por exemplo) para aqueles que so responsveis pelo resultado (o dono
de algo que ser entregue e usado para trazer ganhos financeiros para a empresa por
exemplo) um pilar do Scrum muito relacionado s anlises de Takeuchi e Nonaka na
dcada de 80 onde estes sugeriram a sobreposio de fases (e tambm seus times
especialistas) originalmente estanques (menor interao) e sequenciais (uma fase
posterior somente comea com o fim integral da anterior), como forma de acelerao
dos resultados.

Para que isto seja verdade e realmente produtivo (esta sobreposio, este
paralelismo de trabalhos iterativos das equipes), necessrio que a forma de trabalhar
por todos seja comum e amplamente entendida, alm do que a definio de o que
significa estar pronto para uma equipe B seja o mesmo entendimento de estar pronto
para a equipe A. Voltando linha de produo, um time que espera uma roda
parafusada com toro suficiente para o carro pegar uma estrada, no pode receber
uma roda com parafusos apertados somente o suficiente para pendurar o pneu,
imaginando que passos posteriores fariam esta tarefa.

Exemplificando uma forma de transparncia, voc ver equipes Scrum


utilizando quadros branco, paredes ou ento painis digitais em software de trabalho
em equipe, visveis ao time de trabalho e aos responsveis pelo resultado, com
quadros Kanban indicando:
Transparncia 25

- o que h para o time de pessoas fazer trabalho que ainda no comeou,


- o que est sendo feito e em andamento neste momento e,
- o que j foi feito e est considerado pronto para entrega e no requer mais trabalho.

Tcnicas de quadro tipo Kanban (a fazer, fazendo, verificando e feito) e outros


quadros do tipo burn down chart (de tudo que temos para fazer, onde estamos hoje, o
que ainda falta para se fazer e at quando estar tudo feito) ou burn up chart (um
quadro acumulativo de o que j foi e o que est sendo gerado de benefcio), so
exemplos de ferramentas chamadas de Administrao vista. Ou seja, sempre vista
e transparente para os responsveis pelos resultados.

Exemplo de um quadro Kanban muito simples, com atividades que fluem da


coluna a fazer, para fazendo e indicando as finalizadas. O quadro Kanban d senso de
fluxo, de movimento e tambm de gargalos para o time.

Figura 1 quadro Kanban

Faa uso de um Kanban no seu dia-a-dia qualquer que seja o assunto (estudar
algo por exemplo) e confirme o senso de movimento que o Kanban proporciona. Se
quiser conhecer uma aplicao de Scrum na Educao por exemplo, veja o site
http://eduscrum.nl/en e faa suas analogias.

Exemplo de um quadro Burn Down, onde fica demonstrado a eterna luta


entre as linhas azul (esperado) e vermelha (realizado). Se elas esto juntas, ento o

25
26 Agilidade nas empresas. Guia Scrum para quem no de TI.

realizado est em linha com a expectativa. Se a linha vermelha est acima, ento o
trabalho est aqum da expectativa. Se a linha vermelha est abaixo da azul, ento o
trabalho est adiantado e pode terminar antes.

Figura 2 grfico de Burn Down

A prxima vez que voc tiver uma bateria de coisas a fazer em 10 dias
(exemplo da figura 2), faa um grfico de burn down e v plotando para acompanhar
como que a sua velocidade est em relao ao seu objetivo de terminar tudo em 10
dias.

Exemplo de um quadro Burn Up, onde fica demonstrado a expectativa do total


de benefcios que ser entregue at o final de n iteraes, Sprints ou time-boxes (a
linha vermelha), a linha azul com o trabalho que est completo iterao a iterao
(acumulado), a linha verde com uma projeo mdia das entregas at o ponto final e,
fotos do caminho em situaes hora alm do plano hora aqum do plano.
Transparncia 27

Figura 3 grfico de Burn Up

27
28 Agilidade nas empresas. Guia Scrum para quem no de TI.

Inspeo

Os usurios Scrum devem inspecionar frequentemente os artefatos Scrum e o


progresso rumo s metas da Sprint para detectar variaes indesejveis. As inspees
so mais benficas quando realizadas de forma diligente por inspetores
especializados no trabalho a ser verificado.

Inspeo um 2 pilar, pois pressupe uma proximidade constante do principal


responsvel pelos resultados, do time, dos trabalhos e principalmente dos resultados
intermedirios. Ao avaliar com frequncia o progresso e os resultados intermedirios,
pode ser possvel identificar variaes (entre a expectativa de resultado futuro um
skate rodando por exemplo, e a realidade que est se apresentando uma prancha de
madeira sem lixa e acabamento nas bordas por exemplo) o mais cedo possvel e
corrigir o rumo em tempo.

Quanto mais propriedade, interesse e responsabilidade sobre o produto final


esperado o revisor tiver (mais responsvel pelo benefcio resultante ele for), melhor e
mais criterioso ser seu interesse em fazer o acompanhamento do progresso. O time que
est atuando aproveita as inspees para entender se, na velocidade atual, o time
atingir todo o progresso esperado at o final da Sprint.

Vem da ento o conceito de time-box, um perodo pr-determinado de tempo,


para entregar uma parte ou uma verso intermediria de produto pronto e passvel de
uso pelo seu responsvel, j obtendo resultados e benefcios para a organizao e
obtendo feedback da efetividade do que j est em uso o melhor skate possvel dentro
de um perodo determinado de tempo.

Portanto, neste momento surgiram j alguns conceitos importantes, como:


Sprint, um tiro-curto de algumas semanas para entregar algo utilizvel; time-box, um
tempo determinado para durao das Sprints, o que traz previsibilidade para quem est
interessado no produto final e; velocidade, o ritmo com o qual o time est fazendo
entregas aceitas como prontas pelo principal interessado no resultado final dos
trabalhos.
Adaptao 29

Adaptao

Se um inspetor determina que um ou mais aspectos de um processo desviou para fora


dos limites aceitveis, e que o produto resultante ser inaceitvel, o processo ou o
material sendo processado deve ser ajustado. O ajuste deve ser feito o mais breve
possvel para minimizar mais desvios.

Neste trecho, com uma linguagem prxima de industrial, e trazendo agora para outros
contextos tambm, podemos dizer que ao se fazer inspees frequentes e transparentes
(pilares anteriores) pode ser constatado que o produto resultante do trabalho parece no
estar progredindo na direo entendida inicialmente e que poder no ser aceito como
pronto e entregue, requerendo que o time de trabalho faa adaptaes para corrigir o
rumo: quer seja, melhorando as definies do produto a ser entregue, refinando,
alinhando em maiores detalhes as expectativas (se os cantos do skate tem de ser
abaulados, se a lixa tem de ser integral no shape) ou; quer seja, alterando o modo como
o trabalho est sendo feito, retirando algum impedimento ou dificuldade que possa
aumentar a chance de entregar o produto final que j est claro (se a lixa no tem grip
suficiente, se a manipulao da madeira est tomando um tempo excessivo, etc).

De um modo ou de outro, o importante a destacar a vinculao do conceito de


inspeo frequente e transparente e, principalmente da capacidade de adaptao, ao
contexto do processo emprico, no qual se aprende com a execuo e se corrige (adapta)
o produto final e principalmente o processo de elaborao e as pessoas envolvidas, com
a observao (a inspeo) da realidade em andamento.

O Scrum prescreve quatro eventos formais para inspeo e adaptao, como descrito
na sesso de Eventos Scrum deste documento:

Reunio de Planejamento da Sprint


Reunio Diria
Reunio de reviso da Sprint
Retrospectiva da Sprint

Estes eventos sero descritos em detalhes frente, mas em resumo, eles so as seguintes
aes:

Planejar o que ser feito numa unidade determinada de tempo, uma Sprint;
Acompanhar diariamente o trabalho que est para fazer, sendo feito e o que j
est pronto;

29
30 Agilidade nas empresas. Guia Scrum para quem no de TI.

Rever e negociar que algo est considerado pronto pelo responsvel pelo
resultado final;
Rever as lies aprendidas na Sprint que acabou, e como elas podem ser
aproveitadas j no planejamento do que ser feito na prxima unidade de
tempo, na prxima Sprint.
Valores do Scrum 31

Valores do Scrum

Quando os valores de comprometimento, coragem, foco, abertura e respeito


esto incorporados e so vividos pelo time Scrum, os pilares de transparncia,
inspeo e adaptao do Scrum tornam-se vivos e criam confiana para todos. Os
membros do time Scrum aprendem e exploram estes valores enquanto trabalham com
os eventos, papis e artefatos Scrum.

O uso bem-sucedido do Scrum depende das pessoas tornarem-se mais


proficientes em viver estes cinco valores. As pessoas so comprometidas em atingir
as metas do time Scrum. Os membros do time Scrum tem coragem de fazer a coisa
certa e trabalhar em problemas difceis. Todos focam no trabalho da Sprint e nas
metas do time Scrum. O time Scrum e seus stakeholders concordam em ser abertos
sobre o trabalho e os desafios de fazer o trabalho. Os membros do time Scrum
respeitam-se mutuamente como pessoas capazes e independentes.

Esta sesso Valores foi acrescida agora na verso de Julho/2016 do Guia Scrum,
talvez at mesmo como uma forma de trazer luz e ateno ao grande desafio na
implementao de mtodos geis nas empresas, que tem sido amplamente relacionado
s mudanas culturais que acontecem.

Como toda mudana cultural, a responsabilidade primria pela mudana,


comea nas pessoas, as pessoas so os agentes da mudana que querem ver nas suas
organizaes, no existem outros organismos nas organizaes capazes de fazer a
mudana acontecer, s as pessoas envolvidas podem fazer isso, e os 5 valores vem
neste sentido. Vejamos como cada um dos 5 valores Scrum se encaixa em nosso dia-a-
dia:

Comprometimento: ou voc tem o compromisso pessoal com a


meta de usar e beneficiar sua empresa e por consequncia voc com o uso do
Scrum ou; voc contribui com o assunto quando requerido. Fazendo uma
analogia com a preparao de ovos mexidos com bacon para o caf da manh
da fazenda, comprometido est o porco que d o seu prprio corpo para gerar
o bacon enquanto a galinha contribui botando ovos. Ns podemos fazer isso
na nossa equipe tambm VS Depois me conta com foi a? Se precisar de algo
me fala, Ok?
Coragem: bom, depois da explicao do caf da manh com
ovos mexidos com bacon, talvez tenha ficado claro que voc precisa ter

31
32 Agilidade nas empresas. Guia Scrum para quem no de TI.

coragem para assumir uma postura de comprometimento, precisa ter coragem


para correr riscos e at sair da sua zona de conforto quentinha e agir no frio
da experimentao. Vamos combinar uma durao de 3 semanas e comear a
repetir isso algumas vezes at sabermos se foi o melhor time-box para ns e
compartilharmos com os demais times os resultados VS Depois de definido
corporativamente vamos analisar a aplicabilidade ao nosso cenrio.
Foco: como dito anteriormente que o Scrum fcil de entender
e difcil de praticar, preciso ter foco para fazer ao menos uma coisa diferente
de cada vez, poder conscientizar-se da mudana, dos benefcios intermedirios e
ento incorporar novas prticas, como novos hbitos. Ns temos feito reunies
dirias sobre o trabalho em andamento e todos esto mais cientes de tudo,
depois comeamos a colocar a informao visvel para todos, isto tem
melhorado a comunicao entre as pessoas, o fato de sempre terminarmos algo
concreto em tempos determinados, tem dado um senso de ritmo para o time
VS So tantas coisas novas a fazer que no sei por onde comeo, Melhor
no mexer agora.
Abertura: bom, de novo, por isso que os valores so um bloco
de 5 mudanas, se voc no estiver aberto a mudanas, aberto a fazer pequenas
mudanas na sua rotina e incorporar o pensamento de que melhoria contnua
possvel e que voc est aberto a isso, voc continuar parado, fixo e talvez
defendendo um status-quo que talvez voc no tenha mais. Eu tenho feito as
minhas tarefas usuais A, B e C e reportado o progresso num mapa na parede
do meu lado para que todos possam acompanhar a minha fila de trabalho VS
Prefiro ver os resultados de alguns testes antes de comear a mudar.
Respeito: de modo similar, permita entender que mesmo voc
estando comprometido, focado e corajosamente aberto a aprender novas
prticas, nem todas as pessoas ao seu redor, no seu crculo de relacionamento
podero estar no mesmo nvel de aceitao mudana, mesmo voc entendendo
e comprando ou fazendo buy-in dos benefcios da mudana. Portanto, vale
entende-las, respeit-las e ajud-las e ver tambm elas o benefcio, bem como
meios de fazer a transio para mtodos geis tambm do ponto de vista desta
outra pessoa. Vou compartilhar os benefcios que eu estou tendo com os
demais como forma de exemplo e deixar que eles percebam, do ponto de vista
deles, que possvel mudar e melhorar tambm VS Vou demonstrar os meus
resultados para forar que os outros mostrem os deles tambm.
O time Scrum 33

O time Scrum

O time Scrum composto de um Product Owner o dono do Produto, do time


de Desenvolvimento e de um Scrum Master o mestre Scrum. Times Scrum so auto
organizveis e multifuncionais. Times auto organizveis escolhem qual a melhor forma
para completar o seu trabalho, ao invs de serem dirigidos por outros de fora do time.
Times multifuncionais possuem todas as competncias necessrias para completar o
trabalho sem depender de outros que no fazem parte do time. O modelo de time no
Scrum projetado para aperfeioar a flexibilidade, a criatividade e a produtividade das
pessoas.

Os papis de Dono de Produto e Scrum Master sero explicados


individualmente, ento vamos nesta parte direto ao ponto central da auto-organizao e
multifuncionalidade dos times Scrum, pois onde reside uma ruptura grande de
modelos, entre a estrutura de comando e controle - de certo modo relativamente mais
comumente conhecida e utilizada em mltiplas indstrias, e entre a estrutura de auto-
organizao. Para falar destes dois paradigmas mas com outras palavras tire voc
tambm as suas prprias concluses, vamos recorrer um trabalho da dcada de 50 do
professor e economista Americano Douglas McGregor intitulado Aspectos Humanos na
Empresa.

MgGregor escreveu sobre as Teorias X e Y, dois conceitos antagnicos que


norteiam as relaes entre as empresas e os trabalhadores, tratando dois perfis de
personalidade e comportamento de funcionrios, que muitas vezes os prprios
indivduos no percebem que possuem. Em uma das teorias o funcionrio relaxado,
preguioso e gosta pouco de trabalhar, precisando de comando e controle. J na outra, o
funcionrio gosta de responsabilidade e a busca ele mesmo dentro da empresa.

Se voc j conhece as Teorias X e Y de McGregor no perca seu tempo e v


direto concluso.

33
34 Agilidade nas empresas. Guia Scrum para quem no de TI.

Figura 4 Teorias X e Y

-/ -/ -/

Teoria X O trabalho em si mesmo desagradvel para a maioria das


pessoas

Nesta teoria, chamada por McGregor de Hiptese da mediocridade das


massas, parte-se do pressuposto de que os trabalhadores possuem averso nata
responsabilidade e s tarefas do trabalho, necessitando sempre de ordens superiores para
render no trabalho. Ordens acompanhadas de punio, elogios, dinheiro, coao, etc.;
artifcios utilizados pelos gestores para tentar gerar um empenho maior do colaborador.

McGregor acreditava que as necessidades de ordem inferior6 dominavam as


pessoas nesta Teoria. Assim, as organizaes precisavam colocar a nfase de sua gesto
na satisfao dos fatores higinicos dos trabalhadores, estudados na Teoria dos Dois
Fatores de Herzberg.

Os princpios bsicos da Teoria X so:

6
Lembrar que necessidades de ordem inferior do Herzberg no significam serem menos importantes,
significam serem menos duradouras e ainda externas pessoa, necessitando outro estmulo externo
logo para continuar motivado geram dependncia; enquanto que necessidades superiores na escala
de Herzberg, significam motivaes mais prprias ou internas pessoa, mais duradouras e mais auto
motivadoras independentemente de outros estmulos externos gerem independncia.
O time Scrum 35

Um indivduo comum, em situaes comuns, evitar sempre que


possvel o trabalho;
Alguns indivduos s trabalham sob forte presso. Eles precisam ser
forados, controlados e s vezes ameaados com punies severas para que se esforcem
em cumprir os objetivos estabelecidos pela organizao;
O ser humano ordinrio preguioso e prefere ser dirigido, evita as
responsabilidades, tem ambies e, acima de tudo, deseja sua prpria segurana.

Teoria Y O trabalho to natural como o lazer, se as condies forem


favorveis.

Nesta teoria a coisa muda de figura. Aqui os trabalhadores so encarados como


pessoas altamente competentes, responsveis e criativas, que gostam de trabalhar e o
fazem como diverso. Sendo necessrio que as empresas proporcionem meios para que
estas pessoas possam dar o seu melhor, com mais desafios, participaes e influncias
na tomada de deciso. McGregor acreditava que as necessidades de ordem superior
dominavam as pessoas nesta Teoria.

Os princpios bsicos da Teoria Y so:

O esforo fsico e mental empregado no trabalho to natural quanto o


empregado em momentos de lazer
O atingimento dos objetivos da organizao est ligado s recompensas
associadas e no ao controle rgido e s punies;
O indivduo comum no s aceita a responsabilidade do trabalho, como
tambm a procura;
Os indivduos so criativos e inventivos, buscam sempre a soluo para
os problemas da empresa;
Os trabalhadores tem a capacidade de se auto gerirem nas tarefas que
visam atingir objetivos pessoais e estratgicos da organizao. Sem a necessidade de
ameaas ou punies;
O trabalhador normalmente no faz aquilo que no acredita. Por isso
exige cada vez mais benefcios para compensar o incmodo de desempenhar uma
funo desagradvel.

Desta forma, podemos perceber que na Teoria X o indivduo motivado pelo


menor esforo, demandando um acompanhamento maior por parte do lder. J na Teoria

35
36 Agilidade nas empresas. Guia Scrum para quem no de TI.

Y, as pessoas so motivadas pelo mximo esforo, demandando uma participao maior


nas decises e negociaes inerentes ao seu trabalho.

-/ -/ -/ fim da citao

Ou seja, voltando ao nosso tema, o paralelo feito aqui entre mtodos


tradicionais de comando e controle e pessoas do tipo X e, entre mtodos geis como o
Scrum de times auto organizveis e multifuncionais e pessoas do tipo Y. Suspendendo o
julgamento se um modelo melhor que o outro, o fato que temos que so padres
distintos.

importante destacar do texto acima sobre as teorias X e Y de McGregor,


somados aos Dois Fatores de Herzberg, que estes so perfis comportamentais pessoais e
individuais, que muitas vezes ns nem sabemos que temos. Portanto, sem a
oportunidade de se examinar e de conhecer a si prprio, podem vir grandes problemas
com as grandes responsabilidades de usar Scrum nos nossos times.

Imagine quanto de conflito existir num cenrio de um gestor do tipo X (as


pessoas precisam ser controladas) que tenha um time de pessoas todas Y praticando
Scrum! O time supostamente vai adotar as novas responsabilidades e vai buscar acelerar
em produtividade. Mas, como ser que ficar o gestor controlador com um time Y em
um ambiente que proporciona ser auto gerencivel?

Num cenrio inverso, como ser um time de pessoas X (o trabalho


desagradvel e precisa ser evitado) que agora se v diante do contexto de ter de ser
auto gerencivel e ter de buscar meios por s prprio de atingir as metas da empresa, do
time e pessoais, sem estmulos forados de comando e controle para os quais estavam,
eventualmente, at habituados.

Novamente, independentemente do juzo de valor sobre os padres de


comportamentos X e Y, o fato que ns os temos. Algumas pessoas so mais
destacadas num deles, outras flutuam entre X e Y de acordo com o ambiente, a
necessidade e a convenincia. Outras pessoas podem no saber como so, como atuam.
importante saber que estes padres comportamentais existem e vo influenciar voc e
o time nas suas aes dirias, muitas vezes sem voc perceber7.

Adicionalmente, este pargrafo do Guia do Scrum tambm fala de o time Scrum


ser multifuncional, o que tambm pode ser uma ruptura das estruturas hierrquicas
tradicionalmente agrupadas por funo e isolada em silos, com interaes definidas

7
H uma frase atribuda a Carl Gustav Jung que diz, At voc se tornar consciente, o seu inconsciente
vai dirigir sua vida e voc vai chamar isso de destino. Ento, estude-se.
O time Scrum 37

atravs de processos de acione (abertura de chamados, tickets, demandas, acordos de


nveis de servio, etc).

Segundo o Guia, um time Scrum multifuncional e possui dentro do time,


toda a competncia necessria para completar o trabalho e entregar o produto final ao
dono do produto, sem depender de outras pessoas, outros times ou reas que no faam
parte do time.

Este passo da multifuncionalidade um desafio para que as empresas passem a


utilizar-se dos benefcios do Scrum, onde profissionais especialistas de times funcionais
diferentes, tem de deixar os seus silos e juntar-se a outras pessoas (de tipos X e Y
misturados e desconhecidos), para realizar tarefas no somente as relacionadas sua
funo origem, deixando talvez a zona de conforto onde estava, para pisar num local
fora do conforto habitual, um local l fora, onde ocorre a aprendizagem e o
desenvolvimento pessoal.

Um exemplo de multifuncionalidade que vem ocorrendo na prtica e de forma


cada vez mais frequente nas empresas e eu no vou me aprofundar demais neste
parntesis para ser coerente com o pblico no Tecnologia, a organizao do time de
TI (Tecnologia da Informao) de forma conjunta entre desenvolvimento de sistemas e
operaes da infraestrutura (Development & Operations).

Por dcadas estas 2 reas das organizaes de TI trabalham seguindo estratgias


distintas e de certo modo conflitantes. Development tem normalmente 2 objetivos
primrios de manter os servios de TI em produo, mas principalmente, desenvolver
novos servios de TI alterando os atuais em resposta s necessidades das reas de
negcios ou suporte que demandam servios. A estratgia de Dev, que quanto mais
rpido puder mudar para atender a operao, melhor. Operations trabalha habitualmente
sobre a tica de manter em operao o que est em produo. A estratgia de Ops que
quanto menos mudar e mais estvel ficar, melhor.

Em linhas gerais, voc deve ter percebido o conflito das 2 estratgias entre
mudar e manter. Um pilar de agilidade que vem auxiliar no carcter de equipes
multifuncionais, o fato de um nmero crescente de empresas estar adotando uma
estratgia denominada DevOps (significando Development and Operations juntos).
Onde um time com pessoas oriundas de funes de Desenvolvimento de Sistemas e
tambm de Operaes da Infraestrutura de TI, trabalham juntas num time nico para
entregar o trabalho necessrio.

37
38 Agilidade nas empresas. Guia Scrum para quem no de TI.

Fechando o parntesis do exemplo de DevOps, citei somente para exemplificar


a voc que times multifuncionais vo trazer tambm mudanas nas estruturas
organizacionais e como tal, precisaro ocorrer com alinhamento estratgico e apoio da
alta direo. No ser suficiente que os profissionais estejam corajosamente
comprometidos em trabalhar de um modo novo, se a direo da empresa no estiver
aberta a patrocinar uma estrutura diferente, mais enxuta.

Depois de um longo trecho, voltemos ao Guia.

Times Scrum entregam produtos de forma iterativa e incremental, maximizando


as oportunidades para aprender com a experincia. Entregas incrementais de
produtos Prontos garantem que uma verso potencialmente funcional do produto
esteja sempre disponvel.

Adicionalmente s equipes serem auto gerenciveis e terem mltiplas


capacidades, o fato de times Scrum trabalharem em Sprints (perodos determinados de
tempo time-box), faz com o que os produtos resultantes do seu trabalho sejam
entregues de forma incremental (aos pedaos, em verses intermedirias com as
funcionalidades mais importantes primeiro), seguido de entregas posteriores de outras
verses mais evoludas e com mais funcionalidades.

Retorna neste pargrafo do Guia, o carcter emprico do Scrum, de aprender


com a experincia, ou seja, entregar algo completo o suficiente mas j pronto para uso e
aprender com o feedback de quem passou a utilizar as primeiras funcionalidades,
melhorando a chance de assertividade das prximas entregas.

Importante destacar tambm o objetivo de ter sempre algo potencialmente


funcional que esteja sempre disponvel citado no Guia, o que me remete ao ambiente
de negcios citado na introduo do livro, de que os Servios acabam sendo to ou at
mais importantes que os Produtos.

Dizem que o Gmail, servio de e-mails grtis do Google, ficou anos talvez
esteja at hoje, em verses beta (de testes), sempre potencialmente funcional e sempre
disponvel e pronto.

H uma lgica desencadeada pelo Scrum: um produto potencialmente funcional


(j despertando o interesse atravs das funcionalidades mais importantes entregues
primeiro), sempre disponvel ( disposio para ser usado e receber feedback por isto),
evoludo de forma incremental (constantemente recebendo novos investimentos em
O time Scrum 39

importantes funcionalidades) e iterativa (que aprende a partir do feedback recebido de


quem j est usando e obtendo benefcio e retorno financeiro8).

O time Scrum ento responsvel por seguir entregando em tempos pr-


determinados (Sprints time-box) evolues funcionais cada vez maiores do produto e
com mais velocidade, sempre em acordo com o principal responsvel por direcionar o
rumo do produto, o dono do produto.

8
Isto me lembra do movimento feito pelo Google criando a sua holding Alphabet, tendo como
significado a mais pura gesto de portflio, onde Alpha significa o investimento de melhor retorno de
uma carteira e Bet significa aposta. Eles apostam alto. Veja mais em http://abc.xyz

39
40 Agilidade nas empresas. Guia Scrum para quem no de TI.

O Product Owner

O Product Owner o Dono do Produto, responsvel por maximizar o valor do


produto e do trabalho do time de desenvolvimento. A forma como isso feito pode
variar amplamente atravs das organizaes, dos times Scrum e dos indivduos.

Vamos pensar num servio de ingressos online para sesses de cinema onde
as pessoas gostariam da comodidade de poder apresentar seus ingressos atravs de um
App nos seus prprios celulares. Em termos de rentabilidade para a rede de cinemas,
no vai adiantar muito o time Scrum entregar uma soluo impecvel de impresso de
tickets em papel com cores vibrantes, etc, etc. Se, o interesse do pblico era ter um
simples ticket no celular que possa ser carregado no bolso e apresentado para ingressar
no cinema, lido atravs de um QR Code.

Neste cenrio, entregar uma soluo correta, rpida, estvel e confivel de


tickets responsabilidade do time Scrum e seu Scrum Master, mas responsabilidade
primordial do Dono do Produto que a soluo seja amplamente percebida pelos
visitantes do cinema como til e valiosa a estes, que a soluo seja mais um dos
diferenciais da rede de cinemas e que a soluo possa contribuir ativamente em ajudar
os clientes a optar por uma rede de cinemas em detrimento de outras redes, na hora da
sua atividade de lazer. Pode ser uma deciso at subliminar e imperceptvel para o
cliente, mas pode ajudar a fazer diferena para a rentabilidade da rede de cinemas.
Maximizar o retorno sobre os investimentos da rede de cinemas em tecnologia,
responsabilidade do Dono do Produto. Papis distintos, responsabilidades claras.

O Dono do Produto, a nica pessoa responsvel por gerenciar o Backlog do


Produto. O gerenciamento do Backlog do Produto inclui:

Expressar claramente os itens do Backlog do Produto;


Ordenar os itens do Backlog do Produto para alcanar melhor as
metas e misses;
Otimizar o valor do trabalho realizado pelo time de
Desenvolvimento;
Garantir que o Backlog do Produto seja visvel, transparente,
claro para todos e que mostra no que o time Scrum vai trabalhar a seguir; e
Garantir que o time de Desenvolvimento entenda os itens do
Backlog do Produto no nvel necessrio de detalhe.
O Product Owner 41

Como foi dito no Glossrio, backlog uma lista de coisas a fazer. No caso,
uma lista de coisas novas que o Produto ou o Servio do qual o Dono do Produto
responsvel precisar fazer em algum momento no tempo, breve ou mais frente. O
Dono do Produto pode utilizar-se de vrias ferramentas para chegar s definies de o
que esperado do Produto ou Servio. Desde pesquisas de mercado, focus groups,
legislao, benchmark e at mesmo sua intuio pessoal.

importante o Dono do Produto preocupar-se com a clareza da comunicao


que est fazendo ao time de desenvolvimento9.

Para obter o mximo valor do investimento feito com o time de


desenvolvimento, importante que os itens de backlog do produto sejam priorizados
com a mais alta prioridade dada para os itens que mais trazem resultados para os
usurios do produto ou servio. O dono do produto precisar deixar claro para o time de
desenvolvimento que devemos definir em detalhes agora para um certo time-box, uma
Sprint, uma Iterao prxima de comear, um item de backlog do produto, de um jeito
que seja minimamente vivel para iniciar o uso assim que estiver pronto mas; que h
uma linha de evoluo clara para novos itens e tambm evolues dos itens j
entregues.

Um suposto servio de locomoo diria individual e uso compartilhado em


grandes cidades, pode comear com um skate compartilhado entre amigos, uma
agenda unificada para fazer as reservas, passar por bikes disponveis em
estacionamentos prximos de estaes do Metr, expandir-se para uso de carros
compartilhados retirados e entregues em postos similares e chegar a carros autnomos,
solicitados via App no celular que te recebem e te deixam nos locais solicitados
enquanto voc l, descansa, se alimenta, etc.

O Dono do Produto, deve fazer o trabalho acima, ou delegar para o time de


Desenvolvimento faz-lo. No entanto, o Dono do Produto continua sendo o
responsvel pelos trabalhos.

9
H uma regra na comunicao de que a responsabilidade sobre o entendimento correto da mensagem
do emissor, ok?

41
42 Agilidade nas empresas. Guia Scrum para quem no de TI.

Figura 5 O Product Owner (PO)

Diferentemente da figura acima, o Dono do Produto / Product Owner (PO), no


precisa ter superpoderes e fazer todo o trabalho, mas ele precisa ter superpoderes e
usar todas as suas habilidades de trabalho em equipe e trabalho colaborativo com o
Time Scrum, pois no bottom line, ele o responsvel pela rentabilidade do produto.

Brincadeiras parte, o Dono do Produto trabalha mesmo muito, pois ele tem de
estar junto ao time Scrum sempre que requerido pelo time, esclarecendo algo e
refinando algum conceito e precisa tambm estar trabalhando nos prximos passos que
viro, trabalhando sempre que necessrio e factvel no backlog do Produto.

O Dono do Produto, uma pessoa, no um comit. O Dono do Produto pode


representar os desejos de um comit no Backlog do Produto, mas aqueles que
quiserem uma alterao nas prioridades dos itens de Backlog, devem convencer o
Dono do Produto.

Para que o Dono do Produto tenha sucesso, toda a organizao deve respeitar
as suas decises. As decises do Dono do Produto, so visveis no contedo e na
prioridade do Backlog do Produto. Ningum tem permisso para falar com o time de
Desenvolvimento sobre diferentes configuraes de requisitos, e o time de
Desenvolvimento no tem permisso de agir sobre o que outras pessoas disserem
que no o Dono do Produto.

Importante esta questo de que o PO uma pessoa, no um comit. E


continuar sendo comum o Dono do Produto precisar de n pessoas e at n comits
para obter aprovaes para suas ideias de novos produtos e as suas evolues. Mas,
O Product Owner 43

cumprido estas atividades do Dono do Produto como sendo um proxy, um


representante, de comits internos, focus groups, pesquisas pblicas e de mercado,
aprovaes junto a rgos reguladores e qualquer outra atividade de gesto de
stakeholders (pessoas interessadas) que continua sendo necessria ser feita, o Dono do
Produto a fonte da verdade para o time Scrum. Se o Dono do Produto seguiu todos os
passos corporativos e regulamentares para aprovar uma ideia ou, se o Dono do Produto
teve um insight e passou a ideia direto para o time de Scrum, por sua conta e risco,
valer para o time Scrum a definio do Dono do Produto. Faz parte do
empoderamento ser assim10.

O time de desenvolvimento Scrum tem a obrigao de fazer o seu trabalho


alinhado com as decises do Dono do Produto. O Dono do Produto tem a obrigao de
fazer o melhor uso possvel da fora de trabalho do time de desenvolvimento Scrum e
de fazer o seu trabalho alinhado com as demais partes interessadas interna e
externamente organizao. Novamente, papis distintos, responsabilidades claras.

10
J dizia o Super Heri, que com grandes poderes vem grandes responsabilidades, pois o papel do
time de Desenvolvimento entregar certo, rpido e mais. O Dono do Produto precisa saber o que pedir.

43
44 Agilidade nas empresas. Guia Scrum para quem no de TI.

O Time de Desenvolvimento

O Time de Desenvolvimento consiste de profissionais que realizam o trabalho


de entregar uma verso potencialmente utilizvel, incrementando o produto Pronto
ao final de cada Sprint. Somente os integrantes do time de desenvolvimento criam
incrementos de produto.

O time de desenvolvimento quem executa o trabalho que produz uma verso


potencialmente utilizvel de um novo incremento de produto pronto. Nossa, quantos
termos e conceitos, vamos por partes.

Como o objetivo que o time seja multifuncional (lembra-se?), durante uma


Sprint, ele produz uma parte com incio, meio e fim do produto esperado, de modo que
esta entrega possa ser utilizvel por quem o Dono do Produto representa.

Como uma meta a alcanar, as entregas de produtos intermedirios realizadas


Sprint a Sprint, tem o objetivo de serem potencialmente utilizveis. Pode acontecer de
no espao de tempo (padronizado, time-box) de 2 ou 3 Sprints por exemplo, no ser
possvel produzir-se algo efetivamente utilizvel na forma de um produto final
comercializvel por exemplo. Esta, falha semntica digamos, no invalida a lgica
maior de fazer entregas parciais, recorrentes, validadas de forma incremental (cada vez
com mais funcionalidades consideradas prontas para uso) e ir juntando
funcionalidades at que uma verso maior seja efetivamente liberada para uso pblico.

Por ir juntando funcionalidades voc pode entender, e esperar tambm, que as


entregas das primeiras Sprints de um trabalho possam ser itens mais relacionados a
infraestrutura e a arquitetura da soluo, como forma de alicerce sobre o qual ser
formado um produto com n funcionalidades que interessam ao Dono do Produto.

Outra possibilidade de ir juntando funcionalidades quando a empresa tem


uma viso clara de administrao dos seus servios por processos, com passos de
oferecimento, originao / iniciao, processamento / efetivao, finalizao /
liquidao, controles e contabilizaes. Talvez uma entrega inicial de um servio possa
atender ao passo de oferecimento, mas no permita iniciar negcios o que pode ser ou
frustrante para o cliente ou deix-lo motivado a conhecer mais do servios e vir a
contrat-lo. Assim como pode ser um desafio para o Dono do Produto ter uma
funcionalidade que inicie negcios mas que no os processe, liquide e contabilize de
forma automtica. Em qualquer uma das situaes, o Dono do Produto precisa de uma
viso dos Processos de Negcios e das Operaes que esto consumindo o servio, para
O Time de Desenvolvimento 45

tomar decises sobre qual o produto que minimamente vivel, j traz exposio ao
mercado e resultados, com riscos controlados para a operao do negcio.

H tambm outra razo de ir juntando funcionalidades mas vamos explorar l


no trecho de cancelamento de Sprint.

Os times de Desenvolvimento so estruturados e autorizados pela organizao


para organizar e gerenciar o seu prprio trabalho. A sinergia resultante otimiza a
eficincia e a eficcia do time de Desenvolvimento como um todo.

Os times de Desenvolvimento tem as seguintes caractersticas:

Eles so auto-organizados. Ningum (nem mesmo o Scrum


Master) diz ao time de Desenvolvimento como transformar o Backlog do
Produto em um incremento de funcionalidade potencialmente utilizvel;

Importante esta parte de que o time de desenvolvimento que faz o trabalho,


ele que transforma o Backlog do Produto em um incremento de funcionalidade
utilizvel. Importante entender estas duas instancias de coisas, sendo o Backlog do
Produto de responsabilidade do Dono do Produto e o incremento de funcionalidade
de responsabilidade do time de desenvolvimento.

O backlog do produto pode ser algo de alto nvel, definido pelo dono em termos
mesmo que genricos e amplos, sejam claros e desafiadores. Exemplo (um shape de
skate com desenho diferenciado do mercado que ajuda a manter os ps do skatista
preso prancha).

O incremento de funcionalidade deve ser algo especfico, definido e produzido


pela equipe de desenvolvimento na forma de algo que possa ser efetivamente utilizvel
pelo Dono do produto ou, ainda, pelo pblico alvo almejado (uma prancha de madeira
cortada no tamanho certo, de peso adequado para manuseio, com densidade forte o
suficiente para resistir a tores e impactos de pessoas at 100 kilos, que proporcione
bom grip ao praticante que vai us-la pela parte superior e que proporcione fixao
firme e duradoura do eixo na sua parte inferior).

O Time de Desenvolvimento no deve eximir-se de detalhar o incremente, mas


sim, agregar o seu valor de especialista.

Times de Desenvolvimento so multifuncionais, possuindo todas


as habilidades necessrias enquanto time, para criar o incremento do Produto;

45
46 Agilidade nas empresas. Guia Scrum para quem no de TI.

O Scrum no reconhece ttulos para os integrantes do time de


Desenvolvimento que no seja o Desenvolvedor, independentemente do
trabalho que est sendo realizado pela pessoa. No Scrum, no h excees
para esta regra;
O Scrum no reconhece sub-times no time de Desenvolvimento,
independentemente de domnios que precisam ser endereados tais como
testes ou anlise de negcios. No Scrum, no h excees para esta regra, e;
Individualmente os integrantes do time de desenvolvimento
podem ter habilidades especializadas e reas de especializao, mas a
responsabilidade pertence ao time de Desenvolvimento como um todo.

Acabamos j adiantando informao sobre o time de desenvolvimento nas


partes que falamos de times auto organizados e multidisciplinares. Vale destacar aqui a
importncia da caracterstica de time (todos jogando juntos na mesma direo) e da
condio de interdependncia entre os integrantes para que a potencializao da
produtividade e criatividade do time seja mxima. Novamente baseado em
conhecimentos da teoria dos mltiplos canais de comunicao possveis num grupo, o
Guia Scrum ir preconizar times pequenos, vamos falar o porqu disto em detalhes.
O tamanho do Time de Desenvolvimento 47

O tamanho do Time de Desenvolvimento

O tamanho ideal do time de Desenvolvimento pequeno o suficiente para


manter-se gil e grande o suficiente para completar uma parcela significativa de
trabalho dentro de uma Sprint. Menos de 3 integrantes no time de Desenvolvimento
diminuem a interao e resultam em um menor ganho de produtividade. Times de
Desenvolvimento pequenos podem encontrar restries de habilidades durante a
Sprint, gerando um time de Desenvolvimento incapaz de entregar um incremento
potencialmente utilizvel. Havendo mais de nove integrantes exigido muita
coordenao. Times de Desenvolvimento grandes geram muita complexidade para um
processo emprico gerenciar. Os papis de Dono do Produto e Scrum Master no so
includos nesta contagem, a menos que eles tambm executem o trabalho do Backlog
da Sprint.

Ufa, vamos l. Pequeno o suficiente ... e grande o suficiente ... para manter a
comunicao mais ativa possvel, essa a preocupao do Guia. Vejamos:

Ponto 1) convenhamos, a chance de um par de pessoas conseguir ser


multifuncional de modo a desenvolver algo do incio at o fim e entregar um produto
efetivamente pronto e operacional pequena, pouco provvel e at improdutivo, dado a
necessidade de tantos papis que temos hoje em dia, providos por somente 2 pessoas,
por isso da recomendao (do entendimento) que na prtica um time mnimo comece
com ao menos 3 pessoas. Ponto 2) pode ser que 3 pessoas em mltiplos papis vo
gerar trabalho em uma velocidade inferior ao que poderia ser considerado um ritmo
vivel economicamente. Ponto 3) Seguindo a lei da natureza de que 9 mulheres no
fazem a gestao de 1 criana em 1 ms, mesmo que fossem infinitos os recursos
financeiros (R$) nas nossas empresas, a quantidade de recursos humanos no seria
exatamente infinita, ainda; Ponto 4) onde o Guia Scrum quer chegar com um nmero
mgico para o tamanho do time?

O que h por trs deste alerta de que quanto mais pessoas, maior a dificuldade
de coordenao11?

- Valor do Manifesto gil que diz interao entre pessoas sobre processos e
ferramentas;
- Princpio do Manifesto gil que diz o mtodo mais eficiente e eficaz de transmitir

11
Voc tem o hbito de participar de assembleias de condomnio? Faa um paralelo.

47
48 Agilidade nas empresas. Guia Scrum para quem no de TI.

informao a conversa face-a-face;


- Regra da teoria da comunicao que diz que o nmero de canais de comunicao
cresce conforme o grupo aumenta, entre 3 pessoas por exemplo, h 3 canais de
comunicao, 4 pessoas so 6 canais, 5 pessoas 10 canais, 6 so 15, 7/21, 8/28, 9/36 e
10/45.

Em resumo, quanto mais pessoas juntas, mais difcil manter a comunicao


boa com tantos canais possveis de a comunicao se estabelecer. A confuso aumenta e
a produtividade que havia atingido um patamar ideal com um time menor do que 10
pessoas, cai.

A maioria das recomendaes de que os times Scrum tenham de 3 a 5 pessoas, o


importante a considerar que poucas pessoas vo produzir pouco trabalho e muitas pessoas
juntas vo dificultar a comunicao. Caber ao Scrum Master encontrar o equilbrio entre a
quantidade de pessoas e a velocidade de produo.
O Scrum Master 49

O Scrum Master

O Scrum Master responsvel por garantir que o Scrum seja entendido e


aplicado. O Scrum Master faz isto para garantir que o time Scrum aderiu s teorias,
prticas e regras do Scrum.

O Scrum Master um lder servidor para o time Scrum. O Scrum Master ajuda
que est fora do time Scrum a entender quais das suas interaes com o time Scrum
so teis e quais no so. O Scrum Master ajuda todos a mudar estas interaes para
maximizar o valor criado pelo time Scrum.

O Scrum Master o profissional responsvel por fazer com que este framework
de gesto gil chamado Scrum seja entendido e praticado no dia a dia das organizaes.
Em seu(s) time(s) Scrum, numa rea, numa empresa, num mercado. um profissional
que tem um papel de ser um apoiador para que os outros papis executem bem as suas
prprias responsabilidades. um resolvedor de problemas e um otimizador de pessoas e
processos em benefcio da organizao. Bom, no algum do tipo X (lembra-se?). No
algum de TI. No aplicvel somente a TI. Vamos voltar este tema ao falar do
planejamento da Sprint.

O Scrum Master servindo ao Product Owner

O Scrum Master serve ao Dono do Produto de vrias maneiras, incluindo:

Encontrando tcnicas para um efetivo gerenciamento do Backlog


do Produto;
Ajudando o time Scrum a entender a necessidade de Backlogs
de Produto claros e concisos;
Entendendo o planejamento de produto em um ambiente
emprico;
Garantindo que o Dono do Produto sabe como organizar o
Backlog do Produto de forma a maximizar o valor;
Entendendo e praticando agilidade; e,
Facilitando os eventos Scrum quando requerido ou necessrio.

Resumindo, aquela pessoa da capa:

49
50 Agilidade nas empresas. Guia Scrum para quem no de TI.

Figura 06 Scrum Master (SM)

So mesmos tantas atribuies do Scrum Master que ele(a) precisa mesmo ser
algum do tipo Y para no entrar em pnico com tantos desafios!

Se o Dono do Produto no est conseguindo chegar a termo com um Product


Backlog, tem que auxili-lo com tcnicas que possam fazer com que o PO chegue
boas decises e que estas decises possam agregar valor, ou ento pode faltar tijolo na
obra, faltar o que o time fazer.

Se o time no entende os Product Backlogs do PO, podemos ter itens no


aceitos como prontos, gerando retrabalho, menor produtividade, confuso,
desperdcio e desgaste.
O Scrum Master 51

Se no h como demonstrar planos de como estamos indo e para onde estamos


indo (grficos de Burn Down e Burn Up por exemplo, lembra-se?). Com qual
informao a organizao ser comunicada? Como ficar a transparncia?

Se a Agilidade no praticada pelo Scrum Master para servir de exemplo, ento


como ficar a relao de confiana com o Dono do Produto e o time Scrum? S no
discurso? Produtiva12?

Scrum Master servindo ao Time de Desenvolvimento

O Scrum Master serve ao time de Desenvolvimento de vrias maneiras,


incluindo:

Treinando o time de Desenvolvimento em auto-organizao e


interdisciplinaridade;
Ajudando o time de Desenvolvimento a criar produtos de alto
valor;
Removendo impedimentos ao progresso do time de
Desenvolvimento;
Facilitando os eventos Scrum quando requerido ou necessrio;
e,
Treinando o time de Desenvolvimento em ambientes
organizacionais nos quais Scrum no totalmente adotado e entendido.

Ser Master no Scrum me arrisco a dizer que em Japons13 poderamos chamar


de Sensei (pois um ttulo honroso para tratar com respeito um professor ou mestre).
Em Ingls fica mais fcil contextualizar como Coach (um treinador ou instrutor).

Independente da nomenclatura, a questo que ele tem de ser um facilitador do


time, um tcnico, um treinador, um mestre nos mtodos geis para que a prtica do
time Scrum, e na empresa especificamente, possa confirmar a teoria e trazer agilidade
para a organizao.

12
Voc sabe que a confiana um acelerador nas negociaes no sabe? Voc se recorda de situaes
onde negociou a manuteno do seu carro ou da sua casa com profissionais nos quais voc tinha total
confiana e com profissionais nos quais voc no podia confiar? Qual foi o seu nvel de controle e de
stress nestes 2 contextos?
13
Definies em www.significados.com.br/sensei e www.significados.com.br/coach

51
52 Agilidade nas empresas. Guia Scrum para quem no de TI.

responsabilidade do Scrum Master fazer o time ser cada vez mais rpido,
produtivo, de alta performance cada nova Sprint. Motivos para enxergar
impedimentos performance e a excelncia, muitos tero nos times, mas compete ao
Scrum Master auxiliar o time a remover os impedimentos, otimizando e acelerando a
performance do time14.

Com a atuao na ponta Dono do Produto o Scrum Master ajuda o Dono do


Produto a gerar itens de backlog do produto que vo agregar valor. Com a atuao na
ponta Time Scrum o Scrum Master ajuda o time a gerar os incrementos de produto de
modo eficiente. A soma das duas atuaes gera eficcia e traz resultados para a
organizao.

Bom, fechando o assunto time, h um pensamento que diz que um time no


um grupo de pessoas que trabalham juntas, um grupo de pessoas que confiam uns nos
outros ento s mesmo sendo um sensei coach.

14
Outra aluso tambm, que o Scrum Master algum que passou a atuar como agente de
transformao e saiu do grupo a gente da reclamao. Ser Scrum Master ser algum que decidiu ser
parte da Soluo, no do Problema.
O Scrum Master 53

Scrum Master servindo Organizao

O Scrum Master serve organizao de vrias maneiras, incluindo:

Liderando e treinando a organizao na sua prpria adoo de


Scrum;
Planejando implementaes Scrum dentro da organizao;
Ajudando empregados e stakeholders entender e tornar aplicvel
o Scrum e o desenvolvimento emprico de produtos;
Causando mudanas que aumentam a produtividade do time
Scrum; e,
Trabalhando com outros Scrum Masters para aumentar a
eficcia da aplicao do Scrum nas organizaes.

Retomando a ideia da pessoa da capa, e extrapolando a atuao em um time


Scrum, o Scrum Master deve ser algum com vontade de liderar a organizao na
adoo do Scrum, primeiro em iniciativas isoladas para dar resultados prticos e
concretos que sero usados como motivadores para os cticos obterem resultados
maiores, depois planejando expanses de adoo do Scrum em um maior nmero de
times agora j baseado no conhecimento emprico (lembra-se) adquirido na prpria
organizao, com as prprias pessoas envolvidas, demonstrando quanto de aumento de
produtividade esto tendo os times que j fizeram o movimento de transio e
trabalhando com outros Scrum Masters da empresa para reutilizar as lies e acelerar
novas adoes na organizao.

O Scrum Master (a pessoa da capa) um agente de mudanas e de promoo de


melhoria contnua, no no estilo grandes rupturas (a partir de hoje somos geis) mas
no estilo Kaizen de melhoria contnua. O importante demonstrar objetivamente
benefcio e retornos tangveis, para que o suporte iniciativa de Agilidade do Scrum
somente seja reforada pela administrao snior, e no fique num discurso bonito mas
subjetivo.

Alguns profissionais que atuam como Scrum Masters com a experincia


adquirida, acabam atuando tambm como Agile Coaches e Agile Trainers, em aes de
treinamento de novos times Scrum e no acompanhamento da evoluo de pessoas nos
papes de Scrum Master, Donos de Produtos, time Scrum, DevOps, automaes de
testes, build e deploy de sistemas por exemplo.

53
54 Agilidade nas empresas. Guia Scrum para quem no de TI.
Eventos Scrum 55

Eventos Scrum

Eventos prescritos so usados no Scrum para criar regularidade e para


minimizar a necessidade de reunies no definidas no Scrum. Todos os eventos so
eventos time-box, de tal modo que todo evento tem uma durao mxima. Uma vez
que a Sprint comea, sua durao determinada e fixa e no pode ser reduzida ou
aumentada. Os eventos restantes podem terminar sempre que o propsito do evento
alcanado, garantindo que uma quantidade adequada de tempo seja gasta sem
permitir perdas no processo.

Os eventos Scrum (reunies) so todos time-box (de tempo determinado), de


modo que toda oportunidade seja aproveitada para desenvolver o hbito da cadncia,
sempre no mesmo horrio comea, no mximo com a mesma durao encerra-se,
sempre igual, sem necessidade de controle. Por definio no Scrum, ou recomendao
lgica de eficcia, somente a Sprint deve ser mantida sempre do mesmo tamanho.
Finalizado uma Sprint, se algo no foi possvel chegar ao estado final de pronto, a
Sprint encerra-se e uma nova comea no se prorroga uma Sprint para esperar algo
que no ficou pronto, Ok?.

Se tudo que estava previsto inicialmente para a Sprint ficou pronto antes da
Sprint terminar, pode ser sinal que a velocidade do time aumentou desde a Sprint
anterior, ento mais incrementos de produtos podem ser includos na Sprint para
complet-la e o time saber, pela experincia, que a prxima Sprint poder ento prever
entregar mais produtos, pois a velocidade e a produtividade do time est melhor que
antes.

Alm da Sprint propriamente, que um container para outros eventos, cada


evento no Scrum uma oportunidade formal de inspecionar e de adaptar alguma
coisa. Estes eventos so especificamente projetados para permitir uma transparncia
e uma inspeo criteriosa. A falha em no incluir qualquer um dos eventos resultar na
reduo da transparncia e na perda de oportunidade para inspecionar e adaptar.

Alinhado aos pilares transparncia para inspecionar e adaptar, o conjunto de


eventos Scrum so pensados para que o Dono do Produto possa inspecionar o progresso
dos trabalhos de forma frequente e transparente e que o time possa adaptar, quer seja
refinando o entendimento do produto, quer seja adaptando a forma de trabalho (o
processo) ou auxiliando os envolvidos no trabalho a realizar melhor seu trabalho.

55
56 Agilidade nas empresas. Guia Scrum para quem no de TI.

Se voc Dono de um Produto, no perca a oportunidade de prover e de


aproveitar da transparncia dos eventos do Scrum e no deixe de adaptar seu produto
para as solues que seu time poder te apresentar, esteja aberto e direcione seu time
sempre.

Se voc Scrum Master, no deixe de prover a transparncia e a cadncia de


eventos que o Scrum preconiza e de auxiliar o time Scrum a entender e entregar o
produto dos trabalhos. responsabilidade do time de desenvolvimento entregar o
melhor produto possvel dentro do Sprint. Mas responsabilidade sua auxiliar o time de
desenvolvimento a fazer isso da melhor maneira possvel. E responsabilidade sua
auxiliar o Dono do Produto a fazer o melhor produto possvel. Como sempre, papis
distintos, responsabilidades claras.
A Sprint 57

A Sprint

O corao do Scrum a Sprint, um evento time-box de um ms ou menos,


durante o qual um incremento de produto Pronto e potencialmente utilizvel do
produto, criado. Sprints tem duraes consistentes em todo o perodo de
desenvolvimento. Uma nova Sprint inicia imediatamente aps a concluso da Sprint
anterior.

Muita discusso ocorre nos times que implementam Scrum sobre a durao
ideal de uma Sprint (4, 3, 2 semanas). Mais importante que projetar a melhor durao
possvel experimentar as primeiras Sprints e seguir adaptando a durao, o processo e
as pessoas para o que melhor se aplica ao seu caso. Lembre-se das caractersticas
emprico e adaptativo do Scrum, aprenda com a experincia do time e faa adaptao
do que precisar. Neste sentido, de aprender com a experincia, ento quanto menor for a
Sprint (2 semanas?) talvez melhor seja para fins de aprender rapidamente com os
feedbacks que vo surgir.

Pode (e talvez v mesmo acontecer) de uma 1 Sprint parecer um grande


pesadelo, o tempo (time-box) ter passado e pouco (ou quem sabe at mesmo nada)
potencialmente utilizvel ter ficado pronto, mas, para a prxima Sprint, ajuste tudo
que voc conseguiu aceitar que errou e faa de novo. Aprenda e adapte. Aprenda mais,
adapte e fique melhor. Como o passar das Sprints a velocidade do time vai aumentar.

As Sprints so compostas por uma reunio de planejamento da Sprint, pelas


reunies dirias, o trabalho de desenvolvimento, uma reviso da Sprint e a
retrospectiva da Sprint.

Dividindo o elefante em partes menores (opa, sugiro novamente suspender o


julgamento sobre dividir o elefante em partes e ficar s com a analogia, ok?), uma
Sprint composta por 5 partes, to igualmente importantes e fundamentais como os
rgos do corpo:

Planejar o que cabe ser feito em 1 Sprint lembre-se do Kanban,


levar algo da situao de A FAZER at a situao de FEITO, pronto e
potencialmente utilizvel;
Reunir-se diariamente, todos os dias, todo o time, e cada pessoa do
time saber o que ele tem na sua prpria fila para fazer, o que est em suas mos
e fazendo e como que o Scrum Master pode ajudar o time a fazer sem os
impedimentos, sem gargalos;

57
58 Agilidade nas empresas. Guia Scrum para quem no de TI.

Trabalhar todos os dias e produzir o incremento de produto objetivo da


Sprint;
Revisar diariamente a velocidade em produzir o incremento de produto
e decidir o que est pronto e poder receber o selo de feito e o que poder no ser
considerado pronto e precisar voltar para a lista de coisas a fazer15;
Rever a Sprint em retrospectiva, entender o que funcionou bem e o que
no funcionou, como fazer mais vezes o que funciona bem no seu contexto, aceitar
o que foi aprendido com os erros e como evitar a reincidncia deles na prxima
Sprint que comea agora, com o Planejamento da prxima Sprint.

Durante a Sprint:

No so feitas mudanas que possam por em perigo o objetivo


da Sprint;
As metas de qualidade no diminuem; e,
O escopo pode ser clarificado e renegociado entre o Dono do
Produto e o Time de Desenvolvimento quanto mais for aprendido.

3 pontos importantes: Sprint tem objetivos especficos, a qualidade do produto a


ser entregue no negocivel, e escopo se negocia.

Um dos objetivos de as Sprint serem curtas o fato de isto forar que as


entregas sejam pontuais e especficas o suficiente (para caber no time-box) e evitar que
incertezas futuras impeam os primeiros trabalhos de acontecer, permitindo que o
movimento (os ciclos de melhoria contnua) se inicie.

Um ponto importante esperado dos trabalhos, que o produto entregue tenha


qualidade e que qualidade seja algo a ser buscado e no negligenciado. Uma entrega de
pouca qualidade na Sprint de hoje, reduz a capacidade produtiva do time de
desenvolvimento em fazer coisas novas nas prximas Sprints, pois o tempo do time de
desenvolvimento ter de ser compartilhado em resolver problemas. Fora que
experincia de quem estar usando o Produto ser superior ao usar um Produto livre de

15
H um vdeo do Alpacino, trecho do filme Any Given Sunday de 1.999 onde ele fala discurso para um
time de footbal, e diz que um jogo se ganha inch-by-inch, onde a margem para erro so small e diz
que The inches we need are everywhere around us. Portanto, na minha opinio, um time deve
aproveitar cada uma das oportunidades todos os dias para ganhar como equipe ou sucumbir como
indivduos. Assista o vdeo todos os dias antes de comear o trabalho! Veja mais em
https://youtu.be/BL2CsP5JG2Y
A Sprint 59

defeitos. Um cliente desencantado, procura outros produtos e servios e seus


fornecedores para encant-lo.

O terceiro ponto que o produto se clarifica e se negocia. Os itens de backlog


do Produto no so detalhados em todo o nvel de detalhe possvel antes da Sprint
comear (ou ento teramos voltado ao modelo preditivo / waterfall anterior, ok?).
Clarificar significa que mais detalhe sobre um mesmo assunto se define ao longo do
desenvolvimento do incremento de produto. Negociado significa que se for necessrio,
um item de backlog de produto pode entrar na Sprint e outro pode sair, desde que duas
situaes sejam satisfeitas: o item que entrou tenha o mesmo tamanho e exija o mesmo
esforo para ficar pronto do item que saiu e; que esta repriorizao tenha sido feita com
o acordo do Dono do Produto.

Cada Sprint pode ser considerada um projeto com horizonte no maior que um
ms. Como os projetos, as Sprints so utilizadas para realizar algo. Cada Sprint tem a
definio do que para ser construdo, um plano projetado e flexvel que ir guiar sua
construo, o trabalho e o produto resultante.

Sprints so limitadas a um ms corrido. Quando o horizonte da Sprint muito


longo, a definio do que ser construdo pode mudar, a complexidade pode aumentar
e o risco pode crescer. Sprints permitem a previsibilidade que garante a inspeo e
adaptao do progresso em direo meta pelo menos a cada ms corrido. Sprints
tambm limitam o risco ao custo de um ms corrido.

Fazendo um paralelo, Sprints so pensadas para estimular os times de desenvolvimento


e os Donos dos Produtos a criarem o hbito de fazerem entregas parciais a mais concreta
possvel (potencialmente utilizvel) em curto e repetveis espaos de tempo, entregas time-box
de 1 ms por exemplo, como forma alternativa ao modelo waterfall / sequencial de 1 entrega
nica ao final x meses aps comear.

A possibilidade de poder fazer entregas frequentes mesmo que parciais (em


funcionalidade), tem relao direta com a estratgia de habilitar a empresa com a capacidade de
adaptao e rpida resposta frente s mudanas que o mercado exigir. Por isso de pensar em
pequenos incrementos de funcionalidade disponveis para uso do mercado de modo a conquistar
sua ateno, seu interesse e at sua predileo para com a empresa nas prximas entregas.

O trecho abaixo sobre Cancelamento da Sprint (uma situao extrema mas possvel),
pode ajudar a entender a importncia dos ciclos serem curtos e frequentes.

Cancelamento da Sprint

59
60 Agilidade nas empresas. Guia Scrum para quem no de TI.

Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar.


Somente o Dono do Produto tem a autoridade para cancelar a Sprint, embora ele (ou
ela) possa fazer isso sob influncia de outras partes interessadas, do Time de
Desenvolvimento ou do Scrum Master.

Uma Sprint poder ser cancelada se o objetivo da Sprint se tornar obsoleto.


Isto pode ocorrer se a organizao mudar sua direo ou se as condies do mercado
ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela no faz
mais sentido dadas certas circunstncias. No entanto, devido a curta durao da
Sprint, raramente cancelamentos fazem sentido.

Quando uma Sprint cancelada, qualquer item de Backlog do Produto


completo e Pronto revisado. Se uma parte do trabalho estiver potencialmente
utilizvel, tipicamente o Dono do Produto o aceita. Todos os itens de Backlog do
Produto incompletos so reestimados e colocados de volta no Backlog do Produto. O
trabalho feito neles se deprecia rapidamente e deve ser frequentemente reestimado.

O cancelamento de uma Sprint consome recursos, j que todos tem que se


reagrupar em outra reunio de planejamento da Sprint para iniciar outra Sprint.
Cancelamentos de Sprints so frequentemente traumticos para o Time Scrum, e so
muito incomuns.

Indo direto ao ponto, se possvel perder uma parte do trabalho, que esta parte,
ou que essa perda, seja pequena para se desperdiar e jogar fora. Este um benefcio
que h por traz da lgica das Sprints serem curtas e serem pequenos os incrementos de
produto entregues. A comparao , o que mais custoso, perder? 2 semanas de
trabalho de um grupo de 5 pessoas por exemplo, que consumiu supostamente 5
pessoas * 10 dias * 8 horas/dia = 400 horas de trabalho para produzir 5 coisas novas?
Ou um grupo mdio de 6 pessoas com picos de 10 pessoas, que trabalharam 6 meses
para produzir 55 coisas que agora podem no valer mais?

Pode acontecer de as prioridades do mercado, do negcio, da empresa e do


Dono do Produto mudarem e o Product Backlog ser repriorizado e descontinuar a
necessidade de algo (ou tornar-se obsoleto como diz o Guia) e aumentar a prioridade de
algo que estava l no fundo da lista. Portanto, quanto antes o Time puder concluir (ou
at mesmo suspender) um trabalho e passar a atender outras prioridades, melhor, mais
rpida a resposta mudana ser dada ao mercado por exemplo, e menos custosa a
adaptao ter sido.

Visualmente algo mais ou menos assim ...


A Sprint 61

... (Figura 7A) temos um acordo, um acordo sobre algo extenso, demorado,
desafiador e complexo ...

... (Figura 7B) ento mergulhamos no rduo trabalho de produzir


absolutamente tudo que precisa ser feito ...

61
62 Agilidade nas empresas. Guia Scrum para quem no de TI.

... (Figura 7C) ento, finalmente, quando o produto resultante do trabalho est
pronto e voc coloca ele no mercado, ..., opa! o mercado mudou! E no est mais l!

Finalizando e olhando numa escala menor (menos catastrfica), se o objetivo de


uma Sprint pode mudar ento pode acontecer de ela ter de ser cancelada, devido ao isto,
melhor que ela seja a menor possvel para ter a menor perda possvel.
Planejamento da Sprint 63

Planejamento da Sprint

O trabalho a ser realizado na Sprint planejado na reunio de planejamento da


Sprint. Este plano criado com o trabalho colaborativo de todo o Time Scrum.

A reunio de planejamento da Sprint possui um time-box com no mximo oito


horas para uma Sprint de um ms de durao. Para Sprints menores, este evento
usualmente menor. O Scrum Master garante que o evento ocorra e que os
participantes entendam seu propsito. O Scrum Master ensina o Time Scrum a
manter-se dentro dos limites do time-box.

A reunio de planejamento da Sprint Planning responde s seguintes questes:

O que pode ser entregue como resultado do incremento de


produto da prxima Sprint?
Como o trabalho necessrio para entregar o incremento de
produto ser realizado?

A reunio de planejamento da Sprint um primeiro ponto de mudana para o


Time Scrum, para nos certificarmos de que o Time no ser um time gil mas s at a
primeira pgina! (termo usado oportunamente pelo colega Thiago Simes da IBM).

O ponto central aqui est no 1 pargrafo, onde consta que Este plano criado
com o trabalho colaborativo de todo o time Scrum, pois denota-se aqui a caracterstica
de auto-organizao do time Scrum, pois fica cargo de todo o Time Scrum fazer o
planejamento e no sob responsabilidade segregada junto ao Scrum Master ou um
Gerente de Projetos. o prprio time que faz o plano (Sprint Planning) de o que cabe
numa Sprint. O time que teve a oportunidade de fazer o prprio plano de entregas, ser
motivado e comprometido a cumprir o plano com uma chance maior do que um time
que recebeu um plano pronto.

Tpico Um: O que pode ser feito nesta Sprint?

O Time de Desenvolvimento trabalha para prever as funcionalidades que sero


desenvolvidas durante a Sprint. O Dono do Produto debate o objetivo que a Sprint
deve realizar e os itens de Backlog do Produto que, se completados na Sprint,
atingiriam o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do
trabalho da Sprint.

63
64 Agilidade nas empresas. Guia Scrum para quem no de TI.

Um ponto importante a destacar aqui que existe trabalho fora da Sprint (eu
costumo dizer que existe vida fora da Sprint). Esta uma questo importante, pois os
times geis podem passar a generalizar de que tudo na vida agora so Sprints e que s
existe vida dentro das Sprints e, at mesmo por este pargrafo do Guia, isso no
verdade, h trabalho antes de iniciar uma Sprint, atuando-se no refinamento do Backlog
do Produto, nas revises de Stories, em sesses de Planning Poker, em descoberta e
ordenao de itens de Backlog do Produto para compor uma lista mnima de
funcionalidades com as quais j possvel dar partida numa equipe de desenvolvimento,
sem o risco de ficar sem escopo logo aps a primeira Sprint. No pode faltar tijolo
na obra. Este trabalho responsabilidade principal do Product Owner, suportado pelo
Scrum Master como vimos nas sesses anteriores mas, como citado neste pargrafo do
Guia Scrum, o time de desenvolvimento tem um papel ativo na proposio de novas
funcionalidades a serem desenvolvidas numa Sprint futura. Ou seja, natural que se
tenha trabalho antes da primeira Sprint e tambm durante as Sprints, preparando
trabalho para as prximas. Cerca de 10% do tempo de uma Sprint deveria ser usado em
planejamentos e refinamentos da(s) prxima(s) Sprint(s). No pode faltar tijolo na
obra ou o ritmo ser perdido.

A entrada para a reunio de planejamento da Sprint o Backlog do Produto, o


mais recente incremento do produto, a capacidade projetada do Time de
Desenvolvimento durante a Sprint e o desempenho passado do Time de
Desenvolvimento. O nmero de itens selecionados do Backlog do Produto para a
Sprint o nico trabalho do Time de Desenvolvimento. Somente o Time de
Desenvolvimento pode avaliar o que pode ser completado ao longo da prxima Sprint.

Corroborando com a colocao anterior de que existe trabalho fora da Sprint


o Guia Scrum define que h varaveis que o time de desenvolvimento deve avaliar para
decidir-se sobre O QU possvel aceitar entregar numa Sprint:

a) os itens de Backlog do Produto que so mais prioritrios16 (que trazem mais


valor) ao negcio;

b) a capacidade do time de desenvolvimento, pois em geral a capacidade dos


times finita, acredite, basta pensar que um time de desenvolvimento ideal ter de 5 a 9

16
Importante destacar que os itens de mais alta prioridade devem ser combinados ENTRE o Dono do
Produto E o time de Desenvolvimento. Se depender do Dono do Produto, ele vai sempre priorizar novas
Funcionalidades que ele mesmo entende serem necessrias no produto ou servio mas, o time de
desenvolvimento precisa negociar que haver situaes que em algumas Sprints, itens que No
representam Funcionalidades (conhecidas com requisitos no-funcionais por exemplo, ou melhorias
nos processos internos), precisaro ser atendidos em prol da manuteno de um software em bom
estado de uso e na ampliao contnua da velocidade das entregas
Planejamento da Sprint 65

recursos, portanto a capacidade deste time de desenvolvimento, mesmo que 100%


dedicado ao Backlog de um Produto, finita, mesmo em times geis ainda h
restries de recursos e as pessoas continuaro fazendo algumas atividades no
relacionadas Sprint;

c) o desempenho deste time (destes indivduos) em Sprints anteriores (quando


aplicvel) pois sempre haver uma 1 vez, uma 1 Sprint desta formao de time neste
desenvolvimento, pessoas que saram outras que entraram, novas verses de
ferramentas, novos processos & procedimentos;

d) a disponibilidade deste time (destas pessoas) para as prximas Sprints, pois


sempre h oportunidade de algum sair em frias, estar em treinamento, ou ainda ter sua
alocao compartilhada com outro trabalho / outra demanda.

Bom, de posse destas variveis: o valor e o tamanho do que h de mais


importante para fazer agora, quem vai trabalhar e qual a velocidade deste time de
desenvolvimento nos ltimos trabalhos, qual a disponibilidade do time para a(s)
prxima(s) Sprint(s), o time decide quais sero os incrementos de produto da prxima
Sprint passveis de o time comprometer-se a entregar.

Novamente, perceba a condio de negociao que deve existir entre quem


espera por um novo incremento de produto (o Dono do Produto) e o time que o
responsvel por fazer estes incrementos acontecerem. Pode haver conflito entre o senso
de prioridades e valor do Dono do Produto e o tamanho do esforo entendido pelo Time
de Desenvolvimento (e o Scrum Master precisa ajudar o time e o Dono do Produto nesta
equao).

Aps o Time de Desenvolvimento prever os itens de Backlog do Produto que


ir entregar na Sprint, o Time Scrum determina a meta da Sprint. A meta da Sprint o
objetivo que ser atendido dentro da Sprint atravs da implementao do Backlog do
Produto, e a Meta da Sprint fornece orientao para o Time de Desenvolvimento sobre
o porqu de ele estar construindo o incremento.

Perceba que negociado o QU ser feito uma Sprint, o time de desenvolvimento


toma para s a responsabilidade por entregar aquele incremento dentro do timebox
combinado. Ento agora o Time de Desenvolvimento precisar combinar entre si o
COMO este trabalho ser realizado e, algo importante o Time de Desenvolvimento
estabelecer entre eles, uma meta da Sprint, para que esta meta seja tambm a Meta
pessoal de todos, de modo que todos estejam comprometidos com as suas metas e a
Meta da Sprint.

65
66 Agilidade nas empresas. Guia Scrum para quem no de TI.

Tpico Dois: como o trabalho escolhido ser considerado


Pronto?

Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do


Produto para a Sprint, o Time de Desenvolvimento decide como ir construir essas
funcionalidades durante a Sprint e transform-las em um incremento de produto
Pronto. Os itens de Backlog do Produto selecionados para a Sprint, junto com o
plano de entrega destes itens chamado de Backlog da Sprint.

Derivado ento de uma parte de Backlog do Produto que entrou para a Sprint
como a definio de O QU ser feito, o Time de Desenvolvimento elabora o Backlog
da Sprint como a definio de COMO isto ser feito. Como dito anteriormente, o Dono
do Produto responsvel por fazer definies de alto-nvel para o Backlog do Produto
sobre as coisas que so necessrias de ter no Produto, e o Time de Desenvolvimento
responsvel por determinar o como as atividades transcorrero (levando em
considerao as tecnologias relacionadas ao produto em questo e os procedimentos
disponveis na empresa). Novamente, papis distintos, responsabilidades claras.

O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do


trabalho necessrio para converter o Backlog do Produto em um incremento do
produto utilizvel. O trabalho pode ser de tamanho varivel ou esforo estimado.
Contudo, trabalho suficiente planejado durante o planejamento da Sprint pelo Time
de Desenvolvimento para prever o que esta acredita que poder fazer durante a
prxima Sprint. O trabalho planejado pelo Time de Desenvolvimento para os primeiros
dias da Sprint, decomposto at o final desta reunio, frequentemente em unidades
de um dia de durao ou menos. O Time de Desenvolvimento se auto-organiza para
realizar todo o trabalho do Backlog da Sprint, durante o planejamento da Sprint e
quando for necessrio durante a Sprint.

O Dono do Produto responsvel por definir O QUE necessrio e o Time de


Desenvolvimento por definir O COMO isto ser feito, portanto, o Product Backlog
uma lista de COISAS a fazer no Produto novas funcionalidades esperadas, e esta lista
NO contm atividades e tarefas. O modo de fazer o Incremento de Produto chegar ao
estado de Pronto determinado pelo Time de Desenvolvimento.

Neste sentido, para enriquecer seu entendimento sobre Backlog do Produto ( O


QU, coisas ou funcionalidades) e Backlog da Sprint ( COMO, atividades ou trabalho
), importante lembrar que o Scrum passvel de utilizao em trabalhos no
Planejamento da Sprint 67

relacionados ao desenvolvimento de Software, h no livro Scrum a arte de fazer o


dobro do trabalho na metade do tempo. De Jeff Sutherland exemplos de aplicao do
processo de gesto Scrum em contextos relacionados educao, em casos de cobertura
jornalstica de guerra, trabalhos sociais, entre outros, registrando-se ganhos de
produtividade de at 1.200%.

O Dono do Produto pode ajudar a clarificar os itens de Backlog do Produto


selecionados e nas decises conflituosas de troca. Se o Time de Desenvolvimento
determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint podem
ser renegociados com o Dono do Produto. O Time de Desenvolvimento tambm pode
convidar outras pessoas para participar desta reunio de forma a fornecer opinio
tcnica ou de domnios especficos.

Utilizando o contexto de um Servio de TI, o Time de Desenvolvimento o


responsvel pela confidencialidade, disponibilidade e integridade do Servio de TI que
materializa um Produto cujo Dono tem interesse em obter benefcios para a organizao
(quer seja um sistema de uso interno na organizao ou um produto de Software
comercializvel). Neste sentido, entenda-se o termo em Portugus do Scrum decises
conflituosas de trocas para o caso j citado, de quando o Time de Desenvolvimento
precisa negociar que uma Sprint compreenda atender por exemplo, um requisito no
funcional de Segurana da Informao que surgiu em detrimento a produzir uma
funcionalidade de negcios nova (da as decises conflituosas de trocas).

Ainda, o Time de Desenvolvimento, de posse de sua atuao auto-organizada,


pode precisar demonstrar ao Dono do Produto que ele est com excesso ou ainda com
falta de trabalho para uma Sprint, combinando com o Dono do Produto postergar ou
ainda antecipar a entrega de algo na Sprint em planejamento.

No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz


de explicar ao Dono do Produto e ao Scrum Master como pretende trabalhar como
equipe auto-organizada para completar o objetivo da Sprint e criar o incremento
previsto.

Voltando ao tema de que h vida fora da Sprint, vale comentar aqui no


fechamento do planejamento da Sprint, que um time Scrum trabalhando com mtodos
geis, no um time que no faz planejamento, mas sim, que faz planejamento em
camadas. No feito planejamento up front, ou todo ele antes da execuo, mas sim,
de forma incremental e evolutiva. No que no tenha planejamento no Scrum, que
ele no feito no modelo Preditivo / Waterfall / Up Front. Em primeiro lugar, por

67
68 Agilidade nas empresas. Guia Scrum para quem no de TI.

definio o trabalho j est intrinsicamente ligado um Produto17 da organizao que


existe devido sua estratgia e que d retorno para a empresa.

Ainda, grosso modo, se temos Sprints mensais, no mnimo as equipes geis


fazem planejamentos macro de forma a distribuir novas features / novas demandas pelas
iteraes ao longo dos prximos meses de horizonte, fazendo atualizao e
acompanhamento dirio do andamento das demandas atravs da Administrao vista,
com seus quadros Kanban e grficos de Burn Down e Burn Up.

Figura 8 planejamento em camadas

Objetivo ou meta da Sprint

A meta da Sprint um objetivo definido para a Sprint que pode ser satisfeito
atravs da implementao do Backlog do Produto. O objetivo fornece uma direo
para o Time de Desenvolvimento sobre o porqu de estar construindo o incremento. O
objetivo criado durante a reunio de planejamento da Sprint. O objetivo da Sprint d
ao Time de Desenvolvimento alguma flexibilidade a respeito da funcionalidade que
ser completada dentro dos limites da Sprint. Os itens do Backlog do Produto
selecionados entregam algo de funcionamento coerente (claro, conciso e consistente),
que pode ser o objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro item de

17
Por Produto entenda um produto fsico ou um servio prestado, para pblico interno organizao ou
comercializado para clientes finais e at mesmo utilizvel pelas partes necessrias da sua cadeira de
valor
Planejamento da Sprint 69

funcionamento coerente (claro, conciso e consistente) que faa o Time de


Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas.

Conforme o Time de Desenvolvimento trabalha, ele mantm o objetivo da


Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementam funcionalidade
e tecnologia. Caso o trabalho acabe por ser diferente do esperado pelo Time de
Desenvolvimento, ento eles colaboram com o Dono do Produto para negociar o
escopo do Backlog da Sprint dentro da Sprint.

Dependendo da complexidade e do tamanho do Incremento de Produto a


entregar, pode ser necessrio organizar um release que para ele possa acontecer, pode
ser que exista a necessidade de mais de uma iterao (Sprint) ou at mesmo Sprints
(iteraes) de mais de um Produto feitas at mesmo simultaneamente. Veja o diagrama.

Figura 9 planejamento de releases entre diferentes produtos

Quando um Time de Desenvolvimento trabalha de forma independente, esta


anlise de interdependncia entre Produtos pode no ser aplicvel ficando restrito
somente ao planejamento de Releases aps mltiplos Sprints. J num contexto de
mltiplos Produtos e mltiplos times Scrum trabalhando em paralelo, existe a
necessidade de os Donos de Produtos conciliarem as suas demandas entre si, permitindo
que mltiplos Times de Desenvolvimento possam fazer seus planejamentos em
camadas, do portflio de iniciativas que fazem a estratgia acontecer, passando pelo
planejamento de releases no tempo com antecedncia e suas dependncias, chegando
ao planejamento das Sprints e seu acompanhamento dirio para no perder o objetivo
ou meta da Sprint do radar.

69
70 Agilidade nas empresas. Guia Scrum para quem no de TI.
Reunio Diria 71

Reunio Diria

A Reunio Diria do Scrum um evento time-boxed de 15 minutos, para que o


Time de Desenvolvimento sincronize atividades e crie um plano para as prximas 24
horas. Esta reunio feita para inspecionar o trabalho desde a ltima Reunio Diria,
e prever o trabalho que dever ser feito antes da prxima Reunio Diria.

A Reunio Diria mantida no mesmo horrio e local todo dia para reduzir a
complexidade. Durante a reunio os membros do Time de Desenvolvimento
esclarecem:

O que eu fiz ontem que ajudou o Time de Desenvolvimento a


atender a meta da Sprint?
O que eu farei hoje para ajudar o Time de Desenvolvimento
atender a meta da Sprint?
Eu vejo algum obstculo que impea a mim ou o Time de
Desenvolvimento no atendimento da meta da Sprint?

O Time de Desenvolvimento usa a Reunio Diria para inspecionar o


progresso em direo ao objetivo da Sprint e para inspecionar se o progresso tende
para completar o trabalho do Backlog da Sprint. A Reunio Diria aumenta a
probabilidade do Time de Desenvolvimento de atingir o objetivo da Sprint. Todos os
dias, o Time de Desenvolvimento deve entender como o mesmo pretende trabalhar
em conjunto, como um time auto-organizado, para completar o objetivo da Sprint e
criar o incremento esperado at o final da Sprint. O Time de Desenvolvimento ou
membros da equipe frequentemente se encontram imediatamente aps a Reunio
Diria para discusses detalhadas, ou para adaptar, ou re-planejar, o restante do
trabalho da Sprint.

O Scrum Master assegura que o Time de Desenvolvimento tenha a reunio,


mas o Time de Desenvolvimento responsvel por conduzir a Reunio Diria. O
Scrum Master ensina o Time de Desenvolvimento a manter a Reunio Diria dentro do
time-box de 15 minutos.

O Scrum Master refora a regra de que somente os integrantes do Time de


Desenvolvimento participem da Reunio Diria.

Reunies Dirias melhoram as comunicaes, eliminam outras reunies,


identificam e removem impedimentos para o desenvolvimento, destacam e promovem

71
72 Agilidade nas empresas. Guia Scrum para quem no de TI.

rpidas tomadas de deciso, e melhoram o nvel de conhecimento do Time de


Desenvolvimento. Esta uma reunio chave para inspeo e adaptao.

As Reunies Dirias (as Daily Meetings) so uma reunio do Time de


Desenvolvimento, o Dono do Produto pode mesmo participar das Daily, mas uma
reunio do Time e para o Time de Desenvolvimento manter-se organizado e
sincronizado. As Daily podem parecer um excesso de reunies, mas o fato de ser rpida
(no exceder 15 minutos) e de o Scrum Master ajudar o Time a manter-se todos
intrnsecos s 3 respostas (qual trabalho eu j fiz, qual trabalho em tenho para fazer, o
que est impedindo meu trabalho), faz com que o time precise estar todos os dias ciente
do seu trabalho em andamento (WIP Work In Progress) o que est em suas mos,
cientes de o que est na sua fila, na sua caixa de entrada (e vai ficar parado somando
tempo de fila) e a posicionar-se sobre se h algo que esteja impedindo os trabalhos
(possibilidade de pedir ajuda para que no seja interrompido o fluxo de trabalho).

De modo similar as pessoas que esto com pouca atuao podem ajudar outras
que esto super atarefadas e gerando gargalo para a realizao do trabalho.

A reunio diria um momento de uso da informao de Administrao vista,


pois o andamento do trabalho acompanhado por todos no quadro Kanban18 da Sprint,
no grfico de Burn Down produzido pelo Scrum Master, e outros acompanhamentos
visuais que a atividade do time requerer para dar transparncia inspeo do seu
prprio trabalho.

A reunio diria uma oportunidade de o time de desenvolvimento inspecionar


se o trabalho est progredindo conforme o objetivo da Sprint, se h alguma adaptao a
fazer em processos ou nas pessoas, se algo precisa ser corrigido na qualidade do
produto19 ou ainda se algum refinamento do entendimento ou renegociao com o Dono
do Produto precisa acontecer por exemplo, nos casos de trabalho em excesso ou
faltando.

18
O quadro Kanban atualizado diariamente, no nos 15 minutos da Daily. Uma atividade que saiu do
status TO DO e passou a DOING, atualizada no Kanban no momento que isso aconteceu. Se a atividade
acabou e precisa ser conferida, ento muda para VERIFY.
19
Vamos falar mais disso num grfico mais frente, sobre a efetividade do que se est produzindo.
Reviso da Sprint 73

Reviso da Sprint

A Reviso da Sprint feita no final da Sprint para inspecionar o incremento e


adaptar o Backlog do Produto se necessrio. Durante a reunio de Reviso da Sprint o
Time Scrum e os stakeholders colaboram sobre o que foi feito na Sprint. Com base
nisso e em qualquer mudana no Backlog do Produto durante a Sprint, os
participantes colaboram nas prximas coisas que podem ser feitas para otimizar valor.
Esta uma reunio informal, no uma reunio de status, e a apresentao do
incremento destina-se a motivar e obter comentrios e promover a colaborao.

A Reviso da Sprint (Sprint Review) uma reunio chave para o Dono do


Produto inspecionar antes do release, o incremento de produto (seja ele qual for, uma
nova verso de um produto fsico ou software, uma matria jornalstica elaborada, um
treinamento realizado, ..., o que estiver sendo entregue iterativamente). O Dono do
Produto e o Time de Desenvolvimento podem precisar de obter aprovaes de outros
interessados num tema, antes de considerar um incremento de produto como Pronto
para a Operao. A reviso da Sprint serve tambm como oportunidade de atualizar o
time com os novos itens de Backlog do Produto para ser usado j no Planejamento da
prxima Sprint.

Esta uma reunio time-boxed de 4 horas de durao para uma Sprint de um


ms. Para Sprints menores, este evento usualmente menor. O Scrum Master
garante que o evento ocorra e que os participantes entendam o seu objetivo. O Scrum
Master ensina a todos a manter a reunio dentro dos limites do time-box.

A Reunio de Reviso inclui os seguintes elementos:

Os participantes incluem o Time Scrum e os stakeholders


chaves convidados pelo Dono do Produto;
O Dono do Produto esclarece quais itens do Backlog do Produto
foram considerados Prontos e quais no foram considerados Prontos;
O Time de Desenvolvimento discute o que foi bem durante a
Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas
foram resolvidos;
O Time de Desenvolvimento demonstra o trabalho que est
Pronto e responde a questes sobre o incremento;

73
74 Agilidade nas empresas. Guia Scrum para quem no de TI.

O Dono do Produto discute o Backlog do Produto tal como est.


Ele (ou ela) projeta as provveis datas de concluso baseado no progresso at
a data (se necessrio);
O grupo todo colabora sobre o que fazer a seguir, e assim que
a Reunio de Reviso da Sprint fornece valiosas entradas para a Reunio de
Planejamento da prxima Sprint;
Anlise de como o mercado ou o uso potencial do produto pode
ter mudado e o que a coisa mais importante a se fazer a seguir; e,
Anlise da linha do tempo, oramento, potenciais capacidades, e
mercado para a prxima verso esperada do produto

A Reviso da Sprint (Sprint Review) o evento limite para o Dono do Produto


aceitar um incremento de Produto (uma entrega) como pronto ou no pronto para a
Operao. Como o Dono do Produto participou ativamente da definio, reviso e testes
do incremento de produto durante os trabalhos da Sprint, a entrega no uma
novidade para o Dono do Produto, sendo a Sprint Review uma oportunidade final de
aceit-lo como Pronto ou No-Pronto. No contexto de Desenvolvimento de Software
por exemplo, ateno especial dada ao risco de o incremento de Produto poder ser
considerado como no-pronto, pois devido s questes de gerenciamento de verso de
cdigo-fonte, nem sempre livre de riscos o trabalho de retirar um incremento de
produto do cdigo-fonte de um software, podendo at ser uma tarefa complexa que
pode gerar novos defeitos no cdigo-fonte, e at mesmo desestabiliz-lo.

O resultado da Reunio de Reviso da Sprint um Backlog do Produto


revisado que define o provvel Backlog do Produto para a prxima Sprint. O Backlog
do Produto pode tambm ser ajustado completamente para atender novas
oportunidades.

A Reviso da Sprint (Sprint Review) tambm traz a oportunidade de o Dono do


Produto compartilhar com o Time de Desenvolvimento, as mais novas prioridades do
Product Backlog obtidas partir da Operao do Dia a Dia ou ainda dos clientes finais
da organizao (em ltima anlise, do mercado), servindo como entrada para reunio de
Planejamento da prxima Sprint, no sem antes o time olhar a ltima Sprint em
retrospectiva.
Retrospectiva da Sprint 75

Retrospectiva da Sprint

A Retrospectiva da Sprint uma oportunidade para o Time Scrum inspecionar


a si prprio e criar um plano para melhorias a serem aplicadas na prxima Sprint.

Muito importante esta oportunidade de as pessoas poderem de forma constante


(time-box) sarem da rotina por um momento, olharem para si mesmos e os ltimos
trabalhos feitos e, de posse desta auto avaliao, proporem melhorias no seu prprio
jeito de trabalhar em equipe, melhorias na prpria equipe, nos relacionamentos entre as
pessoas que fazem o trabalho acontecer que fazem o produto ser incrementado, nos
processos e ferramentas utilizadas para tal. Tudo de forma que a implementao da
mudana esteja nas mos das pessoas. No precisa ser um evento to estruturado
como um evento de Kaizen da melhoria contnua utilizado no Lean Management, mas
uma oportunidade de melhorar.

A Retrospectiva da Sprint ocorre depois da Reviso da Sprint e antes da


reunio de planejamento da prxima Sprint. Esta uma reunio time-boxed de trs
horas para uma Sprint de um ms. Para Sprint menores, este evento usualmente
menor. O Scrum Master garante que o evento ocorra e que os participantes entendam
seu propsito. O Scrum Master ensina todos a mant-lo dentro do time-box. O Scrum
Master participa da reunio como um membro auxiliar do time devido a sua
responsabilidade pelo processo Scrum.

O propsito da Retrospectiva da Sprint :

Inspecionar como a ltima Sprint foi em relao s pessoas, aos


relacionamentos, aos processos e s ferramentas;
Identificar e ordenar os principais itens que foram bem e as
potenciais melhorias; e,
Criar um plano para implementar melhorias no modo como o
Time Scrum faz seu trabalho.

A Retrospectiva da Sprint um momento para avaliar como as coisas esto indo


na equipe. Usando a linguagem do Lean Management, como que o trabalho est
fluindo. H vrias perguntas chaves que podem ser usadas de ncora para iniciar
discusses que ajudam a trazer temas mesa. Vamos ver algumas possibilidades de
perguntas para auto avaliao:

O que est indo bem?

75
76 Agilidade nas empresas. Guia Scrum para quem no de TI.

O que no est indo bem?


Quais impedimentos estamos tendo?
Quais riscos temos para com o processo Scrum no nosso time?
De modo similar, quais oportunidades podemos aproveitar melhor?
Se voc puder resumir o time numa Meta, qual ela?
H impedimentos no nvel do time?
H impedimentos no nvel da organizao?
O que voc gostou de fazer?
O que voc no gostou de fazer?
O que voc aprendeu?
O que voc pode fazer para melhorar isso em voc?
O que voc perdeu?
O que voc esperava e no viu acontecer?
Alguma fraqueza pessoal?
Qual sua meta pessoal de melhoria para a prxima Sprint?
Que compromisso pessoal voc faz para a prxima Sprint?
Quais lies voc aprendeu?
Quais foram suas realizaes?
H reas de problemas?
Alguma considerao para as Sprints futuras?
Cite questes especficas com relao a: pessoas, produtos, processos,
ferramentas, infraestrutura, local de trabalho.

Esta lista no para ser usada na ntegra, siga a lgica de que menos mais, e
escolha umas 4 mximo 5 questes por sesso de Retrospectiva e v variando as
questes cada reunio para usar estimular a criatividade da equipe ao explorar
diferentes questes. Para falhas que estejam trazendo maiores impactos para a
produtividade do trabalho, voc pode inclusive fazer uma anlise FMEA, do tipo:

A falha
A causa raiz
A consequncia ou implicao
A ao de preveno para no reincidncia
Como saber que a soluo foi efetiva
Retrospectiva da Sprint 77

Fazendo novo link com os valores do Scrum, importante que a equipe


participe das reunies de Retrospectiva de forma aberta a receber feedback e aprenda
com eles, bem como que d feedback de forma respeitosa aos demais colegas da equipe.

O Scrum Master encoraja o Time Scrum a melhorar, dentro do framework do


processo Scrum, o processo de desenvolvimento e as prticas para faz-lo mais
efetivo e agradvel para a prxima Sprint. Durante cada Retrospectiva da Sprint, o
Time Scrum planeja formas de aumentar a qualidade do produto, adaptando a
definio de Pronto quando apropriado.

Ao final da Retrospectiva da Sprint, o Time Scrum dever ter identificado


melhorias que sero implementadas na prxima Sprint. A implementao destas
melhorias na prxima Sprint uma foram de adaptao inspeo que o Time Scrum
faz a si prprio. A Retrospectiva da Sprint fornece um evento dedicado e focado na
inspeo e adaptao, no entanto, as melhorias podem ser adotadas a qualquer
momento.

Uma reunio de Retrospectiva deve terminar sempre, sempre sempre, Ok?


com uma lista de aes combinadas pelo time Scrum, aes que sero tomadas por estas
pessoas j na prxima Sprint. a institucionalizao do processo de melhoria contnua
no time Scrum, Sprint a Sprint, de modo que o time seja mais produtivo e que o
incremento de produto gerado tenha sua qualidade melhorada.

77
78 Agilidade nas empresas. Guia Scrum para quem no de TI.

Artefatos do Scrum / Backlog do Produto

Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento


de transparncia e oportunidades para inspeo e adaptao. Os artefatos definidos
para o Scrum so especificamente projetados para maximizar a transparncia das
informaes chave de modo que todos tenham o mesmo entendimento dos artefatos.

Backlog do Produto

O Backlog do Produto uma lista ordenada de tudo que deve ser necessrio
no produto, e uma origem nica dos requisitos para qualquer mudana a ser feita no
produto. O Dono do Produto responsvel pelo Backlog do Produto, incluindo seu
contedo, disponibilidade e ordenao.

Como colocado em pontos anteriores, o Backlog do Produto (lista de coisas a


fazer) um funil de entrada de novas ideias e caractersticas para um Produto em
questo. Tudo que o Dono do Produto pretender fazer em algum momento, vai para a
lista inicialmente, pode ser to simples quanto uma nota ou lembrete, o Backlog do
Produto vai sendo ordenado, refinado e melhor estruturado pelo Dono do Produto
conforme o seu senso de prioridade para os negcios. Vejamos.

Um Backlog do Produto nunca est completo. Os primeiros desenvolvimentos


apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O
Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele ser
utilizado evoluem. O Backlog do Produto dinmico; mudando constantemente para
identificar o que o produto necessita para ser mais apropriado, competitivo e til. O
Backlog do Produto existir enquanto o produto tambm existir.

Fazendo um paralelo com o mundo de Product Management Gesto de


Produtos, um conceito existente no mercado de produtos (extensvel a servios), a
curva da banheira, onde, quando do lanamento de um produto h uma fase conhecida
como infncia onde a Taxa de Falhas alta e o produto ainda est amadurecendo
podendo ser necessrio que vrios itens de Backlog do Produto sejam abertos para
completar, melhorar ou ainda corrigir o produto que j tem adeso do mercado, e
segue rumo a consolidar. A fase intermediria conhecida como vida til uma fase
que as empresas esperam que seja a mais longa possvel, para que o produto, agora
estvel, possa ser consumido pelo mercado e trazer retorno para a empresa, at que ele
chegue fase final em que o desgaste passa a ser maior e a taxa de falhas sobe
Artefatos do Scrum / Backlog do Produto 79

novamente, tornando o produto invivel e forando clientes a uma atualizao para


outro produto mais moderno melhor ainda se for da mesma empresa!

Figura 10 curva da banheira

Durante a vida til do produto ou servio, o desejo da empresa que o lanou


ao mercado que passado a infncia este j esteja recebendo ateno e demandas aos
montes do mercado, e que a sua vida til seja sempre a maior possvel, maximizando o
retorno sobre os investimentos feitos. Porm, em produtos fsicos e muito mais ainda
em servios, voltando l na abertura do livro introduo ao tema agilidade, a
volatilidade do mercado cada vez mais alta, significando que nem sempre a vida til
do produto ou servio to calma como uma linha reta sem falhas e ainda sem
necessidade de novos investimentos para responder s presses do mercado (clientes e
concorrentes), ento a empresa precisa fazer novos investimentos, mudanas no
produto, e gerar novos itens de Backlog do Produto. neste sentido que o Guia do
Scrum diz que o Backlog do Produto existir enquanto o Produto tambm existir.

Figura 11 curva da banheira (com mudanas)

Uma pesquisa recente do MIT demonstrou que na dcada de 1960 as empresas


duravam uma mdia de 60 anos e que nos dias atuais a mdia de durao 10 anos. To
cruel quanto real.

79
80 Agilidade nas empresas. Guia Scrum para quem no de TI.

O Backlog do Produto lista todas as caractersticas, funes, requisitos,


melhorias e correes que formam as mudanas que devem ser feitas no produto nas
futuras verses. Os itens do Backlog do Produto possuem os atributos de descrio,
ordem, estimativa e valor.

Este pargrafo embora pequeno importante, pois pode parecer que somente
grandes evolues dos produtos e servios, s coisas novas, so feitas atravs do
mtodo que h no Guia do Scrum, mas no, novas caractersticas, funes ou
funcionalidades passam pelo funil do Scrum, bem como melhorias em caractersticas ou
funcionalidades j existentes e at mesmo correes de erros vo sendo priorizados nas
Sprint Backlog, portanto o time Scrum um time integrado que entrega correes,
melhorias e evolues no Produto, tudo por um grupo s.

Esta uma mudana cultural grande. Fazendo um 2 parntesis, Scrum no


acontece no mundo de TI desacompanhado de prticas como: XP, TDD, FDD, Crystal
Clear, Peer Programming, Refactoring, Automao de Build, de Testes, de Deploy e
DevOps. Portanto, para passar da primeira pgina na sua implementao de Scrum,
para fazer mais que o Scrum. Fecha o parntesis.

Enquanto um produto usado, ele ganha valor, e o mercado oferece retorno, o


Backlog do Produto ento torna-se uma lista maior e mais completa. Requisitos nunca
param de mudar, ento o Backlog do Produto um artefato vivo. Mudanas nos
requisitos de negcio, condies de mercado ou tecnologia podem causar mudanas
no Backlog do Produto.

A estratgia do gerenciamento gil de Produtos e Servios encontrar um


ponto inicial de caractersticas para um produto, de modo que ele seja minimamente
vivel ou seja, possa ser comercializvel, desperte interesse de usurios por j
agregar algum valor a estes, e possa ao ser experimentado pelo mercado, prover
feedbacks e insights ao Dono do Produto sobre o que mais importante incorporar no
produto, nas suas prximas verses. Estes (insights) vindos do mercado ou mesmo
stakeholders internos da organizao (setas azuis) so capturados pelo Dono do Produto
no Backlog do Produto (funil) e vo sendo entregues pelo time Scrum (seta vermelha)
conforme o senso de prioridade do Dono do Produto e limitadas sua (capacidade). O
desafio de todos ns e fazermos o (vermelho) do lado direito do funil (capacidade)
maior para atendermos mais coisas do lado esquerdo (azul).
Artefatos do Scrum / Backlog do Produto 81

Figura 12 funil de ideias e trabalho

Mltiplos Times Scrum frequentemente trabalham juntos no mesmo produto.


Um Backlog do Produto usado para descrever o trabalho previsto para o produto.
Um atributo do Backlog do Produto que agrupe itens pode ser ento aplicado.

O refinamento do Backlog do Produto a ao de adicionar detalhes,


estimativas e ordem aos itens no Backlog do Produto. Este um processo contnuo
em que o Dono do Produto e o Time de Desenvolvimento colaboram nos detalhes dos
itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens
so analisados e revisados. O Time de Desenvolvimento decide como e quando o
refinamento est Pronto. Este refinamento usualmente no consome mais de 10% da
capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto
podem ser atualizados a qualquer momento pelo PO ou a critrio do PO.

81
82 Agilidade nas empresas. Guia Scrum para quem no de TI.

Figura 13 refinamento do Backlog do Produto

A figura 13 (acompanhe a leitura da esquerda para a direita) explica o trabalho


contnuo de refinamento do Backlog do Produto, onde a lista de coisas para fazer tem
prioridade quanto mais acima na lista mais prioritrio, portanto quanto mais prioritrio
o item, mais detalhe mais informao se tem dele.

Os itens mais altos da lista esto mais refinados e detalhados em partes menores
mais precisas de o time Scrum entender, e so aqueles que sero mesmo entregues
dentro do time-box j de uma prxima Sprint.

Os itens do meio da lista podem vir a ser feitos e os do final, provavelmente


podem at mesmo nunca ganhar prioridade para serem refinados podendo ficar na
lista l em baixo como uma ideia de algo grande ainda sem muito detalhe.

Finalizando a figura do lado direito voc v tambm que os itens mais


prioritrios foram refinados e detalhados, mas tambm foram divididos em pedaos
menores de incremento de produto. Voc v pela parte mais azul do lado direito que os
itens que esto prontos para o prximo Sprint tem tamanhos20 menores (de 2 a 13
tamanhos cada) e que os itens menos prioritrios, ainda no esto prontos o suficiente
(grau de detalhe suficiente) para uma Sprint e so itens de tamanhos supostamente
maiores (20, 40, G, GG).

Este processo contnuo de priorizar, refinar, detalhar, dimensionar importante


porque todos do foco no detalhe do que importante para estar pronto agora j para a
prxima Sprint sem perder do radar que outras caractersticas e funcionalidades sero
brevemente incorporadas ao produto nas prximas Sprints. (voc se recorda dos 10% de
trabalho no refinamento dos itens das prximas Sprints? Ento, isso).

Este mecanismo contnuo de trabalho um instrumento til para o Dono do


Produto pelo o fato de que aps uma Sprint de 3 a 4 semanas por exemplo, entregando
o que foi topo prioritrio da lista, o time Scrum vai precisar ter um novo topo
prioritrio pronto para ser desenvolvido, ento caso as necessidades ou condies do
mercado tenham mudado, o Dono do Produto tem a oportunidade de repriorizar o

20
O termo tamanho para o Scrum uma forma de medio em Story Points ou pontos de estria. No
Scrum, os itens de backlog so escritos na forma de estrias algo assim como administrador do App
de chamado de carros autnomos eu quero uma consulta de carga das baterias para saber se algum
veculo est perigosamente perto demais de ficar sem energia em trnsito at o prximo posto de
abastecimento e estas estrias tem tamanhos para serem feitas. Se o exemplo foi bom, voc entendeu
que o tema extenso e que ser coberto em outro Volume do livro que no este introdutrio do tema.
Exemplo, estamos abreviando aqui a informao de que uma estria para entrar na Sprint, precisa
estar pronta para aumentar a chance de ela estar feita ao final da Sprint. No Volume II voc
entender a diferena de pronta e feita.
Artefatos do Scrum / Backlog do Produto 83

Backlog do Produto e trazer para a parte do topo prioritrio o refinamento de alguns


novos incrementos de produto que antes estavam l em baixo nesta lista dinmica de
coisas a fazer no Produto ou Servio e ter estes itens refinados, dimensionados e
entendidos pelo time Scrum e prontos para serem feitos na prxima Sprint de 3 a 4
semanas por exemplo.

Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser
mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais
precisas so feitas baseadas em maior clareza e maior detalhamento, quanto menor a
ordem na lista, menos detalhes. Os itens do Backlog do Produto que iro ocupar o
desenvolvimento na prxima Sprint so os mais refinados, de modo que todos os itens
possam ser Prontos dentro do time-boxed da prxima Sprint. Os itens do Backlog do
Produto que podem ser Prontos pelo Time de Desenvolvimento dentro da Sprint so
considerados como Preparados para seleo no Planejamento da Sprint. Itens do
Backlog do Produto geralmente adquirem este grau de transparncia atravs das
atividades de refinamento descritas acima.

O Time de Desenvolvimento responsvel por todas as estimativas. O Dono


do Produto deve influenciar o Time, ajudando no entendimento e nas concesses, mas
as pessoas que iro realizar o trabalham fazem a estimativa final.

Ainda na figura 13, l no canto direito foi dito sobre o tamanho das coisas que
esto prontas para serem feitas durante uma Sprint. O time de Desenvolvimento
responsvel por dimensionar o tamanho dos incrementos de produto que podero
caber o time-box de 1 Sprint. O fato de o item de Backlog de Produto se quebrado em
partes menores e detalhado em conjunto com o Dono do Produto para facilitar a
assertividade do time de Desenvolvimento em estimar o tamanho dos itens.

O time de Desenvolvimento precisa saber qual a sua capacidade produtiva


para uma Sprint quanto de trabalho possvel fazer num perodo de tempo de 3 a 4
semanas por exemplo, de modo que a sua capacidade de trabalho dentro de uma Sprint,
possa ser preenchida com n incrementos de produtos cuja soma dos tamanhos seja
inferior21 capacidade do time de Desenvolvimento (para fins de reservas para
imprevistos por exemplo).

21
Mas porque inferior? Lembre-se que o time Scrum faz coisas novas mas tambm resolve defeitos /
incidentes em ambiente produtivo. Sem uma reserva feita na partida / no planejamento, seu time pode
vir a fazer muito overtime e as suas prximas entregas de coisas novas, podem atrasar ou ainda vir a
serem entregues sem testes adequados de qualidade, podendo gerar mais incidentes e alimentando um
crculo vicioso ruim. Isto no ser Scrum, pois qualidade um must have.

83
84 Agilidade nas empresas. Guia Scrum para quem no de TI.

Como o Scrum pressupe um processo emprico de aprender com a


experincia realizada, um time Scrum (Desenvolvimento, Scrum Master e Dono do
Produto) vai trabalhar algumas Sprints at aprender com sucesso qual e como
melhorar o seu ritmo de trabalho, sua capacidade produtiva cada Sprint e quantos
incrementos de Produtos prontos por Sprint eles podem fazer.

O funcionamento das Sprints como as partidas e chegadas de um trem nas


estaes. O trem tem hora e minuto programados para chegar e sair das estaes (as
Sprints). O trem tem uma capacidade de carga por viagem. As pessoas conforme a sua
prpria prioridade de horrios, precisam estar prontas na estao quando o trem chegar,
para que o seu transporte at a prxima estao seja feito. Voltaremos ao trem mais a
frente.

Monitorando o progresso a caminho do objetivo

Em qualquer ponto do tempo, o total de trabalho restante para alcanar um


objetivo pode ser somado. O Dono do Produto acompanha o total de trabalho restante
pelo menos a cada Reunio de Reviso da Sprint. O Dono do Produto compara este
valor com o trabalho restante na Reunio de Reviso da Sprint anterior, para avaliar o
progresso na direo de completar todo o trabalho previsto, com o tempo estimado
para alcanar um objetivo. Esta informao deve ser transparente para todas as partes
interessadas.

Vrias prticas de projeo de tendncias como burndown, burnup e outras


prticas de estimativa tem sido usadas para prever o progresso. Estas prticas tem se
provado teis. Contudo, no substituem a importncia do empirismo. Em ambientes
complexos, o que acontecer desconhecido. Somente o que tem acontecido pode
ser usado para uma tomada de deciso a respeito do que vir.
Artefatos do Scrum / Backlog do Produto 85

Figura 14 Grfico de Burn Up

No simples grfico de Burnup exemplo acima, possvel o time Scrum


demonstrar de forma transparente para o Dono do Produto, quanto de esfoo em
pontos esperado fazer em um produto ou servio (a linha preta Escopo/Scope), como
tem sido a velocidade de entregas nas primeiras 6 Sprints (as colunas em cor azul) de
realizado/actual, baseado na experincia do time que est atuando, uma projeo (linha
pontilhada em cinza) de quando os itens de Backlog do Produto j priorizados e
estimados estaro prontos para uso. responsabilidade do Dono do Produto demandar
incrementos de produto que realmente tragam valor para a organizao fazendo o
melhor uso possvel do tempo e do custo do time de Desenvolvimento.
responsabilidade do time de Desenvolvimento ampliar sua capacidade produtiva e
manter a qualidade da entrega sempre em nvel timo, para que a experincia do usurio
com o produto ou servio seja sempre a melhor possvel. responsabilidade do Scrum
Master auxiliar ambos os lados. O Dono de Produto a demandar o melhor produto
possvel e, o time de Desenvolvimento a fazer o melhor produto possvel. Isso mesmo,
aquela pessoa da capa, lembra-se?

85
86 Agilidade nas empresas. Guia Scrum para quem no de TI.

Artefatos do Scrum / Backlog da Sprint

O Backlog da Sprint um conjunto de itens do Backlog do Produto


selecionados para a Sprint, juntamente com o plano para entregar o Incremento do
produto e atingir o objetivo da Sprint. O Backlog da Sprint a previso do Time de
Desenvolvimento sobre qual funcionalidade estar no prximo Incremento e sobre o
trabalho necessrio para entregar essa funcionalidade em um Incremento Pronto.

O Backlog da Sprint torna visvel todo o trabalho que o Time de


Desenvolvimento identifica como necessrio para atingir o objetivo da Sprint.

O Backlog da Sprint um plano com detalhes suficientes que as mudanas no


progresso posam ser entendidas durante a Reunio Diria. O Time de
Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog
da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de
Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho
necessrio para alcanar o objetivo da Sprint.

Sempre que um novo trabalho necessrio, o Time de Desenvolvimento


adiciona este ao Backlog da Sprint. Conforme o trabalho realizado ou completado, a
estimativa do trabalho restante atualizada. Quando elementos do plano so
considerados desnecessrios, eles so removidos. Somente o Time de
Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da
Sprint altamente visvel, uma imagem em tempo real do trabalho que o Time de
Desenvolvimento planeja completar durante a Sprint, e pertence exclusivamente ao
Time de Desenvolvimento.
Artefatos do Scrum / Backlog da Sprint 87

Figura 15 item do Backlog do Produto

Enquanto o Backlog (lista de coisas, caractersticas ou funcionalidades a fazer)


no Produto mantido pelo Dono do Produto, o Backlog da Sprint (lista de trabalhos a
fazer) mantido pelo time de Desenvolvimento.

O Backlog da Sprint composto pelos itens do Backlog do Produto definidos e


priorizados pelo Dono do Produto e dimensionados pelo time de Desenvolvimento,
acrescido das atividades relacionados ao trabalho do time de Desenvolvimento para
fazer o incremento do produto como o trabalho ser feito, qual o progresso, os
problemas ou defeitos que a verso intermediria do incremento de produto tem para
serem resolvidos, documentao para gesto do conhecimento neste e nas prximas
Sprints por exemplo.

Relembrando o que vimos da reunio de planejamento da Sprint, o Backlog do


Produto diz respeito ao O QU precisa ser produzido no produto esta definio do
Dono do Produto e ser a sua base de julgamento se o produto (at o final da Sprint)
ser considerado pronto ou no, e o Backlog da Sprint diz respeito a COMO isto ser
feito a forma de trabalho do time de Desenvolvimento.

Fazendo uma aluso pintura de uma casa, a definio de quais sero as cores
de paredes, tetos, portas e janelas feita pelo Dono do Produto / Dono do Imvel e, o
acordo sobre quais sero os procedimentos para preparao, pintura, acabamento e

87
88 Agilidade nas empresas. Guia Scrum para quem no de TI.

limpeza dos locais feita pelo time de Pintores. Ainda, o esforo, o custo do time de
Pintores e a qualidade esperada para pinturas do tipo fosco, brilho, alto-brilho, verniz,
tinta-leo, acrlico, patina, laqueado, entre outras possibilidades, pode variar em
tamanho, mas principalmente, para o Dono do Imvel o valor percebido para cada um
dos tipos de acabamento pode variar significativamente. Novamente, responsabilidade
do Scrum Master (a pessoa da capa!) auxiliar o time Scrum a chegar nestes acordos de
modo eficaz, buscando o melhor benefcio para o Dono do Imvel e a melhor
rentabilidade e tambm produtividade para o time de Pintores.

Monitorando o Progresso da Sprint

Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos


itens do Backlog da Sprint pode ser somado. O Time de Desenvolvimento monitora o
total de trabalho restante pelo menos a cada Reunio Diria. O Time de
Desenvolvimento acompanha estes resumos dirios e projeta a probabilidade de
alcanar o objetivo da Sprint. Com o rastreamento do trabalho restante em toda a
Sprint, o Time de Desenvolvimento pode gerenciar o seu progresso.

Figura 16 grfico de Burn Down

Monitorar o progresso do trabalho durante a Sprint importante para o time Scrum


para: 1 garantir a entrega do que foi combinado numa Sprint e subsidiar a caracterstica
de processo emprico (aprender com a experincia) do Scrum.

Caso a monitorao do trabalho em andamento no seja feita de modo deliberado e


consciente (o que e quanto estamos fazendo, como estamos indo, que velocidade temos,
Artefatos do Scrum / Backlog da Sprint 89

estamos adiantados ou atrasados em relao ao time-box, qual a qualidade do que ns


estamos gerando, qual est sendo a efetividade do que est ficando pronto), o time
Scrum corre o risco e entrar num modo automtico, no aprender, no evoluir em
capacidade, produtividade e qualidade, no entregar algo de real valor. Trabalhar
automtica e mecanicamente. Isto no ser Scrum.

Sendo coerente com os 3 Pilares do Scrum que falamos no incio:


Transparncia, Inspeo e Adaptao, o grfico de acompanhamento do trabalho a
seguir, d transparncia ao trabalho, demonstra quanto de inspeo vem sendo feito e
proporciona que adaptao acontea com a meta de atingir o objetivo da Sprint.

Figura 17 progresso dos trabalhos

Um acompanhamento do progresso dos trabalhos neste formato acima, promove


a transparncia sobre 4 informaes:

a) a quantidade total de incrementos de produto que est se buscando


realizar em 14 dias (linha em cor preta com 25 Story Points);

b) a quantidade de incrementos de produto que est desenvolvido pelo


time de Desenvolvimento, e supostamente pronto, (linha amarela);

89
90 Agilidade nas empresas. Guia Scrum para quem no de TI.

c) a quantidade de incrementos de produto que est feito QA (Quality


Assurance) ou inspeo de qualidade pelo prprio time de Desenvolvimento, e
provavelmente pronto, (linha laranja);

d) a quantidade de incrementos de produto que est efetivamente


inspecionado e agora aceito como pronto pelo Dono do Produto ou outros
interessados relevantes, (linha azul).

Perceba como que as 3 linhas inferiores evoluem em ritmo diferente rumo ao


topo (quantidade total de incrementos de produto a integrar em uma ou mesmo mais
Sprints). 1 passo amarelo, finalizado a sua construo, montagem ou execuo e
supostamente pronto. 2 passo laranja, finalizado os testes de verificao de
qualidade e soluo de defeitos, provavelmente pronto. 3 passo azul, efetivamente
aceito como pronto e passvel de utilizao real por usurios em ambiente produtivo ou
na operao da empresa no mercado.

Perceba pelo grfico, como que as inspees frequentes (pelo time de


Desenvolvimento e depois pelo Dono do Produto), possibilita que o time de
Desenvolvimento possa fazer adaptao (do produto final, da forma, processo,
velocidade e/ou procedimentos de trabalho), de modo que o objetivo de entregar
incrementos de produtos no tamanho total de 25 unidades (Story Points) de tamanho,
seja atingido. uma forma de garantir o foco no que est sendo feito.

No exemplo do grfico da figura 17, ao final de 14 dias de trabalho para


produzir 25 coisas, todas esto finalizadas, 23.5 esto verificadas a qualidade e
somente 5.5 esto efetivamente aceitas como prontas. Se estes 14 dias eram o prazo
final do time-box de Sprint, ento somente 22% do trabalho ficou pronto! Denotando
que a velocidade real do time de Desenvolvimento 78% inferior ao projetado, sendo
necessrio analisar-se as causas raiz dos problemas durante a reunio de Retrospectiva,
e adaptar-se tudo que for causa raiz para que o time Scrum possa ser mais assertivo no
planejamento do prximo time-box.
Incremento 91

Incremento

O incremento a soma de todos os itens do Backlog do Produto completados


durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da
Sprint um novo incremento deve estar Pronto, o que significa que deve estar na
condio utilizvel e atender a definio de Pronto do Time Scrum. Este deve estar
na condio utilizvel independente do Dono do Produto decidir por liber-lo realmente
ou no.

91
92 Agilidade nas empresas. Guia Scrum para quem no de TI.

Transparncia do Artefato

Scrum invoca transparncia. Decises para otimizar o valor e o controle de


riscos so feitos com base na percepo existente do estado dos artefatos. Na medida
em que a transparncia plena, estas decises tem uma base slida. Na medida em
que os artefatos no so completamente transparentes, estas decises podem ser
falhas, valores podem diminuir e riscos podem aumentar.

O Scrum Master deve trabalhar com o Dono do Produto, Time de


Desenvolvimento, e outras partes envolvidas para entender se os artefatos esto
plenamente transparentes. H prticas para lidar com transparncia incompleta, o
Scrum Master deve ajudar todos a aplicar a mais apropriada prtica na falta de uma
transparncia plena. O Scrum Master pode detectar transparncia incompleta pela
inspeo dos artefatos, percebendo padres, ouvindo atentamente o que est sendo
dito, e detectando diferenas entre o esperado e o resultado real.

O trabalho do Scrum Master trabalhar com o Time Scrum e a organizao


para aumentar a transparncia dos artefatos. Este trabalho geralmente envolve
aprendizagem, convencimento e mudana. Transparncia no ocorre de um dia para o
outro, mas um caminho.
Definio de Pronto 93

Definio de Pronto

Quando o item do Backlog do Produto ou um incremento descrito como


Pronto, todos devem entender o que o Pronto significa. Embora, isso varie
significativamente de um extremo a outro para cada Time Scrum, os integrantes
devem ter um entendimento compartilhado do que significa o trabalho estar completo,
assegurando a transparncia. Esta a Definio de Pronto para o Time Scrum e
usado para assegurar quando o trabalho est completo no incremento do produto.

A mesma definio orienta o Time de Desenvolvimento em saber quantos itens


do Backlog do Produto podem ser selecionados durante a Reunio de Planejamento
da Sprint. O propsito de cada Sprint entregar incrementos de funcionalidades
potencialmente utilizveis que aderem definio atual de Pronto do Time Scrum.

O Time de Desenvolvimento entrega um incremento de funcionalidade do


produto a cada Sprint. Este incremento utilizvel, assim o Dono do Produto pode
escolher por liber-lo imediatamente. Se a definio de pronto para um incremento
parte das convenes, padres ou diretrizes de desenvolvimento da organizao,
todos os Times Scrum devem segui-la como um mnimo. Se pronto para um
incremento no uma conveno de desenvolvimento da organizao, o Time de
Desenvolvimento do Time Scrum deve definir uma definio de pronto apropriada
para o produto. Se h mltiplos Times Scrum trabalhando no lanamento do sistema
ou produto, os times de desenvolvimento de todos os Times Scrum devem
mutuamente definir a definio de Pronto.

Cada incremento adicionado a todos os incrementos anteriores e


completamente testado, garantindo que todos os incrementos funcionam juntos.

Com um Time Scrum maduro, esperado que a sua definio de Pronto seja
expandida para incluir critrios mais rigorosos de alta qualidade.

Qualquer produto ou Sistema deve ter uma definio de Pronto que seja um
padro para qualquer trabalho feito nele.

Ao final do time-box da Sprint, quando da reunio de Reviso da Sprint,


esperado que o incremento de produto produzido na Sprint esteja em condio de
pronto, esperado que o item seja passvel de utilizar em ambiente produtivo, na
operao ou ainda, por clientes no mercado.

importante que o Scrum Master atue diligentemente no entendimento da


definio de pronto ou de em condies de operao entre o Dono do Produto e do

93
94 Agilidade nas empresas. Guia Scrum para quem no de TI.

time de Desenvolvimento, ou ento o cenrio apresentado na figura anterior s 22%


do trabalho aceito como pronto, pode repetir-se e tornar o trabalho do time Scrum
invivel. Se o que est sendo supostamente entregue no est sendo efetivamente
aceito e utilizado pelo usurio final, ento no est sendo Scrum.

Em desenvolvimento de software por exemplo, pode ser necessrio negociar


que o produto esteja testado22, que a documentao dos clientes esteja atualizada com as
novas funcionalidades, que o material de marketing esteja pronto, que os canais de
suporte e de feedback pelo usurio estejam atualizados, que requisitos regulatrios
estejam atendidos, entre outros, dependendo do contexto e do produto.

Outro ponto a destacar que mesmo considerando o incremento de produto


como pronto o Dono do Produto pode optar por segurar e liberar para a Operao mais
frente, junto com mais funcionalidades, dentro de uma campanha de marketing, junto
um evento de grande ateno, por exemplo. Neste caso, o time Scrum inicia os
trabalhos em outra Sprint e atua na produo de mais incrementos de produto para a
aceitao do Dono do Produto.

22
Em verdade, em um servio de TI, uma gama de testes pode ocorrer, tais como: de unidade, smoke,
de funcionalidade, de sistema, de integrao entre sistemas, de aceitao, performance, estabilidade,
usabilidade, stress, shake, PEN)
Notas finais 95

Notas finais

O Scrum livre e oferecido neste guia. Papis, artefatos, eventos e regras do


Scrum so imutveis e embora seja possvel implementar somente partes do Scrum, o
resultado no Scrum. Scrum existe somente na sua totalidade, funcionando bem
como um container para outras tcnicas, metodologias e prticas.

Agradecimentos

Pessoas

Das milhares de pessoas que tem contribudo com o Scrum, ns devemos


destacar aquelas que foram fundamentais nos primeiros dez anos. Os primeiros foram
Jeff Sutherland trabalhando com Jeff McKenna, e Ken Schwaber trabalhando com
Mike Smith e Chris Martin. Muitos outros contriburam nos anos subsequentes e sem a
ajuda deles o Scrum no teria sido refinado tanto quanto est hoje.

No Brasil, Fbio Cruz o tradutor oficial do Guia Scrum, escritor e consultor


reconhecido no tema Scrum. Fbio Cruz consultor e Agile Coach especialista em
gerenciamento gil de projetos pela FabioCruz.com.

Histria

Ken Schwaber e Jeff Sutherland fizeram a primeira co-apresentao do Scrum


na conferncia OOPSLA de 1995. Esta apresentao essencialmente documentou o
aprendizado que Ken e Jeff tiveram ao longo dos anos anteriores aplicando o Scrum.

A histria do Scrum j considerada longa. Para homenagear os primeiros


lugares onde ele foi experimentado e refinado, ns reconhecemos a Individual, Inc.,
Fidelity Investments, e IDX (atual GE Medical).

O Guia do Scrum documenta o Scrum conforme desenvolvido e sustentado por


mais de 20 anos por Jeff Sutherland e Ken Schwaber. Outras fontes fornecem
padres, processos, e percepes que complementam o Framework Scrum. Estas
otimizam produtividade, valor, criatividade e satisfao.

95
96 Agilidade nas empresas. Guia Scrum para quem no de TI.

2016 Scrum.Org and Scrum Inc. Offered for license under the Attribution Share-Alike license of
Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum
Guide you acknowledge and agree that you have read and agree to be bound by the terms of the
Attribution ShareAlike license of Creative Commons.
Concluso 97

Concluso

Como dito no Guia Scrum ele simples de entender (espero ter contribudo com voc) e
difcil de aplicar (posso te ajudar com isso tambm).

Como mtodo emprico mais importante aprender com a experincia que projetar
todos os prximos passos de todos os 365 dias do prximo ano. importante fazer planos
(vises, roadmaps, walking skeletons, MVP) tudo isso muito importante e a muitos importa,
mas sem dar o primeiro passo voc vai continuar onde est. Coloque-se em movimento.
Permita-se experimentar e evoluir. J dizia Darwin que no o mais forte que sobrevive, mas
sim o mais adaptvel.

Voltando aos temos do comeo do livro, voc v hoje em dia a Ford fabricando carros
do mesmo jeito que fazia o Ford-T? Tudo evoluiu? Voc tem modem externo em casa hoje em
dia? (at tem, mas eu digo aquele que fazia um sonzinho ao discar!?).

Tudo muda o tempo todo! Aproveite! Quando chega a onda da mudana, VOC, tem 2
escolhas, voc pega uma prancha e surfa a novidade / o tsunami, ou voc finca uma estaca no
cho, se agarra nela e torce para estar l e respirando, depois que a onda passar. Entendeu a
parte do voc?

Boa mudana para voc!

Se der medo, vai com medo mesmo!

[]s

Roberto

97
98 Agilidade nas empresas. Guia Scrum para quem no de TI.

CV do autor, Roberto NAVAS Pinheiro

28 anos em IT & Operaes, 23 em Bancos internacionais. 21 gerenciando projetos.


Certificaes PMP e PRINCE2. Posies seniores em empresas internacionais como IBM e
Amazon. Gesto de mudanas de negcios, com equipes distribudas em mltiplos pases.
Profissional experiente em Centros de Servios Compartilhados. Habituado ao gerenciamento
de equipes multidisciplinares em projetos e programas de milhes de R$ de oramento.

Habituado a liderar projetos prioritrios que requerem recursos considerveis e


integrao de equipes multifuncionais. Lidera projetos desde a concepo, entrega de produtos
iniciais at a utilizao final em operao, produo e/ou mercado. Faz interface com todas as
reas participantes dos projetos incluindo patrocinadores, usurios, clientes e fornecedores, em
modelos contratuais tipo virada de chave, preo fixo e alocao. Faz garantia de qualidade,
aderncia a processos de negcios e experincia do cliente. Conduz comits de direo com
executivos seniores. Gerencia um conjunto de projetos de maneira a otimizar o retorno sobre o
investimento e garantir o alinhamento com a estratgia da organizao, administrando o
nivelamento de recursos para resolver problemas de capacidade.

Trabalha de modo eficiente em ambientes desafiadores. Flexvel, confivel e


comprometido. Tem uma liderana orientada entrega, autocontrole, autoconhecimento e
motivao, pragmtico, diplomtico e Coach (treinador).

Experiente em disciplinas de Requisitos, Arquitetura, Desenho & Construo, Testes e


Implementao em produo. Habituado a utilizar contagem FPA/NESMA, mtodos geis,
gesto Scrum, prticas XP & OpenUP, CAPEX e OPEX, BABOK, BPM CBOK, SOX e
Segurana da Informao. Profundo conhecimento de PMBOK, BABOK, PRINCE2, ITIL e
COBIT.

Agile Coach e Trainer de Scrum Masters e Product Owners.

Resumindo:

PMP, PRINCE2, Agile, Coach, Trainer, Mentor, PMO-CC ... (oba, mudana)
PLA Solutions 99

PLA Solutions

Somos um grupo de profissionais experientes nas reas de operao de escritrio de


projetos e programas do portflio de iniciativas (alinhados com a estratgia e a gesto da
capacidade de entrega). Temos certificaes de reconhecimento internacional em projetos
atravs do PMI/USA (PMP) e UK Government (PRINCE2).

Conhecimentos certificados no mundo Lean Management (Six Sigma Black Belt) e


Mtodos geis de desenvolvimento de produtos e servios (Scrum Master, Product Owner,
Agile Coach, Trainer e Scaled Expert).

Alm das certificaes, temos experincia PRTICA em implementaes de sucessos


em gesto de PMOs, seguindo o pensamento Lean enxuto e usando mtodos geis de
desenvolvimento de Produtos e Servios.

Ns somos bons de planejamento, mas temos especial disciplina na Execuo com


qualidade e eficincia.

Atuamos de modo profissional em processos de Coaching e Mentoring com


certificaes internacionais, e sabemos maximizar o desenvolvimento das pessoas durante as
transformaes organizacionais que promovemos. Afinal, empresas so o resultado de pessoas.

Fazemos gesto de Mudanas de forma certificada pelo HUCMI conveniado do ACMP


Global. Tecnologia, Negcios, Produtos, Servios e Operaes de excelncia so vitais, mas
somos especializados em gesto das pessoas, que fazem isso tudo acontecer.

Vamos tomar um bom caf?

contato@plasolutions.com.br

(11) 3280-4771 Skype

(11) 98125-6429 WhatsApp

99
100 Agilidade nas empresas. Guia Scrum para quem no de TI.

VCPRO training

VCPRO uma marca do grupo PLA Solutions. Nosso foco est em treinamentos
comportamentais, de modo a auxiliar pessoas e empresas a atingir mais resultados e mais
rpido, ainda, com maiores controles e menos riscos.

VCPRO contribui com empresas e profissionais no desenvolvimento de competncias,


habilidades e atitudes dos lderes de sucesso.

Atravs de um programa de treinamentos comportamentais para desenvolvimento de


lderes com experincia prtica em componentes da inteligncia emocional, o workshop
PMRAD Profissional Moderno RADioativo, desenvolve e auxilia pessoas e empresas a adquirir
hbitos e atitudes vencedoras.

PMRAD Mdulo I liderana, inteligncia emocional (12 horas)


PMRAD Mdulo II autoconhecimento (28 horas)
PMRAD Mdulo III performance pessoal (10 horas)
PMRAD Mdulo IV performance empresarial (encontros mensais)
CAPIE Mentoring 101

CAPIE Mentoring

Entre os anos de 2013 e 2015 a PLA Services desenvolveu um programa de Mentoring


com metologia prpria* denominado C.A.P.I.E.

- Criar um relacionamento de Mentoring


- Analisar a performance
- Preparar um plano de desenvolvimento de competncias
- Implementar aes de melhoria
- Encerrar o relacionamento de Mentoring

* por prpria entenda o trabalho de compilao de parte do material de


institutos nacionais e internacionais como: PMI - Project Management Institute, The
IIBA - International Institute of Business Analysis, IBC - Instituto Brasileiro de
Coaching, IFT - Instituto de Formao de Treinadores, Management Mentors USA -
Mentores profissionais.

O programa de Mentoring CAPIE da PLA Solutions disponibilizado atravs do


Workshop Projetando VOC, em duas verses: 1to1 e Group Mentoring. No relacionamento
individual 1to1, Mentor e cliente fazem um trabalho de avaliao dos skills pessoais,
mapeamento de situao As Is e To Be, desenvolvimento de metas e acompanhamento do plano
de ao at formalizar o resultado das aes no prximo ciclo de reviso de desempenho (seja
ele na periodicidade que a empresa do cliente adotar). A verso Group Mentoring do
Projetando VOC, concentra o trabalho em um dia inteiro de trabalho, com avaliaes
pessoais de autoconhecimento, levantamento do As Is e projeo do To Be utilizando-se de
frameworks do tipo Business Model You e Estratgia do Oceano Azul.

Assessments especficos do PMI Competence Development Framework e


Competncias do PMO VALUE RING so feitos na verso 1to1 somente.

O Workshop Projetando VOC acontece nas modalidades presencial e distncia


(Hangouts ou Skype).

10
1
102 Agilidade nas empresas. Guia Scrum para quem no de TI.
PMO encontros geis / tech Talks / People sharing toughts 103

PMO encontros geis / tech Talks / People sharing toughts

Ciclo de palestras presenciais e tambm webinrios com eventos temticos. O PMO


encontros geis acontece em So Paulo/SP desde 2015, em continuao um ciclo de palestras
realizados inicialmente em Curitiba/PR.

So encontros descontrados do tipo Happy-Hours mas com muito compartilhamento de


contedo e oportunidade de ampliar seu Networking e fazer negcios.

Em 2017 o PMO encontros geis est incorporando tambm duas trilhas temticas, a
saber:

Change Management people sharing toughts. Encontro de profissionais do


meio de Human Change Management, que compartilham ideias e pensamentos
transformadores.
Fintechs, Insurtechs and Agritechs tech Talks. Encontro voltado para o
ecosistema de empresas de tecnologia que empreendem solues de digitalizao dos servios
financeiros, de seguros e do mundo agrcola. To amplo quanto isto. E disruptivo do jeito que
voc imagina. Venha ver isso!

Para manter-se informado das palestras, use nosso Whats http://bit.do/whatsapp-


pmoencontrosageis para recados, informao, link dos webinars, perfis no LinkedIn, e o
esquenta das palestras.

O calendrio de palestras gratuitas de PMO encontros geis est neste link,


http://bit.do/pmoencontrosageis

Traga o seu conhecimento e leve o nosso com voc!

Seja voc tambm um palestrante.

Roberto NAVAS Pinheiro


contato@plasolutions.com.br
(11) 3280-4772 (Skype)
(11) 98125-6429 (WhatsApp)

linkedin.com/in/navas

10
3
104 Agilidade nas empresas. Guia Scrum para quem no de TI.
PMO Global Alliance & PMO VALUE RING 105

PMO Global Alliance & PMO VALUE RING

A PMO Global Alliance gestora de uma comunidade global de profissionais em


PMOs com mais de 5.000 membros, em diversos pases. A PMO Global Alliance prov servios
e produtos desenvolvidos a partir do trabalho colaborativo e da inteligncia coletiva desta
comunidade, dentre eles, a metodologia PMO VALUE RING.

PMO VALUE RING uma metodologia internacional, fundamentada por um amplo


estudo com a consolidao da experincia de profissionais maduros de diversos pases, apoiada
por uma ferramenta comercializada na modalidade SaaS (Software as a Service), com a
possibilidade de adoo de modo simplificado pelas organizaes, sem investimento em TI.

PMO VALUE RING apoia a criao, a reviso e a operao do PMO, com foco na
gerao de valor efetivo para a organizao

10
5
106 Agilidade nas empresas. Guia Scrum para quem no de TI.

PMO VALUE RING fornece recomendaes e orienta a configurao do PMO a partir


de experincias que foram bem sucedidas, e semelhantes a situao real da organizao.

Parte fundamental e indissocivel da PMO VALUE RING que o seu mind-set prope:

- que o PMO seja visto como um prestador de servios;

- que como tal, ele possui clientes, seus stakeholders, cada qual com necessidades e
tambm expectativas, normalmente, especficas;

- que atender as expectativas dos stakeholders a melhor forma de gerar valor


percebido;

- que o PMO cumprir esse objetivo provendo servios (funes) da melhor forma
possvel.

A metodologia e ferramenta PMO VALUE RING no vendida isolada somente como


licena de uso de software, mas sim acompanhada de profissionais acreditados para oper-la e
obter o maior benefcio para os stakeholders. H 3 certificaes no programa. A saber:
PMO Global Alliance & PMO VALUE RING 107

Para garantir e maximizar o retorno sobre os seus investimentos em PMO,


procure um professional certificado em PMO-CC (PMO VALUE RING Certified
Consultant) atravs de um dos RSP (Regional Solution Partner).

O amigo Amrico Pinto Presidente do Conselho da PMO Global Alliance.

10
7
108 Agilidade nas empresas. Guia Scrum para quem no de TI.

Das könnte Ihnen auch gefallen