Seja um profissional Ágil

A matéria de capa da revista Você S/A do mês de março tem a chamada: “Seja um profissional ágil”. Isso é um sinal bem claro de que o movimento Ágil está ganhando cada vez mais espaço em todas as áreas de trabalho. O que exige cada vez mais conhecimento e profissionalismo em relação a como conduzir uma organização para que ela se torne realmente Ágil.

unnamed2.jpg

É muito fácil, quando se fala em agilidade, conduzir o pensamento para post-its colados na parede, ouvir termos como Scrum, Kanban, Squads e basear a rotina de trabalho em várias reuniões. Muitas vezes, sem saber qual é o fundamento que precisa servir como base. E sem isso, qualquer iniciativa tem uma grande chance de não ser bem sucedida.

O primeiro passo do movimento Ágil foi com o Sistema Toyota de Produção, criado por Taiichi Ohno durante a segunda metade do século XX. Consiste, basicamente em mapear o fluxo de trabalho, identificar e remover os obstáculos deste fluxo, eliminando os desperdícios e aumentando a produtividade. Esse movimento ganhou força na área de desenvolvimento de sistemas depois de um encontro de 17 profissionais da área de tecnologia, em 2001, que se reuniram para discutir melhorias na forma de se produzir sistemas. Um dos principais questionamentos era em relação ao modelo cascata, onde tínhamos grandes fases bem delimitadas e que cada fase trabalhava com a entrega do escopo inteiro de todo o sistema, ou seja, todos os requisitos, depois todo o código, depois todo o material para teste e assim por diante até chegar na implantação em produção (imaginem descobrir um erro de definição na fase final…). O resultado deste encontro foi um documento com 4 valores e 12 princípios para guiar o processo de desenvolvimento de sistemas.

Valores:

manifesto_agil_valores

Princípios:

manifesto-agil-principios

A partir deles é que temos todas as práticas, que podem ser utilizadas sozinhas, misturadas ou até mesmo ter a sua própria (por que não?). É é dentro deste conjunto que estão o Scrum, Kanban, Lean, SAFe, entre outros (temas para novas publicações no blog). E, independente de como você vai aplicar a agilidade, esse é um trabalho empírico, ou seja, é uma prática que evolui conforme os acertos e erros vão acontecendo.

O artigo da Você S/A, reforça bem práticas que devem fazer parte de um trabalho Ágil, tais como trabalho em equipe, colaboração, transparência e melhoria contínua. Na reportagem também tem uma mini entrevista bem bacana com Jeff Sutherland (que participou da criação do Manifesto Ágil e é um dos criadores do Scrum) e seu filho.

Um outro ponto bem reforçado é a derrubada do mito da multitarefa. Ao invés de fazer várias coisas ao mesmo tempo,  focar naquilo que é mais importante e trabalhar para terminar o mais rápido possível e depois partir para o próximo item. Existe uma frase muito famosa no Kanban que diz para parar de começar coisas novas e começar a terminar as coisas em andamento (stop starting, start finishing), que reforça ainda mais esse conceito (fiz até um adesivo para usar essa frase como um lema, rs…).

unnamed

Mas é claro que há algumas distorções (na minha opinião): omitir os 4 valores do Manifesto Ágil e falar apenas dos princípios; dizer que uma Sprint pode durar 10 semanas (isso só acontece no SAFe que possui um modelo Ágil em escala com papéis e fluxos bem definidos para justificar as 10 semanas), uma Sprint tem uma duração máxima de 1 mês; usar termos do Spotify deliberadamente, vejo muitas empresas por aí dividindo suas equipes em Squads, Tribes, Chapters, sem necessariamente trabalharem de forma Ágil.

Apesar disso, a reportagem abre uma janela para que todas as profissões procurem neste mindset, uma forma de entregar valor aos seus clientes de forma rápida. Vale a leitura e vale também buscar informações consistentes antes de sair colando post-its na parede para dizer que sua organização é Ágil.

 

Links úteis:

https://www.manifestoagil.com.br/index.html

https://www.scrumguides.org/scrum-guide.html

https://leankanban.com/guide

https://www.scaledagileframework.com

https://www.infoq.com/br/articles/spotify-escalando-agile

 

Falando em metas…

No início deste ano, eu divulguei uma lista com 12 metas para trabalhar durante o ano de 2019. Hoje quero falar um pouco dos conceitos e o que me levou a definir aquele conjunto para este ano

Antes de estabelecer qualquer meta, é importante ter em mente quais os principais objetivos envolvidos. Aonde você quer chegar. Meu principal objetivo desse ano é cuidar da saúde.

Uma vez que tenho o objetivo, preciso traçar as metas. Como vou alcançar esse objetivo?

As metas podem ser de curto, médio e longo prazo. É bom para ter ações para pôr em prática já e ações para horizontes mais distantes. Alcançar o primeiro degrau dá estímulo para seguir adiante e ir atrás dos outros. Não adianta listar uma série metas para cumprir amanhã, não vai rolar e só vai trazer frustração e te deixar mais longe do objetivo. A minha lista possui itens para cumprir todos os meses, itens para cumprir algum momento deste ano e itens que acredito que serão cumpridos ao longo do ano.

Um ponto bem importante das metas, é que elas precisam ser mensuráveis. Preciso de critérios de sucesso bem definidos para saber se estou no caminho certo. Disse que queria voltar a visitar a praia, por exemplo. Não disse quantas vezes queria ir lá para este ano, o que quer dizer que uma vez basta. Se isso não fosse suficiente, deveria especificar o número de visitas que deveriam ser cumpridas. Mas neste meu caso, uma vez já basta mesmo.

As metas precisam ser desafiadoras, mas também alcançáveis. Por exemplo, o peso que eu preciso alcançar. Perder 10 kg em um mês é um sonho que não será realizado. Perder esse mesmo peso ao longo do ano é possível e bastante desafiador, principalmente uma vez que eu me permiti chegar a um peso 10 kg acima do ideal.

Estabeleci que eu precisava fazer os seguintes itens para atingir o objetivo de cuidar da saúde. Separei em dois grupos para ilustrar que o primeiro é da saúde física e o segundo da saúde mental.

  • Beber pelo menos 2 litros de água por dia
  • Fazer pelo menos 50 km por mês no Nike+
  • Voltar para a natação
  • Chegar a 55 kg
  • Normalizar taxas do meu exame de sangue (no ano passado, as taxas de glicose e colesterol estavam na faixa limítrofe)

 

  • Ler pelo menos 2 livros por mês
  • Voltar a visitar a praia (que eu não vou desde que comecei o MBA)
  • Iniciar o segundo módulo da formação de sommelier

Percebi que algumas das minhas metas se encaixam melhor como objetivos, principalmente porque tenho uma lista de ações para conseguir realizá-las. E, são coisas que eu quero realizar no segundo semestre.

  • Fazer a tatuagem de caveira
  • Trocar de carro

Tenho um objetivo profissional para este ano, com algumas metas para serem cumpridas, mas decidi deixar público a parte de estudo. Isso foi um ponto que, durante um certo tempo, fui deixando para trás por causa da correria do trabalho no dia a dia. Quando me dei conta, estabeleci que precisava ter mais foco nos estudos e tenho tido bons resultados.

  • Cursar o M30
  • Cursar o Positive Coaching

Quem quiser acompanhar a evolução das minhas metas, é só me seguir no instagram @lisa.hayashida. E você, já definiu suas metas para este ano?

Mudanças x Pessoas

Pessoas são diferentes, fato. Não existe uma abordagem única que sirva para todos. Para melhorar uma organização, é necessário trabalhar com as necessidades das pessoas individualmente e lidar com as barreiras que edificam suas mentes.

Uma forma de  mudar uma organização, a nível de indivíduos, é aplicando o modelo ADKAR, criado por Jeff Hiatt em 2006. Trata-se de um modelo de gestão de mudanças orientado a metas, que não deixa esquecer de lidar com o aspecto de pessoas.

Esse modelo possui 5 dimensões:

adkar

Awareness (Consciência)

As pessoas precisam ter consciência da vontade de mudar. Mas isso depende muito da forma de transmitir essa mensagem. É necessária uma boa comunicação, que vai desde o conteúdo da mensagem até a forma de transmitir. Um outro ponto importante é dar o exemplo. É necessário mostrar como sua visão pode se transformar em realidade, praticando aquilo que está se pregando.

Desire (Desejo)

Além de conscientizar as pessoas a respeito de suas ideias, é importante complementar com gatilhos emocionais para que a mudança aconteça, ou seja, a mudança precisa ser urgente e atraente. As pessoas precisam sentir a crise e experimentar as ideias para desejar a mudança. Procure atingir os desejos intrínsecos: status, ordem, honra, propósito, curiosidade, maestria, aceitação, liberdade, poder e relação.

Knowledge (Conhecimento)

Depois de ter consciência da necessidade de mudança e do desejo, o próximo passo é entender o que precisa ser feito. A maneira de como ensinar quanto o seu conteúdo. Isso pode ser feito por técnicas de aprendizado interativas, como storytelling, exercícios e jogos.

Ability (Habilidade)

Após ter o conhecimento, é preciso ter habilidade para mudar. Um agente de mudança precisa remover qualquer obstáculo que possa impedir que as pessoas adotem os comportamentos desejados. Dê às pessoas o espaço e os meios de que precisam para aprender e praticar suas habilidades.

Reinforcement (Incentivo)

A mudança precisa ser sustentável, por isso precisa de incentivo. Todo processo de mudança precisa ter ganhos de curto prazo. As pessoas precisam sentir que estão fazendo um bom trabalho. Certifique-se de comemorar os pequenos sucessos para que as pessoas saibam que estão caminhando na direção certa e para que queiram continuar trabalhando para atingir esses objetivos.

Fonte: Appelo, Jurgen. How to Change the World: Change Management 3.0, 2012

PDCA

Todas as vezes que visito disciplinas a respeito de Gestão de Projetos PMI ou Gestão Ágil, essas quatro letrinhas sempre aparecem na lista de conteúdo. E, na realidade, é possível utilizar em qualquer coisa que você queira fazer, seja num projeto de trabalho, seja num projeto pessoal ou promover melhoria contínua.

ciclo-pdca-3

O modelo PDCA foi desenvolvido por Walter Shewart, no início da década de 1920 e foi popularizado na década de 1950, por William Edwards Deming. Trata-se de um modelo interativo de quatro passos, onde você determina uma sequência de intervenções e valida seus efeitos no sistema. Quando funciona você vai para o próximo passo, caso contrário tenta algo diferente. O conceito do modelo PDCA está baseado no método de hipóteses, experimentação e avaliação. Abaixo, deixo um pequeno resumo de cada um dos seus passos.

Plan (Planejar)

Antes de qualquer coisa, é preciso ter uma meta a ser cumprida. É importante deixar claro o que você quer conquistar. Quando já se sabe aonde quer chegar, uma boa forma para começar é encontrar exemplos onde as coisas estão indo bem e observar as boas práticas. Em muitas iniciativas de mudanças, não é necessário começar do zero. Pode procurar onde já está funcionando, e começar com elas. Não foque excessivamente no resultado final, foque nos primeiros comportamentos, principalmente aqueles que podem fazer a diferença.

Do (Executar)

É importante começar com pequenos passos. Não basta ter uma visão geral do que se quer. É necessário também apresentar metas de curto prazo que sejam claras e realistas. Faz parte da gestão de mudanças descobrir os passos a seguir e escolher o momento e locais certos para começar

Check (Verificar)

Depois de dar os primeiros passos, você precisa verificar e compreender como o sistema responde e se livrar daquilo que não funciona. Além de verificações qualitativas (feedbacks) é necessário medir também os resultados quantitativos. Se o resultado não foi bom, será que é possível tentar algo diferente?

Act (Agir)

Ciclos curtos de feedback são melhores, pois saber se algo funciona ou não evita que você invista muito tempo em uma abordagem ruim. Quando as coisas ainda estão frescas nas cabeças das pessoas, há mais detalhes que podem ser refletidos no feedback. Permite também usar ganhos de curto prazo para evidenciar que sua mudança vale o esforço.

 

Fonte: Appelo, Jurgen. How to Change the World: Change Management 3.0, 2012

 

FISL 11 – Final de feira

O último dia do evento foi um tanto quanto vazio, se comparado a outros dias. Muita gente já tinha programado para voltar para suas cidades de origem durante o último dia ou logo que terminasse o evento. Muitas malas guardadas na recepção. Em geral, as palestras do último dia estavam bem vazias. Podia- se escolher calmamente qual palestra assistir. Enfim, sem muitas coisas para contar. Nesse dia, descobri que as pessoas passavam horas (sentido literal) na fila do estande da Caixa Econômica Federal para conseguir uma camiseta personalizada com sua caricatura… =/ Conclusões que eu posso tirar dessa experiência: um evento dito como internacional ainda possui algumas deficiências tais como wifi deficiente e falta de estrutura para que as pessoas fiquem com seus note/netbooks ligados full time. Vi muita gente pelos cantos procurando tomadas, inclusive eu. E muita gente com seus computadores nos corredores e arredores. Havia nerds de todos os tipos: estudantes, profissionais e simpatizantes. O nível das palestras em geral era bastante básico (pelo menos, das palestras que assisti) daria para a empresa onde trabalho enviar vários palestrantes, de todas as áreas de tecnologia: desenvolvimento, administração de sistemas, banco de dados, interface, qualidade; lá tem vários ‘cases’ que poderiam ser apresentados num nível bem mais elevado de quem estava lá. Mas é sempre bom saber o que outras organizações estão trabalhando. Acho que seria uma excelente oportunidade de divulgação da empresa também, como usuária e contribuidora do movimento de software livre, não só em palestras, mas também nos estandes, por que não? E quem sabe, encontrar algum talento novo. Ter o evento numa universidade, me fez sentir nostálgica, com saudades dos meus tempos de faculdade. Não tenho dúvidas de que o clima de uma boa univerdade renova qualquer ânimo. Ver pessoas diferentes é bastante interessante.

FISL 11 – Palestra: Desenvolvendo software na nuvem

Palestra feita por Bruno Souza (Javaman) e Fabiane Nardon.
O Javaman começou falando das vantagens do desenvolvimento de software na nuvem, que visa o alcance de mais pessoas e barateamento de custos.
Entre os motivos de fazer o cloud computing ele cita: 70% tempo de pequenas e médias empresas é gasto com gerenciamento de sistemas de TI; conhecimeno compartilhado na rede; infra-estrutura; 11% possui infra para trabalho remoto;
Depois a Fabiane citou ferramentas para desenvolvimento em cloud computing que vão desde issue tracker, controle de versão, integração contínua, gerenciamento de biblioteca.
A apresentação deles está disponível em http://prezi.com/nrdglitkkmli/desenvolvendo-software-na-nuvem e eles tem mais informações disponíveis em sua página no twitter @toolscloud.

FISL 11 – Palestra: Quer aprender a programar de verdade, pergunte-me como

O palestrante foi o Henrique Bastos. É a segunda palestra que eu assisto dele, consequentemente, os mesmos ‘causos’, mas mesmas frases de feito.
A primeira foi dele me explicando scrum “by the book”, com o seu surpreendente exemplo de que, usando scrum, uma equipe de 14 pessoas colocou um site no ar em 1 dia. Mas essa segunda foi interessante.
Ele começa explicando o início de carreira inial de um desenvolvedor: programando pascal na faculdade e fazendo um estágio formal. Segundo o palestrante, o ensino de computação é waterfall, mais do que em empresas.
Como técnicas para aprimoramento de desenvolvimento, ele citou o DojoRio (pares) e o ForkingRio (individual)
Dojo: um grupo se reúne, alguém propõe um problema lúdico, o grupo decide uma estratégia inicial, decide os papéis. Como papéis há o piloto e co-piloto, sendo que esse segundo não programa. Os papéis mudam a cada turno. São fases do Dojo: vermelho, piloto escreve o teste e o código, co-piloto ajuda o piloto e a plateia observa em silêncio; verde, execução de testes, todos, inclusive a platéia podem dar opiniões; refatoração: “organizar o código como se o próximo programador fosse um psicopata que sabe onde você mora”; retrospectiva.
Forking: feito normalmente para contemplar os finais de semana, o grupo decide o que estudar e o que implementar. Depois cada um vai para sua casa, fazer sua própria implementação. Na segunda se reúnem,depois é feito o merge, união das soluções e o diff, comparação das soluções implementadas.
Duas formas curiosas de formar um grupo de estudo 😉

Frases de efeito:
Arte e ciência são duas faces da mesma moeda (Donald Kunth)
Teoria e Prática são faces da mesma moeda (palestrante)

FISL 11 – Terceiro dia

Cheguei um pouco mais tarde que os outros dias e, consequentemente, perdi o mayor do foursquare para o rapaz da globo.com.
Desisti de assistir palestras mas técnicas. As que eu assisti eram muito básicas, e eu sempre chegava no final com um pequeno sentimento de frustração. Passei o dia procurando palestras aleatórias, apenas para ouvir os seus ‘cases’.
Nessa leva, assisti Scott Chacon repetindo o mesmo mantra de outros, que é bom participar de comunidades open source, recomenda escrever um código decente pois outros desenvolvedores irão analisar esse código, falou um pouco de desenvolvimento com times pequenos (scrum??). Teve uma outra apresentação (Por que sou fanático por testes e você é umbundão), uma espécie de teatro que dá ênfase na importancia dos testes em todo o desenvolvimento. Teve também a apresentação de Jared Smith, da Red Hat, apresentando em linhas gerais o desenvolvimento open source do Fedora. Não sou tão fã assim de Linux, então não assisti a apresentação do Maddog, sorry people.
Depois de garimpar as palestras, dei uma nova volta pelos estandes e comprei uma jaqueta com o logo do FISL. Por conta disso fui chamada de nerd (vejá só… o sujo falando do mal lavado) mas fazer o quê…
O local dos estandes costumavam servir de ponto de encontro do pessoal da firma. Abaixo uma fotinha da turma reunida no final do dia (foto by Chui)

Nessa noite fomos jantar junto com o pessoal o iG, os antigos coleguinhas de trabalho. O pessoal do estande da firma também estava na mesma churrascaria, aliás… houve um certo atrito por causa desse jantar. Como fui convidada pela turma do iG, foi com eles que fui jantar…