[Ed.: Colaborou na preparação deste entrevista: Jorge Alberto Diz]
Alguns editores e colaboradores do InfoQ Brasil estiveram presentes no Agiles 2008, que aconteceu em Buenos Aires, na Argentina. Uma série de entrevistas foram realizadas durante o evento e serão publicadas em breve. A primeira delas foi realizada com Tobias Mayer, palestrante do Agiles 2008 e instrutor do curso Certified Scrum Master do qual tivemos a oportunidade de participar.
A entrevista é repleta de frases motivantes e explicativas sobre Scrum. Um dos pontos altos da entrevista foi a discussão sobre as controvérsias entre Scrum e Lean, nas brincadeiras onde Mary Popendick mencionou as críticas em relação a timeboxing realizadas durante seu keynote. Outro ponto interessante foi a resposta dele as críticas da comunidade em relação ao processo de certificação da Scrum Alliance e a necessidade ou não do Scrum Master.
Enfim, tem vários trechos interessantes e acredito que a leitura seja interessante principalmente para as pessoas que estão iniciando com Scrum, mas evidentemente é válida também para quem já tem alguma experiência.
Vale ressaltar que a participação Brasileira no evento, embora pequena foi um grande sucesso, visto que gerou a cooperação entre Brasil e Argentina para realizar a edição Agiles 2009 no Brasil, em um dos lugares preferidos da comunidade Argentina (e da Brasileira também) que é Florianópolis trazendo grandes nomes para o evento e esperando trazer grandes nomes da comunidade Brasileira através do processo de submissão de palestras que já está aberto.
InfoQ Brasil: Um pouco sobre Tobias Mayer por Tobias Mayer.
Resposta
InfoQ Brasil: Pessoas de de fora, que vem com uma visão externa, tem mais chances de conseguir realizar mudanças?
Resposta
InfoQ Brasil: Sobre a certificação Scrum Master.
Resposta
InfoQ Brasil: Quais são os principais benefícios do Scrum?
Resposta
InfoQ Brasil: Sobre Timebox.
Resposta
InfoQ Brasil: Se você tivesse um time caótico e pudesse adicionar uma prática de Scrum, qual prática seria?
Resposta
InfoQ Brasil: O que você tiraria de um time que está funcionando bem?
Resposta
InfoQ Brasil: Porque as técnicas de estimativa de Scrum são "melhores" que as outras?
Resposta
InfoQ Brasil: Qual o valor do quadro branco com postits?
Resposta
InfoQ Brasil: Ajudaria se tivéssemos uma TV grande ou algo assim?
Resposta
InfoQ Brasil: O Scrum Master deve ser um desenvolvedor ou ter experiência com TI (Tecnologia da Informação)?
Resposta
InfoQ Brasil: Mas... o nome Scrum vem de uma metáfora dos esportes, e nos esportes geralmente o treinador tem experiência jogando... Scrum Master tem que ter experiência desenvolvendo?
Resposta
InfoQ Brasil: Referências
Resposta
Respostas
InfoQ Brasil: Eu acho que poderíamos conversar um pouco sobre você, como foi seu envolvimento com Scrum e sobre o que você está fazendo agora.
Tobias Mayer: A primeira vez que tive contato com Scrum foi em 2003, eu acho, eu já estava familiarizado com extreme programming (XP) desde 1998, escrevi um artigo que foi publicado naquela época, isso foi antes da publicação do primeiro livro de Scrum. Eu estava pesquisando sobre processos de software na universidade South Bank, em Londres, e me interessava muito a idéia de que você não pode definir com antecedência projetos de software, você tem que permitir que eles encontrem seu próprio caminho para emergir.
Há um ditado de “Ian Foster” que eu gostava muito na época, que é: “como posso saber o que penso até ver o que digo?”. É a idéia de que o pensamento é um processo que resulta de se ter tido uma conversa; você começa a aprender como pensa através da fala, e eu tentava aplicar esse princípio ao software – como vou saber o que estou construindo?– eu construía, na época, ferramentas para medidas, instrumentos para análise estática e coisas assim...
Eu não tinha uma certeza clara do que eu iria medir, de como essa ferramenta iria funcionar , qual o tipo de interface que teria ou qual o valor disso para as pessoas, então eu permitia que o processo fosse emergindo... E as pessoas perguntavam: “Qual é o seu plano? O que isso fará no final?” e eu respondia: “não sei...eu não sei o que penso até ver o que digo.” (risos)
Na realidade, o uso desse tipo de princípio foi muito semelhante ao Scrum e XP, que são baseados em processos empíricos. Descoberta através do fazer. Quando terminei aquela pesquisa me mudei para os Estados Unidos, eu mudei de Londres para Califórnia em 1999, e lá comecei a trabalhar em indústrias de software. Primeiro trabalhei para uma empresa iniciante onde só havia caos e hacking, esse era o processo deles, e daí fui para Yahoo onde havia Waterfall, quer dizer o processo Waterfall, que eles haviam recentemente imposto na empresa. Era horrível e desastroso e as pessoas passavam a maioria do tempo em reuniões, e haviam muitos documentos para serem escritos e aprovados e assinados antes de que qualquer um pudesse fazer qualquer coisa... era um entrave e eu comecei a investigar extreme programming (XP) mais a fundo, porque começamos a fazer testes de unidades e o meu grupo era um grupo de Java, a maioria das pessoas de lá estava trabalhando, tínhamos aquela margem de pessoas e Java tinha uma estrutura que havia sido justamente projetada para os testes de unidade Framework, a J Unit.
Então eu comecei a explorar o uso daquilo, e de como podia nos ajudar a escrever softwares melhores, nos já estávamos fazendo uma remanufatura rigorosa em nossos códigos, acho que é algo que eu sempre fiz, eu nunca codifiquei não-refratariamente, eu nunca deixei de ler OOP (programação orientada a objetos). Então começamos a pegar algumas práticas de XP em nosso grupo e daí em diante quis explorar mais e encontrei um grupo no Yahoo chamado extreme testing, que achei interessante, e lá vi referências a essa coisa chamada Scrum, e fiquei me perguntando “o que é isso?”. Então comecei a ler mais sobre o assunto e ele retornou e fui levado ao “Manifesto Ágil” que eu rapidamente imprimi e colei na parede do meu box, muito para indignação do meu gerente de projeto, que não gostava nada do que via, mas eu continuei a pesquisar sobre isso e descobri que havia treinamento disponível, e me registrei para um treinamento local com Ken Schwaber, isso foi no início de 2004.
Eu já havia tentado implementar algumas práticas leves de Scrum no nosso grupo e realmente foi a idéia de se ter reuniões freqüentes com pessoas que testam e desenvolvem softwares trabalhando juntos e de ter programação em pares e aí testes em pares com desenvolvedores para achar bugs mais cedo e com mais frequencia. E aí nós fizemos um programa onde tínhamos que reduzir, tínhamos que reproduzir um sistema que havia sido mal escrito e tínhamos que medir todos os bugs que foram encontrados nele, era uma maneira muito tradicional de desenvolvimento, levou muito tempo, ele era um enigma de tantos bugs e a integração foi um pesadelo. Nós reescrevemos esse sistema usando uma coisa que era uma imitação de um Scrum ágil, que fizemos baseados no que sabíamos e naquilo que eu estava contando às pessoas, funcionou, nos reduzimos, fizemos uma comparação de bugs da segunda tentativa com a primeira e houve uma melhora de 700%, foi tão drástica que nos não tivemos que fazer nenhum aconselhamento sobre bugs, no final do projeto eles foram consertados enquanto nós prosseguíamos.
InfoQ Brasil: Conhecer o domínio não foi um fator?
Tobias Mayer: Não, nem conhecíamos bem o domínio da primeira vez também. Nós todos estávamos bastante familiarizados com o domínio que trabalhávamos, foi um domínio empreendedor reconstruir o messenger, nós todos tínhamos bastante familiaridade com o messenger, apenas escrevemos mal o sistema e aí sim, podemos dizer que da segunda vez aprendemos um pouco com a primeira mas nós o escrevemos de um modo muito diferente. Enquanto muito do original foi escrito em linguagem C, o segundo foi escrito em Java, algumas pessoas eram menos qualificadas em Java, você poderia dizer que o primeiro era um produto para se jogar fora... eu não chamaria nem de um software mal escrito.
Mas é claro que houve um pouco de aprendizado, mesmo assim 700% é muito, vamos dizer que no primeiro tínhamos 700 bugs e nós tínhamos 100 bugs, nós tínhamos 100 bugs mas estávamos lidando com eles num trabalho contínuo, assim eles não estavam todos lá no final como estavam no primeiro. Na essência havia um nível maior neles, eu não lembro os números exatos mas eram impressionantes o bastante para que eu escrevesse um relatório e começasse a mandar a diferentes pessoas de processamento e gerência e dizer “hei, você deveria tentar essa coisa de agile”, mas demorou mais um ano para que alguém levasse realmente a sério. Eu encaminhei isso para uma das listas internas e houveram algumas pessoas interessadas o bastante para fazerem um acompanhamento pessoal comigo, mas ninguém de autoridade deu importância por mais um ano.
Eu tinha um amigo no departamento de recursos humanos e eles tinham dinheiro para trazer palestrantes convidados, então o convenci a trazer Ken Schwaber para uma palestra, e como Ken não podia vir ele mandou Jeff Sutherland, que tinha uma reputação razoavelmente boa, ele tinha uma boa reputação em softwares em geral, mas tinha uma reputação bastante boa nisso também, e os executivos que vieram para a palestra gostaram dele e o ouviram, eles não me ouviam mas ouviram Jeff (risos).
Daí em diante foi “vamos fazer um piloto e vamos fazer isso formalmente” e eles designaram “Pete Dima” que já era o encarregado do processo de software no estilo Waterfall e teve que dar uma virada totral... mas ele abraçou isso bastante bem, ele abraçou o agile muito bem!
InfoQ Brasil: Você acredita que alguém que vem de fora, que vem com uma visão externa, tem melhor chance de fazer as coisas mudarem?
Tobias Mayer: Pessoas que vem de fora são consideradas especialistas, por alguma razão pessoas que trabalham na sua empresa não são consideradas especialistas e pessoas que não trabalham na sua empresa são especialistas... então vá entender isso... (risos)
Minha posição na empresa era de gerente iniciante, gerente de desenvolvimento, eu não tinha um cargo alto, então eu não tinha a voz e os ouvidos das pessoas certas, eu podia gritar alto sobre o Agile mas ninguém queria ouvir.
Mas alguém vindo de fora está vindo automaticamente como um especialista na área, então ele será ouvido. Assim.. é importante trazer pessoas, é a razão porque agora me levam às vezes em empresas, eles dizem “queremos fazer o Agile mas ninguém nos ouve, então queremos que você venha e fale sobre isso”. Eles podem dizer a mesma coisa que estou dizendo, mas eles não... eu não sei.
InfoQ Brasil: Você pode falar um pouco sobre Scrum Alliance e o valor de se ter um certificado de Scrum Master?
Tobias Mayer: Quando Ken Schwaber desenvolveu Scrum, eu não lembro bem a história exata, mas ele conversava talvez com Martin Fowler ou com algum dos outros que assinaram o Manifesto Ágil, sobre como poderíamos fazer com que as pessoas se interessassem pelo que estávamos fazendo aqui, porque eles estavam convencidos de que essa era a maneira correta de se desenvolver software e na época a Microsoft fazia todo o processo de certificação, e era uma coisa importante no mundo Microsoft, todo mundo tinha que se tornar um arquiteto ou desenvolvedor certificado pela Microsoft e assim se conseguia emprego, então as pessoas se inscreviam convictas.
Então, Ken sugeriu: “por que nós não certificamos pessoas?”, e basicamente sozinho ele criou o Programa de Certificação Scrum (Certified Scrum Program), que ele chamou de certificação Scrum Master (Certified Scrum Master). Ele mandou fazer certificados escritos a mão e saiu por aí dando cursos e oferecendo certificação, e as pessoas começaram a se inscrever até o ponto em que ele sozinho já não dava conta. Então ele começou a endossar pessoas que haviam sido treinadas para darem o treinamento, e o modo de fazer isso era que você trabalhava com Ken durante uma sessão e se tornava um Scrum Master, a Scrum Alliance saiu realmente daí, e então Ken se associou a Mike Cohen e Ester Derby e criou essa coisa chamada Scrum Alliance, era uma organização sem fins lucrativos, ainda é, e foi se tornando o que é hoje, passou por muitas mudanças, por muitos problemas, e as pessoas tentaram fazer com que fosse em diferentes direções. Agora está numa posição consideravelmente estável, tem um bom diretor de gerência que realmente entende nosso trabalho, Jim Cundiff é seu nome.
O programa de certificação está se tornando mais maduro, temos aproximadamente 80 instrutores agora e o processo de certificação para se tornar um instrutor ficou bem mais difícil, você tem que ser um Scrum Master certificado e tem que ter trabalhado com Scrum por pelo menos um ano, e provar isso através de um relatório de experiência escrito e revisado em pares por outros instrutores e praticantes certificados, e depois de um ano disso, outro ano daquilo, então já são 2 anos, daí você pode se inscrever para ser um instrutor e o formulário de inscrição é bastante extenso. Você deve provar que fez treinamento, que tem experiência com Scrum, que entende os princípios, que você é capaz de ensinar outras pessoas, tem que apresentar o seu material e mostrar o quão interativo é o seu curso e quanto conhecimento você pode transmitir às pessoas, e isso é revisado por dois ou três outros instrutores da organização e se todos aprovarem ele vai para o conselho para uma aprovação final.
Agora também está sendo introduzido um exame para a certificação do Scrum Master, que será no final do curso de treinamento, assim ele não será aplicado durante o curso, é algo que vai demandar pesquisa e estudo adicional ao curso de treinamento, onde serão testados os princípios básicos de Scrum. É claro que passar no exame não fará de você um grande Scrum Master, ser um bom Scrum Master o tornará um Scrum Master melhor, é essa a verdade.
Um curso de dois dias não vai te ensinar, um exame não vai tornar você melhor, mas é uma forma de se medir, é possivelmente uma forma útil de medida, quando alguém faz um esforço para passar no teste acredito que isso signifique algo, e é uma coisa boa!
InfoQ Brasil: Que bom ouvir isso!
InfoQ Brasil: Quais são os principais benefícios do Scrum?
Tobias Mayer: Pessoas Felizes! É o principal benefício, eu acho, o que eu tenho a dizer.
Nas organizações que eu trabalhei as quais estão fazendo Scrum tendem a ter um maior grau de prazer, diversão e risos do que aquelas que não fazem. Você reparou que muitas empresas grandes fornecem coisas como jogos e tênis de mesa, salas de jogos, de forma que seja agradável fazer isso, de forma que seja uma compensação para um ambiente de trabalho infeliz, que você tenha que deixar seu ambiente de trabalho, afim de jogar.
E o que o Scrum faz é introduzir um senso de jogo dentro de seu ambiente de trabalho no dia a dia o que, para mim, é mais saudável, isso é um grande benefício, obviamente o outro benefício é a colocação do produto no mercado mais rapidamente, com melhor qualidade, isso é bom para os clientes e é bom para a moral das pessoas que fizeram o software e é bom para qualquer um desses dois grupos, produtos em marketing, pessoal de marketing e pessoal de vendas. É bom para todo mundo e a maneira que o Agile ou o Scrum entrega produtos para o mercado mais rapidamente é usando o princípio da priorização. Nós não temos documentos gigantes de requisitos que tentam documentar o produto inteiro porque normalmente só 20% disso tem valor alto e nós focamos nisso e nós fazemos muito muito bem. Nós gastamos o nosso tempo para fazer isso bem feito. Nós testamos apropriadamente, entregamos e recebemos o retorno rapidamente. Então o valor do Scrum é software entregue frequentemente e Pessoas Felizes!
Pessoas Felizes agora é muito importante porque é tão difícil de contratar e quando você fornece um bom ambiente eu acredito que você tem uma vantagem competitiva. Eu acho que o time de Scrum mudou para um diferente modelo de entrevistar pessoas, se alguém levar uma pessoa para uma entrevista e eles deixam essa pessoa passar o dia com o time, ela irá pedir para trabalhar lá. Você não terá preocupações com uma negociação salarial.
InfoQ Brasil: Durante todo o curso e as conversas eu ouvi muito sobre “time box”. Você poderia explicar o valor do time boxing, reuniões e coisas assim?
Tobias Mayer: Eu gostaria de complementar a pergunta, eu ouvi algo sobre non-time boxing…
InfoQ Brasil: Esta manhã?
Tobias Mayer: Sim
InfoQ Brasil: Eu ia fazer um comentário sobre isso. Eu não acho que o Scrum se encaixe na coisa do non-time boxing, mas gostaria de ouvir sua opinião.
Tobias Mayer: Para mim time-boxing tem a ver com ritmo. Acredito que você precisa ter cadência ou ritmo para o que você faz, e eu acho que time boxing te dá isso. A idéia do contínuo, preeencher requerimentos através de um time e te-los trabalhando sem parar nisso é um pouco preocupante para mim, porque parece uma linha de produção... E não acredito nisto.
O que eu lembro é de manufatura, a idéia desse fluxo contínuo de valor da forma como isso é falado na comunidade Lean, eu acho que é perfeito para quando se tem uma linha de produção ou para quando se está criando algo que é repetitivo, e software é muito mais um empenho artístico, se você olhar para o artesão, eu não acho que o artesão só trabalhe e trabalhe e não pare, eu acredito que exista um ritmo na atividade deles, eles fazem pausas e intervalos periodicamente, e para mim o valor do time-boxing é que no fim da iteração você tem uma reunião para reflexão.
Agora é claro que você pode ter reunião reflexivas mesmo sem ter time boxing , porque você opta por fazer essa reunião, mas há algo sobre o ritmo da retrospectiva quando você sabe que terminou, há uma sensação de que aquele trabalho foi completado, mesmo sabendo que muito mais virá você sabe que pode respirar e parar e funciona assim... se você está atravessando um rio saltando sobre pedras, cada vez que você pula de uma pedra para outra você tem que parar e se reequilibrar, certo? Caso contrário você cairia na água, se ficasse só pulando e pulando...
Para mim o momento de retrospectiva é então no fim da iteração, onde a razão para o time-boxing é se chegar no final do time box, - nós paramos, respiramos fundo, reequilibramos, olhamos ao redor e decidimos o que vamos fazer agora – e isso nos dá uma visão ampla, nos permite parar e olhar para essa vista mais ampla ao invés de focarmos apenas na próxima tarefa... quando você olha para a arquitetura total? Quando você tem a visão do todo? Eu acho que o ritmo do Scrum te dá esse “zoom in” e “zoom out”, dando uma visão próxima quando você está na corrida e uma visão afastada quando você sai dela, pisa fora dela...
Hey, sobre o que é esse grande sistema, o que é nosso arquiteto, de onde ele veio, onde estamos indo, como o que está por vir se encaixa nisso. Assim eu gosto disso pelo ritmo, o time-boxing te dá o ritmo. Outra coisa que eu mencionava sobre time-boxing quando eu ensinava CSM é que é muito, muito difícil ter as pessoas que você precisa ter nos encontros de revisão. Você tem encontros de revisão num horário regular, você pode agendar com meses de antecedência, mas se você não estiver fazendo time-boxing você pode fazê-los quando quiser, mas pode não conseguir ter as pessoas que precisa lá.
Então, quando pessoas da comunidade Lean ou Kanban dizem: ...” você não tem que fazer time boxing”... Não, você não precisa, mas a idéia do time boxing iria aparecer sozinha porque se você quer ter certeza que as pessoas estarão nas suas reuniões de revisão, e você quer que o time faça uma pausa e olhe novamente para o grande sistema, o time boxing iria aparecer daí ou por ele mesmo.
InfoQ Brasil: Então vamos pelo início, vamos começar falando disso.
InfoQ Brasil: Vamos para o melhor e pior, ok? Se você tivesse um time caótico e pudesse adicionar uma prática de Scrum, qual prática seria?
Tobias Mayer: Primeiro vou falar de duas e depois eu restringirei, que seriam tanto a reunião diária quanto a retrospectiva, acho que eu poderia sugerir algo como uma retrospectiva semanal para começar. Então, faça o que estiver fazendo no meio do seu caos, e toda semana reserve duas horas para sentar em time e conversar sobre o que funcionou e o que não funcionou, e se comprometa a fazer alguma coisa diferente, acho que esta seria a minha sugestão. Talvez duas horas seja muito tempo, talvez você só consiga dispor de uma hora, um período de tempo que permita que o time pare o que estiver fazendo e comece a se reequilibrar. Você precisará de um bom facilitador nesse time, pois caso contrário, as pessoas não verão o valor que isso tem, mas é só uma prática, se você não refletir, não conseguirá nem melhorar.
InfoQ Brasil: Algum evento social pode ajudar,.. vamos dizer, por exemplo, pizza..?
Tobias Mayer: Possivelmente sim, mas eu sempre evitei qualquer tipo de comida, bebida ou incentivo para que os times façam coisas, não sei por que, é uma coisa pessoal. Acho que cheira a paternalismo, onde você é um pouco babá deles. Nós não precisamos comprar comida para desenvolvedores de software que ganham US$ 120.000,00 por ano; em minha opinião eles podem comprar sua própria comida... (risos)
Sei que há pessoas que dizem que ajudam trazer comida para uma reunião, mas prefiro que o valor da reunião seja ela mesma, se o valor de uma reunião não é compreendido, trabalhe para fazer com que seja. É uma espécie de suborno, venha e eu te alimento, muitas pessoas gostam disso e poderão te dar muitas razões para gostar, eu não. E isso é só meu método pessoal.
InfoQ Brasil: A segunda pergunta, que eu acho é o pior... O que você tiraria de um time que está funcionando bem? Eles estão fazendo todas as reuniões...
Tobias Mayer: O que me faz pensar é que se temos um time de Scrum que está funcionando bem, vamos fazer com que funcione menos bem tirando alguma coisa... (risos) então há que se tomar cuidado aí.
Acho que não tiraria as reuniões diárias padrão, definitivamente não tiraria a retrospectiva ou revisão, você não pode tirar a revisão porque não pode ter um processo empírico se não estiver revisando, e se tirar a reunião de planejamento quem saberá o que estão fazendo? Então, de certa forma, não se pode tirar nenhuma dessas reuniões. Elas são absolutamente essenciais, você pode acabar não precisando de um Scrum Master, possivelmente se o time tiver um alto desempenho e eles entenderem os princípios de Scrum, se a organização ao redor deles os apoiar no que estiverem fazendo e pronta para auxiliar na remoção de impedimentos, o Scrum Master pode não ser necessário. Assim, esse papel podia ir, poderia, não iria.
InfoQ Brasil: Você mostrou muitas técnicas de estimativa durante o curso CSM, estimando projetos que são um pesadelo atualmente. Por que você acredita que eles funcionariam com Scrum, ou você acha que eles não funcionariam de forma alguma?
Tobias Mayer: Não, eu realmente acho que eles funcionam com Scrum, porque estamos estimando baseados em conhecimento renovado, de forma regular. A maioria das estimativas dos produtos de software tende a ser feita cedo, no início, como já mencionei no curso, e é essa a hora que tendemos a ser mais estúpidos sobre os projetos que conhecemos menos do que em qualquer momento futuro, assim qualquer estimativa que fazemos no início será pior do que uma estimativa que fizermos depois disso. Então o que o Scrum faz, ele estima iterativamente, ele fará estimativas grosseiras no começo e irá refinando-as regularmente, baseado num retorno real, de se estar construindo um software real e de entender do que o time é capaz.
Então... no começo você tem um time que provavelmente não se conhece, nós temos uma tecnologia com a qual podemos ainda não estar familiarizados e requisições que são vagas e indefinidas, assim tentar fazer qualquer tipo de estimativa com três fatores desconhecidos faz com que as chances de se estar certo sejam muito pequenas. Agora se você tiver pessoas muito, muito experientes em software, dentro de um longo período de tempo, aí então pode haver um grau de precisão. Mas daí você começa a desenvolver e descobre que eles não estão no caminho certo, ou causa certa, e se você assistiu a palestra do “Demetric” esta manhã, ele falou sobre isso: times não começam necessariamente com uma capacidade 100%, ou com habilidade 100%, e o medo é – “oh, nós não vamos conseguir fazer a tempo.”
Relembrando o jogo que fizemos no curso, éramos muito precisos como time estimando os pontos que faríamos, só não fazíamos isso no primeira, segunda ou terceira jogada, mas chegávamos lá. Nós somos muito melhores com estimativas do que pensamos se confiarmos em nós mesmos, e um dos perigos de se estimar é que estamos sob a pressão de chegar a um número que fará as pessoas felizes, e queremos fazer pessoas felizes; então , mentimos... Alguém pode te dizer: “nós precisamos que isso seja feito em 6 meses, o que você acha?” Eles já te induziram ao dizer 6 meses, e o que você pode dizer? Então diz: “ok, eu acho que podemos fazer”, porque não tem nenhuma idéia, então talvez possa fazer. Eu já fiz isso como gerente, eu comprometi meu time a fazê-lo, conforme fui me aprimorando no que fazia, eu disse: “eu não farei mais isso” , eu vou retirar o que disse ao meu time e não vou dizer que eles querem isso feito em 6 meses, perguntarei quanto tempo levará para que façam, aí você tem honestidade, e honestidade geralmente é precisa. Respondi sua pergunta?
InfoQ Brasil: Sim
InfoQ Brasil: Se olharmos fotos e Scrum no Google ou qualquer outro, encontramos montes de fotos de quadros, quadros de Scrum, com anotações e tudo mais, é lindo. Parece divertido, mas você poderia dizer qual o valor que essas coisas trazem para o time e para a sala de trabalho, e o aumento de comunicação?
Tobias Mayer: Bem, o primeiro valor que traz é visibilidade: quando você coloca todo o trabalho exposto na parede, escrito em cartolina ou bloquinhos de recados, ele está muito mais visível do que quando enterrado em planilhas no computador de alguém, mesmo que essa planilha esteja online em algum lugar. As pessoas não estão olhando para ela, haverá um esforço de se fazer um login para visualizá-la. Se estiver na parede você verá ao passar por ela, alguns times a colocam na sala de trabalho, outros deliberadamente colocam fora, no corredor, assim as pessoas que estão passando irão ver e querer saber mais sobre aquilo, ou aprender; então é um modo de se tornar visível o que se está fazendo.
O outro benefício é o de aumentar a colaboração do time, porque você tem que se reunir todo dia em volta daquele quadro, você tem que tocar fisicamente as histórias e tarefas em que está trabalhando e movê-las – você realmente vê as coisas se movendo pelo quadro - é uma experiência muito táctil para os membros do time, simplesmente adiciona mais sentido ao que fazemos. Colaboração não é o mesmo que comunicação, comunicação é o conversar, e colaboração utiliza os cinco sentidos, e talvez o sentido do tato. Nós não costumamos nos tocar num time de Scrum, mesmo sabendo que nos tornamos mais físicos a medida que aumentamos a familiaridade, mas em geral, o aspecto táctil talvez surja através dessas mãos movendo coisas ao redor, colaboração diz tudo sobre o envolvimento profundo com outras pessoas, escutar profundamente, compreender e questionar profundamente, você precisa ter todos os sentidos alerta para fazer isso, então acho que a tarefa, de certa forma, acentua esse comportamento. Quando você tem uma simulação de tarefa colocada em um computador, e alguns times fazem isso porque tem um ou dois membros do time fora do local, isso se perde, pois sempre se tem uma pessoa no teclado dirigindo a coisa e assim o foco volta para essa pessoa central ao invés de todos olhando para todos.
InfoQ Brasil: Ajudaria se tivéssemos uma TV grande ou algo assim?
Tobias Mayer: Sim, isso ajuda um pouco. Aparente há algumas boas ferramentas eletrônicas para simulação de quadros de tarefas, eu conheço mas não as usei, tenho tido bastante sorte de não ter de usá-las, mas somente usaria se tivesse um time distribuído e eu ficaria relutante em trabalhar com um time distribuído pela possível falta de colaboração.
InfoQ Brasil: Eu gostaria que falasse se existe ou não a necessidade do Scrum Master ser um desenvolvedor ou ter experiência com TI (Tecnologia da Informação).
Tobias Mayer: O que sinto sobre o Scrum Master é que ele tem que ser uma pessoa centralizadora de pessoas, não uma pessoa centralizadora de tecnologia; e quanto mais focado ele estiver na parte tecnológica, menos verá a dinâmica do time, e não acho que um Scrum Master focado em tecnologia desmpenharia este papel da melhor forma.
Não acho que seja ruim que o Scrum Máster tenha conhecimentos tecnológicos, eu tenho uma formação tecnológica, mas não me apoio nisso quando estou trabalhando como Scrum Master, não influenciaria o time de nenhuma forma falando sobre meus conhecimentos tecnológicos (que inclusive já estão desatualizados). Eu já trabalhei com times cujo domínio eu não conhecia bem, não entendia bem o que eles estavam construindo, há tantos projetos de software complicados e complexos no mundo, você sabe... Se for um Scrum Master que circula como eu, é difícil entender os detalhes de todos os domínios, e na realidade, você não precisa fazer isso. O time sabe, o product owner sabe, e entre eles existe o conhecimento do “que” e do “como” do sistema, o Scrum Master conhecendo pouco faria mais danos do que benefícios, é como aquele ditado “Um pouco de conhecimento é muito perigoso”, ou algo assim. Não lembro direito o ditado, mas a idéia é a de que se você só aprender um pouco sobre algo e tentar usar isso para influenciar as pessoas, irá causar danos.
InfoQ Brasil: É interessante que o Scrum recebe seu nome como uma metáfora dos esportes, quando pensamos em alguém como técnico de um esporte, geralmente essa pessoa tem alguma experiência com o trabalho, não precisa ser o melhor jogador...
Tobias Mayer: Acho que a única influência dos esportes é o nome Scrum. Há pessoas que trabalham em Scrum e que fazem analogias do trabalho em time com o time esportivo, mas eu não. Acho que a diferença é o tipo de time, eu nem gosto da palavra time pela conotação de time competitivo, porque não estamos em competição com ninguém quando estamos construindo um software, estamos colaborando com pessoas. Eu gostaria de chamá-los grupo de dança. Eu faço uma analogia com o tango em aula...
É como um grupo de atores que se une para criar algo, um grupo de atletas que se une para derrotar o outro time tem outra motivação. Então para eles o termo “técnico” pode ser apropriado, ele tem a mesma formação que eles porque... Eu acho que o esporte não muda tão rápido como a tecnologia, jogar futebol hoje não é tão diferente do que há 20 anos atrás. Construir um software hoje é inacreditavelmente diferente do que era há 20 anos. Então se eu tivesse um técnico que construísse software 20 anos atrás eu não escutaria uma palavra do que ele me dissesse hoje sobre isso – eu diria: “nós não usamos mais Cobol, nós evoluímos."
InfoQ Brasil: Você tem algum livro ou website para indicar para as pessoas que não acreditam ou ainda não conhecem Scrum, para que seja avaliado ou para convencê-las disso?
Tobias Mayer: Não, eu não acho que tenha um livro ou site para convencer as pessoas, a melhor maneira de se convencer sobre Scrum é ver um time em ação ou fazer parte de um time; eu tive essa experiência de tentar evangelizar o Scrum quando estava no Yahoo, apesar de uma ou duas pessoas ouvirem, na verdade isso irrita e chateia muitas outras mais. Scrum precisa do princípio da atração muito mais do que promoção.
A atração vem quando você tem time praticando isso com muito sucesso e permitindo que tudo seja visível, isso puxa outras pessoas que vêem e dizem: “eu quero saber o que está acontecendo aqui, eu quero isso que eles tem.” Se você sair vendendo, vai parecer um vendedor qualquer, e no mundo de hoje estamos imunes a essa conversa de vendedor, não queremos ouvi-la, então não conheço nenhum website que possa ser convincente.
Se as pessoas acreditarem que Scrum é só outra moda ou idéia louca que uns caras de software tiveram, eu indicaria inicialmente a Wikipedia e diria: “leiam sobre o complexo dos dois sistemas, e irão ver que o Scrum é uma progressão natural do modo que pensamos sobre o mundo de hoje e do modo que o mundo inteiro se move em direção aos negócios, e tudo se move em direção a um modelo que é muito mais baseado em confiança e auto-organização do que essas culturas de controle por comando, modos mecânicos de fazer coisas em que estivemos antes. Então leia sobre o complexo dos dois sistemas e aí vá para o Scrum.
Sobre os autores
Tobias Mayer é um Agile Coach e Instrutor, com experiência em desenvolvimento de software, design gráfico e facilitação de equipes/grupos de trabalho. Tem 20 anos de experiência como instrutor, 13 anos na indústria de software e 5 na comunidade Agile. Tobias atualmente trabalha como instrutor e facilitador, oferecendo serviços de coaching e consultoria para os times e organizações. Seu foco atual está no Scrum, oferecendo tanto cursos públicos como privados para explorar os princípios e as práticas do Scrum.
Yara Senger é Diretora Educacional e Instrutora da Globalcode, formada pela USP em São Carlos, diversos artigos publicados na Java™ Magazine e palestras ministradas nos maiores eventos de Java do Brasil, e também no JavaOne/EUA e Javapolis/Bélgica. Suas áreas de interesse estão realacionadas principalmente a desenvolvimento web com JavaServer Faces e tecnologias relacionadas, bem como metodologias ágeis de desenvolvimento e gestão.
Jorge Alberto Diz é Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP. Com 25 anos de estrada na área de tecnologia da informação, boa parte deles em grandes empresas, ensina há 7 anos, 2 deles na Globalcode. Interessado atualmente em metodologias, testes e linguagens específicas de domínio. Foi fisgado pelo Java em 1999.
Ana Claudia R. Silva, Canadense, ministra aulas para crianças e adolescentes, faz transcrições e traduções e é responsável pelo programa de Imersão em Ubatuba (http://immerseyourselfubatuba.blogspot.com/) e Olivia Borges, também professora e tradutora experiente.