Durante o terceiro encontro do user group Scrum Amazonia, foram discutidas a técnica de gerenciamento de tempo Pomodoro e o uso de ferramentas para suporte ao gerenciamento de projetos Scrum.

Então…

Scrum Tools: to use or not to use? That is the question.

Essa pergunta é frequentemente feita por entusiastas assim como organizações que utilizam Scrum para o gerenciamento de seus projetos, independente de seus níveis de experiência. Vamos falar um pouco sobre as ferramentas, seus objetivos e as que estão em uso no mercado (as principais) e então vamos discorrer um sobre o cerne da questão.

Entre as ferramentas em uso atualmente temos aquelas utilizadas online, hosteadas em algum web server que disponibilizam suas funcionalidades online, sem necessidade de instalação ou deployment por parte do usuário. Algumas são 100% gratuitas enquanto que outras possuem versões mais completas e pagas. Entre estas ferramentas podemos citar:

* Scrumpad
* Scrumy
* SkinnyBoard
* Banana Scrum

Em se tratando de ferramentas que não são web-based (com instalação e/ou deploy), podemos citar as mais utilizadas Redmine, ScrumWorks e ScrumWorks Pro, Mingle, VersionOne, Scrum for Team System, RallyDev, TargetProcess, entre outras. As tecnologias utilizadas pelas ferramentas variam desde simples php até Widgets GWT e Ruby on Rails. O blog Scrum Breakfest apresentou uma pesquisa de 2008 que no momento mostrava como se encontrava o uso das ferramentas de deploy no mercado. A figura abaixo mostra esse uso.

Com relação puramente a Scrum, algumas têm suas funcionalidades bem focadas na arquitetura do Scrum enquanto que outras (Skinny Board, Scrum Pad) já adicionam por exemplo funcionalidades a mais, como o Kanban. Lembrando que Kanban não é Scrum, mas uma ferramenta Lean.

Na verdade, a questão principal das ferramentas é o valor que ela adiciona na administração do projeto ou ao projeto em si. Temos que diferenciar o valor gerado ao gerenciamento e o valor gerado ao projeto. O valor gerado ao gerenciamento, ou ao sistema de gerenciamento de projetos (vide PMBOK) utilizado é definido pela organização. Isso será válido enquanto o Scrum estiver rodando apenas em alguns times esparsos na organização e enquanto a cultura organizacional ditar necessidades alheias ao Scrum. O valor gerado ao projeto é definido pelo time e pelo Product Owner. O TIME define quais tecnologias podem vir a melhorar o processo de trabalho, enquanto que o PO lida com valores de negócio.

Por exemplo, a geração de estatísticas, gráficos como o burndown, etc. É fato que Scrum não trabalha com horas trabalhadas e sim com o número de horas que ainda restam para uma tarefa ou estória ser considerada realizada. Porém, quando uma organização está iniciando em Agile e Scrum, ela muito provavelmente vem aplicando metodologias baseadas nas práticas do PMBOK ou outro processo pré-definido qualquer que facilitam a extração de horas trabalhadas. E isso as organizações o fazem porque faz parte de suas culturas calcular (baseando-se em estimativas) o custo de um projeto, ou quanto tempo resta para terminar o projeto, ou quanto custa cada developer, ou qualquer outra medida que sob o ponto de vista de organização facilita o gerenciamento da tríade CUSTO, TEMPO, ESCOPO.

Temos então dois pontos de vista: o da organização e o do time. Em um mundo ideal, esse ponto de vista seria o mesmo, mas isso é uma outra estória. Sob o ponto de vista da ORGANIZAÇÃO, sendo ela iniciante em Scrum, a mesma deve inciar com práticas mais lúdicas como o Scrum Board, post-its, etc. Por quê? Porque se tal organizacão buscar ferramentas “puras” em Scrum como o ScrumWorks, ela vai sentir falta de estatísticas passíveis de serem geradas no decorrer do Sprint como as famigeradas horas trabalhadas. Sob o ponto de vista do TIME, ele pode definir que o uso de uma ferramenta pode melhorar seu trabalho, porém se isso impactar de alguma forma a organização (geralmente isso é definido pela figura de um gerente de projeto), seja infraestruturalmente ou seja pela quebra de alguma cerimônia, fica para o ScrumMaster a tarefa de proteger o time de quaisquer impactos. Ou seja, mesmo que o time defina utilizar uma ferramenta pode ser que isso não seja facilitado pela organização. Ou pode ser que ele utilize a ferramenta sem problemas.

O que pode motivar um time a adotar uma ferramenta? Isso realmente varia de time pra time, mas podemos citar alguns pontos que podem ser indicadores:

* Facilidade de acesso a critérios de aceitação de user-stories;
* Acompanhamento das releases planejadas;
* Maior visibilidade da situação dos projetos de escopo fixo e os riscos atuais;
* Acesso a ações planejadas para lições aprendidas; e
* Acompanhamento remoto.

Para a organização já vimos o que pode motivar: necessidade cálculos e estatísticas para gerenciamento do projeto. Um bom exemplo prático é que determinadas instituições demandam acompanhamento bem próximo do seu portfólio de projetos (podendo levar ao command and control…) e processos como ISO e CMMI demandam registros.

Sendo assim, partindo desses dois pontos de vista, pode-se utilizar ferramentas, desde que:

* Isso não impacte o trabalho do time;
* Seja de consenso entre time e organização (se estiverem “separados”);
* Agregue valor ao time e/ou à organização.

E sob o ponto de vista puramente do Scrum? Não precisamos de ferramenta alguma!

Acredito que em todos os projetos nos quais já trabalhei, documentação foi um fator determinante para o sucesso ou fracasso do projeto. Documentação é muito importante e chega a ser irresponsável dizer que documentação é inútil.

Na minha opnião, documentação é uma forma de comunicação entre você (programador/documentador do presente) e você ou outros (programadores/gerentes do futuro - sendo futuro qualquer momento posterior à escrita da documentação). Através da documentação, tem que ser explicado para o próximo o que aquele sistema ou módulo faz. Essa é a função primordial da documentação.

Mas documentação não é apenas escrever dezenas de UMLs. Como disse, documentação é uma forma de comunicação e por definição não pode estar restrita à modelos. Modelos são ótimos para termos um lugar de onde partir (afinal, a melhor forma de aprendizado é através da cópia), mas temos que ter consciência de que devemos criar nossas próprias formas de comunicação com nossa equipe futura.

O que muitos acreditam erroneamente é que agilistas não gostam de documentação. Isso com certeza não é verdade. A maioria dos agilistas que vejo é mais preocupada com documentação do que desenvolvedores que utilizam processos tradicionais. A grande diferença é como cada um lida com a documentação.

Em um processo tradicional, a documentação é vista como uma obrigação. E obrigações são chatas e entediantes, não importa qual seja. Os agilistas encaram de outra forma. A documentação é uma responsabilidade de toda a equipe.

Então você não pode ter alguém responsável por escrever a documentação em uma equipe? Claro que pode (e talvez deva). Mas o ponto de ser uma responsabilidade afeta todos os tipos de documentação, não apenas os que devem ser entregues a algum gerente/supervisor/chefe.

Uma documentação que costuma ser muito ignorada é o próprio código. Como documentação é uma forma de comunicação entre o agora e o futuro, o código fonte da aplicação é o primeiro ponto de contato. Código auto-documentado é um dos principais tipos de documentação. Nenhum outro é capaz de suprir sua falta, porque esse é o código que realmente roda em produção (e consequentemente é quem traz dinheiro para a empresa). E notem a ênfase em auto. Eu não estou falando em ferramentas como javadoc, ndoc, ou comentários. Estou falando sobre código que além de legível é compreensível. Existe uma grande diferença entre os dois. Na comunidade de desenvolvimento SmallTalk isso é levado muito a sério. As boas práticas dizem que se você sentir a necessidade de acrescentar um comentário, você deve alterar o código para que fique mais compreensível e o comentário seja desnecessário.

Um segundo ponto de contato muito importante são os testes automatizados. Testes nada mais são do que documentação funcional do seu código, que ainda tem uma vantagem sobre os outros tipos. Eles são capazes de dizer se o seu código está certo com relação à quando o teste foi escrito. Se um teste falha, significa que o código está errado ou que o teste perdeu o sentido (ou seja, você nunca corre o risco de ficar com essa documentação desatualizada).

Esses são dois tipos de documentação que tem manutenção automática. Você não precisa lembrar de alterar o documento DOC4129-X porque acrescentou um método à classe Funcionario. Acrescentando o método (e o teste), a documentação estará feita.

Mas isso é suficiente? Nem sempre. Trabalhei com vários projetos onde foi o suficiente. Vários outros, não chegou perto do mínimo necessário. Quando estou desenvolvendo uma API para uso público, eu costumo documentar (com uma ferramenta como javadoc) toda a parte pública dela (por mais que muitas vezes eu gaste mais tempo com a documentação do que escrevendo essa parte pública), porque preciso explicar tudo o que vai acontecer, sem que o usuário precise olhar a implementação. Se quero que o projeto ganhe visão, preciso de uma documentação para o usuário, ensinando-o a usar o sistema (essa costuma levar mais tempo ainda).

O mais importante é lembrar que qualquer tipo de documentação exige esforço. Quanto desse esforço é convertido em valor para o projeto? O Toyota Production System é completamente baseado em eliminação de desperdício. E desperdício é qualquer coisa que não acrescente valor ao produto ou cliente. Quanto da documentação nos seus projetos atuais agregam valor aos seus clientes? Todas as 10 páginas para se criar uma modificação em uma classe? Então essa documentação é ótima. Nenhum dos diagramas UML? Então essa documentação precisa ser reavaliada.

Documentação é tão vital quanto água. Sem documentação, um projeto pode morrer. Com documentação excessiva, também.

Por que eu resolvi escrever esse post ?

Bom, vejo muito as pessoas falando de coaching, porém, sinto que não há uma clara percepção no mundo ágil do que realmente é um trabalho de Coaching, qual a importância do papel do Coach em um processo, seja ele qual for.

Por isso resolvi escrever algo a respeito deixando claro que é uma opinião minha sobre o assunto, e que vou falar de forma bem abrangente.

O que é coaching?

Coaching é um processo que visa aumentar a performance de um indivíduo – seja ela pessoal ou profissional com um papel específico – um grupo de profissionais com um objetivo comum ou uma empresa, gerando resultados positivos com metodologias, ferramentas e técnicas, conduzidas por um profissional em uma parceria com o cliente.

Coaching é o processo de evocar a excelência em seus clientes, promover excelente performance a curto, médio e longo prazo e potencializar seu poder.

Coaching estimula uma forte comunicação, identificação e reformulação de valores, metas e busca de soluções.

Coaching é uma habilidade de gestão e gerenciamento de pessoas, indispensável para executivos e líderes.

O que não é coaching?

Coaching não é terapia, aconselhamento, psicologia, consultoria ou mentoring. O coaching é uma abordagem pragmática focada na realização de um ou mais objetivos específicos.

A principal diferença entre o Coach e uma Terapia é que uma terapia tenderá a focar nas experiências e nos sentimentos relacionados a eventos passados, tratando de distúrbios e desequilíbrios emocionais. Já o Coaching irá atuar fortemente com disciplina orientada ao ajuste dos objetivos e encoraja o cliente a seguir em frente na conquista dos mesmos e de novas realizações.

O aconselhamento, mentoring e consultoria não podem ser comparados com Coaching porque conselheiros e consultores fornecem conselhos indicando, falando o que deve ou não ser feito. Em contrapartida, o Coaching irá atuar com o cliente questionando, dando possibilidades e ferramentas para que ele conquiste suas próprias soluções, respeitando sua cultura, valores e princípios. Enfim o coaching não realiza mudanças no cliente, mas sim, o ajuda a descobrir se precisa ou não de uma mudança e contribui fortemente nesse processo que é a parte mais difícil para o cliente — a fase de transição de uma realidade para outra, muitas vezes quebrando paradigmas, idéias fixas, crenças e valores, o que torna dura e difícil a mudança. E se estamos sozinhos é uma tendência natural do ser humano manter-se na zona de conforto. É nesse momento que o papel do Coach é extremamente importante, pois ele será o agente de mudança que irá sempre conduzir o seu cliente com foco em sua meta e não permitindo que o mesmo permaneça acomodado.

O papel do Scrum Coach

O Coach é o agente de mudança responsável por promover a seu cliente a busca de novos entendimentos, alternativas e opções que façam com que ele amplie suas realizações e conquistas. Sempre focado no futuro com o intuito de aumentar a performance, mudança, transformação ou aprendizado; fazer com que o cliente entre em ação de forma mais efetiva e focada.

Definir de forma clara quais são seus principais objetivos com a implementação da framework em sua empresa, traçar um Road Map para atingir esses objetivos com metas e foco no processo. Isso é o mínimo que você pode esperar de um Scrum Coach para fazer com que a implementação do Scrum em sua empresa seja bem sucedida.

Além disso: garantir que os paradigmas da empresa sejam quebrados, desmistificando as “crenças limitantes” que impedem o processo de mudança sem afetar a cultura, diminuindo as dores da mudança, diminuir os riscos com ferramentas como gains and losses para minimizar perdas, dar manutenção de ganhos e produzir uma congruência sistêmica, trabalhar de forma efetiva na educação do time, fornecer ferramentas eficientes no estimulo da comunicação, descobrindo os pontos fracos e trabalhar na melhoria contínua, habilidades para superar barreiras e remover os impedimentos para alcançar seus objetivos. Enfim, garantir que a implementação seja bem sucedida e conduzi-la da melhor forma possível dentro da cultura da empresa.

No próximo post sobre o assunto irei focar mais no papel de um Agile Coaching atuando como um agente de mudança dentro de uma organização.

Até mais.

A AdaptWorks assinou durante o Agile 2009 em Chicago acordo de parceria com a empresa americana Rally. Com sede em Boulder - Colorado, a Rally ajuda organizações a conquistar excelência na utilização de práticas Agile e Lean. A família de produtos Rally para Agile ALM (Application Lifecycle Management) conquistou a premiação JOLT (o Oscar da indústria) por quatro anos seguidos: 2006, 2007, 2008 e 2009. Em um recente third-party study, os clientes Rally provaram ter um aumento em 50% no time-to-market e 25% em sua produtividade. “Ficamos muito contentes em trabalhar com a AdaptWorks, dada a crescente demanda que estamos experimentando no mercado brasileiro e nossa inabilidade para atendê-lo diretamente” disse Dan Forman, Director of Partners & Alliances para a Rally. Com esta parceria a AdaptWorks passará a distribuir as soluções da Rally no Brasil, fornecendo soluções que ajudam times de projeto a adquirir as habilidades necessárias para a entrega rápida de software com qualidade. “Acreditamos que as soluções da Rally podem ser muito úteis para grande parte de nossos clientes. Queremos poder proporcionar isso a eles, e por isso estamos muito motivados com a parceria” disse Alexandre Magno, Diretor da AdaptWorks.

Mais informações sobre a Rally Software e seus produtos e soluções podem ser obtidas em http://www.rallydev.com, ou entre em contato conosco.

Eu costumo falar que a Daily Meeting é uma das práticas mais difíceis de se aplicar em Scrum, ou pelo menos é uma das que mais vejo ser distorcida em times de projetos. Quando falo isso as pessoas sempre me questionam “Mas como pode ser? A Daily Meeting é algo tão simples de ser feito!”.
Em 2007 eu publiquei um artigo na Scrum Alliance chamado “The Daily Meeting Trap”, nele eu citei alguns dos pontos que, naquele momento, eu via como principais armadilhas para a reunião diária. Muitas daquelas armadilhas ainda vem sendo repetidas, mas hoje vejo alguns pontos ainda mais críticos, que não apenas atrapalham no bom aproveitamento de uma “prática de Scrum”, mas sim acabam gerando desperdício dentro do seu processo.
Na minha opinião, a Daily Meeting é uma prática difícil de ser aplicada principalmente pelo fato de que, se o seu time não estiver trabalhando de forma auto-gerenciada MESMO, a Daily Meeting perde completamente o sentido! Ora, o time ser auto-gerenciado em Scrum significa que o micro-gerenciamento fica por conta dele (falo sempre isso em minhas turmas, e recentemente o Mike Cohn também publicou algo a respeito), e a Daily Meeting nada mais é do que uma ferramenta para o micro-gerenciamento! Se o time não é auto-gerenciado…do que me importa saber o que o João fez ontem e pretende fazer hoje? É por isso que vemos muita gente achando as Daily Meeting super chatas. É claro, se uma reunião não aborda algo que realmente me interesse, ela será para mim uma tremenda “perda de tempo”. Um outro ponto é que, se o time não está em busca da mesma meta durante aquela Sprint, a reunião diária mais uma vez deixa de ter valor. Se eu tenho a “minha meta” e é em busca dela que concentro meu trabalho, não me interessa saber como anda o “seu trabalho”.
O que quero dizer é: não adianta apenas aprender a executar uma prática, você deve entender o porque está fazendo aquilo…isso é o que importa!

Após o retorno de Chicago, onde estive participando da Agile Conference, entrei em uma sequência bem grande de viagens que me impediram de escrever aqui minhas impressões sobre o evento. Como agora estou tendo um “tempinho livre”, vamos ao meu relato:

- Hoje, na minha opinião, o que diferencia claramente os eventos gringos de Agile e os eventos realizados aqui no Brasil não é tanto o nível das palestras, mas sim o público! Enquanto aqui encontramos sempre as mesmas “figuras de sempre” nesses eventos, lá fora os organizadores estão focando em trazer clientes e novos usuários para os eventos. Fiquei muito, muito contente em ter na minha palestra pessoas que tinham escutado sobre Agile pela primeira vez fazia 1 ou 2 meses! Não adianta falar sobre Agile para aqueles que já estão convencidos…temos que ter “sangue novo” nesses eventos. Portanto se você é praticante de Agile, convide seus amigos iniciantes para o próximo evento! E para nós palestrantes, o que penso é que temos que sempre revisitar temas básicos em nossas palestras, para tornar os eventos atraentes para os iniciantes no assunto;

- Pelo que vi por lá, Feature-teams é algo que vem sendo bastante utilizado em projetos ágeis largos. O Jim Highsmith apresentou uma idéia destes times bem semelhante ao que é proposta pela FDD (Feature-Driven Development). Já o Bas Vodde, que fez para mim duas das melhores apresentações do evento, tem uma proposta um pouco diferente para estes times, como uma evolução dos já conhecidos times de componentes.

- Falando em FDD, vi por lá umas 3 palestras utilizando estratégias “em cores” no estilo Peter Coad, em técnicas para usabilidade, modelagem de negócio e identificação de itens para um Product Backlog. E pensar que o “em cores” já foi tratado como piada em um evento local…mas vamos em frente;

- A TDD Clinic em C++ apresentada pelo Bas Vode e James Grenning foi fantástica! Nossa…como eu estava com saudade de mexer em um código C++, aqui rolou para mim um profundo momento nostálgico…rs

- A sessão “Product Vision and the Glass Wall” do Matt Roadnight da Conchango foi, como eu poderia dizer, FANTÁSICA! Eu já conhecia um pouco sobre como a Conchango trabalha com a questão de usabilidade na elaboração de produtos, mas a dinâmica, que envolveu quase os 90 minutos inteiros da apresentação, nos mostrou tudo isso na prática. A Conchango é realmente a companhia que inspira o em-fase-de-crescimento estúdio de projetos da AdaptWorks.

- A utilização de Scrum e/ou Lean na gestão de portfólios e programas está crescendo bastante. Além da minha palestra vi o tema ser abordado em várias outras apresentações, destaque para a Barelly Suficient Portfolio Management, apresentada pelo Todd Little da Landmark Graphics.

- As palestras de games para o ensino de práticas ágeis, como eu poderia dizer…causaram um certo enjoo (não apenas em mim). O problema é que eram muitas, e quase todas falavam a mesma coisa, trocando apenas o “brinquedo” a ser utilizado. Uma das exceções neste quesito foi a apresentação dos brazucas Luiz Paulo Parzianello e Rafael Prikladnicki, com a famosa apresentação sobre os jogos estatísticos, que já havia feito bastante sucesso no Brazil Scrum Gathering;

E por falar em Brasil, fiquei muito contente em ver vários brasileiros por lá…fiquei mais contente ainda em ver que a palestra de muitos de nós obteve destaque! Tem muita gente mandando bem de verdade com Agile aqui no Brasil, tem muita empresa - que nem imaginamos - fazendo isso bem. Isso me motiva! Penso que o Brasil vive um momento bastante especial em vários aspectos, mas isso é assunto para um próximo post!

Por fim, gostei bastante de participar da Agile Conference, é um evento bem grande, e que consegue nos passar a dimensão que Agile está tomando. Foi maravilhoso conhecer Chicago, uma cidade belíssima que um dia pretendo voltar realmente de férias, e reencontrar por lá uma grande referência na minha carreira, Renato Quedas, que hoje é Domain Specialist para a Borland/Microfocus no escritório de Chicago.

No dia 22 de agosto, no Novotel Manaus, ocorreu o primeiro encontro do user group Scrum Amazonia, que já conta com mais de 70 associados. Para um primeiro encontro, a presença de 30 pessoas é muito boa!

Parabéns a todos os participantes do encontro, que foi um sucesso. As apresentações foram de altíssimo nível: INDT (Insituto Nokia de Tecnologia), Fundação Paulo Feitoza e Divus. O INDT fez duas apresentações, uma sobre o timeline de implantação do Scrum na empresa e a outra sobre o cotidiano dos times, como estimativas são realizadas, além de como trataram da adoção de Scrum e ISO 9001. A Paulo Feitoza discorreu sobre o case do projeto i-Doctor. A Divus fez uma apresentação sobre um case de implantação do Scrum em agências de fomento do governo estadual.

Tivemos a presença de Carlos Santos, INDT Manaus e de Marco Mafra, INDT Recife. O INDT é o “pai” do Scrum Amazonia! Obrigado ao Carlos e ao Marco pela presença e patrocínio.

Sorteamos diversos brindes: decks de planning poker da Paulo Feitoza e do INDT, 3 livros sobre Scrum (The Enterprise and Scrum, User Stories Applied e Agile Project Management with Scrum). Parabéns aos ganhadores dos livros:

1 - Diego Menezes (User Stories Applied, Kent Beck)
2 - Elizangela Vieira (The Enterprise and Scrum, Ken Schwaber)
3 - Carlos Alberto Viana (Agile Project Management with Scrum, Ken Schwaber)

O livros estão sendo comprados pelo INDT e estaremos serão entregues no proximo encontro do grupo, em setembro.

Tivemos também a presença de Ricardo Moura, MBB (Master Black Belt) Seis Sigma, proprietário da Desenvolver Consultoria, que nos deu apoio na organização do evento.

As apresentações estão disponíveis em:
http://groups.yahoo.com/group/scrum-amazonia/files/

As fotos do evento estão em:
http://groups.yahoo.com/group/scrum-amazonia/photos/album/0/list

Até o próximo encontro!

A Info Exame, principal publicação da área de tecnologia no Brasil, deu destaque na sua edição de agosto para o framework Scrum. Com uma matéria entitulada “Você está pronto para Scrum?” a revista explora o quanto este framework vem se destacando nas empresas brasileiras e o quanto o mercado está carente de profissionais com experiência em sua aplicação. Alexandre Magno, diretor da AdaptWorks, foi entrevistado para a matéria e falou um pouco sobre como Scrum transformou o resultado dos seus projetos, o que consequentemente deu um novo rumo a sua carreira. A matéria conta ainda com um trecho entitulado “Procura-se ScrumMaster!” onde é comentado que o ritmo de adoção das metodologias ágeis no Brasil é maior do que o mercado de trabalho pode oferecer. Alexandre cita que é bastante procurado por headhunters que querem indicação de profissionais com experiência em Scrum, mas revela que o mercado ainda está em fase de transformação e que estes profissionais, que devem agir como agentes de mudança nestas empresas, ainda são raridade no mercado.
No final a revista deixa uma mensagem para quem não está empregado, ou procurando melhores oportunidades, ou ainda está na faculdade: além de correr atrás de uma certificação, começar a estudar e aplicar a filosofia dos métodos ágeis em seus projetos pessoais.

Em meu último post, falei um pouco sobre mudanças organizacionais e de como algumas empresas vêm percebendo a necessidade por mudanças nas atitudes, tanto dos dirigentes quanto dos funcionários.

A esse novo tipo de lidarança a imprensa especializada vêm chamando de “liderança sustentável“. E não é somente pela expressão “sustentável” estar muito em voga.

Analisando as necessidades das empresas, ter uma liderança que se sustente por muito tempo ou mesmo entre diferentes “times” (usando o jargão de Scrum), é realmente uma vantagem enorme.

Estas empresas que procuram este novo tipo de liderança não procuram somente “o retorno que o líder pode trazer a curto prazo“. Elas estão mais preocupadas na sustentabilidade da empresa, mesmo que o lucro não seja o maior possível. Este foi um ponto positivo que a crise econômica trouxe — as empresas realmente estão repensando sobre o que é importante ao invés de somente lucro imediato.

Como ScrumMaster (e até antes disso) sempre achei importante a capacitação dos funcionários. Afinal, não basta simplesmente dizer a uma pessoa o que ela deve fazer — é preciso realmente investir nos funcionários e colaboradores, uma vez que eles nos ajudarão a levar a empresa à frente. E mais ainda, eles podem nos ajudar a sempre melhorar nossos processos, uma vez que são eles que vivenciam isso todos os dias (quem leu “Toyota Talent” vai entender).

Quem sabe a partir de agora, pessoas que realmente tenham algo a oferecer às empresas tenham um pouco mais de chances de provar seu valor.

E que venham as pedras.

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?