Esqueceram de mim

A principal tarefa de um Scrum Master é curta e grossa: garantir o bom funcionamento do Scrum. Existe uma tarefa implícita nesta frase, que é extremamente desafiadora: educar bons Product Owners. Muitos Product Owners ainda não conhecem seus papéis como deveriam, geralmente têm bastante experiência em projetos de software e raramente são incentivados a criar uma comunidade para que possam desafiar suas certezas em prol de uma nova realidade. Além disso, eles enfrentam a principal mudança que os métodos ágeis trazem consigo: foco nas pessoas como o verdadeiro motor durante o desenvolvimento de um produto, não no projeto. Em um primeiro momento, a cultura ágil privilegia os times de desenvolvimento de produtos, o que torna a adoção da cultura mais fácil para os desenvolvedores. Por conta da dificuldade particular de educar Product Owners, muitos acabam “esquecidos” pelos Scrum Masters e viram verdadeiros pedregulhos no caminho dos times.

Quem é o Product Owner?

O primeiro passo para se educar um Product Owner é saber quem ele é (ou quem ele pode ser). E definir quem é o Product Owner é uma tarefa do Scrum Master. Algumas características ajudam nesse desafio:

Segundo Roman Pichler, em Agile Product Management with Scrum, um Product Owner deve ser:

• Visionário e executor;
• Líder e membro do time;
• Comunicador e negociador;
• Com poder de decisão e comprometido;
• Disponível e qualificado.

Levando em consideração tais características, podemos elencar alguns profissionais que podem se encaixar no papel:

Analista de negócio: Este profissional tem a peculiaridade de conhecer bem as regras de negócio de uma organização sendo ele um profissional de TI. Pelo forte foco no produto que a cultura ágil prega, ele acaba sendo uma boa opção por seu conhecimento das necessidades da organização. O problema é que nem todo analista de negócio sabe ou quer medir o progresso do desenvolvimento do produto e resolver, ele próprio, as barreiras de comunicação que dificultam a integração entre as partes de um produto.

Gerente de produto: Pouco explorado, este profissional é utilizado em pouquíssimas empresas. Na minha opinião, é a melhor representação de um Product Owner. É um analista de negócio, que tem responsabilidade sobre o prazo de seu produto e precisa reportar o progresso do desenvolvimento do mesmo aos seus clientes. O único perigo com este profissional é o de ser uma pessoa hiperativa que não consegue esperar que as soluções emirjam do próprio time. Esta atitude pode minar a auto-organização e a auto-gestão do time.

Gerente de projetos: Algumas empresas já tentaram elencar gerentes de projetos como Product Owners. Funciona bem, desde que o profissional consiga se desvencilhar do hábito de comando e controle que seu papel original propõe. Adotando uma mentalidade de coach, de liderança-servidora e focando no produto e na satisfação do cliente acima de tudo, o gerente de projetos também pode se tornar um bom Product Owner.

Usuário-chave: Usuários têm outros afazeres em suas rotinas que não podemos ignorar. Quando estamos falando de projetos pequenos, onde o próprio dono de um empreendimento trata com 1 ou 2 desenvolvedores, o usuário-chave como Product Owner funciona muito bem. Quando o produto começa a crescer e ficar mais e mais complexo, surgem questões tecnológicas das quais um usuário-chave não tem a mínima ideia do que significam. Sem contar que este tipo de Product Owner tem a tendência à otimização local e ignora as questões de integração com outras áreas da empresa dentro do produto. Nesse momento, um usuário-chave como Product Owner pode ser extremamente prejudicial ao produto.

Um bom Product Owner leva todos a bons sprints

Um time Scrum que não tem um bom Product Owner está fadado a fracassos. Os insulmos oridundos deste papel são tão importantes quanto o produto que está sendo desenvolvido pelo time de desenvolvimento. Em todas as experiências que tive com times ágeis, o Product Owner tinha um peso enorme sobre o progresso do time. Negativo ou positivo. Um bom Product Owner sabe motivar o time em prol da sua visão de produto e consegue, facilmente, definir o plano de ação para ter aquele produto, ao final de um projeto ou período. Um mau Product Owner é capaz de segurar o progresso do time inteiro e, mais do que isso, desmotivá-lo por sua falta de visão, clareza e segurança e colocar seu produto em sérios apuros. Sem um bom Product Owner, não há um bom time. Sem um bom time, não há um bom produto.

Coaching, não só mentoring

Para um time de desenvolvedores, o que importa é desenvolver software e ter seu conhecimento constantemente desafiado para que criem boas soluções para os problemas que encontram durante a construção de um produto. Se estamos utilizando Agile ou Waterfall, pouco importa. Desde que todos sintam-se em casa e estejam felizes em estar ali. Em minhas experiências, é relativamente fácil conduzir a adoção de um framework ágil em um time de desenvolvedores. Principalmente porque a cultura ágil favorece seu bem-estar. É um trabalho muito mais forte de mentoring, de ensino, do que de coaching.
No caso do Product Owner, a realidade é outra. Desenvolvedores, designers, testadores. Todos continuam sendo desenvolvedores, designers e testadores. Mas um Product Owner, provavelmente, era gerente de projetos ou analista de negócio. Além disso, a cultura ágil “prejudica”, à primeira vista, o seu tempo de resposta ao cliente. Ele está passando por 2 grandes mudanças: no formato do seu trabalho e no seu próprio papel dentro da cultura. Não há dúvidas: haverá resistência. E tal resistência não é quebrada somente com o mentoring em Scrum do Scrum Master. Este Product Owner vai precisar de um Scrum Master no papel de seu coach, ajudando-o a desenvolver novas competências para uma nova realidade e auxiliando-o no questionamento de suas certezas para descobrir novas certezas. Não é um trabalho fácil, nem breve, mas é fundamental.

Scrum Master: seja parceiro do seu Product Owner

Costumo dizer que, no Scrum, o gerente de projetos foi dividido em 2: Scrum Master, responsável pelo processo e pelas pessoas, e Product Owner, responsável pelo produto. Antes, um gerente de projetos era responsável por processo, pessoas e produto. Fatalmente, e não pouco frequente, seu foco se mantinha no produto, ignorando o bem-estar das pessoas e a manutenção de um bom processo de desenvolvimento do produto. Scrum Masters e Product Owners, juntos, devem representar gerentes de projetos melhores do que os representados em uma só pessoa, pois as atenções estão bem divididas. Se estes dois papéis representam um profissional, para que ambos tenham sucesso é preciso uma colaboração e parceria muito fortes. Apesar das rusgas e discussões que os prazos e negociações trazem, Scrum Masters e Product Owners trabalhando em parceria são vitais para o bem-estar e felicidade do time de desenvolvimento  e, consequentemente, para o time Scrum e, consequentemente, para o produto e, consequentemente, para a empresa e, consequentemente…

Reunião Diária: muito maior do que se imagina

Uma Reunião Diária é muito mais do que uma simples reunião onde todos os membros do time se juntam para dizer o que estão fazendo. Se fosse tão simples quanto isso, eu diria que a Reunião Diária não tem utilidade alguma, pois simplesmente olhar para o quadro já informa tudo o que cada pessoa está fazendo. Esta reunião é uma reunião de “status report” para o próprio time. Ora, se um time se diz auto-organizável, este deve ser maduro o suficiente ao ponto de que cada um de seus membros assuma compromissos perante o time e o próprio time saiba cobrar estes compromissos. A Reunião Diária é o momento para isso.

Times iniciantes no Scrum ou no XP utilizam a seguinte fórmula para obter o real valor desta reunião e mantê-la “chamativa”:

• 15 minutos de reunião
• O que fiz até esta reunião?
• O que farei até a próxima reunião?
• O que impede meu trabalho?

O valor envolvido nesta reunião é a comunicação. E a maior utilidade dela é a possibilidade de os membros do time assumirem compromissos perante os outros membros e cobrarem compromissos anteriores. É bom lembrar: aquele grupo específico de pessoas está reunido em prol de um objetivo maior. Em um time, o sucesso é compartilhado e o fracasso também. O que o outro está realizando é tão importante quanto o que eu estou realizando. É tão parte do meu trabalho quanto o código que eu mesmo faço. Isso se chama código comunitário: todo o código gerado pelo time é de responsabilidade de cada um de seus membros. Portanto, se você fez besteira ou está enrolando para terminar uma tarefa, seja humilde o suficiente para se retratar perante o time e agir em prol do seu sucesso.

Quando um compromisso é assumido em uma Reunião Diária, isso quer dizer que, até a próxima, este compromisso estará liquidado. Se não estiver, o mínimo que os outros membros do time devem fazer é se interessar pelo que impediu o compromisso de ser honrado. Uma falha do próprio time pode ter ocasionado isso. Uma falha do ScrumMaster pode estar causando isso.

A Reunião Diária mantém-se curta para que não seja evitada. Assim, caso haja algum problema maior para ser resolvido, outra reunião, entre as partes interessadas ou todos, pode ser iniciada após o status, e todos os outros membros seguem o seu fluxo de concentração. O tamanho e a frequência desta reunião permitem que os membros do time mantenham-se focados pela maior parte do tempo no objetivo do sprint. Sua frequência diária é fruto do tamanho curto de um sprint, e permite que não haja desperdícios ou surpresas durante o mesmo, além de manter o time sincronizado.

Ou seja:

• 15 minutos de reunião – mantém a reunião relevante e enxuta.
• O que eu fiz até esta reunião? – O compromisso que eu assumi na última reunião deve estar liquidado nesta reunião. Se não estiver, há um impedimento ou mal-planejamento.
• O que farei até a próxima reunião? – O compromisso é assumido perante todos os outros membros do time. Respeitar este compromisso é respeitar o time.
• O que impede meu trabalho? – Impedimentos devem ser relatados ao ScrumMaster. A resolução de impedimentos deve ser cobrada do ScrumMaster.

Como está o seu Kaizen?

A reunião de retrospectiva é o ritual mais importante dentro do Scrum. Esta pausa permitida pelo processo ao time abre espaço para o aprimoramento do processo de desenvolvimento de software utilizado pelo time. Este é o momento sagrado dentro de cada sprint para que o time avalie que práticas deve manter e que práticas deve mudar. Sem esta reunião, o Scrum perde 2 de seus 3 pilares – transparência, inspeção e adaptação. Permitir-se inspecionar e adaptar às necessidades de um time, ambiente, cultura ou contexto específicos é um dos maiores trunfos do Scrum. Isso lhe confere flexibilidade, diferentemente dos processos tradicionais de desenvolvimento de software. É esta oportunidade de parar e rever o que está sendo feito que confere ao time a possibilidade de se superar, sprint pós sprint. Isso porque o time consegue adaptar o processo à realidade de sua existência, para que consiga manter o foco no produto a ser entregue mais facilmente. Sem esta possibilidade, o time seria desmotivado pela obrigação de participar de um processo onde não há o acordo consensual sobre a necessidade de suas práticas, podendo ser retardado pelo processo, ou, pior, dizimado. Retrospectivas são vitais para processos empíricos como o Scrum, e não é de hoje.

Sistema Toyota de Produção
O Sistema Toyota de Produção (TPS) é um sistema de produção integrado, desenvolvido pela Toyota, que compreende a sua filosofia e práticas de gestão. O TPS organiza fabricação e logística para o fabricante de automóvel, incluindo a interação com fornecedores e clientes. O sistema é um importante precursor do “lean manufacturing”. Taiichi Ohno, Shigeo Shingo e Eiji Toyoda desenvolveram o sistema entre 1948 e 1975. Originalmente chamado de “Just In Time Production”, baseia-se na abordagem criada pelo fundador da Toyota, Sakichi Toyoda, seu filho, Kiichiro Toyoda, e o engenheiro Taiichi Ohno. Os fundadores da Toyota atraíram-se fortemente pelo trabalho de W. Edwards Deming e pelos escritos de Henry Ford. Quando estes homens chegaram aos Estados Unidos para observar a linha de montagem e a produção em massa que tinha feito a Ford rica, eles estavam impressionados. Enquanto faziam compras em um supermercado, observaram a ideia simples de um substituidor automático de bebidas: quando o cliente quer uma bebida, ele pega uma, e outra a substitui. Os princípios subjacentes à TPS são incorporados no Toyota Way. Dentre os princípios do Toyota Way, que se dividem entre Aprimoramento Contínuo e Respeito pelas Pessoas, está o Kaizen, um dos maiores responsáveis pelo seu sucesso.

Kaizen: Aprimoramos nossas operações continuamente, sempre buscando inovação e evolução
Kaizen é a palavra japonesa equivalente à palavra “aprimoramento”. Em sua aplicação no TPS, a filosofia é que toda a linha de produção deve parar seu trabalho caso haja algo anormal no processo. Junto com seu supervisor, estes operários sugerem soluções para a anormalidade, e um Kaizen deve ser iniciado. Sendo assim, um ciclo de Kaizen pode ser definido desta forma:

• Padronizar uma operação
• Medir a operação padronizada
• Comparar métricas com requisitos
• Inovar para atingir os requisitos e aumentar a produtividade
• Padronizar a nova e melhorada operação
• Continuar o ciclo infinitamente

Este ciclo também é conhecido como ciclo PDCA (Plan, Do, Check, Act).

5S: Disciplina japonesa objetivando o Kaizen
5S é o nome de uma metodologia de organização de trabalho que usa uma lista de cinco palavras japonesas que são Seiri, Seiton, Seiso, Seiketsu e Shitsuke. A lista descreve como os itens são armazenados em um ambiente de fábrica e como a nova ordem deve ser mantida. O processo de tomada de decisão geralmente vem de um diálogo sobre padronização que constrói um entendimento claro entre os funcionários de como o trabalho deve ser feito. Ela também permite a apropriação do processo por cada empregado. É interessante refletir como cada um dos S’s pode ser aplicado a um time de desenvolvimento de software para aprimorar sua disciplina em prol do aprimoramento próprio.

Selecionar (Seiri): Eliminar todas as ferramentas, peças e instruções desnecessárias. Avalie todos os materiais, ferramentas, e assim por diante, na área de trabalho. Mantenha apenas os itens essenciais e elimine o que não é necessário, priorizando as coisas conforme são requisitadas e mantendo-as em locais de fácil acesso. Todo o resto é armazenado ou descartado.

Simplificar (Seiton): Deve haver um lugar para tudo e tudo deve estar em seu lugar. O lugar de cada item deve ser claramente rotulado ou demarcado. Os itens devem ser organizados de uma forma que promova o fluxo de trabalho eficiente. Os trabalhadores não devem ter que curvar-se repetidamente para acessar os materiais. Cada ferramenta deve ser mantido próximo ao local onde ele será usado – em outras palavras, simplificar o fluxo.

Limpeza Sistemática (Seiso): Manter o local de trabalho limpo e organizado. No final de cada turno, limpar a área de trabalho e estar certo que tudo será restaurado ao seu lugar. Isto torna mais fácil saber onde estão as coisas e garante que tudo está no lugar certo. Um ponto chave é que a limpeza sistemática deve ser parte do cotidiano de trabalho – e não uma atividade ocasional iniciada quando as coisas ficarem muito bagunçadas.

Padronização (Seiketsu): Práticas de trabalho devem ser consistentes e padronizadas. Todos os postos de trabalho devem ser idênticos. Todos os funcionários devem ser capazes de trabalhar em qualquer estação fazendo o mesmo trabalho com as mesmas ferramentas que estão no mesmo local em cada estação. Todos devem saber exatamente o que suas responsabilidades são para aderir ao 3 primeiros S’s.

Manter a disciplina e a auto-disciplina (Shitsuke): Manter e revisar os padrões. Uma vez que os 4 S’s anteriores foram criados, eles se tornam a nova forma de operar. Manter o foco sobre essa nova maneira e não permitir um declínio gradual de volta aos velhos costumes. Ainda pensando sobre a nova forma, também pensar sobre melhorias. Quando surge um problema como uma melhoria sugerida, uma nova forma de trabalho, uma nova ferramenta ou um novo requisito, revise os 4 primeiros S’s e faça as alterações apropriadas.

Uma Retrospectiva sem Kaizen foi tempo perdido
O pensamento Lean, dentro da cultura Agile, exige, primariamente, um processo enxuto de desenvolvimento de software. Combinar o Lean ao Scrum sugere uma mistura poderosa que, além de buscar o maior valor de negócio para o software, busca o melhor processo para que um time específico desenvolva este software. Um processo que elimine exageros ou tarefas desnecessárias do ponto de vista do desenvolvimento de software. Um processo que permita que o time mantenha o foco nos requisitos de negócio e na qualidade sem que ele seja interrompido por exigências desnecessárias do mesmo. O Kaizen é muito importante para que um time atinja a alta performance. Se suas reuniões de retrospectiva não produzem ciclos de Kaizen, a evolução do processo de desenvolvimento de software do seu time está fadada à estagnação, e seu projeto ao fracasso.

Pulsos

Um dos desafios na utilização do Scrum é prever o quanto um time é capaz de entregar a cada sprint. Muitos tentam, em uma vaga tentativa de criar uma métrica, atribuir a 1 story point uma determinada quantidade de trabalho a ser entregue, ao invés de observar como um time desempenha seus papéis e realiza suas entregas. Por exemplo: 1 story point equivale a um cadastro com 8 campos que acessa 1 tabela na base de dados. Este tipo de abordagem não funciona, porque um time é constituído por pessoas, com diferentes experiências, percepções e problemas (pessoais ou profissionais). Individualmente e coletivamente, um time sempre apresenta características técnicas e emocionais distintas de outros times. Os membros do time A nunca levarão o mesmo tempo que os membros do time B levaram para adaptarem-se entre si. Times nunca apresentarão exatamente os mesmos conflitos ou a mesma produtividade. Enfim, em conjuntos recheados por seres humanos, pode até haver um padrão estatístico relativo à produtividade, mas nunca um padrão industrial, exato e previsível. Sempre haverá uma margem de erro. Daí, surge uma questão para reflexão: é melhor traçar um plano e subordinar sua equipe a este plano, a qualquer custo, em prol de um contrato ou meta corporativa? Ou melhor seria traçar uma meta e acompanhar o desempenho e crescimento do seu time, guiando-o rumo à missão, desfrutando de um ambiente harmonioso, feliz e de alta produtividade,  e realizar os ajustes necessários ao plano de projeto em prol da satisfação do seu cliente, oferecendo a ele um projeto transparente, sem surpresas?

Times Scrum são empíricos, assim como os bebês
Sendo o Scrum um processo empírico, seus times também terão o mesmo comportamento. Times Scrum experimentam e adaptam-se aos diferentes obstáculos encontrados durante um projeto de software. Eles não têm medo nem vergonha de errar, porque sabem que estes erros agregarão mais valor ao negócio do cliente. Em The Artful Making: What Managers Need To Know About How Artists Work, Robert Austin cita como exemplo de time empírico uma companhia de dança. Para atingir seu objetivo, o time de dançarinos testa o que foi ensaiado, grava-se, e observa o resultado por diferentes ângulos, até atingir o nível de excelência desejado. Da mesma forma funciona um time Scrum: inspecionando e adaptando. Observando todos os aspectos de suas ações e práticas e suas consequências. Não há um padrão ou boas práticas a seguir desde o início do projeto. Há um objetivo e um prazo, e o time se organiza sozinho, com a ajuda do ScrumMaster, para atingí-los. Práticas e padrões, comportamentais ou técnicos, emergem durante o desenvolvimento do software, e, é claro, funcionam muito bem – quase que exclusivamente – para aquele grupo de pessoas. Ou seja, assim como bebês aprendem errando – e erram o quanto for necessário até completar o aprendizado – um time Scrum aprende da mesma forma. Porém, com a vantagem de já possuir seu raciocínio lógico formado.

Apesar disso, é preciso, em algum momento do projeto (preferencialmente, o mais cedo possível) saber o potencial de entrega de um time por sprint, ou seja, sua velocidade. Para isso, é essencial, ao início de um projeto, focar na formação/coaching do time e na obtenção de sua velocidade média. Ao mesmo tempo em que o time já está desenvolvendo o software a partir dos requisitos do negócio, ele começa a se conhecer e se auto-organizar, ganhando um padrão de trabalho. Sem esta mentalidade, é impossível conhecer o ritmo de um time. A capacidade de entrega será sempre “o que o time conseguir entregar neste sprint”.

Um time não avança como um carro. Um time pulsa como um coração.
Uma das premissas de um time Scrum é que ele tenha um ritmo sustentável. Que ele trabalhe em um ritmo dentro do qual ele consiga manter a qualidade e completude de seu trabalho, sem prejudicar a sua saúde e bem-estar. Bem como nosso coração. Um time Scrum pulsa tal qual nosso coração pulsa. Para que estejamos saudáveis, nosso coração pulsa em um ritmo sustentável, diferente para cada ser humano, mas dentro de um padrão esperado. Dentro de uma faixa. Esta faixa deve ser percebida logo no início do projeto, quando o foco está em detectar a produtividade do time. No início de um projeto, um time deve ser “auscutado” pelo ScrumMaster, que vai ajudar o time a extrair e manter seu ritmo através da remoção de impedimentos em seu trabalho e de sua proteção contra influências externas. Um time sempre terá uma faixa de produção, seu máximo e seu mínimo de esforço ao longo da duração do projeto. Sua média será usada para manter seu ritmo sustentável. E qualquer mudança na composição do time afeta sua pulsação, seja no âmbito da produtividade, seja no âmbito psicológico. O fluxo de trabalho de um time Scrum pode ser tão previsível quanto o fluxo sanguíneo. Porém, seres humanos são compostos de emoções, que acarretam variações neste fluxo. Se um time é composto por diversos seres humanos, é fato que as emoções também afetarão seu fluxo de trabalho.

Ansiedade: o mal do século
Gerir um projeto de software é, basicamente, gerir aquisição de conhecimento. Conhecimento de negócio, sobre o objetivo a ser atingido, e conhecimento tecnológico, sobre como o objetivo será atingido. Durante todo o projeto, uma emoção está sempre presente: a ansiedade. Ficamos ansiosos pelas expectativas geradas por mudanças em requisitos, ficamos ansiosos pela proximidade do prazo, ficamos ansiosos pelo desempenho do time, ficamos ansiosos pela saída de um membro do time. Enfim, um projeto de software é estressante. Não há coração que agüente. E, se o coração de um projeto de software é o time de desenvolvimento, ele deve ser observado atentamente e cuidado. E isso só é possível conhecendo-se a pulsação por sprint do time. Sua capacidade média de entrega. Daí, deve-se estar atento ao que o time tem a dizer sobre seu trabalho diante das seguintes situações:

Pressão baixa: Se um time atinge uma pulsação abaixo do seu mínimo, fatalmente será acometido pela ansiedade dos gestores, patrocinadores ou usuários. Uma entrega era prevista e foi bem abaixo do esperado. O time tem algo a declarar. Times não deixam de performar simplesmente porque não querem performar. Algo os atrapalha, seja emocionalmente, seja profissionalmente. E, além da ansiedade externa, o time acumula sua própria ansiedade, porque sabem que estão abaixo do esperado, e porque estão sofrendo por algum fato.

Pressão alta: Se um time começa a se comprometer com sprints acima do seu histórico máximo, provavelmente está sofrendo pressão para tal. A ansiedade cresce porque o time sabe que está sob a expectativa de entregar acima do seu registro máximo, e provavelmente ele mesmo não sabe se conseguirá entregar o que se comprometeu a entregar. Seu esforço para realizar esta entrega será maior que o normal, invadindo o bem-estar do time. Provavelmente horas extras serão utilizadas para atingir o objetivo, e um novo registro máximo será instituído para o time caso ele consiga entregar em condições sub-humanas. O time conseguirá atingir tal feito por mais 2 ou 3 sprints, e daí o estresse causado pelo alto grau de ansiedade e cansaço começará a aparecer em falhas bobas e conflitos internos.

Em ambos os casos, a ansiedade por atingir ou superar expectativas leva ao estresse e até à frustração. Por isso é tão importante que o ScrumMaster esteja atento e auxilie o time na manutenção do seu ritmo sustentável. Este ritmo certamente é muito mais produtivo e criativo do que “o máximo que se pode aguentar”.

Horas extras: a descarga de adrenalina de um time
Assim como descargas de adrenalina, as horas extras devem ser usadas com cautela durante um projeto e de forma planejada. Se uma pessoa é submetida a descargas freqüentes de adrenalina, provavelmente seu coração ficará acelerado até parar. Ele cansa. Se um time for submetido a horas extras por um tempo exagerado, provavelmente ele ficará acelerado até parar. Ele cansa. Seus membros ficarão desmotivados, frustrados, produzirão menos do que o normal em determinado momento da jornada intensa e, fatalmente, deixarão o time em prol de sua saúde ou qualidade de vida. Horas extras devem ser usadas como descargas de adrenalina: com um objetivo definido e por um tempo determinado.

Sucesso? Mantenha um ritmo saudável
Sem dúvidas, o coração de um projeto está no time que o sustenta. Existirá a vontade de realizar um projeto, patrocínio para realizar um projeto, líderes para guiar sua execução. Mas tudo isso é inútil sem um time para transformar o ideal em realidade. E não basta apenas ter um time que torne os ideais realidade. Este grupo deve estar suficientemente motivado, unido e confortável para que o ideal seja atingido com qualidade. Desta forma, um time é capaz de manter um ritmo sustentável, saudável. Um ritmo que atinja a superação sem que os próprios membros do time a percebam.
Um dos maiores erros que alguns gestores cometem é assumir que o sustentável não é o suficiente. Ora, se o sustentável não é o suficiente, o insustentável é? Claro que não. O suficiente é manter um ritmo com o qual o time consiga realizar suas entregas consistentemente, corretamente, com qualidade, gerando a previsibilidade tão valorizada pelos gestores organizacionais e bem-estar para seus próprios membros. Tal qual um coração saudável.

Escalando o Monte Everest: o Scrum e a cultura Waterfall

“A disposição para mudar demonstra força, mesmo que a mudança signifique mergulhar a empresa em total confusão por algum tempo.” – Jack Welch

Por muito tempo, o mercado de TI acostumou-se a utilizar o modelo Waterfall de desenvolvimento de software, que, por sua vez, é baseado no processo definido de produção. Ou seja, antes de iniciar-se uma fase de produção, a fase anterior deve estar finalizada, com subsídios suficientes gerados para que a próxima fase se inicie. Modelos de contrato, utilizando-se das mais diversas ferramentas para medição (Pontos por Função, Homem-Hora, Time Material, etc) foram criados levando em consideração o processo Waterfall. Com o advento do RUP, toda uma metodologia surgiu para apoiar e organizar o processo definido de desenvolvimento de software. E, para tentar tornar tudo isso útil e até possível, surgiram as fábricas de software, fortes entusiastas da certificação CMMI de controle de qualidade em processos de desenvolvimento de software. Uma nova forma de construir software, iterativa e incremental, baseada no processo empírico de produção, onde a inspeção e adaptação contínuas são mais importantes do que um plano de execução, chegava com o RUP. Porém, por falta de força e por questões culturais das organizações, o iterativo e incremental seria adaptado para o processo de maior costume no mercado: o Waterfall.

Durante aproximadamente 25 anos, todo o breve parágrafo acima tomou forma e amadureceu. Organizações e, principalmente, as fábricas de software, construíam seus softwares e adaptavam seus processos incansavelmente, em busca do Santo Graal da componentização, que permitiria, enfim, uma montagem rápida de softwares, baseada em bibliotecas de componentes surgidos em projetos anteriores ou componentes criados pelas equipes de arquitetura. A alta tecnologia estava em sua melhor forma e, cada vez mais, surgiam idéias para otimizar o reaproveitamento e aumentar a produtividade dentro das fábricas de software. Porém, algo mais importante do que a tecnologia estava sendo esquecido: o problema do cliente. Mais importante do que criar excelentes frameworks e bibliotecas de serviços e processos que conduziam à alta produtividade era resolver o problema do cliente dentro do prazo que ele precisava e de acordo com as suas possibilidades financeiras. E tal modelo, na maioria das vezes, falhava. Segundo pesquisas do Gartner Group, até hoje, mais da metade dos projetos de software tradicionais faliram ou atrasaram. Algo estava muito errado e o mercado de software perdia rapidamente a confiança de seus clientes. Surgia, então, em 2001, o processo Ágil de desenvolvimento de software e, com ele, diversas frameworks para apoio ao processo, como XP, Lean e Scrum. Em aproximadamente 10 anos, com foco total no cliente e em seus processos de negócio, o Ágil mostrou-se a forma mais confiável para desenvolver software. Mas a caminhada até este ponto foi muito árdua, e ainda não está terminada.

Com sua grande base de utilizadores concentrada na Europa e na América do Norte, o Ágil e seus frameworks ainda não dominam regiões como América do Sul e Ásia. Por questões culturais e governamentais, o caminho nestas regiões ainda é longo e de provação. É necessário, talvez, um grande case de sucesso, público ou privado, para que as grandes organizações invistam sem receios nesta nova forma de construir software. Todas as esperanças estão sendo depositadas no Scrum, o processo de gestão de projetos ágeis de softwares baseado no processo empírico de produção, iterativo e incremental. Uma quebra de paradigma muito forte para o nosso atual mercado de tecnologia. Em um mercado global, não basta competir com base somente nos resultados. É preciso, também e fundamentalmente, adotar uma mentalidade de funcionamento global, ou seja, se as organizações e governos destas regiões que estão sempre a perseguir os resultados dos chamados “líderes de mercado” não adotarem a mesma mentalidade, princípios e cultura que rege tais lideranças, estarão fadados a eternamente perseguir os líderes tentando utilizar-se de uma cultura pré-globalização, talvez não mais tão efetiva, inclusive, no próprio mercado interno.

O Scrum nasceu junto com o processo Ágil, mas só agora vem ganhando notoriedade e força no mercado, devido à sua facilidade de adoção, leveza e fácil adaptação à realidade das empresas. Porém, existem valores no Scrum e no Ágil que não podem ser adaptados, sob pena de perda de toda a performance que os processos oferecem. Tais adaptações, demandadas pela forte raiz da cultura Waterfall nas organizações, têm sido o principal motivo para a lentidão do sucesso destes processos por aqui, com um agravante: no Ágil, não há certo ou errado. Ele se adapta às necessidades das organizações, mas não ao Waterfall. Por serem provenientes de processos de produção distintos (definido e empírico), uma mudança cultural se faz necessária em toda a organização, e não somente no departamento de TI. Os contratos devem mudar, as medições devem mudar e a forma como os requisitos são solicitados devem mudar. Os projetos devem mudar. A gestão deve mudar. Para tal, a transição deve ser realizada de forma típica: pelo Scrum.

No livro The Enterprise And Scrum, Ken Schwaber, um dos criadores do Scrum e um dos fundadores da Agile Alliance e da Scrum Alliance, comenta que algumas pessoas sentem-se profundamente desconfortáveis quando são solicitadas a utilizar o Scrum. Parece arriscado. É desconfortável. Seus instintos preferem a utilização do Waterfall. Segundo Schwaber, os requisitos são tratados de forma bem diferente no Scrum. Aproximadamente 50% de um projeto típico é gasto na criação dos requisitos, arquitetura e desenho. Durante o mesmo projeto, 35% dos requisitos mudam e mais de 65% das funcionalidades descritas pelos requisitos são raramente utilizadas… ou nunca. No Waterfall, todos os requisitos, arquitetura e desenho são desenvolvidos antes do time começar a construir funcionalidades. O Scrum enxerga requisitos e arquitetura como inventório. Se alguns requisitos mudam ou não são utilizados, o tempo gasto para entendê-los ou desenhá-los é perdido.

Para que haja a possibilidade de o Scrum funcionar, é necessário erradicar 3 costumes que foram, ao longo do tempo, fortemente enraizados no dia-a-dia e na cultura das organizações que hoje, ainda utilizam o Waterfall, total ou parcialmente.

Comando e controle
A pessoa mais indicada para descrever como uma tarefa deve ser executada é quem vai executá-la, não seu gestor. O trabalho é complexo e possui nuances inesperadas. Se os executores obedecem instruções de outras pessoas, eles não estão livres para fazer o seu trabalho da melhor maneira possível.

ScrumMasters sabem que times Scrum auto-gerenciáveis são mais produtivos. Os primeiros 10% de seus pensamentos são focados no auto-gerenciamento. Mas os outros 90% sabe que eles estão à frente. Se alguma coisa sair errado, eles vão entrar e dizer o que o time deve fazer. Inspecionar e adaptar, ou ensinar, no caso, é a melhor maneira de garantir que tudo dará certo. É extremamente difícil descartar o Comando e Controle.

Para que um time esteja formado e comece a performar leva tempo. Alguns times necessitam de mais atenção do que outros. Afinal, times são formados por humanos, diferentes entre si e suscetíveis a falhas. Por isso, os ScrumMasters são responsáveis por ensinar o trabalho em equipe auto-gerenciável para os times. Por exemplo, se um time pergunta ao ScrumMaster: “Esta história é muito grande para esse sprint! O que fazemos?”, o mesmo não dá uma resposta. Ao contrário, o ScrumMaster guia o time pelo processo de descobrir como desconstruir a história. O ScrumMaster ensina, o time aprende e o exercício é concluído. Da próxima vez que uma situação similar aparecer, o time saberá resolver. A partir do momento que o ScrumMaster diz ao time o que ou como fazer, ele exerce comando e controle. No comando e controle, o ScrumMaster acredita ser o responsável pela produtividade e resolução dos problemas. No auto-gerenciamento, o gestor acredita ser o responsável por ensinar ao time auto-gerenciamento e resolução de problemas.

Compromisso em desafiar as leis da natureza
Negócios se resumem a compromissos. Quando assumimos um compromisso com alguém, damos a nossa palavra. A outra pessoa organiza o seu negócio de acordo, contando com o que dissemos que faríamos. Essa abordagem é baseada na confiança e é uma enorme fonte de eficiência.

Porém, pressionar alguém a se comprometer com uma tarefa sem se preocupar com o que esta pessoa pensa que é possível é um mau-hábito. Se a pessoa sob pressão é honesta, não prometerá nada. Se está encurralada, provavelmente se comprometerá com algo que não é entregável. Nenhuma das alternativas ajuda se uma ação se faz necessária. Nosso costume nos diz que podemos pedir para nosso time se comprometer com uma tarefa. O costume do nosso time é se comprometer, não importa as circunstâncias.

Esconder a realidade
Os novatos no Scrum não acreditam que a transparência, ou a verdade, é aceitável onde trabalham. Eles temem a demissão caso digam a verdade. A verdade não é o que seus clientes querem ouvir. Acreditam que alguém fará isso caso não façam. As pessoas envolvidas com desenvolvimento de software acreditam que seus clientes só querem escutar notícias se forem boas, ou preferem escutar uma mentira no lugar da verdade. “Mentira” é uma palavra pesada. Mas não consigo encontrar nada que defina dizermos que algo é verdadeiro quando sabemos que não é. Os Product Owners querem acreditar em mágicas, e os desenvolvedores alimentam esta crença mentindo. “Pode nos entregar em dezembro?” “Claro, sem problemas.”

Os desenvolvedores desconhecem as complexidades que causam mudanças em suas estimativas. Não sabem que o cliente está infeliz. Se um gerente de projetos é confrontado por um cliente durante o marco de 60% de andamento de um projeto e este lhe pergunta como está o projeto, de fato ele não sabe. Ele sabe que algumas coisas estão caminhando bem. Também sabe que algumas outras coisas não estão indo tão bem assim. Também sabe que não checou, ainda, algumas coisas que podem se tornar críticas. No entanto, dizer “Não sei” é inaceitável. Então, os gerentes de projeto aprenderam a dizer “Tudo ok”, “Chegando lá”, “De vento em popa”, ou qualquer coisa equivalente que faça o cliente ir embora e deixá-lo em paz para tentar entregar tudo no prazo e dentro do orçamento. Basicamente, mentem. É mais simples do que expor tudo o que vem junto com “Não sei.”

Gerentes de projeto também acreditam que mentir os faz ganhar tempo. Mas, porque o Scrum se pauta na transparência, mentir destrói toda a aplicação do Scrum. Se um Product Owner não sabe exatamente como andam as coisas em um determinado ponto no tempo, ele será incapaz de tomar as melhores decisões possíveis para atingir seus objetivos. Eles precisam da melhor informação possível, seja ela boa ou ruim.