Certificado da Scrum Alliance

Semana passada recebi meu login da Scrum Alliance... muita emoção quando eu vi aquele e-mail na minha caixa postal :)

Agora mais do que nunca é fazer valer este certificado!!!

Time Box e Sprint Planning

Hoje passei por uma experiência que provou muita coisa a respeito de Time Box na hora de executar o Sprint Planning.

O que aconteceu foi o seguinte: Precisávamos especificar algumas ferramentas para nosso projeto, cada uma destas ferramentas seriam um Product Backlog e então entramos na reunião com o Product Owner, que veio com alguns 'cartões de estória' para cada um destes, e dai retiraríamos então nossos Sprint Backlogs. Já partindo do pressuposto que nossa Sprint teria o Time Box de duas semanas, começamos a ver o primeiro Product Backlog, já priorizado pelo PO.

Começamos a ler cada um dos 'cartões de estória' e tirar nossas dúvidas com o PO, em seguida resolvemos levantar os pontos, que por sugestão do gestor acabou sendo visto em dias, logo vimos que o primeiro item já seria o suficiente para ocupar a nossa Sprint, com uma certa possibilidade (baixa) de sobrar tempo e podermos então pegarmos um novo item. Apesar de avisado sobre isso o gestor resolveu que deveríamos ver todos os outros itens de backlog que o PO já havia feito os 'cartões de estória', mesmo após a argumentação que este conhecimento muito provavelmente seria perdido durante o tempo decorrido, nosso gerente argumentou que deveríamos ver, pois haviam itens que se repetiam nos itens de backlog e isso poderia nos ajudar a ter a visão de criar "dispositivos reutilizáveis".

Bom, mesmo descordando (eu) seguimos (toda equipe) em frente. Gastamos 2,5H pela manhã e 1,5H na parte da tarde. Isso basicamente conversando com o PO e discutindo algumas coisas técnicas com a equipe. Depois disso tudo claro que devíamos ainda analisar os itens vistos e separar em tarefas pequenas que não tivesse mais de 2 dias de trabalho, nesta parte estávamos só nós sem o PO e o gerente. Vimos tudo que foi levantado distribuímos os pontos nas tarefas e então obtivemos a visão de tudo que teríamos que fazer nos próximos dias, como de costume... muuuuito trabalho! :)

Vamos apontar o que esteve errado nisso tudo:

1º - O time box foi totalmente desrespeitado. Partindo do princípio que no Sprint Planning devemos levantar os itens que serão 'atacados' durante a sprint e logo definirmos seus pontos de esforço. Ou seja, deveríamos usar as 4Hs para fazer tudo isso e não perder quase o dia todo em reunião.

2º - Ao vermos tantos Products Backlogs no mesmo dia, quando fomos levantar as tarefas, toda a equipe estava confusa com alguns requisitos de um item para outro. Claro que excesso de informação pode ser prejudicial ehehe

3º - Se um novo integrante entrar na equipe ele vai ter que tirar todas as suas dúvidas com os membros da equipe e com o PO, é claro, mas deixou de ter todo aquele Brain Storn do Sprint Planning. Ou seja acabou lembrando Waterfall!

4º - Reuniões demoradas e sem pausa causam um certa fadiga onde gera falta de atenção e comprometimento dos envolvidos. Desta forma deveríamos ter tido uma leve pausa no período da manhã.

O que eu vejo que deveria ter sido feito:

1º - Para atender o gerente o Scrum Master devería ter analisado o documentos juntamente com o gerente e o PO (se possível), afim de ter a visibilidade dos itens a seguir conforme o solicitado. Isto é possível porque o Scrum Master (eu) possui um perfil técnico que faz parte da equipe como arquiteto/desenvolvedor e ainda conhece do negócio (praticamente um severino). Desta forma o Scrum Master poderia passar para a equipe um visão do que ocorreria nos próximos passos que poderia ser reaproveitado.

2º - Deveria ter sido respeitado o Scrum e feito da maneira correta: 4Hs para toda a Sprint Planning, pois o Time Box é algo que o Scrum bate muito forte para que seja seguido a risca.

3º - Tentar tirar dúvidas técnicas entre a equipe junto com o PO pode ser bem desastroso e tomar o tempo precioso dele. Acho que o PO deve participar de forma bem ativa, mas só até o time ter todo o entendimento do negócio, depois o PO pode ser dispensado e a equipe parte para a divisão das tarefas e devida pontuação, claro que em determinados momentos pode haver dúvidas que devem ser tiradas com o PO.

Por fim, nós acabamos tendo todo este trabalho, creio eu, pelo fato do PO tirar férias daqui a uns 50 dias e por isso o gerente quis adiantar as coisas, mas acabou dando um pouco errado. Penso que o Scrum foi elaborado para ser seguido e algumas de suas partes adaptadas, mas não tudo.

Ainda precisamos arrumar uma solução para esta falta no PO em determinada parte do projeto, pois desta forma perdemos um dos pontos fortes do Scrum que é ter o PO o mais junto da equipe o possível.

Abraços!

Curso CSM com Alexandre Magno (final)

Com toda a empolgação do mundo fui para última parte do curso. Tive que correr um pouco na hora do almoço para poder almoçar, tomar um banho e fazer o checkout do hotel, que me permitiu ficar aqui na recepção até a hora de eu partir de Porto Alegre.

Antes de mais nada, CSM significa Certified Scrum Master e não Curso de Scrum Master... por favor!!! ehehehe 

Na ultima parte do curso tivemos uma verdadeira aula de como escrever User Story, identificar épicos, divisão de tarefas e tudo acompanhado de exercícios práticos. Aliás o estilo do curso foi todo assim vários exercícios e muitos cases para ilustrar e dar um rumo. Vimos também como é possível aumentar a velocidade da equipe adicionando mais membros na equipe, devido ao processo ser interativo... ou seja adeus waterfall!

Outro ponto bacana foram explicações simples de porque não existe uma relação direta entre pontos e horas, as vezes coisas tão básicas como: O sapato numero 40 equivale a quantos cm? Resposta: depende do fabricante! E isso é óbvio não é? Então porque fazer relação entre pontos e horas? ehehehe A quebra de paradigmas é sem dúvida uma dos grandes problemas e outro que é seu complemento é a cultura das pessoas :)

Para fechar o curso... mais um atividade :0) 

E não daria para esperar menos. Foi feito um exercício de Scrum escalável!!! Quatro equipes trabalhando no mesmo projeto, como se fosse uma em cada país. Cada uma possuía seu quadro (Kanban) com seu Scrum Master. 

A tarefa: Ken Schwaber falando o seguinte: "O exército dos Waterfall Wolves" baniu nossos CST`s das principais cidade do mundo. Agora precisamos nos organizar em uma cidade que proporcione um ambiente familiar de trabalho e lazer para todos os Scrummers do mundo. Precisamos construir a Scrumland!", claro que isso é fantasia e o Ken Schwaber não disse isso!

Em cima disto recebemos itens de backlog para fazermos e logo estes foram divididos entre as equipes. 10 minutos para Sprint Planning... itens devidamente priorizados partimos para identificação das tarefas, tendo em vista que teríamos uma sprint de dois dias de 10 minutos e um Daily Meeting de 2 minutos. Ficamos responsáveis por construir a biblioteca e uma loja de post-its... e tínhamos que realmente montar isso tudo e resistir aos testes de qualidade do Product Owner (petelecos nos prédios).

Após o daily, fomos fazer um Scrum of Scrum para sincronizar as equipes onde foi possível identificar gargalo na minha equipe e folga em outra, logo combinamos de ter uma cooperação dos membros ociosos.

No final atingimos o meta estipulada pelo PO!!!

Daqui para frente é aprofundar ainda mais em Agile e Scrum!!!!

Curso CSM com Alexandre Magno (parte 3)

Hoje na terceira parte do curso foi só Scrum. :)

Nesta terceira parte foram desmistificados cada um dos papeis dentro do Scrum. Claro que como em todas as conversas sobre papeis o mais evidenciado foi o do Scrum Master :P

Entramos na famosa discussão sobre ter um Scrum Master que realiza tarefas técnicas dentro da equipe, tal como o que eu faço hoje, sendo Arquiteto, Desenvolvedor e Scrum Master. Foi bom escutar de um profissional bem gabaritado que isso é meio furado, já que em vários momentos eu vou acabar gerando um impedimento na minha tarefa 'técnica' por estar resolvendo coisas da equipe. Espero que com isso eu também não seja afastado do Scrum e sim focado :)

Chegamos numa conclusão muito boa sobre isso tudo, que seria: É ótimo ter um Scrum Master com o pé firme no desenvolvimento pois ele pode ter visão da próxima Sprint e começar a levantar pontos que podem ser críticos para ela e então já tomar medidas para a prevenção. Mas este Scrum Master deve se ater a isto, no mais deve executar seu papel com qualidade, para que o processo seja garantido, para que a equipe esteja realmente protegida, entre outras. O que pode ser feito e isso é uma prática do Scrum é: Terminou suas todas as tarefas que você deve fazer, não tem outras? Então vá ajudar quem precisa! Go Team!!! Ai sim o Scrum Master vai ajudar o desenvolvimento de uma maneira sadia sem fazer com que ele tenha que ser o famoso Jedi!

Outra coisa que foi bem lembrada é que o Product Owner, precisa ser muito bem treinado para que ele saiba transmitir ao time o que o cliente deseja, de maneira clara com uma linguagem única. O que me faz lembrar la da empresa onde trabalho que acabamos tendo um PO por projeto e que muitas vezes complica, pois é mais um trabalho para demonstrar como tudo funciona para que ele entenda como priorizar o backlog e tudo mais. O ideal segundo discussões no curso é termos um único PO que atende os clientes dos mais variados projetos, claro que se o número de projetos for tão grande que o PO não esteja conseguindo desempenhar suas atividades deve haver mais um e então uma divisão destes projetos para cada. Isso seria incrível, ganharíamos uma velocidade com o levantamento das necessidade ou requisitos e ainda poderíamos ter User Stories vindos praticamente prontos do PO.

Tiveram outros pontos apresentados e muita colaboração de todos com várias explicações e casos de sucesso aplicados pelo Alexandre, citando empresas com a Gol.

Logo publico a última parte do evento.

Curso CSM com Alexandre Magno (parte 2)

Depois do famoso almoço executivo :P

Voltamos para o curso e ai sim entramos no processo do Scrum. Cada um dos itens foi passado, superficialmente, e discutido amplamente até que todos estivessem com suas dúvidas sanadas. Isso eu achei muito legal, porque eu já tinha ouvido falar que no curso seria passado como o processo era e pronto. Já neste a única coisa que foi dita é "evitem tentar ficar tirando apenas dúvidas sobre seus problemas ou da sua empresa e tentem absorver o que é o Scrum e o que ele se presta em resolver". Acho que foi mais ou menos isso que o Alexandre falou. O mais bacana foi ver que eu não sou o único a ter este conceito, porque eu sempre entendi sala de aula como isso! :)

Após tudo isso executamos o famoso Scrum 59! Nele nos foi passada a tarefa de construir um 'Flyer', para um Spa de Cães. Executamos de uma forma rápida (59 minutos) praticamente todos os processos do Scrum, lógico que nesta etapa os participantes ainda não tem noções completas sobre como executar o Scrum, mas a intenção era esta! A de acertar errando. Isso porque o ser humano aprende mais errando, é claro! 

É interessante participar novamente de um simples processo onde você se força a trabalhar com outras pessoas que nunca viu na vida e mesmo assim pode ver as coisas funcionando bem em pouco tempo.

Contamos também com a participação do Daniel Wildt da Dell aqui de Porto Alegre (onde estou no momento), que enriqueceu os debates varias vezes com cases e experiências profissionais.

Lamento apenas não poder ficar para o evento de quarta feira sobre Agile. Mas existem coisas mais importantes como a família :)

Amanhã continuo blogando sobre o evento.

 

Curso CSM com Alexandre Magno (parte 1)

Hoje as 09:05 começou o treinamento ministrado pelo Alexandre Magno (CST) da Caelum.

Na primeira parte vimos pouco sobre o que fala o Scrum, mas tivemos uma base excelente sobre método Interativo e Waterfall, onde ele demonstrou que uma das principais razões do Scrum ser de difícil implantação, é por causa da forma interativa de trabalho, que as pessoas custam a entender. Isso tudo claro devido a anos trabalhando com o modelo waterfall. 

O que achei legal foi um fato que ocorreu com ele tentando mostrar isso a um amigo. Ele disse ao amigo que havia encontrado uma maneira de executar Scrum usando Waterfall e então o amigo começou a identificar os mais variados artefatos usados pelo Scrum, dizendo então que daquele forma o Scrum funcionaria e que ele conseguiria ter várias práticas em cada uma das iterações. Lógico que isso foi só uma jogada para que o citado amigo identificasse que o problema na verdade era a quebra de paradigma e que pudesse compreender aquela mudança.

Toda esta primeira parte tivemos muita interação entre os participantes, formando 3 equipes de 4 integrantes e mais uma de 5. 

Demonstrações de métodos ágeis, com atividades, que nos fizeram ter real noção de como a distribuição de tarefas e responsabilidades podem nos ajudar na execução do projeto.

Em fim logo nesta primeira parte tivemos muito sobre agile, gestão, etc. Sem quebra pau sobre PMP, RUP e outros.. o que me deixou mais feliz, porque ficou algo  muito tranquilo e legal de assistir e aprender.

Ahhh e para que acha que é só ficar dentro da sala e pronto.. se engana o próprio Alexandre já falou que se não demonstrar que absorveu, não leva o CSM e ele já fez isso com algumas pessoas :)

Abraços!

O que o cliente paga é aquilo que recebe?

No final de semana passada passei um micro curso, talvez até mesmo um simples overview. Por incrível que pareça isso foi feito para meu cunhado que é fã do PMI, eheheh.

Passamos por todas as etapas de execução de um projeto, sempre com exemplos e tentando encaixar os conceitos no dia-a-dia dele de gerente de projetos. Bom.. conversa vai, conversa vem e lembrei de um desenho que representa um grande paradigma do desenvolvimento e gestão de projetos.

Este desenho é um espelho da realidade, vou passar meu ponto de vista para cada um dos quadros.

Como o cliente explicou: O cliente quando explica o que quer tenta passar uma visão de algo inovador, grande ou diferente, onde nem sempre condiz com a realidade ou com requisitos técnicos.

Como o líder de projeto entendeu: Uma única pessoa (líder) conversou com o cliente (etapa anterior), coisa que não ocorre com o Scrum onde toda a equipe vai conversar com o Product Owner. Bom um único entendimento e passado adiante, gera um ruído considerável.

Como o analista planejou: Quando o analista recebeu os requisitos do líder e tentou atender as especificações e limitações, ele acaba planejando algo em cima do que compreendeu, ou seja, mais ruído.

Como o programador codificou: O programador recebe do analista o que deve fazer, mas também tem sua interpretação e novamente ruídos. Então ele codifica com todos os requisitos levantados, porém pode ser que não funcione com o esperado.

O que os beta testers receberam: Os testadores das primeiras releases do sistema receberam algo que pouco condizia com o produto esperado e logo irão fazer testes em algo que não está funcionando corretamente, pelo menos não como deveria.

Como o consultor de negócios descreveu: O vendedor faz sempre o produto parecer mais do que é, muitas vezes passando uma falsa visão de como será o produto.

Valor que o cliente pagou: Quando um projeto é feito, sabemos os riscos e o quanto de trabalho teremos, logo conhecemos também as tradicionais falhas e tudo isso é levado em conta, sendo assim este valor é repassado ao cliente, onde muitas vezes ele paga muito mais do que seria realmente preciso. 
Como o projeto foi documentado: Lembre sempre, Agile não é ausência de documentação é sim ter somente a documentação que é necessária e agrega valor após o projeto.

O que a assistência técnica instalou: Se for instalar algo para o cliente, entregue algo funcional. É isso que diz a metodologia e o bom senso é claro, afinal ninguém quer ser enrrolado.

Quando foi entregue: Lógico que atrasos acontecem, mas estamos sempre tentando entregar em dia, muito atraso desgasta a equipe a a imagem da empresa com o cliente.

O que o cliente realmente necessitava: Sempre, eu repito SEMPRE, que o cliente especifica um produto o que ele realmente precisava era algo muito menor e mais simples.

Agora se tivéssemos usado um dos princípios básicos do Scrum que é levar toda a equipe para conversar e tirar as dúvidas com o cliente (product owner), não teríamos mais excessos ou deturpações de requisitos durante o processo de construção do produto. Se resolvêssemos esta parte já teríamos uma grande economia para o cliente, deixaríamos ele mais satisfeito e pouparíamos a equipe, podendo ainda receber novos projetos em um menor período de tempo.

Abraços!

Como levantar os requisitos do sistema?

Geralmente quem vem das metodologias tradicionais, tende a dizer que não é possível iniciar um projeto sem ter certeza de tudo que todos os requisitos serão levantados, pois precisam ter uma visão do todo. 

Devemos nos questionar sobre o seguinte: Ter visão do todo significa conhecer todos os itens no maior nível de detalhes? É preciso desenhar milhões de UML, prototipar telas, escrever, escrever, escrever....?

Ainda ontem, vi o desenho da monalisa (mais uma vez) e me lembrei disso... Eu estou vendo como será o produto só não sei ainda os pequenos detalhes! Lógico que muitas pessoas vão dizer que pequenos detalhes fazem a grande diferença! E fazem mesmo, mas fazem tanta diferença que são mudados o tempo todo, então para que perder tempo com algo que será mudado o tempo todo? Devemos trabalhar junto ao Product Owner (cliente), fazendo entregas constantes mostrando como está ficando o produto que ele quer, pois cada detalhe que precisar ser ajustado, será muito mais fácil se ele ainda não estiver 100% completo.

Pensando em coisas mais concretas do que software, pense no seguinte: Você vai construir uma nova parede em sua casa. Você ao pedreio que quer uma parede 2x2 e diz que vai ter 2 tomadas nela, dividas igualmente neste espaço. Bom muito simples, mas pense que enquanto ele está fazendo a parede vc foi comprar aquele super sofá, quando ele terminou vc colocou o sofá no lugar e viu que ele tampou as duas tomadas! Agora é tarde, para alterar os locais destas tomadas você vai pagar um alto custo (e se encomodar).

Se você estivesse partindo de princípio ágeis (Scrum), você teria visto como estaria ficando cada entrega da parede, e quando o pedreiro estivesse mostrando a parede sem acabamento (reboco) mas com as tomadas, você viria que estavam erradas e pediria para reposicionar. Sairia muito mais barato e vc não teria grandes dores de cabeça.

Esta é a ideia de trabalhar utilizando Scrum. Entregas constantes mostrando ao cliente como o produto está ficando. Você conhece o todo, mas não precisa de muitas especificidades, não precisa fazer trabalho que não será de grande valor agregado. Claro que existem documentações importantes e nós termos várias! Mas vamos deixar isto para outros posts.

Abraços!

Vou ser PAPAI!!!!

É isso mesmo!!!

Vou ser papai! Descobrimos hoje as 13:15.

Grande abraço a todos, porque agora eu vou é comemorar!

O que é trabalhar de forma ágil (Agile)?

Hoje um colega me fez esta pergunta. Na verdade a pergunta não foi bem essa, mas de forma sucinta foi isso. Claro que antes veio todo o cerco por volta de trabalhar usando Scrum, quadro com post-its e tudo mais.

Respondi que trabalhar de forma ágil, usando Scrum, era basicamente cortar as 'gorduras' ou formalismos existentes no dia-a-dia tradicional e que não agregam valor no fim do projeto e ainda entregar partes funcionais do produto antes de ter concluído ele por completo dando visibilidade ao cliente.

Exemplifiquei da seguinte forma: Imagine algo simples como fazer uma banqueta de madeira... no método tradicional eu farias vários desenhos até que um deles agradasse a você, quando estivesse com isso concluído, faria um projeto definitivo da banqueta com medidas precisas, desenhado no autocad e tudo mais que tivesse direito. Agora pare um instante e pense: Para você aprovar um dos desenhos lá se foi um dia por exemplo, para eu passar para o projeto definitivo e autocad, mais um dia. Até agora você não sabe como será a banqueta de verdade, e o pior é que ela nem começou a ser produzida! Este passo de produção seria dado logo após a sua aprovação final do meu projeto no autocad (ehehe). Ai você pensa 'Maravilha! Aprovei o projeto agora é só esperar chegar!'. Em termos seria isso, mas quando chegar você pode ser altamente feliz ou dizer que aquilo que foi materializado a partir de sua ideia, não era bem da maneira que você queria (o que é muito comum) e faz sugestões e ajustes e insere coisas novas como um apoio de pé... e por ai vai.

Agora analisando esta situação temos três equipes distintas: dono do produto, analista/arquiteto e produção. Cada um aqui com tarefas bem distintas, certo? Bom, por isso eles precisam trabalhar tão longe? Não! E isso que a visão ágil vai fazer colar os integrantes juntos nos momentos necessários. Este mesmo processo da banqueta na visão ágil ficaria assim: Você me diz mais ou menos como quer sua banqueta, então produzimos um pé dela, 3Hs depois de termos conversado você estará vendo este pé e ai já pode dizer se quer mudar algo nele, se quiser.. nós já mudamos e enquanto isso a equipe de produção está trabalhando no tampo que é mostrado em 5Hs após a nossa conversa e já com um pé montado com as mudanças solicitadas! Então se tiver algo mais a ser modificado, novamente, mudamos e com estas informações a equipe já está mudando e terminando os outros pés, que no fim do dia você está vendo a sua banqueta quase que totalmente pronta! Faltando detalhes que você ainda pode opinar para ter o produto que você tanto quer! Ou seja no final de 1,5 dias você vai ter sua banqueta como você queria!

Conclusão: Economizamos tempo, pessoas, dinheiro e ainda saímos muito satisfeitos! Pese nisso na modelo tradicional você gastou 2 dias só planejando e com Agile (Scrum) você teve o produto em 3/4 deste tempo!!!

Isso é processo ágil! Isso é pensar ágil! E por fim... o Scrum vai te ajudar e muito com isso.

Pense nisso ;)

Daily Meeting caindo no esquecimento?

Antes de mais nada preciso agradecer ao meu amigo Abu, que me apresentou Scrum e me fez voltar a querer partir novamente para o lado gerêncial, mostrando com é possível gerênciar e estar inserido na equipe, podendo acompanhar bem de perto o trabalho e entender seus desafios de perto, sem ser aquele cara que olha todos de cima para baixo e simplesmente manda executar o trabalho. Grande abraço amigo!!!

Uma das coisas que costumam deixar de funcionar no processo do Scrum é o Daily Meeting!
E por qual motivo isso deixa de funcionar? Geralmente porque as pessoas acabam ficando cansadas, de todo o dia sair de seus locais de trabalho (quando preciso), e ficarem todos de pé para ficar lembrando o que fizeram no dia anterior, o que pretende fazer hoje e se há ainda algo que esteja impedindo suas tarefas.
Agora vamos refletir sobre tudo isso... ficar de pé a princípio é para termos uma reunião breve e objetiva, sem perdermos muito tempo. Isso até pode funcionar, mas não garante nada! O processo tem que ser moldado conforme o perfil do time. De que adianta ter os integrantes ali de saco cheio porque tem que ficar de pé? A reunião será tão objetiva quanto os integrantes do time desejarem, claro que o Scrum Master pode pedir foco quando achar necessário. Mas veja pelo meu caso, já ministrei muitas aulas então falar de pé não é problema! EHEHEH Os integrantes do meu grupo optaram por cada um tomar suas posições, ou seja, quem desejar permanecer de pé, ótimo, quem não quiser pode ficar sentado, e isso não muda em nada o quão produtiva será o Daily Meeting.
Agora os demais itens: O que foi feito no dia anterior, o que será feito hoje e quais o impedimentos, são os famosos 'maus necessários', pois eles permitem não só ao Scrum Master, mas toda a equipe ter uma visibilidade do que está acontecendo e como o projeto está andando, além de ser um grande momento de troca de experiências onde é possível que um integrante se comprometa em ajudar outro caso já tenha alguma experiência favorável. Neste momento o Scrum Master precisa ficar atento para que não comece uma troca de informações ávidas em que faça todo o grupo ficar observando aquela conversa ou ainda virar um verdadeiro brainstorm! Uma boa maneira de sempre lembrar o que foi e será feito é olhar o quadro de acompanhamento com os post-its. Ao contrário do que muitos pensam aquilo lá não é só para mostrar que o time está fazendo algo, é sim uma grande ferramenta de visão para todo o time.

A melhor dica que se pode ter é: Não deixe de fazer se quer um dia o Daily Meeting, pois, a equipe tende a cair na preguiça por esta perda.

Abraços!

Tabalhar sem parar. Vício ou necessidade?

Hoje estava lendo uma reportagem (revista Mercado Brasil ago/08), a respeito de pessoas consideradas 'Workaholics'.
Este termo proveniente da língua inglesa remete a indivíduos que possuem uma espécie de vício em seus trabalhos. Podemos citar como exemplo alguém que trabalhe umas 12Hs por dia e chegue em casa e por um impulso quase que incontrolável, resolve voltar a trabalhar mesmo que de casa. Trabalhando remotamente ou rascunhando possíveis soluções para os problemas encontrados durante o dia. Trabalhadores incansáveis que muitas vezes buscam a perfeição em suas atividades, podem ser estes considerados Workaholics.
Por um lado estes podem ser considerados ótimos funcionários, pois se demonstram muito interessados pelos problemas da empresa e os faz quase que pessoais. Porém, por outro lado isso pode acarretar grandes níveis de estresse ao funcionário, tornando-o pouco produtivo e outras vezes passando seus problemas para o restante da equipe. Ou seja você pode acabar com uma equipe caso tenha um Workaholic que passe seu estresse (não detectado) para os demais. Claro que existem exceções, onde os Workaholics são considerados verdadeiros 'estimulantes' para os demais membros, mas isto varia de cada indivíduo.

O Scrum Master da equipe deve estar atento não só ao andamento de itens de backlog, planilhas, acompanhamento do processo, etc. Mas também aos integrantes do time que devem possuir uma boa sinergia, para que este seja realmente um time e não um amontoado de pessoas que realiza uma tarefa.
Este tipo de 'leitura' pode ser adquirido todos os dias no Dayli Meeting, e durante o dia-a-dia é claro, mas principalmente no Dayli Meeting que é o momento onde o Scrum Master pode perceber alterações de humor, cansaços aparentes e até descontentamentos com papeis. Agile não pode ser só o processo de execução, mas também a velocidade em que as coisas podem mudar e impactar no projeto. Se o Scrum Master não for hábil o suficiente para identificar problemas com a equipe e resolve-los rapidamente podemos ter um bom atraso em uma Sprint que irá impactar nas outras demais.
Muitas vezes uma simples troca de papel dentro de uma equipe faz dois integrantes ficarem muito mais satisfeitos e com uma boa elevação na auto estima. Pense nisso, Agile é todo o processo e os famosos 'porcos' são praticamente a essência do processo, o Scrum Master é meramente a pessoa que garante todo o processo (um trabalhão eu concordo) e isso inclui as pessoas. Então o quanto mais ágil for a tomada de decisão e a identificação dos problemas, mais eficaz e FELIZ será a equipe e consequentemente o Product Owner.

Abraços!