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


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!


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?