Considerações a respeito do post “12 COISAS A MELHORAR NO SCRUM (sem tirar Sprints)”

Olá pessoas,

Precisou um Kanban Boy fazer um post inusitado na rede social dos “Heads da porra toda”, pra eu voltar a ocupar este espaço, que num passado não muito distante fui um frequentador mais assíduo. Sem brincadeira, quando me loguei no blog, duas aranhas (uma fumando cigarro e outra de Rayban) gritaram em uníssono: “porra, c tá vivo seu demônio?”

Pois é gente, sem mais delongas…

Um novo posicionamento, numa aposta digamos menos hostil, da Kanban University “em direção ao Scrum” foi um dos assuntos mais comentados no Kanban Global Summit 2022 — segundo os próprios Kanban Boys que lá estiveram. Este novo direcionamento, porém, vem a pretexto de uma pseudo, generosa e “gratuita” ajuda vinda da comunidade do Kanban que, num ato nobre (pra não dizer heróico), resolveu auxiliar a comunidade ágil e o Scrum a se livrar do engessamento prescritivo promovido, desde sempre, pelo sadismo irracional de seus criadores. Sim, senhoras e senhores, o método Kanban com seus cerca de 7% de market share global, se propôs, por intermédio de sua combativa e engajada comunidade, estender a mão aos praticantes do framework ágil mais utilizado no mundo.

Este novo posicionamento da KU provocou, quase que instantaneamente, uma ligeira inflexão no discurso dos Kanban Boys mais ativos, que não perderam tempo e iniciaram o abrandamento as críticas ao Scrum, numa espécie de cessar fogo seguido por um “levantar de bandeiras brancas” em formato de posts, lives e afins.

É oportuno esclarecer, porém, que a aproximação mais consistente (e talvez mais modesta) do Kanban com o Scrum, se deu em 2018 quando o Daniel Vacanti — uma das pessoas que contribuiu ativamente nas primeiras implementações do método Kanban, na Corbis, em 2006 — se juntou a Scrum.org e ajudou a criar o treinamento oficial Professional Scrum with Kanban™ (PSK), que tem como objetivo central, orientar Times Scrum na aplicação das práticas utilizadas pelo Kanban, sem a necessidade de abandonar os elementos essenciais do Scrum. E muito embora eu tenha algumas críticas a este treinamento (sim, compartilhei meu feedback com a comunidade da Scrum.org como uma oportunidade de melhoria) tive o privilégio de, junto com a AdaptIdeas, organizar a 1ª turma do PSK™ em maio/2019 aqui no Brasil. Com algum conhecimento de causa, posso afirmar tranquilamente que a proposta do treinamento tem muito a contribuir para fortalecer o Professional Scrum.

Frise-se ainda que, na época em que rodamos as primeiras turmas do PSK™ no Brasil, os porta-vozes da comunidade Kanban local (pelo menos o mais enérgicos deles) teceram críticas pesadas e injustas chamando o treinamento de Kanban apócrifo, de puxadinho do Scrum (qdo li essa crítica eu rachei) dentre outros absurdos e leviandades. 🙂

Precisou o Mr. David Anderson & cia mudar o seu posicionamento para fazer a turminha tropical do Kanban deixar as paixões ideológicas de lado e reconhecer, de maneira mais ostensiva, o que o Daniel Vacanti já havia reconhecido 4 anos atrás. Independente da motivação, entendo que mudanças de ideia e de posicionamento devem ser sempre vistos com bons olhos.

Breve introito feito, adentremos então nos motivadores que me fizeram escrever este singelo post.

Por razões que estou ainda tentando compreender, recebi de alguns amigos e seguidores fiéis um post com o título 12 COISAS A MELHORAR NO SCRUM (sem tirar Sprints), escrito por um dos representantes da KU no Brasil. E lendo o aludido post, notei que muitas das coisas apresentadas pelo autor já foram, na verdade, melhoradas pela própria comunidade do Scrum — a partir do ciclos de melhoria contínua e da evolução natural das coisas — sem a necessidade de uma ajuda mais latente do Kanban. Além disso, notei tbem que muitos dos pontos e argumentos apresentados no post são conceitos que já estão deprecados há um bom tempo.

Minhas considerações a respeito, estão a seguir:

Nota: para facilitar a leitura, o texto em itálico com fundo amarelo são as considerações feitas pelo autor extraídas do post em questão (link acima)

1. Expandir o Upstream

^{Mapear o Discovery, com um quadro kanban, pode ajudar o Product Owner no seu trabalho – enxergando-o como um Fluxo – seja para sempre ter demandas suficientes para o Sprint Planning (o Replenishment na língua Kanban), evidenciar a necessidade de disparar um “Grooming” e gerenciar a demanda. Esta melhoria também pode “chamar para o Scrum” outros stakeholders que tendem a se afastar, criando “skin in the game” entre todos os demandantes do processo. O benefício oblíquo desta melhoria é trazer a voz do cliente para próximo do time e aliviar a fragilidade mais elementar do Scrum: “the PO is the single wringable neck”.}

Pra quem já participou de nossas turmas do treinamento Profissional Scrum Product Owner™ (PSPO) sabe que o direcionamento, tanto do curso quanto da Scrum.org (que é a proprietária intelectual do material didático utilizado no treinamento), é a de que o Product Owner é o Gerente Ágil de Produto. Isso quer dizer que o PO deve se preocupar, não só com o que é esperado dele como membro de um Time Scrum, mas em fazer a gestão efetiva do produto do — Discovery ao Delivery. Como é sabido pelos que não pararam de ler, gerenciar produto com Scrum, exigirá do PO que ele faça pesquisas de mercado, que ele compreenda a concorrência, que interaja com as partes interessadas capturando, por intermédio das métricas e dos feedbacks, novas oportunidades de mercado e que, dentre outras, se comunique efetivamente com o time, de modo a maximizar o valor do trabalho que é feito. Um PO proxy, como me parece ser o PO a que o autor esteja se referindo, ou seja, aquele PO que é um mero “gestor de backlog” ou um “tirador de pedidos” não deveria ser estimulado em um time Scrum.

Isto posto, se um Product Owner compreende bem suas responsabilidades na gestão de um produto, é bem provável que ele já esteja visualizando e gerenciando de alguma forma, com ou sem ajuda de um quadro Kanban, a evolução das hipóteses/produto (from-upstream-to-downstream).

Um outro detalhe importante, que talvez tenha passado despercebido pelo autor do post é que, principalmente a partir do Scrum guide 2020, clientes e demais partes interessadas podem (e devem) estar mais próximas do time. Seja por participar da Sprint Planning quando fizer sentido, seja por dar o feedback e trazer as necessidades do negócio na Sprint Review ou ainda por minimizar a necessidade do PO de ser a “única voz do cliente”.

2. Kanbanizar o Sprint

^{Quando ministrava treinamentos de Scrum ensinava e usava nos meus clientes aquele famigerado “Sprint Board” que aprendi no meu CSM em 2007. Trata-se daquele modelo que ainda é usado em algumas organizações até hoje onde quebramos o Item do Sprint Backlog em tarefas de aproximadamente (ou no máximo) 8 horas e utilizamos a Daily Scrum para atualizar o andamento da Sprint neste quadro. Era um modelo bem simples e que tem seus benefícios, porém tem pontos cegos extramamente relevantes: gargalos, filas e bloqueios também acontecem dentro da Sprint. A orientação aqui é fortalecer a gestão visual da sua Sprint tratando-a como um Fluxo, usando um quadro kanban com suas etapas detalhadas no Workflow do Time Scrum.}

Embora eu acredite que a esta altura a maioria dos times Scrum já tenham “kanbanizado” suas Sprints, neste ponto concordo em partes com o autor do post. Hoje em dia, são bem poucos os times Scrum que ainda estejam utilizando um Scrum board simples sem que haja a necessidade de mapear melhor o fluxo. De todo modo, os participantes do treinamento PSK™ e as pessoas que passaram na certificação PSK I certamente compreendem a importância de se visualizar o fluxo (no sentido mais amplo e especializado da palavra) e o Scrum, por intermédio dos pilares do empirismo, pode contribuir bastante para que os times Scrum que ainda não chegaram, cheguem a esta conclusão.

3. Limitar o WIP (dentro da Sprint)

^{A Sprint é o mecanismo escolhido pelo Scrum para limitar o trabalho em progresso. É responsabilidade do Time Scrum definir o que “cabe na Sprint”, na maioria das vezes especulando o tamanho das tarefas ou usando práticas mais exóticas e ineficientes como o Planning Poker. Como sempre digo o Scrum é um Sistema Puxado, porém arcaico. De qualquer forma o Timebox do Scrum é melhor que um sistema sem limitação nenhuma no WIP.}

_{Se você usa algo parecido com a prática (2) acima é possível limitar quantos Itens do Sprint navegam pelo Fluxo do Time, tornando a execução da Sprint “mais ágil”. Como exemplo, limitar o trabalho em progresso nas etapas do Fluxo cria FOCO e poderá garantir que ao menos alguns itens serão entregues na Sprint. Esta prática também limitará o tempo em fila, aumentará a Eficiência do Fluxo, promoverá uma maior colaboração, removerá o abuso ou sobrecarga “acidental” (aquele que muitas vezes não é resolvido pela Spring Planning pelas razões listadas no parágrafo anterior) e também gerará um estresse necessário para melhorar o Fluxo de execução da Sprint. Tenha certeza que Limites WIP no Scrum irão turbinar os assuntos da Retrospectiva.}

Yuval Yeret — trainer da Scrum.org e um dos criadores do treinamento PSK™ — defendeu em seu artigo a ideia de que o Sprint é uma forma de limitar o WIP. Independente de concordarmos com ele ou não, quando puxamos os PBIs para o Sprint Backlog acabamos limitando, meio que por osmose, a quantidade de trabalho em progresso. O que talvez precise ficar mais claro aqui é que, Times Scrum não precisam definir o que “cabe na Sprint”. O mecanismo utilizado para orquestrar “o que entra e o que sai” da Sprint é o Sprint Goal e que, uma vez definido, permite ao time incluir na Sprint corrente novos itens, excluir e/ou desmembrar itens que já estejam no SB, tornando desta maneira a Sprint mais ágil e mais orientada ao negócio.

Uma prática, porém, que muitos Times Scrum costumam aplicar e que, a meu ver, faz mais sentido no contexto Scrum é o swarming (enxame). A ideia por trás desta prática é estimular que os Developers iniciem o desenvolvimento do menor número de itens possíveis e que, enquanto estes itens iniciados não estiverem prontos, não seja iniciado o desenvolvimento de outros. Esta é uma forma bastante eficaz pela qual times Scrum promovem a colaboração, a multidisciplinaridade e o WIP limit. Portanto, os ganhos da melhoria aqui proposta são marginais uma vez que o Scrum já possui mecanismos e práticas bastante difundidas que auxiliam a limitar o trabalho em progresso.

4. Expandir o Downstream

^{É muito comum que a execução da Sprint jogue o trabalho para uma fila “Aguardando Produção” (ou similar) e não alimente diretamente a entrega de valor para os clientes. Em algumas situações equipes Scrum se limitam a entregar a funcionalidade potencialmente implantável “para o PO”, gerando pontos cegos confortáveis e perigosos – o sistema funciona como um “ciclo aberto”. Usar as técnicas do Kanban para visualizar o Fluxo após a Sprint (downstream ao Scrum) – envolvendo todos os passos até a entrega para o cliente e até após isso – cria um ciclo de feedback fechado que garante que as entregas estão de fato impactando o mercado e gerando valor e/ou aprendizado. Isso nos leva a uma outra capacidade interessante (5), listada abaixo.}

O Scrum tem estimulado, desde sempre, a persecução de ciclos curtos de feedback como forma de reduzir os desperdícios, a complexidade, maximizar retorno, satisfazer os clientes etc etc… e para que isso aconteça é de fundamental importância que incrementos do produto sejam entregues (em produção) sempre que fizer sentido para o negócio. Isso, invariavelmente, quer dizer que a entrega deverá ocorrer a qualquer momento durante as Sprints (não um pouco antes e nem um pouco depois da Review).

Entretanto, as dificuldades que alguns times Scrum encontram em entregar valor aos usuários finais, leia-se em produção, se dá pelas amarras da burocracia organizacional. E, em absoluto, o máximo que método A ou B e prática C ou D podem fazer para auxiliar, é evidenciar aos tomadores de decisão as perdas causadas pela manutenção desta burocracia. Acho importante dizer ainda que já há um movimento da Scrum.org no sentido de lançar um treinamento PSK II (mais avançado) que abordará temas como DevOps, CI/CD, Scaling dentre outros.

5. Fluxo End-to-End

^{Sob as lentes do Kanban, os itens (1) e (4) acima permitiriam uma gestão Orientada ao Serviço de Entrega de valor para os clientes e não somente a instância Scrum – algo que poderia dar uma visão mais ampla e até estratégica de todos que trabalham para este serviço dentro e fora do Scrum. É extremamente raro, principalmente em empresas grandes, a instância Scrum ter contato direto com os clientes e usuários finais, logo, é mais comum elas mapearem somente uma parte da cadeia de valor. É por isso que o Agile precisou nos últimos anos de um “plugin” chamado “Business Agility” – algumas pessoas receberam esse termo no mercado como “boas novas”, mas qualquer pessoa mais informada sabe que é um remendo em algo que não está funcionando.}

^{Essa melhoria número 5 habilitará uma melhor visão e equilíbrio da capacidade e da demanda, habilitará que a empresa tenha antecipação (uma característica essencial para a empresa ter agilidade), proporcionará uma tomada de decisões mais voltada ao cliente e ao mercado, revelará algum possível gargalo corporativo, alavancará otimizações globais, permitirá retrospectivas mais significativas e muito mais.}

Times Scrum são unidades coesas com foco na entrega de valor de negócio (produto). Isso significa que Times Scrum devem compreender e mapear as necessidades de negócio, propor soluções simples e que façam sentido, planejar, desenvolver e entregar (end-to-end). A maioria do times em que tive o privilégio de trabalhar, o contato com clientes e usuários era frequente e, como este contato acontecia de forma natural, conseguíamos sem maiores dificuldades entender e mapear toda a cadeia de valor. Pra quem tiver interesse, e quiser entender melhor como isso pode funcionar na prática, sugiro dar uma lida rápida no paper Scrum Studio: A Model for Innovation escrito em 2017 pelo Kurt Bittner, VP de soluções corporativas da Scrum.org.

6. Daily Scrum estilo Kanban Meeting

^{A reunião diária do Scrum tem um foco excessivo nas pessoas. As famosas três perguntas da Daily Scrum – uma orientação seguida por muitos ScrumMasters por mais de uma década – tem caído em desuso por uma provável influência direta do Método Kanban, isto porque a Kanban Meeting tem como foco o Fluxo, os tickets de trabalho, seus bloqueios, filas, gargalos, políticas explícitas e classes de serviço. Sua Daily Scrum pode ter o estilo Kanban: pergunte sobre o estado dos cartões, não sobre as pessoas. Esta prática pode tornar a sua Daily Meeting menos invasiva. Esse ciclo de feedback deve ser dominado pelo sentimento de “fazer o trabalho fluir”.}

Confesso ser a primeira vez que ouço falar em Daily Scrum com foco excessivo em pessoas. O que temos visto muito por aí ainda são Dailies com foco em task management orientada a status report, por algumas disfunções que podemos desdobrar em um outro post. O que precisamos ter mais clareza aqui é que, nas versões passadas do Scrum guide havia, até como uma forma de facilitar o evento, uma recomendação (não prescrição) para que os Developers respondessem as famosas 3 perguntas. O problema foi que alguns SMs (e alguns trainers) que leram apenas o orelha do guide assumiram isso como algo obrigatório a ser feito em toda fucking Daily… e o resultado disso nós já conhecemos. De todo modo, como a Daily sempre teve como foco o planejamento diário em direção a uma meta de negócio (Sprint Goal) e por ela ser mais velha, digamos assim… é bem provável que ela tenha influenciado a Kanban Meeting a ser como ela é, e não o contrário.

Só a título de conhecimento, no treinamento PSK™ Times Scrum são orientados a analisar durante a Daily métricas como o Work Item Age como um forma de melhorar o autogerenciamento.

7. Métricas de Fluxo “Ágeis” (😖) e a evolução da Retrospectiva

_{Uma das reclamações mais comuns de equipes Scrum é que chega um momento onde não há mais muito o que melhorar dentro da Sprint. Os Kaizens mais significativos estariam upstream ou downstream do Time Scrum. Talvez você veja mais claramente o que precisa melhorar dentro e fora da Sprint se você usar as lentes que as métricas do Kanban podem te revelar, destacando o CFD, Cycle Time Control Chart da Sprint, o WIP Aging, a Análise do Tempo de Bloqueios e etc… Tais métricas podem evoluir a sua Retrospectiva Scrum – que sem métricas é puramente especulativa, qualitativa e muitas vezes só terapia de grupo – para uma Flow Review no estilo Kanban. A Flow Review é a “Retrospectiva com esteróides”: orientada a dados e fatos e não guidada por impressões e sentimentos das pessoas.}

_{São benefícios oblíquos desta melhoria (7): aumento da previsibilidade; exclusão, felizmente, do Planning Poker e Story Points e a provável evolução do ScrumMaster para um Flow Manager.}

Neste ponto concordo bastante com o autor do post. Como o Scrum não evidencie diretamente a importância de se medir e gerenciar o fluxo (isso tá intrínseco), as métricas que sim, provavelmente foram popularizadas pelo Kanban, tem ajudado muitos times Scrum melhorarem a entrega de valor, a previsibilidade e etc. Aliás um dos tópicos bastante discutido no treinamento PSK™ é a importância e o impacto que as métricas (leading e lagging) exercem sobre a tomada de decisão e como elas podem ajuda a melhorar o propósito dos eventos Scrum, tornando os loops de feedback mais efetivos, e melhorando a gestão do todo.

8. Sprint Planning “Automática”

^{Esta melhoria emergiu de forma natural, fruto da evolução, em uma das primeiras implementações Kanban que fiz em equipes Scrum lá por 2011 em uma empresa de Internet. A partir do momento que os itens (2), (3) e (6) acima foram implementados, com o tempo, o buffer “Selecionadas para a Sprint” também teve seu WIP limitado, baseado na capacidade do time, o que tornou a Sprint Planning Parte 2 (onde o Time Scrum decide tecnicamente o que entra e o que não entra na Sprint) totalmente desnecessária. A Sprint Planning ganhou uma cara de “Replenishment” do Kanban, mas com data fixa no início das Sprints.}

Na versão mais atual do Scrum guide o commitment do Sprint Backlog é a meta da Sprint. Portanto, Times Scrum que trabalham orientados a meta de negócio (Sprint Goal), não precisam se preocupar em limitar o WIP do tal buffer “selecionadas para o Sprint”, uma vez que novos itens podem ser criados e re-ordenados para atender a meta a qualquer momento durante a Sprint. Um outro ponto importante que por alguma razão foi desconsiderado aqui é que, desde as versões mais antigas do guia, a palavra “compromisso” deu lugar a palavra “previsão” (salvo engano na atualização de 2011 para 2013) e com isso introduziu-se mais flexibilidade na Sprint. Desta forma, Times Scrum passaram a discutir, ao longo de toda a Sprint, o que deveria entrar ou sair do Sprint Backlog.

É oportuno esclarecer ainda que, modernamente, temos visto e estimulado times Scrum utilizarem a Planning como um ponto de definição de uma meta (Sprint Goal) que seja alcançável e que faça sentido para o negócio e que a partir disso, eles puxem apenas itens de backlog para os primeiros dias da Sprint e que plano seja evoluído ao longo da iteração.

9. Sprint Review sob Demanda

_{Eu realmente acho que este item de melhoria é chover no molhado. Creio que foi em 2019 que fiz uma pesquisa em um grupo de discussão sobre métodos ágeis e muitas pessoas, creio que quase a metade delas, já usavam essa prática, pois os riscos de deixar uma revisão “para o final da Sprint” é uma postura “cascateira”, consequentemente propensa a riscos desnecessários. Muitas delas já tinham “Kanbanizado a Sprint” (item 2) e possuíam uma etapa no Fluxo que envolve, sob demanda, uma atuação do PO para validar as demandas dentro do tempo da Sprint. Com isso a Sprint Review ao final do Sprint se torna pro forma, ou melhor, me parece irresistível acrescentar aqui conteúdo KCP, ela se torna uma relíquia evolucionária.}

Pois é aqui realmente eu tbem acho que o autor choveu no molhado. Validar o que está pronto, principalmente quando se trabalha com timebox (foco), é algo que me parece bastante intuitivo. Em 2017, tive a oportunidade de trabalhar no desenvolvimento (do zero) de um produto (tag de pedágio) em uma grande empresa do setor de meios de pagamento. Me lembro que, toda vez que um item estava pronto e validado pelo PO durante a Sprint, buzinas eram tocadas por membros dos demais times (eram 5 times trabalhando no mesmo produto) e o clima de festa tomava conta do ambiente. Até aqui nenhuma novidade.

Entretanto, quando times Scrum entendem que não há a necessidade da Sprint Review, pelo simples fato dos itens já terem sido revisados pelo PO, fica claro que falta ainda uma melhor compreensão do propósito do evento. Se a Sprint é um loop de feedback é na Sprint Review que temos o momento mais oportuno para consolidar este feedback e, junto com o cliente, descobrir o que fazer a seguir.

10. Fortalecer as Políticas Explícitas

_{Esta foi uma contribuição do Rodrigo Oliveira para o artigo. O Scrum tem o seu próprio conjunto de políticas – elas estão no Scrum Guide – coisas como: “Sprints têm duração fixa de um mês ou menos para criar consistência”, “Scrum Teams são multifuncionais” e muitas outras. O Kanban, por outro lado, não tem regras fixas, mas ele prega que se a organização tem regras elas devem ser claras e explícitas para todos e também seguidas até que uma discussão a respeito da efetividade delas seja questionada em algum Ciclo de Feedback. Com as regras claras todos ficam mais seguros. Em uma implementação Scrum as Políticas Explícitas podem guiar o comportamento na seleção de Itens no Sprint Planning, quais são as regras para iniciar novos Itens dentro da Sprint, o disparo de comportamentos sob demanda (como o “Grooming”), os critérios de aceite, as situações de cancelamento da Sprint e etc… Somente regras explícitas, sendo sequidas e com seu impacto mensurado, que geram motivação emocional necessária para questioná-las e com isso a melhoria do processo. Não há jeito melhor de remover burocracias do que respeitá-las!}

Sim, esta prática do Kanban pode ajudar Times Scrum a relembrar o fato de que transparência e visibilidade nunca é demais (me lembrei de um chefe meu que dizia q “o que abunda não prejudica”). Só pra não passar batido, aproveito o tópico para abrir um pequeno parêntese. Pela segunda vez o autor do post se refere ao Refinamento como “grooming” e embora o foco aqui não esteja nos “nomezinhos” técnicos disso ou daquilo… o termo grooming foi retirado da versão 2011 do guide por ter uma conotação negativa para algumas culturas ao redor do mundo. Não tenho dúvidas de que o autor tenha conhecimento disso, mas preferi registrar para o caso desta curiosidade não ser do conhecimento de algum visitante deste blog.

11. Aumentar o Tamanho do Time

_{O Scrum Guide limita o tamanho do Time Scrum em aproximadamente 10 pessoas. Esta regra pode tornar a autogestão e auto-organização mais simples, porém, não necessariamente esta é a forma mais efetiva para se trabalhar. Para o Método Kanban, um fluxo Orientado ao Serviço pode envolver dezenas e em alguns casos até uma centena de pessoas, logicamente pensando em toda a cadeia de valor e não só à instância Scrum. Relatos de organizações que sobrepujaram essa limitação de 10 pessoas com Kanban são inúmeros. Para os efeitos deste artigo, acreditamos que os itens 2, 3, 6 e 10 podem aprofundar a comunicação e a autogestão do que acontece dentro da Sprint de forma que esse número pode ser aumentado, e assim, a capacidade de entrega otimizada, os custos de coordenação reduzidos e também melhor performance e menor impacto na gestão de dependências.}

Posso até estar enganado mas não me lembro de ter visto, em nenhuma das versões do Scrum guide, esta regra que limita o tamanho de um time em aproximadamente 10 pessoas. O que há é a recomendação de que o tamanho do time seja (idealmente) de até 10 pessoas, ou seja, nem tão grande para não prejudicar o autogerenciamento e nem tão pequeno para não prejudicar a multidisciplinaridade. Tem inclusive o conceito do 2-Pizza Teams criado pelo Jeff Bezos da Amazon falando a respeito deste assunto.

Independente das recomendações do guide, já tive a oportunidade de trabalhar com Times Scrum de 20 pessoas e não tivemos qualquer problema quanto a isso. Neste quesito entendo que o autogerenciamento deva ser o grande juiz de todos e que os times devem empiricamente ser os responsáveis por aumentar ou diminuir o seu tamanho quando, e se, fizer sentido.

12. Implementação de Classes de Serviço

_{Classes de Serviço e a facilidade de implementá-las em um Fluxo é um dos inúmeros ícones do Método Kanban. Apesar da restrição que coloquei neste artigo de NÃO TIRAR A SPRINT (e outros elementos chave do Scrum), mesmo assim, Classes de Serviço podem ser efetivas no Scrum e um meio de contornar algumas limitações impostas pelos Timeboxes. Combinando isso com Reserva de Capacidade (limites em raias, como exemplo) é possível criar um sistema de entrega de valor levando-se em consideração o perfil de risco de cada demanda (este é o poder das Classes de Serviço). Possivelmente, com alguma flexibilização razoável das regras do Scrum, podemos alcancar melhores resultados para nossos clientes, fazendo que nossas entregas com o Scrum sejam mais adequadas ao propósito.}

Acredito que alguns times Scrum possam chegar a conclusão de que as classes de serviços auxiliem de alguma forma na gestão das demandas. Entretanto, um Time Scrum que compreende e domina bem o framework não tem a menor necessidade de trabalhar com elas. Como já citado anteriormente, times autogerenciados buscarão sempre compreender como melhor atender as necessidades do negócio e a colaboração com o cliente, proposta pela abordagem ágil, fará com que essas necessidades sejam atendidas da melhor forma e num prazo razoável para o negócio.

Conclusão

Sabiamente, e até por ser um framework, os criadores deixaram explícito no guia que o Scrum é propositalmente incompleto e que práticas complementares podem ajudar. Além disso, aproveito para reafirmar aqui, o que tenho dito nos últimos tempos nas redes e na comunidade: mudanças repentinas (e nonsense) “do Scrum para o Kanban” na maioria das vezes acontece por falta de compreensão ou por implementações ruins do framework.

E embora esta “aproximação” promovida pela KU seja um pouco tardia (logo eles que falam tanto em CoD), e talvez oportunista, entendo que este movimento — iniciado de maneira mais consistente em 2018 pela Scrum.org — só tem a agregar uma vez que estimula a comunidade Scrum a continuar melhorando o framework, mantendo (ou não) as bases que o fez prosperar até aqui.

Saudações.

Créditos: esta é a segunda versão do post, a primeira confesso estava bem melhor… ocorre que o sr. WordPress resolver dar pau no salvamento automático e perdi praticamente a primeira versão inteira do post. O lado bom (e sempre há um lado bom nas coisas) é que o post original tbem foi alterado pelo autor o que me permitiu contemplar aqui as alterações realizadas lá. 🙂