Quantos lados tem uma empresa?

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Responda rápido. Quantos lados tem a sua empresa?

Tempo.... quase lá... BOING!

E ai? Respondeu?

A não ser que você tenha sido óbvio ao responder "lado de fora e lado de dentro", você errou. Pois se você pensou e respondeu alguma outra coisa, você está cometendo um erro bastante comum no mundo das empresas: achar que existem lados!

Quantas vezes dentro da sua empresa, nas conversas de corredor, não escutou coisas como "aquele pessoal do comercial", "aqueles diretores" ou "aqueles programadores nefastos"? Sempre com ar pejorativo, como se fossem uma célula terrorista inimiga, pronta para arquitetar planos diabólicos contra o SEU lado.

Uma das coisas mais complexas de se mudar numa cultura de empresa, na minha opinião, é exatamente esse sentimento de que existem "lados" dentro do ambiente de trabalho. As decisões precisam ser transparentes para todos. As informações precisam iniciar numa ponta e chegar até o seu destino sem ser podada pelo AI-5. As pessoas precisam ter a noção de que seu trabalho, por mais simples que seja, está fazendo parte de um todo que é a engrenagem que move a empresa. E também que todas pessoas saibam se o cliente está ou não satisfeito com o trabalho.

Vejam, coisas simples, triviais até. E que contribuem bastante para acabar com as barreiras que formam os "lados". Porém, infelizmente nem todas as empresas agem dessa forma. Muitas por medo de que informações possam ser mal-interpretadas, outras por simplesmente acharem que tal informação não precisa chegar a todos. Portanto é lógico perceber que os lados começam a ser criados de cima pra baixo, normalmente.

E o que se pode fazer para mudar isso? Nós, como gerentes, podemos contribuir sim. Primeiramente deixando claro que nós não fazemos parte de nenhum lado. E não por estarmos em cima do muro, mas sim por sermos exatamente o meio de campo da empresa. Aqueles que são responsáveis por garantir que os patrocinadores, clientes e sócios estejam felizes e ao mesmo tempo que a equipe esteja feliz. Pois nós, mais do que ninguém, sabemos o prejuízo que se tem com essas subdivisões.

Buscar conscientizar as pessoas, seja numa conversa informal, seja com atitudes, irá contribuir bastante para começar a mudar isso. Mostrar que aquelas pessoas do comercial não são chatas porque nasceram assim: eles estão representando o cliente, dentro da empresa. Mostrar que os programadores não complicam acima do aceitável. Eles querem trabalhar de forma a garantir que o trabalho saia com qualidade. Que tal criar um breve workshop para que cada área apresente seu dia-a-dia? Ou quem sabe criar um vídeo mostrando o dia-a-dia de cada setor? Ou ser mais radical ainda, fazer uma espécie de "intercâmbio", colocando pessoas de áreas diferentes para trabalharem um dia em outro setor? São algumas sugestões que podem ser aplicadas. Mas existem dezenas de outras.

Se você, amigo gerente, percebeu já que a sua empresa é composta por lados, ajeite as mangas e comece hoje mesmo a mudar isso. Tenha a certeza que se você não for devidamente valorizado por isso, ao menos estará contribuindo para um ambiente de trabalho melhor.

Um grande abraço a todos!

Agilistas-san

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Cena 1:

Daniel Larusso, cansado de ser um cara que apanha de todos, procura Sr. Kesuke Miyagi. Quer aprender Karatê para se defender. O Sr. Miyagi reluta mas aceita.

Cena 2:

Daniel-san chega no primeiro dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda polir os carros. Em movimentos circulares. O dia todo.

Cena 3:

Daniel-san chega no segundo dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda pintar a cerca. De cima para baixo, com calma. O dia todo.

Cena 4:

Daniel-san chega no terceiro dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda varrer o deque de madeira. De um lado para o outro. O dia todo.

Cena 5:

Daniel-san chega no quarto dia puto da cara. Quer aprender Karatê, e não ficar pintando, polindo ou varrendo. Xinga o Sr. Miyagi e diz que é tudo uma bobagem.

Cena 6:

Sr. Miyagi o manda repetir cada um dos movimentos dos três dias. E aplica golpes de Karatê em Daniel-san. Os movimentos de polimento, pintura e varredura, são os mesmos usados na defesa dos golpes. O que parecia inútil, foi o início e a pedra fundamental para Daniel-san aprender, sem saber, Karatê.

Sim, se você percebeu esse é o filme "Karatê Kid".

A famosa cena 6, em vídeo:



Qual a analogia que podemos fazer com agile? Simples.

Quantos "agilistas-san" você conhece? Aqueles que conhecem SCRUM / XP / TDD / LEAN ou qualquer outro processo ou corrente ágil, e resolve implantá-la achando que terá resultados da noite pro dia?

Quantas vezes você já ouviu donos de empresa falarem "Agora faremos SCRUM!" e obrigarem as equipes a praticarem processos ágeis, sem que eles entendam o por quê?

Para ter sucesso com qualquer processo ágil, é preciso trabalhar com calma, ponto a ponto. "Wax on, Wax off", como o Miyagi diz no filme. Entender o processo... diagnosticar problemas... melhorar a comunicação... valorizar as pessoas... fazer sua equipe entender que mudanças vão acontecer... fazê-los perceber porque reuniões diárias, taskboards, etc são benéficas... tentar criar um projeto piloto... enfim.

Se você achar que pode simplesmente implantar agile (ou aprender Karatê) apenas lendo um livro e atropelando tudo, ou você sofrerá uma grande decepção com os processos ágeis (ou levará uma grande surra!).

Agora, toda vez que algum conhecido seu se afobar com processos ágeis, peça para ele assistir ao filme Karatê Kid. Afinal de contas, é um bom divertimento também.

Um grande abraço

Scrum e XP direto das trincheiras

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sim!! O melhor livro para se aprender SCRUM agora está em português!

Leia mais aqui.

Você pode fazer download diretamente aqui.

Aproveitem. Agora não há mais desculpa!

Scrum vs. cultura da empresa

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje numa lista saiu este post do Rodrigo Lima. Achei bem pertinente e selecionei algumas respostas.

Pessoal,

Eu trabalhei um tempo atrás com Scrum, tenho um conhecimento prático grande, leio bastantes, etc. Atualmente estou num empresa que tem um forma de gerenciamento totalmente "torta".

Tem um projeto rolando, começou em setembro e com prazo pro final de dezembro. Pelo que eu to vendo o projeto está caminhando pro fracasso, a empresa tem pessoas muito boas tecnicamente, mas não tem um time de desenvolvimento. É um projeto em que a pressão por resultado está grande, cliente cobrando, pressionando, etc.

Queria saber dos mais experientes da lista se é uma boa oportunidade pra iniciar com scrum na empresa. Tenho medo que se no final der errado, a culpa seja colocada no scrum e não de tudo de errado que aconteceu no projeto anteriormente.

O que falo de dar errado é, não conseguir entregar as coisas nos prazos que já estão acordados e não podem ser redefinidos.

Qual a opinião de vocês em relação a isso?

Este tipo de mensagem é bastante recorrente nas listas. As respostas costumam ser praticamente as mesmas.

"Faça isso! Faça aquilo! Não faça isso!"

Mas uma pessoa (Fabiano Milani) postou uma mensagem que realmente trata da realidade nua e crua:

Bom, gostaria de dar a minha opiniao sobre o assunto, e deixando claro que é apenas a minha opinião e não que eu tomo ela como verdade, li todos os post do mesmo e vou fazer um comentário a respeito dos comentários.

Primeiramente gostaria de lembrar 2 pontos extremamente importantes :
1) Não podemos esquecer do fator principal que é a CULTURA DA EMPRESA, e isso meu amigo Rodrigo Lima, você melhor que ninguém que vivencia o dia a dia da empresa pode analisar e ver a real possibilidade ;
2) Levando em consideração a CULTURA da empresa podemos dizer que, não há a menor chance de funcionar a implantação na sua empresa se você tentar implantar Scrum da mesma forma que eu fiz na minha, ou o Wescley, Raony, Kerber fizeram na deles, podemos pegar algumas dicas e como cada projeto é um projeto, cada implantação do Scrum será uma também;

Infelizmente, por mais que todos nós fiquemos felizes em ajudar, temos que ter a convicção de que assim como cada projeto é um projeto, cada empresa é uma empresa. Parecidas, mas nunca iguais.

Eu tive recentemente um problema de falta de comunicação na minha empresa atual, onde todos querem implantar métodos ágeis, mas ao mesmo tempo tem algum receio de seguir em frente. E apesar de eu tentar demonstrar que a mudança seria gradual, por algum motivo demonstrei que queria fazer a mudança de forma "radical".

O que eu estou fazendo então? Por acreditar nos métodos ágeis estou buscando exercitar as práticas do agile antes de mais nada: valorizar as pessoas e a comunicação (embora já tenha ocorrido alguns problemas de comunicação - alguns até mesmo meus), focar em entregar partes do sistema funcionando em iterações, tentar a colaboração com o cliente e reagir às mudanças, ao invés de achar que tudo é imutável. E estou com a plena consciência de que estou aprendendo diariamente. Procuro tentar aprender algo de cada erro e acerto, mesmo que ainda não seja um hábito.

Tenho tido bons resultados até o momento. Tivemos um pequeno atraso de dois dias em um dos projetos devido a pessoa que está o tocando ser nova na empresa. E mesmo assim foi excelente para ele aprender o framework já do começo ao fim, e de forma iterativa... ao invés de fazer TODO site.

É importante perceber que para começar a usar o SCRUM nós temos duas maneiras de iniciar:

a) Tentando praticá-lo com a base, ou seja, com os desenvolvedores do projeto.
b) Tentando vender a idéia para nossos chefes.

Ambos os casos tem vantagens e desvantagens. Mas dependendo da cultura da empresa, um será mais benéfico do que o outro.

Então a minha sugestão é simples: avalie BEM a cultura da sua empresa. Sua equipe de desenvolvimento é resistente? Tente a abordagem com seus chefes ou busque aliados estratégicos. Seus chefes são tradicionais? Tente a abordagem com sua equipe.

Sua equipe é resistente e seu chefe é tradicional? Bom... daí você tem duas outras opções. Chutar o balde e tentar pisar nos calos das pessoas da empresa, mostrando como o agile pode ajudar (neste caso, vale muito a pena ter dados concretos, como valores) ou... sair da empresa. Mas essa última opção, sabemos que não é tão simples. Porém, sabemos que também você encontrará com certeza um mercado de empresas "ágeis" que vão recebê-lo de braços abertos.

Ultimo lembrete: lembre-se que a cultura da empresa não é aquilo que ela FALA que faz. Mas sim aquilo que ela REALMENTE É.

Dinâmica de aviões - PUCRS 2008/2 (com fotos e vídeos!)

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Como eu havia dito, no último dia 11/11 realizei novamente a convite do prof. Rafael Prikladinicki a dinâmica dos aviões em uma turma de gerenciamento de projetos da graduação da PUCRS (Sistemas de Informação).

Essa foi uma das melhores turmas que eu ministrei a dinâmica: todos, sem exceção, demonstraram enorme interesse não só na dinâmica, mas nos resultados e discussões que fizemos após. O fato é que a aula acaba as 22h30, mas eram 22h35 e eu terminava de falar e ainda TODOS estavam em sala de aula. Este é o melhor feedback que uma turma pode dar.

Se você não conhece a dinâmica, clique aqui.

Desta vez, por lição aprendida, não utilizei os cartões para definir os papéis. Isto pois quando a turma é muito grande, temos alguns problemas com um lendo o cartão do outro ou então um não se segurando e falando o que tem que fazer. Ao invés disso, o Rafael chamou um de cada equipe, discretamente, e passou a idéia desta pessoa ser o gargalo do time.

Pela primeira vez desde que comecei a aplicar a dinâmica, as TRÊS equipes produziram o protótipo bem próximo da realidade, mas claro, sempre esquecendo de alguns detalhes "pega-ratão" ;)

E felizmente, todos os erros de estimativas iniciais e as correções posteriores, ocorreram de forma ideal. Uma equipe falou que produziria muito a mais da sua capacidade (por não conhecer seu limite) e quando percebeu que não entregaria isso, reduziu a estimativa... mas nem por isso deixou de tentar superar este limite posteriormente. Ou seja, aplicaram exatamente o conceito do PDCA. Em todas as equipes o resultado foi similar, o que demonstrou que os três grupos estavam bastante maduros em relação a este ponto central da dinâmica.

E o gargalo? Ahh o gargalo. Os três gargalos das três equipes foram perfeitos. E mais perfeitos ainda foram os demais integrantes da equipe (e Scrum Master) que perceberam o gargalo e reduziram o trabalho neles. É essa a intenção: fazer a equipe perceber o problema e superá-lo de alguma forma.

Enfim, a dinâmica foi uma das melhores, na minha opinião. Os principais eventos da dinâmica para causar uma bela discussão no final do processo, aconteceram. E graças a ele eu senti que os principios do agile foram bem assimilados e bem praticados. Tomara que futuramente eu pegue turmas no mesmo nível ou, se der sorte, melhor do que esta.

Abaixo, curta algumas fotos e um vídeo desta dinâmica.

A Scrum Master corre contra atrás de matéria prima para atingir a meta da equipe.

O Scrum Master dá uma discreta conferida na equipe adversária.

Linha de produção em pleno vapor. Um membro do time fica de pé sendo elemento móvel.

Linha de produção em ação.

Linha de produção em ação.

Vista geral da sala. Três equipes.

Apresentação dos protótipos iniciais (com pouquíssimo escopo). O momento mais divertido.

Adivinhem quem é o gargalo deste time? hehe

Reunião de replanejamento de processo.

Apesar de tudo, essa foi a equipe vencedora! Não parece... mas se puxaram! :)

Planilha com as estimativas iniciais e o previsto/realizado de cada equipe, por sprint.

Aviões prontos para serem avaliados por mim ao final do sprint.

Os vídeos!

O desafio do agile

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Atualmente estou tendo pouco tempo para participar mais ativamente das listas. Porém, encontrei este tópico e achei muito interessante. Uma colega da lista teve sérios problemas em implantar o SCRUM em sua empresa. Por quê? Resistência ferrenha dos seus colegas mais antigos.

Este é um dos maiores desafios do agile: mudar a cultura das pessoas. E não pensem que é fácil. A mensagem da Lívia e as respostas dos colegas que se sucedem retratam bem essa situação:

Olá pessoal,

Já aviso que é um post negativo e triste... :(

Tentei implantar scrum onde trabalho. Após muitas palestras, leituras de livros e listas de discussão, tínhamos uma equipe motivada a usar Scrum.
Mas acho que fomos vencidos pela outra equipe, os seres que já estavam aqui antes de nós: os analistas "experientes".

Não nos deram a chance de testar, boicotaram nossas reuniões diárias, ignoraram o sprint backlog, pensaram em fazer um sistema muito além do escopo definido pelo usuário, não estudaram a metodologia e, para melhorar, fecham-se a coisas novas.

E agora estamos aqui. Após 1 mês e meio de trabalho, tínhamos planejado e estimado uma tarefa simples de criação de um cadastro, mas nem terminamos a modelagem. 1 mês e meio para realizar uma modelagem... de um cadastro...

Depois de tanto ponto negativo, pergunto-lhes: O que me resta? Sentar e chorar?

Att,
Lívia. Triste. Muito triste.

--
Lívia Silva Santos

Resposta do Antônio Carlos Zegunis Filho:

Olá, Livia!

Acho que podemos fazer algumas ponderações e quem sabe te oferecer alguma alternativa.

De qual nível da empresa partiu a idéia de utilizar Scrum? Foi do pessoal da área operacional (desenvolvedores, analistas, etc)?

Se sim, as áreas interessadas em $$$ (tática e estratégica) ficaram sabendo do objetivo da troca de metodologia? Acho válido que esse tipo de movimento parta do pessoal operacional, mas é importantissimo que quem manda na conta bancária da empresa não fique de fora, pois a idéia é que esses caras obtenham a maior parte dos benefícios oferecidos pelo Scrum que é o foco em
ROI.

Talvez uma alternativa que você tenha é em caso do pessoal da grana não estar sabendo desse tipo de movimento, preparar um pequeno estudo e fazer uma apresentação que mostre quanto $$$ potencialmente pode ser economizado com essa estratégia nova.

Uma vez que esses caras estejam convencidos e você tenha alguma liberdade pra tocar pra frente o Scrum ai você pode tentar ver se o pessoal das antigas se adapta a nova forma de trabalho ou então trocar cada um que não se adaptar.

Agora...se o pessoal que pensa em $$$ ficou sabendo e mesmo assim a coisa foi pro brejo das duas uma: ou vocês acabaram pisando na bola em um determinado ponto (talvez conversando com a gestão isso seja esclarecido) ou então o pessoal não quer economizar $$$ e sua melhor opção é de fato procurar outro lugar pra trabalhar...

Nem todas as empresas estão preparadas pra esse tipo de mudança, mesmo que só traga melhorias.

Att.,
Antonio Carlos Zegunis Filho

Resposta do Wescley Costa:

Oi Lívia... não acho que seja o momento de sentar e chorar... mas sim de repensar, reorganizar e tentar novamente, porém, da forma certa.

Faz um tempo que venho planejando usar Scrum onde trabalho, mas devido ao que aconteceu com vc, e vários artigos, pdfs, e etc que li por aí, aprendi que existe o momento e lugar certo para se fazer isso.

Na minha opinião, oq aconteceu com vc é normal, vc pode ter se precipitado, na ansiedade de começar logo não esperou o momento ideal, e nisso os tradicionais(analistas experientes) se aproveitaram da situação para derrubar sua iniciativa, e talvez o objetivo deles foi alcançado
né, pois vc já pensa em sentar e chorar, ou seja, desistir.

Quer um conselho? não dê esse gostinho a eles... analise melhor as coisas na sua empresa, molde as coisas pouco a pouco e na hora certa, tente novamente... vá incentivando todos aí que será
melhor para a empresa usar Scrum e quando todos estiverem de acordo, comece...

ou então, consiga montar uma equipe onde todos estejam realmente interessados em adotar as práticas ágeis... oq é a melhor opção. E relaxa... raramente alguem consegue o sucesso na primeira tentativa!

Att,
Wescley Costa

Resposta do Adail Retamal:

Lívia,

Enquanto não estivermos preparados para explicar, claramente:

* Por que mudar?

* O que mudar?

* Para o que mudar?

* Como causar a mudança?

não conseguiremos superar as várias camadas de resistência à mudança.

Tenho usado a TOC (Teoria das Restrições) justamente para me auxiliar nesse processo de convencimento e de transição, pois as empresas estão fartas de mudanças que não necessariamente se traduzem em melhorias. Essa resistência à mudança tem seus motivos... As pessoas não são idiotas (ok, algumas nos levam a pensar que sim)...

Veja um pouco aqui: www.heptagon.com.br/toc

Se puder ajudar em algo, pode me procurar...

Heptabraço,

Adail Muniz Retamal

Resposta do Manoel Pimentel:

Olá Lívia,

Na verdade isso é muito comum (muito mesmo), então talvez seja o caso de você rever a estratégia e tudo aquilo que os colegas da comunidade já falaram nesse tópico.

Mas, permita lhe dar só duas sugestões:

1) Leia o livro: O livro "A quinta disciplina" de Peter Senge, que além de você ver que "Quando mais você empurra, mais o sistema empurra de volta", você verá que talvez sua empresa tenha um sério problema de aprendizagem e que precisa ser resolvido, através de injeções à questões que vão além da proposta do Scrum.

2) E também é importante que você faça as seguintes perguntas:
- Por quê implantar Scrum nessa empresa?
- Existem algum problema que justifique usar Scrum nela?
- E outra, essa empresa, merece usar Scrum (eheheh)???

Grato,
Manoel Pimentel

Então a Lívia se revitalizou um pouco e explicou melhor a sua situação:

Olá pessoal,

Nossa, fiquei mais animada depois das mensagens.

Vou tentar explicar um pouco mais a minha situação. Trabalho em um hospital de clínicas de uma universidade estadual...

Situação atual (que queremos reverter): Os analistas desenvolvem aplicações pro hospital em cobol e db2, usando mainframe. Cada um é dono de um sistema, e todos torcem para ninguém sair de férias. Quando alguém sai, o sistema fica literalmente parado por 1 mês pois ninguém mais quer colocar a mão. Existem ilhas de conhecimento, não há cooperação. Não há o conceito de equipe. Ninguém gosta de expor o próprio código.

Porém, a universidade quis mudar a plataforma de desenvolvimento e escolheu java por N motivos. O primeiro desafio foi informar a mudança. Houve um choque! Passado o choque, fizeram cursos. Mais de um ano depois, ninguém desenvolveu nada na tecnologia nova por não conseguir, não entender e não ter apoio da diretoria da informática. Depois do desastre, começaram a contratar uma equipe para trabalhar com java. Eu fui a segunda pessoa a ser contratada no ano passado. A equipe já conta com 4 analistas e 1 programador novos.

A universidade também tentou utilizar o RUP, mas parece que não deu muito certo. Usaram o RUP para justificar as falhas. Por exemplo: "Fulano, por que você não perguntou isso para o cliente?"... "Ah, porque o RUP não fala que eu tenho que fazer isso!"

O problema: Unir essas duas equipes para trabalharem em projetos novos. Quando nós soubemos como eles trabalhavam, não achamos legal continuar nesse esquema. Além disso, há outro agravante: muitos analistas estão para aposentar em até 5 anos. Ou seja, o conhecimento deles tem que ser passado aos poucos para os outros. A diretoria de informática ainda não tinha pensado nisso. Ano passado, eu e outro analista novo fomos ao Java Brasil e voltamos cheios de idéias. Scrum e XP nos trouxeram um pouco de esperança por alguns motivos, tais como:

-trazer de volta o trabalho em "equipe", acabando assim com as ilhas de conhecimento (pensamos muito na programação em par e em como isso poderia nos ajudar);
-conseguir aumentar nossa produção, já que a equipe antiga demorava até 4 meses apenas levantando requisitos (e para variar, quando entregavam o produto, muito tempo depois, muita coisa tinha mudado e eles faziam os clientes aceitaram do jeito errado mesmo por medo de fazer alterações);
-melhorar o gerenciamento e fazer a diretoria do hospital entender que mesmo que trabalhemos em um órgão público, há SIM gastos e custos;
-melhorar a integração dos novos com os que já trabalhavam aqui para disseminar o conhecimento de java e para nós, os novos, aprendermos as regras do negócio que só eles sabiam...

Explicamos para a diretoria de informática, que comprou a idéia. Chegou inclusive a pagar um treinamento para dois analistas.

O problema que eu já apontei e entendi depois de ler alguns posts: realmente, houve imposição da utilização dessa metodologia. Os analistas que já trabalhavam aqui não acreditam, não apoiam e não querem usar. A diretoria pediu que nos dessem uma chance para tentar testar e ver se realmente funciona. Mas acredito que enquanto houver resistência á tentativa, nada sairá do papel.

Por mais que a gente explique para os outros analistas o que é o scrum e como ele poderia nos ajudar e facilitar nossas vidas em vários aspectos, também tentamos informar os pontos em que talvez ele não se aplique aqui. Mas esses analistas não se interessam, não estudam a metodologia, não se esforçam para fazer funcionar.

Essa modelagem do sistema novo está demorando tanto porque estão agindo como faziam antigamente: querem prever tudo o que o sistema pode ter, aumentar o escopo do projeto, demorar para definir as coisas. Nós queremos feedback, queremos que o usuário aprenda sobre o sistema enquanto o fazemos. Mas todos aqui tem medo, muito medo, de mudanças, de todos os tipos: código, conceitual, paradigma...

Ana, falei da tarefa para o cadastro, mas me enganei. Era realmente uma história. A modelagem é que era uma tarefa. Sei que com certeza erramos em vários pontos na implantação do scrum. Afinal, foi nosso primeiro, e já esperávamos ter que corrigir coisas no meio do caminho. Mas acho que aqui a gente luta por algo não tão no nível do scrum.

Estou chegando à conclusão que o problema não foi só o scrum dar errado. Talvez o problema esteja mais embaixo. :(

Obrigada a todos pelas dicas!

[]s
Lívia

O que eu posso dizer sobre isso? Mudar um processo é difícil. Conscientizar as pessoas é mais difícil ainda. Você poderá ser mal comprendido, poderá ser visto como revolucionário. E com certeza escutará coisas do tipo: "Você não conhece os processos" ou então "Isso não vai funcionar aqui... é outra realidade".

Embora o sentimento seja de desistir, temos que aprender e retomar as tentativas. E mostrar que tudo o que queremos é, na verdade, AJUDAR a empresa a se adequar ao futuro.

No meu MBA um dos meus professores falou sobre empresas orgânicas, que isto é a tendência do futuro para todas organizações de todos os tipos. A maioria dos princípios são aderentes ao do agile. Mas isso é assunto para outro post :)

Abraços

Dinâmica dos aviões

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Terça-feira, dia 11, realizei novamente a convite do professor Rafael, na disciplina de Gerência de Projetos, na PUC-RS, a dinâmica dos aviões para que o pessoal vivenciasse alguns conceitos do agile na prática.

A dinâmica foi um sucesso! Uma das melhores turmas, com certeza. Fiz algumas fotos e vídeos. Devo postá-los entre hoje e amanhã :)

Aguardem!

Por que agile é TÃO legal

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Falei da reunião, certo?

Num determinado momento nós iríamos simular alguns processos. Dessa forma saberíamos as disposições, os recursos atuais, projetos por equipe e onde faltam recursos. Logicamente, como eu já tive algumas experiências anteriores, eu sabia que uma reunião que teria tudo para se tornar monótona e sem graça, precisava de um toque especial... um toque agile.

E então eu criei cartões sobre os processos e afins. E com post-its fomos preenchendo o resto. A reunião ficou tão divertida, que um dos diretores pegou a máquina e fotografou.

Sim, eu sou o laranjão.


Agile é legal porque é VISUAL.
Quanto mais VISUAL, mais INTERATIVO.
Quando mais INTERATIVO, mais COLABORATIVO e INFORMATIVO.

Por isso que usar dinâmicas, post-its, taskboards, burndowns, planning poker, etc. é tão importante. Motiva e cativa as pessoas.

Eis ai um exemplo BEM prático :)

Colaboração do cliente

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

O agile tem quatro princípios bem "revolucionários" em sua proposta. Maximizar a comunicação, valorizar as pessoas, reagir à mudanças, software funcional e ... colaboração do cliente.

Todos estes envolvem uma mudança cultural, mas somente um deles trata de algo externo à empresa. Sim, você já adivinhou qual é.

Hoje estávamos em reunião na empresa e um colega que entrou esta semana, vindo de outra empresa, contou uma história que me deixou pensando como existem clientes que são impossíveis de serem "colaboradores".

Diz que a agência dele trabalhou na realização de um hotsite (aqueles sites promocionais) de um produto estilo "toddyinho", mas que era uma marca pouco conhecida inclusive na praça onde eles trabalhavam (região sudeste). Eles quiseram promover o produto criando um hotsite para crianças e adolescentes, que consistiria em um jogo com alguma complexidade e os vencedores ganhariam algum tipo de prêmio.

O hotsite foi um sucesso. Receberam acessos inclusive de outras regiões do Brasil, batendo a incrível marca de um milhão de acessos. Porém, como o jogo era complexo, a empresa recebeu VINTE emails reclamando do hotsite. E o cliente foi pra cima da agência dizendo que "nunca antes recebemos tantas reclamações como agora".

Vinte emails de uma população de um milhão de visitantes. Isso daria algo como 0,00002% de reclamantes. Mas como o cliente tinha um site que nunca era visitado, isso deve ter representado um aumento de 200% em suas reclamações.

Como "colaborar" com um cliente assim?

O que é dito lá no trabalho, que é bastante comum, é o cliente ter um prazo para entregar seu material para a criação dos sites. Porém eles atrasam a entrega. Só que depois vêm pra cima da agência querendo explicações dos motivos dos atrasos no cronograma, acusando a agência de ter atrasado a entrega.

Enfim, eu confesso que me assusto ao pensar que é ESSE tipo de colaboração que nós agilistas temos que conseguir. Na teoria é muito bonito. Na prática, talvez só VINTE clientes de um milhão colaborem hehe

Abração

"15 anos de casa..." e outros chavões dos chefes..

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Na sexta-feira eu e o meu colega tivemos uma reunião bem informal com o meu chefe. Estávamos discutindo sobre o novo projeto que entrou (e que o pagamento já foi feito). Discutimos sobre a equipe, perfil, valores (salários da equipe e nosso), etc. Sem se aprofundar muito, bem informal mesmo. Tanto que em seguida já estávamos falando de outros assuntos.

O que me chamou a atenção foi que por diversas vezes o meu chefe utilizou a expressão "Olha, eu tenho 15 anos de casa", também variando para "15 anos de janela" ou "15 anos vendo isso acontecer". Isso me chamou a atenção mais ainda quando ele brincou sobre as reuniões que eu estava organizando (usando o SCRUM). "Me assusto só de ver aquele monte de papel que tu usa!", foi um dos comentários.

Felizmente eu tenho a certeza que em pouco tempo ele vai começar a entender o motivo da papelada. É aquele conceito do "always visible", ou seja, escrevemos user stories em papel, criamos a taskboard física e tudo mais, exatamente pela simplicidade de acessar os dados e informações. Nada melhor do que ter tudo isso fisicamente presente ao lado da equipe. E daí fica aquela questão: valeria a pena passar tudo para o computador, e depender de que o time veja isso diariamente? Eu tenho dúvidas que isso aconteceria ("pelos meus 4 anos de casa" hehe).

Voltando a essa frase, eu comecei a pensar quantas pessoas devem possuir chefes que realmente pensam e agem dessa forma.

Eu tenho xx anos de casa, portanto...

... sei que isso não irá funcionar!
... não sei para que manter essa mudança!
... conheço todos os processos!
... acho que as coisas funcionam da forma que estão!

E assim vai.

Será isso arrogância? Auto-suficiência? Resistência à mudança? Acho que depende de chefe para chefe. O meu eu acredito que não seja nenhum desses, mas ele costuma utilizar outra frase que me deixa realmente LOUCO nas reuniões.

"Para desenvolver esse [sistema/banco de dados/tarefa/etc] eu acho que uma semana está mais do que bom".

O pior é que ele costuma falar que "Nos meus pequenos conhecimentos de banco de dados..." e dai depois termina com um "acho que o desenvolvimento dele é simples e demora 3-5 dias".

Enfim, chefe que é chefe vive de chavões. O grande problema é quando ele leva isso tudo a sério demais. E quando nós, os gerentes e colaboradores, somos efetivamente cobrados devido a esses chavões...

Enferrujado!

Eita, hoje eu vi como estou enferrujado!

Resolvi pegar o meu projeto atual e transformar todas as funcionalidades em user stories. Quando comecei a explicar para os meus dois colaboradores, eu comecei a ver como eu estava bem enferrujado devido a mais de três meses sem praticar.

O resultado foi a discussão de detalhes excessivos em alguns casos! Detalhes técnicos!!!! E no início do projeto!!!!

Quando me dei por conta, já havíamos perdido boa parte da reunião e então continuei apenas tentando listar e quebrar as funcionalidades em estórias. Deixei o detalhamento de lado. Ainda bem!

Não adianta, as técnicas de agile acabam sendo como tênis: se não praticar, a gente acaba ATÉ jogando... mas bem meia-boca! :)

Anyway, hoje recebi a notícia de que nosso projeto de pesquisa teve a parte financeira aprovada!! Ou seja, poderei começar a pensar na equipe definitiva! Aleluia!

Ah sim, essa semana vou começar a planejar a adaptação do Zoho Projects para SCRUM. Vai ser uma coisa bem adaptada, mas vai dar certo, pelo menos na teoria!

Abraços!

Sexta-feira, o dia do "yes!"

Nesta última sexta-feira aconteceu uma coisa que eu merecia (sem falsa modéstia).

Vocês que acompanham o blog sabem que eu sempre costumo expressar minhas opiniões sobre comunicação, liderança, gestão, etc. Porém, sabem também o quanto eu tenho de problemas no trabalho, devido a falta de uma cultura de projetos, principalmente.

O que estava acontecendo então? Eu me sentia aquele cara que sabe tudo na teoria, mas que nunca consegue colocar as coisas em prática. É um sentimento muito ruim, desmotivador, inclusive.

Desde que eu assumi esse "projeto" (já que me foi jogado no colo para eu "resolver") eu tive um pequeno desacerto com o meu chefe, vi meus antigos funcionários cairem fora, recebi um novo funcionário (indicação de outro chefe) e tive diversos problemas com os requisitos do projeto.

Eu estava crente que seria mais um projeto que iria para o lixo, sem chance alguma de sucesso, qualquer que fosse o meu esforço. Eu me senti como se estivesse numa competição do "Aprendiz" em que o Trump ou o Justus me jogam para a arena com uma espada de madeira para lutar com uma dezena de gladiadores e leões. Embora a analogia seja meio pobre, posso dizer que mostra o sentimento de impotência que eu estava sentindo.

Porém, algo me motivou. Inicialmente eu comecei a pensar que de nada adiantaria eu ficar em cima do muro, fazendo apenas o necessário para depois dizer "eu avisei que não ia dar certo". Eu precisava encarar isso como um desafio e fazer o que fosse possível para resolver a situação. Junto a isso, e que foi um daqueles suplementos alimentares na minha motivação, o fato do novo funcionário ser um jovem de excelente competência técnica, me mostrou que SIM eu posso obter ótimos resultados tendo uma equipe razoável e um desafio pela frente.

Nesta sexta-feira os meus dois chefes me solicitaram para ver o projeto, onde estávamos, o que havíamos feito, etc. E o que eu apresentei a eles, não apenas solucionou os problemas propostos como ainda consegui ir além.

Desenvolvemos em uma semana: um software para o celular (a melhor solução possível para um problema crítico deste projeto - que envolve um processo específico), dois sistemas de relatórios via web (para demonstrar o que podemos manipular em nível de dados), além de uma pesquisa sobre os processos envolvidos, com soluções propostas e vantagens e desvantagens. Tudo isso em um Powerpoint para ser apresentado ao cliente. O que eu fiz, basicamente, foi tentar orientar essa "demanda" em um projeto. E espero fazer isso após a reunião com o cliente.

A reação dos meus dois chefes foi daquelas de deixar qualquer subordinado animado. Eles sairam felizes! A sensação foi de que superamos as expectativas deles. Lógico que a expectativa deles também não era muito alta, pois eles sabem o histórico ali do laboratório... mas ainda assim foi uma das únicas vezes que eu vi os meus chefes realmente satisfeitos com o que viram (de cabeça, eu lembro da vez que apresentamos o antigo projeto na feira, que o meu chefe ficou muito feliz também, mas apenas um deles... o outro não estava envolvido).

Enfim, a sexta-feira foi a recompensa que eu há muito estava buscando. O resultado da minha superação em atingir um resultado e superá-lo, inclusive. Fui gerente de projetos, analista, desenvolvedor e DBA (analista de banco de dados). Não é o que eu quero que se repita - e irei deixar isso claro futuramente - mas o esforço valeu a pena.

Por pior que seja o nosso ambiente de trabalho (o meu é ruim apenas na questão organizacional, vale ressaltar) nós sempre temos um objetivo em comum: encantar nosso cliente. Seja ele o cara que compra o seu produto ou mesmo o cara que paga o seu salário. Nada melhor do que atingir isso.

A lição que dá pra tirar disso é: se você está desmotivado, busque motivação. Se você quer passar uma mensagem, a melhor forma de fazer isso é motivado, atingindo um bom resultado... e depois apresentar uma forma alternativa de superar aquilo. Nenhum chefe vai dar atenção a alguém que falha (para depois dizer "eu avisei") e se demonstra desmotivado. Porém, se você tiver os holofotes por algo bom que tenha feito, sua mensagem será potencializada. Tenha a certeza disso.

Sexta-feira: o dia em que eu esperei por um bom tempo chegou. E o seu? Lute para que ele chegue o mais cedo possível.

Apresentação: Essência de Gerenciamento de Projetos

Prezados,

conforme eu havia prometido, aqui está o pdf com a apresentação que eu fiz na turma de gerenciamento de projetos, na turma de graduação da PUCRS, no dia 19/08.

Foi muito legal a apresentação. A receptividade da turma foi excelente. Eu estourei bastante o tempo e ainda assim notei muita gente interessada na palestra. Essa é a força de trazer "cases" e situações para nossas palestras, além de ser um pouco teatral também :)

Também consegui trazer uma visão "agilista" de gerenciamento de projetos, sem ser radical ou aparentar fazer "lavagem cerebral". Acho que essa abordagem também foi bastante eficiente.

Faça o download aqui

Ah, e sempre reforço que no icone do menu direito (seção de downloads) você pode baixar as outras apresentações além dos podcasts, videos, documentos, artigos, etc. Faça bom proveito.

Dinâmica: fábrica de aviões versão 2.0

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal, com atraso estou publicando para vocês a dinâmica da fábrica de aviões que apliquei na turma de "Especialização em gerenciamento de projetos" na PUCRS. A idéia da dinâmica é vivenciar os conceitos do SCRUM, de forma prática, facilitando a visualização dos benefícios. Usamos bastante o conceito PDCA e processos empíricos, que são algumas das bases do SCRUM.

Esta dinâmica foi desenvolvida com base na primeira versão, só que agora ela se tornou mais "ágil" e divertida. Por quê? Inseri algumas novas variáveis e situações que tornam ela mais aderente ao que desejamos passar, ou seja, o conceito do SCRUM.

Para acompanhar este post, é legal você primeiro baixá-la no link abaixo.

Baixar a dinâmica (PDF)
Baixar a tabela em excel (XLS)
Baixar as fichas de responsabilidades (PPT)

Qual a essência da dinâmica? Criar uma linha de produção de aviões de papel que segue uma regra bem simples: a folha de papel começa numa ponta e "termina" avião na outra ponta. Na dinâmica que eu apliquei, foram 3 equipes com 7 membros cada. Se você tiver mais gente envolvida, tente manter no máximo 4 equipes com os membros necessários. Assim você consegue fazer o papel de Product Owner, avaliando o que foi produzido. Crie nomes do alfabeto grego para as equipes (no meu caso foram Sigma, Omega e Gama. Você já verão o por quê disso.

Avise as equipes que a forma como eles se organizarão para fazer a engenharia é com eles. Se quiserem ficar de pé, organizar as mesas em círculos, etc. é problema deles. DESDE QUE o produto comece numa ponta e acabe na outra. Além disso, a outra restrição é que não pode haver estocagem de material, ou seja, cada grupo só pode pegar mais 10 folhas quando a última folha entrar em produção. Isso existe só para tornar o processo mais difícil e para dar trabalho ao Scrum Master, na hora dos sprints :)

A estrutura da dinâmica é simples: as equipes tem três minutos para discutir o processo (retospectiva e planejamento) e ao final do tempo passam a estimativa de produção. Depois elas tem três minutos para produzir o que prometeram, conforme as definições do escopo solicitadas. E assim por diante (ciclo PDCA).

Neste primeiro momento, os papéis não existem ainda. O cliente fictício é a Força Aérea. É informado que a organização quer um novo avião e entrou em contato com as empresas deles. Então a organização quer saber das equipes quantos aviões eles produzem em três minutos. E eles tem UM minuto para dar a estimativa.

Isso mesmo, curto e grosso assim. Qual a idéia por trás? Quantas vezes nossos clientes e chefes chegam para nós: "Quanto tempo a gente entrega um sistema de cadastro e relatórios para o cliente XYZ?". "Bem... depende, como é o escopo?". "Escopo? É um sistema de cadastro e relatórios!! Quanto tempo?". Notaram a semelhança? É exatamente essa. Dar uma estimativa de algo que não se tem a menor idéia. No fim da dinâmica, na retrospectiva, isso serve para avaliar como as estimativas melhoram quando a equipe trabalha e conhece sua capacidade.

Enquanto as equipes fazem as estimativas, abra a planilha Excel para fazer o controle do "previsto / realizado". E marque ali assim que eles derem as estimativas.

Continuando, passe para eles que a Força Aérea gostou das estimativas. E vai abrir concorrência. Agora, a organização passou o escopo do avião. Com base no escopo, as equipes terão 3 minutos para produzir um protótipo. O escopo é bem simples:

- O avião deve possuir 12 janelas
- Deve possuir uma cabine
- Deve possuir o logotipo da empresa que está produzindo, nas asas e na cauda (o logotipo tem que ser o símbolo do Sigma, Gama, Omega - aqui é outra pegadinha!)

Note que não é dito "que tipo de avião" deve ser produzido. A idéia é mesmo que as equipes quebrem a cara na hora de apresentar o protótipo. Esse é o momento mais divertido da dinâmica. Se as equipes perguntarem algo mais sobre o escopo, diga que você não sabe... a organização não passou mais informações.

Cuidado para não passar o próximo slide, onde tem o projeto que a Força Aérea quer. Esse slide é para depois das apresentações!!

Após a produção, peça para um de cada equipe vir até a frente e apresentar o avião. No final, faça o teste do vôo. Não esqueça de solicitar os aplausos para cada apresentação :)

Depois das apresentações, passe o feedback de cada avião. Compare os protótipos com a idéia do que o cliente queria (o slide que mostra isso). Uma coisa que quase nenhuma equipe coloca é PORTA. Pergunte: "Como o pessoal vai entrar no avião???". Se eles reclamarem que isso não foi dito no escopo, fale: "Mas precisava dizer?!". Aqui é a velha demonstração das expectativas do cliente versus produção. :)

Pronto. Agora eles já sabem o que deve ser produzido. Então as linhas de produção vão começar. Diga que eles terão 3 minutos para avaliar a engenharia que irão utilizar para o processo e ao final, passarão a estimativa de produção. Eles deverão produzir os aviões criteriosamente conforme o escopo passado. Aqueles que, ao final dos três minutos do sprint, não estiverem de acordo (faltou uma janelinha, faltou o logotipo correto, etc) não contam como finalizados, mas podem voltar para a linha de produção para serem finalizados. Essa regra é importante e segue os princípios do SCRUM.

Antes de começar, porém, é preciso definir os papéis. Utilize as fichas que estão ali em cima para download (imprima mais fichas "membro da equipe"). Diga que você irá passar para cada um dos membros das equipes uma ficha contendo o papel deles na equipe. Invente que as equipes serão multi-funcionais e cada um terá um papel para desempenhar. Diga que eles devem ler a ficha e atuar conforme está escrito ali e não devem comentar com ninguém quais são suas atribuições.

Por que dessa cena toda? Porque os papéis nas equipes são: SCRUM MASTER (não pode produzir, deve cuidar do time, avaliar o processo, remover impedimentos e buscar matéria-prima), MEMBRO DO TIME (produzirá o produto e avaliará o processo) e ... ELO FRACO.

Cada equipe tem UM Scrum Master e UM Elo Fraco (se você quiser colocar dois por equipe, dependendo do tamanho, é uma idéia interessante também). O Elo Fraco tem como função principal ser exatamente a pessoa que atrasa o processo todo. Aquele cara descompromissado, que destoa dos demais. É o gargalo do time. Mas ele participará do time como se quisesse melhorar o processo (dará sugestões, etc), mas na produção será sempre o gargalo. Ele tem que ser um bom ator e não pode deixar ninguém saber que ele está atuando assim, dai a importância de deixar claro que ninguém pode ler a ficha do outro (se possível, recolha as fichas após eles lerem).

Sabendo disso, diga que o SCRUM MASTER deverá sair da linha de produção e ficar de pé, auxiliando o time nas suas funções. Ele, lógico, pode dizer o que pode ou não fazer.

Feito isso, as regras estão expostas, o escopo é sabido e os papéis e responsabilidades são conhecidos. Dê o start para que eles comecem a planejar o processo e ao final passar a estimativa.

Uma sugestão que causa um efeito psicológico bacana: Durante esses períodos de planejamento, controle o tempo e passe para eles quanto tempo falta para encerrar. Mas nos sprints não avise o tempo, só diga quando encerrou. A idéia é que o Scrum Master ou a equipe percebam que eles que tem que controlar o tempo.

Ao final do planejamento, eles começam os sprints de 3 minutos. Repita daí o processo de "planejamento/estimativa 3 minutos" e "sprint 3 minutos". São três sprints (um número ideal para ninguém cansar ou encher o saco!).

Quando as equipes passarem as estimativas, marque na planilha Excel, na coluna "previsto". Quando você fizer a contagem dos produtos finalizados (que devem estar totalmente de acordo com o escopo) marque na outra coluna "realizado". Assim até acabarem os sprints.

Ao final do terceiro sprint, veja qual foi a equipe vencedora (a que entregou o maior número de produtos). Entregue algum prêmio, como uma caixa de "Bis" para motivá-los :)

Encerrada a dinâmica, avalie com o pessoal como foi o processo. Revele os papéis "obscuros" que existiam nas equipes (os elos fracos) e questione se a equipe havia percebido isso e se tomaram alguma atitude para contornar o problema. Avalie a questão do protótipo versus expectativa do cliente... a questão do trabalho em equipe... a identificação do limite de produção da equipe... o desafio de superar esse limite... a questão do empowerment (onde os membros da equipe avaliavam o processo e tinham poder de sugerir mudanças)... os benefícios da inspeção e adaptação com base na experiência... e encerre comentando a idéia de usar sprints de trabalho.

Faça a pergunta que contém no slide: "Seria melhor entregar todos os aviões em 10 minutos ou % deles a cada 3 minutos?". Dificilmente alguém dirá que o ideal será a primeira opção. Lembre da teoria do estudante (deixar tudo para a última hora), a motivação que será alta nos primeiros minutos e depois cairá com o tempo (afetando a produção).

Antes de terminar, abra a segunda aba da planilha Excel, onde tem o gráfico baseado nas estimativas passadas. Demonstre que o primeiro ponto representa a estimativa quando eles não sabiam NADA do que tinha que ser feito (quando a Força Aérea pediu estimativa sem passar nada). As outras estimativas já foram com base na experiência e no conhecimento do escopo. Possivelmente você terá um gráfico que começa mais alto ou baixo e que depois tende a ficar parecido com uma reta, estabilizando. A idéia é que a gente erra nas estimativas iniciais em +400% e -20%, normalmente. E com o tempo, conhecendo o escopo e nossos limites de produção, as estimativas tendem a ser mais próximas à realidade e tendem a estabilizar. Comente que se houvessem novas sprints, o gráfico se estabilizaria de vez, cabendo à equipe e ao Scrum Master a idéia de tentar encontrar soluções para superar aos poucos estes limites.

Por exemplo, se as equipes produzissem 15 aviões no máximo, o que eles teriam que fazer para otimizar o processo para produzirem 17-18? E assim sucessivamente, quando conseguissem atingir os resultados.

Por fim conclua, demonstrando que eles vivenciaram a essência do SCRUM, ou seja, um ciclo PDCA onde eles planejaram o que fariam, realizavam as tarefas, checavam e avaliavam o processo e por fim tomavam decisões de mudança com base nisso, para alimentar o planejamento.

Termine desafiando: "E se usássemos isso na produção de um software?". Aí é discussão para não acabar mais :)

Ufa! Apesar deste texto longo, eu tenho certeza que você conseguirá aplicar essa dinâmica com o mesmo sucesso que eu tive ao aplicar na turma de especialização em gerenciamento de projetos, na PUCRS. Ali foi muito bacana. Os momentos mais divertidos foram na prototipação e durante os sprints (tive a sorte de escolher bem quem seriam os elos fracos - que foram excelentes atores!).

Ao final da dinâmica, todos entenderam a essência do SCRUM. A mensagem foi passada com total sucesso e tenho a certeza que abriu um novo horizonte para aqueles que não conheciam essas práticas.

Use essa dinâmica como um reforço para passar a mensagem do SCRUM ou mesmo para vender a idéia para sua diretoria. Apesar do pretexto bobo (criar aviões de papel) tenha a certeza de que ao final todos vão ficar bastante satisfeitos com o resultado.

Peço encarecidamente que, quem for aplicar a dinâmica, me envie um email contando como foi a experiência :)

Um grande abraço e façam bom uso!

Dinâmica 2.0

Pessoal, ainda hoje eu publico pra vocês a dinâmica "Fábrica de aviões 2.0" que é uma versão bem melhor da dinâmica que eu havia criado anteriormente, para vivenciar SCRUM.

Introduzi algumas variáveis e situações bacanas, que tornam a dinâmica mais "ágil" e divertida.

Vão gostar :)

Abraços

Ótima notícia para a comunidade de SCRUM

O grande Henrik Kniberg, autor do excelente livro prático de SCRUM "SCRUM and XP from the trenches" (baixe aqui) divulgou em seu blog que uma versão do livro em português está a caminho.

Os brasileiros que tem dificuldade com inglês possuiam pouquíssimo material de apoio no assunto, e agora teremos um bem bacana. O livro é sem dúvida alguma um dos melhores sobre SCRUM que existem, pois basicamente ele passa a visão prática dele. O subtítulo é "How we do scrum", ou seja, "como usamos o scrum".

Se você quer começar a utilizar, siga os processos propostos pelo Henrik e adapte com a necessidade à sua empresa.

Enfim, a tradução do livro é uma excelente notícia para todos.

Post original.

Abraços!

PMBOK x Agile

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Bem interessante a comparação entre o PMBoK e os métodos ágeis (SCRUM, XP, etc). Discordo de um ou outro conceito, mas a essência é essa :)
Tirei do blog do Abu.

Desenvolvimento incremental x iterativo

Um exemplo prático :)

[Editado: resolvi colocar a explicação do Abu, que é muito boa]

Quando eu era mais novo e possuía uma empresa de desenvolvimento de software, eu costumava ir ate o cliente, fazer o levantamento de requisitos, o entendimento de cada requisito, prototipação das telas, rascunho do banco de dados, etc etc etc. Minhas atividades tinha o objetivo de sair com todas as informações necessárias para a construção do sistema inteiro (quando ele era pequeno) ou de alguns módulos (quando o sistema tinha um porte maior).
Mas este trabalho tinha o foco de garantir que a minha entrega não teria retrabalho, isto é, após eu entregar o sistema o cliente estaria satisfeito e eu receberia a minha recompensa ($$$).
O problema desta técnica é que ela exigia do cliente uma visão muito assertiva do que ele realmente desejava, mas nem sempre o cliente tinha total informação e visão do que ele desejava de sistema.
O cliente passava a ter uma noção do que ele realmente queria quando estava utilizando o software e desta maneira ele passava a gerar solicitações de mudança.
O sistema nem tinha nascido direito e já estava com solicitações de modificação, e vinha a minha pergunta, onde eu errei na analise ou o cliente não sabe o que deseja.
Este modelo de desenvolvimento de software é o que se chama de “Incremental”.
Já no desenho de baixo é mostrada a pintura de forma “Iterativa”, onde as definições dos requisitos são realizadas junto com o desenvolvimento do software. Nesta técnica não quer dizer que nos não sabemos do que se trata o sistema e passamos a descobrir no decorrer do desenvolvimento. Vocês podem observar que o esboço da pintura já existia, isto é, “ESCOPO INICIAL”.
Mas os detalhes de cada item do sistema são definidos conforme o sistema vai sendo desenvolvido, isto é, a pintura tem que ter olhos e dois olhos, porem a cor de cada olho e os seus detalhes serão definidos no decorrer do desenvolvimento.
A pintura tem que ter boca, mas se ela vai sorrir ou vai ficar seria, é uma opção definida no decorrer da execução da pintura. Desta maneira podemos ate mesmo tentar qual fica melhor, sorrindo ou serio.
A diferença entre as duas técnicas esta no fato do cliente saber tudo o que ele deseja com o mínimo dos detalhes desde o inicio do projeto (Incremental) ou ir colocando os detalhes na execução do projeto (Iterativo).
Ambas as técnicas podem levar ao resultado final, sim, podem, porem devemos lembrar que os requisitos (Itens de Backlog) sempre mudam, a questão é como vamos trabalhar com esta mudança. Na técnica Iterativa nos conseguimos absolver as mudanças com um impacto menor, pois esta técnica já é feita para se trabalhar com as mudanças.

Extraído do blog do Abu

Retrospectiva do projeto (lições e prática)

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Conforme dito, vou passar aqui alguns itens citados na retrospectiva do meu projeto.

A retrospectiva abrangiu o projeto como um todo (2 anos) e infelizmente não pôde contar com todos os envolvidos (faltou o chefe/cliente e um membro da equipe).


Apresentação


O processo da retrospectiva foi realizado em dois momentos. No primeiro momento, uma linha do tempo que abrangia todo o projeto foi desenhada. A partir disso, foram sendo citados os eventos que ocorreram durante o projeto, numa espécie de brainstorming. Estes eventos eram colocados em ordem da data em que aproximadamente ocorreram.

Após este levantamento, alguns eventos foram excluídos por serem “duplicatas” ou então por serem conseqüências de alguns itens citados.

O segundo momento foi a divisão entre o que foi bom e o que não foi legal no projeto, e a classificação de cada um dos eventos nesse quadro comparativo. Para cada evento também eram analisados alguns fatos, como comentários sobre o evento, causas e conseqüências. Alguns eventos também foram discutidos pela equipe, apenas como relembrança.

Ambos os processos foram fotografados para posterior documentação. Este documento apresenta estes eventos classificados em “o que poderia ter sido melhor” e “o que foi bom”, com comentários do autor do documento (Flávio, gerente do projeto). Alguns outros itens foram incluídos pelo gerente posteriormente.

A figura abaixo demonstra a organização da retrospectiva.

Este post pode (e deve) ser usado como referência para futuras tomadas de decisão, sendo um excelente repositório de lições aprendidas na prática. Use-o para refletir se suas decisões e atitudes podem ou não causar os mesmos estragos ou oportunidades aqui descritos.

--------------------------

O que poderia ter sido melhor

• Utilização do conceito Waterfall, como engenharia. A utilização do waterfall (concepção, análise, desenvolvimento e finalização) se mostrou bastante inútil para nosso projeto. Houve uma perda de tempo enorme uma vez que o desenvolvimento já poderia ter sido iniciado muito anteriormente.
• A não utilização do Wiki como ferramenta. A idéia do Wiki como repositório de conhecimento foi muito boa. A ferramenta é fácil de usar e bastante simples. Infelizmente não houve uma cultura (e cobrança) para que o uso fosse disseminado.
• Muito tempo na fase de concepção. Seguindo o modelo Waterfall, a equipe acabou levando muito tempo na fase de concepção. Houve muita desorganização, apesar do documento de concepção ser bem completo (e boa parte estar defasada já).
• Equipe muito grande. Houve muita desorganização no começo. O projeto começou inicialmente com 8 desenvolvedores, um gerente e um coordenador. Ficou evidente que o ideal seria uma equipe com 4 desenvolvedores no máximo (finalizamos com 3).
• Software poderia ter iniciado logo depois da concepção. Perdeu-se muito tempo para modularizar e definir de fato o software embarcado, uma vez que tivemos muito foco no hardware. Posteriormente ficou evidente que pelo menos dois ou três módulos poderiam ter sido iniciados logo após a concepção.
• Utilização do Status Report semanal. O documento, apesar de boa intenção para identificar as tarefas realizadas pela equipe, se mostrou bastante burocrático e ineficaz. Boa parte do resultado que desejava se atingir com ele, poderia ter sido feito com mais reuniões e com a cobrança da gerência.
• Escopo muito solto. Por muito tempo o projeto teve um escopo muito “solto”, ou seja, não se sabia ao certo o que iríamos produzir. Isso custou tempo, foco e afetou a produtividade. Deveria ter havido mais cobrança junto ao cliente para formalizar o escopo.
• Tentativa de utilização de um TCC como hardware do projeto. Perdeu-se algum tempo com a idéia de usar como placa-mãe um trabalho de TCC de alunos. A idéia era muito boa, mas mostrou-se ineficiente (já que os alunos pediram um valor altíssimo pelo projeto).
• Falta de datas (deadlines). Por diversas vezes a equipe sentiu a necessidade de vislumbrar uma data final para a realização de alguma atividade. Faltou cobrança e planejamento, muito devido ao escopo “solto”. Isso acabou levando a equipe a também se comportar de forma mais “solta”.
• Curso extraprojeto com membros da equipe. O curso, além de ser muito ruim – na opinião dos dois – ainda demandou que dois membros da equipe saíssem por alguns dias do projeto para aprenderem sobre uma tecnologia que nada agregaria ao projeto. Além disso, o projeto em que seria usado o que foi aprendido no curso, acabou sendo abandonado.
• Documentação do projeto. Por diversas vezes a equipe foi cobrada para realizar a documentação do projeto. O documento foi desenvolvido, mas sempre foi desaprovado pelo cliente. Infelizmente faltou, por muitas vezes, um norte para que a equipe desenvolvesse o que o cliente queria (lhes foi dito que a documentação deveria permitir que até mesmo uma empregada pudesse montar o sistema). A falta de norte também levou a produção de uma documentação acadêmica e desnecessária, que não agregariam nada ao projeto em si. Perderam-se meses nesta documentação, levando a desmotivação de todos (equipe e cliente). Por diversas vezes a aprovação da documentação ficou pendente por muito tempo, levando todos a questionar se essa documentação era realmente importante.
• Falta de definição de papéis. O coordenador do projeto trabalhou no projeto como coordenador, especialista e cliente. Isso confundiu bastante a equipe e o próprio coordenador, por diversas vezes.
• Coordenador segurou as compras durante o desenvolvimento. Apesar de ter sido uma ótima decisão no início do projeto, a insistência na decisão de só comprar os componentes após a documentação ter sido finalizada acabou atrasando bastante o projeto, uma vez que a documentação foi problemática (conforme citado anteriormente). Alguns módulos e ferramentas poderiam ter sido adquiridos para o início da produção. Essa falta de materiais “tangíveis” do projeto, gerou um pouco de desmotivação no projeto.
• Falta de aproximação do coordenador com a equipe. Por ser o especialista do projeto, poderia ter tido uma participação mais efetiva no projeto, onde algumas coisas poderiam ter sido agilizadas.
• Reuniões sem agenda. Diversas reuniões foram realizadas sem uma agenda para ser seguida, o que levou a falta de foco e decisões.
• Reuniões de acompanhamento e de escopo. Por diversas vezes as reuniões de acompanhamento (onde também eram discutidas algumas idéias de escopo) foram muito problemáticas. Por um período grande, o cliente decidia por uma funcionalidade ou componente, para na outra semana desistir. Ou então sugeria algumas funcionalidades interessantes, mas que fugiriam do real objetivo do projeto (ex: capacete 3D!). A desmotivação de ambas as partes, ao final das reuniões, era visível.
• Mudança da empresa para o laboratório. Essa decisão foi bastante criticada por todos os integrantes da equipe. Na empresa, a equipe mantinha-se mais focada e produtiva. No período ainda estava sendo implantado o SCRUM, o que causou uma grande mudança no projeto. A mudança para o laboratório reduziu muito a concentração, foco, comprometimento e a produtividade da equipe. Isso foi dito pelos próprios.
• Comunicação ineficaz. A comunicação foi sempre um problema no projeto. Diversas decisões eram tomadas sem que os envolvidos tivessem conhecimento. Recursos específicos do projeto eram solicitados para outros projetos, decisões de escopo eram tomadas sem consulta a equipe e gerência, poucos sabiam ao certo o que o outro deveria fazer, papéis e responsabilidades eram incertos. A comunicação foi bastante maximizada com a utilização do SCRUM, isto sendo bastante evidenciado pela equipe.
• Mau uso de alguns recursos. Por diversas vezes ocorreu um mau uso dos recursos do projeto. Financeiramente falando, o projeto poderia ter sido mais bem planejado e executado (algumas compras foram feitas na correria, devido aos prazos). Também ocorreram situações onde recursos do projeto (materiais e humanos) foram usados em outros projetos, com perda de foco e tempo. Além disso, a equipe poderia ter utilizado com mais responsabilidade alguns recursos do projeto, como ocorreu no caso onde o Valter, por acidente, formatou o seu “home” do computador. Não ocorreu uma perda crítica de conhecimento, porém o tempo para restaurar isso foi bastante grande para a situação em que o projeto se encontrava.
• Aumento dos salários como motivação. Isso foi uma lição aprendida na prática, embora pudesse ter sido evitada. O aumento dos salários, que foi usado como questão motivacional, não surtiu o efeito desejado. Em um projeto como o Agritec, o impacto só foi sentido devido ao atraso no cronograma. Porém, deve-se evitar isso. A motivação se dará por diversos outros fatores como técnicas de empowerment, feedback, etc.
• O projeto em segundo plano, em algumas vezes. Por diversas vezes, mesmo com alguns prazos apertados, a equipe decidiu por dar prioridade aos estudos e a questões pessoais em detrimento ao projeto. Isso gerou por um período, um certo mal estar, mas por pelo menos uma vez, um feedback da gerência foi suficiente para a retomada. Porém, o sentimento de que “poderia ter havido maior comprometimento” ficou evidente.

O que foi bom

• O coordenador segurou as compras no início. A decisão de segurar as compras no início do projeto, indo contra a ansiedade da equipe, foi excelente. Diversos componentes solicitados, na época, se mostraram inúteis no projeto, o que seria um gasto desnecessário.
• Saída de alguns membros da equipe. Alguns membros da equipe (não terão os nomes citados) reduziram os conflitos dentro do projeto, o que melhorou o foco e a cumplicidade.
• Mudança do laboratório (antigo) para a empresa. A mudança para a empresa possibilitou a equipe sentar junto. A comunicação melhorou e o comprometimento também, apesar de algumas ressalvas no período “pré-SCRUM”. O ambiente de trabalho melhorou consideravelmente.
• Reunião semanal de pesquisa. Uma reunião semanal, no início do projeto, foi uma idéia válida para alinhar a pesquisa de todos. Infelizmente algumas pessoas não levavam a sério, o que tornava esta reunião apenas uma burocracia. A idéia foi melhorada posteriormente.
• Mudança do foco (não produzir o GPS). A idéia inicial de produzir um GPS felizmente foi abortada. Dificilmente teríamos uma precisão decente para o projeto. A idéia foi abortada logo, o que evitou a perda desnecessária de tempo.
• Produção do documento de concepção. Embora tenha sido detalhado demais, o documento possibilitou naquele momento a consolidação da pesquisa inicial realizada. Além disso, serviu como nivelamento para possíveis novos integrantes. De ruim, apenas o tempo que se levou produzindo o mesmo e também o caráter “completo” que ele possuía, com muitas informações que não seriam aplicáveis com o tempo.
• Feedback aplicado na parte inicial do projeto. Infelizmente por apenas uma vez, o Flávio e o coordenador realizaram um feedback com a equipe. A idéia foi de entrevistar cada membro da equipe para identificar problemas e necessidades que a equipe enfrentava. Foi interessante e útil para identificar conflitos, até então não conhecidos. A idéia de usar o feedback foi elogiada pela equipe.
• Primeira versão do SCRUM. A implantação do SCRUM pelo Flávio teve um impacto extremamente positivo. Ficou muito mais claro para todos quais eram suas responsabilidades, quem estava sub ou super alocado, a comunicação melhorou muito e a freqüência também. A primeira versão do SCRUM foi uma versão adaptada (que não é exatamente como deveria ser o SCRUM) com uma taskboard onde havia nomes (linhas) e situação da tarefa (colunas). Reuniões diárias e retrospectivas foram utilizadas com sucesso (veja abaixo).
• Reuniões diárias. As reuniões diárias foram uma das grandes mudanças que ocorreram para maximizar a comunicação do projeto. Através das três perguntas que cada pessoa da empresa respondia (na 1ª versão, inclusive os não integrantes do projeto) que eram “O que você fez ontem? O que pretende fazer para hoje? Quais seus impedimentos?” possibilitou criar cumplicidade na equipe e também a realidade de todos saberem o que o colega ao lado estaria fazendo. A implantação de um horário fixo para a reunião, no início dos trabalhos, fez com que a freqüência passasse a ser muito maior, evitando o “trabalho em casa”. Foi possível identificar alguns focos de problemas também, que foram resolvidos com o tempo. Além disso, segundo a própria equipe, as reuniões melhoraram a cobrança interna entre eles.
• Descontração no ambiente de trabalho. O “carro-chefe” desse item é o cofrinho em forma de porco, que foi comprado com a idéia de que quem chegasse atrasado nas reuniões pagaria 50 centavos ao porco. O dinheiro, no final do mês, era revertido na compra de comes e bebes para uma confraternização e retrospectiva do projeto (que ocorreu muito pouco, apenas duas vezes). O porco serviu para deixar o ambiente mais leve e divertido, e contribuiu muito para manter a moral da equipe elevada. Deve-se estudar para buscar alternativas!
• Retrospectivas. As primeiras retrospectivas foram importantíssimas para avaliar a situação do projeto, seja em relação ao escopo, cronograma e processos, seja em relação a equipe, comunicação e infra-estrutura. Logo na primeira retrospectiva foi evidenciado que a infra-estrutura da empresa, para a produção do projeto, era quase nula. Faltavam ferramentas e materiais simples (como canetas para o quadro branco). Também foi possível identificar as necessidades das equipes (descontentamentos, por exemplo) às necessidades do projeto, sempre que possível. As retrospectivas, posteriormente, acabaram ERRÔNEAMENTE ficando em segundo plano. Mas a última, que avaliou o projeto e gerou este documento, foi muito bem sucedida.
• Melhora na infra-estrutura. Este era um dos maiores problemas do projeto: a falta de material e ferramentas para a realização de diversas tarefas. Por muito tempo, por exemplo, ocorreu uma improvisação absurda com a utilização de canivete suíço e até moedas, como chave de fenda. A partir da primeira reunião de retrospectiva onde isso ficou evidente, o Flávio solicitou a equipe que levantassem tudo o que precisaria para o projeto. Após a listagem completa, deliberadamente foi com um membro da equipe até uma loja especializada onde comprou todos os itens da lista. De um dia para o outro a empresa possuía ferramentas para o projeto (e outros também). Isso ocorreu por diversas outras vezes. Talvez não tenha sido a forma ideal (pode-se ter gasto a mais em alguns itens – o ideal seria pesquisar preços), mas naquela situação específica a mudança precisava ser rápida. E o resultado foi excelente.
• Visita do pessoal da agricultura (clientes finais). A possibilidade de conversar diretamente com os usuários finais do projeto fez com que fosse possível ter uma visão bem mais próxima da real necessidade do projeto. O escopo foi priorizado e modificado para atender ao máximo as necessidades dos agricultores. Ter uma aproximação junto aos usuários finais é sempre uma excelente idéia para agregar aos projetos. Graças à visita foi possível identificar que as trajetórias retilíneas não poderiam atender as necessidades deles. Essa informação possibilitou a abertura do escopo para trajetórias curvilíneas.
• Visita à Empresa Especializada no assunto. Assim como no caso do pessoal da agricultura, a empresa especializada foi uma grande parceira no projeto, trazendo idéias inovadoras que o produto poderia possuir. A maioria acabou não podendo ser implantada, mas possibilitaram a citação como funcionalidades futuras, dando um caráter inovador ao produto.
• 2ª versão do SCRUM. A implantação da segunda versão do SCRUM, agora mais aderente a prática real, tornou o processo mais auto-suficiente e seguro. Algumas técnicas novas foram aplicadas e garantiram excelentes resultados.
• Planning Poker. Essa foi uma das técnicas que foram utilizadas na 2ª versão do SCRUM. Foi usada apenas uma vez, mas possibilitou a visualização por parte da equipe e do cliente de como os dois pensamentos da complexidade do projeto estavam distantes. A maioria das funcionalidades era tida como “simples” pelo cliente e como “difíceis” pela equipe. Essa técnica auxiliou o cliente a desistir de algumas idéias e funcionalidades para a versão inicial do projeto.
• Finalização do 1º protótipo do painel. A realização deste primeiro protótipo começou a ser definida com a melhora na infra-estrutura do projeto. Foi um grande marco no projeto ter esse protótipo funcionando, pois evidenciou que estávamos no caminho certo e que toda pesquisa não havia sido em vão. A necessidade de ter algo tangível em um projeto ficou claramente exposta aqui. Além disso, possibilitou a realização dos primeiros testes reais.
• Contato com empresas para solução Kalman. O contato com empresas especializadas, em forma de parceria, possibilitou o abandono da idéia de usar a tecnologia de Kalman no projeto o que, segundo os próprios donos da empresa, era inviável devido ao alto custo e complexidade.
• Uso do Doxygen como documentação de software. A utilização do sistema “Doxygen” para documentar o software do projeto foi muito boa. O sistema gera uma documentação com base nas funções e comentários direto no código, o que facilitou muito a manutenção do projeto. Ele também acabou forçando a equipe a comentar muito o código, o que tornou um código que seria bastante complexo em algo um pouco mais “tragável”.
• Mudanças internas no laboratórioA mudança de alguns mestrandos de dentro do laboratório para fora tornou o ambiente um pouco mais favorável à concentração. Infelizmente, segundo a equipe, ainda não está o ideal.
• O sucesso da feira que apresentou o produto. A realização de um evento como marco no projeto, como foi a feira realizada no início de Julho/08 se mostrou como uma excelente forma de motivar o time a atingir o resultado. O bom planejamento que foi realizado para o dia, com a finalização do protótipo físico (para demonstração), a criação de um programa que simulava o projeto, textos e banners informativos e um vídeo demonstrando todo o processo de criação tornou o projeto um dos mais bem planejados e representados na feira, sendo bastante elogiado pelos avaliadores.
• O comprometimento com a deadline, pela equipe. Nos dias finais que antecederam a feira citada acima, a equipe não se preocupou em trabalhar inclusive à noite e sábados e domingos para entregar o projeto funcional. Isso demonstrou uma capacidade de comprometimento da equipe, com o projeto, que deveria ser um exemplo. A decisão de fazer isso partiu da própria equipe. Muito embora por diversas vezes o projeto tenha ficado em segundo plano (devido a situações pessoais e de estudos), essa demonstração de comprometimento demonstrou como um projeto pode deixar de ser apenas trabalho para se tornar parte da realização pessoal de uma equipe.

Conclusão

Apesar de esta retrospectiva ter sido realizada pelo gerente do projeto e por dois membros da equipe, com a ausência do coordenador e de outro membro, ficou demonstrada a importância da realização de uma retrospectiva para analisar o projeto durante um período. Diversas questões problemáticas poderiam ter sido solucionadas se fossem identificadas mais rapidamente. E diversas questões benéficas poderiam ter sido potencializadas se tivessem sido percebidas com mais antecedência.

Para os próximos projetos as retrospectivas devem ser feitas mais frequentemente e, além disso, as lições relevantes devem ser documentadas e divulgadas para as demais equipes. Algumas lições poderão auxiliar a todos a atingirem um padrão de processo, além de evitar erros comuns que já possam ter sido cometidos por outras equipes.

Neste processo de retrospectiva do projeto poderia ter identificado planos de ação para os problemas levantados, mas nessa retrospectiva específica isso não foi utilizado. Porém é importante pensar em planos de ação para evitar que problemas ocorram ou voltem a ocorrer, funcionando como uma espécie de gestão de riscos do projeto.

No final, a equipe que participou da retrospectiva levantou 24 problemas e 27 coisas boas que ocorrem no projeto (algumas não citadas aqui no post do blog).