Times Scrum – Como facilitar as fases de formação?

Texto por Bianca Pereira

No texto anterior, entendemos um pouco mais a analogia entre o time de scrum e o de futebol (clique para ler). Vimos brevemente como as equipes são compostas e entendemos melhor os papéis que cada um desempenha.

Hoje conversaremos melhor sobre as fases de formação de times e como arbitrá-las até a equipe se estabilizar na partida.

Em 1965, o psicólogo Bruce Tuckman publicou um estudo apresentando as quatro etapas de construção de um grupo e o comportamento das pessoas em cada momento.

Formação e conflito

O primeiro estágio, chamado de “formação”, envolve a apresentação, o entrosamento inicial dos membros, entendimento do “jogo” e reconhecimento das outras posições.

O facilitador ou Scrum Master, analogamente ao juiz da partida, exerce um papel diretivo para equipe, trazendo pontos de atenção relacionados ao objetivo do projeto. É o momento de mostrar as regras do jogo que precisam ser seguidas: prazos, cerimônias do Scrum, objetivos de entregas.

No segundo momento, a equipe tende a entrar na fase de “conflito”.  É quando os ânimos ficam exaltados e a pressão da vitória atinge todos os membros do time. Surgem, então, os carrinhos, os puxões de camisa, as defesas irregulares e o juiz precisa ser mais incisivo em relação às regras.

Alguns times podem tentar evitar essa fase, camuflá-la ou negá-la. Porém, é importante que scrum master ou facilitador do projeto ajude a trazer esses problemas à tona.  Só assim o grupo poderá reconhecer o conflito e chegar a uma solução em conjunto.

Estabilização e desempenho

Depois da tempestade, vem sempre a calmaria e é por isso que após muitas faltas marcadas e cartões distribuídos, os times entram na fase de “normatização”, seguida pela etapa de “desempenho”.

Esse período de estabilidade ocorre porque os membros resolveram os conflitos e passam a reconhecer os pontos fortes uns dos outros, trabalhando com sinergia para suprir as lacunas em direção ao mesmo objetivo.

O juiz continua a exercer um papel de apoio, mas sua interferência torna-se cada vez menos necessária. O time começa a adquirir independência e alta performance.

Uma partida de futebol e projetos de scrum não são eventos lineares. Alguns acontecimentos podem levar times já estabilizados novamente ao conflito. Isso acontece por exemplo, com a entrada e saída de membros, mudança na priorização de entregas, trocas de papéis, discordância de técnicas, entre outras inúmeras situações. Nesse caso, cabe ao juiz ser imparcial e diretivo fazendo valer as regras do jogo visando ao resultado esperado.

Para além da teoria, cada jogo e cada time tem sua particularidade. Imagine-se sendo árbitro de uma disputa entre Flamengo x Macaé ou São Paulo x Portuguesa, parece algo dentro do “roteiro”, certo? Agora, coloque-se como juiz em um jogo entre, por exemplo,  Flamengo x Fluminense, Grêmio x Internacional ou ainda, Palmeiras x Corinthians e algumas outras variáveis entram em questão. Mas isso é papo para outra hora, por hoje, fim de jogo.

Times Scrum – Quem não sonhou em ser um jogador de futebol?

Texto por Bianca Pereira


Todo amante de futebol sabe a importância que faz um time bem estruturado em uma partida. As posições precisam ser estrategicamente definidas e preenchidas com os jogadores responsáveis, é preciso treinar diariamente para evoluir a técnica e, principalmente, o time precisa estar entrosado.

Muitas vezes temos jogadores com muita habilidade em campo, mas se não houver o tal do entrosamento do grupo, nada feito! Então acontecem passes perdidos, bola na trave, bola na área sem ninguém pra cabecear, e daí, o choro é livre.

Quem já trabalhou utilizando o Scrum, sabe que funciona da mesma maneira. Para entregar um projeto baseado nesse framework, a construção de um time colaborativo é essencial. Isso vai além do domínio de técnicas avançadas de desenvolvimento e abrange a capacidade de adaptação, inspeção e transparência da equipe para com o jogo em si.

Para chegar nesse patamar é preciso, claro, muitos treinos, muitos jogos, adversários “fáceis”, aqueles mais complicados, muita falta apitada e alguns cartões pelo caminho.

Papéis do time scrum x time de futebol

Para contar essa história direito, vamos explicar os papéis do Scrum dentro de campo e veremos como os times são formados. 

time2-1

 

Product Owner (Goleiro/Capitão do Time)

A principal função do PO é traduzir os interesses do cliente em valor, priorizar isso de forma assertiva e comunicar o que será ou não feito para o restante da equipe. Como capitão, é ele quem vai motivar as pessoas em relação ao negócio e mostrar o porquê de aquilo estar sendo feito. Além disso, ele também precisa defender o time dos itens que fogem do objetivo a ser entregue.

Na formação de times colaborativos, tanto de futebol quanto de Scrum, essa é uma atribuição fundamental. “Falem um com outro, cobrem um do outro, ajudem um ao outro, queiram ganhar um com o outro” é parte de uma famosa preleção de Rogério Ceni que poderia ser facilmente usada em uma Daily Scrum.

Gosto de fazer a analogia do PO com o goleiro, pois ele é um indivíduo um pouco distinto, joga com os pés, mas sobretudo joga com as mãos e posicionamento. Não tem como jogar sem ele, e dificilmente conseguimos substituí-lo por um jogador de linha.

Time de desenvolvimento (Jogadores de linha)

Colocando um objetivo em comum a ser alcançado em cada caso, desenvolver sistemas pode ser comparado a vestir a camisa e chutar a bola no gol. Veja que nessa situação não há diferenças entre quem desenvolve, quem testa, quem valida requisitos ou quem desenha fluxos, todos buscam o mesmo foco e contribuem de acordo com sua posição em campo.

Scrum Master ou Facilitadores (Juízes)

Os juízes são responsáveis para que a partida aconteça de acordo com as regras do futebol, enquanto o Scrum Master ou Facilitador garante que os princípios do Scrum sejam desenvolvidos no decorrer do jogo. Cabe a ele comunicar esses preceitos da melhor forma e fazer com que a equipe consiga avançar os estágios de formação durante o projeto.

A regra é clara e quando a situação sai do roteiro, ele precisa se posicionar, direcionar a disputa e conduzir os times. Muitas vezes alguns podem achar que árbitros são desnecessários e o melhor seria que sua função não fosse percebida. De certa forma, isso é verdade, porém, são nos jogos complicados que essa figura torna-se fundamental para o desenvolvimento do time e jogo.

Como nem tudo são flores, as equipes podem estar desfalcadas em algumas situações e o time precisa se adaptar para suprir esses hiatos. Defesas são feitas por laterais, gols são marcados por zagueiros. Mas por mais que a equipe passe por uma etapa de conflito, com muito treino, ela consegue se desenvolver e caminhar para melhores resultados.

Formação de times

time1-1

Tanto no futebol quanto no Scrum, a formação de times colaborativos e auto gerenciáveis não é algo simples. Você escolhe os jogadores responsáveis por cada posição, apresenta os outros membros e tudo vai bem, até colocá-los para trabalharem em equipe. 

Em 1995, após ter sido eleito o melhor jogador do mundo, Romário desembarcava na Gávea. Pouco tempo depois era a vez do campeão brasileiro Edmundo e o “melhor ataque do mundo” estava formado. Parecia que o puro talento dos seus jogadores renderia incontáveis títulos ao Flamengo, mas um elenco vitorioso precisa ser um time antes de tudo.

O grupo durou apenas 6 meses apresentando problemas de gestão, estrutura, organização e estilo de jogo. Próprios ex membros da equipe a classificavam como “uma bagunça”. O que deu errado?

Equipes de scrum passam por processos semelhantes, o grande desafio é auxiliar que elas se desenvolvam e atravessem as fases de formação e conflito. Chegar à estabilidade e alto desempenho em um projeto é um desafio diário que requer muito treino. Será que sua equipe está preparada? Falaremos mais disso no nosso próximo post, por hoje, fim de jogo. 

 

Nossas Retrospectivas

Todo mês fazemos as famosas Retrospectivas na Jera. Quando falamos de SCRUM, as retrospectivas acontecem ao término de cada Sprint, fazemos essa também, mas limitada ao time que está trabalhando no projeto. Esse post se trata das retrospectivas envolvendo toda a equipe.

Sempre que penso nesse assunto, me lembro de um artigo do Manuel Pimentel que trata de forma bem prática, se você não está familiarizado com o termo, recomendo a leitura antes de prosseguir.

Mas, na verdade, o conceito de retrospectiva só nos remete a um assunto que é velho conhecido do pessoal de administração, que é o famoso PDCA. O objetivo de ambos é promover melhoria contínua!

Legal, apesar de ser um assunto aparentemente simples, melhoria contínua trata-se de um dos maiores desafios para qualquer empresa ou pessoa. Para melhorar é preciso saber o que não está bom, e para isso é preciso de humildade para entender e aceitar nossos erros.

As retrospectivas da equipe aqui na Jera sempre causam espanto aos que acabaram de começar conosco. A gente sempre segue o princípio da honestidade, sendo que o todos são encorajados a dizer o que estão sentindo, o que está incomodando e claro, o que deu certo.

Só consideramos que isso seja possível graças a ausência de hierarquias e cobranças “comuns” como pontualidade ou qualquer tipo de formalidade no tratamento. Sentir-se à vontade no trabalho para nós é obrigatório e se algo está te impedindo de conseguir isso, a retrospectiva é o momento certo para discutir o ponto.

Foto: Pizza por Haseo

Agile Coaching

Recentemente terminei um trabalho em um cliente* onde ministrei um treinamento sobre gerenciamento ágil de projetos e agora estou fazendo um trabalho de coaching ajudando-os na utilização das técnicas nos projetos. Eles têm uma equipe de cerca de 10 pessoas entre analistas de negócio, DBAs e desenvolvedores. Trabalham também um uma fábrica de software que atende a maioria das solicitações de desenvolvimento.

Inicialmente, para melhorar a visibilidade do processo e conseguir gerar e coletar alguns indicadores, montamos um Kanban contemplando todos os projetos e analistas de negócio responsáveis e organizando as atividades pendentes com os desenvolvedores.

A partir desse trabalho, participo semanalmente da retrospectiva da equipe onde avaliamos os pontos positivos e implementamos novas melhorias. Vou fazer esse trabalho com eles por mais umas cinco semanas com o objetivo de identificar os pontos que precisam ser melhorados em uma nova fase da consultoria.

Disponibilizei todo o material usado no treinamento no meu slideshare organizado por aulas:

  1. Abordagens Ágeis (Parte 1)
  2. Abordagens Ágeis (Parte 2)
  3. Casos de Uso
  4. Histórias do Usuário
  5. Planejamento do Projeto
  6. SCRUM e Kanban

* Infelizmente ainda não posso mencionar o nome do cliente, mas em breve pretendo escrever mais sobre o trabalho.

Review AgileBrazil 2010

Recentemente participei do AgileBrazil 2010 em Porto Alegre, evento que reuniu a galera mais pirada e antenada de desenvolvimento de software do Brasil. A minha expectativa era enorme para ouvir, discutir e ver o que a galera estava utilizando de fato; isso tudo porque tomei vergonha na cara e realmente parei de “só falar” e entrei na “onda” com mais alguns doidos de realmente utilizar esse “negócio de ágil”.

O melhor desse evento sem dúvida nenhuma, foram as pessoas, e não as palestras que rolaram. Muito diferente dos eventos de Linguagem que já fui, a galera estava mesmo muito afim de conversar e trocar idéia sem aquelas famosas panelinhas de eventos de Java, é bacana ver pessoas interessadas sobre questões técnicas do dia-a-dia, e deixando aqueles assuntos toscos (“ahh eu uso XP”, “eu uso Scrum”, “agile é lindo e RUP é uma bosta”, “Java é passado”, …) pra lá.

A galera da Bluesoft vez esse resumo em vídeo sobre o evento.


Agile Brazil 2010 from Bluesoft on Vimeo.

Para não deixar esse post do tamanho do mundo, vou comentar rapidamente sobre o que mais me chamou atenção.

Partipei juntamente com o Adriano Bacha do curso de XP ministrado por  6 pessoas (Bruno Pedroso, Dairton Bassi, Daniel Wildt, Giovanni Bassi, Hugo Corbucci e Renato Willi). Toda essa galera falou sobre execução das técnicas XP através de muito bate-papo e dinâmicas, na parte da manhã fizemos um caixa eletrônico (olha só o resultado do projeto) e a tarde programação em par com constante mudança do piloto através de pomodoro. Esse curso valeu cada centavo (é, eu sou mão de vaca).

Houve um espaço democrático no evento chamado “Open Space” onde qualquer um poderia marcar na programação sobre o que estava afim de debater, no tal horário marcado a galera se reunia; Nós (@adrianobacha, @sauloarruda e eu) marcamos um, mas pelo visto ninguém ficou muito afim e resolvemos ir jogar um pouco de PS3 🙂

Open Space de Jera
Open space de Imersão Ágil

O workshop “Reconheça! Você não sabe modelar! Iniciando Projetos Ágeis” do Rodrigo Yoshima e Phillip Calçado foi muito legal, basicamente partiu-se da idéia prática de 3 elementos fundamentais para modelar: modelo de domínio, navegação entre telas e protótipo de tela; evidentemente que sem o uso de ferramenta, importando-se assim muito mais com o entendimento do problema por parte do cliente e desenvolvedores. Em grupo demos início a um projeto de troca de figurinhas da copa (tô manjando disso).

Os palestrantes internacionais também detonaram, foi a primeira fez do Martin Fowler aqui no Brasil e ele falou ao melhor estilo britânico sobre a essência do ágil, débito técnico; integração e entrega contínua (nós não tiramos nenhuma foto com ele, pois ele não é muito fã disso); David Husman (0 cara) falou de “Produtos e Pessoas sobre Processo e Dogma”, o cara é muito engraçado e pra mim foi uma das melhores palestras do evento.

Agile Brazil
Apresentação do Martin Fowler

O último Keynote, foi com o Klaus (pioneiro na implantação de práticas ágeis no Brasil). Com muito humor e sacadas genias veio para quebrar tudo, aquela idéiazinha chata de falar “mais do mesmo”, sabem né? Então… o cara é doido varrido, o tema era “Learning and Coolness – Beyond XP” e como ele mesmo disse “como alguma coisa pode ser além daquilo que já é extremo?”; a apresentação foi feita no notepad, ele simplesmente “jogou fora” os cinco valores do XP e incluiu Learning e Coolness, traduzido como aprendizado e “ducaralhisse”; além disso falou muito sobre o lance da entrega contínua e direto em produção.

Já estou aguardando o próximo AgileBrazil, porque com certeza eu irei.

<update> Adicionei algumas fotos no meu álbum </update>