Cultura de aprendizado e formação de equipes de alto desempenho — GU Day SUCESU-RS 2013

O assunto Cultura de Aprendizado é um assunto que me cativa demais. Seja pelo meu objetivo de vida de me tornar inútil e ajudar lideranças a serem formadas, mas também pela questão de formação de times de alto desempenho. Ajudar a desenvolver profissionais que sejam melhores profissionais, dia após dia. Lembrar que tudo isto é um processo de adaptar e desenvolver a governança corporativa.

É algo que envolve a cultura da organização, envolve uma questão de atitude de cada pessoa, e principalmente o grupo, a sinergia que o grupo consegue desenvolver.  No final, o que se quer é viver feliz, desenvolvendo um trabalho de valor, e evitar a famosa aposentadoria por alívio.

A cultura de aprendizado sendo trabalhada vai ajudar a desenvolver uma cultura de prevenção. E tudo começa a fazer sentido. Um time mais responsável, com liberdade e muita colaboração para fazer as coisas acontecerem.

— Daniel Widt (assine meu canal de vídeos)

Em busca de um ritmo

banner-A-300x250Me perguntaram dia desses:

“Como fazer para voltar a ter paz com um cliente? O cliente não parava de pedir coisas e estava fora de controle. O time não conseguia atender as demandas, já que sempre vinham novas demandas. E o time não tinha como  negociar com o cliente para acertar as entregas.”

Não tem jeito fácil de virar este jogo. Pegando experiências que tive com equipes, normalmente se passa por três passos:

O primeiro é “aceitar a falha”. Entender que existe um problema com a equipe. Tomar consciência disto. O cliente não é o culpado. Ele pediu, e a equipe aceitou fazer e entregar. Mesmo sabendo do seu histórico. Não existia nenhuma restrição “segurando o cliente” de pedir mais. Esta restrição será criada com as próximas ações.

O segundo passo é trabalhar com a priorização das demandas. Ensinar os clientes a classificar as próprias demandas. Fazer este trabalho junto com os clientes. Capacitando eles, por exemplo a pensar sobre “o que acontece se eu não implementar esta funcionalidade?”. Pequenos detalhes que ajudam na percepção de demandas x valor x real necessidade.

O terceiro ponto que considero importante é o time estabelecer um ritmo de entregas. A equipe deve estabelecer um ritmo de entrega com os clientes. Se não está conseguindo entregar, baixe a velocidade. Aceite a falha novamente. Não corra. Apressar uma entrega pode ser a geração de um defeito no seu código fonte. Qualidade não é opcional.

Com as ações de melhoria contínua, o time vai melhorar, vai ser mais consistente nas entregas, vai ouvir mais o cliente. Agora, o que o time não pode deixar de dar atenção é na questão simplicidade. E lembrar, lá do manifesto ágil:

Simplicidade é a arte de maximizar o trabalho que não é feito. 

Sempre dando atenção a questão simplicidade, garantindo que a comunicação com o cliente está fluindo e a priorização ocorre e que o ritmo está sendo interessante para a equipe e para o cliente, a equipe ganha espaço para seguir melhorando e buscando melhorar ainda mais a qualidade do serviço que presta.

Este ciclo de melhoria não pode parar. Já falei em outros posts, é como Deming dizia:

Não é necessário mudar. Sobreviver não é obrigatório.

Quer praticar programação? Coding Dojo!

Todos times deveriam ter um momento de prática. Um momento para desligar e viver situações diferentes. Treinar programação. Compartilhar pensamentos que não apareceriam no dia a dia de projeto.

Um Dojo é o lugar do caminho, é a casa dos praticantes de artes marciais. Desenvolvimento de Software além de ser uma atividade criativa, é uma arte. E como tal, deve ser estudada, praticada, e melhorada de forma constante.

A troca de experiências que ocorre em uma sessão de treinamento, entre pessoas com mais experiência e iniciantes é algo  único, uma oportunidade de aprender e de ensinar. De colaborar e ajudar na formação de melhores desenvolvedores.

É um ambiente de colaboração. Competição não possui lugar. É um ambiente de treinamento, onde práticas do eXtreme Programming como Desenvolvimento Orientado a Testes (TDD), Design Simples, Programação em Pares e Posse Coletiva podem ser compartilhadas. As ideias devem ser provadas com código. E todo novo código precisa aparecer evoluindo dentro do ciclo do TDD (Red-Green-Refactor). Explico: primeiro se faz a criação de um teste falhando um determinado cenário em foco, depois criar o mínimo necessário de código para fazer o teste passar e por fim aplicar técnicas de refatoração para melhorar a estrutura do código fonte, deixando ele mais simples. Ciclos curtos fazendo isto até fazer o que precisa ser feito.

Normalmente para se fazer um dojo se precisa de:

  1. Um problema a ser resolvido. É normalmente um problema de lógica, onde através de técnicas de design, evolução constante do código através da criação de testes e pequenos passos, este problema vai sendo trabalhado e evoluído. Eventualmente se pode chegar na solução do problema, mas o propósito do Dojo é estudar situações e oportunidades de projetar e resolver um determinado problema.
  2. Datashow ou forma de compartilhar o que está ocorrendo com os participantes.
  3. Uma estratégia para tocar o Dojo. Existem algumas, como o (a) Prepared Kata, onde um especialista resolve o problema do início ao fim. O que mais uso, o (b) Randori Kata, possui um timer tocando a cada 5-7 minutos, indicando uma nova rotação a ser feita. Temos apenas um computador sendo usado nesta abordagem, assim como é com o Prepared Kata. A cada rotação o desenvolvedor que ficou na máquina tem a tarefa de passar o conhecimento e situar quem está chegando. Aqui estão as oportunidades perfeitas para parear pessoas com grande diferença de conhecimento. Assim o aprendizado funciona muito melhor. Ainda temos o conceito de (c) Kake Kata, onde pequenos grupos se formam e resolvem o mesmo problena. As rotações ocorrem dentro do grupo e entre grupos. O desafio neste caso comparado com o Randori, é que a cada ciclo, estaremos visualizando código diferente e que não foi tocado anteriormente pelo time. Então o processo de aprendizado tem mais desafios.
  4. Pessoas. Pelo menos 1 pessoa. Se pode fazer um Prepared Kata e gravar para publicar online.  🙂
  5. E o tempo? Uma hora pode ser o suficiente para passar a mensagem e fazer o time trabalhar junto. Gosto de usar 60-80mins de tempo de trabalho.

E quer saber qual a parte mais legal? Esta estrutura de pareamento e colaboração pode ser usada para diversas abordagens! Desenvolvimento de um Business Canvas, escrita de requisitos em um dojo de análise de negócios, e por aí vai.

Update Jan/2019, vídeo sobre Coding Dojo.

Extras:

Dúvida para o seu primeiro Dojo? Pegue um problema simples como o FizzBuzz, escolha uma linguagem, um framework de teste e mande ver!

A gente somos inúteis, e isto pode ser excelente!

Em maio de 2013 falei na BITS South America, dentro do espaço de inovação SEBRAE-RS Thinkers. A palestra ocorreu dentro das atividades organizadas pela galera do Thinkers Poa.

Palestra: A gente somos inúteis, e isto pode ser excelente! 

Descrição: A vida em rede é algo real, e os benefícios que temos em colaborar, contribuir, ensinar e aprender são essenciais para nossa evolução como pessoas e como profissionais. Entender até onde queremos chegar e o que queremos entregar, é algo em constante adaptação. E ainda mais interessante quando conseguimos ensinar tudo o que sabemos a ponto de nos tornarmos inúteis, dando chance para aprendermos mais. Venha discutir mais sobre você e como você pode viver melhor, fazendo e realizando mais. Usaremos técnicas como Business Model You e outras que podem ajudar na formação de objetivos, ajudando você nas ações do tipo “vai lá e faz”.

Quer ver um pouco sobre o assunto Business Model You, tarefas, propósito? Veja esta palestra que fiz na Desconf 2012 com o assunto “Quem é você?”.

— Daniel Wildt (update 2021: quem é você em formato podcast)

Uma dinâmica para brincar de Métodos Ágeis – A hora extrema!

A prática é a melhor forma de demonstrar e criar conhecimento. Desenhar, refletir, discutir, concordar e discordar.

A primeira vez que participei de uma dinâmica da hora extrema (eXtreme hour), foi em 2004, e o exemplo utilizado foi a criação de um caixa eletrônico. Hardware e software. 🙂

Desde então, sempre que tenho a oportunidade, faço a dinâmica para poder ensinar um pouco sobre Agilidade e demonstrar disciplinas do eXtreme Programming aliadas a práticas que ajudam a maximizar comunicação e compreensão do que se quer alcançar no software.

Que materiais você precisa para fazer a eXtreme Hour?

Cartões para se poder escrever as histórias e brincar com o conceito 3C.
Folhas de papel brancas e coloridas
Canetas coloridas
Réguas
Tesouras
Fitas adesivas
Colas

Para que tudo isto? Para se poder montar telas, fazer mockups, e poder trabalhar com a prática do paper prototyping. Nesta uma hora, provaremos as histórias através da “execução” dos protótipos de papel.

E quanto tempo dura a dinâmica? A dinâmica deve durar 1 hora! O tempo total do evento pode ser mais de 1 hora, considerando uma ambientação com agilidade e eXtreme Programming, e depois um fechamento do evento.

Considere que você vai fazer de duas a três iterações, e que neste tempo está incluído o papo inicial do cliente, e também uma retrospectiva da dinâmica. O cliente segue disponível durante toda a dinâmica, a menos que você adicione uma restrição para ele “sumir” por alguns minutos. E assim o time poder ver como se comporta. Eu normalmente faço duas iterações. Elas já servem para demonstrar as ideias e surgem muitos pontos de discussão a partir disto. E normalmente crio restrições em alguma das iterações para ser mais difícil falar com o cliente.

Comentei que o exemplo usado é sobre construção de caixa eletrônico, com seu software e hardware. Aqui então mando uma lista que itens que você pode vir a requisitar para as equipes construírem:

  • No hardware do caixa eletrônico, o seu formato. Pensar na forma da retirada de dinheiro, se tem leitor de código de barras, forma de entrada do cartão (chip, magnético ou se vai fazer leitura da digital). Se vai ter impressão de recibos ou envio dos mesmos por email?
  • Tipos de uso pelo cliente, se vai fazer uso com o cartão do banco ou sem o cartão do banco. Exemplo, sem o cartão é possível fazer impressão de extrato ou saldo. Para fazer saque e pagamento, será necessário cartão do banco.
  • Sobre funcionalidades do software, temos várias opções, com saque, consultas de conta, pagamentos com ou sem código de barras, transferências, doc e ted, e outras funções que um caixa eletrônico possui. Escolha um banco e pense nas funcionalidades que o caixa eletrônico oferece. Dica: ao pensar no saque, pense em limitações de valor e horário, para que os times possam exercitar situações de exceção e erro.

IMG_4806

E sobre todas estas possibilidades, você deve indicar para as equipes coisas que quer ou que gostaria de ter. Não necessariamente precisa indicar o que é prioridade. 🙂 O que normalmente ajuda a gerar resultados bem diferentes e interessantes. A prioridade pode ficar como algo “não falado” nos primeiros minutos da explicação, para ver se as equipes vão fazer perguntas ao cliente ou se elas vão simplesmente executar o que o cliente falou, na ordem que ele falou. Que não necessariamente vai ser a ordem de importância. O ponto aqui é ver se as equipes estão buscando entrega de valor e comunicação com o cliente, aproveitando a presença do mesmo.

Costumo dividir as equipes em 7 pessoas. Evite muitas equipes, para que possa gerenciar tudo sendo apenas 1 cliente.

Quanto ao tempo, uma sugestão de uso pode ser a seguinte:

  • 3 mins – As equipes se organizam e definem quem faz o que (quem faz design, escrita de histórias, validações, a criação dos protótipos, tira dúvidas com o cliente, manter o tempo, e por aí vai). Lembre que as equipes devem ser multidisciplinares. Então as pessoas podem se ajudar em atividades.
  • 7 mins – Apresentação do problema. Aqui você como facilitador usa sua imaginação e pensa em funções que o caixa eletrônico vai ter, qual o público alvo e restrições do jogo, exemplo tempo disponível para tirar dúvidas, e outras questões neste sentido.
  • 15 mins – Primeira iteração. Nesta iteração, o time deve fazer planning (2mins de sugestão), execução da iteração e retrospectiva. Na metade do tempo da iteração, deve fazer uma “diária”. Então considere que cada dia termina depois de 7mins. E neste momento existe 1 min de reunião diária para o time alinhar o que está ocorrendo. No décimo terceiro minuto, o time deve fazer sua retrospectiva da iteração, para entender o que pode ser melhorado para a próxima iteração.
  • 5 mins – Tirar dúvidas com os times e mostrar insights que foram vistos durante a primeira iteração. Normalmente equipes focam demais em planejamento e não em execução. Outras equipes focam demais em execução. Outras equipes não se organizaram e todos fazem de tudo e não entregam nada. Aqui não se resolve nada muito profundo, o objetivo é dar pequenas dicas para deixar visível aos times oportunidades de melhoria na sua comunicação e tática.
  • 15 mins – Segunda iteração. Mesmo ciclo da primeira iteração, os times tentam entregar mais um grupo de funcionalidades.
  • 15mins – Retrospectiva do exercício, aqui serve como momento de reflexão e gerar uma discussão com os participantes sobre agilidade e metodologias ágeis.

E era isto! Espero que todos se divirtam!

Deixo algumas fotos da dinâmica que ocorreu no Agile Games Night, evento que ocorreu no UniRitter/Porto Alegre em junho de 2012.

E agradecimentos ao Thiago Esser! Ele ajudou a priorizar este post! Espero que possa ser útil!

Caso tenha interesse em levar esta dinâmica para sua empresa, ou evento, ou alguma palestra, faça! Só peço uma coisa em troca! Faça um post contando da experiência e comente por aqui fazendo uma referência! Quero saber quem anda brincando com a eXtreme hour por aí!

Update 24/set/2012Thiago Esser manda feedback da dinâmica que ele fez!

Porque você não deve testar seu software!

Dia 23/agosto tenho uma palestra no evento do Grupo de Usuários de Teste de Software do RS. O evento ocorre em Porto Alegre, na PUC-RS a partir das 19h15min.

Depois complemento este post com um resultado da palestra, mas de imediato deixo o resumo da palestra:

O objetivo é mostrar todos os benefícios de não testar software. Ao melhor estilo “dilbert”, ir contra as práticas, que acabam sendo uma forma diferente de refletir e aprender um determinado assunto. Falar dos “benefícios” 🙂 de se não testar e não se preocupar com a qualidade do seu software. E principalmente toda a emoção que estas práticas irão trazer para o dia a dia do seu time. Tudo isto através de uma reflexão coletiva com a platéia.

Convido a todos para irem assistir esta palestra e participar de todas atividades da noite do GUTS-RS.

UPDATE!

Claro que a palestra foi uma “tirada” sobre equipes e profissionais que ainda acreditam que são muito bons e que testes, automação e outras técnicas para garantir qualidade não se aplica a eles. E também para empresas que consideram os processos de teste como algo “inútil”.

Fora histórias que vivi no passado de empresas que vendiam seus serviços ao mercado com ou sem testes. Até projetei nos slides o que seria esta empresa que “consegue” fazer entrega sem testes. 🙂

Depois comecei a puxar aspectos de algumas metodologias ágeis e trazer algumas reações que já vi equipes e pessoas terem a respeito das práticas e sua associação com processos de teste e de garantia da qualidade.

A mensagem no final, é sempre lembrarmos que o processo de testes deve ser uma atividade de prevenção. Nunca de reação. Que o modo de medição do profissional de testes, não pode ser atrelado a quantidade de defeitos que a pessoa acha. E sim a qualidade que este profissional consegue adicionar na sua equipe de trabalho. O quanto ele consegue fazer funcionalidades passarem por todo o ciclo de trabalho e chegarem a produção de uma forma mais consistente. Pareamento com analistas, desenvolvedores, foco total na criação de conhecimento.

Fecho o post com a apresentação realizada hoje.

Priorizando projetos de TI

Estava lendo um artigo na cio sobre priorização de projetos de TI.

Esta priorização muitas vezes funciona como um malabarismo, pelas diferentes áreas de negócio demandando projetos. Lá pelas tantas, se fala:

“Os modelos formais e mecanismos de priorização não funcionam mais”, diz David Cearley, vice-presidente do Gartner. “A priorização não pode ser feita de forma isolada do negócio. Precisa acontecer em estreita parceria com a empresa.”

Nesse cenário, a TI está sentindo a pressão para ser mais ágil em seus métodos de entrega, mais flexível na priorização de projetos, e mais experiente na avaliação de ROI – tudo para que possa trabalhar com, e não contra, as necessidades de negócio.

Um dos pontos é em evitar constantes “não” para os clientes. Mas o ponto não é este. O não é muito bom para testar reais necessidades. Quando um cliente requisita uma nova funcionalidade ou um novo projeto, perguntar “O que acontece se este projeto não for entregue? O que se perde?“, pode ser uma forma de buscar o real valor do projeto. Claro, você deve saber se tem um ambiente propício para isto. Senão a resposta pode ser… “Ah, o que se perde? Seu emprego.

Quando escrevemos uma user story, queremos saber questões como o porque ela precisa ser implementada, o que de deve ser implementado, e quem se beneficia com isto. Para um pensamento mais “amplo”, em projetos, esta linha de pensamento serve igual. Isto me lembra a Project Story do Luiz Parzianello, que eu curto muito. Ela é um documento que consegue criar uma visão mais clara de um projeto a ser entregue. E é uma forma para empresas se organizarem e criarem governança na hora de escolher o que priorizar e porque priorizar. Temos outras formas de fazer isto, seja pensando em uma estrutura de Business Canvas e Lean Startup.

E neste sentido, é interessante como as grandes empresas dificilmente conseguem ver valor em estar mais próximas das áreas de negócio. E em trabalhar com ciclos mais curtos de entrega. Deixando as áreas de negócio realizarem testes, desenvolvendo produtos mais rapidamente e testando o seu resultado é pelo menos um exercício para minimizar risco. É muito importante para a equipe de desenvolvimento estar próxima dos clientes, pois assim poderão ajudar na priorização de funcionalidades em um lado mais técnico e entender mais dos processos de negócios envolvidos.

Depois no artigo, este assunto vem a tona:

O alto nível de envolvimento das partes interessadas também levou TI a repensar seu processo de desenvolvimento, passando a adotar uma abordagem mais ad hoc quando as equipes de TI passam a integrar o pessoal de marketing ou das áreas de negócios para o desenvolvimento mais rápido de um aplicativo móvel  – às vezes em questão de dias em vez de semanas ou mesmo meses.

O foco aqui não é entrega rápida de aplicativos de mobilidade. Quero focar em entrega de projetos em geral. E quando se fala em abordagem ad hoc… o que o pessoal deveria olhar são as metodologias ágeis puramente, porque muitas das preocupações citadas, são na verdade princípios e questões que as equipes ágeis valorizam.

Para que isto ocorra de forma efetiva, a formação de equipes menores para se trabalhar em projetos, dentro das áreas de negócio é uma boa solução, só que o problema é que normalmente as equipes “tradicionais” não são preparadas e estimuladas a assumirem mais de um papel. Isto deve ser trabalhado e permitido. E com o cliente presente para ajudar nas definições, os ganhos serão vistos de forma rápida.

O tempo de resposta das equipes é cada vez menor. E para que isto possa ocorrer desta forma, devemos estar leves e comprometidos com o essencial, permitindo sempre uma revisão de rumo e constante avaliação se algo pode ser melhorado no processo diário.

Vinicius Teles uma vez me disse que “o cliente só sabe o que quer depois que vê o que pediu“. Neste sentido o que queremos fazer é lançar logo software para que os clientes possam avaliar e prover feedbacks. Só que muitas empresas ainda não caíram na real e algumas só vão se ligar em certas práticas quando a água estiver chegando no nariz.

Qual é o custo da inovação?

Em uma das tirinhas de domingo do Dilbert, apareceu uma sobre inovação, com uma forma bem interessante de motivar as pessoas a participarem de ideias para novos produtos. De forma algumas as ideias foram “reprimidas” e o ambiente era propício para as pessoas poderem ser humildes e respeitadas. 🙂

Bom, vamos ao foco do post. O grande problema que eu vejo em ideias que surgem dentro de uma equipe é o processo de evolução ou morte destas.

Muitas empresas, dependendo da sua estrutura e/ou cultura, vão ter ideias que morrem por falta de ação da gerência, como já ouvi em um evento anos atrás. Quer dizer, devido a outras 1000 coisas que a gerência precisa fazer ou entregar, uma ideia positiva e legal nem terá a chance de evoluir. Nem de ser experimentada. E ninguém nem tem a chance de sentir peso na consciência, já que a ideia não está no plano de desempenho anual. :-/

Eu prefiro pensar que uma ideia perde seu valor porque a equipe como um todo deixou de acreditar nela. E que uma ideia mantém o seu valor em virtude de ações que a equipe realiza. É a chance de uma evolução mais democrática.

Ainda assim, isto não é garantia de nada.

Muitas vezes a equipe está lotada de trabalho e de tarefas que precisam ser realizadas, não restando tempo para a equipe trabalhar em novas visões ou simplesmente seguir uma ideia que é reconhecida pela equipe como boa. Muitas vezes as equipes voltam para os momentos de “loucura” e se esquecem que a melhor coisa que elas podem fazer é manter um ritmo saudável para evolução dos produtos, com qualidade constante.

Por isto, mesmo em uma equipe aberta a inovação é preciso ter algum tipo de método ou controle ou restrição para garantir que vai existir um balanceamento no que é feito em produtos existentes e novos produtos.

Este tipo de investimento pode ser medido, tanto o investimento como o retorno do que é feito.

O que se quer então?

a) Formas de testar as ideias para se ter visão pós feedback do mercado sobre a sua validade.
b) Restrições que ajudem as ideias a serem lançadas e mantidas. E que principalmente ajudem a equipe a não perder o foco.

Lembre-se. Ideias podem surgir como forma de ajudar um produto a ganhar consistência, como forma de se testar tecnicamente alguma tecnologia, ou simplesmente para testar um mercado que não se conhece.

Pode ajudar uma empresa a desenvolver seu nome pelo mercado de tecnologia.

E também pode prejudicar uma empresa. Parecia fácil né? Mas não é… qualquer tipo de lançamento deve ser feito com responsabilidade e sem perder foco na qualidade. Ela não é opcional. E portanto seus experimentos devem mostrar que o caminho está correto. Os experimentos devem ser responsáveis por mostrar o respeito e mostrar que uma ideia merece mais persistência e apoio.

How technology evolves in a team?

Dilbert is always nice. On Oct 17th 2011, the comic strip was about building a 5-year technology plan for the CEO.

How is technology evolving in your team nowadays?

What triggers new technology to be selected for a proof of concept, for some sort of research or even for an internal project?

Here are some options you can think about:

  • Presentation events: build a morning or a night to get the team together and have lightning talks, 5-10 min talks about technology, management, out-of-box-thinking, things that can spark, trigger new directions to the team. Examples are TED talks or Desconf (in portuguese – this is an initiative I help).
  • Coding Dojos: having a regular coding dojo agenda, can help the team to practice their programming skills, try different languages and frameworks. With this, new ideas will come up eventually and there you go, more options to use inside the team. You will also work on pairing skills, test automation skills and will find a better team integration.
  • Hackatons: Think about initiatives like Rails Rumble or Random Hacks of Kindness (RHoK). Think about days where people get together to solve a problem, trying some engagement in the local community.
  • Blogs: tell people what are you learning and share knowledge. Telling what your team is trying, without violating some internal rule with the company. Creative Commons content. You will probably show something that is already online, but making it easy for someone else to find and use the documentation.
  • Yammer or other internal social network like Chatter: show what are you doing internally. Motivate others. Create some groups where people with same interest can share ideias and promote. Create a more online and active team sharing what’s happening. It’s a way between IM (sync) and e-mail (async) communication. And a form of communication where you want to be short and concise.

uMov.me – 1 year after public launch

Since May of 2009 I’m playing as CIO / CTO for Trevisan Tecnologia, a mobile development company located in the south of Brazil.

My mission here is to create a new culture and help grow the company teams to enable the creation of new products. When I say culture I mean creating a Learning culture based on Lean and Agile practices. Our team is growing a lot and will keep growing. When I say new products, I’m saying Lean Startup style.

Today is a great day. uMov.me is completing 1 year after public release. uMov.me is a mobile platform that enables companies to deliver quality corporate mobile apps faster to the market. It’s simple, fast to develop, and you can find what you need to develop corporate mobile applications.

The good thing is to look back and see amazing things our team done, not only technically but also looking at the product itself. I’m proud to be part of this team.

We have published an infographic telling a bit of the story of this past year.

uMov.me infographic