Scrum Master, tão simples quanto possível

Olá pessoal. No post de hoje vou falar um pouco do papel do Scrum Master, e vou usar como pano de fundo, o caminho que trilhei.

O Post também vem para cumprir uma Meta, e desde já agradeço ao Mestre Manoel Pimentel.

Hoje é muito debatido qual o verdadeiro papel do Scrum Master, se é necessário, se é desnecessário, se ajuda a promover a auto-organização…

Bem, como sempre, vamos por parte.

Scrum Master é um facilitador que remove impedimentos do Time, e que isso não necessariamente quer dizer que ele seja o único a fazer isto. Eu como Scrum Master sempre busquei auxiliar ao Time como descobrir seus reais problemas, e como combate-los como Time.

Em alguns impedimentos, minha atuação direta como Scrum Master ajudava, pois não precisaria dispender alguém do Time, logo não atrapalha o pessoal. Contudo, toda atuação minha para tirar impedimentos era clara. Eu fazia questão de informar ao Time o que eu fiz, como fiz, com o intuito de transmitir conhecimento.

Porém, alguns impedimentos realmente tinham que ser tirados pelo time. Geralmente conhecimentos técnicos, necessidades de infra que exigiam o conhecimento apurado de alguém para explicar. Nestes casos, eu atuava realmente como facilitador, buscando ajudar ao máximo.

Um Scrum Master tem uma meta básica que é zelar pelos Valores do Scrum, logo os Valores do Manifesto Ágil. Isto é realmente muito difícil e requer experiência.

Quando me foi sugerido ser Scrum Master, que no caso fui indicado pelo pessoal do Time, eu já tinha um bom conhecimento de Métodos Ágeis, porém, não poupei esforços para conhecer mais.

E qual foi a primeira coisa que fiz? Não. Não foi buscar a certificação.

Foi buscar um arsenal de Literatura e Mentoring. Na época a empresa era assistida por um Mentoring, o Felipe Rodrigues. Dezenas de livros amontoaram minha mesa e meu computador, dentre eles:

  • Agile Software Development with Scrum – Ken Schwaber
  • Agile Restrospecitves – Diana Larsen
  • Agile Estimating and Planing – Mike Cohn

Porém, fui mais além disto e quis conhecer as raízes então fui ler:

  • Scrum Papers – Jeff Sutherland
  • The New New Product. Development Game – Hirotaka Takeuchi and Ikujiro Nonaka

Me inundei numa leitura de Posts, tanto dos Gurus externos quanto internos e deixo aqui dois grandes posts do Fabio Akita:

http://akitaonrails.com/2009/12/10/off-topic-voce-nao-entende-nada-de-scrum

http://akitaonrails.com/2010/01/30/off-topic-lendo-os-principios-ageis

Sem falar nos Mentorings e troca de experiência com vários grandes profissionais da nossa área. Mergulhei mais ainda também em participação em eventos, reuniões, grupos de usuários e etc.

Em seguida veio a certificação CSM com o grande Alexande Magno. O processo certificatório pode ser falho, mas a oportunidade de troca de experiência com o Magno foi sensacional.

A atuação de um Scrum Master, zelando pelos Valores do Scrum é simples ou complicado mediante a sua verdade. Não se cria um sentimento de união, um senso de comprometimento e auto gerenciamento num Time de uma hora pra outra.

Cada Time tem sua dinâmica, e isto deve ser somado a realidade de cada Empresa. Como Scrum Master aprendi que melhorias no Time são ótimas mas podem não gerar bons frutos se forem feitas isoladas. Melhorias que buscam impulsionar os Valores Ágeis devem ser feitas em escala Empresarial. Eu tive muita dificuldade nesta parte.

O que acontece com algumas pessoas que atuam como Scrum Master, é que elas passam a achar que estão sempre certas e são Juízes, julgadores do bem e do mal. Eu sempre mantive claro para mim, que eu não era assim. Que como todo profissional eu estava passível de erros e acertos. Logo, eu aprendi com meus próprios erros vendo que quando estava pensando em lutar pelos Valores Ágeis, na verdade eu estava criando um cabo de guerra.

Se todo Scrum Master deve prezar pelos Valores Ágeis então ele deve ser o primeiro a realmente se fazer deles. Eu fazia retrospectivas e buscava melhorias. Quando percebi que minha atuação criava cabo guerra, sentei com todos os envolvidos e busquei dissolver isto.

Hoje, percebo que a atuação de um Scrum Master é tão simples quanto possível, utilizando como sua principal arma o Bom Senso.

Porém, o bom senso é algo relativo e deve levar em conta vários aspectos. Neste ponto, uma literatura me auxiliou muito:

Buscando melhorias, não podia me contentar com melhorias locais e passei a buscar melhorias sistêmicas. Minhas Retrospectivas tomaram outro caminho, onde junto do Time, analisavamos nossos problemas, o que os causavam, os pontos de alavancagem para as melhorias e o que isto impactaria a estrutura como um todo.

Mais uma vez, isto foi algo que eu errei e aprendi como Scrum Master. A grande dica que eu dou a quem exerce este papel é:

Jamais se ache MASTER

A simplicidade me guiou nesta caminhada. Como todo desenvolvedor que busca aprender, como todo analista que deseja conhecimento, eu também como Scrum Master segui o caminho de buscar aprendizado, de fazer, de errar, de aprender.

Eu causei muita polêmica como Scrum Master, gerei muitos embates e hoje vejo que não foi um dos melhores caminho que segui. Porém também vejo o quão o pessoal dos Times que atuei se desenvolveram, o quanto eles entregaram, o quanto estavam felizes. Tudo como um processo simples e natural da vida.

Ser Scum Master é tão simples quanto qualquer outro papel. Você deve buscar sempre conhecer tudo que é tido como fundamental e bom para exercer seu papel, você deve atuar, errar e aprender.

Grandes questões como “Scrum Master pode ajudar na auto gestão”, a respostas não está no papel do Scrum Master, e sim na pessoa que atua nele.

Ter Empatia por todos os envolvidos na dinâmica de desenvolvimento da Empresa, buscar melhorias consistentes e sustentáveis, ser verdadeiro, ter conhecimento podem fazer com que boas coisas aconteçam, independente do papel que a pessoa exerça.

Hoje, posso dizer que por espaços de tempo, eu vi times realmentes auto gerenciados, pude ver Retrospectivas com toda a Estrutura da Empresa envolvida no Produto, pude ver o crescimento de várias pessoas.

Não posso jamais dizer que eu criei Times Auto Gerenciaveis, que tinham total noção do ROI e blá blá blá. Mas posso dizer com certeza que por bons momentos, pude ver coisas feitas da forma certa. Pude ver P.Os discutindo com o Time o real alor das coisas, pude ver Times conseguirem atingir Metas incríveis, pude ver produtos Entregues, pude ver elogios da Gerencia e outras coisas boas.

Para mim, as coisas hoje são tão simples quanto possível. Eu vejo desejos de várias partes, vejo necessidades e oportunidades e busco fazer parte de toda esta dinâmica.

Ambientes que buscam melhorias e se valem dos Valores Ágeis, proporcionam a um Scrum Master ou um Agile Coach auxiliar o pessoal a chegar a grandes feitos. É isso que faço hoje.

Já conheci Scrum Masters que colocavam o nome do papel na assinatura de e-mail, já conheci outros que estimavam pelo Time, conheci outros que não sabiam o que era uma Iteração e outros ainda que não sabiam quem era Ken Schwaber. Por isso que digo que o X da questão não está no papel, está na pessoa.

E você caro amigo, como foram suas experiências como Scrum Master? Ou como o Scrum Master com que você atua é?

[]s.

Aprendendo a andar de bicicleta

Versão resumida do post: Scrum Master’s, deixem as equipes se ralarem um pouco, só cuide para que eles não se matem.

Se você leu e não entendeu, leia o resto do post 😛

Image

Quando somos crianças, ou já adultos, quando vamos aprender a andar de bicicleta, sempre caímos.

Nunca, ninguém aprendeu a andar de bicicleta sem ter ralado um joelho antes, mas mesmo depois que se aprende, continuamos a ralar os joelhos e cotovelos e esse processo é essencial para o nosso aprendizado. Fazemos isso porque estamos testando nossos limites, quando nunca andamos antes, nosso limite é conseguir andar e fazer algumas curvas.

Após esse passo básico, nossos limites vão aumentando, mas continuamos a testá-los e a cada teste continuamos ralando os joelhos e cotovelos, as vezes algo mais. Quando estamos aprendendo a andar, temos sempre alguém nos ajudando a descobrir os limites à serem testados, e ajudando a evitar que a gente se mate nos primeiros 5 minutos em cima da bicicleta.

Em outros momentos da nossa vida passamos pelo mesmo tipo de situação, aprendendo a fazer alguma coisa, testando os nossos limites e com alguém nos ajudando a não nos matarmos. No Scrum eu vejo uma situação dessas principalmente na hora da Sprint Planning.

Na Sprint Planning a equipe deve estimar as estórias e definir com o que eles vão se comprometer na sprint. O SM (Scrum Master) está lá para ajudar a equipe a manter o foco, ver se a equipe está seguindo os “rituais” necessários e, entre outras coisas, a ajudar a equipe não se “matar” com a quantidade de estórias que eles vão colocar na sprint.

Nesse ponto o SM tem que tomar muito cuidado para que ele não “trave”, impedindo que eles testem seus limites e aprendam, uma das maneiras de “travar” a equipe é exigindo que eles sempre entreguem tudo com o que eles se comprometerem, sem dar uma margem para que a equipe erre. Ele tem que saber deixar a equipe testar os seus limites, isso, com certeza, vai gerar alguns ralados, mas assim como quando aprendemos a andar de bicicleta, esses ralados fazem parte do aprendizado, eles nos dizem que naquele momento ultrapassamos nossos limites e que precisamos melhorar em algo antes de descobrirmos novos limites. Mas mesmo assim o SM também tem que tomar cuidado com o outro lado, evitar que a equipe se comprometa com uma quantidade irreal de estórias e se “mate” na sprint.

O conceito essencial para que as coisas funcionem na Sprint Planning é o mesmo conceito fundamental para se andar de bicicleta, equilíbrio. Não é algo fácil, não existe fórmula mágica para calcular isso, esse equilibrio vem da convivência e da conversa entre a equipe e o SM, lembrem-se, assim como quando aprendemos a andar de bicicleta existe alguém nos ajudando a não nos matarmos, essa mesma pessoa nos ajuda a levantar quando caímos, ajuda a curar os nossos ralados, evitando infecções e outras coisas.

Assim tem que ser o SM na Sprint Planning, ajudando a equipe a testar seus limites, ajudando ela a se levantar após um tombo, ajudando a tratar os ralados, mas sem proibir a equipe de andar de bicicleta alegando que é muito perigoso.

Portanto: Scrum Master’s, deixem as equipes se ralarem um pouco, só cuide para que eles não se matem.

Apresentações e materiais

Olá caros amigos.

Tem tempo que já estava querendo fazer isto, agora chegou a hora.

Estou unindo todo o conteúdo que já gerei e deixando os links aqui no blog para mais fácil acesso e divulgação.

Seguem então os slides de algumas palestras, talks, vídeos e fotos das apresentações que fiz e participei. Confira!

Nesta palestra no grupo formado por empresas de TI da Região de Campinas, o SPIN, eu falo sobre as raízes do Scrum, o impacto de sua adoção no ambiente corporativo e algumas dicas para melhorar esta ação.

Nesta palestra realizada no TDC 2011 na trilha de Liderança e Coaching, abordei os princípios da Liderança Servidora, princípios sobre Motivação e os desafios da Motivação em grupo.

Nesta palestra realizada no TDC 2011 na trilha de Agile, abordei sobre a dificuldade da realidade da Filosofia Ágil em um ambiente corporativo bem como hype Ágil prejudicou um pouco esta adoção.

Nesta palestra junto com o Renato Freire realizada no Agile Brazil 2011, abordamos sobre a motivação de ir no Agile Brazil em Porto Alegre, o que nós aprendemos no evento e como utilizamos e disseminamos este conhecimento e sobre nossas conclusões.

Este foi um Lightning Talk que apresentei no Agile Brazil 2011 sobre o Domain Game, um jogo criado para auxiliar na disseminação sobre o domínio de um negócio, sua linguagem e integrar o Time ao Cliente.

Ainda tem o vídeo que fiz para o Conversa Rápida, idealizado pelo Jonas Abreu.

Esta palestra sobre Srcum eu realizei em vários treinamentos, workshops e eventos em faculdades. É uma introdução básica as raízes do Scrum e como ele roda. Além disse, a palestra apresenta de modo irreverente os valores do Scrum

Este painel foi realizado durante o TDC 2011 na trilha de Agile. Nele, vários nomes do Desenvolvimento de Software Ágil do Brasil, como André Nascimento, Dairton Bassi, Giovanni Bassi, Victor Hugo Germano e Rodrigo Yoshima comandados por Felipe Rodrigues, juntamente comigo :O, discutimos sobre o que pode vir depois da Onda Ágil. O vídeo é bem divertido, e como sempre, eu buscando tirar risadas da galera.

Esta apostila eu fiz, com base na minha experiência, no aprendizado prático e através de conhecimento adquirido com vários gurus de Scrum e Agile. A apostila foi revisada por grandes nomes do Scrum no Brasil e eu a utilizo nos meus treinamentos de Scrum.

E isso é tudo pessoal.

Espero que gostem, apreveitem e deem feedback 😀

E aqui vai umas fotos do Rafajagua aprontando ao redor do Globo.

Este slideshow necessita de JavaScript.

[]s.

Analista de Negócios, Analista de Requisitos, Analista de Processos. Preciso ir a uma Analista

Olá caros amigos, tudo certo?

Você vai ter uma overdose da palavra “Análise”, mas siga firme que terá êxito em ler o Post.

Como prometido há algum tempo, hoje vou falar sobre esta miscelânia de papéis que existem na TI referente a Análise.

Esta variedade de papéis costuma fundir a cabeça das recrutadoras do RH nas empresas, costuma causar crise de identidade nos profissionais e mais ainda, costuma causar problemas no projeto se o profissional não souber corretamente qual é o seu papel e o que se espera dele.

Mas afinal, será que Analista de Negócios, Analista de Processos e Analista de Requisitos não é tudo a mesma coisa?

A resposta: Não. Não é tudo a mesma coisa não.

Apesar de ser muito comum o desentendimento sobre cada papel e alguém acabar fazendo os três papéis (ou fazer apenas um e achar que está fazendo todos) no dia-a-dia, cada tipo de análise é sim uma coisa diferente.

Como gosto de fazer, vamos por parte e destrinchar cada um destes papéis:

Primeiro, vamos saber o que é um Analista:

a.na.lis.ta1 adj m+f (gr analystés) Que analisa. s m+f 1 Pessoa que analisa ou é versada em análises. 2 Pessoa cujo ofício é fazer análises das propriedades químicas, físicas ou de outra espécie de uma substância ou produto.

a.na.lis.ta2 adj m+f (lat annale+ista) Relativo ou pertencente a anais ou a quem os escreve. s m+f Pessoa que escreve anais.

O Analista é uma pessoa que tem por carateristícas, a vontade de observar, compreender e descrever a dinâmica de algum produto, processo ou modo de execução. É fundamental para quem exerce este papel ter uma dicção para poder se comunicar de forma clara, ter domínio da escrita, sendo simples na sua forma de descrever porém coeso e acertivo. Um Analista também deve ter em si uma curiosidade natural para sempre procurar saber mais sobre as coisas, como elas se iniciam, como se processam e como passam a diante.

Vamor ver o que é “Negócios”:

By Wikipedia:

Em apertada síntese, podemos dizer que, entende-se por negócio toda e qualquer atividade econômica com o objetivo de gerar lucro.

Etimologicamente, e num sentido mais lato, a palavra negócio deriva do latim, e quer dizer a negação do ócio. Negócio não trata apenas de negócio financeiro ou comercial, mas sim toda a atividade humana que tem efeitos jurídicos

Processos:

By Wikipedia:

Processo deriva do latim procedere, verbo que indica a ação de avançar, ir para frente (pro+cedere)) e é um conjunto sequencial e particular de ações com objetivo comum. Pode ter os mais variados propósitos: criar, inventar, projetar, transformar, produzir, controlar, manter e usar produtos ou sistemas.

Em gerenciamento de processos (também apelidado BPM), o processo de negócio é uma sequência de tarefas (ou atividades) que ao serem executadas transformam insumos em um resultado com valor agregado.

Requisitos:

By Wikipedia:

No âmbito da engenharia, um Requisito consiste da definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender.

O duro trabalho do Analista

Em outras palavras, o Negócio é algo “maior”. Está diretamente ligado as maneiras que a Empresa irá operar para conseguir gerar Lucro.

O Negócio alinha-se com a estratégia da Empresa e leva em consideração objetivos a serem alcançados e os meios que devem ser satisfetios para serem atingidos. A análise do Negócio percorre toda a estrutura da Empresa.

Esta análise é a que vejo menos ser feita nos Projetos de Software. Geralmente o que acontece, é que alguém realiza análise de Processo, ou seja, realiza análise de Gatilhos e Estados iniciais de uma área ou interação de uma área, análise suas ações e suas execuções e por fim análisa as saídas que esta área oferece para suas interações.

Este é o papel do Analista de Processo: analisar os processos que as áreas das Empresas realizam e geram para atingir uma Meta de Negócio.

Basicamente, todo processo tem um Gatilho ou um Estado Inicial. O processo tem sua execução e gera insumos que podem ser gatilhos para outros processos ou estados finais com respostas.

Entenda que o papel do Analista de Processo não é menor do que o Papel do Analista de Negócio, eles apenas estão em esferas diferentes.

Geralmente, uma Empresa já tem suas Metas definidas e buscam através de Projetos ou Produtos conseguir atingi-las. Poucas Empresas eu realmente vi estarem abertas para Análise de seu Negócio para aferir o que realmente um Projeto ou Produto pode fazer por ela.

Isto toma tempo, pode revelar algumas coisas interessantes e até indesejadas, dada a burocrácia e hierarquias da Empresas atuais. Mas posso dizer que o resultado de uma Análise de Negócio é algo realmente muito interessante e bom.

Analisar o Negócio está diretamente ligado em entender todo o ambiente aonde a Empresa se posiciona: O seu Mercado de atuação, sua posição neste mercado, seu histórico, seus concorrentes e etc..

Uma vez tendo a diretriz de negócio madura, pode-se iniciar a análise dos Processos que a Empresa realiza para atingir seus objetivos.

Não quero fazer alusão a Waterfall e mostrar uma sequência obrigatória, mas realmente fica mais fácil analisar o processo tendo uma diretriz de negócio definida, talvez estas duas análises não possam correr em paralelo.

Analisar o Processo requer uma imersão e um acompanhamento próximo no dia-a-dia da Empresa. Não que a Análise de Negócio não requira isto, mas a Análise de Processo se diferencia pelo grau de imersão e proximidade junto as áreas da Empresa, o dia-a-dia mesmo.

Analisar o Processo vai de encontro a entender os “mini objetivos” que as áreas da Empresa tem, analisar a interação entre elas e ver o quão isto se alinha ao objetivo da Empresa.

Os processos buscam satisfazer alguns requisitos e eles mesmo são compostos de algumas regras. Aqui entra o chapéu do Analista de Requisitos.

A Análise de Negócio gera Requisitos de Negócios a serem satisfeitos. A Análise de Requisitos trabalha diretamente para entende-los e ver suas partes na execuções dos processos. Compreender aonde cada requisito é requerido, processado e satisfeito.

Está no trabalho do Analista de Requisitos ser capaz de descrever e validar os requisitos da solução que foram iniciados na Análise do Negócio.

Não quero aqui gerar links profundos entre uma Engenharia de Requisitos, falar em tipos de documentos, técnicas, linguagens de modelagem com o conceito geral da Análise de Requisitos. Que seja livre de quem estiver exercendo este papel escolher as melhores ferramentas para atingir seus objetivos segundo sua realidade.

Mas, basicamente, temos uma “Cebola” com três camadas que demonstram a atuação de cada papel:

A Cebola da Análise

Dentro de um Processo Ágil, estas fase podem (e devem??) ser sobrepostas, o que faz com que a pessoa que irá realizar este trabalho assuma os chapéus de cada Analista em diferentes momentos ao longo do Projeto.

Este dinamismo da troca do chapéu ajuda a causar o desentendimento de cada papel em específico.

Segundo o IIBA, todo este processo de análise pode estar contido no papel do Analista de Negócios. Eu particularmente discordo um pouco, por achar que quem é capaz de fazer isso ou é o Super Homem ou é Louco e também por ver objetivos e características mais específicos para cada perfil de Analista.

Conheço grandes Analista de Requisitos que não têm muito o perfil de estar com uma Junta Diretora de uma Empresa e ser capaz de abstrair os obejtivos de Negócio e ser capaz de compreender a complexidade do Mercado, porém é extremamente habilidoso no mapeamento, modelagem e descrição dos requisitos.

Talvez seja uma questão de experiência, talvez seja uma questão de aprendizado, mas acho que cada Analista tem sim seu perfil mais adequado.

E você, discorda? Concorda? Acredita que todos estes papéis são sim uma coisa única em tempos diferentes? Ou que esses papéis são realmente diferentes mas possíveis de ser feito por uma única pessoa?

Expresse sua opinião.

[]s.

2012 Um grande ano, grandes eventos, grandes oportunidades

Olá caros amigos, tudo bom?

Antes de dar sequência a mais um post “técnico” eu gostaria de compartilhar com vocês as minhas expectativas para este ano que já se iniciou.

2012 se mostra bem propício a grandes realizações e acredito que gerará ótimos frutos.

No âmbito de eventos, eu participo da organiação de dois eventos bem “iguais e diferentes” ao mesmo tempo.

Junto com grandes nomes da TI brasileira, eu participo da organização do Agile Brazil 21012, nada mais nada menos que o maior evento sobre Metódos Ágeis do Brasil, que neste ano será realizado em São Paulo. O evento promete ser grandioso, tanto em tamanho, quanto na sua qualidade. Fique atento na hashtag do twitter #AgileBR e acompanhe as últimas novidades sobre o evento.

Este ano também, estou na organização da segunda edição do Caipira Ágil, um evento para disseminarmos a Filosofia Ágil no interior paulista. A segunda edição também acontecerá na Unicamp. Acompanhe no twitter o @caipiraagil para saber mais novidades sobre o evento.

E com certeza, outros eventos como o TDC 2012, Agile Vale, vão trazer um grande conteúdo para todos os amantes da nossa área de TI.

O ano também se mostra muito promissor no âmbito profissional. Atuando numa grande empresa, um grande produto e com uma missão valiosa, estou bem empolgado para os desafios que virão. Tendo evoluido bastante (mas sempre com vontade de evoluir mais) em conhecimentos sobre Metódos e técnicas ágeis, me volto agora para área de Análise de Negócios, Processos e Testes.

Um estudo bem aprofundado, com aplicações desafiadoras são o meu futuro neste ano. Ser um Analista de Negócios é algo grande, que requer um poder de análise, abstração e comunicação muito potente. Realizar análise de Processos requer perspicácia, visão e aprendizado rápido.

Bem como, aprofundar em conceitos e práticas de testes, requer muito pensamento e atenção.

Estes novos caminhos trazem oportunidades gigantescas para aprendizado e vou procurar sempre compartilhar este desafio aqui no blog.

E você? O que lhe espera neste ano? Está preparado?

[]s galera.