Olhando o Manifesto Ágil pela visão do Product Owner

O que sustenta a ponta de um iceberg dentro de um cenário ágil, seja em uma organização, time ou até mesmo um papel, é o Agile Mindset. Essa nova mentalidade que o ágil nos leva a entender, está estabelecida por meio de 4 valores, fundamentados em 12 princípios, ou seja, Manifesto Ágil, e manifestada através de diversas práticas, técnicas e métodos diferentes.

agile-mindset

Há uma grande distância entre ser ágil e estar fazendo ágil. Como Product Owner temos um radar de práticas, técnicas e métodos para ajudar de acordo com o contexto que estamos trabalhando, com isso, precisamos internalizar esse Mindset que está fundamentado e estabelecido no Manifesto Ágil e em momento algum podemos feri-lo.

Os valores do Manifesto Ágil:

INDIVÍDUOS E INTERAÇÃO mais que Ferramentas e Processos

SOFTWARE FUNCIONANDO mais que Documentação Abrangente

COLABORAÇÃO COM CLIENTE mais que Negociação de Contratos

RESPONDER A MUDANÇAS mais que Seguir um Plano

O Manifesto é composto de valores e princípios, assim como cada um de nós, para preservar um valor na sua vida é preciso definir alguns princípios, por exemplo: você pode torcer para seu time do coração e, para preservar esse valor na sua vida, é necessário estabelecer alguns princípios, como: ser um sócio torcedor, assistir todos os jogos, assistir pelo menos um treino apronto no mês, comprar camisa oficial. Certamente seguindo esses princípios esse valor de torcer para um time favorito estará vivo em seu dia a dia.

Abaixo temos 12 princípios que preservam os 4 valores do Manifesto Ágil.

Vamos destacar os princípios de bolso de um Product Owner:

  1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor – O Product Owner é responsável em criar, priorizar, fatiar e manter o product backlog, ou seja, é o dono do backlog (única fonte de requisitos do produto). A forma que o Scrum manifesta esse primeiro princípio é através de ciclos curtos que se chamam SPRINTS, com isso, o Product Owner determina o que é prioridade para o cliente no primeiro momento, buscando sempre a satisfação do cliente, e antecipa o poder de entregas (lembrando que não é somente entregar, também gerar percepção de valor em cada entrega).

visao-do-po_3

  1. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas – O Product Owner precisa entender que o cliente não está comprando o produto, mas sim investindo no produto, certo que em um curto espaço de tempo terá esse retorno. Com o foco em fazer o cliente tirar vantagens competitivas de mercado, o PO precisa estar aberto a aceitar mudanças. Quem nos disse que um plano não pode mudar? a única certeza que temos em desenvolvimento de produto é que ele vai mudar, mas com métodos ágeis isso vai acontecer o mais cedo possível, com isso, existe a necessidade de adaptação para responder à mudança sem traumas, lembrando que mudanças sempre são bem vindas. Os requisitos podem mudar a qualquer momento, o que é normal e aceitável, é necessário gerenciá-los conforme suas prioridades. Se os seus requisitos não mudam, tem alguma coisa de errado.
  1. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos – O Product Owner precisa decidir quais funcionalidades são prioridade no primeiro momento, fatiar pequenos incrementos com valor para o cliente. A entrega constante gera a percepção de rápido, pois o objetivo é entregar o mínimo o mais cedo possível para o cliente e gerar o feedback antecipado, gerando assertividade, ou seja, maior frequência de planejamento e maior qualidade das entregas. Com o conceito MVP, tudo isso fica mais claro, pois o objetivo é escolher o mínimo do produto necessário, colocar na mão do cliente e o cliente determina se é viável para evidenciar o aprendizado emergente do produto. O Product Owner pode trabalhar a concepção do produto para entender o todo e priorizar o que precisa entregar. Nesse momento os detalhes não são importantes (detalhes são refinados durante o tempo) e o esforço inicial não deve chegar a duas semanas, apenas dias.

visao-do-po_2

  1. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente durante todo o curso do projeto – O Product Owner está sempre engajado e disponível para o time de desenvolvimento, respondendo a quaisquer dúvidas relacionadas ao negócio. Durante sessões facilitadas, é importante o envolvimento dos desenvolvedores com as partes interessadas, facilitando o entendimento do negócio.
  1. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho – O Product Owner está muito próximo do time de desenvolvimento e é importante que todos saibam que ele faz parte do time (Scrum). O PO deve ter o conhecimento necessário sobre o negócio assim como ter toda confiança para que possa fazer seu trabalho, precisa priorizar o que deve ser feito, tem que ter poder de decisão e, principalmente, saber dizer “NÃO” para necessidade do cliente quando não está alinham com a visão do produto.
  1. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara – O Product Owner é responsável em manter o Product Backlog priorizado e com valor, o time de desenvolvimento em entregar o que está se comprometendo em cada Sprint. Com isso, há uma aproximação forte através de conversas ativas e sessões facilitadas, colaborando constantemente para entender os itens do backlog que podem ser apresentados por User Stories. Valoriza os momentos de conversas cara a cara para dar o entendo de negócio do que está representado através das User Stories, lembrando que ela é apenas um “lembrete” da necessidade do cliente, ou seja, fornece um flash da comunicação, representa os requisitos (necessidades) mais do que documentá-los. Os melhores documentos nos ajudam a recordar nossas conversas, eles não a substituem. Para provocar a colaboração de todas as partes interessadas, pode-se adotar ferramenta simples, como cartões, post-it, papéis, flip-chart, paredes ou quadro em branco, certamente incentivará a comunicação ativa de todos interessados no produto.
  1. Software funcional é a medida primária de progresso – Todo incremento do produto representa uma entrega funcional de valor do produto para o cliente. O Product Owner é o responsável por demonstrar esse progresso de valor para todos interessados.
  1. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes – O Product Owner entrega o que precisa ser desenvolvido para o time, ajudá-lo no entendimento do negócio para que o time possa fatiar e estimar. O trabalho do Product Owner de refinamento dos requisitos é um esforço contínuo durante todo o projeto.
  1. Contínua atenção à excelência técnica e bom design, aumenta a agilidade – O Product Owner contribui constantemente ajudando o time de desenvolvimento a entender a visão e roteiro do produto, seus objetivos de negócio e principais features, deixando claro todo contexto de negócio, com isso o time facilmente consegue identificar riscos técnicas, arquitetura, buscando sempre a excelência técnica.

  1. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito
    –  A principal ferramenta do Product Owner é dizer “NÃO” para um item entrar no backlog. Todo o esforço de refinamento do Product Owner está nos itens de maior prioridade para o cliente, ou seja, saber o que é importante para o produto e saber o momento certo de parar, neste cenário “menos é mais”.
  1. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis – O Product Owner é o responsável pelo backlog e definir sua prioridade, mas em um projeto todos têm toda condição, habilidades e conhecimento necessário para auto organizar e se comprometer com o trabalho que precisa ser feito.
  1. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo –  O Product Owner reconhece que o seu papel precisa se adaptar e melhorar a medida que o produto evolui e está bem alinhado com todo o processo. Retrospectivas frequentes conduzem a melhoria contínua e a forma como o time trabalha para maximizar o valor para seus clientes.

visao-do-po

___________________________________________________________________________________________________________________

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Product Owner, Scrum

12 Dicas para uma Sprint Retrospective Meeting efetiva (PARTE II)

A Sprint Retrospective é a oportunidade para todo o Scrum Team (Product Owner, ScrumMaster e Development Team) se inspecionar e criar um plano de ação para as melhorias para a próxima Sprint.

Aqui você encontra as 6 primeiras dicas para uma Sprint Retrospective eficiente.

7.      Faça a Sprint Retrospective

Não fazer a Sprint Retrospective é o mesmo que não usar Scrum

A Sprint Retrospective é o coração do Scrum, a ponto de muitos praticantes experientes dizerem que é a reunião mais importante. Jean Tabaka afirma que não fazer a Sprint Retrospective é a pior falha possível em relação a este evento.

A Sprint Retrospective é o momento em que os membros da equipe têm a oportunidade de inspecionar e adaptar o seu processo. E é nela que os membros do Scrum Team conversam sobre o que deu certo, o que poderia ter sido melhor e o que pode ser feito melhor para a próxima Sprint. O objetivo é o foco de ao menos uma melhoria no processo, ou Kaizen, e iniciar a implementação de imediato.

O processo da melhoria continua é considerado tão importante dentro do Scrum que é peça central do raciono do aumento de produtividade de um Scrum Team. Sendo considerado por Jeff Sutherland um dos principais artifícios para aumentar a produtividade do Scrum Team, ou um dos itens fundamentais para “fazer o dobro do trabalho na metade do tempo”.

srum-meeting8.      Todos têm algo importante a falar

Todos pensam, todos falam

Um ScrumMaster pode de forma inconsciente filtrar ou desconsiderar o que uma das pessoas está dizendo e isto pode destruir a Sprint Retrospective, segundo Jean Tabaka essa é uma das formas mais eficientes de destriu-la.

Existe um teste muito interessante proposto pelo Marcelo Leite para fazer uma autoavaliação da imparcialidade de um líder que deveria ser feito por todos os ScrumMasters que acreditam em sua imparcialidade.

Nele você é levado a se perguntar sobre sua relação com seu “Colega Não Favorito” e se você realmente consegue ser imparcial em sua relação a ele dentro do local de trabalho.

Caso você tenha tido um resultado próximo do meu, recomendo que você reflita o quão imparcial você é e se ao facilitar você tem momentos iguais ao do Deputado Frank Underwood, interpretado pelo Kevin Spacey, na série House of Cards.

9.      Musica dá o tom no ambiente

Música ajuda a relaxar e pode ajudar a dar o tom na sua Sprint Retrospective.

Estudos mostram que pessoas de diferentes épocas e culturas experimentam uma gama universal de reações emocionais a intervalos musicais específicos. Como se houvesse uma espécie de gramática universal tonal. Para ajudar, estudos mostram que nos esportes ouvir sua música preferida melhora o desempenho dos profissionais.

O difícil é descobrir músicas que funcionem, algumas dicas:

10.      Fluxo de facilitação na Sprint Retrospective

Utilize um fluxo para chegar em algum lugar

Não planejar a Sprint Retrospective e não seguir um fluxo podem ter consequências desastrosas em uma Sprint Retrospective. Principalmente em inicios de projeto ou quando a Meta da Sprint não foi alcançada.

Frisar a primeira diretiva do Norman Keath, uma dinâmica de warm-up, um momento especifico para falar o que foi bem, e um momento para que todos se comprometam com a melhoria podem ser a diferença entre o sucesso e o fracasso do projeto.

Existem muitos fluxos de Sprint Retrospective publicados na internet, para citar três exemplos famosos e que estão disponíveis gratuitamente:

11.      Foco nas três perguntas

Scrum não é patrocinado pela empresa que faz marcadores autoadesivos

Existe um lado lúdico e romantizado ao se utilizar flipchart e marcadores adesivos nesta reunião. Para muitos a Sprint Retrospective se resume ao ScrumMaster facilitar uma reunião mediada por uma técnica.

Primeiramente Post-it não faz parte do core do Scrum, da mesma maneira que o Planning Poker, a User Story, e o quadro de Kanban não fazem parte do framework.

O Rafael Nascimento, Agile Coach na Adaptworks, comenta que passou mais de um ano em uma multinacional facilitando diversas reuniões e nunca usou um post it.

O foco do Rafael em uma Sprint Retrospective era sempre fazer com que as seguintes três perguntas fossem respondidas:

  • O que foi bom?
  • O que melhorar?
  • Como melhorar?

srummaster12.      O ScrumMaster é uma pessoa

O ScrumMaster isento existe?

Muito se fala e lê sobre o ScrumMaster se manter isento durante esta reunião. A maior dificuldade está relacionada ao fato que em sua essência o ScrumMaster é uma pessoa.

E uma pessoa e por isso tem vieses cognitivos. Como exemplo de vieses posso citar:

Uma pessoa que busque evidencias que confirmem uma hipótese inicial de problema ou solução e não permita enxergar outras possibilidades pode parecer teimosia, mas para psicólogos isso tem o nome de viés da confirmação.

Aliado ao fato do viés do observador, o ScrumMaster pode enxergar com clareza um problema que não existe e mesmo assim tentar soluciona-lo.

Um exemplo claro nisso é um observador externo ao time enxergar anarquia em um time auto organizado. Para um observador externo a anarquia é imensa, mas na realidade não existe um padrão facilmente detectável de organização. O problema fica gigantesco quando o observador tendência a propor soluções centralizadoras para uma característica do sistema auto organizado.

Estudos mostram que as escolhas das massas influenciam diretamente como uma pessoa faz escolhas mesmo que vá contra o próprio juízo da pessoa. Esse é o famoso viés da conformidade.

O extremo do viés da conformidade nos leva ao pensamento de manada, que é um fenômeno em que o desejo pela harmonia do grupo faz com que as opiniões pessoas sejam suprimidas. Pois pensamentos contrários se tornam tóxicos e fica mais difícil ainda alterar o status quo.

Um ScrumMaster não consciente desses vieses pode se deixar levar pela opinião do grupo e suprimir ideias e opiniões importantes.

Já o efeito de ancoragem é um viés cognitivo que que descreve em se “ancorar” em uma característica ou parte da informação recebida. Em outras palavras, a dificuldade de se afastar da primeira impressão.

Dessa forma um ScrumMaster que tenha a impressão que a culpa de um insucesso seja um determinado processo irá se ancorar e terá dificuldade em ver o que está realmente ocorrendo.

De forma resumida, o ScrumMaster não é uma máquina de facilitação, mas sim uma pessoa. Que deve sempre focar em processos de facilitação para se isentar o máximo possível.

Referencias

As dicas foram baseadas na minha experiência pessoal, no e-book do Better Scrum, vídeos como o da Jean Tabaka no Scrum Australia, de websites como o do Norman Kerth, e artigos como: http://www.administradores.com.br/artigos/carreira/voce-e-realmente-um-lider-imparcial-faca-o-teste-e-descubra/79793/ do Marcelo Leite, Occupy Scrum: How Sprint Retrospectives Brought us to Agile Nirvana (http://blog.loomio.org/2013/11/20/occupy-scrum/).

Vale ressaltar que li intensamente o Scrum Guide de 2013 para que o conteúdo ficasse aderente ao que consta no texto base do Framework Scrum.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Scrum, Sprint, Sprint

12 Dicas para uma Sprint Retrospective Meeting efetiva (Parte I)

A Sprint Retrospective é a oportunidade para todo o Scrum Team (Product Owner, ScrumMaster, e Development Team) para se inspecionar e criar um plano de ação para as melhorias para a próxima Sprint.

1.      Excelente ScrumMaster = Excelente Retrospectiva

Tudo o que você precisa é de um excelente ScrumMaster

certified-scrum-masterExistem milhares de técnicas de retrospectiva publicadas em livros e em blogs que quando BEM aplicadas alcançam resultados maravilhosos. A questão principal é saber como e quando aplicar uma determinada técnica ou fluxo ao invés de outra.

Eu sou muito fã da técnica StarFish e recomendo para os ScrumMasters iniciantes e experientes a utilização desta técnica. Pois já tive momentos bons assim como já vi colegas tendo resultados empolgantes com essa técnica.

Mas confesso que nem sempre tenho sucesso ao aplicar essa técnica e que o sucesso veio com a pratica. Pois a questão principal não era saber apenas a técnica e sim saber como facilitar uma retrospectiva.

Alguns colegas dizem que musculatura de retrospectiva só se ganha com o tempo, a pratica e a vontade de melhorar a facilitação. E assim se tornaram melhores facilitadores e suas Sprint Retrospectives se tornaram cada vez melhores assim como os seus Scrum Teams.

E finalmente o Certified Scrum Trainer Alan Cyment vai alem ao dizer que tudo que o Scrum precisa é de um excelente ScrumMaster para começar a fazer Sprint Retrospectives. Por isso espero que as próximas dicas te ajudem a se tornar um excelente ScrumMaster.

2.      Faça a Sprint Retrospective em um momento auspicioso

Uma Sprint não precisa terminar as Sextas

Existe uma tendência de se iniciar Sprints as segundas e terminar as sextas, todavia isto pode não funcionar.

E qual o problema de se fazer a Sprint Retrospective as Sextas?

O seu Development Team pode estar cansado de uma semana intensa de trabalho e participar apenas fisicamente da reunião e terá problemas para manter a presença mental na reunião.

Dependendo do horário da Sprint Review e da Sprint Retrospective alguns times ficam compelidos a fazer trabalhos complexos como implantação e testes exploratórios em um dia em que o foco pode estar no final de semana. Isso se não for encontrado um bug e o resultado da Sprint não for como o esperado.

E dependendo do que é falado na Sprint Retrospective muitos finais de semanas podem ser estragados, ou ainda, algumas situações podem ficar piores…

E finalmente, Estudos mostram que a sexta-feira tem uma ligação forte com os conceitos de “Liberdade” e “Partir”. De certa forma, sexta-feira é o dia que tipicamente as pessoas estão mais focadas em no fim de semana do que em qualquer outro tema. Basta lembrar quantas vezes na sexta-feira o assunto do seu Scrum Team é o final se semana.

Sprint Retrospectives na Sexta-Feira funciona em muitos Scrum Teams, todavia isso pode não ocorrer no seu ambiente de trabalho.

3.      O corpo fala

Escute as palavras e veja o real significado

o-corpo-falaInfelizmente ainda não é possível saber o que outra pessoa está pensando. Dessa forma entender as reais intenções de uma pessoa é algo que beira o impossível.

Podemos ter um melhor entendimento das reais intenções das pessoas por meio das expressões corporais. Por exemplo:

Braços cruzados podem significar desde uma postura defensiva ou de insegurança até uma postura de hostilidade. Uma posição relaxada com braços e pernas ligeiramente abertas demonstra autoconfiança e segurança. Já uma postura recolhida significa tédio.

Movimentos de cabeça de um lado para o outro significam negação, já movimentos de cabeça para cima e para baixo consentimento. Uma postura erguida demonstra segurança, valor e importância no que você está fazendo. E mãos na cintura significam desafio, agressividade.

Alguns sinais corporais podem trazer impressões incorretas, todavia desconsiderar essas informações valiosas em uma facilitação pode levar a resultados desastrosos.

Em outras palavras, comece a ler o Best Seller “O Corpo Fala – A Linguagem Silenciosa da Comunicação Não-verbal” do Pierre Weil e do Roland Tompakow.

4.      Presença obrigatória do Product Owner

A participação do Product Owner é essencial na Sprint Retrospective

O Product Owner é obrigado a participar da Sprint Retrospective. E acredite isto está escrito no Scrum Guide. A primeira frase do Scrum Guide sobre a Sprint Retrospective é a seguinte:

“A Sprint Retrospective é uma oportunidade para que o Scrum Team inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima Sprint.”

Tendo em vista que o Scrum Team é compreendido pelos três papeis do Scrum incluindo o próprio Product Owner. A presença do Product Owner é obrigatória, seu Scrum Team gostando ou não.

A questão principal é que existe a responsabilidade do ScrumMaster em garantir a segurança psicologia de todos os envolvidos durante a Sprint Retrospective.

Por exemplo, com frequência o Development Team não se sente à vontade em frente ao Product Owner, por questões que vão desde arrogância, hierarquia, desconfiança, dentre outras. Nestes casos Peter Hundermark recomenda que, temporariamente, o Product Owner não participe das Sprint Retrospectives e o ScrumMaster trabalhe em paralelo estas questões objetivando a segurança psicológica da reunião.

Vale lembrar que o Scrum demanda muito trabalho do Product Owner e estes precisam ser capazes de colaborar com a melhoria continua dos processos dentro do Scrum. Como exemplo de processos em que o Product Owner é essencial tem-se a priorização e a preparação dos itens do Product Backlog e o relacionamento com os Stakeholders.

5.      Não buscar culpados

Diga não à caça às bruxas!

apontando-erradoUm dos maiores receios ao se entrar em uma Sprint Retrospective é o de que a reunião se torne uma sessão de caça às bruxas, onde a única coisa que importa é buscar culpados.

Claramente tal atitude não contribuirá para a evolução do time ou para um melhor desempenho coletivo. Com esse raciocínio Norman Keath define a primeira diretiva de uma boa Sprint Retrospective como:

“Independentemente do que descobrirmos, nós entendemos e realmente acreditamos que todos fizeram o melhor que podiam, dado o que eles sabiam no momento, as suas competências e capacidades, os recursos disponíveis, bem como a situação na mão. ”

Dessa forma a chave para uma Sprint Retrospective bem-sucedida e construtiva é garantir que todos os participantes estejam de acordo com essa diretiva. E assim teremos um tão sonhado evento de aprendizagem coletiva que irá dar bons resultados no longo prazo.

6.      Checar e Atuar

Sempre há algo a melhorar no processo

O mais importante de uma Sprint Retrospective é o comprometimento dos envolvidos com as melhorias do processo de desenvolvimento de software.

No Scrum temos diversos ciclos de PDCA (Plan-Do-Check-Act) sendo executados com diferentes objetivos. Na Sprint Retrospective é feito o Checagem do processo e a criação de um plano de ação para melhorias.

Jean Tabaka menciona que sair de uma Sprint Retrospective sem um plano de ação é uma das maiores falhas possíveis, mas de nada adianta criar um plano de ação e este não for foco de atuação durante a próxima iteração.

Existem estratégias como um backlog de melhorias, expor o plano de ação em local visível, e pedir para todos os envolvidos escrever o plano de ação auxiliam na implementação das melhorias. O ScrumMaster deve guiar a melhoria dos processos, todavia deve haver o comprometimento de todos os membros do Scrum Team com a melhoria continua de processos.

Jeff Sutherland finaliza neste vídeo com a seguinte definição de Sprint Retrospective:

“ A Sprint Retrospective é desenhada para corrigir o problema mais importante. E quando isso ocorre, o Development Team acelera e começa a ir mais rápido, assim como a qualidade também aumenta. Dessa forma a Sprint Retrospective é crítica para o aumento da performance do Development Team.”.

___________________________________________________________________________________________________________________

Gostou? Aqui você encontra as outras 6 dias para tornar a sua Sprint Retrospective ainda mais eficiente.

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Daily Meeting, Scrum, Sprint, Sprint

Product Backlog Building

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

Como chegar ao Backlog?

Como construir algo que tenha valor?

Como encontrar a real necessidade do cliente?

Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

A dinâmica do PBB consiste em vivenciar na prática a construção do Product Backlog utilizando o Backlog Canvas como ferramenta. Essa dinâmica leva todos os envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais benefícios:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.

 

 

PBB é representado por um canvas chamado de Backlog Canvas que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

Veja abaixo o fluxo de construção do Backlog:

IDENTIFICAÇÃO: A primeira etapa é identificar o produto que será construído.

PROBLEMAS: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, neste momento as partes interessadas buscam de forma colaborativa a mesma compreensão do estado atual, pontuando os problemas que desejam que sejam resolvidos. É importante conhecer o problema antes de criar a solução.

EXPECTATIVAS: Nesta etapa é importante identificar o Estado Desejado, alinhando suas expectativas aos problemas do estado atual, para que, de uma forma compartilhada, todos os envolvidos possam alinhar suas expectativas.


PARTES INTERESSADAS: Nesta etapa saiba quem são os usuários, papéis e responsáveis envolvidos no negócio. Alinhando seu contexto de negócio, suas atividades de negócio, seus problemas e dores, necessidades e objetivos.

 


ÁREAS DE NEGÓCIO:
A partir desse momento, identificado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS e os principais objetivos de negócio das partes interessadas de cada área.

 

 

 

 

 

 

 

 

ATIVIDADES DE NEGÓCIO: Em seguida, identifique as ATIVIDADES DE NEGÓCIO de acordo com suas respectivas ÁREAS DE NEGÓCIO já identificadas, as atividades que cada PARTE INTERESSADA realiza dentro do negócio, mapeando na sequência de uso da esquerda para a direita. Descreva a ATIVIDADE DE NEGÓCIO com uma breve descrição da atividade, sempre pontuando o “Problema” e a “Expectativa” da parte interessada relacionada a essa atividade de negócio.

overview-product-backlog-building-atividade-de-negocio

FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representá-las por User Stories ou modelo ARO (<AÇÃO><RESULTADO><OBJETO>). Construindo a lista de funcionalidades, podendo organizar(priorizar) verticalmente o que é mais importante.

 

Essas são as etapas de forma resumida do “PRODUCT BACKLOG BUILDING”. Etapas que compõem o Canvas:

[Identificação > Problemas > Expectativas > Partes Interessadas > Áreas de Negócio > Atividades de Negócio > Funcionalidades]

*As três últimas etapas são baseadas no conceito do FBS (Feature Breakdown Structure) do FDD.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreensão e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

 

Como resultado teremos um Product Backlog totalmente alinhado com o valor de negócio do cliente.

O Scrum não fala como podemos representar cada item no Backlog, podemos escrever de várias forma, inclusive de forma textual. A User Story é a forma mais usadas hoje pelos times ágeis para representar um item no Backlog. História de Usuário é uma breve descrição do que é necessário para o cliente ter no produto, que pode representar uma necessidade do usuário ou uma descrição de uma funcionalidade.

A estrutura de uma História de Usuário basicamente responde 3 perguntas: QUEM? O QUE? POR QUÊ?

 

O PBB nos ajuda na escrita das User Stories. Como podemos notar no PBB temos o “QUEM?” que é a Parte Interessada, o “O QUE?” que nesse caso são as funcionalidades já representadas em modelo ARO e por último, o “POR QUÊ?” que está no objetivo e benefício que a parte interessada destacou na atividade de negócio.  A figura abaixo exemplifica de uma forma bem simples como fica fácil escrever as User Story com ajuda do Product Backlog Building.

 

Como podemos perceber o grande poder do PBB é a facilitação e a colaboração que provoca com todos os envolvidos na construção de um Backlog, sempre levando todos a  um entendimento compartilhado do contexto de negócio e a descoberta de itens do Backlog totalmente alinhado com o valor de negócio do cliente.

Pronto! todas as funcionalidades descobertas representarão os itens do Backlog. Agora é só priorizar o Backlog usando quaisquer técnica de priorização e começar entrar…

Baixe aqui o seu Backlog Canvas e comece a construir seu Product Backlog:

Vídeo: Product Backlog Building com Fábio Aguiar | Test-Drive

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

3 Comentários »

Categorias deste post

Agile, Scrum

Como validar PDUs do PMI em treinamentos da Adaptworks?

Para renovar a certificação PMP (Project Manager Professional) do PMI (Project Management Institute), o profissional precisa coletar um total de 60 PDUs (Professional Development Unit).

Se você particiou das turmas de:

• Certified ScrumMaster
• Certified Scrum Product Owner
• Certified SAFe Agilist
• Certified SAFe Product Manager – Product Owner
• Certified SAFe Scrum Master

• Certified SAFe Advanced Scrum Master
• Management 3.0
• Certified Agile Professional

na Adaptworks, você pode solicitar a quantidade equivalente de horas de treinamento em PDUs.

Isso mesmo, todos os treinamentos acima podem lhe adicionar preciosos PDUs!

Se você estiver em busca de PDUs e fez um destes treinamentos conosco, segue os passos para solicitação dos PDUs:

1) Acesse o site do CCRS e faça login.

2) Clique em Report PDUs na barra de navegação a direita para iniciar o processo.

3) Clique em Course Training

4) Em Provider digite o nome da Adaptworks.
Provider: Adaptworks Treinamentos

5) Em Activity digite o nome do treinamento que você cursou.
Provider: NOME_DO_TREINAMENTO

6) Em description digite a descrição do treinamento que você encontra no site da Adaptworks.
Drescription: DESCRIÇÃO

pdu-adapt-pmi-cap-csm-cspo-artigo7) Preencha a data de inicio do seu treinamento.
Date started: DATA_INICIO

8) Preencha a data de fim do seu treinamento.
Date started: DATA _FIM

9) Preencha o endereço do nosso website.
URL: adapt.works

10) Preencha o nome do nosso contato comercial.
Contact Person: Marcio Santos

11) Preencha o telefone para contato na Adaptworks.
Contact Phone: (11) 2507-3563

12) Preencha o endereço de contato da Adaptworks.
Contact Email: contato@adaptworks.com.br

13) Clique em próximo

14) Em PDUs claimed, distribua o número de horas do treinamento entre Tecnhical, Leadership e Strategic. Recomenda-se 10 para Tecnhical, 3 para Leadership e 3 para Strategic. Totalizando 16 PDUS.

15) Clique em “I agree the claim is accurate” e pressione “Submit”.

16) Terminado, agora é só esperar a resposta do PMI.

Este fluxo é uma tradução livre das instruções do próprio site do PMI

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Certified Agile Professional, Management 3.0, PDU, SAFe, Scrum

Você deve ler o Scrum Guide com frequência!

O Scrum é um framework de desenvolvimento descrito em um guia de dezesseis páginas e como praticante você deveria lê-lo com frequência.

Isso mesmo, o Scrum é um framework com um texto curto, direto e simples. Um bom significado para Simples é “o que é elementar, não apresentando qualquer embaraço para sua compreensão.” Ou seja, no Scrum Guide temos apenas o que é elementar para o desenvolvimento de produtos com o objetivo principal de ser um guia de fácil compreensão.

ScrumButAo mesmo tempo, colocar em prática como descrito no guia não é uma tarefa fácil. Qualquer praticante sabe que praticar Scrum é fácil na teoria todavia a prática do dia a dia é muito mais dolorosa. É muito fácil e cômodo cometer desvios e começar a executar o famoso ScrumBut.

Você executa ScrumBut quando você diz coisas como: “eu prático Scrum mas não faço reunião diária”, “eu uso Scrum mas minha área de negócio não sabe e eu não tenho PO”, “eu pratico Scrum mas tenho sprint só de documentação”.

Aparentemente, não parece haver problema ao se executar um Scrum pela metade, ou faltando uma perna, porém o Scrum é baseado em teorias complexas, como executar ciclos diários de PDCA (Planejar, Desenvolver, Checar e Agir).

A reunião diária é o momento do Scrum que obriga o time a executar um ciclo de planejamento, execução, checagem e ação todos os dias. Ou seja, não fazer a reunião diária implica em não fazer o ciclo diário de PDCA e no longo prazo alguém vai pagar essa conta.

Em cada um dos ScrumButs exemplificados passa-se por cima de alguma teoria que embasa o Scrum.

O Scrum é um framework simples mas emergiu a partir de um time de desenvolvimento que estava cansado da forma antiga de trabalhar e que estudou muito para elaborar o framework. Os criadores do Scrum estudaram teorias de relacionamento interpessoal, teorias de produtividade de times e indivíduos, teorias de linhas de produção enxuta.

Ou seja, criaram um framework simples e que é embasado por teorias complexas.

leitura-scrum-guideAo ler o framework com frequência você tem menos chance de corroer um pedaço dele por desconhecimento e terá, assim, um conhecimento do que é Scrum de forma mais concreta.

Outra coisa importante é saber o que faz parte e o que não faz parte do Scrum.

O Scrum é um framework enxuto e no qual o praticante pode preenche-lo com os recheios que fazem sentido para um projeto específico. Muito do que se comenta sobre Scrum em blogs e livros dizem respeito aos recheios e não ao core do Scrum. Por exemplo:

  • User Story não faz parte do Framework do Scrum mas você pode usar;
  • O quadro de kanban não faz parte do Scrum mas quase todo mundo usa;
  • A reunião diária não precisa ser em pé em frente ao quadro mas é mais produtiva se realizada desta maneira.

Poderia ficar enumerando vários outros benefícios, o que ficaria cansativo…

Mas para finalizar:

O Scrum Guide é a base do framework mais utilizado em projetos ágeis hoje em dia e demora menos de 30 minutos, inicie a leitura agora! :)

Referências

ScrumGuide

Scrum, A arte de fazer o dobro do trabalho na metade do tempo. Jeff Sutherland

VersionOne. State of Agile Survey 2011.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Scrum

DICAS PARA UMA DAILY SCRUM MEETING REALMENTE EFICIENTE (PARTE II)

Você sabe realmente o que é uma Daily Scrum Meeting? Então lá vai uma explicação clara e direta:

“A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.”

Analisando todo o ambiente da Daily Scrum, criamos algumas dicas que facilitarão o processo. Já falamos sobre algumas delas neste post e aqui vão as demais:

7.    Faça off-line

Por favor, desliguem os dispositivos eletrônicos e telefones celulares

celularO Development Team deve estar com foco total na Daily Scrum, dessa forma o uso de telefones celulares e computadores deve ser evitado.

Os celulares são fonte de distração o tempo todo, pesquisas cientificas tem mostrado que a simples interrupção causada pelo aviso sonoro faz com que a pessoa desfoque e passe a pensar no que está ocorrendo no mundo digital. Essa falta de foco pode significar desde um detalhe que irá passar desapercebido até uma repetição do que uma das pessoas falou.

Os computadores devem ser evitados nessa reunião para que os membros do Development Team não se sintam compelidos a corrigir bugs, auxiliar o colega com dificuldade ou abrir o Facebook. De forma geral, a ausência de computadores irá ajudar os membros do Development Team a controlar a ansiedade de resolução imediata de problemas.

O Development Team deve entender que a Daily Scrum é uma reunião de planejamento diário para auto-organização com objetivo na completitude da Meta da Sprint.

 

8.    Utilize um Token

Todos falam, na sua vez, e todos escutam

Introduzir um mecanismo de ordenação como um token ajuda a fazer com que todos falem e todos escutem.

Nesta técnica apenas a pessoa que tiver com o token na mão pode falar e as outras devem prestar atenção em quem estiver falando. Desta forma até os mais introspectivos falam e são ouvidos pelos extrovertidos.

Jogar o Token de forma imprevisível introduz um pouco de diversão para o ritual da Daily Meeting. Todavia ficar jogando um token pode ser algo negativo, pois pode ser visto como pouco profissional e criar uma percepção negativa desnecessária da Daily Scrum.

A forma mais simples e que ao mesmo tempo é muito eficaz é utilizar uma caneta como token e passar a caneta no sentido horário.

 

9.    Em pé

Faça a reunião em pé para assegurar que ela seja curta.

standupmeetTodas as pessoas se incomodam ao ficar em pé e este incômodo faz com que todos queiram que a reunião acabe o mais rápido possível. Ao ficar em pé, pessoas que gostam de falar se tornam mais objetivas e evitam contar história, discutir ou justificar problemas em demasia.

Do ponto de vista fisiológico, ao ficar em pé a área do pulmão que possui maior absorção de oxigênio fica disponível e por consequência as pessoas ficam com maior capacidade de raciocínio por estar com o cérebro mais oxigenado.

Existe o mito de que a Daily Scrum precisa ser feita em pé em frente. É importante ressaltar que não existe menção a isso no Scrum Guide, todavia é uma das práticas do framework eXtreme Programming que muitos Scrum Teams utilizam.

 

10.    Multiplique os facilitadores

Ensine facilitação e como ser facilitado

multiplique

ScrumMaster deve ensinar ao Development Team como se manter na timebox e ao mesmo tempo como conduzir a reunião. Utilizando palavras do próprio Scrum Guide “O ScrumMaster assegura que o Development Team tenha a reunião, mas o Development Team é responsável por conduzir a Daily Scrum. O ScrumMaster ensina o Development Team a manter a Daily Scrum dentro do timebox de 15 minutos. ”

O ScrumMaster deve ensinar aos membros do Development Team a conduzir a Daily Scrum e uma das técnicas que pode ser utilizada é alternar o facilitador da Daily Scrum.

Essa delegação de facilitação não deve ser confundida por “delargação” da facilitação pois o ScrumMaster em última instancia é o responsável pela boa execução da Daily Scrum.

Dessa forma o ScrumMaster deve ensinar o Development Team a conduzir e ser conduzido nesta reunião. O que no longo prazo irá facilitar a vida de todos os envolvidos.

 

11.    Mesmo horário todos os dias

A repetição gera o hábito, o hábito gera a excelência

agendaTer o habito de fazer a Daily Scrum no mesmo horário todos os dias nem sempre é fácil por motivos como horário flexível e ausência de membros do Development Team.

O Scrum Guide não diz qual o melhor horário para a realização da Daily Scrum, ele só fala que deve ser feita no mesmo horário e local para reduzir a complexidade. Os Scrum Team geralmente fazem a Daily Scrum no início e no fim do dia, todavia nada impede de fazerem a Daily Scrum as 11 horas ou as 16 horas.

A definição do horário deve ser baseada no horário em que mais pessoas estão aptas e dispostas a fazer a reunião. Isso evitará faltas e pessoas desmotivadas na reunião.

Uma das formas de destruir a Daily Scrum é realizar a reunião no primeiro horário do trabalho em um ambiente em que poucas pessoas chegam pontualmente no trabalho. É obvio que a reunião será tida como infernal em pouco tempo.

Em times dispersos geograficamente com fusos horários diferentes, definir um horário pode ser ainda mais difícil, pois nem sempre irá haver um horário que agrade a todos. Em última instancia definir um horário rotativo pode se tornar uma opção.

Em relação a ausência de membros do Development Team, uma prática que faz sentido é definir um quórum mínimo de participantes e caso esse quórum não seja atingido a reunião não é realizada e uma ação é tomada.

 

12.    Foco na Meta da Sprint

O foco do Development Team é atingir a meta da Sprint?

A Daily Scrum tem como foco a autorganização do Development Team para atingir a meta da Sprint.

Houve uma clarificação disto na última versão do Scrum Guide na qual as próprias perguntas a serem respondidas mudaram:

  • O que eu fiz ontem que ajudou o Development Team a atender a meta da Sprint?
  • O que eu farei hoje para ajudar o Development Team a atender a meta da Sprint?
  • Eu vejo algum obstáculo que impeça a mim ou Development Team no atendimento da meta da Sprint?

metaO foco das respostas é sempre em relação a atender a meta da Sprint e nunca em um plano previamente feito, isso na prática quer dizer que nesta reunião ocorrem os ajustes no plano para atender a meta da Sprint.

O segundo item importante é o foco no Development Team como um todo e não na meta individual de cada um dos seus membros. Isso clarifica a importância de trabalhar como um time e não individualmente.

Vale destacar que essa “mudança” do foco individual para o Development Team foi feita na última versão do Scrum Guide. O foco sempre foi o Development Team como um todo, todavia isso não estava claro nas ultimas versões.

Uma das maiores reclamações de membros do Development Team é a impressão de que a Daily Scrum era uma perda de tempo tendo em vista que achavam estar fazendo apenas Status Report para os outros membros. Com essa “mudança” fica claro que o Development Team como um todo deve se ajudar a atender a Meta da Sprint.

___________________________________________________________________________________________________________________

Gostou das dicas? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin

Nenhum comentário »

Categorias deste post

Daily Meeting, Scrum

Dicas para uma Daily Scrum Meeting realmente eficiente (Parte I)

Você sabe realmente o que é uma Daily Scrum Meeting? Então lá vai uma explicação clara e direta:

“A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.”

Analisando todo o ambiente da Daily Scrum, criamos algumas dicas que facilitarão o processo:

 

1. Menos de 15 minutos

A maioria das pessoas tendem a se dispersar em reuniões longas.

Quinze minutos é tempo mais que suficiente para que que todos os membros de times pequenos (três pessoas do Development Team) interajam. Já para times maiores (nove membros do Development Team) isso pode ser considerado pouco tempo para que todos sejam ouvidos.

A questão principal é que estender a reunião dificilmente será uma decisão acertada, pois reuniões longas tendem a ser maçantes. Pessoas costumam dispersar em reuniões longas e continuam sem entender o que está ocorrendo.

O papel do ScrumMaster é tornar a Daily Scrum eficiente, ou seja, atingir o objetivo da Daily Scrum no máximo que a timebox pré-definida permite.
relogio analogico parede 4

Mesmo se a reunião for se estender por mais de quinze minutos, faz sentido forçar a sua finalização no tempo estabelecido para reforçar o conceito de timebox e despertar o interesse do Development Team em ser eficientes na comunicação.

Para não tomar tempo em demasia da Daily Scrum, deve-se criar reuniões separadas quando o assunto não for de interesse geral, evitando assim que se perca o foco.

As próximas dicas devem ser encaradas como formas de manter a Daily Scrum na Timebox.

 

2. Melhorar o canal de comunicação em times remotos

“Se uma pessoa do time está remota, todo o time está remoto.”  Lisette Sutherland 

Assumindo esta frase para a Daily Scrum, todos os integrantes do time devem se comportar como se estivessem remotos caso apenas uma única pessoa esteja remota.

Dessa forma, todos devem participar desta reunião por meio de comunicação remota e não apenas aqueles que estiverem remotos. Isso evita que a reunião se subdivida em duas reuniões, a presencial e a remota.

Como utilizar o Skype em sua empresa

Outra recomendação para diminuir o gap de comunicação entre os envolvidos é o uso de ferramentas de videoconferência ao invés de utilizar e-mails, WhatsApp ou telefone. Isso ajuda a perceber nuances na comunicação como incertezas, sarcasmos e insegurança.

A videoconferência irá aumentar o foco das pessoas na reunião, pois isso irá diminuir a chance de que assuntos sejam tratados em separado.

 

3. Conversar com o Product Owner em outro momento

O PO pode falar com o Development Team a qualquer momento do dia menos no horário da Daily Scrum

A Daily Scrum não é uma reunião para relatar o progresso para o Product Owner ou para qualquer outra pessoa que não seja membro do Development Team. Na verdade, o ScrumMaster deve assegurar que somente os próprios membros do Development Team participem desta reunião.

Caso o Product Owner deseje conversar com o Development Team ele deve encontrar um momento durante o dia exceto durante a Daily Scrum para ter essa conversa, pois existe grande chance de o time deixar de conversar sobre microgestão, que é o foco desta reunião.

Reunião de Negócios

Reunião de Negócios

Vale ressaltar que segundo o Scrum Guide o PO não deve fazer parte da Daily Scrum tendo em vista que a maioria dos times fazem Status Report para o Product Owner quando este está presente na Daily Scrum.

E finalmente, utilizando palavras do próprio Scrum Guide, o ScrumMaster reforça a regra de que somente os integrantes do Development Team participem da Daily Scrum.

 

4. Não fazer Status Report ao ScrumMaster

ScrumMaster não é chefe do Development Team

Em times que estão em transição para o Scrum é comum que o Development Team encare o ScrumMaster como um gerente, coordenador ou simplesmente chefe. Pelo Scrum não existe um papel de gestor do Development Team.

Existe a liderança situacional dentro do próprio Development Team em relação a assuntos técnicos, por exemplo, e a microgestão do Development Team. O ScrumMaster não exerce qualquer tipo de liderança ou gestão sobre os itens citados.

Para se assegurar que isso não ocorra na Daily Scrum, o ScrumMaster não deve cobrar nenhum tipo de entrega ou ainda cobrar progresso de tarefas dentro da reunião. De forma mais pragmática ele pode se ausentar da Daily Scrum para deixar ainda mais clara essa premissa.

Vale destacar que uma das mudanças mais importantes na versão atual é que o objetivo da Daily Scrum é que o time deve usar esta reunião para entender como trabalhar junto e se auto-organizar para atingir a Meta da Sprint.

 

5. Impedimentos devem ser notificados imediatamente ao ScrumMaster

Houston we have a problem, and we are blocked to lauch

Alguns membros do Development Team erroneamente aguardam a Daily Scrum para notificar o ScrumMaster sobre impedimentos.

Tecnicamente a resposta dada a pergunta sobre a existência de obstáculos que impeçam o atendimento da meta da Sprint durante a Daily Scrum é para que o Development Team seja notificado no máximo nesta reunião sobre a ocorrência deste impedimento.

Simple-kanban-board-

Se um membro do Development Team aguarda até a realização da Daily Scrum para notificar a ocorrência de um impedimento ao ScrumMaster, ocorre um desperdício de tempo para o início dos trabalhos do ScrumMaster naquele tema e por consequência um tempo maior para resolução do problema.

E não se deve-se esquecer que o ScrumMaster tem de garantir que a reunião ocorra da maneira correta e que para isso ele não necessita estar presente.

 

6. Quebrar o contato visual com o facilitador

Ops, onde foi parar o facilitador?

O facilitador deve sempre quebrar o contato visual para evitar que ele seja o principal ator da reunião.

É muito comum que os membros do Development Team comecem a fazer a reunião olhando diretamente para o facilitador e dessa forma a reunião tende a ter uma conotação de Status Report ao facilitador.

file_3382

O facilitador deve entender que a Daily Scrum é uma reunião de inspeção e adaptação do trabalho do dia a dia do Development Team para o próprio Development Team.

O facilitador pode quebrar esse contato visual de diversas maneiras. Como exemplo: ficar a trás do flipchart, ir ao banheiro, sair da sala, ou ficar atrás de alguém ou de alguma coisa. Acredite isso já rendeu momentos engraçados, mas no fim todos acabam entendendo.

_______________________________________________________________________________________

 

Curtiu? Então da uma olha nas outras 6 dicas que nós elaboramos para você!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Daily Meeting, Scrum

5 lessons learned Coaching big companies

kratos-cover

Over the last year, Rafael Nascimento and I have been helping a big company through its global transformation towards the Agile state. This initiative has been a great experience for the whole Adaptworks team. We spent a lot of energy and we’ve got a lot of insights into how agile could be adopted by big companies. So, we would love to share with you our 5 key lessons from this case.

We won’t talk about the process or any internal decision made at this company but we’ll discuss in the next few paragraphs about our perspective as Agile Coaches. For this reason, the aim of these tips is to help other Agile Coaches to improve the action through some changing processes.

Let’s go to the tips:

  1. Combine the two hats – Agile Coaching is actually a combination of two approaches – Coaching and Mentoring. Remember that there’s a huge difference between both. When you’re acting as a Mentor, you provide the correct answers to solve some kind of problem. When you’re acting as Coach, you provide a set of questions to help people to find out the answers by themselves. So, it’s important to make this difference pretty clear to the audience. In addition, it’s vital that the Agile Coach recognises in which kind of situation Coaching and Mentoring could be applied.
  2. Pull coaching instead push coaching – After the startup phase, let people pull the Coaching or the Mentoring on demand. I mean, avoid pushing your service to people. Most of the time, only when people become aware of their problems, do they get the sufficient awareness and the motivation to accept Coaching. This is also a basic principle in Coaching. Many coaches get anxious to make the process work and don’t apply the right amount of patience that is needed to help a solution fit for that company and even for a specific team to flourish. So, keep your days busy talking to people about their environment, their problems and even about possible solutions to their problems. Keep yourself busy holding relevant talks and even internal webinars. Let people know that you’re capable of helping them, and they’ll talk to you when the time is right for them. And then you get (for free) a great opportunity to focus your energy, instead of wasting it chasing people that don’t want to listen to you.
  3. When you act as mentor, don’t start with magic solutions – Many coaches start their mentoring process by offering specific frameworks or specific tools to people. Agile, project management, business management and product development are really huge and have an amazing variety of tools that can be used in specific situations, using different mindsets. So, as a coach, really use the tools and frameworks that you have mastered from the toolbox. Again, invest most of your time listening to people’s problems, and offer them the tool or framework that may better fit their specific need and watch them walk away smiling.
  4. When you argue about the “why”, you’ll fail  –  When we’re in a change process we can organise the challenges into two big questions – why change?  and how to change? The “why”, most of the time, is compounded by values, beliefs and assumptions etc. The “how” is more related to operational stuff.  Due to these aspects, in our experience, if you as an Agile Coach are trying to argue about why the Coachee must change, you’ll fail. When you argue about the “why” you are trying to prove to someone about “my point of view is better than your point of view, so just accept what I’m saying!”  It’s quite dangerous because most of the time, it sounds like “my why is better than yours” or in other words, “my values are better than yours”. For sure, this kind of approach causes resistance and difficulty in the change process. For this reason, as an Agile Coach, help the people with questions. Especially open questions to help them explore their mental model and to find their own why.
  5. Don’t forget the software  –  Although Agile transformations have a great focus on management processes and leadership/operations roles, it’s highly important that you, as a coach/mentor, don’t forget you’re aiming to optimise processes for software development. What’s more, delivery/quality processes’ automation play a greatly important role here. It doesn’t matter how wonderfully the teams are following the agile processes or how we’ve been able to teach great Product Owners or Scrum Masters, or even if we’ve been able to create a set of metrics that make total sense with the new value delivery mindset. If the teams (and their processes) are really fast in executing, but are getting stuck when they try to deliver or assess an increment quality, you’ll gain a beautiful bottleneck and effective management processes just won’t make it. So, be obsessed with teaching and even provoking people about delivery/quality automation showing them tools you’ve used and cases you know about, always keeping the subject  alive and bothering them.

I hope you have enjoyed these lessons. We will share more tips soon. See you :-)

Nenhum comentário »

Categorias deste post

Agile, Coaching, Extreme Programming, SAFe, Scrum

É necessário alterar a forma de contratação para trabalhar com Scrum?

O Scrum provoca um rebuliço organizacional tão grande que muitas vezes a cultura organizacional é posta em cheque. Em outras palavras muitas vezes se percebe que é necessário mover o elefante da cultura organizacional para outro lugar.

Obviamente isso toma tempo e para muitos a adoção orgânica, lenta e gradual do Scrum faz mais sentido. Em boa parte dos casos as tentativas de adoção abruptas e superficiais (ou os famosos, faça-se a luz e vou instalar e pronto) dificilmente se sustentam no longo prazo.

O motivo é simples, os novos valores são tão diferentes que não fazem sentido algum para os acostumados a forma corrente. E uma das consequências invariáveis dos novos valores é em relação a forma de contratação. Isso invariavelmente surge na mente dos novos praticantes no início.

Isso ocorre por que de acordo com os valores antigos é feita a contratação com um escopo de projeto fechado, e a partir do escopo é estimado um valor total do projeto e o tempo para a entrega. Dessa forma tem se a falsa ilusão de se fechar o escopo, valor e o tempo.

Essa ilusão perde sentido ao se fazer as seguintes reflexões:

->Com que frequência uma estimativa feita está correta?

->Com que frequência o seu cliente possui necessidade de mudar o escopo?

->Com que frequência o cliente consegue mudar o escopo sem entrar novamente em negociação?

->O cliente está contente com a entrega de TI?

A resposta para essas perguntas geralmente está relacionada a:

->As estimativas são superestimadas em 50% das vezes. Para evitar problemas adiciona-se gordura para as estimativas;

->O cliente não sabe o que quer e sempre deseja mudar o que foi combinado inicialmente;

->O cliente não consegue mudar o escopo sem antes ficar exaurido em uma negociação. Ou o cliente tem a opção de iniciar um novo projeto com um novo escopo, prazo de entrega e valor.

->Ouve-se nos corredores das corporações que o cliente de IT não está contente por causa dos atrasos na entrega, alterações no custo, e finalmente porque não ocorre a real materialização do sonho.

Esses problemas estão fortemente relacionados ao raciocínio de que contrato de IT é similar a contratos da engenharia civil. Em outras palavras, é utilizado modelo de contrato para uma reforma ou para a compra de um imóvel na planta em projetos de IT.

Felizmente em projetos de IT existe a necessidade de se utilizar mão de obra de profissionais criativos para concepção do produto final. Ao se utilizar esse tipo de mão de obra em sistemas complexos a margem de erro de estimativas é um fato.

“O cliente não sabe o que quer” é um fato, e é um fato a muito tempo.

Dessa forma deveríamos parar de fazer uma estimativa sobre um escopo cheio de incertezas e ajudá-lo a descobrir o que ele realmente precisa. Para isso precisaremos focar mais na solução de problemas do que propriamente na negociação de um escopo.

Todavia pode-se cair na armadilha de se mostrar a materialização da solução do problema apenas uma vez e assim jogar no lixo tempo e dinheiro. Não faria sentido seguir na direção errada por muito tempo.

Em outras palavras faz se necessário materializar e testar partes da ideia original com frequência e coletar feedbacks do cliente. E somente dessa formar descobrir junto com o cliente para qual direção seguir.

E o mais importante se o mercado mudar, é necessário fazer as adaptações necessárias para obter um produto que faça sentido para o novo mercado.

Dessa forma não é simplesmente alterar a forma de contratação de Fixed Price para Time Material. O foco do contrato deve ser solução de problemas dos clientes ao invés de uma solução especifica.

Afinal o foco agora está em colaborar com o sucesso do negócio do cliente mais do que ficar a apenas negociar e se proteger de contratos.

Se você estiver sentido essa dor, infelizmente não existe receita pronta, mas os links abaixo podem te ajudar:

http://www.agilecontracts.org/

http://www.adaptworks.com.br/TurmaDetalhes/epc-estimating-planning-contracting/1099/Produtos

http://www.infoq.com/articles/agile-contracts

http://www.stridenyc.com/blog/2014/10/3/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams

http://www.twobirds.com/~/media/PDFs/Brochures/Contracting%20for%20Agile%20software%20development%20projects.pdf

 

Nenhum comentário »

Categorias deste post

Agile, Product Owner, Scrum