Mostrando postagens com marcador Gestão Híbrida. Mostrar todas as postagens
Mostrando postagens com marcador Gestão Híbrida. Mostrar todas as postagens

sexta-feira, 25 de setembro de 2020

Agilidade para que?

Lendo o 14º relatório anual State of Agile, cujo link colocarei nos comentários, vi um dado que chamou a minha atenção: dentre as empresas participantes da pesquisa que adotaram métodos ágeis, 71% afirmaram ter sido motivadas pela Aceleração das entregas de software e 51% pelo Aumento da produtividade.

Isso me assusta, pois entendo que Agile não é sobre velocidade de entrega, é sobre velocidade de adaptação, é sobre aprendizado empírico e mudança. E esta adoção da agilidade pelo motivo errado pode levar a prejuízos para a empresa e para a imagem dos processos Lean-Agile.

Penso que a ideia por trás do Agile não é terminar um projeto mais cedo. É entregar partes utilizáveis mais cedo para que as experiências destas partes nos ensinem a construir as próximas. Os processos ágeis vem do mundo de John Locke, onde somente é possível conhecer alguma coisa através da experimentação; logo, faz sentido usar agilidade se, e somente se, você está num mundo de incertezas e constantes mudanças.

Se o seu problema é resolvido por meio do raciocínio, se as suas experiências anteriores te permitem prever o que precisa ser feito ou se você consegue planejar entregas com meses de antecedência: Parabéns, você não precisa de Agilidade! Neste mundo Cartesiano os métodos preditivos tradicionais funcionam muito bem e com menor custo. Entregas iterativas e planejamento em ondas já são previstos por PRINCE2, PMBoK, RUP e outros há mais de uma década.

Por favor, não façam Design Thinking para trocar lâmpada! Nem Lean Inception para construir um produto que vocês já conhecem. MVP serve para provar uma tese, não para acalmar stakeholder ansioso. 

Acredito que, se você quer que seus desenvolvedores produzam mais, se sintam mais felizes e motivados, processos ágeis isolados não vão resolver. Você deve aplicar boas práticas de Arquitetura de Software e de Quality Assurance, deve melhorar seus Líderes e mudar o ambiente.

Vejo muitas organizações confundindo gestão 3.0 com infantilização da gestão. Encher a empresa de videogames, oferecer lanchinhos e espalhar murais coloridos tornam o ambiente descontraído, alegre, divertido, aumentam o conforto, a vontade de permanecer ali etc. Nada disso adianta se você continuar medindo as pessoas em função dos resultados, não funciona se você continuar dando privilégios aos "gerentes", não serve de nada se você continuar gerindo as pessoas em vez do sistema. Transformar sua empresa num jardim de infância não a tornará mais efetiva.

Um líder estúpido continua estúpido, mesmo quando chamado de Scrum Master.
Um código ruim continua ruim até ser refatorado, não importa quanto tempo você demora entre um release e outro.
Um ambiente tóxico continua tóxico, mesmo com quadros e adesivos coloridos.

Essa é a opinião de um mero adepto do Hybrid Manifesto e da Ambidestria Organizacional. E você, o que pensa sobre isso?

quarta-feira, 26 de agosto de 2020

A ingrata comparação entre Scrum Master e Gerente de Projetos

 Olá, pessoas!

    Neste mini-artigo vou falar um pouco sobre uma comparação imprópria que infelizmente muita gente insiste em fazer: Scrum Master vs. Gerente de Projetos.


    Essa comparação me parece tão absurda quanto a tradução de alguns filmes Norte-Americanos que vertem quarterback como zagueiro. E o problema maior não é o fato de o quarterback ser o líder do ataque, mas o fato de serem esportes diferentes (Futebol Americano e Futebol são completamente diferentes!). Não se pode comparar a função de um pivô no basquete com a de um pivô no futsal; por mais que existam semelhanças, são coisas completamente diferentes: outro esporte, outro objetivo, outro conjunto de regras.

    Da mesma forma, Scrum Master e Gerente de Projetos são funções diferentes de processos diferentes. Existem similaridades, como o fato de exercerem liderança sobre os times, mas são "esportes" diferentes. Diga-se de passagem, os trabalhos de "SM" e "GP" podem coexistir sem conflitos ou sobreposição de funções.

    Assim como uma equipe olímpica tem jogadores de vôlei, basquete e futebol, a equipe do projeto pode ter Gerente de Projetos, Gerente de Produtos, Time de Projeto e Time de Scrum (Scrum Master, Product Owner e Dev Team).

    As funções não são necessariamente opostas, nem complementares, são paralelas. Conforme a metodologia adotada pela empresa, podemos ter SM e GP trabalhando juntos, separados, não ter um (ou nenhum) dos dois... uma mesma pessoa alternando entre as duas funções etc.

    Voltando a analogia esportiva: alguns atletas olímpicos competem em mais de uma modalidade. Se não houver conflito de agendas, nada os impede de fazer isso (sem falar nos atletas do Decatlo!).

    Eu não vou tomar o tempo de vocês listando as funções e responsabilidades dos papéis de SM e GP, isso vocês já sabem ou podem aprender rapidamente no Google. Quero apenas destacar a única comparação que considero justa:

    Scrum Master joga em times Ágeis, Gerente de Projetos joga em times Preditivos. Ambos jogam em times híbridos.

    Simples assim.

Scrum - You're doing it the right way! Or... maybe... not at all

     Once upon a time, a long time ago, in a galaxy far, far away, there was a human called John Goodsense. John was a senior Scrum Master, ...