Experience

No livro The Influencer, os autores afirmam que se você quer que as pessoas mudem seus comportamentos mais persistentes e resistentes, a primeira coisa que você deve fazer é criar experiências para que as pessoas vivam a situação.

Quando você não puder oferecer uma experiência real para cada uma das pessoas, ainda assim pode oferecer uma experiência vicária (vicarious experiences). Quando as pessoas vêem alguém se dando bem em algo, sua auto-eficiência (para se dar bem)  aumentará, e quando as pessoas vêem alguém falhar, sua auto-eficiência diminuirá. Esse processo é mais efetivo quando uma pessoa vê aquele que sofre a experiência como seu semelhante.

Esta é uma descoberta da ciência social realizada pelo psicólogo Albert Bandura, que realizou diversos experimentos com mudanças e constatou a eficiência da experiência e da experiência vicária (observar outra pessoa da qual você se identifica passando pela experiência).

Essas idéias já foram aplicadas em diversas iniciativas de mudanças globais como, diminuir o medo de cobras mostrando as pessoas medrosas que outras pessoas poderiam se aproximar delas. Mudanças sociais diversas como o incentivo ao uso do preservativo para prevenção da AIDS também foram disseminadas através do uso de experiências vicárias, através da apresentação de dramas familiares de pessoas infectadas que foram exibidos através de tele-novelas. Alias, televisão, filmes, teatro e estórias são excelentes maneiras de criar experiências vicárias, mas lembre-se para que tenha efeito o ouvinte deve identificar-se com o personagem da estória.

O que você quer mudar na sua organização?

Qual é o novo comportamento que as pessoas precisam adotar para que essa mudança aconteça?

Como você pode fazer com que experimentem o novo comportamento?

Pode contar uma estória de alguém de passou a ter o novo comportamento e obteve bons resultados?

Meu primeiro contato com Management 3.0 foi através do livro Jurgen, depois tive a oportunidade de conhecê-lo pessoalmente e participar do curso aqui em São Paulo. Alguns meses depois fiquei muito feliz em receber o convite da Adaptworks para ser um dos instrutores e disseminar as idéias dessa nova gestão que está alinhada com os princípios que acredito e com que tenho praticado desde que conheci os métodos ágeis de desenvolvimento de software. Acredito que mundo precisa de uma nova gestão, e eu quero ser um agente de mudança e inspirar as pessoas para essa transição.

No mês passado estive em Porto Alegre, e já tenho cursos agendados para Campinas, Fortaleza, e Brasília. Fique ligado na agenda do site da Adaptworks.

Meu trabalho na Bluesoft segue normalmente. Apenas estarei fora por alguns dias para ministrar os treinamentos. Inclusive, no podcast da Bluesoft deste mês, recebi Alexandre Magno que também é instrutor de Management 3.0 para discutirmos alguns dos principais conceitos do livro e do curso. Confira.

Agile Podcast

O primeiro deles é o Agile Podcast. Comecei esse projeto logo depois de ter participado do Agile Brazil em Porto Alegre em 2010. A idéia do podcast, era ser curto e objetivo, e tratar de assuntos relevantes a comunidade ágil. Foi um podcast todo em inglês, o que foi um grande motivador para que eu estudasse e praticasse mais o idioma.

Ao todo foram gravados 6 episódios que você pode conferir nos links abaixo (republiquei aqui no blog para desativar o antigo site):

• Agile Podcast #1 – Martin Fowler at the Agile Brazil 2010 Conference
• Agile Podcast #2 – Manoel Pimentel on Coaching
• Agile Podcast #3 – Time for Learning
• Agile Podcast #4 – Pair Programming
• Agile Podcast #5 – Coding Dojos
• Agile Podcast #6 – Six Hats Retrospectives

DeveloperTalkTV

Semelhante ao AgilePodcast, o DeveloperTalkTV, foi um videocast que tratava de assuntos diversos relacionados à desenvolvimento de software. O diferencial é que era em vídeo, publicado no Youtube, e sempre em ambos os idiomas: Português e Inglês. Também foi uma experiência divertida, que me trouxe bons contatos e grande aprendizado.

Ao todo foram gravados 8 episódios, sendo 4 em português e 4 em inglês  (republiquei aqui no blog para desativar o antigo site):

• DeveloperTalkTV – Retrospective Meetings
• DeveloperTalkTV – Reuniões de Retrospectiva
• DeveloperTalkTV – Optimistic and Pessimistic Locking
• DeveloperTalkTV – Lock Otimista e Pessimista
• DeveloperTalkTV – CCC – Card, Conversation and Confirmation
• DeveloperTalkTV – CCC – Cartão, Conversa, Confirmação
• DeveloperTalkTV – Practices Wall
• DeveloperTalkTV – Mural de Práticas

Conclusão

Eu não diria que esse projetos não deram certo. Digo que deram certo! Sim, porque atingi o objetivo que tinha com eles: Promover meu personal brand, e aprender.  É isso que importa. Fica agora o legado para quem quiser matar a saudade.

Não se preocupe, o este blog continuará firme, e o Podcast da Bluesoft também.

Jason Fried thinks deeply about collaboration, productivity and the nature of work. He’s the co-founder of 37signals, makers of Basecamp and other web-based collaboration tools, and co-author of “Rework.”

Referências

• Declaration of Independence

Um dos principais personagens do livro, é Henry Hank Rearden, um personagem capitalista que acredita no trabalho e na produção. Ele possui uma industria metalúrgica que desenvolveu um novo tipo de metal, mais forte e mais leve que o aço. As pessoas de sua família, apesar de viverem e agirem como “parasitas”, vivendo apenas do trabalho de Rearden, sem contribuir com nada, culpam-no o tempo todo de trabalhar demais, e tentam fazê-lo sentir-se culpado por ser egoísta e preocupar-se apenas com ele e com seu trabalho.

No trecho do livro que cito a seguir, a Mãe de Rearden, pede a ele que dê um emprego de importância para seu irmão em sua fábrica, mesmo que este não o mereça, e que não tenha nada de valor para oferecer em troca da oportunidade. Quando Rearden se nega, ela diz que ele não pratica caridade, e que é egoísta e que não se preocupa com a espiritualidade, e que apenas importa-se com o material, que não tem piedade.

Fica o trecho (em espanhol) como um gostinho da obra de Rand. Perceba como valores  podem ser invertidos para manipular pessoas fazendo com que se sintam culpadas por não estarem praticando uma “falsa” caridade, que na verdade, as levaria apenas a praticar a injustiça, favorecendo aqueles não tem mérito e não merecem ser ajudadas.

Su madre se presentó con aire beligerante y defensivo a la vez. Contempló el despacho cual si supiera lo que representaba para él y expresara su resentimiento contra todo lo que Hank pudiera considerar superior a su persona. Tardó mucho tiempo en acomodarse en un sillón, manoseó su bolso y sus guantes, se arregló los pliegues del vestido, y gruñó:»

— ¿Te parece bonito que una madre tenga que hacer antesala y pedir permiso a una mecanógrafa para ver a su hijo y…?

—Mamá, ¿ocurre algo importante? Hoy tengo un día muy agitado.

—No eres el único que ha de enfrentarse a problemas. Desde luego, es algo importante, de lo contrario no me hubiera tomado la molestia de venir.

—¿De qué se trata?

—De Philip.

—Tú dirás.

—Philip es desgraciado.

—Bueno, ¿y qué?

—Cree que no debe depender de tu caridad y vivir de limosnas, sin un dólar que considerar verdaderamente suyo.

—i Vaya! —exclamó Hank, con sonrisa de asombro—. Siempre esperé que un día u otro se diera cuenta.

—No está bien que un hombre sensible y comprensivo se encuentre en semejante posición.

—Desde luego.

—Me alegro de que estés de acuerdo conmigo. Lo que has de hacer es ofrecerle un empleo.

—¿Un… qué?

—Darle un empleo aquí, en las fundiciones; pero un cargo bonito y agradable, con su despacho y su escritorio y un salario adecuado, sin obligarle a que se mezcle con tus obreros ni con tus malolientes hornos.

Comprendió que aquellas palabras habían sido efectivamente pronunciadas; que no se trataba de una ilusión, aun cuando apenas pudiese creerlo.

—Mamá, tú no hablas en serio.

—Desde luego que sí. Sé muy bien lo que desea, pero es tan orgulloso que no se atreve a proponértelo. Ahora bien, sí tú se lo ofreces y le haces comprender que solicitas de él este favor, no sabes lo feliz que va a sentirse. He venido expresamente a este lugar para que no sospeche que te he sugerido nada.

No entraba en su naturaleza comprender lo que estaba escuchando. Un pensamiento único le atravesó la mente como un rayo luminoso, llevándole a la conclusión de que nadie podía dejar de verlo. El pensamiento había surgido de él como un grito de asombro:

—¡Pero si no sabe nada de este negocio!
—¿Y eso qué tiene que ver? Necesita un empleo.
—No puede realizar ningún trabajo aquí.
—Ha de adquirir confianza en si mismo y sentirse importante. —No me será de ninguna utilidad.
—Debe sentir que alguien desea su colaboración.
—¿Aquí? ¿Y para qué lo quiero yo aquí?
—Das trabajo a muchas personas desconocidas.
—Contrato a hombres que producen. ¿Qué puede ofrecerme él?

Cockburn

• “A Comunicação é como o perfume: muito mais forte quando de perto.”
• A pior forma de comunicação é através de texto, e ainda assim é  forma mais utilizada nos dias de hoje pelas empresas.
• Em um ambiente realmente colaborativo, as pessoas sentem-se à salvo o suficiente para falar das coisas que não estão indo bem, sentem-se à vontade para contar sobre o que está indo mal, fazem isso bem rápido. As pessoas devem estar abertas para ouvir sobre o que estão fazendo que não está dando certo e que devem estar sempre prontas para mudar.

Assista o vídeo:

No livro “the Influencer” [1], os autores afirmam que as pessoas tentaram mudar de comportamento se acreditarem que  vale a pena e que podem fazer o que for preciso para a mudança aconteça.

Imaginação

Para tentar influenciar as pessoas a adotar um comportamento novo ou deixar um comportamento antigo, a grande maioria das pessoas tenta utilizar a persuasão verbal, que para os autores do livro, apesar de ter certo grau de eficácia, nem se aproxima da eficiência de permitir que as pessoas experimentem por si mesmas os benefícios das mudanças (ou seja, do novo comportamento proposto).

Quando não for possível oferecer uma experiência real, você poder oferecer uma experiência imaginária contando estórias (sejam elas reais ou não). Narrativas comoventes permitem que os ouvintes viajem no conteúdo através da imaginação e passem por experiências mentais.

Estórias permitem que as pessoas criem imagens detalhadas e concretas em suas mentes, criando empatia com a estória e sentindo seus efeitos a um nível pessoal, e é por isso que estórias são muito mais eficientes do que aulas tradicionais, afirmam os autores.

Certifique-se de que sua estória deixa bem claro o comportamento atual e seus efeitos, assim como o comportamento futuro e seus benefícios para que os ouvintes possam passar pela experiência a medida que ouvem a estória. Não se esqueça que a estória deverá também deixar claro o porquê a mudança de comportamento vale a pena, e transmitir a idéia de que ouvinte é capaz de realizar a mudança de comportamento.

Note que estórias são muito poderosas e podem influenciar comportamentos. Os gregos sabiam muito bem disso, e por isso grande parte da sabedoria deixada por eles está representada em forma de contos e mitos.

Referências

[1] - Influencer: The Power To Change Anything por Kerry Patterson, Joseph Grenny, David Maxfield, Ron McMillan, Al Switzler

O propósito de Reuniões de Backlog Grooming é aprimorar o Backlog.

A palavra Grooming em inglês significa cuidar da aparência, manter limpo e arrumado. Para facilitar a semântica do artigo, traduzirei “Backlog Grooming” como “Organização do Backlog“, considerando que organizado é por consequentemente limpo e arrumado. Alguns autores preferem chamar de Refinamento de Backlog [4].

Backlog Grooming

Organizar o backlog é uma processo contínuo que envolve:

1. A descoberta de novos itens, assim como alteração e remoção de itens antigos [2].
2. Quebrar Estórias muito grandes (épicos) [1].
3. A priorização dos itens do backlog (trazendo os mais importantes para o topo) [2].
4. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento [2].
5. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas) [2].
6. Incluir Critérios de Aceitação [1].

Muitas equipes que utilizam métodos ágeis como Scrum e XP, reclamam que suas reuniões de planejamento “levam uma eternidade” [1]. Sessões de Backlog Grooming, podem ser utilizadas como uma ferramenta simples e rápida para tornar as reuniões de planejamento mais eficientes.

Embora a manutenção do Backlog seja de responsabilidade do Product Owner, outros membros do time podem colaborar na reunião de Organização do Backlog, Ken Schwaber sugere a participação de 10% da equipe[3] durante de 5 a 10% do tempo da Sprint [4], de forma a incentivar a comunicação face-a-face entre as pessoas ao invés de outros meios como comunicação por e-mail ou documentos.

Roman sugere a utilização de cartões de papel como ferramenta para facilitar a colaboração na reunião, cada participante pode pegar um cartão e escrever suas ideias. Depois, estas podem ser agrupadas e, caso necessário, pode-se transferir as informações para uma ferramenta eletrônica [2], como o Pronto, por exemplo.

Referências

• [1] How to Hold an Effective Backlog Grooming Session by Angela Druckman
• [2] Agile Product Management with Scrum: Creating Products that Customers Love by Roman Pichler
• [3] Schwaber, Ken. 2007. The Enterprise and Scrum. Microsoft Press
• [4] Scaling Lean & Agile Development by Craig Larman; Bas Vodde

“Tudo que pode ser contado não necessariamente conta; Tudo que conta não necessariamente pode ser contado.”
Albert Einstein

Recentemente falamos do papel do Tracker no método XP (Extreme Programming), que entre outras coisas deve ficar atento às métricas. Vejamos agora que tipos de métricas existem e quais podem ser úteis em um ambiente de desenvolvimento de software.

Tipos de Indicadores

Jurgen Appelo [2] e Mike Cohn [3] recomendam que se use ambos os tipos de indicadores:

Indicadores Indutores (Leading indicators): ajudam a detectar um aumento na probabilidade ou na gravidade de um evento antes que apareçam nos indicadores de resultado [1].  Quando um indicador indutor muda, ele indica que você pode estar no caminho para atingir um objetivo ou meta [2]. Por exemplo, aumentar a cobertura de testes ou a quantidade de testes criados pode indicar mais qualidade no produto [2].

Você pode ter diversos objetivos em uma equipe de desenvolvimento de software, como por exemplo, aumento na qualidade, aumento na produtividade, produção de melhores estimativas, redução do custo do desenvolvimento, maior previsibilidade do cronograma, aumento na satisfação do usuário, releases mais frequentes, etc. [3]. Para cada objetivo você deve ter ao menos um indicador indutor e um de resultado [3].

Indicadores de Resultado (Lagging indicators): ajudam a confirmar que um evento pode ocorrer e reagem mais lentamente às mudanças no ambiente do que os indicadores indutores [1]. São métricas que verificam que você atingiu seu objetivo depois de ter completado o trabalho. Por exemplo, reduzir o número de defeitos reportados por clientes aponta que a qualidade do produto de fato melhorou.

Balanced Scorecard

De acordo com a Wikipedia, “Balanced Scorecard (BSC) é uma metodologia de medição e gestão de desempenho desenvolvida pelos professores da Harvard Business School, Robert Kaplan e David Norton, em 1992” [6]. Kaplan e Norton percebiam o fato de a maioria das organizações gerenciarem os negócios através apenas de métricas financeiras como um problema, por isso, o BSC visa a integração e balanceamento de todos os principais indicadores de desempenho existentes em uma empresa de modo holístico, ou seja, visando a organização como um todo. O BSC é formado por quatro perspectivas que devem ser equilibradas:

1. Financeira: Gerenciar bem o dinheiro é fundamental para a sobrevivência de qualquer negócio em um sistema capitalista como  este em que estamos inseridos. Você precisa saber de onde vem o dinheiro da sua organização e onde o investirá;
2. Clientes (satisfação com a organização, produtos e serviços): Pergunte-se o seguinte: “Será que cada pessoa da minha organização sabe o que os clientes querem e como o trabalho deles afeta os clientes? [7]” Vá em frente e faça essa pergunta para eles. Que tipo de resposta você recebeu? Algo genérico como “Humm…. um trabalho de qualidade, acho..”, ou algo específico e mensurável? Você precisa saber quem são seus clientes e o que eles querem de você para atendê-los bem.
3. Processos internos (criação de valor): Diz respeito aos processos relacionados ao suporte à produção ou prestação de serviços da organização;
4. Aprendizado e Crescimento (treinamento, educação, conhecimento): Cuidar das pessoas e do desenvolvimento de competências.

Métricas - http://www.roselladb.com/balanced-scorecard.htm

Este curto vídeo apresenta de maneira bem didática os conceitos do BSC (em inglês): http://www.youtube.com/watch?v=AdXt8BfiGJg

Agile Balanced Scorecard

Steve Garnett sugere 4 áreas para que os times ágeis criem Balanced Scorecards, para acompanhar métricas importantes, com quatro áreas distintas:

1. Valor de Negócio: através de um Burndown Chart.
2. Débito Técnico: não aderência a Definição de Pronto (DoD) e Padrões de Qualidade
3. Melhoria Contínua: Retrospectiva, Planos de Ação, Impedimentos Levantados e Removidos
4. Lean: Tempo de Ciclo e Quantidade de Desperdício

1. Produto: Estamos criando produtos que agregam valor para nossos clientes?
2. Finanças: Estamos conquistando bons resultados financeiros?
3. Equipe: Estamos trabalhando bem juntos como equipe para atender às necessidades dos stakeholders?
4. Cronograma: Estamos conseguindo atender os prazos estabelecidos?

Indicadores Chave de Performance (KPIs)

“What You Measure Is What You Get”
John H. Hummel and William G. Huitt [11]

Há 3 tipos de KPIs:

• Números (quantidades): 2988 defeitos, 689 produtos vendidos, 788 novos clientes.
• Progresso (percentual de completo): 5% pronto.
• Alterações: 5% mais clientes, 10% de aumento nas vendas no último mês.

http://www.youtube.com/watch?v=NCta6j5_FdM

KPI’s geralmente estão associados com metas: Quanto clientes queremos conquistar neste ano? Qual o percentual de redução de defeitos esperado? Quantos story points o time espera entegar? etc.

Segundo Dave Nicolette [8], uma Métrica é um padrão para medir ou avaliar algo, já uma Medida é uma quantidade, uma proporção, ou comparação quantitativa de alguma natureza.

No artigo Appropriate Agile Measurement, Deborah Hartmann Preuss e Robin Dymond apresentam características das boas métricas ágeis, algumas delas são [9]:

• Confirmam e reforçam princípios de Lean e Agile
• Medem Resultado e não Produção
• Acompanham tendências, não números
• São fáceis de se coletar
• Oferecem combustível para discussões significantes
• Podem medir Valor (produto) ou Processo

Para John Seddon as características dos bons KPI são:

1. O KPI está ligado a um propósito do stakeholder.
2. O KPI ajuda a melhorar um aspecto do sistema.
3.  O KPI é parte do trabalho daqueles que estão interessados nele.

Jurgen Appelo afirma que deve-se medir para atender a necessidades de diferentes stakeholders e perspectivas [2]:

1. Colaborador
2. Time
3. Organização
4. Cliente
5. Fornecedor
6. Gerente
7. Comunidade

Exemplos de Métricas e KPI’s

Note que nem todas vão atender as recomendações supracitadas.

Métricas

• Lead time: O tempo entre o pedido do cliente e a entrega (o início e o fim do proceso). Ex: 2 dias do backlog (registro do pedido do cliente) à produção (entrega do software funcionando).
• Cycle time (tempo de ciclo): O tempo total entre o início e o fim da produção ou da prestação de serviço. Ex: 6 horas por estória de usuário do “to do” ao “done“.
• Takt time: Takt é uma palavra em alemão que significa batida de orquestra [7], refere-se a taxa (batida, ritmo) em que um processo é capaz de operar para atender a demanda dos clientes. Ex: A equipe desenvolve 14 story points a cada 2 horas.
• Defeitos por unidade: A quantidade de defeitos para cada unidade produzida ou serviço prestado. Ex: Defeitos por Estória de Usuário Desenvolvida. Há variações como defeitos por milhão, ou defeitos por milhão de oportunidades.
• Nível de Maturidade em Competências: Quais são as habilidades ou competências chave que as pessoas devem desenvolver para que seu negócio tenha sucesso? Como as pessoas estão em nível de maturidade para cada uma dessas competências?
• Custo do Retrabalho
• Valor Agregado
• Horas Trabalhadas
• Linhas de Código
• Cobertura de Testes
• Quantidade de Casos de Teste
• Lucro
• Velocidade do Time
• Throughput (Produção)
• Happiness Index da Equipe
• Trabalho em Progresso (WIP)

Dashboards

O painel (dashboard) do seu carro te fornece informações precisas de forma rápida e confiável sobre a situação atual dos principais elementos necessários para que o automóvel possa operar com perfeição: combustível, temperatura do carro, velocidade, autonomia, etc. Da mesma forma recomenda-se que você use um dashboard com as principais métricas e indicadores de performance da sua organização, para que possa rapidamente identificar como as coisas estão caminhando e tomar providências se necessário.

Dashdoard

Alguns softwares como o VersionOne, criam um Dashboard para projetos com base nos dados das Iterações:

Dashboard no VersionOne

Ferramentas para Medição

Cada plataforma e linguagem de programação possui um conjunto de ferramentas específicas para colher métricas no código fonte produzido por um time de desenvolvimento de software, mas essas são algumas interessantes que podem ser usadas na plataforma Java:

• Sonar – Oferece uma série de métricas interessante como complexidade ciclomática e código duplicado. Possui dezenas que plugins que podem oferecer métricas das mais diversas naturezas como bugs óbvios (FindBugs), alinhamento aos padrões de codificação do time (PMD, Checklist, JLint), entre outras coisas [8].
• JDepend – Mensura dependências entre objetos.

Desafios

• Quais métricas você e seu time utilizam?
• Suas métricas agregam valor, motivam o time ou os ajudam a melhorar de alguma forma?
• Suas métricas atendem as diversas características que os especialistas apontam para “métricas ágeis”?
• Que tal criar um Balanced Scorecard para garantir que a Estratégia de Organização está Equilibrada?
• Que tal criar um Dashboard para seu Time?

Referências

• [1] The Complete Idiot’s Guide To Risk Management by Annetta Cortez; Bob Yehling
• [2] Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo
• [3] Succeeding with Agile: Software Development Using Scrum by Mike Cohn
• [4] Agile Metrics: Agile Balanced Score Card
• [5] Agile Balanced Score Card
• [6] Wikipedia – Balanced Scorecard
• [7] Balanced Scorecard Strategy For Dummies®
• [8] Dave Nicolette – Agile Metrics
• [9] Appropriate Agile Measurement
• [10] Freedom from Command and Control: Rethinking Management for Lean Service by John Seddon
• [11] What you Measure is What You Get