quinta-feira, 12 de abril de 2018

Feel Driven - Caminhando por orientação dos sentimentos

História inicial

No meio de maio de 2017, uma nova squad nasce dentro da estrutura luizalabs que atua na área da logística. Havia apenas o Product Owner (PO) e o Tech Lead (TL). Eu atuava como Agilista em outra Squad, mas não como protagonista, pois havia outro Agilista atuando na linha de frente. Foi quando recebi o convite para compor a nova squad recentemente formada. Agora éramos o PO, o TL e eu como Agile Coach (AC).

Primeiro desafio: formar a equipe para cumprir a missão da squad

Trabalhamos com missões, e a squad precisa ser composta de pessoas que, juntas, tenham poder de alcançar a realização da missão. Como éramos apenas a liderança compartilhada, precisávamos correr atrás de pessoas para compor o time.

Tínhamos o tempo contra nós. Passamos a procurar perfis que fossem compatíveis com o que precisávamos. O TL e eu fizemos inúmeras agendas com entrevistas a pessoas que encontrávamos. Foram manhãs, tardes e até noites falando com possíveis desenvolvedores. A base de relacionamento foi muito importante neste momento.

No início de outubro fechamos a equipe, contratando o último desenvolvedor. Durante o processo de contratações, enquanto os desenvolvedores iam chegando, nós já passávamos a encarar o segundo desafio.

Segundo desafio: conhecer o cliente interno e o que fazer para ajudá-lo

Paralelo às contratações, fazíamos nosso trabalho de ir a campo e entender as necessidades do nosso cliente interno. Fizemos 4 gembas neste tempo para levantarmos tudo o que achávamos necessário na visão do cliente e assim buscarmos alcançar o atingimento da missão.

Nosso trabalho foi muito em uma espiral evolutiva, enquanto buscávamos desenvolvedores, estudávamos as necessidades do cliente, refinávamos estas necessidades e construíamos os MVPs.

Apesar do time ter sido formado, em sua maioria por desenvolvedores JR e PL, tinham uma performance consideravelmente boa. Claro, havia muita coisa a ser melhorada, mas o mais importante naquele momento, devido ao tempo e à missão a ser alcançada, era manter o time engajado e motivado. Neste sentido, surgiu meu grande desafio, que chamaria aqui de terceiro e estratégico desafio.

Terceiro desafio: manter o time engajado e motivado

Bem, o time já está construindo o produto. Com o dia a dia, muitos pensamentos, sentimentos e comportamentos são alterados, e a oscilação do engajamento e motivação torna-se algo preocupante. No início, ainda com poucos desenvolvedores, e no decorrer do tempo, novas contratações, os relacionamentos geram alguns atritos que refletem na produtividade e na qualidade do que se produz.

Após identificar que os gatilhos eram os sentimentos, pensamos em uma maneira de sustentar o engajamento e a motivação, desenvolvi uma maneira de "coletar" semanalmente os sentimentos dos envolvidos e através dos resultados desta coleta, termos um norte de onde devemos atuar e gastar mais energia para que a balança fique equilibrada.

Dividi esta coleta em dois níveis de sentimentos: em grupo e individual

Em grupo

Nesta coleta de dados, geramos 3 tópicos a serem avaliados sempre relacionado à última iteração (que no nosso caso era semanal). Os tópicos eram: Técnico (qual a minha visão e satisfação quanto ao nível técnico?), Processo (qual a minha visão e satisfação quanto ao nível de processo/método?) e Pessoa (qual a minha visão e satisfação quanto ao nível de pessoas?). Junto à isso, coletávamos paralelamente os pontos positivos e negativos dentro desta mesma iteração, isso ajuda a capturar os porque das "votações" e ajuda no plano de ação.

Isso era colocado dentro de uma planilha onde cada desenvolvedor, techlead e PO, colocavam suas notas para o tópico proposto. Ficaria mais ou menos assim.


Estes dados ficam acumulados na planilha que tornam-se uma base de dados para geração do gráfico que nos dava a visão de como o time está se sentindo quanto aos tópicos. O gráfico ficava mais ou menos assim:


Note que o nível de satisfação quanto ao tópico pessoas manteve-se igual em todas as semanas aqui avaliadas, mas o técnico e processo tiveram suas oscilações. Quando tínhamos uma nota baixa para algum dos tópicos, agíamos já na próxima iteração fazendo com que aquele tópico tivesse uma ascendência. Com isso mantínhamos o time engajado e motivado.

Mas o problema poderia ser originado não somente do grupo como um todo, mas sobre o indivíduo dentro do grupo. Por isso, criamos junto á esta "avaliação" uma maneira de coletar os sentimentos quando à própria pessoa.

Individual

Semelhante à coleta em grupo, o individual possuía uma outra abordagem. Era mais focado na "introspecção", onde a pessoa olhava para si mesmo e como ela contribuiu ou não para o grupo dentro da última iteração. Aqui separamos 5 tópicos: Pensamento (minha forma de pensar está sendo benéfica?), Colaboração (estou trabalhando de forma colaborativa?), Entrega (estou comprometido com as entregas?), Planejamento (estou me planejando de forma adequada para os trabalhos?), Desenvolvimento (estou me desenvolvendo pessoal e profissionalmente?).

A planilha ficava mais ou menos assim:

Que nos gerava um gráfico assim:

O bom deste individual, é que além de utilizá-lo para melhorar o time como um todo, eu utilizava por pessoa, e assim conseguia fazer um trabalho de coach e mentoria para cada indivíduo do time.

Conclusão

E assim trabalhamos o ano de 2017, sustentando o engajamento e a motivação focando nos sentimentos das pessoas. Isso me trouxe uma grande experiência no sentido de entender quando e como atuar para que as pessoas mantenham-se no compromisso.

Até mais e abraço! 👍

______________

Inspiração


  • Gerenciamento Ágil de Projetos. Massari, Vitor.
  • http://rafaelbuzon.com/site/2017/01/16/03-act-agile-coach-tool/

Sugestão


  • Liderando Mudanças. Kotter, John.
  • O coração da mudança: Transformando empresas com a força das emoções. Kotter, John. Cohen, Dan.

segunda-feira, 12 de março de 2018

A cultura e o pensamento

INTRODUÇÃO


John Kotter, professor de liderança na Harvard Business School, disse em seu livro "Liderando Mudanças":

A cultura muda somente depois que se alteram as ações das pessoas, depois que o novo comportamento produzir algum benefício ao grupo, por um período de tempo.

O que ele está dizendo, é que ninguém muda diretamente a cultura de uma organização, mas que é possível mudar alguns comportamentos e que se estes se tornarem sustentáveis, aí sim, haverá uma mudança cultural.

Vamos tratar sobre este assunto, mudança cultural, neste artigo.

O QUE É CULTURA?


A palavra tem origem do latim culturae, que significa “ação de tratar”, “cultivar” ou “cultivar a mente e os conhecimentos”. Por sua vez, o latim culturae originou-se, ainda de uma outra palavra latina, colere, que quer dizer “cultivar as plantas” ou “ato de plantar e desenvolver atividades agrícolas”. Com o tempo, foi criada uma analogia entre o tratamento do plantio, com o desenvolvimento das capacidades intelectuais e educacionais das pessoas.

Segundo Kim Ann Zimmermann (https://www.livescience.com/21478-what-is-culture-definition-of-culture.html), a cultura é resultado de padrões compartilhados de comportamentos e interações, construções cognitivas e compreensão que são aprendidas pela socialização. A cultura abarca ainda religião, gastronomia, idioma, casamento, artes, e nossos valores éticos (o que é certo e errado).

Eu defino, sinteticamente, cultura como o resultado de comportamentos baseados nos valores e crenças de um conjunto de pessoas que mantêm uma interação direta ou indireta.

Sabe-se que a cultura é dinâmica, por ser adaptativa e/ou cumulativa, elementos são alterados, retirados ou acrescentados em uma determinada cultura sem periodicidade fixa, no entanto, toda e qualquer mudança, sofre resistências individuais ou grupais.

Como já definimos anteriormente que cultura é o conjunto de comportamentos baseados nos valores e crenças, entende-se que para se modificar uma cultura, é necessário antes disso, provocar uma mudança de comportamentos, e este talvez seja o grande dilema da gestão de mudanças.

COMPORTAMENTOS


Jurgen Apello afirma que a parte mais difícil da melhoria contínua nas organizações, é mudar o comportamento das pessoas.

Segundo a psicologia, o comportamento é o conjunto de procedimentos ou reações do indivíduo ao ambiente que o cerca em determinadas circunstâncias[1]. Mas como se forma o comportamento?

Para William Moulton Marston, psiquiatra, o comportamento humano, é formado pela junção da corrente hereditária e das experiências pessoais. Sobre a carga genética, ainda há algumas discussões  no meio acadêmico sobre a sua influência na formação dos comportamentos, porém sobre as experiências pessoais, cujos valores e crenças são os fatores determinantes, é confirmado por toda a classe de pesquisadores como raiz na formação dos comportamentos.


Com base nisso, talvez a pergunta que deve ser feita é: o certo é forçar a mudança do comportamento de alguém ou instigá-lo a compreender o porque mudar? Christof Braun, pensando nesta dificuldade de provocar mudanças de comportamento, propõe algo interessante, ele diz:

Se você conseguir uma mudança de mentalidade, as pessoas se comportarão de maneira diferente.

MUDE O PENSAMENTO, MUDE A CULTURA


O grande físico, Albert Einstein, disse certa vez:

Pensar é um trabalho árduo; é por isso que tão poucas pessoas o fazem.

Antes de continuarmos, precisamos deixar claro alguns pontos sobre a mudança de pensamento:
  • mudar o pensamento não é automático;
  • mudar o pensamento é difícil;

Grande parte das pessoas, culpam circunstâncias ou outras pessoas pelos insucessos na vida pessoal e/ou profissional, quando na realidade, a culpa está no pensamento.

De acordo com Carol Dweck, existem apenas dois tipos de mentalidade: 
  1. Fixa: buscam insistentemente afirmar-se na posição em que se encontram;
  2. Crescente: buscam insistentemente desenvolver-se além da posição em que se encontram;
Vejamos os traços diferentes entre ambas mentalidades:


A boa notícia, é que existe a possibilidade de mudança de pensamento, saindo de uma mentalidade fixa (que não atinge sua total capacidade) para uma mentalidade crescente (que atingem níveis cada vez mais alto de realizações). Esta jornada não é complexa, basta estar aberto a mudar seus pensamentos.

Esta jornada inicia-se com o auto-conhecimento sobre o seu mindset fixo, identificando os gatilhos que disparam este pensamento e reeducando seus pensamentos fixos agora que descobriu quais são seus gatilhos.

É preciso entender que a mudança é pessoal (eu preciso mudar), a mudança é possível (eu sou capaz de mudar) e a mudança é lucrativa (eu serei recompensado pela mudança).

Como funciona a jornada?
  • Mudar seu pensamento muda as suas crenças: As pessoas nunca realizarão aquilo que não se vêem fazendo. (Karen Ford);
  • Mudar suas crenças muda suas expectativas: Uma crença não é apenas uma ideia que você possui, é uma ideia que possui você. (John Maxwell)
  • Mudar suas expectativas muda a sua atitude: As expectativas negativas são um caminho rápido para levar o pensamento a um beco sem saída. (John Maxwell)
  • Mudar sua atitude muda o seu comportamento: Aquilo que detém nossa atenção determina nossa ação. (William James). Como você pode saber o que há em seu coração? Observe o seu comportamento. (LeRoy Eims)


Para encerrar, deixo um célebre pensamento de Leon Tolstoi:
Todos pensam em mudar o mundo, mas ninguém pensa em mudar a si mesmo.

Referências:


  • O pensamento que faz a diferença. Maxwell, John.
  • Como mudar o mundo. Apello, Jurgen.
  • Mindset. A nova psicologia do sucesso. Dweck, Carol.
  • Talento para a vida. Descubra e desenvolva seus pontos fortes. Matos, Jorge. Portela, Vânia.
  • [1] https://pt.wikibooks.org/wiki/Psicologia/A_psicologia_como_ci%C3%AAncia/Conceito_de_comportamento (12/03/2018).
  • https://www.hbs.edu/Pages/default.aspx.
  • https://www.livescience.com/21478-what-is-culture-definition-of-culture.html

quarta-feira, 27 de dezembro de 2017

Tem desperdício em Desenvolvimento de Software?

Introdução

Estima-se que 2/3 de alimentos são jogados fora todos os anos no mundo inteiro. Isso equivale a 1,3 bilhões de toneladas de produtos que não serão utilizados por nenhum ser humano. Para alarmar ainda mais, isso equivale à 1 trilhão de dólares jogados no lixo anualmente.[1]

Quando citamos estes números, estamos falando em números absolutos focando estritamente nos alimentos, mas existem outros desperdícios durante toda a cadeia de produção destes alimentos. E a água que foi utilizada? A energia elétrica? Os adubos? Tudo isso torna-se desperdiçado também, haja vista que o propósito para a qual foram utilizados, não serviu para ninguém.

O desperdício mencionado no exemplo dos alimentos, pode muito bem ser aplicado também ao desenvolvimento de software, pois quando entregamos software que não será utilizado em 100%, gastamos tempo de funcionários, infra estrutura, esforço, e principalmente o dinheiro do cliente. Enquanto o desperdício de alimento gera revolta, o desperdício em desenvolvimento de software gera prejuízo.

Símbolo do Desperdício


Frederick Winslow Taylor, em 1911 escreveu que "No passado, o homem estava em primeiro lugar; no futuro, o sistema terá primazia".[2] Em seu escrito, o que Taylor está dizendo, é que construiríamos ferramentas poderosas que aumentariam exponencialmente nosso poder de produção. Hoje existe uma grande facilidade de se criar software, as ferramentas cada vez mais robustas, permitem que se construa um sistema com uma velocidade extraordinária, comparada à poucos anos atrás, dá-se a isso o nome de Eficiência.

Mas onde estão os desperdícios na construção de Software?

Como definir o que realmente é desperdício no desenvolvimento de Software? Baseado nos 7 desperdícios dentro do conceitos Lean de Produção, Mary e Tom Poppendieck desdobraram isso para Desenvolvimento de Software.[3]

Vejamos quais são:

Trabalho Inacabado

O problema do trabalho parcialmente feito é um dos grandes problemas dentro do desenvolvimento de software. Frases como "já está pronto, só falta testar" exemplificam muito isso. Alguns exemplos de trabalho inacabado podem ser: documentações não codificadas, código não 'mergeado' no repositório master, código não testado, sistema não instalado;

Funcionalidades Extras

É o famoso gold plating, ou seja, é desenvolver funcionalidades não requeridas pelo cliente como forma de agradá-lo, colocando uma "cerejinha no bolo". Este é o pior dos desperdícios, onde Taiichi Ohno chama de superprodução, ou seja, é criar estoque que não será "imediatamente" necessário.

Reaprendizagem

Há dois níveis de desperdício dentro deste tópico que são: 1) esquecer o que foi aprendido no passado e ter que reaprender; 2) ignorar conhecimento de outras pessoas não envolvidas no processo de desenvolvimento. Resumidamente, é perder o controle do conhecimento gerado/absorvido.

Transferências de Controle (handoffs)

Esse é um problema que raramente será eliminado, mas pode ser mitigado. Isso porque a comunicação do conhecimento tácito, aquele adquirido pela experiência, sempre resulta em perda de conhecimento. Estima-se que 50% do conhecimento tácito fica para trás na primeira transferência de controle.

Troca de tarefas

É o famoso dividir o foco em mais de uma atividade. É cientificamente comprovado, segundo Vítor Massari em Gerenciamento Ágil de Projetos, que 40% do esforço é desperdiçado quando um desenvolvedor alterna de uma tarefa para outra. Existe um consumo de energia no cérebro para que o desenvolvedor se desligue de uma tarefa e inicie uma outra.

Atrasos

O software implementado e testado precisa ser homologado pelo cliente ou designados por ele, mas eles não tem tempo disponível para homologar: desperdício. Aguardar pela disponibilidade de pessoas de outras áreas é uma das grandes causas de desperdício gerando o famoso "atraso".

Defeitos

Este desperdício gera um sentimento negativo diante do cliente: falta de credibilidade. Construir um software cheio de bugs é terrível, porque além de gerar uma sensação de desconfiança, gera custo de qualidade e gasta tempo de desenvolvedores.

Como resolver a questão dos desperdícios?

Os métodos ágeis possuem muitos profissionais experientes, mas que muitas vezes tropeçam em uma armadilha que é corriqueira demais: focar em ferramentas e técnicas e não na resolução de problemas e eliminação de desperdícios. O desenvolvimento de software, deveria abarcar tanto o foco no método ágil, otimizando o processo de construção, quanto na melhora do fluxo inteiro de valor.

Estima-se que apenas 20% dos recursos e funcionalidades em software são utilizados com regularidade e que 50% dos recursos de um software (utilizados ou não) nao agregam valor ao negócio.[4]

Os desenvolvedores, segundo pesquisa feita pela Carnegie Mellon com 13.000 programas, cometem entre 100 e 150 erros em cada mil linhas de código, comprometendo assim a qualidade do produto, demandando 80% do orçamento para correção destes erros.

Em suma, uma boa metodologia de desenvolvimento de software inicia-se com uma premissa simplória: identificar 20% do código que proporcionam 80% de valor e executá-los dentro do tempo de forma puxada ao invés de empurrada e sempre envolver o cliente na definição dos requisitos e testes.[4]

De forma sintética, usando o contraponto mencionado no início deste post, quando falamos que crescemos em Eficiência, deixo uma frase do famoso Peter Drucker e logo em seguida abordaremos os métodos resolutivos para cada tipo de desperdício demonstrado até aqui:
Sem dúvida, não há nada tão inútil quanto fazer com grande eficiência o que não devia ser feito de modo algum[2]
Drucker está confrontando aqui Eficiência versus Eficácia. Isso é assunto para um outro post.

Métodos resolutivos


Desperdício Resolução
Trabalho Inacabado - Uma boa definição de pronto (done);
- Dividindo o trabalho em pequenos lotes ou iterações;
Funcionalidades Extras - Se não houver uma necessidade econômica, a funcionalidade não deve ser implementada;
- Entregue somente o que o cliente pediu (concentre-se no trabalho dele);
- Entregue VALOR e QUALIDADE
Reaprendizagem - Registre tudo o que você sabe;
- Anote todas as decisões tomadas
Transferências de Controle - Reduza o número de transferências;
- Faça transferências face a face ao invés de documental (mas mantenha o documento);
- Faça transferências através de modelos, protótipos e simulações
Troca de Tarefas - Comece a terminar e pare de começar;
- O time que construir, deverá manter;
Atrasos - Todos envolvidos devem estar completamente disponíveis a qualquer hora;
- Conhecimento compartilhado evita silos;
- Iterações curtas com feedbacks frequentes;
Defeitos - Testes automatizados, antecipados e frequentes;
- TDD (prática do XP)

Espero ter contribuído. Até mais!


Referências

1. https://www.embrapa.br/busca-de-noticias/-/noticia/28827919/os-desperdicios-por-tras-do-alimento-que-vai-para-o-lixo (27/12/2017);
2. Startup Enxuta. Ries, Eric
3. Implementando o Desenvolvimento Lean de Software. Poppendieck, Mary; Poppendieck, Tom
4. TI Lean, capacitanto e sustentado sua transformação Lean. Bell, Steven.

Total de visualizações de página

Pesquisar este blog

Seguir

Sobre mim

Minha foto
Daniel C. Moreira
Sou um apaixonado por leituras. Desde 2000 trabalhando com tecnologia, posso me considerar um "fanático" por resolver problemas da melhor maneira possível e idealizar soluções que atendam ao negócio. Atuo atualmente como Agile Coach, mas já foi Professor, Instrutor, Programador, Desenvolvedor, Analista de Sistemas, Líder Técnico, Analista de Negócio, Gerente de Projetos, além de na vida pessoal atuar como Pastor Evangélico desde 2013.
Visualizar meu perfil completo

Followers