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.


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.

sexta-feira, 9 de julho de 2021

Sobre facilitações e diversões

    Recentemente, participando de um workshop sobre "melhores reuniões", surgiu uma interessante discussão. O material oficial do workshop e, claro, a pessoa facilitadora mostraram as vantagens de utilizar dinâmicas quebra-gelo no início das reuniões para melhorar o clima e trazer um pouco de diversão.

   Em determinado momento, foi proposta uma dinâmica em pequenos grupos para que discutíssemos formas de tornar nossas reuniões mais divertidas. E aí surgiu a reflexão que me leva a escrever esta publicação: "Eu não quero que a reunião seja divertida, quero que ela termine logo para eu ir pra casa me divertir com outra coisa." — Disse uma participante. Imediatamente eu pensei: "Temos um 'alto D' no grupo"

   Mais tarde, — bem mais tarde — quando meu filho me acordou às 4 da manhã dizendo que um rinoceronte não queria deixá-lo dormir, eu lembrei desta situação e percebi o quanto havia sido idiota por pensar em perfis comportamentais DISC em vez de pensar de modo sistêmico. — Será que aquela pessoa não queria reuniões divertidas ou o sistema no qual ela está inserida não é amigável a tais coisas?

   Me recordei de uma situação exemplo levantada por ela num outro momento, quando falou sobre uma reunião para decidir se uma determinada ação proposta por um engenheiro poderia ser realizada ou se  violaria a legislação. — Estamos falando de Engenheiros e Juristas!

   Aí eu te pergunto: Numa reunião entre juristas para decidir sobre a legalidade de uma proposta feita por engenheiros, você espera que sejam realizadas dinâmicas de quebra-gelo e diversão? — Claro que não! O sistema não permite. — E não é preconceito nem "coisa de velho". Este tipo de reunião não é compatível com aquele tipo de prática, e explicarei o motivo de eu acreditar nisso.

   Dinâmicas e jogos de grupo, como os citados anteriormente, tem por objetivo fortalecer a rede de conexões, melhorar o fluxo das comunicações pelos diversos canais e estimular a criatividade dos integrantes do grupo. Todas essas coisas são fundamentais para atividades criativas e indutoras de inovação. São excelentes quando você busca práticas emergentes, novas soluções, ideias fora da caixa... soluções para problemas complexos.

   Discussões acerca da legalidade de algo são o oposto disso. Você não quer que seus advogados deem uma nova interpretação ao texto da lei. Nem que eles criem uma nova forma de enquadrar práticas na legislação. — Exceto casos bem específicos — O que se espera dessa situação é que os especialistas decidam, dentre as boas práticas, qual melhor se adequa ao seu caso. Você não quer novidades, você quer segurança. Seu problema não é complexo, é complicado.

   Aqueles que conhecem o Cynefin framework já são capazes de perceber a incompatibilidade pelas palavras que destaquei. O problema (a reunião) está no domínio do complicado, enquanto a solução (as dinâmicas) no domínio do complexo. Quando o binômio problema x solução está em domínios diferentes, temos um enorme sinal de alerta: Até pode dar certo, mas se der errado o efeito será catastrófico. — Neste caso, uma falha põe em risco a continuidade de empregos, carreiras e até mesmo da organização. — Este não é um ambiente seguro para experimentação.

   E não podemos esquecer da possibilidade de os participantes da reunião acharem que você está louco por propor diversão numa hora dessas. — Não que engenheiras e juristas não possam se divertir em equipe. Elas (as pessoas) não apenas podem, como devem ter momentos de alegria e descontração. Mas há situações propícias a isso e situações onde é melhor "manter o decoro". Todas essas dinâmicas e integrações devem ser feitas no momento adequado.

   Não há dúvidas de que as práticas disseminadas no workshop são ótimas, mas não para toda e qualquer reunião.

   Enfim, antes de aplicarmos as "melhores práticas" que "todo mundo" usa, precisamos verificar se estamos no mesmo contexto que "todo mundo". Quando falamos de Management 3.0, Agilidade e tudo mais, estamos falando de soluções para problemas complexos; não para complicados, nem para problemas claros. Quase ninguém faz, ou não deveria fazer, Design Thinking para trocar lâmpada — mas deveria fazer para inventar um novo tipo de lâmpada. — Quase ninguém quer se submeter a uma cirurgia inovadora e experimental quando há um procedimento simples e padronizado para o seu problema de saúde — mas talvez queira num caso de doença sem cura conhecida. 

   Resumindo: A prática deve ser adotada conforme o contexto.

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.


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.

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