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:

Pré Game

stakeholders

roi

fronteira

macrovisaofuncionalprovaconceito

meta

Anúncios

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.

Práticas Lúdicas. O que são e como podem lhe ajudar

Olá caros amigos.

Hoje vamos falar sobre Práticas Lúdicas e seguindo a linha de sempre, vamos comer o boi a bife.

Lúdico:

adj. Relativo a jogo, a brinquedo; que apenas diverte ou distrai: atividade lúdica.

Ludico é uma forma de desenvolvimento da criatividade, conhecimentos e raciocínio através de jogos, atividades artísticas e etc. O intuito é ensinar, através da diversão e buscando a interagração entre as pessoas.

Prática/Atividade Lúdica:

Atividade lúdica é todo e qualquer movimento que tem como objetivo produzir prazer quando de sua execução, ou seja, divertir o praticante.

Sumariamente teríamos as seguintes características sobre elas:

  • são brinquedos ou brincadeiras menos consistentes e mais livres de regras ou normas;
  • são atividades que não visam a competição como objetivo principal, e mas a realização de uma tarefa de forma prazerosa;
  • existe sempre a presença de motivação para atingir os objetivos.

By Wikipedia

Como visto, práticas lúdicas são formas bem interessantes de aprendizado. E o que é realizar um projeto ou produto senão uma razão de um aprendizado sobre algum tema, num espaço de tempo.

Veja que, as práticas lúdicas tem um aporte de diversão, brincadeiras e busca inspirar, motivar e ajudar a atingir metas. Percebe o quanto uma Prática Lúdica está alinhado com o Core do Ágil?

Dito isto, como será que as Práticas Lúdicas podem lhe ajudar?

Bem, como disso no parágrafo anterior, a prática lúdica tem por o objetivo o ensinamento de modo divertido. Em projeto o Time aprende o negócio/domínio sobre um tema, e eles traduzem isto em um produto.

Este aprendizado pode ser feito de forma lúdica no período do desenvolvimento do produto. Metódos ágeis (alguns deles) denotam a fase do Pré Game. Fase onde existe um aprofundamento no negócio e na tecnologia com a intenção de clarear um pouco o caminho.

Nesta fase o aprendizado é fundamental. Tratar esta fase de uma forma mais dinâmica, participativa e descontraída pode auxiliar a absorvição do Time sobre o conteúdo a ser ensinado. Eis aí um bom ponto onde você pode usar uma prática lúdica.

Ano passado eu criei e neste ano apliquei e desenvolvi um Jogo chamado Domain Game: https://agilementoring.wordpress.com/2011/07/05/domain-game-uma-dinamica-para-todos/

O jogo é uma prática lúdica que visa disseminar o conhecimento sobre um domínio a todo o Time, que envolve também a participação dos Clientes e Experts, estimulando a interação entre eles, a colaboração e motivando-os.

E o uso das práticas lúdicas não param por aí.

Seja em Workshops ou Treinamentos, a utilização de tais práticas ajudam muito a manter um ritmo gostoso no ensino, de forma leve e descontraída.

Como isto está bem ainhando ao Core Ágil, não demorou muito para vários gurus da área criarem um grupo para trocarem ideias e experiências. Nasce assim o Google Group Agile Games:

http://www.hanoulle.be/2010/06/agile-games-google-group/

http://groups.google.com/group/agilegames?pli=1

Eu acompanho o grupo e já tive várias oportunidades de usar jogos descritos lá. O pessoal realmente se supera 🙂

Descorrendo mais sobre práticas lúdicas no dia-a-dia de um Time ágil, não é apenas no Pré Game que é possível utiliza-las.

Ao decorrer da Sprint, você pode utilizar de práticas lúdicas para auxiliar o Time no entendimento de uma User Story, auxiliar a criar cenários de testes (adoro fazer analogias a RPG para isso).

E existe mais um ponto num ambiente ágil onde é muito viável utilizar práticas lúdicas e particularmente, acredito que seja fundamental utiliza-las. Retrospectivas.

Como sabem, a Retrospectiva é o momento onde um Time busca olhar e entender para tudo o que se passou em uma iteração. Neste momento o Time buscará colocar em prática o must da Inspeção e Adaptação.

Instigar aos membros do Time para fazer isto não é fácil. É muito comum com o passar do tempo um Time perder o interesse numa Retrospectiva, achando que ela se tornou monótona. É fundamental para um Scrum Master, um líder ou mesmo para o Time em si saber maneiras de manter o ânimo numa Retrospectiva, com eficiência e eficácia para manter o ciclo da melhoria contínua.

Eu gostava de usar algumas práticas como:

Conclusão de frases:

Eu criava algumas frases e deixava lacunas para os membros do Time completarem. Geralmente as frases eram brincadeiras que buscavam o sentimento/opinião dos membros do Time sobre o ambiente do produto, exemplos:

  • Se o meu projeto fosse um animal, ele seria um(a) _________________________________________________
  • Se eu fosse o Super Man, a Criptonita desta Sprint foi a/o ____________________________________________
  • Se eu fosse a Mulher Maravilha, utilizaria o meu laço mágico para agarrar a/0 ______________________________
  • Rosas são vermelhas, violetas são azul (são??) neste Srint eu queria _____________________________________
  • Se eu fosse o Thor, utilizaria o meu Martelo para acabar com a _________________________________________

Quando o Time é mais novo, gosto de fazer práticas para lhes ensinar sobre auto-gerenciamento, colaboração e ROI.

Dinâmicas como formar uma fila com base em alguma premissa, construir alguma coisa juntos e separados, com material dividido entre eles, brincar de Passa ou Repassa, sobre o que estão fazendo, se está agregando valor.

Dentre cursos, treinamentos, workshops que participei, legal levantar algumas pessoas que utilizam muito bem isto:

  • Alexandre Magno: durante seus CSM e CSPO e workshops, ele utiliza várias dinâmicas para explicar o Core do Ágil e Scrum
  • André Nascimento: Durante seus workshops de Scrum ele utiliza várias dinâmicas, inclusive a Famosa Dinâmica do Avião de Papel
  • Manoel Pimentel: Durante o Agile Coach Professional, ele se supera utilizando 1001 práticas
  • Hugo Corbucci e Mariana Bravo: Lean Lego Game, uma fantástica brincadeira para ensinar os conceitos do Lean
  • Matheus Hadda: Utiliza várias práticas para ensinar Scrum, como a Horta e também para ensinar sobre o Canvas Business Model.

Eu também utilizo do Lúdico para realizar Análise de Negócios, seja através de perguntas ou pequenas dinâmicas que faço com o pessoal entrevistado.

E é isso pessoal.

E você conhece mais algumas práticas lúdicas? Já utilizou alguma? Como foi?

[]s e até a próxima.

Caipira Ágil – A alegria de se fazer este evento

Neste post quero comentar sobre a alegria de ter realizado junto com outros amigos o Caipira Ágil.

Em menos de um ano conseguimos ter uma ideia, ver o seu valor e então apostar nela.

No Encontro Ágil 2010, Renato Freire, Vitor Hugo, Alan Braz e eu tivemos a ideia de realizar em Campinas um evento do mesmo foco. Um evento que fosse mais dinâmico, participativo e colaborativo. Com o evento, buscaríamos alavancar a comunidade de desenvolvimento de software na RMC (Região Metropolitana de Campinas). Durante o papo com eles no Encontro Ágil, foi dito o nome “Caipira Ágil” e seguiu-se de gargalhadas. Sentimos que o nome tinha poder 😀

Durante um HHA (Happy HourÁgil) em Campinas, conversamos com mais pessoas sobre a ideia e com isto o Renne Rocha e o Alberto Leal se juntaram a nós e ai formou-se o grupo dos organizadores.

Para facilitar a comunicação, montamos um grupo no Google e então começamos a botar a mão na massa.

A tarefa não foi fácil. Alguns já tinham até oganizado alguns tipos de eventos antes, mas nada como o vindouro Caipira Ágil. Nossa primeira atitude foi definir uma visão do que seria e pra que seria o evento. Segue um trecho dessa visão:

Alavancar a comunidade de desenvolvimento de software localizada na RMC, incentivando e estimulando a realização de eventos, Dojos, encontros, grupos de usuários e estudos. A RMC é um pólo industrial muito importante, com grandes empresas e importantes faculdades, mas é muito pobre na realização de eventos.

Com a visão em mente, começamos a corrida. Definições de grades, patrocinadores, horário, data, comida, e etc.. Tenha certeza que esta foi a parte mais simples e mais desgastante. Aprendi muito sobre como li dar com opiniões diferentes, definições em grupos e etc.

Convocamos aqueles que achamos que agregariam ao evento para realizar os Workshops, viabilizamos todo os gastos do evento com os patrocínios sem finalidade alguma de obter lucro com o ele. Com o valor pago pela inscrição, buscamos oferecer uma refeição de qualidade e durante todo o evento (o que sinceramente achei um grande diferencial do Caipira).

Fizemos uma coisa interessante: Quem realizasse inscrição no evento, poderia submeter lighting talks. Um ponto que foi relamente bem legal no evento.

Nossa meta era de ter 150 pessoas inscritas no evento. As inscrições ficaram no ar por cerca de 2 meses e o evento aconteceria logo após a maratona do Agile Brazil e TDC.

Agora compartilho com vocês os números do evento, que nos deixaram muito orgulhosos:

Tivemos 186 inscrições, sendo que 131 foram confirmadas. No dia do evento, tivemos cerca de 130 pessoas, tendo inscrições feitas no dia. Para se ter uma ideia, o Encontro Ágil 2010, em sua terceira edição teve em torno de 200 pessoas.

Tivemos profissionais de aproximadamente 80 empresas diferentes. Sem duvida, uma das nossas metas foi atingida.

Tivemos um ótimo evento. As talks foram muito boas, bem legais e divertidas, com muita improvisação. Workshops fantásticos, um Dojo com mais de 30 pessoas, open spaces interessantes e até sessões de Ignite Presentations.

Quero agradecer de coração todos aqueles que participaram do evento, que ajudaram no evento, que falaram sobre o evento e que pensaram no evento.

Como dissemos ao final do Caipira Ágil: “O Evento terminou, mas não seus objetivos”. Vamos buscar manter ativa esta comunidade, com mais eventos, encontros, conteúdos e tudo o que for possível.

Para ver as fotos do evento, slides de apresentações, videos e tudo mais, acesso o Blog do Caipira Ágil.

Já adiantamos que em breve teremos um evento sobre Startups em Campinas (Estartapi Caipira, sô!). Acompanhe a gente no Blog do Caipira Ágil e fica atento a tudo mais que vem por aí.

[]s.

Agile além da fazenda: os desafios e interesses de uma empresa

Esse foi o tema da minha palestra na trilha de Agile do TDC 2011.

Fazenda é uma metáfora para o ambiente físico de desenvolvimento de software.

No início do ano 2000, nós tínhamos um cenário desfavorável no desenvolvimento de Software. O Chaos Report demonstravam que os índices de sucesso em projetos eram por volta de 20%. Indefinições quanto a processos e ferramentas eram grandes, PMP lotavam as gerencias e o CMMI estava em alta.

Nesse conturbado cenário, um grande grupo de pessoas ligadas a desenvolvimento de software reuniram-se em Utah nos EUA e deram luz ao Manifesto Ágil de desenvolvimento de Software.

Com esse ato, métodos, metodologias, frameworks e práticas ligadas a “cultura ágil” foram impulsionadas. Começamos a por um pouco de ordem na nossa fazenda. Começou-se a mudar a cultura “fabril” na Fazenda. Pessoas começaram a ser valorizadas. Suas opiniões mais ouvidas, seus problemas, mais entendidos e isto foi bom.

Melhoramos mais nossas práticas e ferramentas, e o resultado foi bom. O Chaos Report de 2004 a 2008 mostrou os resultados destes esforços. Índices de sucesso e quase 40%. Porém foi neste período que aqueles tidos como “comprometidos” começaram a perder um pouco o foco.

A empolgação com este novo tratamento digno aos antes esculachados “Comprometidos” fez com que a soberba e orgulho saltassem além de limites seguros.

As responsabilidades aumentaram, e com isso uma turbulência veio. Começou-se uma briga entre aqueles denominados “Comprometidos”. Estas brigas envolviam discussões intermináveis sobre métodos e ferramentas. Discussões sobre certificações, balas de pratas, cases de sucesso,  nome, renome. E nisto, perdeu-se o foco mais ainda das novas dificuldades e desafios que emergiam.

Aí percebeu que tinha alguma coisa errada. A vaca poderia estar indo pro brejo.

Aquilo que fora antes disseminado como cultura, estava agora jogado ao mercado como “produto de caixinha”. Atitudes para melhoria, foi alterada para modelo econômico. E o pessoal da fazenda esqueceu um pouco do seu desafio, da sua paixão. Parou de olhar para aqueles que fazem parte do fluxo de entrega do seu fruto, perdeu um pouco de vista o pessoal da “Feira”, tanto vendedores quanto os compradores.

E o Chaos Report de 2009 foi implacável. Caímos de novo.

A Fazenda estava ficando triste, vazia…

É notável a evolução que o Manifesto Ágil trouxe. Mas o Manifesto em si, não é um fim, e sim um meio para atingir algo maior e melhor.

Aqui começa nossa reflexão: Quais são os desafios e interesses de nossas Empresas?

Uma Empresa tem um objetivo. Satisfazer uma necessidade que tenha valor a um Cliente. Ou então, gerar valor ao Cliente/Mercado, mesmo que este hoje nem saiba que precisa (vide Apple, Nintendo e outras empresas).

Dado que uma Empresa busca satisfazer a necessidade que um Cliente tem, ela também busca uma remuneração por seu esforço. Toda Empresa é feita para obter lucro. Esses em suma são os interesses de uma Empresa. Algumas porém dão mais valor ao Cliente enquanto outras dão mais valor para o Lucro, mas isto é outra história.

Com estes interesses em mente, uma Empresa tem o desafio de tentar gerar o produto de maneira menos custosa, mais rápida e com diferencial. Perceba que até este ponto, não é interesse nem desafio de uma Empresa “fazer Agile” ou “ser Agile”.

Agile é um dos vários meios que uma Empresa utilizará para poder atingir seus interesses. E o desafio da empresa não deve ser de “fazer o melhor Agile possível” pois, você pode afirmar que utilizar “Agile” além dos limites da Fazenda trará benefícios?

É obvio que a mudança da cultura na Fazenda traz benefícios, mais tenha em mente que uma Empresa busca satisfazer um cliente. A Fazenda faz parte de um meio ambiente muito maior. E é aqui que muitos ainda erram. Tentar levar SCRUM para o setor de Vendas da Empresa, pode não ser uma boa ideia. Ao mesmo tempo que quando buscamos trazer todos os envolvidos no projeto de um Produto para uma reunião, pensasse sempre em trazer um Cliente. Mas pare para pensar: O setor de Vendas não está envolvido no Produto? Como um vendedor pode vender um produto cujo ele não conhece e não ve crescer? E geralmente, você tem alguém de Vendas nas suas reuniões do Produto?

E expanda este pensamento. O pessoal do Suporte participa das reuniões? Pessoal de Treinamento ao Cliente? Implantadores?

A nossa visão na Fazenda ainda é uma visão de “Projeto”, enquanto o desafio de uma Empresa é fazer e entregar “Produto” (obviamente com valor maximizado ao Cliente).

Enquanto estivermos focado em fazer o “melhor Agile” será difícil expandirmos nossos horizontes e realmente trazer melhorias sistêmicas para toda a Empresa.

O Pensamento Enxuto (Lean Thinking) vem se apresentando como uma das ferramentas que auxilia muito nessa expansão da visão e geração de comprometimento. Ter uma Visão do Seu Fluxo de Valor e dar visibilidade a este Fluxo são iniciativas simples que podem ser feitas.

Temos muito para melhorar, e isto é bom para quem realmente busca tanto uma Fazenda melhor, quanto um ecossistema inteiro melhor.

Link para os slides da apresentação no TDC 2011.

Gostaria de agradecer a todos que ficaram e participaram da minha Palestra, que na verdade, foi uma continuação do Painel realizado no TDC. Foi realmente muito divertido e gratificante.

Os Desafios do Desenvolvimento de Software

 

Os desafios de se desenvolver softwares vão muito mais além do que problemas de processos e procedimentos. Trabalhar com expectativas, transferir e compartilhar conhecimento, motivação e um bom ambiente são exemplos de aspectos que devem ser considerados muito importantes no desenvolvimento de um software. Cada vez mais fica claro que o foco de pontos a melhorar e a melhoria contínua provem e depende das pessoas comprometidas
com o desenvolvimento do software. Isto nos eleva a um novo patamar na cultura de desenvolvimento de software, onde, tanto quanto a Ciência de Software é considerada uma área Exata, sua aplicabilidade se demonstra cada vez mais uma área Humana.

A evolução de uma prática, processo ou produto somente acontece através da evolução de Pessoas. Esta evolução está cada vez mais presente nas necessidades do desenvolvimento de software atual. Evoluirmos como Pessoa, como um Time unido, através de colaboração, confiança e comprometimento são atitudes que se mostram eficazes e eficientes para vencer os desafios de desenvolver um software. Esta cultura que já nasceu e está sendo disseminada,
uma cultura voltada a Pessoas e a interação entre elas, voltada ao real valor agregado aos clientes, simples e leve vem se fortificando, se adaptando as necessidades e dando novos ares a forma que se desenvolve software.