Esta é a segunda parte da série de artigos sobre Lean Software Development resultado de uma entrevista de mais de uma hora de duração realizada no Agiles 2008 com o casal Poppendieck, criadores e evangelistas de Lean Software Development. Nesta parte da entrevista são abordados dois assuntos extremamente polêmicos: Liderança e os papéis definidos no Scrum e estatísticas e coletas de dados durante o processo de desenvolvimento do projeto, ou como diria Tom Poppendieck, do produto.
Se você gostou do conteúdo comente, colabore, divulgue. Até a Ana Claudia e Olivia que não são programadoras nem metodologistas, que trabalharam na tradução e transcrição ficaram animadas com Agile nesta entrevista com a Mary e Tom Poppendieck.
Como parte da comissão organizadora do Agiles 2009 gostaríamos também de convidá-los para o Agiles 2009 que será realizado em Florianópolis entre os dias 06 e 09 de Outubro. Aguarde e acompanhe as cenas dos próximos capítulos.
InfoQ Brasil: Se pudéssemos colocar numa escala, em um extremo, tivéssemos um metodologista e no outro, um arquiteto técnico, que são dois papéis totalmente distintos. Parece que a maioria das pessoas aqui no Agiles 2008 pende para a esquerda, são mais metodologistas do que técnicos, mas quando assisti a sua aula e a sua palestra eu achei que são mais técnicos que os outros, mais preocupados com a arquitetura, com os diagramas. Gostaria que comentasse um pouco sobre esse lado técnico.
Mary Poppendieck: Se você realmente olhar para a maioria dos metodologistas, ou ao menos para as pessoas que ensinam isso, eles provavelmente nunca foram codificadores, nunca desenvolveram um código e, como nunca foram realmente programadores nem trabalharam em software, fica difícil serem qualquer outra coisa que não metodologistas, porque não sabem o bastante para se preocuparem com tecnologia.
Depois de passar muito tempo programando de verdade e gerenciando programadores depois de ter sido eu mesma uma deles, eu acho que há muito além de metodologia nisso. Metodologia é útil, deve ser constantemente aperfeiçoada.
É útil e o conceito de iteração é bom, porém não chega perto de resolver os problemas dos softwares.
Nós precisamos mesmo é de um bom enfoque técnico e vejo muita falta disso quando estamos focados somente em metodologia.
Agora se ninguém aqui fosse nem metodologista nem tecnicista, eu provavelmente iria reforçar mais o lado da tecnologia. O problema é que todos já vão muito para a metodologia, assim eu quero levar as pessoas para o outro lado... nós temos esse grande buraco no Ágil, não chegamos nem perto de falar o suficiente sobre o que constitui uma abordagem boa, sólida e técnica para o desenvolvimento de software. E nenhuma metodologia irá resolver nossos problemas se não encontrarmos um modo técnico de fazer um produto superior.
InfoQ Brasil: É bom ouvir isso. Mas relacionado a isso, eu também notei que você defende o papel de um líder técnico. E em SCRUM eles as vezes dizem, que é melhor que um ScrumMaster não tenha sido um desenvolvedor, porque se você for um desenvolvedor e ScrumMaster, isso pode influenciar a maneira como se relaciona com o time, você pode influenciá-los com sua experiência técnica.
Mary Poppendieck: O pessoal de SCRUM tende a ter medo de líderes. Tobias disse hoje, e eu acho que acertou nisso, que quando se tem uma empresa altamente disfuncional, o ScrumMaster pode ajudar a encontrar e eliminar a disfunção, mas eu não trabalho com o que se tem que fazer com a empresa disfuncional. Acho talvez que é porque eu venho de uma empresa relativamente saudável, eu trabalho com o que os profissionais tem que ser, e não com o que temos que fazer para resolver, para eliminar problemas muito ruins, com gerentes ruins e esse tipo de coisa.
Eu não estou realmente interessada em me preocupar com alguém que precise que seu time seja protegido de uma má gestão, mesmo Tobias disse: “você sabe, se tiver uma empresa saudável na verdade você não precisa de um ScrumMaster”, e é por isso que eu acho que você realmente não precisa de um ScrumMaster, apesar de não ser uma má idéia ter alguém para ajudar um grupo a mudar para um novo processo, mas eu já estou presumindo que as empresas serão bem sucedidas, terão uma boa gestão e o que eu entendo por boa gestão é o que tínhamos na nossa empresa, na 3M, e isso tem a ver com gerentes, sendo que a função do gerente é ser um professor, ser um técnico, ajudar as pessoas a alcançarem seu potencial pleno e garantir que elas terão o tipo certo de encargo, o tipo certo de ajuda e direcionamento para alcançarem seu potencial máximo.
O acordo nesse tipo de empresa é: nós iremos te ajudar a alcançar o seu potencial máximo e você irá ajudar a empresa dando seu melhor. E é esse tipo de empresa, onde há uma atitude de gerenciamento que favorece as pessoas, que eu tomo como ponto de partida. Nesse tipo de empresa não há problemas com liderança, você não precisa “arranca-los” dali porque vão começar a dizer aos outros o que tem que fazer.
Isso não é gestão é uma distorção do que é gestão. Eu acho que esse é um problema fundamental e volto a mencionar os metodologistas e tecnicistas. Quando eu era uma técnica, todas as pessoas para as quais eu tinha que me reportar, gerentes de primeira e de segunda linha, eram profissionais de alto nível, totalmente competentes, engenheiros, cientistas, pessoas assim, e todos que guiavam o trabalho do pessoal técnico eram eles próprios muito técnicos e podiam chegar até dentro do problema e dar um direcionamento real e verdadeiro.
E quando você tem esse tipo de liderança em gestão isso é bom.
Não há nada errado com esse tipo de liderança, é uma coisa muito importante, pois há o pessoal júnior que acabou de sair da faculdade, eles precisam de muita ajuda, direcionamento e orientação. Se esta é sua visão de gerenciamento, então queremos mais dessas pessoas ajudando e liderando.
Se você for para organizações, eu acho que havia alguém na nossa aula que era da marinha e, ela entendia o conceito de gestão como liderança porque que é assim que eles fazem em organizações militares e a primeira coisa que é feita é agrupar e ensinar às pessoas a tomar iniciativa e liderar grupos.
Não há nada errado com os líderes, mas algumas vezes me preocupa que o pessoal do Ágil sinta um nervosismo em relação a liderança, porque eles tem medo que isso se torne uma pessoa dizendo a outra: faça isso e depois aquilo, então com certeza não vamos querer um líder técnico porque ele pode começar a dizer as pessoas como as coisas tem que ser feitas.
O problema aí é que não existe um bom treinamento de liderança naquela organização e se existem esses tipos de organizações (e não tenho dúvida de que existem), eles tem problemas e falta de bom treinamento, não só para o pessoal, mas também para os gerentes, mas eu não vou gastar meu tempo e energia me preocupando com esse tipo de organização, eu creio que o mercado irá cuidar delas. Entende?
O que eu realmente procuro são organizações saudáveis e o que elas deveriam estar pensando em fazer. E quando entro em uma empresa não gosto de imaginar que é uma bagunça. Quando entro em uma empresa gosto de pensar que é uma organização saudável com uma boa liderança e eu encontro muito isso.
Eu não tenho tanta certeza de que existem todas essas organizações disfuncionais, ou talvez eu tenha as pessoas certas conversando comigo, não sei. Mas eu não faço essa presunção, eu acho errado dizer que um ScrumMaster nunca deveria codificar e que ele não deve ser nenhum tipo de líder; que ele não deve dar nenhuma orientação, ajuda ou assistência. Apenas jogar um grupo de pessoas numa sala e dizer: “organizem-se”...
Ok, você sabe que fizemos isso no início dos anos 90, no movimento pela qualidade, havia todos aqueles times de auto-gestão e aprendemos muito. Aprendemos que eles às vezes funcionam, por um curto período de tempo, mas eles não são um ambiente sustentável, porque não há um mecanismo para lidar com “e se eles não funcionarem?”, você entende, o que fazer com isso?
Não há um mecanismo para fornecer orientação e liderança que são muito importantes para o pessoal Junior.
Então eu acho que definitivamente não gosto dos papéis que o SCRUM tem. Não gosto do papel do ScrumMaster porque ele interfere com outros papéis importantes: o líder técnico e o líder funcional.
Não gosto do papel do dono do produto (Product Owner) porque ele fica de fora, ele é um intermediário entre o time de desenvolvimento e o cliente, então não gosto de nenhum desses papéis. É isso.
Na verdade também não gosto de retrospectivas porque não tem força o suficiente para mim.
Eu gosto de conceitos gerais, mas gosto de ver o verdadeiro processo clássico de aperfeiçoamento de processos.
Em todas essas áreas o que eu acho que precisamos fazer é imaginar isso, olhar para o que uma boa empresa pode fazer e não para o que precisamos fazer para empresas ruins. De qualquer modo é o que eu prefiro fazer
Tom Poppendieck: Existem três palavrões: um deles é negócios, como Mary disse na mesa-redonda, negócios significam que o grupo de desenvolvimento não é parte do negócio, está separado, e isso na verdade quer dizer que nós não entendemos nada de negócios. Nós deveríamos pensar sobre o nosso negócio, não sobre “negócios”, que é o primeiro palavrão.
O segundo é projeto. Um projeto, por definição, tem um início e um fim e deve trazer um resultado. Ele é estabelecido inicialmente, e quando alguém te dá um monte de dinheiro vai querer saber o que vai obter por esse dinheiro, então você é forçado a fazer uma projeção em um momento quando está mais ignorante sobre o que é necessário fazer com o problema que está tentando resolver. Pensar no projeto leva a uma grande fração da disfunção que sofremos no desenvolvimento de softwares; deveríamos pensar em termos de produto não em termos de projeto. Produtos não terminam se forem bem sucedidos, eles continuam, permanecem, são aperfeiçoados, o time do projeto fica com o produto. A medida de sucesso de um produto é sua quota no mercado e seu rendimento, isso importa.
A medida de sucesso de um projeto é a projeção de custo, que é totalmente irrelevante. Você pode estar totalmente dentro de sua projeção de custo e não vender nada – será um desastre. Você pode ultrapassar muito o orçamento, vender uma quantidade tremenda, e o gasto extra será irrelevante. Assim, esse comportamento métrico não tem nada a ver com os verdadeiros objetivos de organização da nossa organização.
O terceiro palavrão é requisito. Requisitos não existem. Bem, existem as leis matemáticas e a legislação, talvez, mas no sentido que a maioria de nós usa a palavra requisito, eles não existem. Requisitos são decisões determinadas por alguém que não deixa que as pessoas que irão implementá-los tenham nenhuma participação, e dessa forma eles são disfuncionais, porque as pessoas que os implementam tem contribuições importantes e valiosas.
Se as pessoas que estão implementando, os desenvolvedores, tiverem um conhecimento de primeira mão do problema que estão tentando resolver eles farão escolhas diferentes, irão influenciar, farão que o que for colocado no produto seja diferente do que o que uma pessoa sem competência técnica faria.
E isso é levado para todo o time, todo o time deve estar envolvido na descoberta do produto, não apenas alguém que define os requisitos, não apenas o dono do produto, mas todos devem contribuir com sua perspectiva.
Agora isso não quer dizer que não hajam pessoas mais focadas em uma ou outra área, mas todos devem estar envolvidos, e é nesse envolvimento que você encontra paixão, esse envolvimento é a compreensão da diferença que você faz nas pessoas para quem trabalha, é de onde vem a paixão, é de onde vem o orgulho que faz o trabalho valer a pena.
InfoQ Brasil: Algumas coisas que eu queria perguntar já foram respondidas. Então o que eu gostaria é de falar sobre métrica e sobre o que Deming chama de “doenças”, e há várias doenças sobre as quais Deming fala que se relacionam com o uso errado de métrica. Uma delas é gerenciamento somente através de números visíveis, e a outra é perder de vista o fato de que o que estamos medindo, o que a métrica pode fazer, o que podemos tomar, são só modelos substitutos para coisas reais que não temos como medir. E outra das doenças é quando focamos em resultados em curto prazo ao invés de fazermos uma projeção em longo prazo. Eu gostaria que comentasse sobre isso, como isso funciona nas organizações de software, nas funcionais e disfuncionais.
Mary Poppendieck: Eu concordo totalmente com Deming, que sub-medições tendem a criar um foco sub-otimizado e não uma imagem do todo. Nós tínhamos isso em nossas fábricas, quando o pessoal da contabilidade fazia cálculos de custo, de uso de máquinas, tivemos que tirar isso da cabeça deles quando fomos para o “just in time”, que aquilo não fazia nenhuma diferença, era um medição ruim, nos levava a fazer inventários, e o que nós realmente queríamos era que o gerente de nossa fábrica andasse ao redor falando num megafone: “inventários são do mal”.
Ele estava sempre tentando diminuir os inventários, o que era uma vantagem, era uma boa coisa que acontecia por lá.
Portanto medições podem criar um comportamento muito negativo, e de fato se você vir qualquer tipo de disfunção em qualquer lugar, em qualquer organização, eu aposto que há uma medição de algo por trás disso. Há uma medição sub-otimizada que está levando as pessoas a se comportarem dessa forma. As pessoas simplesmente não se comportam mal por acaso, elas se comportam mal porque é isso o esperado que elas façam, porque há uma medição que elas estão tentando cumprir e que faz com que tenham esse comportamento.
Quando as coisas não estão sendo feitas de forma adequada, há uma medição mal feita, sub-otimizada, portanto eu concordo totalmente com isso: medições são um verdadeiro problema, e o que você realmente precisa fazer é tentar ter o mínimo de medições possíveis, do nível mais alto possível. O que é exatamente o oposto do CMMI, por exemplo.
Provavelmente uma das minhas preocupações com ele é que existem medições demais, ao invés de um, dois ou três indicadores chaves. Existe um livro chamado “Good to Great”, de Jim Collins, onde ele diz que toda empresa tem uma espécie de medida oculta que elas tem que descobrir (as boas empresas), que as ajudará a encontrar a coisa certa a fazer.
Assim por exemplo na Walgreens, a grande cadeia de drogarias, há uma parcela de lucro por empregado por visita de cliente, não um lucro por loja, mas por visita de cliente; para jornais, porque jornais eram importantes, eu acho que havia um lucro por região geográfica.
Basicamente cada empresa tem que descobrir qual é sua medida chave, que irá tornar sua economia boa. E as decisões, quando você encontra essas medidas de alto nível, se você conduzir isso na direção certa, o resto irá também. Aquela uma, ou duas ou três medidas de alto nível não serão disfuncionais, são medidas niveladoras de sistema, mas você tem que encontra-las, e tem que saber qual é a medida correta para sua empresa, e tem que conduzir até mesmo pequenas decisões baseadas nela, e é provavelmente difícil conduzir uma economia excelente, adequar as medidas econômicas da empresa em uma direção correta, e Collins diz que empresas realmente boas descobriram uma, duas ou três coisas que eles realmente deveriam seguir, e não se preocupam mais com outras medidas sub-otimizadoras.
A cadeia de lojas Zara, por exemplo, a empresa de roupas, como mencionei em minha aula, eles só seguem medidas que façam aumentar a porcentagem de itens vendidos, ou diminuir a porcentagem de itens não-vendidos, e aumentar a porcentagem de itens vendidos pelo preço integral. E tudo que é feito lá tem que conduzir esses números para a direção certa ou não é feito, e muito dinheiro pode ser gasto para que esses números sigam a direção correta. Então eu acho que medidas têm que ser cuidadosamente pensadas, medições de processos, em minha opinião.
Lean quase sempre mede o tempo do ciclo como processo chave de medição, e a razão disso é que quase cada coisa que dá errado tem um ciclo de tempo mais lento, um sistema de fluxo mais lento. Então se lean tem a ver com fluxo, se medir do início ao final, do final ao final e não o intermediário, mas do fim ao fim de um ciclo, isso tende a mostrar, tende a ser o processo de medição de alto nível correto, de quanto o seu processo é bom. E se usar outras sub-medições ao invés disso, provavelmente terá sub-otimização.
Eu não vou dizer que em absolutamente todos os casos o ciclo de tempo seja a medição correta, mas acontece na maioria das situações - o fluxo através do sistema e o tempo de ciclo através do sistema são parâmetros muito bons de um bom processo de medição para qualquer tipo de operação lean. E essas são coisas que deveríamos estar procurando.
Ah, e outra coisa que Deming disse – é interessante que se conduza; os números têm que ser observados porque existem as finanças, existem os concorrentes, é preciso se manter economicamente saudável ou não poderá ser mantida a injeção correta; mas quando falamos de números em relação a pessoas, isso não é uma coisa que deveríamos contar em absoluto. Para pessoas temos orgulho, trabalho, qualificações, especialidades, esse tipo de coisa.
Mary Poppendieck: Posso falar mais uma coisa sobre medições? Eu esqueci de uma coisa. O que eu acabei de falar é sobre medições de desempenho. Dados, entretanto, são bons. Você pode coletar todos os dados que quiser, e deve, mas não os use como medição de desempenho, use-os como medição para aperfeiçoamento. Se olhar para Toyota, eles coletam muitos e muitos dados e usam para checar como está o desempenho do processo. Não há nada errado com muitos e muitos dados se forem usados para medir o resultado de um experimento, isso é bom. Mas há essa diferença clara entre dados e medida de desempenho. E tenho certeza que o que Deming se referia como pecados mortais eram medições de desempenho. Dados são bons, porque te dão informações e conhecimento para ajudá-lo a tomar boas decisões, não há nada de errado com isso desde que não sejam medições de desempenho.
Tom Poppendieck: Deming era um estatístico.
Mary Poppendieck: Ele tem tudo a ver com estatística, portanto ele não tem nenhum problema com coletar dados. É a medição de desempenho que é o problema.
Sobre os autores
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.
Manoel Pimentel É Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach em Agile, Lean e TOC para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e Editor Chefe da InfoQ Brasil, Já escreveu sobre agile para importantes portais e revistas do Brasil e exterior e Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.
Tradutoras:
Ana Claudia R. Silva, Canadense, ministra aulas, faz transcrições e traduções e é responsável pelo programa de Imersão em Ubatuba (http://immerseyourselfubatuba.blogspot.com/) e Olivia Borges, tradutora, trabalha na área de assessoria em idiomas a mais de vinte anos prestando serviços para diversas empresas.