Equipe

A Equipe Scrum é constituída por todos os participantes no projeto. Os membros da equipe representam papéis os quais se classificam quanto à responsabilidade e quanto ao nível de comprometimento.

Quanto à responsabilidade

Quanto à responsabilidade existem dois papéis de destaque: o Scrum Master e o Dono do Produto (Product Owner). Repare que todos os membros de uma Equipe Scrum desempenham vários papeis durante o desenvolvimento  ( dos quais falaremos depois) mas o Scrum Master (SM) e o Dono do Produto são especiais. Não são especiais porque têm mais responsabilidade que o resto e sim porque só podem ser representados por uma pessoa e sempre pela mesma. Ou seja, quem é o Dono do Produto tem que sempre ser o Dono do Produto e quem é o Scrum Master sempre tem que ser o Scrum Master. O resto dos papeis pode ser permutado, mas não estes.

O Scrum Master

O Scrum Master é aquele que respeitando os valores e as práticas do Scrum faz os outros participantes as seguirem e respeitarem também. Além disso ele é o Facilitador oficial do projeto. Tudo aquilo que impede o projeto de seguir em frente é mencionado ao Scrum Master (SM) e é dele a responsabilidade de remover esses obstáculos.

Tradicionalmente espera-se que um Gerente de Projeto tenha exatamente esta função. Contudo os Gerentes de Projeto tradicionalmente passam seu tempo mais preocupados com planilhas e horas de trabalho da  equipe em vez de com aquilo que interessa ao projeto. Em scrum não se gerencia a equipe, gerencia-se o projeto. Sendo que do principio ao fim do projeto ha um compromisso entre pessoas que se respeitam não ha porquê ficar no pé da equipe ou pairando sobre os seus ombros. Todos se comprometem periódicamente a cada sprint com o seu trabalho e como tal não é necessário vigiá-las a todo o momento.

Em Scrum o controle de cronograma é absurdamente simples e eficaz. Isso permite que a pessoa no tradicional papel de Gerente realmente agora possa ajudar a equipe e o dono do produto a realizar algo. Isto é normalmente um problema durante a implantação do Scrum. Para assumir o papel de Scrum Master a pessoas terá que ter muita coragem e respeito. Entenda-se que ela não irá definir o Produto nem construi-lo mas tudo o que poder dar errado durante o decorrer do projeto irá cair nas suas mãos. Desde dá falta de café até à falta de máquinas, até a falta de definição do que fazer a seguir.

Depois que o projeto tenha um Scrum Master com a coragem , respeito de, e pelos, que possa se responsabilizar pelo andamento do projeto, você precisa de alguém que se responsabilize pelo Produto em si: o dono do produto.

Insight

O paradoxo é o seguinte: é esperado que aqueles que são designados gerentes no modelo tradicional assumam o papel de scrum master em Scrum. O problema é que essas pessoas não estõa habituadas a serem abertas, a respeitarem os membros da equipe (muitos se referem à equipe como “os meninos”) ou a terem a coragem de resolver problemas. Para os gerentes tradicionais “gerenciar” significa “conseguir delegar” que é um eufemismo para “não fazer nenhum o dia todo e ganhar todos os louros”. Em Scrum isto não funciona. Um enrolão destes é detectado no primeiro mês de uso de Scrum pela sua incapacidade em resolver problemas. É por isto que muitos gerentes resistem ao uso do Scrum. Eles têm completo pavor que o seu embuste seja exposto. O que é curioso é que os chefes destes gerentes não fazem nada para os por à prova. Donos de empreas não querem (supõe-se) vagabundos nos seus quadros. Se você é dono de uma empresa, não importa o tamanho. Implemente Scrum e verá os ratos fugirem do navio. Aqueles que ficarem é porque têm a coragem e o respieto pela sua empresas e pelos colegas para se comprometerem com o trabalho.

O Dono do Produto

O Dono do Produto é aquele que tem a responsabilidade de definir o que o produto é. A definição do Produto é algo extramente sério e estratégio e deve ser deixado sob a responsabilidade de alguém que entende. Por exemplo, ao construir um software muitas funcionalidades podem ser adicionadas. Algumas essencias e outras superfluas ou de embelezamento que mas trazem valor ao produto e retorno a quem aposta no produto.Contudo não podemo enchar o produto com tudo o que é possivel ser feito. Isso gera trabalho extra que não trará nenhum valor ao produto, ou pior, irá desvalorizar o valor que o produto já tem sem essas funcionalidades.

Funcionalidades demais ou funcionalidades inuteis ou que não produzirão retorno. Este é o tendão de Aquiles de todos os projetos de software. Se deixado à vontade dos programadores ou à dos clientes o produto terá tudo e mais alguma coisa e se deixado à mercê dos finaciadores ele será o mais simples possivel : tão simples que não fará cocegas à concorrencia. É por isto que o projeto precisa de um Dono do Produto.

Além de estipular o que o produto terá de funcionalidade, o Dono do Produto também estipula em que ordem as funcionalidades serão adicionadas. O objetivo aqui é ter um produto comercializável o mais cedo possivel, mesmo que antes do fim do release. Desta forma o Dono do Produto poderá utilizar estas versões alfa para fazer pequenas demonstrações e angariar fundos, clientes ou convencer os stakeholders de que o projeto tem mérito e precisa ser levado até ao fim.

A forma do Dono do Produto poder interferir na ordem da implementação das funcionalidades é priozandos as histórias no back log do release tomando em consideração o valor da funcionalidade e o tamanho dela já préviamente estimado pela equipe.

É preciso deixar claro que o Dono do Produto não é o Gerente de Projeto nem o Scrum Master.  O Dono do Produto não é o Cliente nem é “quem paga”. O Dono do Produto é o responsável pelo produto. Apenas pelo produto. Não pela entrega, prazo, custos,etc.. Embora sua decisões possam influenciar e serem influenciadas por estes parametros não é da sua responsabilidade que o produto seja entregue no prazo ( isso é responsabilidade do Scrum Master) e sim que o produto entregue tenha o maior retorno de investimento (ROI) possivel.

Em uma empresa que produza software para consumo interno ou para venda “de prateleira” o dono do produto é normalmente alguém do departamento de Produto. Em empresas que não tenham este tipo de departamento o Dono do Produto pode ser qualquer pessoas desde que tenha a capacidade e o poder de decisão sobre o que entra e sai da definição do produto.

O Dono do Produto é livre de conferenciar com as pessoas da equipe  que lhe dão informações para basear suas decisões. Normalmente estas pessoas são o Scrum Master, alguém ligado a marketing/pesquisa de mercado, legal, artistas e desenvolvedores. Ele é livre de incluir na equipe qualquer um que ele considere que trará valor ao produto.

A Equipe

Explicar quem é a equipe é a parte mais dificil de explicar o Scrum. Parece contraditório mas é verdade. À primeira vista diriamos que os desenvolvedores são a equipe. Sim, eles estão na equipe. Contudo, são necessárias pessoas que testem o software e garantam que cada funcionalidade dele está pronta. Pessoa que documentem o software para se saiba exactamente o quê cada parte faz e como. Sobretudo quais decisões tiveram que ser feitas durante o desenvolvimento. Precisamos de artistas gráficos e de som, para embelezar o software. Precisamos de pessoas de marketing e legal para dizerem o que seria interessante ser colocado e o que não pode.  Precisamos de especiialistas no domino do software para informarem as regras intrinsecas ao dominio. E muitas vezes precisamos do apoio de pessoas que nem trabalham na empresa, mas cuja participação é necessária. Por exemplo, ao implementar um sistema de e-comerce é importante trabalhar com alguem da operadora de cartão de crédito; ou se a aplicação for enviar SMS  possivelmente temos que trabalhar junto de alguem para operadora de telefonia ou de um message broker. E sempre é boa ideia entrevistar alguns usuários para entender o que elas esperam do software  em termos práticos.  Um software é feito por muito mais pessoas que apenas os desenvolvedores. A equipe é portanto formada por todos aqueles que participam de alguma forma para o sucesso do projeto.

O termo “equipe scrum” refere-se a todos os envolvidos que participam ativamente no projeto e inclui o Dono do Produto e o Scrum Master.

O termo “equipe” refere-se normalmente a todos os que fazendo parte da equipe scrum não são o Dono do Produto nem o Scrum Master. Normalmente isto significa os desenvolvedores, mas não está limitado às pessoas que programam o software.

Os papeis de Dono do Produto e Scrum Master não podem ser desempenhados pela mesma pessoa. Tirando isso o Scrum Master pode ser qualquer um, inclusive um membro da equipe que passa a maior parte do tempo representando outro papel. Sendo que o papel de Scrum Master exige resolver vários problemas politicos é necessário que esta pessoas tenha a autoridade perante outros para poder resolver esses problemas. Nada impede que um dos desenvolvedores ou o arquiteto sejam o Scrum Master, excepto a sua falta de autoridade perante aqueles que não fazem parte da equipe scrum.

O ideal é que existam pelo menos 4 pessoas destintas para que os papeis sejam bem separados e não haver confusão com as responsabilidades de cada um. Contudo, 3 já podem formar uma equipe scrum : 1 Dono do Produto e 2 membros da equipe fazendo um deles o papel de Scrum Master.

Por outro lado não é vantajoso que a equipe seja demasiado grande. Um limite de 7 pessoas é aconcelhando na literatura. A partir daqui é demasiada confusão.

Quanto ao comprometimento

Como vimos o scrum é fortemente baseado em comprometimento. Infelizmente nem todos os membros da equipe estão empenhados no projeto com o mesmo nível de comprometimento.

Certo dia iam um Porco  e uma Galinha pela estrada imaginando o que fazer  para ganharem algum. A Galinha teve a ideia e disse para o Porco – Que tal abrir um restaurante? – E como se chamaria – retrucou o Porco. “Presunto e Ovos” respondeu a Galinha. O Porco pensou e respondeu à Galinha já animada com os lucros:  – Acho que não é boa ideia. Tu estarias apenas envolvida enquanto eu estaria realmente comprometido.

Também entre a equipe Scrum existem os que se comprometem – chamados “Porcos” ( em alusão ao personagem da historia)  e os que apenas estão envolvidos – chamados “Galinhas”.

Todos sabemos o que as Galinhas fazem na presença de problemas: fogem. E o Porco é que se lasca. Literalmente. Esta metáfora é perfeita para caracterizar o tipo de participantes em um projeto.

Sendo que um dos valores do scrum é o Comprometimento a execução não pode estar apenas nas mãos dos envolvidos. São necessários os que se comprometem.

O Dono do Produto e o Scrum Master são porcos quase que por definição. Os outros sãos os membros chave da equipe sobrante. Normalmente os desenvolvedores. Todos os outros são apenas Galinhas. Muito do trabalho do Scrum Master é manter as Galinhas na ordem para que não atrapalhem o trabalho dos Porcos. Isso é dificil porque normalmente as Galinhas se acham muito importantes e vaidosas e acham que elas é que têm tudo a perder se o projeto der errado. Na realidade elas só têm a ganhar ( e sabem disso); apenas querem que os outros se queimem por elas.

Esta peraltice das Galinhas exige ainda mais que o Scrum Master tenha real autoridade sobre elas. Caso contrário elas simplesmente irão sabotar o projeto – mesmo sem querer – por se acharem demasiado importantes para darem explicações.

Insight

Em uma empresa com hirarquia para-militar ( que são quase todas e infelizmente as regras trabalhistas ainda apoiam esta visão) o Scrum Master tem um problema grave. Ele deve comandar as Galinhas, mas as Galinhas são sua superiores hirarquicas, ou pior, amigas das suas superiores hirarquicas. Isso deixa o Scrum Master de mãos atadas muitas vezes e este é o real desafio do Scrum Master hoje em dia.

Sendo que em Scrum não existe uma hirarquia (isso deixa muitos confusos) o Scrum Master tem a liberdade de imprepor as suas preocupações aos superiores dos seus supriores imediatos ou aos superiores de hirarquias paralelas que o possam ajudar a resolver os problemas. A velha máxima “Fale com Seus e não com os santos” se aplica aqui. É claro que isto só funciona se a hirarquia para-militar for flexivel o suficiente, ou se as pessoas envolvidas realmente se preocuparem com o sucesso dos projetos da empresa em que trabalham mesmo quando são de outros departamentos. Esta é a parte realmente dificil e complexa de implantar o Scrum. O Scrum dissolve o conceito de “poder” e o substitui por “respeito por compromisso”. O poder advem de cumprir o compromisso e adquirir o respeito. O poder não é automatico nem dado pelo nivel hierarquico em que a pessoa está. O exemplo classico é o presidente da empresa tentar dar pitaco em assuntos técnicos que desconhece porque acha que se ele foi desenvolvedor ha 20 anos atrás esse conhecimento lhe vale alguma coisa para definir o desenvolvimento de agora. Se isso fosse verdade ele não precisaria contratar desenvolvedores, analistas, arquitetos, etc..

Em Scrum se documenta o que vai ainda precisa feito e não como vai ser feito. É que o “como” muda a todo o momento conforme as constrições do momento. Ao colocar como Scrum Master uma pessoa que passou a vida sendo o tipo de Gerente de Projeto que fica muito preocupado em gerenciar as pessoas e as tarefas das pessoas acontece um choque de cultura. É quase impossivel mostrar a este tipo de gerente que o que ele tenta fazer é numa escala tão absurdamente fina que na realidade ele não produz nenhuma informação util. E quando o faz, ela já está desatualizada porque o projeto mudou. Convencê-lo disto é quase como convencer alguem a deixar as drogas. Pior. Porque ele acha que está fazendo certo. O Scrum propõe um mecanismo de controle de muito mais alto de nível e isso confundo este tipo de gerente que não acredita que isso funcione. Isso é irónico porque acredita e jura piamente que o sistema que ele usa funciona, quando todos sabemos que não funciona, mas não acredita em um sistema que provadamente funciona. Irônico.