Scrum e mudança organizacional — estamos no caminho certo?

[img:hbrjun2009.jpg,full,alinhar_esq_caixa]Estive lendo um artigo interessantíssimo na Harvard Business Review sobre foco na confiança, “Chegou a hora de uma cultura da franqueza“, de James O’Toole e Warren Bennis. Interessante porque o artigo justifica muito do que pregamos em Scrum, mais especificamente a questão da mudança organizacional — o que me levou a rever o conteúdo da palestra do Alexandre Magno no Scrum Gathering Brazil 2009.

Em resumo, o artigo ressalta a importância de uma organização em ser sincera com o público, mas para que isso aconteça, é necessário ser sincera consigo mesma primeiro. E ter franqueza dentro de uma organização é muito mais difícil do que parece. Isso porque a maioria das pessoas já está habituada com a sonegação de informação, com groupthink (quando os integrantes de uma equipe não sabe discordar dos colegas), e principalmente, porque boa parte dos líderes não possuem a capacidade de ouvir seus seguidores, o que pode fazer com que se sintam inibidos e não tenham a coragem de contestar o chefe.

Quem trabalha com Scrum sabe a importância da franqueza no dia a dia. Afinal, essa é a base de uma framework colaborativa como Scrum — utilizar a franqueza para relatar impedimentos, no autogerenciamento, nas Sprint Reviews, etc. E é gratificante ver que algumas empresas já enxergam essa necessidade de transparência e franqueza dentro de uma organização.

De acordo com a palestra do Alexandre, para se atingir esta mudança é necessário mudar o comportamento das pessoas. Mas algumas empresas tentam fazer isso através de uma abordagem errônea. Vejamos:

Em 1971, o psicólogo social Philip Zimbardo conduziu um experimento na universidade de Stanford, que posteriormente foi relatado em seu livro The Lucifer Effect. No livro, ele conta como foi o experimento e como ele fugiu do controle: em um porão de um dos prédios da universidade, uma prisão de mentira foi criada e os voluntários foram divididos em dois grupos: um deles faria o papel de carcereiros, enquanto o outro seria de prisioneiros. Entretanto, os voluntários levaram a encenação tão a sério que o experimente teve que ser interrompido no meio. Isso porque os “carcereiros” começaram a cometer abusos físicos e psicológicos contra os “presos”.

A conclusão do psicólogo foi a de que “quase todo mundo está sujeito a passar para o lado do mal, pois a conduta humana é ditada mais pela situação e pela dinâmica do grupo do que pela natureza inerente do indivíduo“. Assim, ao invés das empresas gastarem milhões em aulas de ética na esperança de que as pessoas passem a se portar bem, seria muito mais eficaz criar uma cultura interna que premie o indivíduo que age corretamente.

Por isso, líderes devem sempre se policiar de forma a se manterem abertos a questionamentos e encará-los de forma positiva (ScrumMasters estão incluídos nessa).

O artigo termina dando algumas dicas para se criar uma cultura de franqueza — lembrando que antes de tentarmos mudar alguém ou algo, é necessário mudarmos nossa própria conduta para depois tentar isso externamente:

  • Diga a verdade.
  • Incentive as pessoas a falar a verdade aos líderes.
  • Premie dissidentes.
  • Aprenda a travar conversas desagradáveis.
  • Diversifique suas fontes de informação.
  • Admita seus erros.
  • Gere apoio organizacional para a transparência.
  • Liberte a informação

Pois é, isso só corrobora a idéia de que estamos trilhando o caminho correto. E você, o que acha?

4 Comentários »

Categorias deste post

Mudança organizacional, Scrum

Scrum Executivo – Pt. 2

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.

3 Comentários »

Categorias deste post

Scrum

A qualidade do software começa na comunicação!

Para mim, o grande diferencial entre as metodologias ágeis e qualquer outra abordagem tradicional de desenvolvimento de software está no uso inteligente da comunicação humana. Enquanto os agilistas procuram estimular a comunicação não-verbal com todos os canais sensoriais do ser humano, a maioria dos profissionais de software investe horas e horas de esforço na construção de mecanismos de comunicação escrita responsáveis por somente 7% da eficácia da transmissão da informação a seus usuários. Para evidenciar essa fragilidade das técnicas de comunicação em ambientes de software, podemos encontrar pesquisas que apontam 64% das funcionalidades como sendo raramente ou nunca utilizadas por seus usuários (quem as pediu?), bem como 63% dos problemas de projeto tendo como origem os requisitos de software (que tipos de problema você imagina?). Desenvolver competências na área da comunicação humana tornou-se imperativo para todo e qualquer profissional demandado por resultados imediatos e altos índices de qualidade em seus produtos de trabalho, pois, do contrário, continuaremos por mais algumas décadas vendo os mesmos índices diante somente de mais complexidade e tecnologia.

Pois bem, quanto mais eu me dedico a capacitar profissionais e a orientar equipes em melhoria de processos, mais me dou conta de que a maioria de nossos gestores está remando contra a correnteza … Explico: ao invés de desenvolverem suas equipes para exercerem toda a competência necessária na entrada do processo de software (comunicação com o cliente e identificação de seus requisitos), investem fortunas em sua saída a fim de comprovar que a qualidade de seus produtos e a eficiência de seus processos realmente são precárias. A comunidade ágil propõe que assuntos como processos de negócio, objetivos estratégicos, retorno de investimento, fluxo de informação, etc. sejam do conhecimento do time e não uma exclusividade de gerentes e analistas de negócios. Com base nessas informações, podemos desenvolver produtos em prazos nunca antes imaginados, com altos níveis de qualidade desacreditados pelo mercado, e com uma constante satisfação do cliente e da equipe de software. Para tanto, precisamos trazer para nosso ambiente técnicas de comunicação que a área de vendas já utiliza há décadas, tornando nossos analistas profissionais altamente eficazes no tratamento dos requisitos de software.

No workshop entitulado “Requisitos de Software: Conceitos e Práticas para Equipes Ágeis” ensino meus alunos a pensarem na natureza dos requisitos e não apenas a escreverem especificações e documentos. Procuro desafiar suas tradicionais crenças sobre o que é um processo de software apresentando conceitos e práticas não difundidos em nossa área, como por exemplo: percepção e comunicação humana, estratégias de pensamento e mudança, análise de negócios e produção enxuta (Lean Thinking), planejamento e controle de projetos baseados na gestão da produção, entre outros. O resultado, após trabalhar durante dois dias (duração do workshop) com grupos de mentes tipicamente analíticas e pragmáticas, tem sido o despertar para um novo mundo de possibilidades. Um mundo ainda pouco conhecido mas com uma vasta quantidade de recursos que podem aumentar consideravelmente nossa produtividade.

Se você é um profissional que trabalha com metodologias ágeis ou que deseja aprimorar suas habilidades na área de requisitos de software, venha aprender como a mente, a comunicação e a logística podem aumentar consideravelmente a capacidade produtiva de sua equipe nos dias 30 e 31/07/2009, datas do próximo workshop a ser realizado em São Paulo. Para informações e inscrição, contate a Adaptworks pelo email contato@adaptworks.com.br ou pelo telefone (11) 5585-7738.

3 Comentários »

Categorias deste post

Agile, Eventos

Comprometimento do time: não faça hoje o que você pode deixar para amanhã.

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.

2 Comentários »

Categorias deste post

Scrum

AdaptWorks é patrocinadora do Agiles 2009

[img:logo_agiles2008_1.jpg,full,alinhar_esq_caixa]Em 2009 foi realizado em Buenos Aires – Argentina a primeira edição do Agiles, um evento sem fins lucrativos, organizado por profissionais entusiastas, unidos com o objetivo principal de criar um amplo espaço de discussão sobre o tema Metodologias Ágeis. O evento foi um sucesso absoluto tendo recebido um grande número de feedbacks positivos. Naquela oportunidade palestrantes como Mary e Tom Poppendieck, Tobias Mayer, Alan Cyment e Danilo Sato estiveram presente e garantiram o resultado final do evento. O evento superou completamente as expectativas de seus organizadores, pois contou com 900 inscrições e mostrou a força com que nossa comunidade latino-americana demanda informações e a troca de experiências sobre Metodologias Ágeis. Infelizmente eu não pude participar da edição de Buenos Aires, mas não perco por nada a edição deste ano!
O Agiles 2009 será realizado na linda, maravilhosa, aconchegante, quase-perfeita e espetacular cidade de Floranópolis – Brasil. O nome dos primeiros palestrantes e keynotes já agradam: Brian Marick (co-autor do Agile Manifesto), Diana Larsen (autora do livro Agile Retrospectives), Naresh Jain (líder do grupo de Agile da Índia), além do colega Alan Cyment (CST). Eu terei a honra de me juntar a este time proferindo uma palestra e realizando um treinamento de CSPO (Certified Scrum Produc Owner) no evento. A AdaptWorks mais uma vez estará apoiando uma iniciativa Agile no Brasil, e já confirmou participação como uma das patrocinadoras do evento.

Como mensagem final eu vou ser bem direto: Não perca este evento!

Site oficial: http://www.agiles2009.org
Submissão de palestras (até 06 de julho): http://www.agiles2009.org/pt/submissions.php

Nenhum comentário »

Categorias deste post

Eventos