A arte de apresentar resultados tangíveis rapidamente…

julho 9, 2011

Em meus trabalhos atuais venho defendendo a utilização de LEAN e SCRUM na gerência de novos projetos e na sustentação por um simples motivo: Gosto de entregar produtos (software, no caso) e não somente apresentar cronograma de execução para meus clientes! E cliente feliz, sinal de mais trabalho!

E a razão para isso é bem simples: Em algumas das consultorias pelas quais passei, vi vários clientes serem “enrolados” e cansei disso tudo! Justamente pelo fato que uma entrega não efetuada na data estipulada significa mais do que apenas um problema para a linha de base do projeto, mas sim o início da deterioração do relacionamento com o cliente!

No início de cada projeto, dificilmente não existe um bom relacionamento e o envolvimento direto do cliente. Nesse momento, a equipe de projeto deve aproveitar essa “gana” de fazer vingar o empreendimento por parte do cliente para trazê-lo sempre junto do trabalho, firmando parceria. E isso só é possível se resultados forem apresentados de forma rápida!

Ou seja, as equipes que entregam produtos de forma contínua, com períodos de tempo curtos (um mês, por exemplo) esquivam-se de muitos dissabores causados pelo mau relacionamento, além de ter fôlego para trabalhar sem muitos problemas de desinteresse dos seus clientes! Sem dúvida, eliminam ruídos de comunicação e constroem parcerias fortes!

Como as iterações (em tempo) com Scrum são curtas e constantes, entregas deixam de ser uma “lenda” para se tornarem fato! Basta priorizar o que mais interessa ao negócio do cliente, fechar um escopo, focar a equipe no que deve ser atendido e eliminar todo e qualquer desperdício de tempo, recursos humanos, materiais, etc para que se ponha a mão na massa…

O fato é que um planejamento só é eficaz se entregue com o mínimo viés para com o idealizado no início. Caso isso não ocorra, o que podemos fazer para minimizar os problemas? Bem, a primeira medida é: Planejar pequeno! E você sabe o porquê disso?

A resposta é: O melhor plano é aquele que você pode mudar a qualquer momento! Ou seja, planejar muito não significa oferecer previsibilidade, mas sim diminuir meios para que mudanças que possam vir a ocorrer sejam atendidas! Em várias oportunidades pude constatar que durante um projeto, planejar uma entrega pequena, mas com alto valor de retorno ao cliente, satisfaz mais do que uma grande entrega de funcionalidades periféricas, sem muito valor!

Além disso, caso o planejamento atual conter mudanças solicitadas pelo cliente, sua satisfação é maior ainda! Pense: Quando é feita uma entrega de valor, ainda que incompleta, mesmo não significando a redenção da equipe, sempre haverá um respiro à mesma!

Mais do que isso, existe a garantia de um voto de confiança do cliente junto ao trabalho executado, pois ele está acompanhando os resultados e não o planejamento. Sem dúvida, os resultados mais satisfatórios sempre estão ligados à execução total do que é mais importante ao cliente! Pois sempre que o produto entregue estiver aderente às necessidades do negócio, todo restante do trabalho será facilitado e as chances de sucesso aumentam! No entanto, existem chances de isso tudo não dar certo?

Sim, lógico! O mais importante nesse caso é relatar o porquê da “não entrega”, mostrando quais foram os impedimentos e o que foi feito para minimizar ou quais mudanças esses impedimentos resultaram no planejamento inicial. É bom ressaltar que a comunicação correta dos problemas auxilia muito na negociação de novos prazos, custos e escopo, junto ao cliente. Não se esqueça disso! Mas caso isso não ocorra, o que podemos fazer?

Pouca coisa… Pois sem fatos, não existem argumentos! Por tal motivo, sempre que ocorreu uma entrega parcial ou uma “não entrega”, tratei de finalizar o combinado na próxima Sprint, priorizando a inclusão dos itens não finalizados anteriormente. Portanto, antes de prosseguir no projeto, devemos garantir que a entrega de pacotes acordados anteriormente com o cliente sejam sempre efetuadas, ao final de uma jornada de trabalho.

Sem isso, nada feito! Para finalizar, aos colegas românticos, que acham o cliente é um amigo, que não se importa com atrasos, deixo aqui um bom conselho: Não se iluda meu camarada! Seu projeto depende de entregas, e sem isso, não haverá continuidade do trabalho! Mesmo assim se houver, faça um estoque extra de sal de frutas, pois você e sua equipe irão precisar!

Abs, até a próxima e curta o som…


Quem tem medo de Scrum?

abril 14, 2010

Após quase um ano (um ano!) de trabalho duro, voltado à implantação de Scrum em minha empresa, posso dizer categoricamente a todos, em alto e bom som: Ser ágil hoje em dia não está nada fácil! E tem mais! Mudar a cabeça das pessoas que trabalham em TI, visando criar um novo ambiente, uma nova forma de pensar e transformar tudo isso em uma nova cultura, é tão ou mais difícil que escalar o Monte Everest! Para ambos, além do preparo físico, é preciso o psicológico! Pois obstáculos não faltam…

Antes de qualquer coisa, também digo que não! Não sou e nem sofro de um sentimento derrotista! E tem mais: Prefiro atuar com Scrum à ter que subir uma montanha! Afinal de contas, estou deixando aqui apenas mais um depoimento real, de quem saiu do universo teórico dos livros e chegou a uma constatação! Pois entendo que um livro só é bom se vier seguido da prática!

Nesse caso, para aqueles que tentam se aventurar nessa arte, fica aqui um conselho: Como dizia meu Scrum guru Alexandre Magno, a resistência maior ao Scrum não está do lado do cliente (que adora a agilidade), mas sim na própria equipe de TI! E pasmem! A maior mudança, a cultural, não está no comercial, na pré-venda ou na concepção de projeto para o cliente, mas sim, está dentro da nossa própria cozinha! E nessa hora, o que fazer?

Trabalhar de maneira ágil, segundo rezam diversas cartilhas agilistas, de referências como Scott Ambler, Ken Schwaber ou Alistair Cockburn, todos esses são unânimes em apenas um único ponto: Para que seu projeto dê certo e você se torne ágil, o primeiro passo é comunicar-se bem, mais e melhor! E fazer isso é simples? Sim, é muito simples! Tão simples que dói, e para fazê-lo tem que ter coragem…

Digo isso porque sem sombra de dúvidas, para promover a comunicação efetiva entre as pessoas, certas barreiras devem ser transpassadas, dentre elas o orgulho, o ego e a vontade de se sentir mais que o outro. Da mesma forma, para liderar e ser um Scrum Master (team lider), não é preciso ser um catedrático em metodologias ou vomitar processos malucos e sair preenchendo templates. Basta apenas existir no time de projeto uma liderança servidora e pessoas responsáveis por seu trabalho; comprometidas em quebrar problemas e promover a cooperação entre todos os membros, da própria equipe e do seu cliente.

Para isso, o líder deve ter uma atitude positiva! Direcionar sua equipe, sempre visando atingir uma meta comum. Essa pessoa deve mostrar ao time que o “ponto de conforto” está na entrega de valor ao cliente e não na justificativa do insucesso ao final de um ciclo de trabalho! Pois sabemos que a melhor cobrança é aquela que vem de dentro para fora e não ao contrário. E o time que se cobra é porque está comprometido com o resultado de seu esforço!

Entendo que um líder servidor não deve ser um cara teórico, mas sim prático. E para ser prático, esse precisa estar bem informado de tudo que está ocorrendo no decorrer dos trabalhos! Portanto, fazer da comunicação em sua equipe uma prática diária e com hora marcada para acontecer é primordial. Sim! Esse cara terá que se comprometer e ser cobrado por estar informado sobre tudo que acontece! Em Scrum, essa prática é chamada de daily meeting.

Sem mais delongas e indo direto ao ponto, quando se decide utilizar Scrum, algumas práticas propagadas pelo método devem acontecer impreterivelmente! Dentre elas o tal encontro diário da equipe e o acompanhamento dos trabalhos em um canal comum e visível para todos do time, por meio de um quadro Kanban, devem ser utilizados.

Isso por si só, já é Scrum. Essa é a raiz do método, o DNA, onde tudo começa… Sem essas duas práticas ou com apenas uma delas, estamos fazendo o temeroso Scrumbut. Ou seja, “Aqui em nossa equipe utilizamos Scrum, mas…”. E tenha certeza que esse “mas”, geralmente, esconde os problemas que a própria prática do Scrum traz à tona.

E você sabe por quê? A resposta é simples: Quem quer se expor? Problemas geram exposição e quando mostrados, geram desconforto. Será que agora faz sentido o início desse texto, quando foi dito que a área mais resistente à implantação e uso de Scrum é a própria área de TI?

Dessa maneira, até quando iremos nos esconder por trás de nossos próprios erros? Para você (é, você mesmo) que esconde seus erros, está sendo honesto consigo ou está indo trabalhar apenas para bater ponto? Está sendo honesto com seu líder, com seu chefe ou com quem lhe paga o almoço? Se você não assume seus próprios erros, como fica seu propósito profissional? Temer a exposição do erro é um ato de salvação do emprego ou de covardia? No final das contas, você tem medo do que? De errar ou de aprender?

Pondo um ponto final nessa conversa, desde já, entendo que o ultimo parágrafo, até para quem escreveu, causou certo desconforto!

Acredito que o debate é o início para uma boa comunicação. A exposição do trabalho perante o time de projeto e a pontuação de suas atividades pode parecer ruim num primeiro momento, mas quebrado o preconceito, não tenha dúvida que facilita a vida de todo mundo.

Segundo o educador Benjamin Bloom, em sua teoria da taxionomia educacional, o mesmo propõe que o aprendizado efetivo se dá com o erro, pois quando esse ocorre, teoria e prática se fundem, fazendo com que o resultado dessa fusão se transforme em conhecimento!

Portanto, errar não é demérito! Mas empurrar ou escondê-lo é sim, uma grande hipocrisia! Por fim, muito mais do que uma (auto) crítica, afinal também trabalho em TI, convido todos para uma ultima reflexão. Quando desligar sua máquina ao final de mais um dia de trabalho, responda a essa pergunta: “O que você veio fazer aqui hoje?”

SUGESTÃO DE LEITURA:
O Monge e o Executivo – Uma história sobre a essência da liderança
James C. Hunter

http://pt.wikipedia.org/wiki/Taxonomia_dos_objetivos_educacionais


Empresas com DNA Scrum: Onde tudo começa?

outubro 6, 2009

Hoje meu principal patrocinador (lê-se chefe) me lançou um paradigma! Como quem não quer nada, deixou claro que para ele, os valores propagados pelo Scrum, no que diz respeito à organização de times de projeto são notoriamente eficazes; e por isso, não tinha dúvidas quanto à sua adoção!

No entanto, ele estava mesmo interessado em como implantar práticas e conceitos do Scrum não somente às equipes de projetos, mais sim no restante da empresa, pois deseja que a mesma seja vista por seus parceiros e clientes como uma organização ágil em sua missão.

Para um bom entendedor, sem meias palavras, ele deixou claro que a cultura do Scrum não pode ficar restrita somente aos setores responsáveis pelo gerenciamento de projetos, mas sim, deve estar refletido no DNA da sua empresa.

Diante dessa afirmação (com ares de indagação), confesso que fiquei feliz e surpreso ao mesmo tempo. Feliz porque acredito nos benefícios que a mudança de cultura propiciada pelo Scrum pode oferecer à organização como um todo. E surpreso porque nesses últimos tempos tenho acompanhado a aplicação do Scrum a outros temas, que não somente à Engenharia de Software, o qual vem ganhando a cada dia mais força na comunidade ágil.

Apesar da maior parte da literatura sobre a aplicação do Scrum disponível na internet estar relacionada diretamente ao desenvolvimento de software, existem alguns autores que têm explorado em seus artigos as outras áreas de conhecimento, inerentes à gerência de projetos ágeis, mirando benefícios e desafios da aplicação desses métodos, ora focando aspectos da criação de ativos organizacionais e humanos, ora apresentando sensíveis diferenças entre os modelos tradicionais e os ágeis.

E foi numa dessas pesquisas, que no site da Scrum Alliance, descobri um paper de Laszlo Szalvay, relacionando Scrum à área de Recursos Humanos de uma empresa com objetivos ágeis.

Após a leitura desse artigo, ficou claro para mim que para a cultura do Scrum ser efetivamente entendida por todos e emplacar, uma organização que tenha em seu DNA propósitos ágeis, primeiro se faz necessário que esses objetivos sejam definidos e extendidos a todos seus colaboradores e parceiros; sem distinção, por meio de uma política voltada a metas. Dessa forma será possível efetuar avaliações mais assertivas por parte do desempenho dos times, garantindo que as diretrizes culturais de agilidade e o comprometimento da empresa com esses modelos sejam propagados e compreendidos por todos que ali trabalham.

Szalvay em seu artigo vai além, pois também recomenda dentre outras práticas, que a área de Recursos Humanos, aos poucos, seja envolvida em projetos de grande visibilidade (ou aqueles que oferecem maior valor de retorno à empresa), atuando ativamente no âmbito organizacional como um dos principais interessados na conclusão dos projetos (stakeholder).

Nesse artigo, é salientado que a adoção de tal prática acaba gerando um maior grau de comprometimento de colaboradores para com metas e objetivos traçados pela empresa, pois a obtenção de resultados satisfatórios para ambos oferece subsídios para que o crescimento exista de lado-a-lado, e esses fatores são evidenciados em avaliações periódicas que devem seguir o modelo 360º, definindo e orientando a conduta dos profissionais mediante a análise geral dos resultados obtidos e as respectivas atuações individuais.

Cabe também salientar que essa avaliação pode e deve ser feita de maneira contínua, sendo que o critério de aceitação da empresa deve sempre estar orientado ao cumprimento de metas estabelecidas, atrelada a uma política de premiações por objetivos alcançados. Assim, todos os envolvidos nos projetos da organização entenderão o real valor do seu trabalho, participando de forma mais ativa na obtenção de resultados da empresa como um todo.

Dentre as práticas do Scrum, talvez o momento ideal para esse tipo de auditoria (se esse for o melhor termo para designar o envolvimento do RH no processo) se dá na apresentação de resultados da sprint e em sua reunião subseqüente. Durante a reunião de finalização da sprint, não somente aspectos técnicos serão abordados pelo time, mas sim serão apontados também fatores organizacionais e humanos, os quais devem ser avaliados cuidadosamente pela empresa.

Nesse momento, um profissional de Recursos Humanos pode ser um elo ativo junto à melhoria de processos organizacionais e a alta gerência. Pois o mesmo poderá identificar necessidades de perfis e qualidades de recursos da equipe, possibilitando que direcione de forma inovadora as novas contratações, levando em consideração aspectos relacionados à melhoria do trabalho do grupo, premiando talentos ou visando corrigir carências identificadas.

Seguindo por essa vertente, a empresa também pode (e deve) implantar de maneira mais eficaz políticas de incentivo e estabelecimento de metas individuais, o que estreita os laços da organização junto a seu capital intelectual. Portanto, deverá sempre existir uma preocupação de ambos os lados para com o desenvolvimento e aprimoramento do pessoal, tanto do ponto de vista coletivo, como no organizacional, abrindo a possibilidade de aprendizado e valorização com foco na melhoria contínua de seus profissionais e demais recursos humanos da organização.

Uma vez adotada com a periodicidade esse tipo de avaliação, é muito provável que a equipe ganhe mais maturidade e, aos poucos, caminhe para um auto-gerenciamento de seus trabalhos, aos moldes de um PSP, cujo método está baseado em pessoas . Tal propósito, além de representar ganhos de valores para a empresa, vai de encontro com os princípios do Scrum, quanto aos conceitos de valorização e integridade do trabalho do individuo e do grupo.

Tal orientação, portanto, deve servir como base de incentivo a todos os envolvidos nos projetos da empresa, desde o estagiário, até a alta gerencia; pois fica claro para todos que o trabalho bem feito, rende benefícios para todos e premia aqueles que ajudam no crescimento da empresa.

Assim, o fato de a empresa incentivar que metas sejam atingidas e que isso traz algum tipo de recompensa ao coletivo,  o trabalho dos individuos e dos grupos tendem a fluir de maneira mais direcionada à cultura da melhoria contínua. Pois assim, de forma simples, estaremos relacionando propósitos humanos aos da empresa, formando uma cultura orientada a resultados; formando a base da cadeia de um DNA ágil.


Auditando Scrum

agosto 24, 2009

Nessa última sexta-feira, dia 21/08/2009, enfim encerramos nossa primeira iteração, utilizando o Scrum na nossa empresa. Finalizamos a sprint com entregas de valor ao cliente (esse foi um motivo de alegria para todos da equipe) e tivemos um bom feedback por parte dos investidores do projeto, o que nos deixou ansiosos por novos resultados.

Entretanto, como nem tudo são flores, houve também um pequeno problema relacionado à auditoria do método, por parte de interessados nos trabalhos executados pela equipe, mas que não faziam parte do Time de projeto.   

Quando algumas práticas do método começaram a ser inquiridas por agentes externos ao projeto para o time, o Scrum Master responsável decidiu fechar sua equipe em uma reunião, impedindo que a auditoria externa fosse efetuada antes da interna. E isso, obviamente, causou constrangimento, pois nem todos haviam se atentado a esses pormenores do Scrum.

E como não poderia deixar de ser, realizamos a finalização dos trabalhos marcada pela Reunião de Encerramento. Segundo Ken Schwaber, em seu livro Agile Software Development with Scrum, as práticas de auditoria do método prevêem que:

  • Ao final de cada SPRINT deve ser feita uma reunião de retrospectiva, cujo objetivo principal é fortalecer a unidade da equipe. 
  • Essa reunião pode ser dividida em duas etapas. A primeira parte deve ser efetuada a apresentação dos resultados aos investidores do projeto e aos demais interessados no trabalho. Na segunda parte da reunião, devem participar apenas o Scrum Master e o Time, sendo que eventualmente, poderá ter a participação do Product Owner, onde serão discutidos assuntos relevantes a iteração finalizada.
  • Durante essa reunião, três perguntas deverão ser respondidas com seriedade por todos os membros do time SCRUM:

 1. O que você fez e gostou neste SPRINT?

2. O que você fez e não gostou neste SPRINT?

3. O que você vai fazer diferente no próximo SPRINT?

Ao final da reunião, deverão ser geradas duas listas, que apresentem as boas práticas aferidas pela equipe durante a Sprint e pontos falhos, os quais devem ser melhorados e que podem vir a se tornar impedimentos às próximas iterações.

Sabendo que o desenvolvimento de projetos de software é sempre uma prática desafiante, e por essa ser uma atividade complexa a maior parte do tempo, cabe aos membros do time identificar as boas práticas do processo.

Dentre as boas práticas salientadas pelo time, tivemos:

  • Geração de uma documentação consistente às necessidades iniciais;
  • Cumprimento da data;
  • Empenho da equipe mesmo com a falta de informações importantes para o trabalho, fazendo com que os membros do time identificassem entre si, formas de obter as informações necessárias para concluir o objetivo da sprint;
  • Conhecimento adquirido;

Entretanto, o time identificou as seguintes práticas a serem melhoradas para as próximas iterações:

  • Comunicação mais assertiva com relação a prazos, objetivos e expectativas;
  • Falta de informações sobre a parte de configuração da aplicação;
  • Títulos das atividades pouco intuitivos, dificultando o entendimento;
  • Falta de detalhamento dos requisitos;
  • Falta de uma análise prévia do sistema, feita de maneira mais consistente;
  • Falta de um nivelamento do conhecimento sobre o sistema, por parte dos membros da equipe de testes;
  • Pouca interação entre os membros da equipe;
  • Em certos momentos, foi identificada falta de união, tolerância e aceitação por parte de membros da equipe, o que prejudicou de maneira significante a comunicação;

Essas informações puderam mostrar um pouco mais o que foi a entrega dos trabalhos. Embora o sucesso tenha sido atingido e os objetivos iniciais alcançados, os problemas levantados mostram que ainda há muito que melhorarmos.

Entretanto, tais informações servem tanto para a melhoria do time, como para alertas junto à empresa, que deverá prover meios que possibilitem uma melhor utilização dos recursos disponíveis, o que poderá incidir em ganhos nas próximas etapas de trabalho.

Assim sendo, que venha a próxima sprint!


Utopia?

julho 16, 2009

 

Seria utopia imaginar uma equipe atuando nesses moldes?

Segurança e Gestão de Negócios

  • Assegurar a provisão de recursos capazes de executar tarefas que garantam a geração de produtos de valor para o cliente.
  • Alcançar a satisfação do cliente por meio do compromisso;  atendendo da melhor maneira suas diretrizes de negócio.
  • Municiar a gestão estratégica da empresa de maneira eficaz junto aos seus processos de negócio; garantindo valor de retorno a clientes e parceiros.

Inovação e Crescimento

  • Respeitar requisitos da proposta comercial, técnicos e não técnicos; integrando-os às práticas de melhor interação junto ao meio ambiente e a gestão de pessoas.
  • Gerir, implantar, manter e garantir qualidade ao produtos, processos e tecnologias desenvolvidas pela empresa.
  • Atender de maneira ágil requisitos de prazo, desempenho, custo, confiabilidade e portabilidade do software, gerando valores.
  • Identificar oportunidades e aplicar o gerenciamento de riscos, visando a redução de custos e a melhoria continua de produção.

Desenvolvimento e Oportunidades

  • Utilizar os recursos disponíveis de modo inteligente, com foco na eficiência e segurança.
  • Desenvolver produtos de qualidade, respeitando prazos e custos aceitáveis, de modo a se adaptar às necessidades do cliente.
  • Melhorar continuamente os modos de produção, agregando conhecimento e privilegiando a criatividade produtiva.

Envolvimento e Organização

  • Atrelar todo e qualquer esforço coletivo a valores e metas atingíveis; alcançando resultados por meio de respeito, cooperação, autonomia e trabalho em equipe.
  • Comprometer-se com a melhoria continua nos serviços prestados; aumentando a confiança de clientes e parceiros; construindo novas alianças. 

Qualidade Contínua

  • Entender as necessidades dos clientes e desenvolver métodos para que os mesmos sejam plenamente e amplamente atendidos.
  • Avaliar de maneira abrangente os resultados obtidos, mensurando a satisfação do cliente, da empresa e dos recursos comprometidos no desenvolvimento do produto.
  • Visar a garantia da qualidade respeitando critérios e requisitos de satisfação do cliente; agregando valores de negócio aos produtos gerados para ele e para a empresa.

Será mais uma utopia ou vale a pena tentar?


Pondo a mão na massa!

junho 21, 2009

 

Nessa semana começaremos a distribuir nosso tempo de uma forma diferente! Mesmo que com atividades já estabelecidas, arranjaremos tempo para criar uma nova cultura de comunicação. Isso exigirá mais ação e comprometimento de todos. Mas em compensação, teremos menos correria depois, e uma melhor qualidade de vida agora! Garanto que isso irá mexer com muitas pessoas, visto que boas coisas são contagiantes e quando muitos acreditam que pode dar certo, acaba pondo em evidência que as mudanças iniciadas anteriormente, foram necessárias!

Como primeiro passo, se falará muito sobre questões mais abrangentes em nosso cotidiano. Para um trabalho ser direcionado ao relacionamento humano, antes de iniciá-lo, a conversa deverá ser clara, limpa. A formação da equipe Scrum deverá ocorrer orientada pelas práticas da metodologia, levando em consideração a formação de espírito de time! Onde se ganha um, ganham todos. Se um perde, todos perdem!

E esse é o ponto principal onde queria chegar: Lembrando que se a equipe ideal somos nós, então só nos resta formar um ideal para a equipe, certo? Para isso, a principal mudança será a de visão. De cara, tentaremos resolver as seguintes questões: Como seremos imprescindíveis para o negócio de nossos clientes e ao mesmo tempo nos comprometer por aquilo que realmente podemos produzir? Como deixar de lado egos inflados para pensar de maneira  horizontal e cooperativa, sem estrelismos? Vamos mudar nossa forma de trabalhar nos voltando à metas ou continuaremos a seguir objetivos não estabelecidos pela equipe?

A receita (que muda a toda hora), embora simples nesse momento, aos poucos deverá ser complementada e temperada pelas hábeis mãos de um Product Owner, um Scrum Master e seu Time. Uma vez que a massa for feita no capricho e a equipe for ganhando maturidade na arte de modelar novas formas para ela, tudo ficará mais saboroso ao gosto de nossos clientes! Bom pra quem? Para os dois…

Dúvida? Vamos por a mão na massa juntos?


Agora falando sério…

junho 17, 2009

 

Quando cheguei à minha atual empresa, me disseram:
– Aqui na nossa equipe fazemos o que é definido via EPM, e lançamos as horas no PWA! Mas nem todo mundo usa… Isso precisa mudar!
Confesso que quando escutei isso, senti um arrepio correndo minha espinha de cima a baixo! Mas por saber que por ser uma prática comum em muitos lugares que funcionam com gestores de projetos centralizadores e controles automáticos voltados ao produto e não às pessoas, tal reflexão me levou à concluir que grande parte dos times de projeto só trabalha baseado em comando-controle. Na pior das hipóteses, a maioria está acostumada ou só funciona com um “input” vertical! Ou seja: Não pense! Faça isso e pronto! Por mais triste que seja, é a vida como ela é!

O que diz a cultura Scrum?

Usando palavras de Ken Schwaber, mentor e um dos criadores do Scrum (mote desse humilde blog), “o fator cultural e a comunicação de uma equipe contribui e influencia positivamente ou negativamente a saúde da maioria dos projetos“. Nesse caso (é batata! – adoro essa expressão), a saúde do projeto está relacionada diretamente à comunicação entre os membros das equipes! E a qualidade da informação trocada pode ser o maior benfeitor ou o pior dos vilões de um projeto! Em tempos de mudança, uma comunicação bem feita faz milagres! E não precisa saber rezar…

Enfim, não basta ser guru (ou consultor em projetos) para prever que boas práticas na comunicação implicarão na diminuição – tendendo à extinção, se perseguida por todos – daqueles indesejáveis erros que vão se acumulando durante os dias contados nos tenebrosos gráficos de Gantt. Tornando o que antes eram grandes bolas de neve, pequenas bolinhas de gude administráveis!

Quem não se comunica…

Assim, para estancar esse ciclo viciado, devemos começar no inicio de tudo (olha o pleonasmo aí!): na concepção dos requisitos. Porque depois, para remendar o telefone sem fio que passa para os membros das equipes de design, que passa por projeto, que passa por análise, que passa por testes (será que passa? passou…) e culmina com a rejeição do cliente ao produto final apresentado, além de ser oneroso, dá um desgaste daqueles…

O ônus de tudo isso, já sabemos de cor: noites mal dormidas; stress de sponsor, stakeholders e uma nítida impotência diante de negativas, culminando na insatisfação nos olhos de todos do time… Alguém já viu algo parecido?

Assim pergunto a você: Como podemos melhorar nossa comunicação? Bem, se isso não for um hábito cultural da equipe, devemos ter alguém responsável por tal tarefa. Alguém que consiga influenciar positivamente a todos, transformando a cultura do ambiente, propiciando o desenvolvimento coletivo e rompendo com idéias e padrões que não estão dando resultados. Dentre eles, por que não tentar quebrar um velho paradigma do tipo: “manda quem pode, obedece que tem juízo” para: “como posso colaborar para que tudo dê certo?”.

Não sei, mas acho que temos muito a conversar!

Tempos de mudança

É inegável que atualmente a única certeza que temos em ambientes de projeto é que tudo vai mudar! E para haver mudanças, o ambiente entre as pessoas deve ser receptivo a elas; senão isso passa a ser sinônimo de problemas! Nesse caso, ter times que se adaptem rapidamente quando elas ocorrerem facilita muito a vida de todos.

E mais, para que a cultura do autogerenciamento propagado pelo Scrum seja adotada (e notada) em sua plenitude, uma coisa é fato: Pessoas devem ser tratadas como tal e devem se comunicar como tal! E a tarefa do Scrum Master nesse contexto é sempre objetivar uma maior interação entre os membros da equipe. Mediando discussões, incentivando a busca por metas e facilitando as coisas para que as mudanças ocorram com mais naturalidade e sejam melhor aceitas por todos.

Para isso, devemos nos preocupar em formar equipes com um alto nível de comunicação assertiva, focadas num objetivo comum, e não ter um bando especialista afônicos que batem cabeça em grupo! Será que isso é fácil? Não, não é mesmo!

Epílogo

Como esse post é para falar de Scrum, em minhas andanças por sites e blogs de Scrum Masters (porque será que todo Scrum Master tem um blog?), sempre coleto algumas informações que acredito que possam ajudar minha equipe. Sem me alongar muito nesse papo, uma definição legal que achei sobre Scrum é:

Scrum é definido como um método simples e empírico. Depende quase que exclusivamente de inspeção, adaptação e comunicação das mudanças entre os membros da equipe. Iterativo e com times auto-organizáveis, deve gerar incrementos e definir entregas de valor ao cliente ao final de cada jornada de trabalho (sprint).

Simples assim? Sim, simples assim… Mas sem comunicação, nem isso dá pra fazer!

Segundo o Sílvio Santos, “a chave do negócio é se comunicar melhor para atingir cada vez mais mercados“. Será que ele consegue?? Não sei, mas nos dias de hoje, a frase do próprio que melhor se encaixa nesse contexto é: Quem quer dinheiroooo???

Trocando em miúdos, comunicação vale dinheiro! A boa comunicação, abre novos mercados!

Depois dessa, vou dormir! Essa é pra pensar no travesseiro!

Abraço a todos e até a próxima!