Algumas dores do mundo executivo

Em projetos de software temos o costume de ouvir queixas quanto a mudança de requisitos. É frustrante para times de projetos de software enxergar uma grande quantidade de requisitos ser alterada quando mal o projeto foi iniciado. No entanto esta não é uma dor apenas dos times desta área, a realidade do mercado requer frequentemente uma mudança no plano estratégico da empresa logo após a sua escrita, e ver a dor que um executivo sente com isso é bem similar à cena que vemos no mundo de software.
Os problemas com silos em projetos de software nos levou a refletir sobre a utilização de times multi-disciplinares, e o mesmo vem acontecendo no mundo corporativo. Como fazer para que um gerente de recursos humanos esteja focado não apenas na sua meta local, mas sim em como aquele time, composto por executivos de diversas áreas, pode colaborar com a meta da empresa. Enquanto em software nos perguntamos em como fazer para um arquiteto, por exemplo, estar preocupado com a meta do time e não com “minha parte está pronta!”, no mundo executivo há a necessidade de fazer com que o gerente de vendas não esteja preocupado unicamente com “as vendas estão boas!”. As soluções não entregam tudo que podem, em sua maioria pela distância que há entre quem planeja o plano estratégico e quem o executa.

Experimentando o Scrum Executivo

Após as experiências isoladas que citei anteriormente, eu resolvi sentar e pensar em como realmente aplicar algo bem próximo do Scrum proposto por Ken Schwaber e Jeff Sutherland em um time executivo.
O planejamento estratégico da empresa, somado às informações que foram adquiridas através de um Business Plan e outros, serviram de referência para a criação da visão do produto. Esta Executive Product Vision foi o que guiou o Executive Team dentro deste grande programa por estar completamente alinhado às metas anuais da empresa.
Tendo a visão correta para guiar nosso time executivo, partimos então para a criação de um Executive Backlog. Este artefato, assim como um Product Backlog do Scrum, possuía itens priorizados de acordo com o valor para o negócio. Estes itens do Backlog são apontados pelo Executive Product (ou Program) Owner, papel ocupado pelo Diretor Executivo da unidade. Nosso Executive Backlog foi composto por:

Executive Stories: normalmente resultavam em ações executivas
Executive Themes: normalmente resultavam em projetos, portifólios ou programas
Executive Candidates: candidatos a ações, projetos, portifólios ou programas

Nossas Sprints, que tinham o tamanho de 30 dias, eram iniciadas com uma Sprint Planning Meeting. O Executive Team, que era formado por gerentes e diretores da unidade (Sales, Production line, Finance, Support, R&D and Quality) se reunia para planejar o que ia ser trabalhado durante a próxima Sprint. O Executive Product Owner apresentava a meta e explanava sobre os itens mais prioritários, o time tirava as dúvidas e discutia quais dos papéis deviam ser envolvidos em cada um dos itens, em uma atividade chamada Who would help?. A necessidade de haver um facilitador para este trabalho se tornou latente logo nas primeiras reuniões, e com este propósito o time passou a ter um Executive ScrumMaster, executivo da empresa com conhecimento no processo e em técnicas de facilitação e liderança, que além desta atribuição era ainda o responsável pela remoção dos impedimentos do time. Durante a Sprint Planning Meeting o time já procurava identificar quais as tarefas que seriam necessárias para a execução de cada um dos itens, antecipando assim possíveis problemas. Então, por exemplo, de um item chamado “Restruturação de Plano de Cargos e Salários” seriam geradas tarefas como “Identificar premissas para o projeto”, “Levantar histórico dos planos utilizados até hoje”, “Identificar budget do projeto”, “Identificar time para este projeto”, “Colher dados financeiros do plano atual”, etc.
Dentro de uma Sprint o time realizava as atividades necessárias para que o conceito de pronto de cada um dos itens executivos fosse atingido, o que incluía – mas não se limitava a – levar para dentro dos departamentos da empresa a execução, acompanhamento, redirecionamento ou finalização dos projetos. Esses projetos eram rodados dentro dos departamentos utilizando Scrum e, em grande parte deles, tinha o executivo membro do time do Scrum Executive como (Chief) Product Owner ou Program Owner.
Diariamente o time realizava uma Daily Meeting para fornecer visibilidade das suas ações aos outros membros do time. Devido a dificuldade de se realizar estas reuniões de forma presencial todos os dias, era bastante comum a participação de alguns membros do time através de celular, Skype e outros.
Ao fim de uma Sprint os executivos se reuniam para apresentar os resultados ao Executive Product Owner no formato de um Sprint Review comum. Através dos resultados apresentados nesta reunião avaliávamos se a Sprint Executive Goal havia sido atingida ou não. Por fim, o time participava de uma Retrospective que era facilitada pelo Executive ScrumMaster para avaliar os pontos positivos e negativos daquela Sprint, bem como para discutir como melhorar na próxima reunião.

Conclusão

Apesar de ser apenas um primeiro passo na busca de técnicas mais adequadas para os projetos e programas executivos, a utilização de Scrum neste cenário se mostrou bastante eficiente. Como resultado a empresa enxergou claramente um novo comportamento dos seus executivos – agora envolvidos em um real trabalho de time, uma aproximação entre estratégia e execução e uma maior visibilidade do quão as ações executivas estavam alinhadas aos objetivos de negócio da empresa. Scrum se mostra então como uma boa alternativa não apenas para projetos de software, mas sim para projetos em qualquer ambiente onde se necessite elevação do sentimento de urgência, criação de um espírito de time, alinhamento de expectativas e preparo para as mudanças, e no mundo de hoje eu vejo pouquíssimos ambientes em que estas necessidades não sejam latentes.

Essa é uma situação que todos nós sabemos que acontece, porém, sempre fazemos vista grossa, e nisso eu incluo todos os envolvidos no projeto: diretoria, gerência, analistas, desenvolvedores, testers, DBA`s e demais pessoas que participam do projeto. Os desenvolvedores acham que “iludem” o gerente dizendo que os percentuais de desenvolvimento estão dentro do prazo, que não estão tendo problemas e que tudo está andando como esperado. Os gerentes “iludem” seus diretores dizendo que as coisas estão caminhando bem, que seu Gantt Chart está perfeito, que o plano está sendo seguido como esperado, mas que não vai dar moleza para o time, pois se eles não estiverem com um chicote nas costas as coisas não andam…afinal, ele precisa mostrar que tem autoridade sobre o time.

Em geral, isso acontece muito em um cenário tradicional de gerenciamento de projeto, pois a cultura atual leva este profissional (ou recurso, como preferir) a ter essa postura. O que é muito comum em ambientes de projetos é a aparição da famosa síndrome do estudante (quando é que você estuda para a prova mesmo?): quando o desenvolvedor recebe suas tarefas e olha para o tempo que tem para codificá-las, qual é o primeiro pensamento que vêm a sua mente (pelo menos eu também pensava assim) ? “Ah, tem tempo ainda, posso continuar a resolver essa pendência, a ler o livro, a navegar na internet, a ler e responder e-mails diversos, … “, e com isso se passam minutos, horas e muitas vezes dias.

Na minha opinião, os principais pontos que acarretam essas situações são :

- Prazos longos nos dão uma sensação de conforto
- O fato do programador não ter dado a palavra dele do que é ou não possível de ser feito
- Falta de comunicação e excesso de papéis dizendo, ou melhor, tentando dizer o que o time precisa fazer
- Cultura da empresa, acostumada a atrasos e fins de projetos “cheios de emoção”;
- Desenvolvedores ignoram a comunicação e se escondem em seu mundo (com seus fones de ouvido cada vez maiores)
- A falta de uma definição de pronto, o que reflete diretamente na qualidade (Vou fazer o que está escrito aqui e se compilar: “pronto!”)

O comprometimento do time é um dos principais fatores que levam ao sucesso do projeto, afinal um time comprometido com o trabalho e focado em uma meta vai fazer o possível para atingí-la, simples assim! Em times Scrum esse comprometimento é alcançado naturalmente pela forma de trabalho que o Scrum propõe. O fator “síndrome de estudante” fica difícil de ser aplicado já que trabalhamos com iterações curtas e isso teoricamente leva o time a trabalhar firme desde o primeiro dia de trabalho, além disso as reuniões diárias são fortes agentes de combate a este vício.
Falando em comprometimento e estimativa, em times Scrum é o próprio time quem planeja as suas Sprints dizendo quais são os itens que irão entrar naquele período de 2 a 4 semanas, ou seja, a palavra do time tem valor e isso faz com que eles sintam essa confiança que neles é depositada. Quando o time planeja e estima os requisitos que serão desenvolvidos naquela Sprint, eles estão focando em uma meta definida pelo Product Owner, ou seja, para a Sprint ser bem sucedida, a “meta” tem que ser alcançada. Indo mais a fundo, para desenvolver um item do Product Backlog, o time quebra ele em pequenas tarefas que serão desenvolvidas por todos os membros do time, isso mesmo, todos do time irão trabalhar em um mesmo item: o item de maior prioridade para Product Owner, o que tem mais retorno sobre o investimento do projeto. Sei que a primeira impressão é, “isso é impossível” mas acreditem, não é! Essa definição de tarefas que precisam ser executadas para que um item seja considerado pronto são discutidas e criadas pelo time, seguindo a ordem de prioridade definida pelo cliente, e isso também contamina o time para que todos se comprometam e colaborem entre si para que as tarefas de um requisito sejam finalizadas, garantindo que aquele item fique realmente “pronto”. Uma pessoa do time não irá pegar uma tarefa de um outro item se houverem tarefas de um requisito de maior prioridade para serem desenvolvidas, ou seja, ele tem o comprometimento com a “meta” que foi acordada entre eles e o Product Owner.
Esse espírito de união que é gerado dentro do time é um fator que estimula o comprometimento, pois quando vemos que todos os membros do time estão empenhados e trabalhando firme, isto acaba contaminando a todos, e se alguém não estiver comprometido, acredite, ele irá se sentir mal, pois este é um processo natural que ocorre em times ágeis. Esse comprometimento ajuda muito quando temos um dos membros do time que está passando por dificuldades com alguma tarefa que faz parte de um item que compõe a meta, é fato que a ajuda por outros membros do time irá aparecer espontaneamente, pois times ágeis são auto-gerenciáveis.

Outro fator que estimula o comprometimento é que em uma gestão ágil não vemos um Gerente de Projeto “no pé” do desenvolvedor perguntando qual é o percentual que falta para executar a tarefa, porque acreditamos que ele é capaz de fazer o seu trabalho, ou seja, nós confiamos no time e sabemos que eles irão fazer o possível para atingir a meta. Times ágeis possuem um contato muito próximo ao cliente, e isso elimina o “telefone sem fio” quando o gerente escuta a necessidade do cliente, passa para o analista que gera a documentação para o desenvolvedor e este tem que fazer milagres pra entender aquela “maravilhosa” especificação. Isto elimina também a mania que temos de usar os documentos para substituir uma comunicação, a regra de negócio é passada diretamente do cliente para o time em reuniões periódicas de planejamento o que dá mais segurança e confiança para o time desenvolver aqueles requisitos, estimulando mais uma vez o comprometimento do time. Lembrando, documentos são importantes, mas não substituem a comunicação.
Bom, não quero dizer que isso é uma verdade absoluta, apenas estou compartilhando com vocês a minha experiência sobre o que vejo no comprometimento de times que trabalham com uma gestão ágil e naqueles que trabalham com uma gestão mais tradicional. Existem vários outros fatores sobre o comprometimento de times que poderiam ser citados aqui, mas creio que com essas informações já consegui passar o meu recado. Formar um time comprometido e auto-gerenciado é uma das responsabilidades do ScrumMaster, afinal isto não acontecerá como num passe de mágica, mas sim com muito trabalho, dedicação é tendo educação como palavra-chave.

Comentários são bem vindos para nosso crescimento e melhoria: inspect and adapt.

No Brazil Scrum Gathering eu apresentei pela primeira vez algumas das minhas experiências na utilização de Scrum em times executivos. No Agile 2009 em Chicago/US, que acontecerá no mês de agosto, estarei novamente falando sobre este tema, então resolvi postar aqui uma série de 3 posts sobre o tema, a iniciar por este que explica as motivações que me levaram a utilizar Scrum no alto gerenciamento das empresas.

–

O que me motivou a utilizar Scrum com executivos?

[img:HappyExecutive_1_2.jpg,full,alinhar_esq_caixa]Utilizar as práticas de Scrum como uma forma de apoio a times executivos não foi em momento algum algo planejado. O que aconteceu na verdade foi que, ao realizar trabalhos de implantação de Scrum em projetos dentro das corporações, eu me deparava com uma forte resistência na camada do alto gerenciamento das empresas, e isto me levou a tentar entender suas dores. Percebi então que algumas práticas ágeis poderiam colaborar com estes times executivos, pois me surpreendia ao ver que muitos dos problemas que encontrávamos no mundo de projetos de software se repetiam no mundo executivo.
Sem ainda pensar em “utilizar Scrum”, mas apenas em fornecer práticas soltas que pudessem ajudar estes profissionais em problemas pontuais, comecei a sugerir o uso de algumas práticas ágeis em times executivos, e estas experiências sem dúvida alguma me motivaram a usar o que hoje chamo de Scrum Executivo. Abaixo algumas destas experiências:

Planning Poker no board dos diretores
O CIO da empresa me chamou em sua sala para me questionar sobre algo que ele considerava curioso: ele acabara de passar pelo andar de projetos e lá viu várias pessoas jogando baralho durante o horário de expediente! Ao questionar alguns desenvolvedores sobre o assunto estes tinham o mesmo discurso e informavam que era uma técnica para estimativas que eu os havia ensinado.
Após explicar todo o processo do Planning Poker para o diretor e falar sobre como isso incentiva a comunicação do time e evita haver influência de opiniões, fui surpreendido com um “Ha…é disso que eu preciso para as nossas reuniões de diretoria!”. Durante quase o dia inteiro trabalhamos em cima de uma “versão” do Planning Poker para ser utilizada por eles quando da necessidade de se priorizar ações corporativas e definir a complexidade de execução das mesma.

Cafézinho no andar da TI
“Adoro este quadro!” foi o que o CIO me falou após uma reunião. “Com eles eu consigo ter informações diárias de como o projeto está andando sem ter que me preocupar em pedir status para as pessoas cada vez que preciso dessas informações”. Ele estava se referindo a um novo hábito que ele executava diariamente: ir até o andar de projetos para tomar um cafézinho e, enquanto fazia isso, conseguia visualizar nos quadros o que cada projeto havia andado no dia interior.

Kanban na sala do CIO
Com a boa visibilidade que os radiadores dos times lhe davam, não demorou muito para elaborarmos um Kanban com os projetos e ações que estavam sob a responsabilidade do CIO. Este quadro ficava na sua própria sala e era atualizado diariamente pelos próprios gerentes de projeto (ou ScrumMasters) de acordo com o andamento de cada um dos projetos. Este modelo foi apresentado em uma reunião de diretoria e replicado em outras diretorias.

Metas de curto-prazo, e planejamento alinhados à meta
Ao participar de algumas Review Meetings, o CIO enxergou o quão interessante era trabalhar com metas próximas e prioritárias dentro de um time-box curto. Não demorou para eu ser procurado e convidado a elaborar uma forma com o qual ele, o CIO, pudesse trabalhar com seu time de gerentes em pequenas “Sprints” com metas de negócio próximas e com um sendo de urgência elevado.

Se por um lado iniciei este trabalho com o simples propósito de ganhar a confiança do alto gerenciamento da empresa para poder utilizar Scrum mais fortemente em seus projetos de software, por outro eu comecei a enxergar o quanto os valores e práticas ágeis podiam ajudá-los.
Durante muito tempo me perguntei se o que eu estava iniciando era mesmo algo de valor, ou se – pela minha paixão pelo jeito de Agile de trabalhar – eu estava me envolvendo em algo fictício e sofreria as consequências num futuro próximo. Uma matéria publicada na HSM Management do Brasil em Setembro de 2008 me levou a crer que eu realmente não estava errado, e que eu não era o único a pensar que métodos ágeis poderiam sim ajudar times executivos. Em um artigo entitulado “Learning with Programmers”, Keith McFarland, fundador e consultor da McFarland Strategy Partners fala em como os chamados métodos ágeis podem ser úteis para ajudar na elaboração do que ele chama de “Versão 2.0” do modelo de planejamento estratégico corporativo.

Quando falamos sobre qualidade em software, surgem diversas dúvidas quanto ao que significa ter qualidade em um software: ter um código bem escrito? Código que não apresente falhas? Boa performance no que se propõe a fazer?

De acordo com a NBR 13596 (ISO/IEC 9126), existem algumas características que um software deve apresentar para ser considerado como um software de qualidade. Estas características são listadas na tabela a seguir:

A maioria das características que determinam um software com qualidade referem-se mais a boas práticas de engenharia de software ou eficiência da plataforma tecnológica. Entretanto, Scrum, como framework para gerenciamento de projetos, também é capaz de oferecer qualidade no processo de desenvolvimento.

Em Scrum, conseguimos uma melhora na qualidade através de diversos pontos. Entretanto, obter esta melhora na qualidade depende muito se Scrum está sendo bem implementado ou não.

Dentre estes pontos, podemos destacar:

• Iterações
• Remoção de impedimentos
• Inspeção e adaptação
• Autonomia
• Times multi-funcionais

Iterações

Qualidade em software também significa entregar para o cliente algo que lhe seja realmente útil, de acordo com suas necessidades.

Por ser uma framework ágil, Scrum trabalha com iterações, onde a cada iteração entregamos software, ou incrementos de software, potencialmente usável e de acordo com a necessidade do cliente. E a cada nova iteração, temos “feedback” do que foi entregue e que utilizamos para melhorar o produto (sempre de acordo com a prioridade do cliente).

O “feedback” do cliente haveria de qualquer forma, seja apresentando o produto ao final de uma iteração, seja ao final de todo o ciclo de desenvolvimento, o que normalmente acarreta em alterações no código. Entretanto, se estas alterações forem feitas no final do projeto, isto também pode acarretar efeitos colaterais indesejados, ao passo quefazê-las de forma antecipada impede este tipo de problemas.

Através das Sprints, times Scrum estão sempre desenvolvendo algo que realmente tenha valor para o cliente.

Remoção de impedimentos

Remover qualquer tipo de impedimento durante a execução de um projeto é essencial não importa qual metodologia seja utilizada. Em Scrum é esperado que estes problemas apareçam. Mas o que é feito após resolver este impedimento determina se um time está utilizando Scrum corretamente ou não.

Durante a execução de uma Sprint, é recomendável que a execução das tarefas seja feita item a item ao invés de cada membro executar tarefas de itens diferentes. Isso tem duas razões: a primeira é relacionada ao valor para o cliente. Para um cliente, um item somente tem valor caso tenha sido entregue completamente — uma funcionalidade que esteja funcionando 80% não lhe trará vantagem alguma. Além disso, executar um item completamente ajuda a manter o foco da equipe na meta e no item em específico. Desenvolvedores em geral tendem a ser mais orientados a tarefas ao invés de orientados a valor. Manter o foco na meta ajuda a aumentar a qualidade do item sendo desenvolvido.

A outra razão é em relação à forma como os problemas são resolvidos e suas correspondentes soluções são utilizadas. A execução completa de um item representa um fluxo completo de execução e faz parte do processo utilizado no desenvolvimento. Neste caso, problemas que poderiam se tornar recorrentes podem ser solucionados imediatamente, permitindo que isso não se repita na execução dos próximos itens. Desta forma estamos aprimorando o processo, o que também reflete na qualidade do produto.

Inspeção e adaptação

Ao final da execução de uma Sprint há a Sprint Retrospective, uma das cerimônias de Scrum. Nela, revisamos a Sprint (inspeção) e determinamos o que foi bom e o que precisa ser melhorado (adaptação). As adaptações podem ser individuais ou coletivas, mas de qualquer forma são uma forma de garantir a melhora do processo e consequente otimização, o que traz diversos benefícios.

Com um processo mais enxuto e mais eficiente, podemos ter um software com mais qualidade.

Autonomia

Times em Scrum são auto-gerenciados, o que significa uma menor pressão sobre eles. Desta forma, cada um dos membros pode selecionar o que fará e terá o tempo necessário parafazê-lo com qualidade. Estudos mostram que, sob pressão de prazos exíguos, a primeira coisa a ser deixada de lado pelos desenvolvedores é a qualidade.

Além disso, através desta autonomia, os membros do time passam a ter uma melhor qualidade de vida, o que reflete em uma melhoria na qualidade como um todo. Isso porque passam a ter mais tempo e disposição para pesquisar uma melhor forma de abordar e executar uma tarefa. Em um ambiente onde Scrum tenha sido bem implantado, este aprimoramento pessoal é compartilhado com os outros membros, o que traz mais incremento na qualidade.

Times multifuncionais

Quando montamos os times, procuramos sempre montá-los com membros que tenham diferentes características ou atribuições. Por exemplo, ao invés de um time formado só por desenvolvedores ou só de analistas de requisitos, procuramosmisturá-los e formar diversos times Scrum.

Isto porque a experiência de cada um é extremamente útil no planejamento das tarefas a serem executadas na Sprint. Entretanto, existe um conceito maior escondido por trás disto: qualidade desde o início.

Pude presenciar em diversas ocasiões a seguinte situação: empresas utilizando o modelo em cascata, faziam o levantamento de requisitos no início do projeto. Em seguida, arquitetos de sistema e especialistas no negócio modelavam as classes para atender a todos os requisitos levantados na etapa anterior. Depois (bem depois, por sinal), estes modelos eram passados para a equipe de desenvolvimento e o resultado era testado pela equipe de Q&A e homologação. No final do processo, isto era entregue à equipe de implantação.

Invariavelmente, o contato com o cliente era feito no início do projeto, onde este apresentava todos os requisitos possíveis e imagináveis para o produto. Embora saibamos que o cliente saiba o que precisa mas tenha somente uma vaga idéia do que quer, ele era obrigado a informar o que desejava que fosse desenvolvido, e por isso a quantidade de requisitos, algumas vezes desnecessários, era imensa.

Durante a modelagem, os analistas modelavam o que era necessário para a aplicação, muitas vezes deixando de lado alguns detalhes que poderiam facilitar o desenvolvimento ou ignorando outros detalhes que pudessem melhorar o acesso aos dados.

Os desenvolvedores, por sua vez, simplesmente executavam o que foi determinado pelos arquitetos e no prazo determinado pelo gerente de projeto.

Depois de devidamente codificado, o resultado era passado para a equipe de Q&A, que testava o que tinha sido produzido e retornava o resultado dos testes à equipe de desenvolvimento. Infelizmente, isto era feito invariavelmente aos lotes — os testadores eram obrigados a testarem diversos recursos de uma vez, muitas vezes impossibilitando testes com aspectos mais amplos.

Como tudo isso feito às pressas, em algumas situações, a equipe de implantação era informada com poucos dias de antecedência (e em uma situação, a equipe foi informada que tinha até o final da tarde para implantar um sistema). Com tão pouco prazo, muitas vezes a implantação era feita sem qualquer teste, simplesmente esperando que a sorte sorrisse para eles.

Note que os cinco parágrafos anteriores descreveram cada um dos estágios no desenvolvimento. E isto reflete como o desenvolvimento era feito — sem qualquer comunicação adicional entre cada uma das etapas que não fosse a documentação do sistema. É fácil descobrir o resultado disso.

Através de times multifuncionais, a cada Sprint temos a opinião de especialistas em diferentes áreas definindo o que será feito naquela Sprint. Enquanto não sabemos o que o cliente realmente quer como produto, sabemos o que é mais importante para ele, com estes especialistas definindo a melhor abordagem possível, levando em consideração os aspectos nos quais cada um é melhor. Assim, arquitetos podem começar definindo as classes levando em consideração a opinião de um especialista em banco de dados, de domínio, etc.

Utilizando o princípio de qualidade desde o início, o código tende a ser mais enxuto, mais adaptável, a ter mais performance. Como a interação com o usuário é constante, o produto estará sempre de acordo com a necessidade do usuário. E com a presença de um especialista em testes, cada tarefa executada já pode ser testada e eventualmente corrigida rapidamente.

E finalmente, um especialista em implantação já sabe antecipadamente o que deve testar e providenciar como ambiente de produção.

Conclusões

Existe uma beleza singular na simplicidade apresentada por Scrum. Entretanto, por trás desta simplicidade, existem conceitos que não devem ser ignorados, sob pena de obter somente parte dos benefícios de Scrum.

Um ScrumMaster deve estar sempre atento aos diversos sinais que o time apresenta, bem como motiva-los e desafia-los, sempre em busca constante do aprimoramento individual como seres humanos e o time como um todo. Além disso, buscar a melhoria contínua do processo permite que a qualidade passe a ser uma constante em futuros projetos de software.