A distância que nos afasta

Olá pessoal, este meu post é motivado pelos Treinamentos de Análise de Negócio Ágil que realizei neste ano.

Em todas as classes, um ponto em comum me chamou muita atenção: A distância entre Operacional e Comercial. Para quem trabalha no cenário de Consultoria, consegue entender melhor esta situação. Em grande parte das empresas, o primeiro contato com o cliente é feito pela Área Comercial. Onde é usado todo aquele jargão de “Leads, Prospects, Contatos” e etc.

Algo que absurdamente comum (e contraditório no meu ponto de vista) é que os Vendedores ganham bônus em cima de suas vendas. Logo, muitos deles têm como objetivo maior aumentar o bônus. Eles querem efetuar as vendas o quanto antes para partir para o próximo bônus. E é aqui que começa o problema.

Muitas consultorias, em tempo de formalização de proposta querem ser o mais rápido possível. A análise da Visão do Projeto geralmente é feita por uma pessoa (que pode ser body shopping) ou alguém que muito provavelmente não é parte do Time que vai desenvolver aquele projeto.

Quando a empresa se encontra num cenário de Concorrência, as coisas pioram. Pois para se ganhar o projeto, muitas vezes abaixasse os custos (enchendo de Juniors) ou corta-se no prazo (já indicando que muitas horas extras virão).

Operacional e Comercial geralmente não trabalham em sincrônia e quase sempre não compartilham da mesma meta. Logo o projeto já começa fadado a falhas e insucesso.

O cenário só piora quando os analistas envolvidos em tempo de Visão do projeto são cobrados por “estimativas corretas”. E fica mais feio ainda quando já vem do cliente, uma documentação para o analista “analisar” e dar a estimativa. Entenda que o papel do Analista é analisar de verdade, e não apenas realizar uma leitura e pronto.

Empresas de TI que esperam ter sucesso neste novo mundo devem buscar uma formar de unir o Operacional e o Comercial em uma só bandeira, uma só meta. E por incrível que pareça, isto é algo simples de fazer. Ficam aqui alguns pensamentos meus:

– Em tempo do Primeiro Contato do Cliente, já envolver alguém do Time: Sabemos que o dia-a-dia de uma consultoria é corrido, que os profissionais estão sempre alocados, mas, já em tempo de contato com o Cliente ir envolvendo alguém do Time é muito bom, pois permite que desde o início já existe um “feeling técnico”. Além disso, esse contato gera mais interesse do Time, que gera mais comprometimento.

– Em tempo de Visão e Estimativa, envolver vários perfis do Time: Em reuniões para se apurar a Visão do Projeto e ter uma estimativa, quanto mais pessoas do Time, senão o Time todo, estar envolvido, melhor. Com certeza o entedimento do negócio, o Domínio, será muito melhor entendido e disseminado. Além disso, você já inicia um contato que fortalece um vínculo de confiança.

– Bônus compartilhados. Se a empresa trabalha com políticas de bônus, esta deve envolver todos os comprometidos com o Projeto.

A base da Agilidade é a Cultura, pessoas. Se não houver união, metas compartilhadas, você poderá usar práticas ágeis, mas certamente não estará disfrutando de um ambiente tão saudavel quanto uma Cultura Ágil pode lhe prover. Distanciar Comercial do Operacional é uma porta para o CYA (Cover Your Ass).

No meu ambiente atual, buscamos fortalecer ao máximo esta união. Estimativas, análises e contatos são sempre feitos com a união Operacional/Comercial. É notório como a confiança do cliente é maior quando ve o envolvimento, o engajamento de tantas pessoas de diferentes perfis, desde o início do projeto.

Como feedback dos meus treinamentos sobre Análise de Negócio Ágil, vou procurar montar uma palestra/workshop/whatever para falar mais sobre este assunto.

E prentendo ir além. Neste ano, eu submeti uma proposta para o Agile Brazil falando sobre a união entre RH e TI. Neste meu novo desafio, vou buscar falar de todo este ciclo RH x TI (Operacional) x Comercial.

E vocês? Também já se depararam com este cenário?

[]s.

Agile Brazil 2012 vem aí.

Image

Olá pessoal.

Semana que vem é o Agile Brazil 2012.

A maior conferência brasileira sobre Métodos Ágeis de desenvolvimento de software, neste ano estará ainda maior. Com uma enorme lista de convidados, como James Shore, Neal Ford, Johanna RothmanReedy Feggins e outros, a Agile Brazil deste ano ainda trará duas novidades: Painéis.

Um Painel sobre Empreendedorismo, comandando por Luca Bastos contará com a presença de Alex Tabor, Davis Smith e Rafael Siqueira.

Outro Painel interessante será uma discussão sobre O Futuro do Agile Brazil.

Este Painel terá Manoel PimentelRafael Prikladnicki no comando.

Além das ótimas Palestras, Workshops e Talks de grande qualidade, que já são uma marca do evento.

Você pode conferir a grade do evento aqui.

Este ano eu participarei como Colaborador do evento.

Também farei duas apresentações:

Pedaços de XP, FDD, Scrum e Kanban na Análise de Negócio e Engenharia de Requisitos

Utilizando pedaços de técnicas do FDD, XP, Scrum, Kanban e outros, pude realizar uma experiência em Análise e Modelagem de Negócios e Requisitos que foi um divisor de águas para projetos e produtos.

Neste relato, vou expor qual era o cenário padrão da Elicitação de Requisitos e sua Engenharia ao longo do desenvolvimento, os problemas que enfrentamos e o que nos levou a selecionar pedaços de vários Frameworks e Métodos ágeis, junto de outras técnicas, para solucionarmos nossos problemas.

Vou expor também os ganhos que obtivemos com esta mudança, as perdas e como enfrentamos esta transição.

Standup Comedy Agile. A comédia da vida Agile

Nossa dinâmica de desenvolvimento de software por si só já é algo altamente engraçado. Nossas diferenças de pensamentos, paradigmas e princípios tornam ainda mais cômico este cenário.

Vemos no dia-a-dia várias situações engraçadas, ainda mais quando se trata da adoção de Agile ou de conflitos entre modelos de gestão, hierarquias, linguagens de programação e etc.

Esta talk irá se transfomar em um stand up comedy para exibir vários destes acontencimentos engraçados e passar uma mensagem simples de alegria e de como lidar com pessoas.

Espero todos vocês lá.

[]s.

Adapte o processo como um grande chef de cozinha!… WTF!?!?!?

Olá,

Sim, você não leu errado no título do post, é chef de cozinha mesmo, mas eu explico.

Para quem me conhece pessoalmente vai pensar “Mas é claro que ele tinha que falar de comida, mas o que isso tem a ver com métodos ágeis?”

Bom, eu gosto de cozinhar, ou ao menos tentar, nunca matei ninguém até hoje ou mandei para o hospital. Mas para todos aqueles que gostam de cozinhar, acredito que o começo de “carreira” de chef amador é basicamente o mesmo. Pegamos uma receita que gostamos, que seja fácil de fazer, compramos os ingredientes, expulsamos todo mundo da cozinha e mãos à obra. Com um pouco de sorte insistência conseguimos sair com algo razoavelmente decente da cozinha.

Na parte do “mãos à obra” seguimos a receita em todos os seus pontos e vírgulas, se tivermos um termometro digital a gente usaria para verificar se a temperatura do formo está exatamente igual a mencionada, precisão britânica nas gramas de farinha, no tamanho da colher de chá de fermento, enfim, queremos fazer tudo perfeito para que a receita saia um sucesso.

Depois de um tempo fazendo receitas, começamos a ter a necessidade de adaptar elas, deixar elas com a nossa cara, usar ingredientes que gostamos mais do que outros. E é aí que entra o grande truque, o mesmo truque que devemos usar quando adaptamos um processo de desenvolvimento de sistemas para a nossa equipe/projeto/empresa. Modifique, adapte, mas sempre tenha claro quais são essas modificações e seus porquês, e nunca perca de vista o objetivo final.

Quando estou fazendo uma receita de bolo de cenoura, posso modifica-la para usar farinha de trigo integral no lugar da branca, ou fazer a cobertura com chocolate amargo no lugar de achocolatado, mas o resultado final ainda tem que ser um bolo de cenoura, não posso modificar a receita e esperar que saia um frango assado no final.

Grandes chefs de cozinha conseguem adaptar receitas para os ingredientes que eles tem a disposição, sem perder as características principais do prato. Quando modificamos o Scrum, por exemplo, não podemos nos esquecer dos objetivos dele, e quando o modificamos, temos que saber o porque dessas modificações, precisamos lembrar que, assim como em uma receita, essas modificações podem nos obrigar a alterar outras coisas que não foram previstas.

Mas mantendo nosso foco no objetivo final, com a experiência adquirida, vai ficando mais fácil ver onde e como devemos modificar as coisas. Começamos a fazer essas modificações de maneira mais instintiva, assim como os chefs modificam suas receitas. Aprenda novas técnicas e misture-as com as que você já conhece, sem se preocupar com os nomes, um ótimo exemplo disso é o post do Rafael sobre FDD, User Stories e Boards na Engenharia de Requisitos, e use-as com sabedoria nas suas adaptações.

Mas lembrem-se, no final, uma receita de bolo de cenoura não pode terminar como um frango assado…

Gordon Ramsay

FDD, User Stories e Boards na Engenharia de Requisitos

Olá caros, tudo bom?

Hoje vou falar sobre junções de técnicas de diferentes métodos que auxiliam na Engenharia de Requisitos. Venho usando essa junção há algum tempo e obtendo bons resultados.

Vamos começar por FDD.

Feature Driven Development é uma metodologia ágil criada por Peter Coad e Jeff de Luca em 1997, utilizada em um projeto de um grande banco em Singapura.

O FDD oferece uma estrutura interessante:

  • DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
  • CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
  • PPF (Planejar por Funcionalidade): Planejamento Incremental
  • DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
  • CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos

No passo CLF, eu uso a estratégia criada do modelo ARO para escrever nos Products Backlogs. Vamos conhecer mais sobre o modelo:

<ação> <resultado> <objeto>

Exemplos:

  • <calcular> o <total> de uma <venda>
  • <calcular> a <quantidade total vendida por um varejista> para uma <descrição de produto>.

As funcionalidades são granulares, de acordo com a regra de que uma funcionalidade não levará mais do que duas semanas para ser completada, mas não tão granulares ao nível de “getters” e “setters” (os métodos de acesso aos atributos de uma classe). Duas semanas são um limite superior; a maioria das funcionalidades levam muito menos tempo do que isso. Quando um passo de uma atividade de negócio parece maior do que duas semanas, o passo é quebrado em passos menores, que então tornam-se funcionalidades. by Heptagon

Nos últimos projetos que atuei, construi meu Product Backlog, escrevendo as funcionalidades seguindo a descrição ARO. Interessante informar que, descrevendo deste modo, a percepção inicial sobre a funcionalidade é mais fácil de ser “sacada” pelo Time e também mais fácil de ser descrita pelo P.O (ou o Time do P.O).

Tendo como base que o Product Backlog é uma lista de desejos, acho interessante escrever o desejo no modelo ARO. Quando faço entrevistas com os clientes e usuários, vejo que eles tem uma visão interessante do objetivo que desejam alcançar. O que faço é quebrar estes objetivos em ações menores, e vai ficando fácil enquadar isto numa descrição no modelo ARO.

Em projetos que necessitam de um Pré Planning/Pré Game, popular o Product Backlog desta maneira é interessante pois facilita na explicação para o Time e ajuda-os a estimar. Pensando em Agile, não devemos nos alongar em coisas que não serão feitas agora (foco no ROI). Usando o modelo ARO para compor a lista inicial do Product Backlog ajuda, pois não necessita da mesma profundidade de análise e tempo que uma User Story.

O modelo ARO se mostra indiferente ao tamanho. Você pode usa-lo para descrever Funcionalidades menores (inferiores a duas semanas) ou Épicos. Os exemplos abaixo ilustram isso:

  • calcular o total de uma venda
  • calcular a quantidade total vendida por um varejista para uma descrição de produto.

O primeiro exemplo cai bem num Épico, pois é mais vago, está mais aberto para discussão e entendimento. O segundo exemplo cai bem para uma funcionalidade que está em vias de entrar em uma Sprint, pois já define um papel interessado, um cálculo definido e um objeto mais conciso.

Do FDD, eu também gosto de usar a Feature Breakdown Structure. A FBS é um modelo de estruturação de funcionalidades, igual a WBS.

A FBS é uma forma visual e interessante de modelar suas funcionalidades de acordo com a Modelagem de Negócios do Produto/Empresa.

A utilização dos conceitos de Funcionalidade do FDD e a FBS são de grande ajuda para fases iniciais do Projeto e para auxiliar em estimativas.

Para saber mais, dou a dica de dois posts: Um da VersionOne explicando mais sobre a FBS e estimativas e outro da Flylib explicando mais sobre uma fase de Pré Game, utilizando FBS e Funcionalidades.

Para o topo do Backlog, eu geralmente quebro as Funcionalidades, usando o modelo de User Stories:

As a [type of user]

I want to [perform some task]

so that I can [reach some goal]

Isso me facilita muito evoluir no entendimento da funcionalidade, reconhecer os reais usuários, as necessidades e o valor de negócio de uma User Story. Mantendo o padrão Agile, geralmente eu crio as User Stories apenas quando necessário. Em alguns projetos isto quis dizer:

  • No decorrer da Sprint
  • Uma Sprint de antecedência
  • Duas Sprints de antecedência

E vou atualizando minha FBS:

Pra quem utiliza Story Mapping, a FBS é uma mão na massa. Você pode montar suas Releases, Sprints, pinçar as funcionalidades e User Stories necessárias para atingir os objetivos e exibi-las no Map:

by Agile Product Design 

Pra quem usa Boards (ou mesmo o Método Kanban), pinçar as Funcionalidades e/ou as User Stories fica bem interessante, exibindo a decomposição, o avanço do entendimento e a evolução do desenvolvimento.

Eu submeti uma proposta de palestra sobre este tema para o Agile Brazil, vou torcer para entrar.

E você, o que acha desta miscelânia?

Scrum Master, tão simples quanto possível

Olá pessoal. No post de hoje vou falar um pouco do papel do Scrum Master, e vou usar como pano de fundo, o caminho que trilhei.

O Post também vem para cumprir uma Meta, e desde já agradeço ao Mestre Manoel Pimentel.

Hoje é muito debatido qual o verdadeiro papel do Scrum Master, se é necessário, se é desnecessário, se ajuda a promover a auto-organização…

Bem, como sempre, vamos por parte.

Scrum Master é um facilitador que remove impedimentos do Time, e que isso não necessariamente quer dizer que ele seja o único a fazer isto. Eu como Scrum Master sempre busquei auxiliar ao Time como descobrir seus reais problemas, e como combate-los como Time.

Em alguns impedimentos, minha atuação direta como Scrum Master ajudava, pois não precisaria dispender alguém do Time, logo não atrapalha o pessoal. Contudo, toda atuação minha para tirar impedimentos era clara. Eu fazia questão de informar ao Time o que eu fiz, como fiz, com o intuito de transmitir conhecimento.

Porém, alguns impedimentos realmente tinham que ser tirados pelo time. Geralmente conhecimentos técnicos, necessidades de infra que exigiam o conhecimento apurado de alguém para explicar. Nestes casos, eu atuava realmente como facilitador, buscando ajudar ao máximo.

Um Scrum Master tem uma meta básica que é zelar pelos Valores do Scrum, logo os Valores do Manifesto Ágil. Isto é realmente muito difícil e requer experiência.

Quando me foi sugerido ser Scrum Master, que no caso fui indicado pelo pessoal do Time, eu já tinha um bom conhecimento de Métodos Ágeis, porém, não poupei esforços para conhecer mais.

E qual foi a primeira coisa que fiz? Não. Não foi buscar a certificação.

Foi buscar um arsenal de Literatura e Mentoring. Na época a empresa era assistida por um Mentoring, o Felipe Rodrigues. Dezenas de livros amontoaram minha mesa e meu computador, dentre eles:

  • Agile Software Development with Scrum – Ken Schwaber
  • Agile Restrospecitves – Diana Larsen
  • Agile Estimating and Planing – Mike Cohn

Porém, fui mais além disto e quis conhecer as raízes então fui ler:

  • Scrum Papers – Jeff Sutherland
  • The New New Product. Development Game – Hirotaka Takeuchi and Ikujiro Nonaka

Me inundei numa leitura de Posts, tanto dos Gurus externos quanto internos e deixo aqui dois grandes posts do Fabio Akita:

http://akitaonrails.com/2009/12/10/off-topic-voce-nao-entende-nada-de-scrum

http://akitaonrails.com/2010/01/30/off-topic-lendo-os-principios-ageis

Sem falar nos Mentorings e troca de experiência com vários grandes profissionais da nossa área. Mergulhei mais ainda também em participação em eventos, reuniões, grupos de usuários e etc.

Em seguida veio a certificação CSM com o grande Alexande Magno. O processo certificatório pode ser falho, mas a oportunidade de troca de experiência com o Magno foi sensacional.

A atuação de um Scrum Master, zelando pelos Valores do Scrum é simples ou complicado mediante a sua verdade. Não se cria um sentimento de união, um senso de comprometimento e auto gerenciamento num Time de uma hora pra outra.

Cada Time tem sua dinâmica, e isto deve ser somado a realidade de cada Empresa. Como Scrum Master aprendi que melhorias no Time são ótimas mas podem não gerar bons frutos se forem feitas isoladas. Melhorias que buscam impulsionar os Valores Ágeis devem ser feitas em escala Empresarial. Eu tive muita dificuldade nesta parte.

O que acontece com algumas pessoas que atuam como Scrum Master, é que elas passam a achar que estão sempre certas e são Juízes, julgadores do bem e do mal. Eu sempre mantive claro para mim, que eu não era assim. Que como todo profissional eu estava passível de erros e acertos. Logo, eu aprendi com meus próprios erros vendo que quando estava pensando em lutar pelos Valores Ágeis, na verdade eu estava criando um cabo de guerra.

Se todo Scrum Master deve prezar pelos Valores Ágeis então ele deve ser o primeiro a realmente se fazer deles. Eu fazia retrospectivas e buscava melhorias. Quando percebi que minha atuação criava cabo guerra, sentei com todos os envolvidos e busquei dissolver isto.

Hoje, percebo que a atuação de um Scrum Master é tão simples quanto possível, utilizando como sua principal arma o Bom Senso.

Porém, o bom senso é algo relativo e deve levar em conta vários aspectos. Neste ponto, uma literatura me auxiliou muito:

Buscando melhorias, não podia me contentar com melhorias locais e passei a buscar melhorias sistêmicas. Minhas Retrospectivas tomaram outro caminho, onde junto do Time, analisavamos nossos problemas, o que os causavam, os pontos de alavancagem para as melhorias e o que isto impactaria a estrutura como um todo.

Mais uma vez, isto foi algo que eu errei e aprendi como Scrum Master. A grande dica que eu dou a quem exerce este papel é:

Jamais se ache MASTER

A simplicidade me guiou nesta caminhada. Como todo desenvolvedor que busca aprender, como todo analista que deseja conhecimento, eu também como Scrum Master segui o caminho de buscar aprendizado, de fazer, de errar, de aprender.

Eu causei muita polêmica como Scrum Master, gerei muitos embates e hoje vejo que não foi um dos melhores caminho que segui. Porém também vejo o quão o pessoal dos Times que atuei se desenvolveram, o quanto eles entregaram, o quanto estavam felizes. Tudo como um processo simples e natural da vida.

Ser Scum Master é tão simples quanto qualquer outro papel. Você deve buscar sempre conhecer tudo que é tido como fundamental e bom para exercer seu papel, você deve atuar, errar e aprender.

Grandes questões como “Scrum Master pode ajudar na auto gestão”, a respostas não está no papel do Scrum Master, e sim na pessoa que atua nele.

Ter Empatia por todos os envolvidos na dinâmica de desenvolvimento da Empresa, buscar melhorias consistentes e sustentáveis, ser verdadeiro, ter conhecimento podem fazer com que boas coisas aconteçam, independente do papel que a pessoa exerça.

Hoje, posso dizer que por espaços de tempo, eu vi times realmentes auto gerenciados, pude ver Retrospectivas com toda a Estrutura da Empresa envolvida no Produto, pude ver o crescimento de várias pessoas.

Não posso jamais dizer que eu criei Times Auto Gerenciaveis, que tinham total noção do ROI e blá blá blá. Mas posso dizer com certeza que por bons momentos, pude ver coisas feitas da forma certa. Pude ver P.Os discutindo com o Time o real alor das coisas, pude ver Times conseguirem atingir Metas incríveis, pude ver produtos Entregues, pude ver elogios da Gerencia e outras coisas boas.

Para mim, as coisas hoje são tão simples quanto possível. Eu vejo desejos de várias partes, vejo necessidades e oportunidades e busco fazer parte de toda esta dinâmica.

Ambientes que buscam melhorias e se valem dos Valores Ágeis, proporcionam a um Scrum Master ou um Agile Coach auxiliar o pessoal a chegar a grandes feitos. É isso que faço hoje.

Já conheci Scrum Masters que colocavam o nome do papel na assinatura de e-mail, já conheci outros que estimavam pelo Time, conheci outros que não sabiam o que era uma Iteração e outros ainda que não sabiam quem era Ken Schwaber. Por isso que digo que o X da questão não está no papel, está na pessoa.

E você caro amigo, como foram suas experiências como Scrum Master? Ou como o Scrum Master com que você atua é?

[]s.

Aprendendo a andar de bicicleta

Versão resumida do post: Scrum Master’s, deixem as equipes se ralarem um pouco, só cuide para que eles não se matem.

Se você leu e não entendeu, leia o resto do post 😛

Image

Quando somos crianças, ou já adultos, quando vamos aprender a andar de bicicleta, sempre caímos.

Nunca, ninguém aprendeu a andar de bicicleta sem ter ralado um joelho antes, mas mesmo depois que se aprende, continuamos a ralar os joelhos e cotovelos e esse processo é essencial para o nosso aprendizado. Fazemos isso porque estamos testando nossos limites, quando nunca andamos antes, nosso limite é conseguir andar e fazer algumas curvas.

Após esse passo básico, nossos limites vão aumentando, mas continuamos a testá-los e a cada teste continuamos ralando os joelhos e cotovelos, as vezes algo mais. Quando estamos aprendendo a andar, temos sempre alguém nos ajudando a descobrir os limites à serem testados, e ajudando a evitar que a gente se mate nos primeiros 5 minutos em cima da bicicleta.

Em outros momentos da nossa vida passamos pelo mesmo tipo de situação, aprendendo a fazer alguma coisa, testando os nossos limites e com alguém nos ajudando a não nos matarmos. No Scrum eu vejo uma situação dessas principalmente na hora da Sprint Planning.

Na Sprint Planning a equipe deve estimar as estórias e definir com o que eles vão se comprometer na sprint. O SM (Scrum Master) está lá para ajudar a equipe a manter o foco, ver se a equipe está seguindo os “rituais” necessários e, entre outras coisas, a ajudar a equipe não se “matar” com a quantidade de estórias que eles vão colocar na sprint.

Nesse ponto o SM tem que tomar muito cuidado para que ele não “trave”, impedindo que eles testem seus limites e aprendam, uma das maneiras de “travar” a equipe é exigindo que eles sempre entreguem tudo com o que eles se comprometerem, sem dar uma margem para que a equipe erre. Ele tem que saber deixar a equipe testar os seus limites, isso, com certeza, vai gerar alguns ralados, mas assim como quando aprendemos a andar de bicicleta, esses ralados fazem parte do aprendizado, eles nos dizem que naquele momento ultrapassamos nossos limites e que precisamos melhorar em algo antes de descobrirmos novos limites. Mas mesmo assim o SM também tem que tomar cuidado com o outro lado, evitar que a equipe se comprometa com uma quantidade irreal de estórias e se “mate” na sprint.

O conceito essencial para que as coisas funcionem na Sprint Planning é o mesmo conceito fundamental para se andar de bicicleta, equilíbrio. Não é algo fácil, não existe fórmula mágica para calcular isso, esse equilibrio vem da convivência e da conversa entre a equipe e o SM, lembrem-se, assim como quando aprendemos a andar de bicicleta existe alguém nos ajudando a não nos matarmos, essa mesma pessoa nos ajuda a levantar quando caímos, ajuda a curar os nossos ralados, evitando infecções e outras coisas.

Assim tem que ser o SM na Sprint Planning, ajudando a equipe a testar seus limites, ajudando ela a se levantar após um tombo, ajudando a tratar os ralados, mas sem proibir a equipe de andar de bicicleta alegando que é muito perigoso.

Portanto: Scrum Master’s, deixem as equipes se ralarem um pouco, só cuide para que eles não se matem.

Apresentações e materiais

Olá caros amigos.

Tem tempo que já estava querendo fazer isto, agora chegou a hora.

Estou unindo todo o conteúdo que já gerei e deixando os links aqui no blog para mais fácil acesso e divulgação.

Seguem então os slides de algumas palestras, talks, vídeos e fotos das apresentações que fiz e participei. Confira!

Nesta palestra no grupo formado por empresas de TI da Região de Campinas, o SPIN, eu falo sobre as raízes do Scrum, o impacto de sua adoção no ambiente corporativo e algumas dicas para melhorar esta ação.

Nesta palestra realizada no TDC 2011 na trilha de Liderança e Coaching, abordei os princípios da Liderança Servidora, princípios sobre Motivação e os desafios da Motivação em grupo.

Nesta palestra realizada no TDC 2011 na trilha de Agile, abordei sobre a dificuldade da realidade da Filosofia Ágil em um ambiente corporativo bem como hype Ágil prejudicou um pouco esta adoção.

Nesta palestra junto com o Renato Freire realizada no Agile Brazil 2011, abordamos sobre a motivação de ir no Agile Brazil em Porto Alegre, o que nós aprendemos no evento e como utilizamos e disseminamos este conhecimento e sobre nossas conclusões.

Este foi um Lightning Talk que apresentei no Agile Brazil 2011 sobre o Domain Game, um jogo criado para auxiliar na disseminação sobre o domínio de um negócio, sua linguagem e integrar o Time ao Cliente.

Ainda tem o vídeo que fiz para o Conversa Rápida, idealizado pelo Jonas Abreu.

Esta palestra sobre Srcum eu realizei em vários treinamentos, workshops e eventos em faculdades. É uma introdução básica as raízes do Scrum e como ele roda. Além disse, a palestra apresenta de modo irreverente os valores do Scrum

Este painel foi realizado durante o TDC 2011 na trilha de Agile. Nele, vários nomes do Desenvolvimento de Software Ágil do Brasil, como André Nascimento, Dairton Bassi, Giovanni Bassi, Victor Hugo Germano e Rodrigo Yoshima comandados por Felipe Rodrigues, juntamente comigo :O, discutimos sobre o que pode vir depois da Onda Ágil. O vídeo é bem divertido, e como sempre, eu buscando tirar risadas da galera.

Esta apostila eu fiz, com base na minha experiência, no aprendizado prático e através de conhecimento adquirido com vários gurus de Scrum e Agile. A apostila foi revisada por grandes nomes do Scrum no Brasil e eu a utilizo nos meus treinamentos de Scrum.

E isso é tudo pessoal.

Espero que gostem, apreveitem e deem feedback 😀

E aqui vai umas fotos do Rafajagua aprontando ao redor do Globo.

Este slideshow necessita de JavaScript.

[]s.