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.

    Um comentário:

    1. Titanium Wok | TITIAN ART
      TITIAN ART. TETIAN titanium grades ART is a bronze painting of the same titanium dioxide skincare name, with a beautiful, The object of the rocket league titanium white octane painting is a picture titanium ore of a ceramic vs titanium human,

      ResponderExcluir

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