Ó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.

Think simple!

Essa imagem é uma das que mais traduzem a realidade.


Tá bem, eu sei que ninguém aqui faz isso :)

A volta do que não foi...

Enviei um email para o meu chefe ontem, com duas perguntas. A primeira a respeito do final do nosso projeto, se estava finalizado ou não. Falei que como ele não havia me dito nada mais, tomei a liberdade de desmobilizar a equipe. Falei bastante sobre isso neste post. Aproveitei para lembrar da questão da reunião do próximo projeto, já que ninguém havia dado nenhuma notícia.

A resposta do meu chefe foi bastante interessante:

Minha ideia é continuar o projeto até termos o teste no trator aprovado. Vou conseguir verba para isso.

Bom, de fato o teste do trator pode ser interessante. Só que vai ser esse mesmo o deadline? Esse projeto terá algum dia um fim?! Eu, sinceramente, já não sei mais o que fazer... sabe aquele projeto "interminável"? Pois estão diante de um hehe

E sobre a reunião, nenhuma palavra.........

Abraços

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

Distração...

Essa eu tinha que mostrar para o meu chefe. Ele quase sempre reclama das distrações no trabalho, reclamando da internet (msn, email, páginas na internet, etc). Acho que essa charge foi para mostrar que a distração transcende a tecnologia. É uma questão cultural....

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).

O case que me inspirou

Este post foi um dos que me inspiraram a usar o SCRUM. Confesso que, junto com um artigo que eu li na época, fiquei fascinado com os resultados que eu poderia atingir com o SCRUM. Não vi apenas o lado técnico do projeto, mas muito mais a questão anímica (comportamental) que a mudança causaria.

O Phillip Calçado publicou este relato que até hoje é citado como referência.

Felizmente, o meu blog também tem tido o mesmo reconhecimento. E a idéia é realmente essa: mostrar a todos interessados que aplicar SCRUM (ou mesmo alguns conceitos dele) não é nenhum bicho de sete cabeças. Qualquer um pode e o resultado quase sempre será bacana.

O post é este aqui:

http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

Excelente exemplo sobre "aproximar o cliente"

Roubei esta historinha do blog do Alexandre Magno . É excelente para mostrar a importância de se trazer o cliente para junto da equipe.

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

Estou no aeroporto de Congonhas aguardando que você traga para mim alguns documentos que tenho que levar em uma viagem importante. Você está na região da Av. Paulista e precisa chegar o quanto antes no aeroporto.

SITUAÇÃO 1

Decide então pegar um táxi, chama o taxista mais próximo e pergunta:

- Sr., daqui para o aeroporto de Congonhas quanto tempo levaria – qual sua estimativa?

O taxista provavelmente olharia no relógio, no máximo consultaria pelo rádio sobre como o trânsito está naquela região (não, ele não usaria APF) e, de acordo com sua experiência, lhe daria uma estimava:

- Olha, nesse horário creio que em 30 minutos estejamos por lá.

Você acha a estimativa satisfatória e pega o táxi. Ao chegar no aeroporto você percebe que o táxi levou 80 minutos para chegar até o destino, e ao invés de custar R$ 35 (como previsto), custou R$ 90.

Qual seu sentimento com relação ao motorista?

Você estava dentro do táxi o tempo todo e percebeu que ele fez o possível para chegar a tempo, se esforçou. Você viu que o trânsito estava ruim e que um grave acidente no meio do caminho piorou as coisas. Você viu que quando isso aconteceu o taxista tentou pegar um outro caminho para fugir do trânsito e, por mais que a estratégia tenha sido boa, não foi suficiente para chegar a tempo.

Há, portanto, uma probabilidade muito grande de você, mesmo chateado, pagar o taxista e entender o lado dele, afinal você viu o quanto ele se esforçou para cumprir o prometido.

SITUAÇÃO 2

Mesmo cenário. Porém, imagine que ao invés de ir no táxi, você apenas contrata o taxista para levar os documentos para o aeroporto. Ele lhe deu a mesma estimativa de tempo e custo.

No entanto, 80 minutos depois ele lhe liga e diz: “Olha, o trânsito estava muito complicado... só cheguei agora, o custo foi R$ 90 ao invés de R$ 35”.

Qual será sua reação agora? O que você pensará?

Você não viu o que o motorista fez, não soube de nenhum acidente que possa ter causado um desvio, não sabe se ele se esforçou ou não, apenas está ouvindo o relato de alguém que diz que atrasou. Possivelmente, sejamos sinceros, iremos pensar: "Esse cara está me enganando!".

Moral da história

Coloque seu cliente “dentro do táxi” sempre, só assim ele entenderá o seu processo e suas dificuldades para alcançar o sucesso do projeto. Mantendo-o de fora ele sempre achará que você está querendo “se dar bem”.

Criando falsas (ou nem isso) expectativas...

Pessoal, desculpem! Desculpem mesmo. Havia prometido para a semana passada que tornaria o blog diário novamente e que postaria o resultado da palestra para a turma de pos (que foi bem legal) e também o resultado da minha retrospectiva com o pessoal do trabalho.

Infelizmente acabei me enrolando e não consegui finalizar os dois. Quero ver se amanhã sem falta posto, ok?

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

Vou falar sobre a criação de expectativas, muito graças a comunicação ineficiente que ainda existe no meu trabalho. Vejam a minha situação e reflitam se vocês não vivem a mesma coisa ou pior: se vocês não estão fazendo isso.

Lembram quando eu falei que para iniciar o próximo projeto, os meus chefes queriam fazer uma reunião para definir a parte financeira (RH) do projeto? Cheguei a publicar um post falando disso.

Pois bem. Esperamos naquela quarta-feira. E nada. Dois dos envolvidos sequer avisaram que não poderiam comparecer na reunião. Desde aquele dia (9/7/2008) não teve mais nenhuma palavra a respeito da reunião. Nenhuma! Nem previsão de dia, nem justificativa, nada.

Pior: o meu projeto, que apresentamos na feira, não teve oficializado uma deadline. Ou seja, eu não sei se ele está ativo ou não!! E o pior mesmo? É que os gastos de RH deste projeto já acabaram. Então eu acabei fazendo a minha equipe trabalhar por 15 dias neste mês (para finalizar a documentação) e eu nem sei se eles irão receber por isso.

Poxa, não é uma falta total de respeito com a equipe e com os gerentes, isso? Os meus chefes e os demais envolvidos que tanto falam que temos que mudar a imagem do grupo, que nós temos que trabalhar bastante, etc. dão uma demonstração claríssima de falta de comprometimento e boa vontade com a gente.

O que eu fiz? Bom, fechados os 15 dias, desmobilizei a equipe. Falei que não sabia se o projeto havia sido oficialmente finalizado e então disse que por via das dúvidas eles já haviam feito o que deveriam ter feito. Ponto. Um problema é que a equipe do meu projeto seria a equipe de hardware do próximo projeto... e eles também estavam impacientes sobre os rumos do projeto. Se amanhã eu não obtiver resposta dos meus chefes, vou dar como encerrado o assunto e vou liberar a equipe para que eles procurem emprego em outro local, caso não queiram esperar sentados pela famigerada reunião.

Já eu, fiquei mais alguns dias lá e como não obtive nenhum aceno sobre a reunião, eu mesmo me desmobilizei e não compareci na 5a e 6a. Fiz isso propositalmente, para tentar emitir um sinal indireto de que não estou satisfeito com a situação. Lógico, eu também estou arriscando aqui, seria muito mais simples eu simplesmente perguntar "E ai? E a reunião?". Mas seria a terceira vez neste mês. Tem um momento que a gente cansa e parte para o "semancol".

Eu realmente tenho interesse em permanecer lá por causa deste projeto, pois eu ajudei a elaborá-lo, vou ter maior liberdade para tomar decisões (até onde eu sei) e também será um projeto que eu acredito que tenha um impacto social e tecnológico bastante grande. Aquele legítimo projeto que vale a pena ter no currículo. São exatamente estes fatores que me fazem permanecer no grupo de pesquisas. Caso contrário, sinceramente, já tinha saído fora.

O fato é que eles criaram expectativas muito grandes durante a elaboração deste projeto e mesmo posteriormente. Falaram da reunião como sendo algo importantíssimo, que marcaria o começo do projeto e a mudança do perfil do grupo (ah, vale ressaltar: essa mudança de perfil eles estão considerando como idéia deles - embora eu já tenha demonstrado que iria fazer isso antes). E depois, deram claríssimas demonstrações de que a reunião estava em "segundo plano", pois sequer justificativas para as ausências e reagendamentos a gente teve.

A falta de comunicação nas empresas costuma gerar essa mazela, chamada de "falsas expectativas". É assim que surgem os boatos. É assim que surgem os conflitos. É assim que a desmotivação, o descompromisso e o descontentamento se tornam enormes problemas no emprego.

Por isso, caro leitor, reflita um pouco. Será que a sua empresa vive uma situação parecida? Será que seus chefes usam e abusam do famoso bordão "faça o que eu digo, mas não faça o que eu faço"? Será que você também não está criando falsas expectativas nos seus subordinados?

Enfim... não custa se comunicar. Por pior que seja a mensagem, ao menos ela evitará problemas maiores.

Um abraço e bom início de semana.

Semana boa :)

Essa semana começou bem.

Hoje, terça-feira, fiz com a minha equipe (desfalcada, pois um dos integrantes está viajando de férias) uma retrospectiva final do projeto, abrangendo os dois anos que estivemos juntos. Algumas coisas interessantes aconteceram :) Vou listá-las amanhã para vocês (hoje estou moído!).

E na sexta-feira irei fazer uma "palestra-dinâmica" para uma turma de pós, na universidade. Será legal ter um público diferente. Para isso, estou adaptando a dinâmica para funcionar melhor. Depois posto ela aqui para vocês utilizarem. Acho que ficará mais divertida :)

Abração

Voltando...

Pois então, pessoal. Estou de volta.

Semana passada foi meio crítica. O meu pai, no sábado, baixou hospital com algumas dores abdominais, que foram identificadas como uma infecção no local onde ele havia feito uma cirurgia há meses atrás. É um fato raro de acontecer, mas aconteceu.

Deu tudo certo! Na sexta passada ele saiu do hospital e está novo em folha! :)

Mas são nestes momentos que a gente percebe como somos frágeis neste mundo. De uma hora para a outra, podemos estar deitados em uma cama de hospital. A gente começa a refletir um pouco sobre nossos hábitos, sobre a beleza das pequenas coisas, como estar em família. Tirei a semana de folga no trabalho, pois não conseguiria me concentrar sabendo que o meu pai estava hospitalizado. E meus dois irmãos (irmão e irmã) também. Logo, convivemos todos (mais a minha mãe) como antigamente, os cinco juntos. Coisa assim era bastante corriqueira: janta, um final de semana na praia, etc. Mas a semana inteira não :)

E como é bom isso. A gente percebe como a família é mais importante do que tudo.

Refletindo um pouco, a gente as vezes pensa em quantas vezes passamos horas e horas na frente do computador trabalhando. E em quantos momentos já deixamos de fazer algo com a família ou com a gente mesmo, para se dedicar um pouco mais ao trabalho. Por mais que a gente goste de trabalhar, talvez algumas vezes devessemos repensar nossas prioridades. Será que perder uma sexta-feira a noite, ou um final de semana, adiantando trabalho vale a pena? Será que não poderíamos usar esse tempo para nos dedicar a família?

Muito se fala em qualidade de vida. Eu acho que a qualidade de vida está entre balancear corretamente a nossa vida no trabalho com a vida pessoal.

Numa palestra com o Daniel Wildt, no mesmo dia em que eu fiz a palestra sobre o "Scrum in Hell", ele falou uma coisa que acho que mostra a essência de como um processo como o SCRUM pode melhor inclusive a nossa vida pessoal: ele disse que em uma empresa, havia um analista cujo horário de trabalho normalmente ia até as 21h. Então ele tomou este cara como exemplo e desafio e prometeu para ele: "uma das minhas funções aqui é fazer com que tu saia do trabalho às 18h". E conseguiu! Ou seja, o SCRUM (e o agile como um todo) com certeza ajudou a dar mais qualidade de vida para este analista :)

Enfim, estou voltando. E espero voltar a manter a periodicidade diária do blog. Podem me cobrar ;)

Um grande abraço

Ausência forçada por alguns dias mais...

Caríssimos,

estou enfrentando um problema familiar (cirurgia do meu pai) e por isso não estou podendo postar. Quero ver até o final da semana tudo está resolvido e volto a periodicidade diária do blog :)

Enquanto isso, sugiro que vocês leiam os posts anteriores, principalmente os "recomendados" aqui no menu direito. Tem os podcasts também para quem não ouviu.

Até breve :)

Sugestão para "intranet"

Amigos,

estamos aqui no trabalho precisando de uma ferramenta para fazer as vezes de "intranet". Tentamos usar os wikis, que são poderosos, mas ao mesmo tempo não são tão intuitivos.

Encontrei essa ferramenta, já consideravelmente conhecida, chamada Zoho Projects (www.zoho.com). Criei um projeto para ver como funciona e gostei muito do que eu vi.

Pode ser adaptada pro SCRUM tranquilamente. É bem simples e bem funcional! Vale a pena e fica a minha sugestão. Algumas features que ela provê:

- Quatro tipos de usuários (admin, contractor, manager, employee) com visões e atribuições diferentes.
- Forum para discussões
- Visualização de o usuário está online ou não (faltou um chat integrado)
- Cadastro de horas trabalhadas (para empresas mais rígidas)
- Controle de arquivos (com versionamento)
- Agendamento de reuniões
- Criação de milestones que contem grupo de tarefas e que contem tarefas. Aqui, basta mudar para sprint (milestone), user story e impediment backlog (grupo de tarefas) e tarefas. As tarefas podem ficar sem atribuições de pessoas, podendo ser atualizada durante a daily meeting.
- Feed RSS para aviso de mudanças
- Log com mudanças que ocorram na página
- Possibilidade de inserir notas em tarefas, reuniões, etc.

Enfim, para quem procura uma ferramenta bem simples e gratuita para controlar o seu projeto, eu recomendo esta.

Fica a sugestão :)

Navegação no blog melhorada!

Caros leitores,

a navegação no blog ficou facilitada com a inclusão dos links rápidos no menu esquerdo :)

Vocês podem achar facilmente os posts que eu destaquei, as resenhas dos livros sobre projetos e liderança (minhas resenhas, claro) e também os podcasts do blog.

Espero que gostem!

Abraços

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

Editado: Menu DIREITO, lógico!! O que é o efeito do sono! haha

Reunião importante nesta quarta-feira

Quarta feira, 17 horas.

Esse é o horário da reunião mais importante deste ano. Será a reunião onde será decidido como será o nosso próximo projeto. Iremos focar, principalmente, no perfil das equipes. Eles, meus chefes, pretendem mostrar que querem uma mudança radical de atitude das pessoas do laboratório.

Será a minha chance para apresentar a questão da gestão por competências.

O que me deixa meio preocupado é que eles querem mudar... não mudando. Ou seja, vão aproveitar muitos dos que já estão no laboratório e, além disso, querem manter os salários (as bolsas) das pessoas no mesmo nível atual. Daí eu pergunto: se eles realmente querem mudar o perfil, por que agem CONTRA isso?

Mas o ponto mais tenso da reunião será quando falarmos de salários. O salário dos gerentes.

Um dos meus chefes havia me dado a incumbência de fazer o planejamento financeiro de RH do projeto. Eu fiz, prevendo diversas variáveis (inclusive o valor que fica aplicado no banco, gerando rendimentos financeiros). Para o meu salário, peguei a média dos gerente de projetos e taquei ali: R$ 3700,00.

Numa primeira reunião, entre eu, meu colega e meus dois chefes, já houve um princípio de divergência. "Não estão inflacionando o mercado, com este valor?". Eu fui firme: "Não. É o valor de mercado". Deu pra ver que eles não ficaram muito satisfeitos.

No outro dia, marcaram uma nova reunião (essa agora) em que eu e o meu colega estaremos junto com meus dois chefes, mais um coordenador e um diretor da empresa. Ou seja, o cenário está todo armado para que nós façamos uma revisão dos nossos salários.

É claro que eu vou considerar que o ambiente é acadêmico e que a empresa é microempresa. A carga horária também é menor (6h). E quero ouvir deles, quais serão nossas responsabilidades.

Agora, sinceramente, eles também tem que valorizar E MUITO nosso trabalho. Eu e o meu colega recebemos este ano duas ou três tijoladas (projetos incendiários) em que tivemos que agir e recuperá-los. Eu consegui resgatar o meu projeto atual, e o meu colega terminou o dele com antecedência. Temos que lidar com o pessoal do laboratório diariamente, liderando e mantendo a motivação do pessoal. Além disso, eu sou o "escritor oficial" de projetos do laboratório. Sempre que há um edital de projeto, eu sou convocado a auxiliar os meus chefes para escrever. Este que irá começar, de RFID, eu fui o responsável por boa parte do projeto. Também nunca deixamos eles na mão. Sempre fomos integros e honestos. E, por fim, este ano estou fazendo três anos na empresa!

São motivos mais do que de sobra para ter uma remuneração compatível com o mercado. Minha meta é ficar na proximidade de 3000-3200. Abaixo disso, eu já vou pensar muito se fico ou não.

Quero tratar este projeto como meu filho, isso eu já falo há tempos. Irei fazer o possível para entregá-lo em um ano (e alguns meses). Irei me dedicar muito ao projeto. Sei que será um excelente projeto para se ter no currículo, inclusive.

Mas preciso pensar na parte financeira também. Auto-realização não é só fazer o que gosta. É também receber o que se merece.

Enfim. Amanhã é o dia. Vamos ver como estamos cotados lá dentro.

Abraços!

E na reta final... uma ultrapassagem perfeita!

Como é o destino...

Meus dois últimos posts foram bem pessimistas. Disse inclusive que o meu projeto encerraria com 95% dele finalizado, apenas. Porém, desde o post, só aconteceram coisas boas! E o resultado é que o projeto está 99,9% entregue! :) Sim, teoricamente, mas parece que todo mundo resolveu dar um último gás no último segundo, e o panorama mudou.

Sexta-feira, o desenvolvedor da parte do software ficou até tarde trabalhando no laboratório. Queria tentar resolver os bugs que haviam aparecido nos testes. Enquanto isso, eu me dedicava a fazer o vídeo do nosso projeto. Ele estava irritado pois não achava o erro. E eu estava preocupado pois não encontrava vídeos onde pudessem aparecer cenas no campo, já que nosso projeto é de agricultura de precisão. Precisava de tratores, colheitadeiras, etc.

Sábado, envio um email para o meu chefe e ele me diz que encontrou umas fotos e vídeos antigos que fizemos quando fomos na fazenda dele, ainda no início do projeto. Bingo! Todo o material que eu precisava estava lá!! Ao mesmo tempo, o desenvolvedor de software voltou para trabalhar durante toda tarde no laboratório, para encerrar de uma vez o software. Ao final do dia, envia um email comemorando por ter resolvido (teoricamente) todos os bugs que tínhamos. E ainda deu tempo de fazer um sistema DEMO para rodar no dia da feira!

Domingo, finalizo o filme e um documento contendo todos os custos do nosso protótipo. Envio para o pessoal e todos ficam animadíssimos com o filme.

Então chega o dia da feira, segunda-feira. Acordo cedo, 6h30, para levar a namorada na rodoviária. Tinha que estar no trabalho às 8h30. Então durante uma hora e meia finalizo alguns outros materiais e corro para o trabalho. Lá apresento a versão final do filme e todos comemoram pois o resultado ficou realmente muito bacana! O documento dos custos é aprovado por todos também, pois era algo que iríamos precisar MUITO na feira.

Chegando na feira, diversas outras empresas já se encontravam lá. Arrumamos nossa mesa da seguinte forma:

- Notebook rodando o vídeo, em loop;
- Notebook rodando a demonstração do produto;
- Nosso protótipo (numa caixa e acabamento bem razoável) rodando o demo (acendendo luzinhas!);
- Um banner explicativo, bem bacana;
- Cartões de visita, folders, etc.

A nossa principal missão é agradar a comissão avaliadora, que veria os resultados produzidos pelo projeto. Organizamos nosso espaço de forma bem bacana e ainda tivemos sorte de que nossos vizinhos eram projetos extremamente simples (um era sobre abacates!!! Sabe-se lá o que era aquilo hehe).

Durante toda feira pudemos ver que das aproximadamente 20 empresas que estavam no local, éramos sem dúvida nenhuma a segunda melhor a apresentar seus produtos. Não fomos a primeira pois uma das empresas desenvolveu um scanner sensacional, e já estava em versão de produto... impossível competir com um produto tão perfeito, vamos ser sinceros. Fora isso, não tenho dúvidas que o nosso projeto era o que melhor foi divulgado lá.

Os resultados: várias pessoas interessadas em conhecer nosso produto, nenhum problema durante a apresentação, nenhum problema na avaliação (inclusive conseguimos encantar vários avaliadores). Internamente falando, TODA equipe de desenvolvimento estava satisfeita e orgulhosa do resultado. O meu chefe também ficou muito feliz e satisfeito. E eu, claro, me senti muito orgulhoso em ver que tudo havia dado certo. Tanto que não me preocupei em ficar aproximadamente seis horas de pé!

Essa semana iremos fazer a finalização do documento. E meu chefe agora se empolgou e quer fazer o teste final na fazenda, em um trator. Assim podemos ter um vídeo bem completo de todo o projeto. Além disso, a documentação do conhecimento adquirido no projeto será feita via vídeo também. Ninguém conseguirá escrever muito nessa semana, então decidi fazer vídeo. Não vai adiantar muito, mas pelo menos é alguma coisa.

Na sexta-feira faremos a retrospectiva final do projeto. Vamos analisar nossos erros, acertos, o que poderíamos ter feito de melhor, etc. Acho que isso será muito importante. Além disso, tentarei fazer uma sessão de feedback, para discutirmos a atuação individual de cada um. Isso também eu acho que será bem interessante.

Enfim. Essa reta final mostrou que quando um projeto deixa de ser apenas trabalho e passa a ser visto como uma realização pessoal, a coisa muda completamente de figura. Eu jamais imaginei que o desenvolvedor iria trabalhar um sábado inteiro para finalizar a parte dele. Essa foi uma das atitudes que mais me supreenderam nos últimos meses. Graças a ele pudemos ter algo bem tangível com relação ao nosso produto.

Foi uma prova de que se conseguirmos fazer essa mentalidade em toda a equipe, qualquer projeto que pegarmos será um sucesso. Agora, se tratarmos a equipe como "recursos" e um projeto como trabalho, realmente a coisa não irá fluir naturalmente. E o resultado tenderá ao fracasso.

Uma lição aprendida na prática.

Um grande abraço

Finalizando o projeto... infelizmente em 95%

Pois é. O grande Murphy resolveu dar uma pitadinha de humor negro neste final de projeto.

É dose. Hoje fizemos o teste final, antes da apresentação na segunda-feira. E novamente alguns problemas (de algorítmo) surgiram. Como a semana que vem será "extra-oficial" para o projeto, eu posso dizer que finalizamos o projeto com algo como 95% dele finalizado.

Eu me sinto orgulhoso por conseguir entregar esses 95%, visto a situação em que ele se encontrava há pouco mais de 6 meses atrás. Porém, ainda assim, fica aquele gostinho de que eu poderia ter feito algo mais. Talvez não tecnicamente (já que eu não tinha quase nenhum domínio na tecnologia), mas poderia ter esticado a corda um pouco mais... fazer a equipe sair dos momentos de zona de conforto em que estiveram por longos períodos.

Essa semana, por exemplo, na 2a e 3a eles ficaram só estudando para as provas da faculdade. Hoje constatamos que se tivéssemos mais um dia para fazer os testes, quase certamente finalizaríamos o projeto. Ou seja, se eles tivessem se dedicado um pouco (2 horas que fosse) nestes dois dias, poderíamos ter avançado mais.

Não estou muito feliz, é lógico. Mas saio com a sensação de que fiz o possível e que tive uma boa participação para que este projeto não fosse mais problemático do que foi. Podia ter feito mais, mas também não vou me culpar demais.

Vou ver se essa semana faço uma "retrô" aqui para tentar expôr algumas lições aprendidas. Para vocês e para mim será bastante útil, com certeza :)

Um abraço

Murphy visitando o meu projeto

Tem coisas que deixam a gente maluco.

Uma delas é quando as coisas dão erradas, quando precisam darem certas. Nosso projeto foi para teste de campo hoje. Os guris simularam desde ontem e tudo parecia perfeito. Levamos nosso equipamento para o estacionamento e começamos a testar.

E... ?

Problemas no LCD. Problemas nos LEDs. Problemas nos algorítmos. E isso com o meu chefe do lado. Ele estava empolgado no começo. Acabou, era visível o desânimo na cara dele (e na minha).

A situação é a seguinte: esse projeto precisa estar pronto para ser apresentado na segunda-feira!

Os guris prometeram que ficariam até tarde hoje finalizando as coisas. Eles diziam ter certeza de quais eram os problemas. Amanhã faremos novos testes... será que o nosso amigo Murphy vai nos visitar de novo?

Esse "cabra safado" que ouse! :)

Um abraço

Palestra "Scrum in Hell - Implantando agilidade em ambientes difíceis"

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

Salve pessoal,

Ontem realizei a palestra a convite do pessoal do GUMA-RS (Grupo de Usuários de Métodos Ágeis) onde trouxe um caso prático da aplicação do SCRUM, no meu trabalho.

O link para download é este.

Utilizei a conotação "ambiente difícil" para ilustrar ambientes onde os processos são caóticos, a comunicação normalmente é ruim, a cultura é autocrática, etc. que normalmente remetem a empresas de pequeno porte - e no meu caso, em grupos de pesquisa acadêmicos.

A apresentação não foi muuuito bem conduzida. Muito porque eu não tive tempo suficiente para prepará-la. Então acredito que o material apresentado tenha sido bem interessante, porém não consegui conduzir muito bem (em alguns momentos eu nem lembrava ao certo o porque havia escrito aquilo). Mesmo assim, com algumas correções, essa apresentação ficará redonda e bem ilustrativa de como aplicar SCRUM em sua empresa :)

Na verdade acredito que vou mudar o contexto dessa apresentação. Ao invés de ser "Scrum in Hell" será algo do tipo "YES YOU CAN!", que remete a um bordão americano famoso - usado incessantemente por um daqueles apresentadores de programa estilo "Márcia Goldschimitt" nos Estados Unidos, nos anos 90.

No post anterior, o Jefferson comentou que achou muito interessante o processo que eu abordei. Pretendo trabalhar mais em cima disso, mostrando como é simples de aplicar o SCRUM em sua empresa, seja ela pequena, grande, autocrática ou democrática. Podem ser iniciativas que partem desde o modelo "top-down", ou seja, vendendo a idéia para a diretoria para então implantar no operacional, ou "bottom-up", fazendo o inverso.

Então esperem que a próxima palestra será sim bem melhor e bem mais focada :) Tenho certeza que irão gostar mais ainda.

Uma pena que haviam 50 inscritos para a palestra e apenas metade compareceu ao evento, no dia. Espero que estas pessoas não tenham tirado o lugar de outros que não puderam ir!

O link para download da apresentação é este.

Vou ver se consigo com o Daniel para publicar a apresentação dele, que possuia muitos links interessantes.

Um grande abraço