Para relembrar, Flores busca na Teoria dos Atos de Fala explicações para o sucesso e fracasso das relações de trabalho, principalmente nas relações onde alguém se compromete a fazer algo para outra pessoa, em um ciclo pedido, promessa, entrega e aceitação. Já discutimos como o Scrum suporta esse ciclo.

Segundo Flores, no contexto de trabalho em grupo produtivo

“A confiança é crucial, não somente para os relacionamentos internos, mas também para as relações com o cliente”.

Nesse caso vamos focar nas relações entre Time e PO, ou seja, nas relações entre o Time e seu cliente.

Como a confiança é criada?

Bem, a princípio o PO pode escolher um entre quatro papéis:

1. confiar,
2. ser prudente,
3. ser ingênuo ou
4. desconfiar.

Normalmente essa posição inicial de confiança já faz parte da personalidade da pessoa ou foi criada em um ambiente ou domínio específico após outras experiências más ou bem sucedidas. Na gradação entre confiante e desconfiado, devemos estabelecer alguns parâmetros. Aquele que confia está ciente de que pode errar, enquanto o ingênuo não tem essa noção, ou seja, noção do risco em que está se envolvendo quando aceita que Time vai fazer um trabalho, porém ambos escolhem confiar no Time. O prudente se preocupa em investigar se oTime é capaz antes de aceitar que ele faça o que pede, enquanto o desconfiado suspeita e é difícil de convencer.

Esses comportamento, principalmente no princípio de um projeto, pode se refletir em vários passos do Scrum, porém minha sensação é que os maiores problemas de relacionamento estão no momento em que o Time define o esforço necessário para as tarefas ou escolhe um conjunto de tarefas para executar. Já vi POs suspeitarem do Time estar “pegando pouco peso” ao definir o Sprint Backlog ou “dando notas muito altas” ao definir o esforço da tarefa.  Como essas atividades são inerentes ao Time, o PO acaba expressando seu descontentamento de várias formas, inclusive com pressões e ações preemptivas, como criar datas de entrega falsas e adiantadas de forma a forçar o grupo a acelerar seu passo (e provavelmente partir para uma marcha para a morte).

Entre as tarefas do Scrum Master, como um facilitador, está certamente a de azeitar o relacionamento entre Time e PO. Para isso é importante estabelecer uma relação de confiança, que como dissemos, não existe no início e vai sendo desenvolvida ao longo do relacionamento. Voltando a Flores, podemos entender que essa relação é construída sobre quatro avaliações que o PO faz do time:

1. sinceridade,
2. competência,
3. confiabilidade e
4. engajamento.

Para garantir uma boa avaliação de sinceridade, a equipe tem que mostrar ao PO que não faz promessas que não pode, por intenção ou competência, cumprir.  Para garantir uma boa avaliação de competência a equipe deve executar suas tarefas de acordo com os padrões de qualidade estabelecidos entre ela e o PO. Já quando o assunto é confiabilidade, a equipe deve mostrar ser capaz de completar suas tarefas no prazo e deixar claro quando não vai poder cumpri-las por algum motivo e, finalmente, para mostrar engajamento à equipe deve mostrar comprometimento com os interesses do PO.

Novamente podemos ver que o Scrum já busca atender vários desses requisitos. A limitação de tempo de uma Sprint, o conceito de valor, a reunião de revisão, tudo isso implica em facilitar o reconhecimento dessas qualidades na equipe, favorecendo uma avaliação bem fundamentada do PO, por meio de uma sequência de fatos que pode ser revisada no futuro (principalmente se você usa uma ferramenta automatizada que guarda a memória do seu trabalho).

Mesmo assim, ainda podemos encontrar conflitos. Novamente vou dar o exemplo da desconfiança do PO de que a equipe está inflando os números da estimativa de esforço. Segundo a teoria de Flores, o PO, nesse caso, está fazendo uma avaliação que pode ser bem ou mal fundamentada. Podemos também ver que como o interesse do PO é receber valor dentro do prazo, o que está acontecendo nesse caso específico é que ele desconfia ou da sinceridade da equipe, ou do engajamento da mesma.  Veja que nessa desconfiança ele não coloca em jogo, a priori, prazo ou competência.

Para iniciar o tratamento dessa questão, cabe ao Scrum Master investigar, buscar dados que permitam a ele afirmar fatos que corroborem ou não a avaliação do PO. Flores acredita que muitos dos problemas do espaço de trabalho estão relacionados a avaliações incorretas, ou seguindo sua nomenclatura, infundadas. Uma avaliação bem fundamentada precisa ser baseada em um interesse, restrita a um domínio, ter fatos que a comprovem, seguir padrões com que as pessoas estão comprometidas e permitir que ações sejam feitas para corrigir avaliações negativas.

Veja agora a importância de manter o histórico do trabalho. Avaliações bem fundamentadas dificilmente podem ser feitas ou comprovadas usando apenas a memória das pessoas. Vários experimentos já mostraram que nossa memória possui um viés e tendemos a nos lembrar mais dos fatos que suportam nosso estado cognitivo corrente. Assim, um PO sob pressão de tempo pode se lembrar mais dos fracassos que dos sucessos da equipe. A memória do projeto, possivelmente obtida por meio de ferramentas automatizadas, pode ajudar o estabelecimento de fatos que provem, ou não, as avaliações que fazemos.

Podemos também citar o princípio ágil da transparência. Se toda a informação está disponível para todos e todos acompanham o trabalho, então as avaliações que fazemos do trabalho estarão mais próximas de serem bem fundamentadas.

Continuando com o tratamento da questão, o Scrum Master deve não só atacar o problema, seja ele verdadeiro ou falso, como também deve se preocupar em estabelecer ou re-estabelecer a confiança trabalhando as quatro avaliações. O PO deve acreditar na sinceridade, na competência, na confiabilidade e no engajamento do time. São esses os pontos específicos a serem tratados. Soluções possíveis dentro do contexto são, por exemplo, fazer o PO participar mais do dia a dia da equipe e desenvolver conversações mais produtivas, onde o interesse do PO é levado mais em conta. Isso implica em trabalhar apenas o que o PO está pedindo, mas por que ele está pedindo uma história.

Não é surpreendente que as propostas do Scrum se encaixem de certa forma  ao texto de Flores e Letelier, pois são a primeira edição pública de textos antigos que foram circulados no passado e provocaram muitas ideias, tanto na teoria quanto em aplicações. Porém, podendo agora ver o que Flores propôs no passado temos a oportunidade de entender nossas práticas de trabalho.

Bom material de discussão para Reunião de Retrospectiva.

Leia também os demais posts baseado também na leitura do livro Conversations For Action and Collected Essays: Instilling a Culture of Commitment in Working Relationships”

• O Scrum Coordena Ações de Forma Completa
• O Cliente Não Quer o Que Pede

The post A Confiança do PO no Time tem que ser Criada appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

O início de um projeto é provavelmente sua fase mais crítica. Entender corretamente as verdadeiras necessidades dos clientes desde o início é um grande passo para o sucesso. Cada erro de compreensão pode levar a múltiplos erros no futuro e a um alto custo de correção ou mesmo de abandono. Muitas técnicas são recomendadas para serem utilizadas nessa fase, porém uma das mais simples é a mais eficiente. Inicialmente conhecida como a técnica do 5W, hoje é chamada de 6W2H.

Essa sigla representa 8 questões que devem ser respondidas em qualquer projeto ou tarefa que fazemos: who, what, when, where, why, wins, how, how much.

WHO, ou quem, discute sobre as pessoas envolvidas na ação. No caso de uma tarefa normalmente estamos querendo indicar o responsável pela tarefa, ou seja, quem tem que garantir que algo vai acontecer. No caso de projeto “quem” pode significar muita gente e temos que identificar pelo menos algumas classes: quem pede, quem autoriza, quem paga, quem recebe, quem usa, quem se beneficia, quem pode ser prejudicado. Imagine um gerente de vendas comprando um sistema de venda operado em smartphones que será pago pelo departamento de marketing. Veja quantos estão envolvidos?

WHAT, ou o quê, discute conceitualmente o que vai ser feito. Normalmente é uma descrição do que deve ser alcançado sem nenhuma relação a forma como vai ser feito, o HOW, ou como. Em desenvolvimento de software a divisão entre “o quê” e “como” é normalmente encontrada na diferença entre a análise e o projeto. As histórias do usuário deveriam ser sempre ligadas ao “o quê”, cabendo à equipe a definir “como”, porém temos que aceitar que em um método ágil muitas vezes a história do usuário inclui decisões tecnológicas que seriam “um pecado” em métodos como a Análise Essencial.

WHEN, ou quando, e WHERE, ou onde, são importantes de uma forma diferente, pois normalmente agem não como requisitos, mas sim como restrições. “Quando” normalmente se refere a prazos de entrega, enquanto “onde” se refere a locais de execução ou de entrega.

Finalmente, os novatos dessa lista: WIN e HOW MUCH.

Obviamente “HOW MUCH“, ou “por quanto”, indica o valor do investimento do projeto. Isso é importantíssimo para definir não só o ROI do projeto, mas também várias questões de implementação e execução. Uma coisa é você pedir uma bijuteria  para ir a uma festa, outra coisa é uma jóia de ouro feita a mão por um designer conhecido. O investimento a ser feito em um projeto fala muito do tipo de tecnologia esperada, da segurança a falhas e da complexidade e funcionalidade esperada.

Já o WINS, o mais novo termo agregado à lista, e que não é bem uma pergunta, procura indicar os benefícios esperados do projeto. Cada vez mais o foco do desenvolvimento de um projeto tem mudado do que deve ser feito para o benefício que deve ser alcançado. Principalmente no caso de projetos ágeis, onde o valor entregue é o guia do desenvolvimento, esse conceito é mais importante. Entenda os benefícios de seu cliente e estará pronto para discutir o valor do produto.

6W2H, uma técnica simples de aprender, fácil de usar, de alta comunicabilidade. Uma técnica usada em projetos tradicionais, porém totalmente ágil.

The post Na Sprint zero, entenda seu projeto com 6W2H appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

A questão discutida foi:

Quanto vocês estimam de esforço para fazer o que vou pedir.

O motivo foi que o PO necessitava de uma função porém, como não era essencial, só estava disposto a pagar uma certa quantidade de pontos de esforço por ela. Caso ela ultrapassasse o limite estabelecido por ele, outras funcionalidades eram mais importantes.

A proposta que fica é que o PO sempre tenha ideia de qual o valor, em pontos de esforço, ele estaria disposto a pagar para ter certa funcionalidade e ficar satisfeito. Representaria, de certa forma, o "preço justo" do PO para aquela funcionalidade.

Isso lembra um pouco a prática original de definir o valor de negócio da história de usuário, porém a unidade daquele valor nunca foi estabelecida como a mesma unidade de esforço, e o conceito de preço justo também nunca foi citado.

Por que isso seria útil?

Primeiro, podemos ao longo do tempo acertar o conceito do "preço justo" com o "preço técnico", aquela previsão de esforço feita pelo Time. Isso faria com que o PO tentasse compreender melhor a dificuldade de implementação das funcionalidades e também que a equipe tentasse entender melhor se sua velocidade está atendendo as expectativas do usuário.

O estabelecimento da razão preço justo/preço técnico, que chamaremos de razão de produção, também serviria como padrão de produtividade que ajudaria a balizar uma equipe SCRUM em relação às outras, principalmente quando o PO fosse o mesmo. Assim, uma equipe que produzisse duas vezes mais pontos de esforço que outra equipe só teria essa diferença confirmada caso sua razão de produção fosse a mesma.

Também ajudaria a definir prioridades, pois implementar histórias com maior razão de produção é mais eficiente e provavelmente agregaria maior valor ao PO.

Como desvantagens, podemos analisar que seu uso no início do projeto é bastante complicado para o PO. Porém, podemos estabelecer uma técnica semelhante à usada para estabelecer o padrão de medida de pontos de esforço, i.e., escolher a menor tarefa do primeiro Backlog de Produto e dar o valor 2 para ela.

A ideia é que após a equipe estimar pela primeira vez suas histórias o PO daria o preço justo para elas de forma que a história que adicionasse a menor quantidade de valor na primeira Sprint tivesse o preço justo de 2.  

Fica agora para o leitor a pergunta: você já fez algo parecido? Qual a sua opinião? Qual a sua experiência?

The post Quanto quer pagar? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No primeira artigo (O Scrum Coordena Ações de Forma Completa) discutimos como os quatro ato de fala essenciais para o sucesso de uma conversação para ação aparecem no SCRUM.

Lembramos que esses quatro atos de fala são:

1. o pedido do cliente,
2. a promessa do executor,
3. a entrega pelo cliente e
4. a aceitação pelo executor.

Uma questão importante no livro é sobre como os interesses do cliente devem ser endereçados pelo executor quando tenta completar as condições de satisfação do cliente em relação à ação sendo tomada.

É importante entender que um cliente, quando solicita um objeto ou serviço, não está diretamente interessado naquele objeto ou serviço, o que eu chamo em sala de aula como o "objetivo" do cliente, mas sim em atingir alguma meta de negócio, o que eu normalmente defino como o "interesse do cliente". Assim, quando um cliente solicita um relatório, por exemplo, não está propriamente interessado no objeto relatório, mas sim na forma como vai usar as informações do relatório.

A questão importante é que os pedidos são normalmente feitos de forma objetiva, muitas vezes escondendo deliberadamente as preocupações ou interesses do cliente. Assim, se um cliente deseja poder estudar quais seus melhores clientes ele provavelmente vai pedir para a equipe um "Relatório de Venda por Cliente, ordenado pelo valor comprado". A equipe, desconhecendo o verdadeiro interesse, vai fazer exatamente esse relatório, atendendo as condições de satisfação explícitas, mas não atendendo condições implícitas.

A solução para isso é não só entender O QUE deve ser feito, mas PORQUE deve ser feito.

Uma história do usuário bem definida deve dar essa informação ao desenvolvedor.

Consultando a página de Wikipedia para "user stories" é possível encontrar pelo menos quatro formatos básicos. Não é de se espantar que três desse formatos não se preocupem apenas com o que deve ser feito, mas também o porquê de estar sendo feito.

O formato original de uma User Story é:

Como <papel>, eu quero <objetivo/desejo> de forma a <benefício>

Assim nosso pedido deveria ser inicialmente:

— Como gerente, eu quero o relatório de vendas ordenado por valor, de forma a conhecer meus melhores clientes.

Já podemos ver que a equipe poderia perguntar um pouco mais e propor outros relatórios, ou outras formas de entregar a informação "melhor cliente", ou questionar qual é esse valor (receita total, lucro total, período de tempo, etc…). Porém, como a verdadeira função do desenvolvimento é entregar valor, Criss Matt sugere uma inversão:

Para <receber benefício> como <papel>, eu quero <objetivo/desejo>

No nosso exemplo:

— Para conhecer meus melhores clientes, como gerente, eu quero o relatório de vendas ordenado por valor.

A diferença é pequena, mas podemos entender que o foco da frase muda do relatório para o motivo.

Finalmente, minha preferida usa o conceito do 5W.

Como <quem> <quando> <onde>, eu quero <o que> porque <porque>

No nosso exemplo:

— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores clientes.

E, após uma discussão hoje em uma reunião de projeto poderia ainda adicionar:

Como <quem> <quando> <onde>, eu quero <o que> porque <porque>, por <quanto>

No nosso exemplo:

— Como gerente, até o dia 30 de julho, para usar durante a reunião de vendedores, eu quero o relatório de vendas por cliente ordenado por valor porque quero conhecer meus melhores clientes, por até 8 pontos de esforço.

Dessa forma, conhecendo os verdadeiros interesses do PO, a equipe pode realmente agir para melhorar o projeto ao fazer sua promessa.

The post O Cliente Não Quer o Que Pede appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Aproveitando a leitura de "Conversations For Action and Collected Essays: Instilling a Culture of Commitment in Working Relationships", uma coleção de artigos não publicados de Fernando Flores editados por sua filha Maria Letelier, podemos entender melhor algumas de nossas práticas. Flores é um pesquisador e empresário na área de coordenação de trabalho. Suas teorias foram aplicadas em vários produtos de diferentes empresas. Entre suas motivações está melhorar os processos de gerência.

Uma de suas teses é que quando estabelecemos uma conversação para que uma pessoa, o cliente, obtenha um serviço de outra, o executor, devemos passar por quatro atos de fala: o pedido do cliente, a promessa do executor, a entrega pelo executor e a aceitação pelo cliente. Apenas quando passamos por todos esses passos um trabalho está completo.  

Os problemas de gerência acontecem quando esses dois atores e quatro atos de fala não são claros ou não são feitos:

• clientes e executores mal definidos,
• pedidos mal feitos,
• promessas não cumpridas,
• entregas não informadas e
• aceitações não executadas ou postergardas (para quando é tarde demais para refazer o serviço não conforme)

são as pragas que assolam a gerência. Esses atos de fala precisam ser explicitados e isso é responsabilidade dos métodos e ferramentas de gerência.

Analisando o Scrum podemos ver que ele atende perfeitamente as condições de Flores, explicitando os atores e cada uma das fases.

Primeiro ele exige que existam esses dois atores, o cliente e o executor. Claramente o cliente no Scrum é o Product Owner, enquanto o Time é o fornecedor. Não há necessidade que essa conversação seja feita por apenas duas pessoas e podemos aceitar o Time claramente como o segundo ator. Porém também devemos entender que o Time entra na conversação como um “todo”. Assim todos são responsáveis por suas promessas.

Uma história de usuário no Product Backlog corresponde a um pedido do cliente. Quando esse pedido é estabelecido inicia-se o que Flores chama de estágio de negociação. O objetivo dessa negociação é que cliente e executor concordem nas Condições de Satisfação, outro termo específico que significa as condições que tem que ser preenchidas pelo executor, muitas delas inicialmente implícitas. É importante que o executor entenda os interesses reais do cliente em relação à tarefa. Um bom exemplo usado no livro é o cliente solicitar ao executor que passe o grampeador. Caso o executor passe um grampeador sem grampos ele provavelmente cumpriu exatamente o que o cliente pediu, mas como não atendeu as verdadeiras expectativas do cliente, i.e. grampear folhas, seu trabalho foi inútil.

Quando o Time aceita uma história do usuário no Sprint Backlog ele está fazendo uma promessa. Nessa promessa ele se compromete a atender todas as condições de satisfação dentro do prazo combinado com o cliente (no caso, o fim da Sprint). A promessa termina o estágio de negociação e muda o universo. Agora o cliente espera que a promessa seja cumprida e vai agir no futuro confiante disso.

Com a entrega o executor avisa ao cliente que terminou o seu serviço. Mas isso não encerra o processo, pois o cliente tem que poder verificar se o serviço foi feito e dar o aceite. Esses dois passos são feitos na Reunião de Revisão.

Vemos então que com seus poucos mecanismos o SCRUM garante que todas as ações combinadas entre as partes passem pelos quatro estágios que Flores considera essenciais para uma boa coordenação de ações.

The post O Scrum Coordena Ações de Forma Completa appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.