Thiago Giovanella

Um repositório sobre Agilidade, Gestão e Psicologia Organizacional

[Recomendado] O Poder da inteligência emocional

Como liderar com sensibilidade e eficiência? O que a palavra “sensibilidade” está fazendo aqui? Este livro traz uma reflexão importante sobre o papel do lider na cultura organizacional e na experiência do colaborador. Vale muito a pena a leitura.

O efeito “Elephant Carpaccio”

Caso você tenha chegado neste artigo sem saber do que se trata o “Elephant Carpaccio”, não se preocupe, no final deixarei diversos links para que você compreenda e aprenda como praticar. De antemão: vale a pena!

Como previsto, não pretendo neste artigo ensinar como aplicar o exercício junto do time, para isto eu deixei os links no final do texto. Este post é quase um depoimento do que vejo como benefício do exercício além de quais problemas eu acredito que ele ajude a tratar.

De que problemas estamos falando?

Estar atento às oportunidades de aprender quando elas aparecem — e aproveitá-las espontaneamente para praticar novas aptidões — é um jeito rápido de melhorar.

Daniel Goleman, Richard Boyatzis, Annie McKee e Berilo Vargas em: O poder da inteligência emocional: Como liderar com sensibilidade e eficiência

Um grande “problema” sem dúvidas é a dificuldade do time em olhar para o produto sem “ver suas engrenagens”. Digo, olhar pro produto como consumidor, sem pensar nas suas partes, como fazer, complexidades, restrições e etc.

Outro desafio comum é estipular prioridades e dependências. Criar um fluxo de trabalho menos dependente (lembra do INVEST?).

Estipular um plano de entregas que se pareça mais com “um pedaço de bolo que uma camada do bolo” de maneira que a entrega seja realmente usável e não somente mais um pedaço de complexidade no sistema que promete – no futuro – ser algo útil à quem precisa do produto.

Como a atividade pode ajudar?

Seja veloz, e não apressado. Você não precisa acelerar; basta não parar;

Joel Moraes em: Esteja, viva, permaneça 100% Presente: O poder da disciplina, do foco e dos mini hábitos para conseguir realizar seu potencial máximo

A atividade busca fazer com que o time entregue “pedaços do elefante” que ainda se “pareçam com um elefante”. Ou seja, qualquer parte entregável é inconfundivelmente uma parte do sistema esperado. Acredite, parece fácil, mas não é.

Dada a restrição de tempo e abstração do escopo proposta na atividade, o time de desenvolvimento precisa se desvencilhar das amarras do pensamento técnico e olhar pro produto como entregável. Cada final de “sprint” precisa ter uma entrega e ela precisa ser usável (aquele pedaço do elefante que se parece com um elefante).

O time de desenvolvimento precisará compreender e pensar na complexidade do que está sendo entregue e principalmente sobre o que está sendo deixado de ser entregue, sem comprometer o resultado da entrega.

Como a dinâmica é executada em pequenos times, num segundo momento o “plano” de cada time é apresentado aos demais e isso faz com que todos comparem suas soluções e aprendam com o raciocínio do grupo, criando também um novo método de trabalho retirando o melhor de cada proposta.

Finalmente, o time estará mais próximo do que realmente é a proposta de MVP e como isso pode ser decisivo para o sucesso de um produto digital.

Infelizmente não conheço muitos conteúdos deste assunto mas tenho certeza que não será difícil traduzi-los já que são todos links da internet. 😉

INVEST – Adicione valor ao seu projeto

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning.

Rick Cook em The Wizardry Compiled

Não se ofenda com a provocação se você for programador tampouco se for usuário. Já temos maturidade suficiente pra entender que não existe uma tradução fácil entre os idiomas do ambiente de negócios e o idioma dos ambientes de desenvolvimento. E este é o motivo que me impeliu a escrever este post. Me dê mais 2 minutos, não desista agora!

Partindo do princípio – O que é INVEST?

INVEST é mais uma daquelas siglas legais que ajudam a fixar um conteúdo relevante. Criada por Bill Wake, serve como um gentil lembrete do que um backlog de produto de qualidade precisa compreender, além disso, ressignifica a sigla SMART para o contexto de desenvolvimento de produto (de software, mas flexível o suficiente para o desenvolvimento de qualquer produto).

INVEST significa:
Independent (independente)
Negotiable (negociável)
Valuable (de valor)
Estimable (estimável)
Small (pequeno)
Testable (testável)

Vale dizer também que esta metodologia é fortemente recomendada por Mike Cohn em suas publicações (veja o livro aqui neste link. Caso prefira alguma obra em português, acesse neste link) .

Uma verdade dolorosa

Não esperamos ou não deveríamos esperar que um software seja visto por usuários e engenheiros de software da mesma maneira. Vou adiante, não deveríamos esperar que qualquer que seja o produto seja visto e avaliado da mesma maneira por quem usa e por quem fabrica.

Faça uma analogia e reflita, em um espetáculo de “mágica”, um ilusionista profissional teria a mesma experiência do restante da – leiga – plateia? Os valores percebidos seriam os mesmos?

Agora aplique isso para as relações entre médico e paciente, contador e cidadão, programador e usuário e etc. A premissa ainda é verdadeira? Pois bem, sigamos.

Converter uma expectativa em um produto viável é uma tarefa complexa e não se trata somente da produção do item desejado, precisamos entender que se trata da conversão de um domínio em outro.

Explico, trata-se da comunicação partindo da origem que fala a linguagem de um universo para o destino que fala a língua de outro universo. Cada um em uma margem diferente, separados por um oceano inteiro de experiências, preferências, histórias e por aí vai.

Cabe então a nós, que transformamos a ideia em produto, a incumbência de traduzir e fragmentar os desejos e necessidades em partes comunicáveis e factíveis, reduzindo as chances de fracassos e prejuízos ao longo do processo.

Aqui é que o INVEST faz todo o sentido.

Independent

É bem melhor concluir 80% das histórias do que 80% de cada história. Foque a conclusão das histórias.

Robert C. Martin em Desenvolvimento Ágil Limpo: De volta às origens

Tarefas independentes são fáceis de planejar sua execução e também de executar em paralelo, podendo ser um grande aliado do time do projeto, reduzindo eventuais atrasos ou ainda aumentando o acumulado de entregas.

Raramente existirá, se é que existe, projetos com tarefas unicamente independentes, Mesmo assim, tente escrever as histórias o mais independente possível. Mesmo que uma tarefa precisa esperar o momento certo de ser executada, ela precisa ter começo, meio e fim em si mesma, dessa forma tudo que precisa para compreender o início de uma tarefa e decretar que esta foi finalizada, está dentro dela mesma.

Negotiable (e negotiated)

Os detalhes de uma tarefa precisa ser cocriado com quem irá executar a tarefa. O patrocinador com certeza sabe muito bem do que precisa, mas não sabe tão bem como fazer quanto aqueles que vão fazer, logo, trabalho para várias cabeças realizar.

Defina as tarefas, negocie o seu critério de aceite, negocie como e quando e se precisar, negocie novamente. Um projeto é um organismo vivo.

Imagine que ao longo da execução do projeto, por acompanhar e aprender com o seu desenvolvimento, o patrocinador identifica uma forma de agregar ainda mais valor. Isso não deveria ser aceito de imediato? Pois então, negociem.

Agora pensem no cenário onde algo definido na fase de ideação do projeto realmente não seja possível de ser adicionado por um motivo justificável. Negocie uma saída viável.

Jamais deixe que o time de desenvolvimento estime mais do que uma sprint e meia. A chance de estimativas “perderem a validade” nestes casos é muito grande em virtude de mudanças de arquitetura, dependências, prioridades, etc é muito grande e com isso perdemos o tempo que se levou estimando.

Luis Duarte em Scrum e Métodos Ágeis: Um Guia Prático

Valuable

A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive
them as important.

Bill Wake em INVEST in good stories: the series

Com esta analogia, Bill Wake quer dizer que devemos “cortar na vertical” as camadas do bolo e não na horizontal, caso contrário serviríamos só a cobertura, depois só a massa, depois só o recheio e assim por diante. Isso não se parece com um bolo de aniversário, certo?

Este requisito é um grande desafio quando se precisa dividir requisitos em histórias (Épicos em Histórias, se você preferir). Bill Wake recomenda pensar em uma história como um bolo de várias camadas (um bolo de aniversário, por exemplo), quando estamos dividindo uma história é como se estivéssemos servindo um pedaço do bolo.

Pensando em um produto de software, é melhor pensar as histórias de forma que possam ser usadas pelo usuário. Criar todas as tabelas em um banco de dados mas não ter como acessá-las, pode dar muito trabalho, mas não entrega muito valor ao cliente, assim como ter uma interface de sistema desenhada mas que não pode ser utilizada pelo cliente pois não se conecta com as outras partes do sistema. Estes são exemplos de “cortes horizontais” que devem ser evitados quando queremos escrever boas histórias de usuários.

Estimable

Dizer que uma história precisa ser estimável não quer dizer que o seu valor tem que ser preciso ou que este valor deverá estar escrito na pedra, pois se fosse, o conceito de negociável não faria sentido, certo?

Uma boa história precisa ser estimada o suficiente para ajudar no ranqueamento e agendamento da sua implementação. Senão veja, 10 histórias de 5 pontos não deveriam estar juntas na mesma sprint se a capacidade de produção do time é de 30 pontos. Faz sentido? Neste caso ter estimativas nas histórias ajudarão o time a priorizar e selecionar as histórias que devem estar juntas na próxima rodada de desenvolvimento do produto (ou sprint).

Small

Boas histórias tendem a ser pequenas, suas descrições também. Não que devemos economizar informações, somente não colocar coisas que tornem a leitura e entendimento da história confusa ou ainda controversa. Alistair Cockburn descreve os cards das histórias como “fichas prometendo uma futura conversa”.

Histórias menores tendem a ter a acurácia da estimativa maior, reduzem os riscos de implementação e são mais facilmente verificáveis.

Testáveis

Se um cliente não sabe como testar alguma coisa, isso pode indicar que a história (o seu requisito) não está claro o suficiente ou que esta história não reflete algo de valor. Ou pode ainda indicar que este cliente precisa de ajuda para formular o seu pedido e consequentemente os casos de teste.

Clientes tendem a descrever somente o caminho feliz de uma atividade, se esquecendo de todas as exceções que precisam ser consideradas na rotina de alguma atividade. Preparar um produto para estas exceções pode facilmente ser o maior esforço no desenvolvimento da história e consequentemente do produto como um todo.

Finalmente

Escrever boas histórias é uma atividade multidisciplinar e para ser feita em grupo. Da ideia à execução passando pelo planejamento e estimativas requer revisões, negociações, adaptações, comparações, etc. Nada disso é possível de ser feito sem o envolvimento de quem idealiza e de quem executa.

Experimente adotar a sigla INVEST nas próximas vezes que for pensar o desenvolvimento de um produto. Se você se lembrar, volte aqui e comente sua experiência. Até a próxima.

Acesse conteúdos sobre INVEST e muito mais no site do XP123 de Bill Wake clicando aqui e faça o download do e-book sobre INVEST neste link.

[Recomendado] Scrum: Guia prático: Maior produtividade. Melhores resultados. Aplicação imediata

Este livro é um complemento fundamental para o Livro de Scrum: A arte de fazer o dobro do trabalho na metade do tempo. Neste livro JJ Sutherland além de diversos insights reais de sua experiência, compartilha também dicas extremamente úteis de como adotar o Scrum em um formato do tipo “passo a passo”.

Joe Justice sempre diz: “Usar o Scrum é reduzir o custo de mudar de ideia.”

JJ Sutherland em Scrum: Guia prático – Maior produtividade. Melhores resultados. aplicação imediata.

A leitura deste livro é tão boa quanto à do seu par (aquele outro do Scrum que vocês sabem, rs). Os insights são bastante inspiradores e as dicas são úteis tanto para quem nunca usou Scrum quanto para quem já está acostumado a trabalhar em times ágeis. Leitura recomendadíssima!

Você pode comprar o seu livro aqui

[Recomendação] Scrum: A arte de fazer o dobro do trabalho na metade do tempo

Neste livro Jeff e JJ Sutherland contam cases reais em projetos de diferentes segmentos com detalhes de problemas enfrentadas e como estes problemas foram contornados utilizando o Scrum. Destaco a sinceridade dos autores deixando claro quando expectativas precisaram ser renegociadas, sobre a inflexibilidade de alguns clientes e as estratégias adotadas como saída.

Tradicionalmente, a gerência quer duas coisas em qualquer projeto: controle e previsibilidade. O resultado disso é uma quantidade imensa de relatórios, gráficos e diagramas – justamente o que ocorreu na Lockheed. Gastam-se meses no planejamento de todos os detalhes para que nenhum erro ocorra, o orçamento não estoure e tudo seja entregue no prazo.

Jeff e JJ Sutherland em Scrum: A arte de fazer o dobro do trabalho na metade do tempo

O livro é uma leitura muito fácil e com certeza você vai ler este livro mais de uma vez. Dica: destaque os pontos que você notar importante pois é sempre muito útil voltar ao livro para tirar insights.

Você pode comprar este livro aqui!

Previsão do Passado

A performance de um time muito comumente avaliada pelo gráfico de “Velocity” é um instrumento valioso tanto para o time de desenvolvimento quanto para os patrocinadores do projeto já que reproduz com fidelidade a performance do time e a sua evolução.

Em situações normais é esperado – e acontece – que a performance do time aumente à medida que o projeto se desenrola já que o grau de incerteza das tarefas diminui , a maturidade do time sobre o domínio do projeto aumenta, a interação e colaboração se afina e etc.

No entanto, é desaconselhável – pra não dizer errado – que a performance do time seja prevista baseado em fatores externos ao projeto corrente como, histórico de outros projetos, experiência individual de cada membro do time e etc. já que “cada caso é um caso”. Um único projeto já possui em sua essência variáveis suficientes para tornar o seu futuro imprevisível, quem dirá então quando envolvidos outros projetos para comparação.

O passado é o real que já foi. E que já não é mais. E, portanto, não é.

Clóvis de barros em ePAMINONDAS: o gATO EXPLICADOR

Entenda, cada projeto tem um grau de ânimo dos patrocinadores, orçamento e flexibilidade deste, experiências e expectativas do time, fatores geográficos, climáticos, psicológicos, políticos e tantos outros que não permitem que dois projetos por mais semelhantes que sejam, tenham equivalência total. É imperativo que cada projeto precisa ser analisado e avaliado como único e inédito. Ponto.

O tempo é finito. Trate-o como tal. Divida seu trabalho em partes que possam ser realizadas em um intervalo de tempo curto, regular e definido – de preferência, entre uma e quatro semanas. Se você tiver sido contaminado pelo Scrum, chame esses períodos de sprints.

jEFF sUTHERLAND em Scrum: A arte de fazer o dobro do trabalho na metade do tempo

Não pretendo falar sobre todo o potencial do acompanhamento (realista) da velocity do time neste artigo. O meu desejo aqui é alertar para a única forma confiável que existe para predizer se para futuras sprints a performance tende a aumentar ou não. E esta forma é olhando pra trás.

Claro que eu não inventei isso mas me inspirei no que Jeff Sutherland e seu filho escreveram. Eu verifiquei isso ao longo de minhas experiências profissionais tanto como desenvolvedor quanto como gerente.

O mapa não é o terreno! Você já ouviu isso e se trabalha com desenvolvimento de software sabe que isso é verdade sempre. O planejado e o realizado podem ser bem diferentes um do outro, portanto, confie no terreno, não no mapa. Aceite e interaja com o que é realidade do projeto não com o que foi pensado e definido para o projeto.

As restrições de WIP identificam gargalos e áreas problemáticas no processo, auxiliando o time a tomar decisões para resolvê-las.

Mary provinciatto e paulo caroli em Sprint a Sprint erros e acertos na transformação cultural de um time ágil

Trabalhe com o Work in Progress (WIP) possível e incremente-o sempre que o time for capaz. Gerar um WIP maior do que o time tem historicamente praticado e maior que a capacidade percebida do time só vai aumentar a pressão e consequentemente o número de erros, bugs, refatorações e o desgaste de cada um dos envolvidos e entre eles.

Por este motivo olhar para trás, acompanhar o ramp-up do time, a evolução natural que o terreno permite e definir um crescimento racional e alcançável além de criar uma expectativa realista para os patrocinadores sobre o futuro do projeto, aumenta o engajamento do time, cria a – deliciosa – sensação de obtenção de resultados, torna o time ainda mais disposto a obter melhores resultados e melhora o gerenciamento.

Velocity aumenta e diminui. Cada sprint é uma sprint. Acompanhe cada realidade individualmente e aprenda junto com o seu time o que o projeto permite. Um time engajado vai sempre entregar o melhor possível, sempre! Acredite no time e resolva os impedimentos, a performance é consequência.

[Mais] Um início de jornada com blogs

Primeiro diga a si mesmo o que você seria; então faça o que precisa ser feito.

Epicteto

Este não será – pelo menos por um bom tempo – o melhor repositório sobre agilidade, gestão ou psicologia organizacional que você encontrará na internet. E também tenho consciência de que em um cenário de Instagram, LinkedIn, TikTok e Medium, começar um blog do zero não seja a melhor ideia para quem tem intenção de ser popular.

Sendo assim então que fiquem claras as intenções deste repositório. Este blog é um repositório pessoal dos meus estudos compartilhados publicamente.

Gosto de estudar e estes assuntos (psicologia organizacional, gestão, agilidade [e as vezes Estoicismo]) são assuntos que me interessam muito então esperem ter bastante conteúdo disso por aqui. Bom, bastante vai levar um tempo, mas se tudo der certo, terá.

Este post é um contrato firmado de mim comigo mesmo. Não pretendo me tornar uma referência nacional destes assuntos mas se eu conseguir orientar alguém que porventura esteja começando alguns dias depois de mim, fique a vontade para consumir e comentar.

Este é o primeiro post em 16 de Novembro de 2023. Axé!

Desenvolvido em WordPress & Tema por Anders Norén