Neste curto período no Brasil eu tive a oportunidade de conversar com muita gente, tanto do Rio quanto de outros locais que vieram para workshops ou eventos. Como não é novidade para ninguém o Brasil está cada vez adotando mais metodologias menos burras -ou “ágeis” se você preferir.
E algumas coisas se repetem constantemente. Uma delas é um problema comum em projetos e clientes onde eu já estive mas mostra-se de maneira curiosamente popular no Brasil. É o problema da quebra de paredes.
Mas quebrar paredes não era bom? Sim, é! Quebre as barreiras impostas por processos e ferramentas inúteis. Quebre as paredes que não deixam desenvolvedor conversar com cliente, quebre as barreiras que não deixam um time ser multifuncional!
Só cuidado para não quebrar as barreiras que protegem o time.
Scrum é o sabor favorito do Brasil e creio que a forma como ele é ensinado ajuda a causar problemas. O sujeito que assume o papel do Scrum Máster Jedi lê na sua apostilinha que seu papel é remover impedimentos. O cara não sabe direito o que é o tal do impedimento mas por algum motivo ele acha que é basicamente ser uma polícia do processo. A grande maioria das pessoas que eu conheço que têm “Scrum Master” como cargo têm como única tarefa ter certeza que todos estão nas reuniões certinhas e que o Scrum está sendo seguido conforme o jefe mandou.
E aí vem a ilusão de que o processo por si só vai resolver os problemas. Vamos colocar todos os desenvolvedores numa mesa tão pequena que não caiba um mousepad, vamos deixar o cliente ligar para o desenvolvedor cada uma das 232 vezes que ele muda de idéia durante o dia e a mágica dos times auto-gerenciáveis, auto-motivados e auto-limpantes vai fazer tudo funcionar.
Não vai.
Times auto-gerenciáveis evitam desperdício. São ótimos. Cliente poder falar com desenvolvedor evita desperdício. É ótimo. Tudo é maravilhoso, exceto pelo fato que as pessoas ainda são as mesmas.
Uma pessoa que fazia de tudo para destruir o seu projeto não vai melhorar só porque agora faz parte do time. Um cliente que é extremamente indeciso vai perturbar tanto o desenvolvedor que ele não vai conseguir escrever uma linha de código. Um sujeitinho metido a comandante de tropa nazista não vai melhorar porque agora não chamam ele de gerente mas de Product Owner.
Minha palestra no Caelum Day semana passada –que ainda não está disponível mas estará em breve- foi sobre reduzir o tamanho dos ciclos de feedback durante o desenvolvimento. Este é o ciclo do desenvolvedor que desperdiça 5 minutos esperando um servidor de aplicações subir para ver se algo funciona ou não. Estes ciclos técnicos são relativamente simples de resolver, existem técnicas e tecnologias para isso.
Mas trabalhar escrevendo código é apenas uns 50% do que eu faço hoje em dia. Eu também tenho que gerenciar escopo, tempo, recursos e pessoas durante um projeto. A parte do desenvolvimento de software é bem mais fácil –é o que eu gosto de fazer- mas esta outra parte sempre me dá mais trabalho porque eu não me interesso em aprender mais do que o necessário sobre isto.
E uma das coisas que eu aprendi aos trancos e barrancos e hoje em dia considero parte do necessário para um Iteration Manager, Scrum Master ou qualquer coisa que você prefira é que os tais dos ciclos de feedback existem também for a do aspecto técnico. Como gerente de iteração você precisa zelar para que seu time consiga produzir sem problemas. Você não os manda fazer as coisas –eles se gerenciam- mas seja lá o que eles resolvam fazer você precisa ter certeza de que não existe nada roubando tempo deles.
E, infelizmente, ao contrário dos ciclos técnicos eu não consigo listar técnicas e padrões para reduzir os ciclos de gerência de projeto. Minha sugestão inicial é que é melhor um time sem gerente de iteração do que um time com um gerente ruim. Se você tem um pequeno ditadorzinho como desenvolvedor movê-lo para Scrum Master só vai fazer tudo piorar.
A segunda é cuidado se implantar o comunismo na sua empresa. Tornar as pessoas “iguais” vai resolver alguns deles mas vai criar novos. Esta coisa de “todos juntos vamos de mãos dadas, cantando a canção e entregando valor pra missão” é balela. Você sempre vai ter o cliente indeciso, o Scrum Master ditador, o desenvolvedor que não produz nada… métodos ágeis vão deixar os problemas aparentes mas alguém tem que agir, eles não se resolvem por mágica.
Um exemplo relativamente recente de como você precisa prestar atenção aos ciclos foi, para mim, o meu último release do Globo Vídeos dentro da Globo.com. O Vídeos foi o primeiro time de projeto ágil na empresa –não foi o primeiro usando Scrum porque nós nunca usamos exatamente Scrum- e tínhamos um prazo ridículo e uma equipe pequena para entregar um dos sites mais importantes da empresa.
Olhando para o nosso modo de desenvolver eu percebi que não havia condições. Mesmo com todo o aparato ágil que estávamos criando a quantidade ridícula de reuniões e passos burocráticos que um desenvolvedor realizava no seu dia-a-dia iria consumir uns bons 30% do tempo de cada um. Minha proposta para o time foi simples: “nós tínhamos 6 desenvolvedores. A partir de agora nós temos 5. Eu vou parar de escrever código e cuidar apenas da burocracia.”
Para alguém que ama escrever software isso foi uma decisão bem complicada –ok, eu saia tarde todos os dias só para ter alguma chance de escrever umas linhas de código- mas foi a melhor coisa que eu fiz. Eu passei a ir a todas as reuniões –onde nada de útil era discutido-, escrever documentação e preencher formulários, resolver bug da versão antiga, acompanhar os testes requeridos para alguma coisa entrar no ar e todas estas atividades de valor zero para o projeto.
Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy. O cliente só via o trabalho semanalmente, basicamente. E foi entregue no prazo e continua no ar até o momento.
E esta foi só a primeira vez que tive que fazer isso. Depois desta eu não acho que houve um projeto sequer onde eu não tenha que ter feito algo semelhante, seja preenchendo formulários para deixar o time livre para escrever código ou gastando 30% do meu tempo apenas para ter certeza que o GERENTE DE PROJETO (em maiúsculas porque era assim que ele se apresentava) estava feliz e recebendo todos os dados que ele achava interessantíssimos.
É a parte mais chata do meu trabalho, mas negligenciar esta parte é uma das grandes causas de problemas em adoções de métodos ágeis. Existe toda uma engenharia de processo que precisa ser feita. Ao usar métodos ágeis não vai aparecer nenhum duende mágico para fazê-la para você. Achar que você pode ter um Scrum Master que não faz esta engenharia só porque “times se auto-gerenciam” é muita ingenuidade. Ou burrice.
Pior ainda é quando o Scrum Master é a própria fonte de impedimentos para o time. É aquele cara que fica dando pitaco no código, vai de meia em meia hora na sua mesa pedindo pra você abrir/fechar um ticket de sei-lá-o-quê, etc.
Quanto às barreiras funcionais, geralmente são derrubadas pela metade. Sempre tem aquelas funções que o desenvolvedor não tem permissão de fazer, mas a equipe que tem permissão não tem a menor idéia do que fazer. E a comunicação passa por burocracias, hierarquias e egos. Um exemplo desse tipo de função é a de implantação (especialmente em produção).
Bom, Phillip, gostei.
De modo geral Agile aqui no Brasil é ainda muito polarizado. É meio temeroso o que se fala muitas vezes no meio dos Scrummers, mas fico contente que não são todas as empresas que estão derrubando paredes erradas. Existem bons ScrumMasters, pode acreditar.
Minha opinião também é focada em empresas de produto. Faz tempo que estou fora do mundo dos bancos, consultorias, granjas e etc…
Ótimo Post!!!
Mostra que o Scrum não deve e não é engessado, fixo, ele é adaptável!!!
Olá Phillip,
Parabéns pelo ótimo conteúdo e obrigado por ter compartilhado esta experiência.
Tenho ouvido falar de alguns casos onde acontecer simplesmente a troca dos títulos e cargos para os nomes bonitinhos do Scrum, mas mantendo a mesma cabeça e a mesma cultura burocrática na empresa.
Hoje vejo que mesmo que algumas decisões possam (e devam) ser tomadas pela equipe, sempre surgem questões que precisam ser resolvidas por um líder, senão o tempo vai passando e nada é decidido.
Abraço
É o mesmo problema que as metodologias “não-ágeis” enfrentaram. As pessoas querem receitas com o passo-a-passo pra executar o trabalho e esperam que após a aplicação de cada um dos passos eles vão ter um resultado correto e completo conforme se propagandeia por aí.
Ninguém quer pensar, considerar as variáveis que cada time, projeto e cliente produzem, eles querem simplesmente fazer o trabalho das 9 as 5, ir pra casa e no fim do mês receber o salário. O destino das metodologias ágeis nesse mercado vai ser um naufrágio de projetos ainda pior do que os que foram destruídos por RUPs e similares no passado, porque agora eles podem simplesmente ignorar conceitos porque “no método ágil é assim”.
O fato de Scrum (e não XP, que chegou primeiro e teve muita visibilidade) ter ganhado tantos “adeptos” no Brasil é exatamente a facilidade de se distorcer o processo pra seja lá o que for que o Gerente, vulgo Scrum Master, acha que deve ser a forma correta de se desenvolver software. Agora é esperar qual vai ser a próxima Metodologia da Salvação que vai surgir e tomar o lugar como capitão dos barcos a naufragar no mar dos projetos que não dão em lugar nenhum.
Como já disse em um post ha algum tempo http://blog.fmeyer.org/entry/o_scrume as pessoas estão perdendo o foco do que na verdade é um software ou produto. Estão tão interessadas no processo ou em virar uma referência sobre qualquer assunto que literalmente esquecem que o software é um produto oriundo da criatividade e da capacidade de organizar essa criatividade em funcionalidades que agregam valor.
Tudo que eu vejo hoje em dia nesses ditos “scrummers” vai contra a principal verdade do manifesto ágil que literalmente diz “Individuals and interactions over processes and tools”: É uma necessidade extrema de engessar esses conceitos simples que foram pensados pra facilitar o desenvolvimento e iteração dentro de um modelo de negocio lucrativo, que é exatamente o que virou o Scrum no Brazil. Não é raro ver por ai anúncios de workshops que vendem o “como se tornar um scrum master certificado em 8 horas”,este que piora quando oferecem a bizarrice dos tutoriais de 5mn de como fazer TDD, BDD, CDD, GDD, /?DD/ misturado pra você aprender a integrar e desmistificar toda a tecnologia existente em um sábado a tarde.
Fico triste ao ver que nossa área está virando um playground para oportunistas que tiram proveito dos sucessíveis BuzzConcepts que aparecem todo ano para montar o seu portifólio de mentiras e começar a fazer dinheiro. Pessoas essas que fazem um trabalho leviano e superficial e ainda saem espalhando seus cases como se tivessem resolvidos todos os problemas da empresa. Recentemente tive uma experiência muito interessante com um desses ditos “consultores de metodologias ágeis”, resumidamente era como ter um daqueles minutos de sabedoria que você escolhe uma frase de efeito para gerênciar seu dia. O time cheio de problemas de comunicação e entrosamento e ele insistindo em como fazer o daily meeting direito. Mostrando exatamente a deturpação do conceito em prol da criação de um processo, as pessoas devem conversar o dia todo e não apenas nos 15 minutos definidos.
Quem defendia RUP a alguns anos hoje veementemente vende ágile, é assim que a vida segue.
Cara, é por isso que eu escrevo direto no meu blog focado quase sempre em questões de valor cultural, pessoas, comunicação, etc. Eu acredito que o SCRUM é uma excelente forma de introduzir (ui!) todos os valores ágeis propostos.
Estamos na era do conhecimento, onde nós não contratamos mais mão-de-obra, e sim cérebros. E além de conhecimento e habilidades, ATITUDE é importante.
Eu, sinceramente, fico muito feliz pela curiosidade que o mercado está tendo pelo Scrum. Até então eu achava que tratar as pessoas como reais parceiras do negócio, no ambiente de trabalho, era sinônimo de “gerentezinho amigo”, como muito ouvi por aí.
As pessoas são as mesmas. Muita gente vai errar. Muita gente mesmo. Mas ao menos elas vão tentar, vão refletir, vão estudar e, quem sabe, algumas vão rever seus conceitos sobre como liderar uma organização.
Fecho contigo em tudo. Acho que na real só somos diferentes no perfil técnico mesmo: eu ODEIO programar hehehe
Grande abraço!
“Este era um projeto onde o cliente mudava de idéia o tempo todo e eu tive que isolar o cliente da equipe e atuar como proxy.”
Analista de sistemas? http://philcalcado.com/2008/01/15/quando-eu-crescer-quero-ser-analista-de-sistemas/
Muito bom. É importante mostrar a realidade por trás do discurso. Quanto aos oportunistas, como o Meyer disse, isso não é exclusividade da nossa área…todas as áreas sofrem com os problemas gerados pelas pessoas…e felizmente, é isso que faz com que a roda gire…com que as coisas evoluam…pois é isso que faz com que as soluções sejam buscadas constantemente
@David
Nao, analista de negocios. Eu era especialista no domínio e não especificava nenhum aspecto técnico.
Fala Phillip, bom post. Senti durante sua palestra e as conversas que você assim como vários outros agilistas, estão cada vez mais decepcionados com as práticas ou rótulos quem vem se popularizando para vender a falsa mudança nas equipes.
Cara por aqui em Natal, existe muito disso… já ouvi muitas histórias de empresas ágeis em que o próprios facilitadores eram os responsáveis por ampliar os impedimentos, muitos deles gerentes de projetos que para garantirem seus empregos vestiram a pele de cordeiro e acabam por reter tanta responsabilidade(incluindo a retirada dos impedimentos) que acabam por atrasar toda a equipe.
Agora este problema, acredito eu, não vai ser facilmente corrigido… diferentemente do relatado em sua palestra do Caelum Day in Rio, por aqui o cliente confia fielmente em alguns “CORDEIROS”, e este não estão realmente interessados em progredir acham que só ganhar o dinheiro já tá ótimo e assim a culpa fica sempre para a metodologia….. a pena e que nos desenvolvedores podemos nos prejudicar muito…. e mudar de empresa a cada mês pode ficar complicado.
Comecei a ler o artigo que me interessou, porém resolvi não continuar a lê-lo pois não sei quem o escreveu e qual a confiabilidade do que diz.
Uma crítica construtiva para esse site e esse artigo: Identifique-se.
[...] Derrubaram as Paredes Erradas – Phillip Calçado (Fragmental); [...]
Locoselli,
Desculpe mas não tenho idéia do que você está falando. Este blog nunca foi e nunca será anônimo, tenho certeza que em menos de cinco minutos você consegue descobrir meu nome, email e até onde trabalho e trabalhei. Muitas destas informações neste mesmo post.
Primeiro, Phillip, instala o IntenseDebate peloamordedeus :)
Segundo, tenho que discordar com veemência do Flavio Steffens, a popularidade do Scrum foi exatamente a pior coisa que poderia ter acontecido pra Agilidade no Brasil, porque Scrum é um método propositalmente ralo no quesito técnico. Em livros como “Agile Project Management with Scrum” o Schwaber fala que “a equipe deveria estar utilizando testes automatizados”, mas em momento nenhum ele explica onde eles cabem dentro do esquema do desenvolvimento.
Ele assume, automaticamente, que a equipe já selecionou corretamente as suas práticas de engenharia e sabe exatamente como inserir elas dentro do contexto, o que normalmente não é verdade, já que as equipes que estão “migrando” pra a agilidade do Scrum hoje são as que estiveram fazendo RUP-cascata nos últimos tempos e provavelmente não tem conhecimento nenhum das boas práticas de engenharia no desenvolvimento de software.
Scrum é aberto demais pra ser a porta de entrada das pessoas pra agilidade, especialmente porque ele “parece” muito fácil de ser aplicado quando na verdade ele é a metodologia que exige mais bagagem da equipe e Scrum Master exatamente por não conterem manuais extensivos sobre o que deve ser feito. Scrum apenas enumera algumas boas práticas de gerenciamento, esquecendo completamente de como a equipe executa o seu trabalho, o que dá margem para equipes inexperientes tomarem o caminho errado ou um Scrum Master ex-Gerente de projetos definir o que lhe der na telha sobre como as coisas devem ser implementadas.
Seria ótimo ver a própria comunidade Scrum explicando isso para os incautos “novos convertidos” antes deles darem com os burros n’água com mais projetos catastróficos, mas é bem improvável que no espaço tão cheio de oportunistas alguém tenha coragem de mostrar a verdade para os clientes.
É uma pena.
Phillip, acho que o Locoselli tem um pouco de razão, pois diferente do seu blog em inglês que possui uma descrição sua na lateral, este blog está sem um “about” da vida.
Quem chega aqui pela primeira vez e não te conhece fica um pouco perdido mesmo.
Comentário ágil, rs.
RUP: “Throw the baby with the bath water”
Individuals and interactions over processes and tools? ;-)
E assim caminha a TI: iterativa e incremental.. hehheheh
Finalmente um post deixando o romantismo e liberalismo de lado falando claramente sobre um tema discutido por tanta gente…..e com tanta bobagem sendo dita. Compartilho dos mesmos argumentos apresentados por você. Parabéns pelo post!
[...] qualquer instante os desenvolvedores tinham acesso ao PO e o cliente, tomando alguns cuidados. Esse é um ponto a ser defendido a todo custo se a entrega de uma versão inicial seguirá esse [...]
[...] Para quem se interessar sobre o assunto, sugiro a leitura do artigo do Phillip Calçado, que parece ter passado pelo mesmo problema: Derrubaram as Paredes Erradas [...]
[...] Para quem se interessar sobre o assunto, sugiro a leitura do artigo do Phillip Calçado, que parece ter passado pelo mesmo problema: Derrubaram as Paredes Erradas [...]