Foco no Scrum Team!

Quem são? Onde vivem? Do que se alimentam?

Em mais uma talk de 10 minutos com a galera da Concrete e Accenture em Recife (antes de irmos todos para home office), conversamos sobre o Scrum Team, e cheguei à conclusão de que já tinha falado muito sobre eles, mas não com a lupa apropriada.

O Scrum Team é a equipe formada pelo Scrum Master (disseminando agilidade), o Product Owner (valor do negócio) e o Time de DEV ou Desenvolvimento (transformando requisito em produto), trabalhando sinergicamente para o mesmo resultado. Esse modelo ou jeito de trabalhar, o “framework” Scrum, é pensado para que o time seja autônomo e saiba decidir o melhor para entregar o incremento de software ao final da sprint, ou o valor que o cliente espera; e multifuncional, ou seja, que tenha todo o ferramental e skills necessários para fazê-lo, com o mínimo ou nenhuma dependência externa.

O Scrum Guide também diz que esse modelo favorece e aperfeiçoa a flexibilidade para suportar bem as mudanças que virão, a criatividade para encontrar as soluções para os problemas complexos e a produtividade para entregar constantemente pacotes de software prontos para uso.

O Time de Desenvolvimento é formado pelos caras que fazem a mágica do negócio… Transformam requisitos em software, em produto pronto para ser usado. O time precisa ser pequeno o suficiente para se manter ágil e alcançar o consenso, tomando decisões mais rapidamente, e grande o suficiente para ter “braço” que possa entregar software ao final de cada Sprint. Portanto, o Scrum Guide estabeleceu uma linha entre três e nove pessoas. Se temos menos que três é uma dupla, e não um time. E se temos mais de nove a dificuldade para decidir as coisas é maior, precisa de um 2o. turno pra fechar uma questão. Lembrando que essa é uma base de aprendizado, e cada time vai encontrar o seu TAMANHO ÓTIMO.

Algumas palavras resumem o Dev Team ou Time de Desenvolvimento:

Ele decide o COMO. A soma das skills individuais, quando trabalhadas em conjunto, como time, é que os torna MULTIFUNCIONAIS, aquele lance do futebol que falei em outro post. É preciso ter a disponibilidade de todos do time em fazer o merge desses conhecimentos, como forma de mitigar as dependências internas. Por exemplo, no início eu só tenho um QA e um Backend. Com o passar das Sprints e essa vontade de mixar conhecimento dentro do time, eu vou ter mais gente fazendo tarefas de teste, fazendo subidas em ambientes, e por aí vai. Pra ser um time, precisa ser NOTITLE e NOSUBTEAMS, ou seja, não há títulos dentro de um time (QA, BackEnd, FrontEnd, DEVLíder, whatever..), o que há é uma equipe de desenvolvimento que entrega VALOR, only this. Pelo mesmo motivo não existem sub-equipes dentro (como equipe de teste, equipe de back). Por fim, “THE ESTIMATORS”: os membros do Scrum Team são os únicos que mensuram o tamanho do trabalho a ser feito, ninguém mais. O time vai receber deadlines, datas em que aquilo tem valor para o cliente, e isso precisa estar na mesa, na hora da Planning, mas nunca uma ideia de funcionalidade já com a presunção de que fique pronta em duas, quatro ou seis horas de trabalho.

O Product Owner, ou dono do produto, é o cara que precisa saber tudo O QUE precisa ser feito para entregar ao cliente. Ele também MAXIMIZA O VALOR do que vai ser entregue e do trabalho do DEV Team, e faz isso em um artefato Scrum só dele, o Product Backlog. O trabalho constante de detalhar, ordenar e estimar essa lista de coisas a fazer é que permite que o VALOR para o cliente seja entregue de forma constante, a cada incremento de software liberado. Este trabalho, o refinement, é a base do trabalho do PO e é o insumo do qual o Scrum Team se alimenta, mas outras palavras também definem esse cara.

Ele é uma PESSOA. Pode representar um comitê, e muitas vezes o faz, mas é um indivíduo que toma conta e prioriza o que precisa ser feito. Já imaginou três caras brigando para definirem qual feature deve ser feita primeiro? Reduzir complexidade é ter o canal certo para fazer as perguntas. Por isso também temos a premissa de que: um produto = um Backlog de Produto = um Product Owner. Ele tem o PODER pra tomar DECISÃO. A empresa confia no trabalho do PO de concentrar as informações e decidir, dentro do Scrum Team, a ordem do que será feito. Isso leva em conta o VALOR para o cliente, interesses diversos de mercado, concorrência, stakeholders, dependências técnicas e de inovação.

Falando nisso, e corroborando a Annelise Gripp neste artigo, o Dono do Produto é um cara de RELACIONAMENTO, pois ele freneticamente conversa com líderes da organização, com o marketing/vendas, com usuários e clientes e observa a concorrência (todos são stakeholders), além do Dev Team e do SM, para manter o Product Backlog sempre pronto para uso;

Agora #somonozes, os Scrum Masters, os disseminadores dos métodos ágeis como o melhor jeito de trabalhar (framework) para resolver problemas complexos na organização, internamente e para os clientes. Estamos o tempo todo atentos ao DEV Team e sua saúde física, mental, de trabalho, relacionamentos, auto-organização e integração, para produzir bem e com o VALOR adequado para todos os envolvidos. Também olhamos para o PO, ajudando-o com ferramentas, técnicas e ouvido atento, para o que o trabalho de refinement flua da melhor maneira possível e que se consiga o sucesso nas entregas e no resultado para o cliente. Por fim, estamos atentos a toda a organização, buscando levá-la ao lado ágil da força, orientando, capacitando e implementando agilidade em outras áreas de negócio. A Scrum.org cita oito papéis que o SM assume durante o trabalho, dos quais pessoalmente destaco dois que acredito resumirem o que fazemos: somos exterminadores de impedimentos, removendo tudo o que possa atrapalhar o Scrum Team de fazer sua entrega ao final da iteração. Impedimentos podem ser de ordem técnica, comportamental, de relacionamento, pessoal, enfim, precisam ser endereçados e resolvidos. Somos também líderes servidores, e nesse ponto podemos atuar como coach, professor, mentor, facilitador, tudo para que o jeito ágil de se trabalhar mostre a que veio e traga os resultados de entrega.

Enfim, toda essa estrutura, simples de entender, leve e, ao mesmo tempo, difícil de aplicar, só tem sentido se, ao final de cada Sprint, se entregue o que falei 10x nesse texto, e não por acaso: VALOR!

Respondendo às perguntas sobre o Scrum Team:

Quem são: o DEV team, o PO e o SM;

Onde vivem: no mundo todo, e cada vez mais, remotamente;

Do que se alimentam: VALOR!

Seja Ágil!

Ficou alguma dúvida ou tem algo a dizer? Aproveite e deixe um comentário. Quer participar dessas reuniões periódicas sobre agilidade? Saiba mais sobre a Concrete aqui e deixe o seu currículo. Quem sabe o próximo tema a ser debatido não é você quem escolhe? ;) Até a próxima!