Sobre Agile Coach

Agile Coach é basicamente um profissional com conhecimento e experiência em ágil, que tem por objetivo implantar, disseminar, adaptar e ser o agente da mudança no ambiente em que estiver inserido.

Um Agile Coach é muito mais que um Scrum Master, ele tem que ter a capacidade de inspirar e influenciar, pensando sempre no desenvolvimento das pessoas e dos times.

Além da experiência e essa capacidade de coaching, é importante que um Agile coaching tenha uma formação formal para que suas próprias capacidades de influenciar e inspirar sejam remodeladas.

Para me preparar de forma correta e massificar em minha mente está nova possibilidade, desde 2017 criei apartir do meu conhecimento, experiências e necessidades um cronograma de formações para executar durante 2018. Está formação para qualificação como Agile Coach está completa com a certificação de Coaching do expecional Adriano Sugimoto.

Somente realizar alguns cursos específicos não é o suficiente para estar apto, se exige toda uma mudança cultural, pessoal e profissional que você deve trabalhar continuamente.

Na minha visão, um Agile Coach deve procurar mais que o trabalho de disseminação do Agile, deve ser uma busca pessoal para que as pessoas se sintam bem implementando as práticas que mais se adaptam a realidade delas. É estudar e identificar metodologias que dentro desta realidade, Agile ou não, possam ser melhoradas.

Papéis no Scrum: Product Owner, o Dono da Bola, Scrum Master, o Coach Proativo e Scrum Team

Scrum assim como muitas metodologias são formadas por papeis que fundamentam sua aplicação. Os papéis dentro do Scrum são compostos por: O Product Owner, Scrum Master e Team Scrum, que são suficientes para entregar software de alto valor agregado, de acordo com a metodologia Scrum.

Unindo e agregando conhecimento a meus posts anteriormente, temos uma descrição segundo o SBOK.

Product Owner, o Dono da Bola

O Product Owner é o dono do produto, é quem define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, pois fornece o conhecimento do negócio em forma de requisitos para a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa e os clientes.

O Product Owner Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e qualidade que a equipe necessita.

O Product Owner também define o cronograma para liberação das releases, e faz a validação final para saber se as implementações têm as características e qualidade necessárias para a liberação.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint. Estes itens transformam-se no Sprint Backlog.

Daily-Scrum-edersonmelo

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.

Scrum Master, o Coach Proativo

O Scrum Master tem a responsabilidade de assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

As responsabilidades do Scrum Master incluem:

  •  Remover as barreiras entre a equipe e o Product Owner.
  • O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.
  • Melhorar a produtividade da equipe da forma que for possível.
  • Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades seja potencialmente entregável.
  •  Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e organizada.

Em termos práticos, o Scrum Master precisa ter em mente a vivência do Scrum para treinar e orientar os outros papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo.

chickens-standup-edersonmelo

Ele deve manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações externas.

O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.

 E finalmente, Scrum Team

O Scrum Team é a equipe de desenvolvimento sem a necessidade de uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

O Scrum Team é auto organizável, ou seja, quem decide quem faz o que, quais as funções de cada membro e o que cabe ou não na Sprint é o time.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de “Scrum of Scrums“.

edersonmelo-all-blacks-scrum

Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.

Veja a importância efetiva de cada grupo definido no SBOK. Oportunizando a todos o mesmo grau de importância e compreensão do todo.

 

Scrum of Scrums

Iniciado os estudos para Certificação Scrum, me deparo com boa parte que acabei aprendendo mas não utilizando, como o Scrum of Scrums (SoS) , que nada mais é que uma importante técnica para escalar Scrum em grande times e projetos.  Trabalhada em reuniões que permitem agrupar os times para discutir seus trabalhos, focando especialmente em área de sobreposição e integração.”

Definição

Uma técnica para escalar Scrum em grupos grandes (mais de 6 pessoas), consistindo em dividir os grupos em equipes Agile de 5-10. Cada Daily dentro de uma sub-equipe termina designando um membro como “embaixador” para participar de uma reunião diária com embaixadores de outras equipes, chamado Scrum of Scrums.

Dependendo do contexto, os embaixadores podem ser contribuidores técnicos, ou Scrum Master de cada equipe, ou gerentes de cada equipe.

O Scrum of Scrums transcorre como uma reunião diária normal, com os embaixadores que informam as conclusões, as próximas etapas e impedimentos em nome das equipes que representam. Espera-se que a resolução de impedimentos se centre nos desafios da coordenação entre as equipes; As soluções podem implicar concordar com interfaces entre equipes, negociar limites de responsabilidade, …

O Scrum of Scrum realiza seu acompanhamento dos itens através de um backlog próprio, onde cada item contribui para melhorar a coordenação entre equipes. Neste ponto consigo ver várias oportunidades de implementações em equipes de Sustentação de Sistemas, como a que eu trabalho hoje.

Lendo diversos artigos para buscar entender limitações e pontos onde a aplicação venha a aparesentar baixa performance ou qualquer entrave, cheguei a Allan Shalloway, que preve alguns problemas em praticar Scrum com grupos grandes (350 pessoas ou mais). Neste caso há vários diferentes produtos sendo construídos com componentes compartilhados. Ele cita 3 exemplos de problemas que ocorreram:

  • Nível Técnico. Dado que estávamos fazendo desenvolvimento iterativo, os times esperam seguir princípios de design emergente. Isso significa que estamos escrevendo código de qualidade, mas não adicionamos funcionalidade ou design até que eles sejam necessários.
  • Nível Inter Times. A forma como os times trabalham juntos quando há diferentes Product Owners e Scrum Masters para cada time, nem sempre é tão óbvia. Mais uma vez, uma visão mais abrangente ajuda. Isso é especialmente verdade quando há um time de componentes fazendo trabalho de suporte para vários outros times. Orientar-se através de business value requer olhar através dos product owners. Eles podem cooperar, porém, mais uma vez, eles podem não cooperar.
  • Nível de Estrutura do Time. Muitos times scrum trabalhando juntos tem problemas sérios para entregar uma funcionalidade final quando muitos times estão envolvidos.

Já Mike Dwyer diz preferir o SoS e Meta Scrums: “para coordenar a decomposição de estórias, de forma que assim você não termina com a mesma coisa construída por vários times. Aquelas coisas devem ser trabalhadas através de conversas diárias e frequentes que ocorrem em todos os níveis.” Em sua experiência, times bem conduzidos focam na infraestrutura, dados e arquitetura para fazer um bom trabalho de reunir código compartilhado.

O que mais acabaremos encontrando como receita para o sucesso da reunião Scrum of Scrums será o que todos já devemos ter em mente: “Manter a reunião curta. 15 minutos no máximo. Mantenha-a focada. O que os outros querem/precisam ouvir? Discussões devem ser reservadas para uma reunião separada para manter a reunião curta e focada. Traga os problemas que bloqueiam para cada reunião SoS até que sejam resolvidos.

Espero que tenham costado e que curtam. Conforme meu aprofundamento na metodologia e a leitura e entendimento do SBOK irei compartilhar mais conhecimento.

Meu Estilo de Comprar Mudou. Eu Compro Muito Mais Online

Meu Estilo de Comprar Mudou. Eu Compro Muito Mais Online. Sempre comprei uma coisa ali outra aqui, mas nos últimos dois anos eu migrei. Não totalmente, roupas e comida ainda compro em uma loja física quando vou ao shopping ou a um supermercado semanalmente.

Mas estive analisando o obvio, que você também já notou, lojas online oferecem ofertas, promoções que suas lojas físicas não podem oferecer. Lojas físicas possuem aluguel, impostos, funcionários, luz, água, impostos. Não que uma loja virtual também não tenha, mas estes custos são agrupados e menores.

Motivador: O tempo

Sobra também mais tempo para você passear, ir a um cinema, ou curtir um Netflix, veja só, nem para ir ao cinema daqui a pouco você precisa mais sair de casa.

Sobra mais tampo para realizar as minhas atividades físicas, ir a uma academia, caminhar, correr, jogar aquele futebolzinho.

Sobra mais tempo para passear com a família, jantar fora, assistir um filme, ajudar com as atividades escolares. E até para você assistir aquele futebolzinho na tv.

Veja que buscamos neste novo Mundo mais tempo. Mas o tempo continua correndo em 24 horas como sempre foi, nossas atividades e oportunidades de praticá-las que mudou, ela aumentou. Isso deixou a vida mais corrida e o tempo parece cada vez mais curto. Como organizador, sou obrigado a achar mais tempo, e para isso não basta somente metodologias como GTD, Scrum e outras. É preciso mudar alguns hábitos básicos e isso é muio mais difícil.

As tecnologias

As tecnologias e a oferta delas a largo para o público, que tem consumido mais aparelhos como Smartphone, cada vez de maior capacidade tem colaborado para esse levante.

Alguns e-commerce oferecem descontos simples, mas são descontos, para quem realizar a compra via Smartphone, um exemplo é o aliexpress.

A simplificação para finalizar uma compra, armazenar seus dados e cartão com segurança e garantia de cada marca facilita e muito estas compras.

O que dizer do NFC, aceito em muitas máquinas de cartão e agora o Android Pay chegando com força total. Vai ser cada vez mais simples pagar uma compra fisicamente. Você não vai precisar carregar uma carteira cheia de cartões.

E como ficam as pessoas que precisam trabalhar?

Essa já uma das mais acaloradas discussões quando falamos em Inteligência Artificial, e-commerce e Robótica Avançada: Como ficaram as pessoas que precisam trabalhar? Assisti uma palestra na empresa onde trabalho do Gil Giardeli, em que fica claro que haverá trabalho para todos, mas todos precisam se qualificar, todos nós!

Qualificação será algo fundamental, aprender a fazer parte do processo e não ser conduzido por ele.

Hoje infelizmente, quando você vai em uma loja, bate de cara com um profissional desmotivado, sem interesse, como se estivesse obrigado a estar ali. Bom, estes sim podem ainda não ter compreendido que fazem parte e são essenciais para o processo atual, mas que no futuro poderá ficar sem trabalho.

Enfim

Você pode ver todos os cenários, bons e ruins em séries como Black Mirror, filmes como Eu, Robo, O Homem Bicentenário, os substitutos e muitos outros. Estas discussões sempre aparecem discretamente no enredo. Mas vejo oportunidades a todos e principalmente a oportunidade de estar em continua melhoria. evolução.

A eficiência de um Post-it em um quadro de tarefas

Voltando a colar Post-it em um Quadro de Tarefas chega a renovar os ânimos. Não que eu queira ficar colando bloquinhos coloridos, mas pelas possibilidades de renovação em um cenário caótico.

Mesmo usando ferramentas como ALM e Trello, nada substitui um bom Quadro de Tarefas na parede.  Mas não pense em um super Quadro de Tarefas com desenhos de personagens representando cada colaborador, multi colorido, com frases engraçadas. Pense num Quadro de Tarefas padrão com post-it’s simples.

Quando se chega a um ponto do desenvolvimento e você chegar a precisar muito disso e consegue uma brecha para criar você vai entender.  Você vai colocar sua energia, faz o seu melhor, busca técnicas e pode não agradar a todos, mas vale cada segundo.

Um bom Quadro de Tarefas gera motivação sim, todos se reúnem na frente, discutem, novos itens surgem enquanto outros são consumidos e outros priorizados.

Um Quadro de Tarefas é muito fácil, todos entendem, mas não serve de forma alguma como documentação, não vejo esse desejo ou pretensão de que um post-it seja uma forma de matar documentação, bem pelo contrário, é um incentivo a documentar cada etapa. Nada impede que você crie uma tarefa para documentar e ela seja colocada no quadro em um post-it.

Um bom Quadro de Tarefas organiza o trabalho da equipe, você enxerga quem esta fazendo o que, você sabe que talvez um esteja com 3 tarefas e que outro esta com 1 que vale por quatro(neste caso, vale quebrar a tarefa), neste momento você entende a frase 1 post-it + 1 post-it = 3 post-its. Isso porque você enxerga o quanto você produziu em equipe.

Bom, só para ficar o registro de como é legal criar um Quadro de Tarefas e usar post-its. Eu tenho um em casa, tenho ele replicado na minha tela do note através do windows notes. Posso me considerar um fã desta técnica e um eterno aprendiz.

Scrum – Conto clássico, A Roupa Nova do Imperador

Um “tolo sábio” é uma pessoa que faz perguntas desconfortáveis ou levanta verdades desconfortáveis. Nem sempre é fácil ter esse tipo de pessoa por perto, já que eles podem ser considerados encrenqueiros ou alguém que não faz parte da equipe, mas precisam ser cultivados e usados.

Talvez o melhor exemplo seja um que todos já conhecemos — do conto clássico de Hans Christian Andersen, A Roupa Nova do Imperador.

Conforme você deve se lembrar, havia um imperador que tanto adorava roupas finas, que tinha um casaco diferente para cada hora do dia. Se você quisesse saber onde eles estavam, o primeiro lugar que deveria procurar era no quarto de roupas. Um dia, alguns caloteiros foram até o imperador e juraram que tinham um tecido secreto que era tão fino que aqueles que não eram dignos não conseguiriam enxergá-lo.

Eles exigiram uma seda finíssima, mas apenas fingiam tecê-la e na verdade, “teciam” apenas o ar, e o material foi para as suas bolsas. Um dia, o imperador veio para verificar o progresso do trabalho deles e não viu nada. Lembrando-se de que o tecido só era visível para aqueles que fossem dignos, ele elogiou o tecido como o mais lindo que ele jamais vira. Ele pediu a opinião de seus conselheiros, mas todos também juraram que se tratava do material mais maravilhoso de todos.

No dia da entrega, os caloteiros vestiram, cuidadosamente, o imperador com absolutamente nada, e ele recebeu elogios exagerados de toda a corte. Então, o imperador decidiu desfilar pela cidade para exibir para o povo aquele tecido miraculoso.

Você se lembra como o conto termina: ninguém disse nada sobre a nudez do imperador, pois ninguém queria ser considerado indigno.

Assim, a procissão real continuou pelas ruas até que uma criança gritou: “mas ele não está vestindo nada!”. A princípio, o pai da criança mandou que ela ficasse quieta, mas, então, começando com um sussurro que foi aumentando até um grito, e as pessoas começaram a gritar: “ele está pelado!”. O imperador, mesmo temendo que eles estivessem certos, continuou a procissão. E sua corte o seguiu, segurando uma cauda que não existia.

O tolo sábio foi aquela criança — a pessoa que consegue ver que a verdade aceita é simplesmente uma ilusão consensual, e que o imperador realmente estava sem roupas.

Então, se você tem um tolo sábio ou dois, trate-os com carinho.

Essa é a ideia , que com o Scrum tudo seja transparente — a produtividade da equipe, a qualidade do trabalho, o nível de satisfação do cliente.

Bom, não lembro onde li, sei que é muito bacana e deveria ser compartilhado.

Trabalhar demais resulta em mais trabalho

Quando Scott Maxwell, o fundador da firma de capital de risco OpenView Venture Partners, estava trabalhando como consultor da McKinsey & Company no início da década de 1990, recebeu o que considerou ser um discurso de apoio bem estranho. Jon Katzenbach, então diretor da empresa e agora autor de diversos livros e chefe do Katzenbach Center na Booz Allen Hamilton, deu alguns conselhos a Scott dos quais ele jamais se esqueceu. Jon lhe disse que nos anos 1970, quando estava começando, todos trabalhavam sete dias por semana na McKinsey. Aquela era a cultura; aquilo era esperado de todos. Se você não trabalhasse tanto tempo assim, as pessoas achariam que você não estava fazendo a sua parte e que não estava contribuindo com a equipe.

Read more

Um Mundo sem Fluxo, e isso inclui o Scrum

Se você já leu Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo, reconhecerá este texto que acho excelente.

Em um mundo teoricamente perfeito, não haveria processos, reuniões, formulários ou relatórios. No lugar disso, haveria a criação exata daquilo que o cliente deseja, mesmo que o cliente ainda não o saiba. Qualquer “processo” que as pessoas usam é desperdício, e isso inclui o Scrum.
Mas nós não vivemos em um mundo perfeito, e processos ruins estão tão enraizados em nossa forma de pensar que, como alternativa, precisamos de um processo o mais leve possível e com maior impacto no trabalho. O que o Scrum faz é se concentrar na tentativa de eliminar os desperdícios . Tentei criá-lo de forma que o processo em si seja uma estrutura o menos perturbadora possível, e ainda mantenha as pessoas concentradas.

Read more

Micro Curso – Iniciando com a metodologia Scrum

Micro Curso de Scrum Grátis

Está cansado de procurar por milhares informações desestruturadas no Google e Youtube sobre Scrum? Bom, resolvi dar uma mão e unir alguns posts que na minha visão formam um curso básico para você conhecer a metodologia Scrum.

Uma observação importante, este Micro Curso assim como os demais, não possui qualquer certificado, ele serve para ajudar você a conhecer o Scrum.

Porque Scrum?

Scrum – Fábula da Galinha e o Porco

Scrum: Product Backlog

Scrum: Sprint Planning Meeting

Scrum: Daily

Scrum: Scrum Master

Scrum: Team

Scrum: Product Owner

Scrum: Burndown

Scrum: Sprint Backlog

Scrum: Sprint Retrospective

Scrum: Sprint Review Meeting

Scrum Equipe de Manutenção de Sistemas

Equipe ideal para Manutenção Sistemas com Scrum

Reorganização com Pomodoro

Acabei não postando quase está semana devido a uma forte gripe, a anos não tinha uma assim, pequenos resfriados sem importância, mas não gripe.

Também aproveitei para ler e achei um fator limitante em meu currículo, o inglês, e hoje me arrependo de não ter dado foco nele quando tive oportunidades.

Mesmo não estando nos objetivos deste mês, ele entra nos dos próximos como item fixo.

Além do mais nem consegui terminar o livro de Scrum, tenho realmente demorado e tudo isso se da pela falta de organização pessoal. Mesmo utilizando técnica como Pomodoro, GTD, Scrum, e outras, com o passar do tempo eu tenho que voltar e rever tudo, de uma forma que eu não me perca.

Então voltamos ao pomodoro, uma técnica que me ajuda a me reorganizar sempre que preciso. Mas como utilizar ele do jeito certo:

Read more