Mostrando postagens com marcador Transformação Ágil. Mostrar todas as postagens
Mostrando postagens com marcador Transformação Ágil. 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.

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.

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?

segunda-feira, 14 de dezembro de 2020

A Fábula dos Porcos Assados

Este texto me foi apresentado numa aula de Organização Empresarial, quando cursava o Ensino Médio, em 1998. Agora, que estamos literalmente em outro milênio, por acaso o encontrei no arquivo do site passeidireto.com e fiquei impressionado com o quanto isso ainda faz sentido.

Quando falamos de Agile, Lean etc. ainda é assim que muitos pensam. Há algumas semanas contei aqui uma situação pela qual passei, que mostra bem como essa fábula continua atual.

Vamos a estória:

Certa vez, aconteceu um incêndio num bosque onde se encontravam alguns porcos. Estes foram assados pelo incêndio. Os homens, acostumados a comer carne crua, experimentaram os porcos assados e acharam deliciosos. Logo, toda vez que queriam comer carne assada incendiavam o bosque...

O sistema foi desenvolvido e aperfeiçoado. Mas nem sempre as coisas iam bem: às vezes os animais ficavam queimados ou parcialmente crus; outras, de tal maneira queimados que era impossível utilizá-los. Como era um procedimento montado em grande escala, isso preocupava muito a todos, porque, se o Sistema falhava, as perdas ocasionadas eram igualmente grandes. Milhões de pessoas alimentavam-se só de carne assada e também muitos eram os que tinham ocupação nessa tarefa. Portanto, o Sistema simplesmente não devia falhar. Mas, curiosamente, à medida que se fazia em maiores escalas, mais parecia falhar e maiores perdas parecia causar.

Em razão das deficiências, aumentavam as queixas. Já era um clamor geral a necessidade de se reformar profundamente o Sistema. Tanto assim que, todos os anos, realizavam-se congressos, seminários, conferências e jornadas para achar a solução. Mas parece que não acertavam o melhoramento do mecanismo, porque no ano seguinte repetiam-se os congressos, os seminários, as conferências e as jornadas. E assim sempre.

A causa do fracasso do Sistema, segundo os especialistas, podiam ser atribuídas ou à indisciplina dos porcos, que não permaneciam onde deviam, ou à inconstante natureza do fogo, difícil de controlar, ou às árvores excessivamente verdes, ou à umidade da terra, ou ao serviço de informações meteorológicas que não acertava o lugar, o momento e a quantidade de chuva, ou...

Como se vê, as causas eram difíceis de determinar, porque na verdade, o Sistema para assar os porcos era muito complexo. Fora montado uma grande estrutura; uma enorme maquinaria com inúmeras variáveis tinha sido institucionalizada. Havia indivíduos dedicados a acender – os incendiadores – que, ao mesmo tempo, eram especialistas de setores. Havia incendiadores da Zona Norte, da Zona Oeste, etc., incendiadores noturnos, diurnos, com especialização matutina e vespertina, incendiadores de verão, inverno, com disputas jurídicas sobre o outono e a primavera.

Havia especialista em vento, os anemotécnicos, um Diretor Geral de Assamento e Alimentação Assada, um Diretor de Técnicas Ígneas (com seu conselho geral de assessores), um Administrador Geral de Florestação Incendiável, uma Comissão Nacional de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias (ISCUTA) e o BODRIO (Bureau Orientador de Reformas Ígneo-Operativas).

O BODRIO era tão grande, que tinha um inspetor de reformas para cada 7.000 porcos, aproximadamente. E era precisamente o BODRIO que propiciava anualmente os congressos, os seminários, as conferências e as jornadas. Mas isto só parecia servir para incrementar o BODRIO em burocracia. Tinha se projetado e encontrava-se em pleno crescimento a formação de novos bosques e selvas, seguindo as últimas indicações técnicas, em regiões escolhidas segundo determinada orientação, onde os ventos não soprassem mais de 3 horas seguidas e houvesse reduzida porcentagem de umidade. Havia milhões de pessoas trabalhando na preparação dos bosques a serem incendiados. Alguns especialistas eram enviados para a Europa e os EUA, com a missão de estudar a importação das melhores madeiras, árvores, sementes, fogos melhores e mais potentes, além de pesquisar ideias operativas, por exemplo, como fazer buracos para que neles caíssem os porcos.

Havia também grandes instalações para manter os porcos antes do incêndio, mecanismos para deixá-los sair no momento oportuno, técnicos em sua alimentação, etc. Havia construções de estábulos para porcos, professores formadores de especialistas na construção de estábulos para porcos, universidades que preparavam os professores formadores dos especialistas na construção dos estábulos para porcos, fundações que apoiavam os investigadores que davam o fruto do seu trabalho às universidades que preparavam os professores formadores na construção de estábulo para porcos, etc.

As soluções que os congressos sugeriam eram, por exemplo, aplicar triangularmente o fogo após Va -1 pela velocidade do vento sul, soltar os porcos 15 minutos antes que o fogo-promédio da floresta alcançasse 47°; outros diziam que era necessário instalar grandes ventiladores que serviriam para orientar a direção do fogo e assim por diante. Poucos especialistas estavam de acordo entre si e cada um tinha investigações e dados para provar suas afirmações.

Um dia, um investigador da categoria SO/DM/VCH , chamado João Bonsenso falou que o problema era muito fácil de se resolver. Tudo consistia, segundo ele, primeiramente, em matar o porco escolhido, limpando e cortando adequadamente o animal e colocando-o, posteriormente, numa jaula metálica ou armação sobre brasas, até que o efeito do calor e não das chamas, o assasse ao ponto.

Ciente, o Diretor Geral de Assamento mandou chamá-lo e perguntou que coisa esquisita ele andava falando por ali. Depois de ouvi-lo, disse-lhe:

- O que o senhor fala está bem, somente na teoria. Não vai dar certo na prática. Pior ainda, é impraticável. Vamos ver: o que o senhor faria com os anemotécnicos, no caso de se adotar o que está sugerindo?

- Não sei, respondeu João.

- Onde vai por os acendedores das diversas especialidades?

- Não sei.

- E os indivíduos que foram ao estrangeiro para se especializar durante anos e cuja formação custou tanto ao país? Vou pô-los para limpar porquinhos?

- Não sei.

- E os que têm se especializado todos esses anos em participar dos congressos, seminários e jornadas para a Reforma e Melhoramentos do Sistema? Se o que você fala resolve tudo, que faço com eles?

- Não sei.

- O senhor percebe agora que a sua solução não é aquela de que todos nós necessitamos? O senhor acredita que, se tudo fosse tão simples, os nossos especialistas não teriam achado a solução antes? Veja só! Que autores falam isso? Que autoridade há para avaliar sua sugestão? O senhor, por certo, imagina que eu posso dizer aos engenheiros em anemotécnica que é questão de por brasinhas sem chamas! O que eu faço com os bosques já preparados, no ponto de serem queimados, que somente possuem madeira apta para fogo-em-conjunto, cujas árvores não produzem frutos, cuja falta de folhas faz com que não prestem para dar sombras? O que faço? Diga-me !!!

- Não sei.

- O que faço com a Comissão Redatora de Programas Assados, com seus Departamentos de Classificação e Seleção de Porcos, com a Arquitetura Funcional de Estábulos, estatística, população, etc. ?

- Não sei.

- Diga-me: o Engenheiro em Porcopirotecnia, o Sr. J.C da Figuração, não é uma extraordinária personalidade científica?

- Sim, parece que sim.

- Bem, o simples fato de possuir valiosos e extraordinários engenheiros em Porcopirotecnia indica que o Sistema é bom. E que faço com indivíduos tão valiosos?

- Não sei.

- Viu? O senhor tem é que trazer solução para certos problemas: como fazer melhores anemotécnicos , como conseguir mais rápido acendedores do Oeste (que é a nossa maior dificuldade), como fazer estábulos de oito andares ou mais, em lugar de somente sete, como até agora. Tem que melhorar o que temos e não mudá-lo. Traga-me uma proposta para que nossos bolsistas na Europa custem menos, ou mostre-me como fazer uma boa revista para análise profunda do problema da Reforma do Assamento. É disso que necessitamos. É disso que o país necessita. Ao senhor falta sensatez, senso – comum ! Diga-me, por exemplo, o que faço com meu bom amigo (e parente), o Presidente da Comissão para o Estudo de Aproveitamento Integral dos Resíduos dos Ex-Bosques?

- Realmente, estou perplexo! - falou João.

- Bem, agora que conhece bem o problema, não diga por aí que o senhor conserta tudo. Agora, o senhor vê que o problema é mais sério e não tão simples como o senhor imaginava. Tanto os de baixo como os de fora dizem: “Eu conserto tudo”. Mas tem que estar dentro para conhecer os problemas e saber das dificuldades. Agora, cá entre nós, recomendo-lhe que não insista com sua ideia, porque isso poderia trazer problemas para o senhor no seu cargo. Não por mim! Eu falo pelo seu próprio bem, porque eu o compreendo, entendo seu posicionamento, mas o senhor sabe que pode encontrar outro superior menos compreensivo. O senhor sabe como são, às vezes, não é?

João Bonsenso, coitado, não falou um “A”. Sem despedir-se, meio assustado e meio atordoado com a sensação de estar caminhando de cabeça para baixo, saiu e nunca mais ninguém o viu. Não se sabe para onde foi. Por isso é que, até hoje é costume dizer que, na tarefa de reforma e melhoria do Sistema, falta o bom senso.


Artigo originalmente publicado em:

Juicio de la Escuela,

CIRIGLIANO, F. T.. Editorial

Humanitas, Buenos Aires,

1976.

terça-feira, 1 de dezembro de 2020

Automóveis, Explosões e Decisões

No último domingo, durante a transmissão do Formula 1 Gulf Air Bahrain Grand Prix 2020, esta foi a imagem mais alegre e consoladora que tivemos: Um piloto pulando o muro de proteção após escapar de um carro em chamas. 



— Ok, mas o que isso tem a ver com agilidade? 

Nada, e tudo também. Participando do treinamento High Impact Agile, ministrado pelo grande mestre Gino Terentim, fui introduzido ao Cynefin Framework e nesse acidente pude ver todo o framework em ação.

Para quem não conhece nada de Cynefin (e eu conheço apenas um pouquinho), vou explicar os fundamentos do framework antes de mostrar como o relacionei a uma corrida de automóveis.



O Cynefin é uma ferramenta para tomada de decisões que distribui os problemas em três tipos de sistemas: Ordenado, Complexo e Caótico.

  1. Ordenado - Onde é possível estabelecer relações do tipo causa-efeito e ter alguma previsibilidade. Os sistemas ordenados se subdividem em dois.
    1. Claro - É a situação em que "todo mundo" sabe a resposta. Já existe uma Melhor Prática, Protocolo ou Checklist para a solução do problema. Por exemplo: Trocar uma lâmpada.
    2. Complicado - É uma situação em que a resposta não é óbvia, mas um especialista saberá o que fazer. Após a análise, o especialista adotará as boas práticas que melhor se adequam àquele caso. Por exemplo: Um diagnóstico médico (os procedimentos já estão definidos e documentados mas o somente um especialista pode decidir quando e como aplicá-los).
  2. Complexo - Neste mundo não há definições claras sobre causa e efeito e o ambiente é o chamado VUCA. Neste ambiente as práticas e métodos ágeis produzem resultados incríveis. Um exemplo de situação complexa é o desenvolvimento de uma nova Vacina.
  3. Caótico - O nome já diz tudo, aqui não há nenhuma ordem, clareza ou metodologia. O objetivo primário é sobreviver até que o caos se dissolva. Vale destacar que o Caos é também o maior gerador de inovações, mas isso já está além do escopo deste artigo.
Há ainda as áreas limítrofes e o domínio da Confusão, sobre as quais não falarei neste post.

Para cada domínio, o Cynefin prega maneiras diferentes de se tomar decisões e agir. E é este o gancho que vou usar para puxar o acidente sofrido pelo piloto Romain Grosjean para dentro do Cynefin e mostrar a minha visão disso tudo.

A corrida começou agitada, com alguns pequenos toques e esbarrões entre os carros até que, ainda na primeira volta, um dos competidores cruzou a pista de forma desgovernada e atingiu uma parede de aço a mais de 220km/h. O que se viu em seguida foi uma explosão: O Caos.




O piloto do carro médico e o médico responsável, que chegaram ao local poucos segundos após a colisão, relataram que nunca tinham visto uma situação como aquela. Eles precisaram de um ou dois segundos para perceber o que estava acontecendo (a Confusão). Viram metade de um carro virada em sentido contrário ao percurso e uma bola de fogo à direita. Ficou claro que o piloto estava dentro do fogo.

Neste momento eles estavam num sistema caótico. Não há treinamento, técnica ou protocolo que se aplique a um veículo partido ao meio, envolto em chamas, com o piloto preso dentro dele. O  Dr. Ian Roberts relatou que, como médico, ele precisava salvar a vida do piloto; por isso pegou um extintor de incêndio e disparou em direção às chamas procurando algum sinal. — O que diz o Cynefin sobre situações caóticas? Aja - Entenda - Responda. — E foi isso que eles fizeram: agiram com o extintor, entenderam onde estava o piloto e responderam iniciando a tentativa de tirá-lo das chamas.


Aqui o caos se desfaz momentaneamente e temos uma situação complexa. O carro continua em chamas... Quanto combustível ainda há para queimar? Pode haver outra explosão? O piloto está com o macacão queimado e a viseira do capacete derretida... Qual o estado de saúde dele? Ele consegue andar até o carro médico? E o estado mental de quem acabou de passar 29 segundos dentro de uma bola de fogo? — O que diz o Cynefin sobre resposta a problemas complexos? Sonde - Entenda - Responda — O que eles fizeram? Apoiaram o piloto e tentaram levá-lo até o carro médico. Tentaram remover o capacete e as luvas queimadas. O restante da equipe de pista foi tentar apagar o incêndio. Eles experimentaram pequenas soluções. Neste ponto, já era possível dar pequenos passos e observar se o risco aumentava ou diminuía. Um erro ao tirar as luvas poderia agravar uma possível lesão nas mãos, mas não colocaria a vida do piloto em risco. O próprio médico responsável admitiu depois que deveria ter sido mais sutil quando ajudou o piloto a pular o muro mas, naquele momento (ainda na borda do caos), ele só queria afastá-lo do fogo o mais rápido possível.




Está dando certo levar o piloto até o carro e remover parte do equipamento? Sim. As chamas estão sendo controladas? Sim. Se a sondagem sobre os resultados dos experimentos foi positiva, a resposta é continuar neste caminho. Uma vez que o piloto chegou a um "lugar seguro" e a equipe de crise entendeu o incêndio, a complexidade se encerra e temos um problema complicado.

Na complicação, o framework sugere que nós chamemos especialistas para que eles Entendam - Analisem - Respondam. Como isso se deu? O médico examinou rapidamente o piloto, conferiu seus sinais vitais, fez testes para identificar possíveis ferimentos e fraturas. Analisou os resultados do exame e Respondeu adotando o protocolo de remoção para situações em que não há risco de morte.

Enquanto isso, os especialistas em incêndios e na estrutura de segurança da pista escolhiam e adotavam os protocolos para combate ao fogo e, posteriormente, liberação da pista.

Falar em protocolos nos leva à clareza, onde existem melhores práticas definidas. A atitude é Entender - Categorizar - Responder. A equipe médica continuou avaliando o piloto, categorizou os ferimentos e sintomas identificados e respondeu noticiando a inexistência de lesões graves e levando-o ao hospital de referência para tratamento. Para eles era óbvio o que deveria ser feito.

Assim, demos uma volta completa no quadro do Cynefin, do Caos à Clareza, passando por segundos de confusão, num evento que durou apenas alguns minutos. Vimos que os profissionais altamente capacitados envolvidos tomaram as decisões de acordo com o que diz o framework. Talvez estes nunca tenham ouvido falar em Cynefin e, neste caso, a "coincidência" seria uma demonstração de que a ferramenta orienta corretamente a tomada decisões.

Antes de terminar, ainda destaco mais um ponto: O Cynefin aponta que existe um atalho para caos, conhecido como Abismo da Complacência. Caímos nele quando tratamos como Claro algo que não é tão protocolar assim, quando abrimos uma porta para a negligência, a imprudência ou a imperícia. — E isso tem a ver com o acidente da F1? Tem sim!

O guard rail colocado naquele ponto do circuito deveria ter amortecido o impacto do carro e o devolvido à área de escape. Mas o que aconteceu foi que o carro literalmente furou a proteção. Metade do carro atravessou o muro e somente a segunda metade foi rebatida como esperado. Ainda é cedo para falar sobre isso e os especialistas analisarão exaustivamente o acidente para encontrar as causas, falhas e possíveis melhorias. Eu, que sou leigo e sofro do efeito Dunning-Kruger, penso que existem soluções relativamente simples para evitar que isso ocorra. Por exemplo a colocação de uma barreira de pneus na frente dos guard rails, para que a borracha amorteça o impacto. E por que não havia uma proteção de pneus ali? Porque ninguém imaginava que um carro pudesse atingir aquele ponto do muro num ângulo de quase 90º.

 
Imagem retirada do vídeo ao final do post.



As curvas são mais protegidas, mas nas retas os acidentes com carros saindo perpendicularmente à pista são raríssimos. Apesar de todos os protocolos de segurança, a organização da prova pode ter sido complacente, acreditando que naquele ponto não havia necessidade de dispositivos de segurança adicionais aos guard rails. E a complacência é um atalho para o caos.

Qual lição tiramos disso para nossos times de desenvolvimento? Não trate situações complexas como óbvias (e vice-versa) e planeje as suas respostas conforme o sistema no qual o problema está inserido.

Não estou ganhando nada mas, para fins educativos, faço a propaganda: Quem quiser conhecer mais sobre o Cynefin pode procurar um treinamento (eu recomendo os da Hiflex e do Gino Terentim) ou comprar o livro Cynefin - Weaving Sense-Making into the Fabric of Our World. (Hoje está sendo vendido a R$24,00, em formato digital, na Amazon).




Todas as imagens do acidente utilizadas neste post estão linkadas diretamentes a publicações em redes sociais e plataformas de streaming. Os direitos autorais estão preservados na sua fonte. A imagem ilustrativa do framework Cynefin foi retirada do material oficial do treinamento High Impact Agile.

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?

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