Mostrando postagens com marcador Scrum. Mostrar todas as postagens
Mostrando postagens com marcador Scrum. Mostrar todas as postagens

quinta-feira, 21 de julho de 2022

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, hired to lead an Agile Chapter within a traditional organization.

    On his very first day, John was presented to an onboarding whitepaper, which introduces new employees to Scrum Framework. John read these 3 pages and said:

— That's wonderful! You've got every single concept completely explained wrong! — I'm joking, he did not say that.

    This was the real reaction:

— Okay, that's fine. But, if you don't mind, I'd like to make some improvements.

— That would be great! — Replied the Head of Business Agility.

So Goodsense listed his points.

— First of all, I believe we should remove the word "Methodology". Methodologies are typically composed of stringent and mandatory sequences of processes and procedures that implement predefined algorithms. And this is the opposite of Scrum.

    Second, Scrum is not based on the scrum formation from Rugby. Not even the first reference to scrum formation in Product Development. The article "The new new product development game" has associated successful development teams with rugby teams since 19.860. The basis of the Scrum Framework is Lean Thinking and Empiricism.

    Third, write stories to the Backlog is one of Product Owner's minor responsibilities. The PO is essentially a value maximizer, as the title of the role says: He/She is the Owner, the one who looks after success and profit.

    Fourth, Scrum Master is not a Master of Ceremonies, not a secretary, not even a Product Owner Helper. The SM is accountable for team's effectiveness and for establishing Scrum as described in the Scrum Guide.

    Fifth, or whatever, there is no sub teams in Scrum. Developers, Product Owner and Scrum Master are one single unity of work, one single team.

    Rituals and Ceremonies, I used to attend in the Church. Scrum have Events.

    Estimates are not mandatory.

    It is not an obligation to place all tasks in the Sprint Backlog within Sprint Planning. In fact, we may not have any tasks. Sprint Backlog is a plan composed of a fixed Goal and an emerging list of items. Splitting items into tasks is optional.

    The Scrum Team commits to the Sprint Goal, not to the Sprint Backlog. The Goal must be achieved with minimum effort, no matter how many or what items have been completed.

    The 3 questions were — Thank the Goddess! — removed from the lastest version of the Scrum Guide.

    The PO validates development and provides feedback to developers on a daily basis, not just at an event.

    Review is neither a presentation nor a demonstration. It is a working session to inspect and adapt. Key stakeholders shall experience the increment, use the product, to produce empirical knowledge.

    Retrospective's action items don't need to be implemented the next Sprint. Maybe those items are medium- or long-term actions.

    Product Backlog is not an ultimate requirements list, it's an emerging ordered list of what is needed to improve the product. Mind that Scrum is Empirical, so the needs emerge from experience not imagination.

    The same applies to Sprint Backlog, it must be adapted during the Sprint.

    The Head of Business Agility surprisingly, or not, told John:

— Great! I suggest you write a new whitepaper. Wherever you want! Not here.

    And that's how John Goodsense was fired in his very first day on the job.

terça-feira, 26 de abril de 2022

Silent Scrum

First step: our agreements.

1 - This is my very first article written in English, so it may look like a toddler's essay.
2 - This is not about silent, nor shy, people doing Scrum. It's about Scrum being silently adopted by an organization. No shouting, no yelling, no "Let's do Scrum!". Just doing scrum, practice first.

Second step: some context.

A long time ago, in a galaxy far away, I've just been hired as an Agile Master on a software development team. The team had some experience with Kanban and developers suffered from what I call Aversion of Scrum.

— Scrum is plastered! It's too much prescriptive. To adopte Scrum, we must change so many things. — They used to say.

— Okay, let´s go along with Kanban.


Third step: the experience.


As a long time Scrum learner, getting prepared for PSM III Exam, I got it as a challenge. Of course, I accepted it. I believed the key for leading this change (adopting Scrum) was to break the cultural barrier (that one I called Aversion of Scrum). And, as I know, it's useless to fight against the culture.

My only option was to cover Scrum artifacts under Kanban practices. And that was really easy.

First, I incrementally added the three Scrum artifacts and its commitments inside Kanban cadences the team used to attend. Then I invited some stakeholders to "beta test" the pieces os software we were building.
Finally, I introduced the team to the Retrospective Meeting, this was the only "gadget" I told them that was brought from Scrum.

Done.

Forth step: Epiphany.


Someday, finishing our biweekly Retrospective meeting, I told them: — Congratulations! You've just completed a very well succeeded Sprint. The Sprint Goal was achieved with less work than we planned, which is good. We have an Increment that is fully compliant with the Definition of Done. Stakeholders have had a good experience with the increment and provided valuable feedback for us to achieve the Product Goal. Now, let's put everything together, with the action itens we've just discussed, to the Product Backlog and start the next Sprint on Monday morning, with the Sprint Planning meeting.

They were all in awe. — or should I say: in shock!

Last step: Conclusions.


When I asked to create a Product Vision and a Product Goal, Developers and Product Owner agreed it would be good. There was no resistance. — What if I said it was a prerequisite from Scrum? —
The same goes about asking for some feedback before a Version is Release — Why the heck would I call it Sprint Review?

I never changed the name "Release Candidate" to "Increment", nor "Replenishment" to "Sprint Planning" (even when we made some improvements to add a Weekly Goal). We just evolved what we used to do, incrementally and experimentally. The result was a fully Scrum compliant Kanban.

Inspection, Adaptation and Transparency have been present all along. Developers had already been initiated into empiricism by Kanban practices. My job was just to encourage desirable behaviors, so that they could turn into culture.

Easily, but not quickly, built. No resistance, no conflicts, just a silent adoption of Scrum. There's no need to rename anything or announce changes before they happen. We can do it without fanfare: show the need, explain the benefits, do it. At the end, announce what you've done.

terça-feira, 15 de fevereiro de 2022

Correção de Bug não agrega valor! Será?

 Certa feita, ouvi um Agile Coach dizer muito enfaticamente: "Correção de Bug não agrega valor para o cliente". Imediatamente pensei: "Se ele soubesse o que aconteceu na Metabook, não falaria isso". E, para explicar o motivo deste meu pensamento, vou contar um "causo".

 Esta história aconteceu no sistema solar de uma estrela chamada Sol, num planeta chamado Terra, um país chamado Brasil, no estado do Rio de Janeiro, na cidade de Nova Iguaçu. Se eu não dissesse que foi num universo paralelo você jamais acreditaria que este é um caso real.

 Na verdade, em relação a nós, este planeta Terra está localizado nos mesmos pontos das três dimensões de espaço e da dimensão de tempo, mas num local diferente na dimensão da probabilidade. Nesta Terra, coisas absolutamente improváveis para nós acontecem frequentemente. Para fim de desambiguação, chamarei o planeta de Terra 2.0.

 Na Terra 2.0, a cidade de Nova Iguaçu/RJ abrigava uma das maiores empresas de TI do país. Nesta empresa, chamada Metabook, João Bonsenso foi trabalhar como Scrum Master.

 Durante uma Sprint Planning, a PO do time dispara:

– Vamos paralisar todas as Melhorias e Evoluções para focar na estabilidade do sistema. A meta da Sprint é recuperar a confiança dos clientes no produto, reduzindo o número de bugs e aumentando a cobertura de testes.

Imediatamente os Desenvolvedores se insurgiram.

– De jeito nenhum! Nós somos desenvolvedores de soluções, não bombeiros.

 João Bonsenso poderia terminar a discussão em 2 minutos, mas preferiu criar polêmica. Simplesmente pediu aos desenvolvedores para explicarem porque pensavam desta forma.

– Um time ágil é criador de soluções, não apagador de incêndios!

– Nós não somos tarefeiros, não queremos fazer número com o suporte!

– Correção de Bug não agrega valor!

 Bonsenso retomou a palavra e perguntou:

– Por que você diz que time ágil não é apagador de incêndios?

– Porque está no "É - Não É - Faz - Não Faz" do time. Aqui, ó! – Respondeu o Dev.

 Bonsenso seguiu:

– Por que vocês associam essa meta a "tarefeiros" e "número com o suporte"?

 E choveram respostas...

– Porque número de bugs é uma Métrica de Vaidade.

– Isso mesmo, é Métrica Tóxica!

(...), (...), (...) 

 Mais uma vez Bonsenso levantou uma questão:

– Por que vocês acreditam que correção de bug não agrega valor?

– Porque a própria Milena disse, quando implantou a metodologia ágil!

– E ela explicou o motivo? – Indagou Bonsenso.

– É porque bug não acrescenta nada de novo no sistema.

 Agora Bonsenso passa a palavra para a PO:

– Por que você acredita que aumentar a estabilidade é o maior valor que podemos entregar na Sprint?

– Porque um sistema de escrituração fiscal que erra no cálculo do imposto não tem valor nenhum. Não existe nada pior para o contador do que mandar o cliente pagar o valor errado. 

 Com as palavras da PO os desenvolvedores bugaram e a sala ficou silenciosa por alguns minutos, até que as mentes dos devs fosse reiniciada. Em seguida, os desenvolvedores concordaram que a melhor opção era fazer a "Sprint de Debug" e perguntaram a João Bonsenso se isso não seria contra o Mindset Ágil.

– Vamos por partes: Em primeiro lugar, o "É - Não É - Faz - Não Faz" tem que refletir a realidade do time e não o time se ajustar ao que diz o quadro. Se "apagar incêndios" é parte da rotina do time, e vocês sabem que é, isso tem que sair da coluna "Não Faz"; jamais o contrário.

 Segundo: não existem métricas de vaidade, nem métricas tóxicas, apenas métricas. Métricas são fatos e todos os fatos são neutros. O que atribui significado, seja positivo ou negativo, a um fato é a interpretação dada a ele. O que define se uma métrica é produtiva ou vaidosa não é o número, é o uso que você faz dele.

 Medir quantidade de bugs para dizer "Reduzi de 1.000 bugs para menos de 10!", é pura vaidade. Acompanhar o número de bugs para identificar se a cada versão o sistema tem se tornado mais instável e se a experiência dos usuários está fortemente comprometida pelos erros, é essencial.

 Terceiro: o Agile Galaxy Manifest diz que a principal medida de progresso é software funcionando. O Scrum Guide of Agile Galaxies diz que o time deve entregar um incremento de produto potencialmente utilizável no final da Sprint.

 Nenhum dos dois fala em entregar "algo novo", ambos falam em entregar algo que funcione. Se corrigir um bug vai fazer uma funcionalidade finalmente funcionar... a entrega incrementa o produto e, portanto, atende plenamente aos requisitos.

 Quarto: a principal responsabilidade do papel de PO é nos indicar como gerar mais valor. Se a nossa PO diz que o maior valor é a estabilidade do sistema, vamos trabalhar na estabilidade do sistema. Não há nada de "anti-ágil" nisso.

 E foi assim que João Bonsenso ensinou ao seu time que correção de bug pode sim acrescentar valor ao produto e evitou a falência do modelo ágil na Metabook e, posteriormente, num efeito borboleta, em toda a Terra 2.0.


Destaco que esta é uma obra de ficção, sem qualquer relação com fatos ocorridos nas empresas nas quais trabalhei ou trabalho atualmente. 

terça-feira, 8 de fevereiro de 2022

Vamos falar sobre transparência?

 "O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho quanto para quem recebe o trabalho". Assim a transparência é definida no #scrum guide, mas será que isso é suficiente?

Para sustentar o pilar o empírico do Scrum, especificamente no desenvolvimento de um produto, acredito que sim. Contudo, quando penso na sustentabilidade do time e da empresa como um todo, entendo que não. Tenho plena convicção de que é preciso levar a transparência a níveis mais altos, alinhando Estratégico, Tático e Operacional em políticas, regras, processos e práticas transparentes. Sem esquecer, claro, da transparência com clientes, fornecedores e público em geral.

Para ilustrar como a falta de transparência da empresa, por exemplo, nas redes sociais pode levar à falta de transparência dos empregados com seus gestores, vou contar uma história verídica acontecida... digamos... no quinto planeta do sistema solar de Betelgeuse, conhecido como Betelgeuse V.

Betelgeuse V ganhara pela 14ª vez consecutiva o prêmio GPTW (Great Planet To Work) na categoria Tecnologia da Informação Intergaláctica. Em suas redes socias interdimensionais, Betelgeuse V não cansava de se vangloriar da conquista: "Somos mais uma vez GPTW!", "Venha tirar uma selfie com o troféu!", "Nossa satisfação interna está acima de 90% há décadas!" etc. etc. etc.

Dentro de Betelgeuse V a realidade parecia totalmente coerente e convergente, para o oposto do que dizia o setor de marketing. Vamos aos exemplos:


Caso 01 - Um Certo Alguém

Quando João Bonsenso chegou, em seu primeiro dia de trabalho, foi avisado de que, se quisesse algum dia crescer na organização, precisaria "cair nas graças" de Certo Alguém.

_ Mas por que isso? Ele é parente do dono?
_ Não, mas ele já foi pego roubando o planeta duas vezes e, em ambas, os denunciantes foram expulsos.
_ Como assim?
_ O diretor de produtos abraçou a questão, o transformou em vítima e ainda o promoveu.
_ Tem certeza de que foi assim mesmo?
_ Não há dúvidas, as provas ainda estão no Git. Só que o diretor lançou um campo de "problema de outra pessoa" sobre elas e agora ninguém mais as vê. Mas você consegue enxergar se se esforçar o suficiente.

Aqui faltou transparência sobre as denúncias, a apuração dos fatos e as decisões subsequentes.


Caso 02 - Encontro com Deus

Certo dia, João Bonsenso teve um problema e buscou seu gestor (aquele Certo Alguém) para resolver a questão. Certo Alguém respondeu:


_ Por que você está me trazendo este problema que pode ser resolvido por mortais?
_ ???
_ Antes de vir a deus você precisa passar pelos Bispos, o Papa, os Santos, Jesus... depois fala comigo.

Neste caso faltou transparência sobre os procedimentos internos para solução de problemas e comunicação.
 


Caso 03 - Ideias apropriadas

João Bonsenso recebeu de Certo Alguém uma tarefa muito importante, perguntou se havia alguma instrução especial para a execução da tarefa e ouviu que não. Ele teria liberdade para executar como preferisse.

Passado um mês, Certo Alguém chama Bonsenso e lhe aplica uma bela bronca.

_ Isso é completamente inadmissível!
_ O que houve?
_ De onde você tirou essa ideia absurda de fazer Sprint Planning deste jeito.
_ Eu sempre fiz assim onde trabalhei
_ Então sempre fez errado. Vou te perdoar porque foi a primeira vez comigo, mas eu não admito um segundo erro. Outra coisa: Ouvi muitos elogios sobre você ultimamente.
_ Obrigado
_ Não! Isso é péssimo! Se os outros setores estão te elogiando é porque você está olhando muito pras dores deles e se esquecendo das nossas. Eu espero que você se preocupe primeiro com as nossas próprias necessidades.

Passados mais dois meses, Certo Alguém reúne metade do planeta para anunciar que, pesquisando as melhores práticas difundidas nos confins da Via Láctea, desenvolveu um novo e revolucionário processo de Sprint Planning. Por ser uma técnica recém-criada na mente dele, começaria em modo experimental para ser evoluída aos poucos.

E apresentou exatamente aquele modo "inadmissível" que João Bonsenso havia usado. Ficando com os louros betelgeusianos da vitória apenas para si.

_ Fica triste não Bonsenso, é assim que se cresce aqui. Agora ele te deve um favor. – Disse um colega.


Agora temos um caso de falta de transparência generalizada. O "mentor" da novidade foi ocultado, a forma como essa novidade foi descoberta também. Este é o famoso castelo de mentiras.


Caso 04 - Sprint Infinita

Certo Alguém criou uma nova regra para as Sprints de Betelgeuse V: Os desenvolvedores deveriam trabalhar até que todos os itens de backlog estivessem completos. Não importando se para isso teriam que fazer horas extras, trabalhar sábados, domingos ou feriados. Sem receber nada por esse trabalho além do expediente.


_ A empresa se comprometeu a pagar os salários de vocês. Vocês se comprometeram a entregar essa Sprint. A empresa cumpre o compromisso dela e vocês tem que cumprir o de vocês. Quero tudo pronto na segunda-feira às 08h. – Disse ele.

Este caso final mostra a falta de transparência dentro do Scrum. A Sprint perdeu sua característica de ser timeboxed e deixou de ter compromisso com sua meta. Tudo foi substituído por um compromisso com tarefas, e estas são concluídas de modo artificial. Escondem-se os problemas atrás de trabalhos "não-CLT" que obviamente são escondidos de "agentes externos".



Citados exemplos do que ocorria cotidianamente em Betelgeuse V, eu chego à pergunta chave: Como uma empresa (digo: planeta) assim consegue ter 90% de satisfação e ganhar um prêmio GPTW?

– Simples, basta destruir a transparência.

Neste caso, a diretoria incluiu a nota da pesquisa de satisfação interna como gatilho para o pagamento do Programa de Participação nos Lucros. Bonsenso e seus colegas preferiram mentir na pesquisa do que perder o décimo-quarto salário. – Afinal de contas, de que adiantaria reclamar contra o Certo Alguém que se autointitula deus e tem apoio de um diretor?

O planeta em questão criou um incentivo financeiro para que seus funcionários buscassem melhorar a satisfação interna. No entanto, recompensas não incentivam as pessoas a fazerem suas tarefas, apenas a conseguirem a recompensa. Desta forma, em vez de melhorar o clima, resolveram violar a transparência da pesquisa, dando sempre respostas que não baixassem a nota do planeta.

A falta de transparência nas avaliações fez com que o C-Level deixasse de ouvir a verdade sobre a saúde do "planeta" e seus trabalhadores, permitindo que práticas antiéticas, e até mesmo criminosas, se tornassem sistemáticas, institucionais e culturais. – Destacando-se que, aparentemente, até mesmo um diretor se envolveu na coisa toda.

Claro que, se a pesquisa de satisfação é a única forma de um gestor acompanhar seus times, já há algo muito errado. – Destaco que esta é apenas uma situação-exemplo. – Muitos outros sinais claros de falta de transparência entre gestores e geridos eram vistos, mas ninguém notava: era "problema de outra pessoa".

E assim os maiores talentos de Betelgeuse V buscavam, constantemente, empregos nos planetas vizinhos e faziam de tudo para levar consigo os seus poucos amigos que ainda estavam no planeta. O destino de Betelgeuse V não parece muito promissor.

P.s. Essa é uma obra de ficção que não tem necessariamente nenhuma relação com as empresas nas quais trabalhei ou trabalho atualmente. É apenas uma representação lúdica e exagerada do que poderia acontecer.

terça-feira, 27 de abril de 2021

Colagem de trabalhos individuais não é trabalho em equipe

No início, do ano falei aqui sobre como as Reviews sem participação de stakeholders podem ser um sintoma da falta do verdadeiro trabalho em equipe.

Comentei que, algumas vezes, os times fazem Sprint Reviews para servir apenas à própria vaidade: Os desenvolvedores apresentam o que fizeram e recebem aplausos de seus colegas. E isso não acrescenta nada ao produto nem ao processo. Disse também que esse evento demonstra que o time não está trabalhando como time, visto que, se todos participassem de tudo que foi desenvolvido, não haveria nada para se apresentar.

No final do referido artigo, prometi falar mais sobre a diferença entre uma colagem de trabalhos individuais e um trabalho em equipe. Aqui vou eu:

O que é um trabalho em equipe:

Trabalho em equipe é a integração das atividades das pessoas de forma a tornar a execução das tarefas mais simples e ágil, gerando um resultado melhor. Em outras palavras: trabalho em equipe não é simplesmente um grupo de pessoas que trabalham juntas, mas a cultura de valorizar a convivência harmônica entre as pessoas e o trabalho colaborativo.

Tá, mas o que é esse tal Trabalho Colaborativo?

Trabalho colaborativo ocorre quando duas ou mais pessoas executam juntas o mesmo trabalho. Não há o "seu trabalho" e o "meu trabalho", e sim o "nosso trabalho". Quando o trabalho é colaborativo, não é possível determinar qual parte é responsabilidade de quem. Tudo é criado pelo grupo e executado pelo grupo.

Não é por acaso que, no Scrum, os itens de backlog são do time. Em nenhum momento um desenvolvedor assume a responsabilidade por um item, e todos devem colaborar na execução das atividades que compõem cada item do backlog.

E essa tal "colagem de trabalhos individuais", o que é isso?

Quando falo sobre isso, eu nunca consigo fugir da analogia com os "trabalhos em grupo" da escola: Se eram 4 integrantes, dividíamos o trabalho em 3 partes. 3 integrantes faziam, cada um, uma parte e o 4º integrante — normalmente quem tinha a letra mais bonita — passava tudo "a limpo" no papel almaço. Depois colávamos, cada um, uma figura na cartolina e apresentávamos, cada um, a sua parte do trabalho.

Vi, várias e várias vezes, times Scrum que na parte final da Planning separam os itens, criando backlogs pessoais: "Joãozinho pega os itens X, Y e Z"; "Mariazinha faz Alfa, Beta e Gama". Então os membros trabalham em seus próprios sprint backlogs e entregam as suas tarefas. Ao final da sprint, os itens de cada desenvolvedor são colados (ou mergeados) aos dos outros e cria-se o incremento do produto. Depois todos se reúnem e cada um apresenta a sua parte.

Se você reconheceu seu time nessa descrição, não importa que ferramenta, método ou framework vocês usem, tenho uma má notícia para você: Vocês não estão trabalhando em equipe! Vocês estão trabalhando de modo individual e agrupando os resultados.

Entendi, mas qual seria o jeito correto?

O ideal é trabalhar de forma colaborativa, trabalhando realmente juntos. Se um item de backlog envolve análise, programação e teste, ao menos uma pessoa com competência de análise, ao menos uma pessoa com competência de programação e ao menos uma pessoa com competência de teste devem trabalhar juntas, nas três etapas. Programadora e testadora devem participar ativamente da análise, a analista e a testadora devem estar comprometidas com a programação e tanto a analista quanto a desenvolvedora devem atuar nos testes. Todos envolvidos em tudo. O único cuidado aqui é não deixar que o número de pessoas aumente a complexidade das tomadas de decisão. — Na minha vivência: De 3 a 5 pessoas, com diferentes especializações e experiências, é ótimo para discutir abordagens em desenvolvimento de software. E 5 desenvolvedores é uma quantidade normal para times Scrum. —

Numa equipe de alta performance — seja ela ágil ou tradicional, de desenvolvimento de software ou de futebol — não há espaço para aqueles que simplesmente fazem "a sua parte" e deixam seus colegas se virarem com as deles. É fundamental que todos saiam do trivial e ajudem seus companheiros a desempenhar melhor.

Concluindo...

Quando o time colabora em todos os itens do backlog, não há trabalho realizado por um desenvolvedor para ser compartilhado ou demonstrado aos demais. Todo o trabalho é de todas as pessoas, todas sabem o que foi feito e como foi feito. Todas deram sua contribuição.

É sabido há algum tempo que as melhores soluções não emergem da cabeça solitária de uma especialista, e sim da união de pessoas competentes, auto-organizadas em torno do objetivo comum.

Portanto, em vez de dividir o trabalho entre os desenvolvedores, una as pessoas em torno do trabalho.

terça-feira, 30 de março de 2021

Scrum vs. Kanban - Qual escolher?

No início do mês, uma amiga me questionou se eu recomendava que ela adotasse #Scrum ou #Kanban no time que ela lidera. No auge da minha síndrome de Dunning-Kruger, transformei a resposta que dei a ela num artigo.

Espero que minha loucura possa ajudar alguém. Mesmo que seja gerando um questionamento ou uma discordância, ideias diferentes são bem-vindas.

terça-feira, 19 de janeiro de 2021

Elimine a Vaidade das suas Reviews

    Há alguns dias, pensando sobre como poderia ajudar um time Scrum, me deparei com uma situação: Eles faziam Sprint Reviews puramente vaidosas. E a busca pela causa-raiz dessa distorção do evento me levou ao maior problema daquele time, que era a falta de trabalho em equipe.

   — Review Vaidosa? De onde você tirou isso?

   Vamos primeiro entender o contexto, para depois avançar sobre as conclusões. Conversando com os membros do time, descobri que o Scrum Master era um desenvolvedor sênior que foi empossado no cargo sem jamais ter visto um Scrum rodando nem sequer ter lido o Scrum Guide. — Diga-se de passagem, foi exatamente isso que eu fiz comigo mesmo há uns 10 anos — Ele leu artigos na internet e começou a fazer conforme foi capaz de entender. Preciso destacar que ele, considerando o contexto, estava fazendo um bom trabalho.

   A partir disto eu pedi que as pessoas detalhassem como aconteciam os eventos... Terminada a reunião, comecei a meditar sobre o que havia escutado para definir quais seriam as entradas das próximas sessões.

   Eis que surge o problema...

   Durante a sessão, o time revelou que fazia regularmente Sprint Reviews, mas delas somente participavam os membros do próprio time. Eu perguntei qual era o objetivo dessa reunião e eles responderam que eram dois:

  1. Revisar o que foi desenvolvido para identificar os ajustes que precisam ser feitos antes de enviar ao cliente.
  2. Apresentar aos outros membros do time o que cada um fez.
   O fato de eles identificarem ajustes a serem feitos na Review demonstra que a Definição de Pronto deles estava mal definida, mas o meu foco aqui é o segundo motivo. Por que eles viam utilidade em apresentar para os outros o que cada um fez?

   A resposta é óbvia: Porque eles não trabalhavam em equipe! Se todos estivessem envolvidos em todas as tarefas, não haveria nada a ser apresentado; todos saberiam o que os outros fizeram. Ou melhor: todos teriam feito tudo juntos. E aí me veio o insight que dá título a este artigo.

   O time usava as Reviews para admirar o próprio trabalho e trocar aplausos com os colegas, ou seja, para um momento vaidoso. Esse momento de vã exibição acontece principalmente porque cada desenvolvedor faz o seu próprio trabalho e, no final da Sprint, esses trabalhos são ajuntados num mesmo produto. O principal problema disso é que a colagem de vários trabalhos individuais não é, nem nunca será, um trabalho em equipe. 

   Falarei mais sobre a diferença entre o "trabalho em equipe" e a "coleção de trabalhos individuais" numa próxima publicação; e farei o mesmo sobre "celebração" e "exibição vaidosa". Por enquanto, deixo o alerta:

Reviews Vaidosas são sintoma de falta de trabalho em equipe!

sexta-feira, 18 de dezembro de 2020

Como se tornar um verdadeiro líder?

 Nesse artigo eu não vou falar nada. Vou apenas abrir o espaço para você assistir essa verdadeira pérola entregue por Simon Sinek:



Depois disso eu vou falar o que?

quarta-feira, 18 de novembro de 2020

Desmistificando o papel do Scrum Master - Parte I

Na minha primeira postagem sobre Scrum, entitulada "Scrum Master - você está fazendo isso errado", citei alguns desvios de função comuns entre os SMs. Neste artigo vou falar sobre os dois primeiros:

  • Se o Scrum Master é responsável por emitir relatórios de status para gestores a partir das informações da Daily Scrum: Você está fazendo isso errado!
  • Se o Scrum Master é responsável por criar Gráficos, atualizar as Stories ou escrever Planos de Ação: Você está fazendo isso errado!
  • O problema nestas situações reside no fato de Scrum Master não responder pelo time e nem ser o secretário da equipe. O SM deve estar focado em fazer o Scrum acontecer.
    Vamos analisar mais detalhadamente os pontos:

    • Emissão de Status Report a partir da Daily: Essa é a melhor forma de destruir as suas reuniões diárias. As Dailies existem para o time se organizar, portanto pertencem ao time, somente ao time, ninguém mais que o time.
      Ao saber que estão sendo controlados, ou medidos, pelo que falam na Daily, os membros do time passarão a se preocupar mais com o "status" do que com a organização para completar a Sprint. Problemas serão omitidos, impedimentos serão diminuídos e tudo estará sempre sob controle até que a bomba estoure na mão de alguém. Scrum é um processo empírico e empirismo se mede por aprendizado, não por tarefa realizada.
      Um dos pilares do Scrum é a transparência, portanto, qualquer parte interessada tem acesso às informações da Sprint. É por isso se usa o conceito da "gestão à vista". Cabe ao SM, neste caso, garantir que as partes interessadas tenham uma maneira de se informar sobre a Sprint. Em geral, um simples Burndown Chart na parede resolve essa necessidade de Status Report pelas partes interessadas. Mas, repito: O Scrum é um processo empírico e empirismo se mede por aprendizado, não por tarefa realizada.
    • Criação de Gráficos: Naturalmente o Scrum Master pode, e deve, criar gráficos para apoiar a gestão do time. Contudo, isso é uma atividade de apoio, não uma responsabilidade primária.
      O ideal seria os gráficos serem gerados por uma ferramenta automatizada para serem analisados e não se tornarem mais uma obrigação do Scrum Master. Na falta de ferramentas automatizadas, qualquer um pode assumir esse papel, preferencialmente quem tiver mais habilidade para isso — até mesmo o SM.
    • Atualização de Stories: Essa eu não vou me alongar — Quem atualiza a story é quem está trabalhando nela! — Por incrível que pareça, já vi um caso em que o time fazia o refinamento dos itens de backlog e passava por e-mail para o SM para que ele atualizasse as stories. E eu prefiro não comentar sobre isso.
    • Planos de Ação: Não sei se eu já disse, mas os times ágeis são auto-organizados. "Planos de Ação" são montados pelo próprio time e a responsabilidade por executá-los também é igualmente repartida entre todas as pessoas. Espera-se que os planos emerjam das Retrospectivas, onde o time discute e decide como melhorar.
      Claro que o Scrum Master pode agrupar as ideias e escrever um documento com o plano de ação estabelecido pelo time, mas isso não pode ser visto como uma responsabilidade dele. Qualquer pessoa do time pode ser a responsável por resumir a discussão num documento. Ou, o que acho melhor, pode simplesmente não ser feito nenhum documento. — Por que não, simplesmente, criar tickets e colocá-los num kanban de tarefas?

    Acredito que as organizações (entenda-se: as pessoas que compõem as organizações) ainda têm o pensamento cartesiano, linear, hierárquico. Por isso esperam que o Scrum Master assuma o papel de "chefe", uma vez que ele é o líder, e responda pelo time junto à alta gestão. Da mesma forma, o time espera que o Scrum Master cuide das "burocracias", livrando-os da necessidade de executar qualquer tarefa que não seja diretamente o desenvolvimento do projeto/produto. Por isso empurram para o SM atividades como preenchimento de planilhas de controle, de "atas" de reunião, lançamento de dados em sistemas etc.

    Ser a interface entre o time e os stakeholders significa que o Scrum Master pode representar o time nas reuniões com a Diretoria, para evitar que o desenvolvimento do projeto/produto pare por causa da reunião. E isso não dá ao SM o poder de tomar quaisquer decisões pelo time nem aos Diretores o direito de cobrar ao SM pelo que o time fez ou deixou de fazer. Nesta situação, o papel do SM se assemelha mais ao de um porta-voz do que ao de um gerente.

    Ser o facilitador significa que o Scrum Master deve ajudar o time a entender seus objetivos, se autoconhecer e se auto-organizar. E isso inclui a condução de eventos e dinâmicas, a mediação de discussões e debates e a condensação das ideias em acordos ou planejamentos. Em nenhum momento isso obriga o SM a ser o "anotador oficial" do time. Nesta situação, o papel do SM é o de mediador, não o de secretário.

    Como você já deve ter visto várias vezes: Scrum Master não é Chefe, Scrum Master não é Gerente, Scrum Master não é Secretário e — essa é nova! — Scrum Master não é Burocrata.

    terça-feira, 27 de outubro de 2020

    A fábula do bacon com ovos

     

       Conheço poucas coisas que gerem tantos mal-entendidos sobre agilidade quanto essa famosa fábula. A ideia de intensificar o significado do comprometimento é ótima, mas a visão passada não apenas não corresponde à realidade como ainda contraria alguns princípios dos times ágeis.

       Para quem não conhece, ou não se lembra, a fábula do bacon com ovos (em uma de suas várias versões) narra a história da criação de um restaurante que teria como prato principal: Bacon com Ovos. Os proprietários seriam um porco e uma galinha.

       O porco acaba entendendo que a parceria não daria certo porque ele estaria comprometido (dando a própria vida para produzir o bacon) enquanto a galinha estaria apenas envolvida (simplesmente pondo ovos).

       O grande problema gerado por essa fábula é que muitas pessoas levam o comprometimento do porco ao pé-da-letra e acham que trabalhar num time ágil significa dedicar toda a sua vida ao time.

       Na prática, se o porco desse a própria vida para produzir o bacon, o restaurante fecharia, visto que perdeu seu fundador e fornecedor de matéria-prima no primeiro dia de funcionamento.

       A cada dia a galinha precisaria encontrar um novo sócio disposto a morrer por um negócio do qual não tiraria nenhum proveito. O porco nem sequer saberia se os clientes gostaram do prato servido, nem receberia nenhum lucro; estaria morto antes da entrega.

       Quando falamos em times ágeis, pensamos em times preocupados com a satisfação contínua do cliente ao longo das iterações e isso requer que os membros estejam vivos.

       As práticas de gestão de pessoas aplicadas a times ágeis partem da valorização e do respeito às pessoas. Pedir que alguém se sacrifique por uma entrega, definitivamente, não é uma forma de valorizar nem de demonstrar respeito.

       O comprometimento de uma pessoa com o time inclui o comprometimento com sua própria integridade física e mental.

       Outra versão desta fábula narra que um fazendeiro determinou a seus animais, uma galinha e um porco, que preparassem, a cada dia, um saboroso e diferenciado café da manhã. Caso falhassem, o café seria Bacon com Ovos.

       O porco se empenha e se esforça ao máximo para providenciar o café da manhã que seu proprietário pediu, enquanto a galinha faz “corpo mole” e apenas observa o porco trabalhar.

       No final da fábula, o porco não consegue entregar uma refeição satisfatória e o fazendeiro ordena que seus empregados matem o porco para fazer bacon e peguem os ovos da galinha.

       Isso também não retrata nenhuma realidade de times ágeis, nem de times tradicionais. Retrata apenas o ciclo de vida da má gestão, que termina com a punição dos inocentes e a promoção dos não envolvidos.

       E eu vejo “agilistas” perguntando a seus times se são porcos ou galinhas; se estão comprometidos ou envolvidos... sem se dar conta de que esta ideia de dar a vida pelo projeto/produto é altamente tóxica e prejudicial. Sem perceber que este “comprometimento” viola os princípios da boa gestão de pessoas.

       Não estimule seu Dev Team a morrer, estimule-o a permanecer vivo e saudável. Pessoas doentes e exaustas não entregam valor, pessoas saudáveis e felizes produzem mais e melhor.

    segunda-feira, 19 de outubro de 2020

    Você desenvolve Projetos ou Produtos?

       Lendo o artigo Why Agile Transformation sometimes fail da Magdalena Firlit, especialmente no tópico Project-oriented organization (instead of a product), lembrei de uma situação ocorrida comigo há alguns anos.

       Eu gerenciava um projeto de desenvolvimento de um software para apoio ao Centro de Controle Operacional de um cliente. O CCO era uma sala onde ficavam dezenas de operadores e dezenas de computadores, monitores de vídeo, TVs e painéis, de onde eram comandadas operações da empresa.

       Naquele projeto nós não utilizávamos MVPs, mas a sua versão "raiz", conhecida como PoC (Prova de Conceito — sigla em inglês). E, ao final de cada PoC, realizávamos uma reunião de avaliação e definição da próxima fase. Eis que, numa destas reuniões, um analista percebe que mais de 80% do trabalho realizado pelas dezenas de operadores era mecânico e automatizável por software.

       Imediatamente chamei o Diretor para a reunião e o analista lhe deu a notícia:

    _ Conseguimos uma solução que vai acabar com o CCO do cliente!

       O Diretor ficou vermelho...

    _ Ele pode ficar só com 20% daquela estrutura toda. Aquilo é tudo desperdício de dinheiro! 80% do trabalho deles o nosso sistema vai fazer. Se ele quiser, nem precisa mais ter um CCO.

       O Diretor respirou fundo e, após se recuperar da taquicardia, respondeu:

    _ Se é isso que você pensa, e ninguém aqui se manifestou contra, vamos encerrar esse projeto agora mesmo, porque vocês estão jogando meu dinheiro fora. Esse projeto tem um objetivo só: implantar o CCO do cliente do jeito que ele imaginou. E eu não vejo ninguém aqui defendendo isso, que é o mais importante.

       O Diretor enxergou aquele insight como uma ofensa aos objetivos do projeto, sem perceber que aquilo seria o grande diferencial do produto. Será que o cliente não gostaria de saber que poderia reduzir a estrutura planejada em 80% e obter o mesmo resultado? Nunca saberemos a resposta.

       Desta forma, a limitação de escopo do projeto matou o empirismo, a criação, a disrupção, a inovação, o time e o próprio projeto. Sei que 4 dos 7 membros da equipe original do projeto (incluindo eu e aquele analista) saíram da empresa nos meses seguintes e, pelo que ouvi falar, o projeto foi cancelado.

    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.

    sexta-feira, 12 de junho de 2020

    Scrum Master - você está fazendo isso errado

    Scrum Master

    Você está fazendo isso errado!

       Este artigo não tem como objetivo oferecer soluções para todos os problemas que ocorrem todas as organizações que experimentam a sua "Transformação Ágil". Nem mesmo o de oferecer soluções para as situações exemplificadas. Pretendo apenas sugerir sintomas de que algo está errado e propor uma reflexão.

       Estes sinais são uma compilação de situações que vivenciei ou vi acontecer em empresas que tentavam implementar "metodologias ágeis" ao longo dos meus vinte e alguns anos na área de desenvolvimento de software. Diga-se de passagem, o simples uso da expressão "metodologias ágeis" já me dá calafrios, visto que as praticas ágeis podem ser aplicadas a virtualmente qualquer metodologia. Ressalto: Scrum é um Framework!

       Ao longo das próximas semanas postarei mais sobre os sinais abaixo, como estes sugerem distorções da "Agilidade" e como a causa raiz destas distorções pode ser identificada e corrigida.

    Sinais de que alguma coisa está errada:

    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, ...