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 😛

 

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.

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 2,000 times in 2013. If it were a cable car, it would take about 33 trips to carry that many people.

Click here to see the complete report.

Pré Game: Cascata, agilidade ou apenas opção para o mundo real?

Oi pessoal.

Este post tem que ter uma menção honrosa ao Eduardo D’avo, que me pediu pra pensar num método sobre Pré Game.

Vou contextualiza-los:

Trabalho numa grande (e muito legal e feliz) consultoria. Nós atuamos em muitos projetos e nem sempre nossos clientes conhecem Agile. Ou mesmo os que conhecem optam, por vezes, em não trabalhar desta forma e esse é o mundo real. Como todos aqui somos profissionais, e provavelmente não compramos as casas na praia que queremos ou viajamos pra todos lugares que desejamos, nós não negamos fogo a projetos “não ágeis”.

Sem duvida, não deixamos de explicar os benefícios do filosofia Agile (junte Lean aqui, ok) e de trabalhar com essa mentalidade, mas muitas vezes o cliente não abre mão da aceitação formal de fases, mantém o conhecimento em silos, deseja estimativa para saber prazo e custo e as outras maravilhas que todos conhecem. Então, nós aqui na Empresa fazemos um Pré Game.

O Pré Game consiste, no nosso caso, num curto espaço de tempo antes do início do desenvolvimento em si (das iterações) aonde averiguamos o contexto do Negócio (Projeto ou Produto) especulamos sobre seus objetivos, sua forma de gerar Valor e a quem ele gera valor. Também fazemos uma análise sobre as principais necessidades dos clientes e começamos a especular sobre as principais funcionalidades. Quando o caso é projeto, muitas vezes o Cliente já tem uma documentação preparada e tem seus Domain Experts.

Neste caso, literalmente sugamos o conhecimento junto ao Domain Expert, criamos conexões com os usuários e fazemos um reconhecimento da documentação existente. A questão é, Por que fazemos isso a invés de começar logo a desenvolver?

A resposta: Estamos no mundo Real!

Se pegarmos a documentação já existente, toma-la como correta e definitiva e começarmos a desenvolver, alguém aqui arrisca o resultado? Sim, o resultado será MERDA. Não por falta de qualidade ou incompetência. Sabemos o resultado de conhecimento de negócio colocado em papel, como forma de comunicação. Dá merda.

Outro ponto também: muitas vezes o cliente documenta o DESEJO e não o REQUISITO. E o pior: REQUISITO sem conhecimento do domínio do NEGÓCIO é como sexo sem órgão genital. O Pré Game, no nosso caso, serve também para criar a ponte entre o Cliente e o Time, fazer a contextualização sobre o Domínio do Negócio, unir as pessoas e criar o elo indivisível entre aqueles que querem entregar valor.

No nosso Pré Game, começamos a entender o que é desejo, o que é requisito e junto do Cliente buscamos o MPV (minimo produto viável) e criar o Plano de Release. É normal o cliente pedir tudo sem saber do valor sobre o que ele está pedindo. E ele acha que tem que pedir tudo pois provavelmente já teve experiências tristes e frustadas em outras consultorias, aonde coisas de valor pra ele, quando ele não especificou logo no começo do projeto e foi pedir depois, foi tratada como “change request” e foi um transtorno pra ser feito.

O nosso Pré Game serve como meta-game para educar o cliente, sem ele pedir está educação. E sem duvida nosso Pré Game também serve para outra coisa, que gera polêmica: ESTIMATIVAS. No nosso Pré Game, muitas vezes listamos as principais funcionalidades, as entendemos e estudamos sua complexidade técnica e em muitos casos, fazemos POCs.

E geramos uma potencial estimativa para ser feito o MVP. Ao longo do nosso processo de Pré Game, o cliente vai sentido que ele não precisa conhecer ou dominar todo o escopo. Explicamos o que realmente é uma estimativa e como vamos trata-la ao longo do projeto. Porém, por mais bonito que seja o discurso Ágil, e muitos sabem o quanto eu advoco por ele, muitas vezes os clientes não querem isso. Eles querem estimativa e prazo. Nossa artimanha para tentar ir quebrando esse medo e necessidade deles é o Pré Game.

Lá se vão 1 ano e 2 meses que estou aqui. Lá se vão 5 projetos que atuei diretamente e outros N > 10 e < 20 Pré Games feitos em propostas que não vingaram ou estão para vingar e o resultado tem sido muito bom. 2 casos recentes foram muito interessantes:

1 – Um cliente começou um projeto conosco mas por questões políticas internas deles, foram obrigados a parar.

Eles não poderiam fazer o projeto conosco por questões de contrato com outros parceiros e tal. Mas assim que isso se resolveu, eles nos escolheram não só pra terminar o projeto quanto começar um outro grande projeto.

O diferencial: O mote como fizemos o Pré Game e a concepção do MPV deles.

2 – Outro cliente que teve no seu Pré Game grandes descobertas de valor, graças a estudo de mercado e falseamento de hipóteses.

Ao fim do Pré Game, toda uma cadeia de valor foi estudada, grandes e inovadoras funcionalidades foram testadas em POC e hoje o produto ta no ar já dando o ROI esperado. E vem mais Releases dele…

Seria muito fácil para nós, negarmos fazer um projeto por sentir que o cliente não “deseja” Agile. Porém seria, IMHO, muito infantil da atitude de um profissional. Nosso Pré Game é um Meta Game de ensino de Agile. Sim, nós fornecemos estimativas e prazos, mas damos a estes o valor que eles merecem. Nada mais do que chutes ao vento cujo toda iteração iremos avaliar.

O ouro do nosso Pré Game é: O aprendizado junto ao cliente sobre o negócio e seu valor, gerando a integração entre stakeholders e Time, ao mesmo tempo que fornecemos o aprendizado em Agile, criando um elo de confiança.

No nosso Pré Game, sempre buscamos integrar o máximo possível de membros do Time junto aos stakeholders. Abaixo, seguem imagens do método de nosso Pré Game, de um material que gerei graças ao pedido do Edu.

Eu soltei ele pra Comunidade pois quero coletar feedback:

Os números de 2012

Os duendes de estatísticas do WordPress.com prepararam um relatório para o ano de 2012 deste blog.

Aqui está um resumo:

600 pessoas chegaram ao topo do Monte Everest em 2012. Este blog tem cerca de 2.700 visualizações em 2012. Se cada pessoa que chegou ao topo do Monte Everest visitasse este blog, levaria 5 anos para ter este tanto de visitação.

Clique aqui para ver o relatório completo

Mudanças e Mudanças…

Baseado no que tem acontecido comigo nos últimos meses, cheguei a conclusão que existem dois tipos de mudança que dependem de nós mesmos para acontecerem.

A primeira é a mudança de pensamento seguido pela mudança de ações. Todos temos nossas convicções, pensamentos e idéias que guiam muitas das nossas ações. Se alguma dessas convicções é alterada por algum motivo, começamos a mudar nossas ações para se enquadrar às nossas novas idéias e maneira de pensar.

A segunda é a mudança de ações seguida pela mudança de pensamento. Nesses casos tomamos decisões que vão contra nossas convicções. Na maioria das vezes ficamos com “frio na barriga” quando tomamos essas ações, porque estamos confrontando nossa zona de conforto, mas com o tempo, se forem ações acertadas, nossas idéias se encaixam nas nossas novas ações, e essa sensação desaparece.

De certa maneira, os dois tipos nos tiram do status quo e nos levam para novos lugares. A diferença é que a primeira costuma ser mais confortável, lenta e difícil de acontecer. A segunda nos deixa mais tensos com a mudança, as ações normalmente são imediatas e podem acontecer frequentemente, só depende da nossa vontade.

No que eu percebi até agora, a maioria das grandes mudanças estão no segundo tipo.

E você, concorda com isso?

A Importância do Primeiro Seguidor e nosso papel nas novas idéias

Várias vezes durante nosso caminho profissional ou pessoal nos deparamos com a situação de novas idéias.

Basicamente podemos ter dois papéis nesse momento, ou estamos sugerindo uma nova idéia a ser implantada ou estamos ouvindo a idéia de alguém.

Vejam o vídeo a seguir: The Dancing Guy

Quando sugerimos novas idéias, seja a implantação de uma melhoria no processo, um processo novo, TDD ou apenas a troca do horário de uma daily meeting, pode ser também uma dança estranha, devemos expor nossa idéia, o que nos motivou a sugerir essa idéia e tentar convencer as outras pessoas do seu time de que aquela idéia pode ajudar de alguma maneira.

Nesse processo todo de exposição e convencimento, devemos prestar atenção em um personagem muito importante que muitas vezes ignoramos, o primeiro seguidor.

Essa pessoa é a primeira que compra a idéia, quando expomos uma idéia nova, não precisamos convencer todos de uma vez, isso é muito difícil, precisamos apenas convencer um, o nosso primeiro seguidor, que esse irá nos ajudar a espalhar a idéia entre as outras pessoas.

Para implantar uma nova idéia, primeiro precisamos ter coragem de levantar e ser ridículo. Expor novas idéias, na maioria das vezes, quebra antigos paradigmas e tira as pessoas um pouco do seu status quo, nem todo mundo gosta disso, mas se bem explicada, a nova idéia tendo fundamento, é tão simples e clara de se seguir que acaba atraindo o primeiro seguidor dela, e essa pessoa acaba mostrando para os outros como seguir a nova idéia, mostrando que é simples de fazer e que vale a pena.

Quando você expõe uma idéia nova, tem que entender que a idéia não é mais só sua, você acabou de compartilhar ela com todos os que acreditaram nela, inclusive o primeiro seguidor, e cabe a você como “líder” dessa nova idéia aceitar isso, deixar a vaidade de lado e abraçar a idéia de que isso se tornou um movimento de várias pessoas.

Esse primeiro seguidor é o que começa a transformar um maluco solitário em líder de um movimento de mudança. Não se trata apenas do maluco mais, e sim de várias pessoas que acreditam na mesma coisa. O primeiro seguidor ajuda a atrair outras pessoas para a nova idéia. Se vocês perceberem, o primeiro seguidor também é um tipo de liderança, é preciso ter coragem para se levantar e seguir um maluco solitário.

Após algum tempo, não se trata apenas de um maluco solitário, nem de dois malucos, e sim de várias pessoas, e com várias pessoas temos um movimento em torno da nova idéia. Novas idéias precisam ser públicas, as pessoas precisam saber delas. É importante mostrar não apenas o líder, que originou a nova idéia, mas seu seguidores, pois os seguidores novos imitam os seguidores antigos da idéia e não necessariamente o líder original. Isso mostra uma evolução da idéia definida pelo grupo que a apoiou.

Quanto mais gente segue uma nova idéia, o risco dela diminui, afinal um monte de gente já está fazendo isso, portanto, mais pessoas querem seguir a nova idéia. Pessoas que estavam em dúvida em relação a nova idéia acabam seguindo com a multidão. Eles não querem ficar de fora da novidade. A curva de adoção de novas tecnologias tem o mesmo princípio (Tecnology Adoption Lifecycle). Depois dos primeiros seguidores, os próximos não se sentirão ridículos, estarão seguros.

Se você for o cara que teve a nova idéia, lembre-se de cultivar os primeiros seguidores da sua idéia, foque em acha-los e trate-os como iguais. É a idéia que interessa, não você.

Mas uma das maiores lições desse vídeo, se vocês perceberem, é que a liderança é muitas vezes superestimada. O cara dançando sem camisa foi o primeiro, e ele receberá todo o crédito por isso, mas foi o primeiro seguidor que transformou o maluco solitário em líder, ele que ajudou a convencer outras pessoas de que a idéia era viável de ser feita.

No mundo atual existe uma idéia de que todos devemos ser líderes, isso é muito valorizado nas empresas, até demais na minha opinião. Se todos fossemos líderes com novas idéias para serem implementadas, não daria muito certo, cada um olharia somente para sua própria idéia. Se duas pessoas tiverem a mesma idéia, ainda haverá uma “briga” sobre quem teve a idéia primeiro.

Acredito que temos que ter o discernimento para reconhecer boas idéias vindo de outros, independente do cargo ou tempo de experiência, e termos coragem de levantar e seguir um “maluco solitário” em sua idéia. Começar um movimento, uma mudança. Quando vocês encontrarem algum maluco fazendo algo grandioso, tenham essa coragem de se levantar e se juntar ao movimento.

Com isso entramos no segundo papel que falei, onde estamos ouvindo a idéia de alguém.

Quando estamos nesse segundo papel, temos que ter avaliar se o que o “maluco solitário” está fazendo é grandioso ou simplesmente idiota. Para isso agimos como críticos da nova idéia, assim como críticos de cinema analisando um filme ou críticos de gastronomia. Mas precisamos ter cuidado quando estamos nesse papel.

Alguém com coragem está nos expondo seu trabalho, sua idéia, correndo o risco de se passar por ridículo. No vídeo a seguir (Egon – Ratatouille), retirado do filme Ratatouille, temos uma ótima visão do que é ser crítico. Nos falando que mesmo a pior das idéias tem mais significado do que o nosso julgamento como críticos. Vejam o vídeo com atenção, e para quem já passou pela situação de criticar alguma nova idéia que um colega expos, pensem como vocês agiram na situação.

No mundo real, podemos estar dos dois lados dessa moeda em diferentes situações. Podemos ser o maluco solitário procurando nossos primeiros seguidores ou podemos ser a pessoa que observa o maluco solitário expondo sua idéia para nós. Em ambos os casos é necessário coragem, ou para submeter nosso trabalho a avaliação de outros ou para julgarmos se um trabalho vale a pena. Apesar do segundo ter menos risco, somente nele temos a oportunidade de apostar em algo novo e mostrar nossa coragem sendo um dos primeiro seguidores da nova idéia, mostrando para outras pessoas como agir.

Pensem nisso da próxima vez que você tiver uma idéia ou ouvir uma de alguém.

A idéia do primeiro seguidor foi retirada da seguinte talk Derek Sivers: How to Start a Movement.

Agile Brazil 2012 – Um grande evento, uma enorme experiência

Olá pessoal.

Hoje vou falar do Agile Brazil, este grande evento que tive a oportunidade de ajudar a realizar e participar.

O Evento deste ano foi sem duvida muito bom, mantendo o padrão de qualidade dos anos anteriores e elevando as expectativas para os próximos eventos.

Da organização:

Ainda no ano passado fiz contato com o Dairton Bassi, já dizendo que gostaria de fazer parte da comissão da organização. Ao longo do ano, o pessoal foi se juntando e formando um comitê organizador, formado por:

Dairto Bassi: grande presidente desta edição. Participativo demais, gente fina, esse coitado sofreu, mas com certeza fez um ótimo trabalho.

Hugo Corbucci: com certeza não é a simpatia em pessoa, mas da pra levar 😛 Focado, das suas sugestões esporros, colaborou muito pra motivar, engajar e cobrar o comprometimento esperado da galera.

Ceci Fernandes: baita menina danada, que gosta de chamar a responsabilidade, gosta de fazer as coisas, multitarefa.

Mariana Bravo: do tipo “mãezona”, um show nas retrospectivas do evento. Pode parecer brava, e é, mas na verdade é objetiva. Parceira minha na coordenação da trilha de Análise e Planejamento.

Fabio Massa: pal pra toda obra. Precisando, tava ele lá. Gente muito boa, prestativo demais.

Matheus Haddad: simpatia em pessoa, sempre de sorriso no rosto. Calmo, adicionando ótimos conteúdos e opiniões as discussões. Esse é fera.

Luca Bastos: com certeza uma das pessoas mais dinâmicas que já vi. Quero chegar á altura do campeonato que ele está (e tá novo ainda) e ser tão disposto, maluco e alegre como esse cara.

Sarah Pimentel: O que falar dela? Simplesmente virei fã desta menina. Do nordeste, com sotaque do sul, morando em SP. Mistura tudo de bom do Brasil, numa única e maravilhosa pessoa (ela e o Elias formam um grande casal). Essa foi porreta, participando de tudo, pra tudo, em tudo. Nota 10.

E também tem toda a galera que não tive tanto contado direto mas estão bem lembrados e nomeados:

http://www.agilebrazil.com/2012/pt/organizacao/

Esse pessoal se dedicou demais para fazer o melhor evento possível. E com certeza o fizeram. Não é nada fácil esta tarefa, mas todos se doaram bastante, alguns mais, outros menos (mea culpa).

Todos os Keynotes agregaram bastante. Mas o do Khawaja Shams sobre sua experiência na NASA foi algo de brilhar os olhos. Muitas pessoas que argumentam que estão em ambientes ou projetos complexos, ou cenários de muitas pessoas envolvidas ou ainda que tenham equipes geograficamente separadas e dizem que não podem usar Agile, vão repensar sobre isso agora.

O Keynote do Neal Ford também foi algo muito interessante, que expande muito a visão do pessoal da área, sobre as abstrações e as disfunções cotidianas que a nossa área está submetida.

Ao longo do evento, puder ver boas palestras como o Rodrigo Yoshima, falando com propriedade do Kanban.

Tive a alegria de introduzir a palestra da Ceci, que foi muito boa, como sempre. O case do Grupo RBS apresentado pelo Luiz Parzianello junto da Thais foi muito boa também.

Jack London, que eu vergonhosamente não sabia que era, fez uma palestra sensacional, coisa linda mesmo. Inspiradora.

Daniel Cukier tocando até violão pra falar sobre startups

Meu amigo e também postador de conteúdo no blog Renato Freire mandou muito bem com sua talk sobre métricas e foi um case vivo para a talk do Daniel Wildt.

E teve mais uma penca de ótimas palestras e workshops. Perdi alguns que eu queria ver, por ser da organização, mas foi uma troca justa.

Em suma, o evento foi sem duvida um grande sucesso.

O evento ainda contou com o Executive Summit e o WBMA em paralelos, que tiveram bons feedbacks também.

E fico feliz por ter feito parte dele, mesmo o Dairton Bassi tendo esquecido de colocar minha foto no slide de apresentação da organização do evento na Abertura. Mas ta perdoado.

Fiquei muito, mas muito feliz mesmo de ver a sala cheia na minha palestra e na minha stand up talk. Não esperava que teria tanta gente. Obrigado a todos.

É isso pessoal. Espero que quem foi ao evento, tenha gostado e que esteja conosco em Brasília ano que vem.

[]s.

Caipira Ágil 2012 – A confirmação

Olá pessoal. Neste post vou falar um pouco sobre como foi poder ajudar a realizar o Caipira Ágil 2012.

Neste ano, tinhamos uma Meta de superar a quantidade de inscritos do ano passado, 130 pessoas. Além disso, queriamos melhorar ainda mais a qualidade do evento com Palestra e Workshop nos mais variados temas, proporcionando um diversidade favorável a quem quisesse aprender.

Mais uma vez, a organização do Caipira Ágil contou com: Alan Braz, Renne Rocha, Renato Freire, Vitor Hugo e eu.

A grade do evento foi:

Abertura (Sala 1)
09h30	Lightning Talks	Introdução aos Métodos Ágeis Fernando Ultremare	Coding Dojo (Scala)	Open Space
11h00	Gestão Ágil André Nascimento	Requisitos Ágeis Matheus Haddad	Coding Dojo (Lua)	Open Space
12h30	Almoço
13h30	Lightning Talks	Qualidade de software: sem balas de prata Jorge Diz	Coding Dojo (Ruby)	Open Space
15h00	Ágil como o MacGyver Luca Bastos	Lean Startup Victor Hugo	Test-Driven Development: seus testes falam; você os ouve? Mauricio Aniche	Open Space
16h30	Coffee-break
17h00	Lightning Talks	Coach para times estressados Manoel Pimentel	Coding Dojo (Java)	Open Space
18h30	Motivação na Gestão 3.0 André Faria

Além disso, contamos com as Lightning Talks:

09h30	O que você está esperando para mudar? Jonas Abreu
09h45	The dark side of the Ruby Ricardo Panaggio
10h00	Afinal, escrever testes atrasam o desenvolvimento? Alberto Leal
10h15	Introdução ao Clojure José Flexa
10h30	Ágil vs. Lean Startup Alexandre Freire
10h45	Porque diabos eu usaria um banco de dados orientado a grafos? Eder Ignatowicz
	Lightning Talks – Tarde
13h30	Quadro de tarefas: além do TO DO, DOING e DONE Gildemar Henrique Borges
13h45	Javascript: o lado bizarro Ricardo Panaggio
14h00	Quão específica deve ser uma User Story (bem sucedida) na gestão Ágil de Requisitos? Daniel Lima Barros
14h15	Testes mais legíveis com Specs 2 Juliano Alves
14h30	Liderança Ágil Rildo Santos
14h45	Você não precisa de um banco de dados! Juliano Alves
17h00	Como implementar um Web Chat em 10 minutos Ricardo Panaggio
17h15	Relacionamento com o cliente: Você está fazendo isso certo? Rafael Valério
17h30	Você não tem um produto Tiago da Costa
17h45	Testes Caipiras Ágeis Ibrahim Cesar

O evento foi um sucesso. Contamos com mais de 200 inscrições, e a participação da galera foi muito ativa, acima de qualquer expectativa.

Vai aqui um penca de links sobre o evento:

Ágil x Lean Startup no Caipira Ágil by Alexandre Freire: http://www.slideshare.net/alexandrefreire/gil-x-lean-startup-no-caipira-gil

Ágil como MacGyver by Luca Bastos http://www.slideshare.net/lucabastos/gil-como-macgyver-caipira-gil-18082012

Vídeos de divulgação do Agile Brazil no Caipira Ágil: http://www.youtube.com/watch?v=_-ABCsbYO8s; http://www.youtube.com/watch?v=AFs3p7HYwoI; http://www.youtube.com/watch?v=b_Y0YTOxvDc; http://www.youtube.com/watch?v=gr93XLhBYcs;

Pessoal da WebGoal no Caipira: http://www.webgoal.com.br/palavra-chave/caipira-agil/

Blog da Concrete Solutions: http://blog.concretesolutions.com.br/2012/08/agil-como-macgyver-no-caipira-agil-parte-1/

Review do Elias Granja Jr: http://eliasgranja.com/2012/08/caipira-agil-2012/

Todas a Talks foram filmadas e em breve farei uma atualização colocando as filmagens e os slides. Colocarei também uma descrição sobre os Workshops e Palestras.

[]s.

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

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 Rothman, Reedy 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 Pimentel e Rafael 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.