Quando a equipe “demite” o Scrum Master

Calma! Não quero ver pessoas desempregadas. Muito menos eu :P

O termo “demitir” nesse caso, seria mais bem compreendido como: “Demitir da equipe”. Com a conotação de envia-lo para uma equipe que de fato esteja necessitando de um Scrum Master.

Há quem diga que a metodologia Scrum não é para qualquer equipe. Estes pregam que: o Scrum sintetizou no “time-scrum” todas as atribuições que cabem somente ao time, transferindo todas as demais (os problemas?) para o Product Owner (PO). Em outras palavras, é como se a metodologia exigisse que o time fosse responsável somente pelo desenvolvimento de software. E que o fizesse com excelência. Garantindo assim, o pilar da Qualidade do projeto (que nesse caso seria: baixo índice de defeito, de tal modo que não afetaria as relações cliente-fornecedor). Em contra partida, a mesma metodologia exigiria que o Product Owner resolvesse todos os demais problemas. Tais como: Escopo, Prazo, impedimentos de negócio e Custo do projeto. Dessa forma, argumentam que a metodologia transfere a responsabilidade de sucesso do projeto para o maior interessado, no caso o Product Owner e, libera o time de desenvolvimento para fazer aquilo que sabe melhor: desenvolver software. Sem burocracia. De forma incremental. Sem duvidas.

Para atender as expectativas da metodologia, exige-se um Product owner que seja dono de fato. Estando inclusive disposto a aceitar que suas responsabilidades possam culminar no sucesso ou fracasso do projeto. Do outro lado, temos o time-scrum. Responsável por manter os canais de comunicação extremamente ativos. Que permita ao product owner participar de tudo que acontece. Que seja um time de característica pró-ativo. Que resolve. Que se alimenta.

O que se observa, é que nem todo product owner é dono de fato. E que nem todo time é maduro o suficiente. Para isso, existe o Scrum Master. Papel esse, que ajuda o product owner e o time. Que faz o casamento das duas partes. Que fala da qualidade e que avisa do escopo. Que no fim, acaba até falando se o prejuízo é eminente. Assim, pode-se dizer que o SM é um papel transigente, que está no desenvolvimento e na gestão do projeto. Por fim, trata-se de um papel fundamental para o encaixe das engrenagens Gestão-Desenvolvimento.

Mas, se o papel é fundamental, como demiti-lo? Seria pelo PO ou pelo time? Certamente, seria pelo time. Por um time maduro, responsável, que assim como o PO, seja dono do negócio. Autônomo. Auto-Gerido. De Alta performance. Um time que já é time, que deixou a fase de grupo para trás. Assim, pensou-se em cinco características de time que dessem indícios que o seu time é um time que já pode demitir o SM.

Um time que entrega qualidade. Que já “demitiu” o tester.

Entregar qualidade. Mas, o que seria qualidade?Qualidade para o time seria menos retrabalho. Seria fazer uma única fez. Bem feito.

Para chegar a esse nível, o time necessita ter mecanismos de garantia da qualidade. Bem como, práticas de processo bem estabelecidas. Para essa, suas estórias teriam que possuir critérios de aceite bem definidos. Não haver impedimentos. O Kanban deveria ter todos os critérios de Definition of Ready e Done respeitados. De forma, que pudesse ser extremamente lúdico o que necessita ser feito e quando. Para o outro deveria ser um time que faz uso excessivo de testes unitários e code-review. Que possui uma política de Integração Continua bem estabelecida. Que dilui a fase de verificação e inspeção em cada task de cada estória. Que traz a garantia da qualidade por meios de atividades que não sejam o teste fundamentado em caso de teste, mas sim, em práticas e processo. Enfim, ser um time que desenvolve com qualidade, regrado, que testa e que sempre garante.

Um time que não espera cerimônias ou ritos. Que divide para conquistar.

Dividir para conquistar. Fazer de forma incremental. Que não doa a ninguém. Entender que os ritos podem ser feitos antes do ultimo dia do sprint. Que a comunicação constante dentro da equipe, permite que feedbacks sejam dados e correções de curso sejam realizadas. Um time que ao olhar o burndown, já sabe que algo não está bem. Que use dos números a seu favor. Que faz o planejamento singular das estórias e não do sprint. Que identifica melhorias antes mesmo do inicio do desenvolvimento de uma estória. Um time que dilui o PDCA no dia. Que faz dia-a-dia o que seria do sprint.

Um time que sabe o que consegue entregar. Que se conhece.

Que se conhece. Não em comportamento. Mas, em números. Para isso é essencial que o time saiba quais são seus indicadores. Que saiba de sua produtividade. De sua taxa de retrabalho. De sua velocidade de entrega. Que seja capaz de alertar logo no inicio de um ciclo que a carga é demais para o sprint. Ou ainda, saber que determinada funcionalidade permite uma melhor produtividade e aceita uma carga maior no sprint. Um time que alerta. Que sabe de suas limitações e virtudes.

Um time que planeja seus passos. Que sabe onde anda.

Que sabe onde anda. Que já planejou cada task de uma estória. Que toda estória do Sprint está quebrada em tasks planejadas. Que cada task tenha sua definição de pronto. Que saiba antes de iniciar o desenvolvimento da estória, que há riscos envolvidos nas mesmas e quais são. Que comunica sobre os riscos. Que no planejamento, se obtenha estimativas coerentes. Que os indicadores sejam utilizados ao planejar. Que a reutilização e boas praticas de programação sejam discutidas. Enfim, que faça do planejamento algo prático e não dolorido.

Um time de metas. Que corre atrás do que se planeja.

Que corre atrás do que se planeja. Que sabe pelo que se planejou o que é possível se realizar no dia, na semana, no Sprint. Que estabelece metas. Que as divulga. Que trabalhe com foco em resultados. Que seja coerente. Que faça uso dos números à disposição. Que seja engajado com o objetivo. Que não caia em disrupção. Que tenha proposito e missão.

Times com essas características são como duendes islandês. Existem, mas são extramente difíceis de encontrar. Ora, pelo tempo de se doutrinar o time a agir dessa forma, ora pela complexidade do negócio em que são inseridos. Contudo, nada impede que uma gestão de pessoas incisiva seja empregada. Gestão que tenha como virtude criar times de alta performance. Que estabeleça metas pessoais e que empurre todos para excelência. Gestão essa, que dentro do time, cabe ao próprio Scrum Master desenvolve-la e difundi-la. E, por ironia do destino, cabe ao mesmo, assinar sua demissão do próprio time.

A criação de equipes esta relacionada à necessidade do desempenho, essas equipes devem criar uma unidade básica deperformance, tendo em vista que a criação de equipes tem como objetivo o desafio, agindo com uma mola propulsora para a busca deperformance, essas equipes são consagradas por um esforço ou uma vontade organizacional, pois a realização da tarefa se torna uma exigência ou requisito essencial para sua realização. (KATZENBACH; SMITH, 1994.)

Obrigado pela Leitura.