Assim como qualquer modelo, framework ou ferramenta, existe uma tendência natural das pessoas acreditarem que o artefato resolverá os problemas organizacionais simplesmente por estar sendo aplicado. A partir das minhas andanças como consultor, me deparei com diversas situações onde as pessoas disseram que tentaram aplicar os OKRs e não obtiveram sucesso.

No texto a seguir, compartilharei um compilado de aprendizados e dicas para quem já lida com o framework ou para quem está considerando levá-lo para o seu dia a dia.

1) Qual a relação entre OKR e pensamento estratégico?

Um grande desafio nas organizações diz respeito a como decompor sua estratégia. Tudo começa com a construção de um pensamento estratégico que, em linhas gerais, passa por três grandes etapas: (1) coleta de informações; (2) formulação de ideias; (3) planejamento das ações (essas diretrizes e mais dicas podem ser vistas em Strategic Thinking: A Step-by-step Approach to Strategy and Leadership).

É fundamental que a organização entenda o que está mudando no mercado em que ela atua, como a concorrência tem se posicionado diante de tais mudanças e como a organização está operando hoje.

Passada a etapa de entendimento do contexto, o próximo passo de um pensamento estratégico é o levantamento de desejos, hipóteses e necessidades. É importante que a organização crie uma visão futura inspiradora e que garanta a sustentabilidade do negócio diante dos desafios que ela enfrentará.

O último passo é o planejamento daquilo que será feito. A organização precisa compreender quais são as opções de ações e, com muita clareza, deverá escolher o que será feito e o que não será. Neste momento, é essencial que haja uma clareza do que é prioridade dentro de uma perspectiva de curto, médio e longo prazo. Costumo dizer que prioridade é uma palavra que não deveria ser colocada no plural porque quando tudo é prioridade, nada é prioridade.

Pois bem, então o que OKR tem a ver com o pensamento estratégico exposto acima?

Quando falamos que o OKR é a composição do que desejo alcançar (objetivo) e como vou medir o progresso (conjunto de resultados-chave), precisamos partir de uma referência, que no caso do pensamento estratégico se dá através da coleta de informações. Se eu não conheço meu contexto atual, como eu posso definir onde eu quero chegar?

Além do mais, uma visão clara é necessária para orientar o processo de criação dos OKRs. Quando a organização não consegue estabelecer seu norte, qualquer caminho (ou no caso OKR) servirá. O problema dessa condição é que ela gera desperdício de dinheiro, esforço e energia.

Por fim, os OKRs nos forçam a fazer escolhas quando precisamos pensar no que será o foco de um trimestre, por exemplo. Ao definir poucos objetivos, estamos garantindo que a organização estará voltada naquilo que é o mais importante para o horizonte de tempo determinado.

Portanto, lembre-se: sem estratégia, não faz sentido a aplicação de OKR.

2) Quais problemas você pode resolver com OKRs?

Se você deseja comunicar a estratégia da organização, melhorar a transparência, trazer senso de propósito para as equipes e conectar o trabalho das pessoas com os resultados do negócio, OKR pode ser uma boa forma de você chegar lá.

2.1 – Comunicação da estratégia

A partir do momento em que a organização tem a sua estratégia estabelecida, os OKRs que serão desenhados pelas equipes deverão se comunicar com a mesma. Em outras palavras, caso existam OKRs que não estão conectados com as diretrizes estratégicas do negócio, eles deveriam ser descartados.

2.2 Transparência

Ao acompanhar semanalmente o progresso dos resultados-chave, validar e comunicar mensalmente os resultados dos OKRs e refinar trimestralmente os avanços em um momento de inspeção e adaptação, a organização reduzirá uma natural assimetria de informação que existe nas hierarquias e nos silos departamentais. Ficou na dúvida de como aumentar a transparência? Siga o fluxo abaixo.

Ao atingirmos as cadências mencionadas na imagem acima, aumentamos a visibilidade do que está acontecendo no negócio e deixamos os problemas palpáveis para serem tratados.

2.3 Conexão do trabalho com os resultados

Ao atrelar as iniciativas (ex: projetos, evoluções de um produto) com os resultados do negócio, trazemos um senso de propósito que pode motivar e engajar as pessoas no trabalho que está sendo feito.

Como exercício, tenho proposto uma amarração onde toda iniciativa trabalhada por uma equipe (ex: projeto, história de usuário etc.) deve ter um objetivo e uma clareza do impacto no negócio, além da sua descrição e critério de término.

O exemplo abaixo é uma situação de uma equipe que, a priori, tinha recebido a “demanda” de contratar uma solução de força de vendas. Ao conectar tal demanda com o objetivo do negócio e com os resultados-chave, a equipe conseguiu ter maior entendimento da importância do trabalho que seria feito.

Ao unir a entrega com o resultado, você garantirá a necessidade das pessoas olharem os números e os dados da organização. Além disso, você evitará que a equipe invista tempo e esforço para atender uma demanda que não gera impacto nos objetivos do negócio. E em último caso, mas nem por isso menos importante, você forçará a equipe se questionar o porquê de estarem fazendo algo que não impacta diretamente nos objetivos do negócio.

3) Qual a importância das métricas na definição dos OKRs?

Indicadores de negócio são as melhores medidas para avaliar o progresso em direção aos objetivos. Se você está em busca de sair de um modelo onde há uma cobrança por entregas (output) e deseja ser cobrado por resultado (outcome), defina resultados-chave (key results) que se acoplem com os indicadores de performance (KPI) da organização.

Lembrando que a sigla OKR é composta de duas partes (objetivos e resultados-chave), um KPI que precisa ser melhorado será um excelente ponto de partida para criar um OKR e se tornará um resultado-chave para um objetivo.

Lembre-se: OKR e KPI funcionarão perfeitamente juntos dado que os KPIs ajudam a monitorar o desempenho e a identificar problemas e áreas de melhoria no modo atual de operar da organização. Já os OKRs, contribuem na resolução de problemas, na melhoria de processos e no impulsionamento de inovações.

Para exemplificar, gostaria de compartilhar um caso real de uma organização que tinha como objetivo “Expandir os talentos da área de produto” e possuía como indicadores de performance o tempo médio de contratação, o número de vagas ocupadas e a pesquisa de satisfação. Depois de uma sessão de definição, saímos com o seguinte OKR:

Objetivo: Expandir os talentos da área de produto.

Resultados-chave:

• Contratar 4 novas pessoas de desenvolvimento para aumentar a senioridade da equipe.
• Aumentar o resultado da pesquisa de satisfação de 75% (resultado no último trimestre) para 85%.
• Reduzir o tempo médio de contratação de 45 dias para 30 dias.

4) Dicas práticas

Antes de finalizar o texto gostaria, de compartilhar 6 dicas práticas para você revisar sua estratégia de adoção de OKR:

1. Tenha o apoio executivo: OKR, assim como qualquer outra mudança organizacional precisa do suporte executivo para acontecer. Acreditar que apenas movimentos locais (debaixo para cima) farão com que a transformação aconteça é começar o jogo perdendo. Portanto, é fundamental que os OKRs da empresa se desdobrem para os times.
2. Não defina muitos objetivos: independente do contexto (empresa, equipe, tribo etc.), tenha de 2 até 3 objetivos para garantir que as pessoas estejam focadas naquilo que importa durante o trimestre.
3. Tenha resultados-chave mensuráveis: se você não consegue medir, você não saberá se está alcançado o seu objetivo. Não criei resultados-chave para métricas que não existem. Se você quer ter bons OKRs, coloque um esforço para ter as métricas disponíveis.
4. Não tenha mais do que 3 resultados-chave por objetivo: se é muito difícil de medir um objetivo talvez ela possa ser repensando, reescrito ou reestruturado.
5. Deixe os resultados visíveis para todas as pessoas da organização: visibilidade é alma para um melhor alinhamento e para que os problemas que surgirem de fato sejam resolvidos.
6. Evite resultados-chave orientados por tarefas (ex: entrega de projetos): foque em resultados orientados ao negócio porque isso ajudará a organização a traduzir os benefícios de uma nova abordagem de trabalho e suportará a ideia de equipes multidisciplinares.

Conclusão

OKR é uma ótima forma de pensar de forma estratégica e fazer com que as pessoas colaborem na execução daquilo que a organização busca conquistar. O framework em si é bem simples, porém sua adoção, nem tanto.

Pensando em sistematizar a mensagem deste post, resolvi criar um Canvas que te ajudará no momento de desenvolver os OKRs na sua organização.

Basta seguir os passos sinalizados pelas setas e responder às perguntas necessárias em cada um dos quadrantes. Comece pela estratégia, defina os objetivos, crie os resultados-chave, priorize as iniciativas e defina as áreas que precisarão colaborar com aquele OKR. Cada linha do quadro representará um OKR.

E você, quais têm sido os desafios e os principais aprendizados com OKRs? O que achou do OKR Canvas?

Compartilhe comigo sua opinião nos comentários abaixo!

Referências:

• Como definir OKRs em equipes ágeis?
• The Art of the OKR
• Blog do Felipe Castro

The post OKR: lições aprendidas para você começar a aplicá-lo de forma efetiva first appeared on Plataformatec Blog.

Em praticamente todas as empresas que já trabalhei, existia (e imagino que ainda exista) algum tipo de dívida técnica. Em algumas, para não falar todas, presenciei o cabo-de-guerra entre a equipe técnica, desejando tratar esses itens e defendendo o porque são importantes, e os responsáveis pelo produto, promovendo a criação de novas features.

Neste post eu vou te dar pelo menos um bom motivo para pagar dívidas técnicas, deixar uma dica de quando fazê-las e uma sugestão de como priorizá-las.

Porque fazer

Facilidade de manutenção, ganho de performance, compatibilidade com novas tecnologias, diminuir o tempo que o time gasta lidando com os sintomas dessa dívida técnica (e claro, o tempo que seu time passa lidando com esses sintomas, ele está perdendo de fazer novas features, que melhorariam seu time-to-market)… Existem vários ótimos motivos pra investir esforço e resolver a causa raíz, mas eu vou falar só de um.

Quando todos argumentos se esgotarem e ainda assim ficar a impressão de que “isso é capricho de desenvolvedor”, ainda vale a pena. Por quê? Pela satisfação dos seus funcionários.

Qualquer empregador vai falar que achar mão de obra especializada é difícil. Será que não vale incluir um item no seu backlog pra manter um bom empregado?
Você ralou para achar um especialista, e agora que o encontrou, negligenciar a opinião dele pode gerar insatisfação.

Recentemente conversei com um gerente de produto de uma startup, e ele disse que uma das perguntas da entrevista que passou era: “se um desenvolvedor ameaçar sair caso um item X não seja desenvolvido, o que você faz?”
Segundo ele, várias respostas estariam certas na linha de entender esse item X, mas existe uma resposta errada: “é só um desenvolvedor, eu deixo sair”.

Talvez você não seja surpreendido com um funcionário falando isso explicitamente, mas ligue seu radar se a equipe reclamar muito de dívida técnica. Às vezes isso já é um indicativo da infelicidade desses profissionais e currículos podem já estar sendo disparados para outras empresas.

Quando fazer

Se você leu a seção acima e ficou convencido, ou já começou o texto com a intenção de lidar com dívida técnica, a partir daqui eu posso te ajudar.

Aceitar que vamos trabalhar com dívida técnica não significa que vamos parar tudo e ficar semanas focados nesses itens.

Importante: estou considerando aqui que os “juros” dessa dívida técnica estejam sob controle. Se não estamos fazendo nada da dívida e seria apenas uma melhoria para o processo, essa sugestão se aplica. Agora, se você tem um incêndio, talvez você precise de um plano de ação mais agressivo, incluindo talvez parar e trabalhar apenas na dívida técnica.

No universo do Scrum, o termo “hardening sprint” é usado para designar uma sprint inteira dedicada a consertar bugs e resolver dívidas técnicas. Deixo claro que por mais que o termo seja usado, o Scrum desaconselha totalmente essa prática, sugerindo por exemplo, considerar uma parte do esforço da sprint para tratar esses itens.

Recentemente estive com um time que tinha uma quantidade considerável de dívida técnica e, por alguns meses, até se dedicaram a trabalhar apenas nelas. Foi um período de insatisfação tanto das pessoas desenvolvedoras, quanto das pessoas de produto. Com o tempo, eles voltaram ao desenvolvimento de features, e o backlog de dívida técnica ficou parado, onerando capacity do time com pequenas demandas originadas das mesmas. Eles não trabalhavam com Scrum, nem nenhuma outra metodologia/framework. Existia, porém, um quadro tipo kanban (k minúsculo aqui).

A solução então para garantir que dívida técnica seria endereçada sem paralisar totalmente a entrega de features foi usar limites de WIP (Work in Progress).

O time não utilizava Kanban, nem limites de WIP (e nem era algo para se implantar no momento), mas chegamos num combinado:
Em qualquer dado momento, existirá um item de dívida técnica no quadro do time, sendo trabalhado.

Essa estrutura garantiu que existia um espaço para trabalhar em resolver dívida técnica, e tranquilizou stakeholders no sentido de mostrar que não iríamos “parar tudo” para trabalhar nesses itens.

Dependendo do tamanho do seu time e da sua necessidade, esse limite de WIP pode ser diferente de 1.

Essa ideia pode ser adaptada para um time com Kanban propriamente dito, com a criação de uma raia dedicada e limite de WIP considerando o tipo de demanda da “dívida técnica”.

Como priorizar

Não é só porque garantimos um espaço pra resolver itens de dívida técnica que não precisamos priorizá-las.

Se foi trazida a necessidade de fazer, é porque vamos ganhar alguma coisa, e se estamos falando de valor, podemos priorizar de alguma forma.

Dívida técnica, por natureza, não é algo que vai gerar valor para seu cliente ou usuário, pelo menos não diretamente – se gera valor, deveria estar com o resto do backlog para priorização. Como priorizar, então?

Dado esse dilema, achei na literatura referências à matriz GUT. Em resumo, avalia-se o backlog em Gravidade, Urgência e Tendência. Cada item recebe uma nota nessas três categorias, e o problema com somatória mais alta seria o mais prioritário. Porém isso não me atendia.

A maioria dos problemas não tinham gravidade mensuráveis, e urgência era só quando a bomba estourava. A tendência era uma incógnita.

Usei então a estrutura de BVP: Business Value Points. Seria a definição de critérios que faziam sentido para o time, com pesos ponderados.

Note que esses critérios só fazem sentido para a equipe que estava trabalhando comigo. Você pode usá-los como referência, mas pergunte-se se refletem totalmente a necessidade do seu time.

Existe um critério nessa lista ligado à valor monetário, mas seu peso é o menor, dado que os itens aqui não tem a natureza de impactar financeiramente a empresa, mas ainda assim pode ser relevante (até como desempate).

Daí, foi só jogar os itens e ver o resultado dado a média, considerando os pesos (dados fictícios):

O time então pegou o primeiro item da lista e começou a desenvolvê-lo.
Durante as cerimônias de planejamento, a matriz é revista e atualizada, para que assim que o item em WIP for finalizado, puxarmos o próximo.

Achou que este artigo te ajudou? Tem problemas com dívida técnica e não cobrimos aqui? Deixe nos comentários!

The post Dívida técnica: Por que fazer, quando fazer e como priorizar first appeared on Plataformatec Blog.

Trying to get a better understanding of this subject to talk to clients and stakeholders in general, I decided to collect real project data and analyze the relation between amount of story points of the cards and the time it took for each to be developed, counting since the time they started to be developed until the moment they are delivered to production, the famous Lead Time.

Disclaimers

Before we start, some disclaimers about the context of the project:

• Right in the first few weeks of the project we already had the first big problem with story points: subjectivity in estimate the cards. Why this card is worth 3? How do I know this card is twice or thrice the size of the X card? What do I consider in this estimative?
• Thus, it was suggested to the team to utilize some criteria to estimate, intending to reduce this subjectivity.
• My friend and colleague Henrique Oliveira suggested a Fibonacci-like matrix, taking into account T-Shirt Size estimates, to estimate the cards, that helped the team a lot. Check it below:

• Cards estimated as 13 points or higher were broken into smaller cards, as the only time we worked with a card with 13 points, it exceeded the timebox of the sprint, which was 10 business days. So we decide to do not let any card with 13 or more story points to be added to the sprint backlog.
• Cards were broken down into smaller cards in a way that they delivered something functional in production, so that the backend and frontend stayed together on the same card.

A look into the data

I began by collecting the data of the project as a whole and analyzing the lead time graph with all cards that had already been finished or that were in production.

After acquiring this data, I segmented them by the amount of story points and analyzed them individually, having the following graphs:

Cards with 1 story point

Cards with 2 story points

Cards with 3 story points

Cards with 5 story points

Cards with 8 story points

Cards with 13 story points

Data Analysis

After analyzing the data, I reached some conclusions:

• It’s possible to verify that cards worthing 3, 5 or 8 points have a development time (lead time) similar, not being possible to find a correlation between time and the number of story points (it is not scalar).
• If we take a category with plenty of samples, like the cards with 5 points, it’s evident they differ a lot, not being possible to make some affirmations such as “a card worth 5 points takes between X and Y days to finish” when X and Y a small interval of days (1 to 3 days). The same happens with cards with 3 and 8 points.

Observation: Data referring to cards worth 1, 2 or 13 story points were excluded from the individual analysis, because there was little data to be analyzed individually.

Other Analysis beyond story points x lead time

I reached more conclusions about the use of story points that I would like to share with you all:

• At the beginning of the project, when we started to use story points, the subjectivity was very high. By establishing some criteria for estimation, we were able to stabilize it, making the time of development vary a lot less, increasing predictability. If you want to develop this with your team, consider checking out this article from Mike Cohn.
• With the addition of more scoring criteria, like test complexity, dependency on people that are not in the team (internal or external to the company), risks related to the cards and more, we lowered the lead time variability and increased the card delivery rate by breaking the card into smaller ones.
• Many times people relate story points with only the development effort, and this makes the team consider only the time of the Execution of a task. Another point is that the testers/QAs and UXs/designers, have little to no involvement in the estimatives. Making the team think not only about development, but also about the duration of the process as a whole (considering the steps of code review, tests, deploy, etc) and inviting more people to share their concerns about the estimatives helps to improve the predictability of the team.
• With help from metrics like lead time breakdown and CFD, the process of stabilizing the scoring was much easier, as it made the team think about the whole process and showed in which step of the process the team was spending the most time with.

Conclusions

The major conclusions I had were:

• It wasn’t possible to relate time of development (lead time) with Story Points directly, as the goal of the study was.
• It is important to say Story Points should be used inside the team level. If you want to know more about this subject, I recommend the reading of this text from Troy Magennis.
• It was possible to increase the predictability of team delivery and stabilize the process of development using story points with other tools at the same time.
• There are indications that, when you add more criteria to the estimation to breakdown the cards into smaller cards, the smaller the risk/effort/complexity will be and, consequently, the predictability you also increase.
• An important point here is that story points and other estimative methods consider only the moments in which a demand is being worked on, and not consider/can’t predict the time that a demand will be staying in waiting to be worked on. Basically, the team considers how long it will take for a demand to be developed and tested, but don’t consider in this estimatives (as it is not possible to predict some points in the middle of the development) how long the demand will be staying in waiting to be tested, to be deployed or how long it will take to resolve a hypothetical impediment. In other words, the process efficiency will impact your lead time, and consequently, the relation between story points with the time of development. This way, it’s plausible that a user story of 1 story point takes the same amount of days that a 13 points user story to be delivered, because of the flow efficiency. If you would like to know more about process efficiency, check this article.

And if you were asked if you would use story points to estimate a deadline for a delivery of a project or card, what would you respond?

I would say that story points, like the matrix for complexity and uncertainty (T-shirt Size), are excellent tools to instigate your team in better breaking user stories down and help with improvements in the processes, however, to estimate deadlines, I prefer to utilize process metrics and other tools, like a Monte Carlo simulation to help predict when a set of cards will be delivered.

What about you? Do you have any experience with Story Points and time estimates? Have you passed through any similar scenario? What’s your opinion about what I shared in this text? Share with us commenting below or in this email contagil@plataformatec.com.br

The post Relation between Story Points and Development Time (Lead Time) first appeared on Plataformatec Blog.

Qual a sua teoria favorita sobre o papel de um líder? Para mim um resumo perfeito é esta fala do Jack Welch em What is the role of a leader. Em resumo, sem a pretensão de captar a emoção de ouvi-lo:

1. Ser o “Chief Meaning Officer”! Deixar claro para todas as pessoas à sua volta: para onde você está indo, por que você está indo e, mais importante, o que haverá para elas quando elas chegarem lá com você.
2. Remover os impedimentos do caminho para que as pessoas possam agir e fazer as coisas acontecerem. Quebre os silos, se livre das burocracias.
3. Ser generoso. Vibrar com o sucesso das pessoas.
4. Ser o “Chief Fun Officer”. Dê seus pulos para tornar o trabalho divertido!

E qual o papel de um líder em uma empresa de produtos digitais? Não deve ser nada diferente disso, certo? Mas afinal, como traduzir estes conceitos para a realidade de uma empresa de produtos?

Trazendo para este contexto, quem melhor traduz o papel de um líder é o Marty Cagan em Empowered Product Teams. Na minha opinião, este conteúdo é o mais relevante que ele publicou direcionado para líderes que estão à frente de empresas de produtos digitais. E por que é tão relevante? Porque coloca de uma forma mais tangível estratégia e cultura, temas muito falados mas pouco colocados em prática.

Motivos de resistência da liderança

Um tópico bem interessante deste artigo é a explicação do por que líderes resistem tanto para empoderar seus times e continuam mantendo o estilo comando-controle.

Segundo ele, existem duas formas de gerenciar uma empresa de produto:

• O jeito errado: “Na maioria das empresas, os times de tecnologia existem para atender o negócio”. De alguma forma, líderes de outras áreas de negócios (vendas, marketing, CEO) acabam direcionando o produto, que é apenas construído pelo time de tecnologia.
• O jeito certo: “Em empresa com forte cultura de produto, times de produto existem para um propósito muito diferente. Eles existem para atender os clientes, de formas que também atendam às necessidades do negócio”. Ou seja, o foco é o cliente e não stakeholders internos. Mas obviamente o produto também tem que ser sustentável para o negócio. Gibson Biddle diz algo semelhante de uma forma mais poética “encantar clientes, de maneiras que sejam lucrativas e difíceis de copiar”.

Marty Cagan conta que conversou com CEOs de várias empresas para entender porque eles continuam trabalhando do jeito errado com desenvolvimento de produtos, mesmo conhecendo o jeito certo. A resposta foi “falta de confiança” no time. A crença é que este modelo de trabalho (o jeito certo) só funciona em empresas que podem contratar profissionais extraordinários, como os do Google, Netflix, etc.

O curioso é que já existem muitos estudos que comprovam que times de alto desempenho não são formados por estrelas, mas sim por pessoas comuns. Aliás, estrelas muitas vezes atrapalham!

“They would be surprised at how ordinary the vast majority of the members of these company’s product teams actually are, and that maybe the important difference lies elsewhere.”

Outra justificativa comum para não empoderar os times é “pessoas de tecnologia não entendem de negócios”! Quem de tecnologia já não precisou respirar bem fundo quando ouviu esta frase? Times de produto precisam do contexto de negócio, para que possam descobrir a melhor forma de resolver problemas dos clientes.

A falta de confiança certamente não é um problema fácil de resolver, já que em muitas situações os times são de fato muito inexperientes. Mas é importante caminhar nesta direção, desenvolvendo as pessoas para que elas possam atuar do jeito certo. Definitivamente, entrar em um ciclo vicioso de falta de estratégia, time inexperiente e comando-controle, não é um bom caminho!

Papel do líder no “jeito certo” de trabalhar

Trazendo para o contexto de empresas de produto, como ser o “Chief Meaning Officer”? Ou seja, como deixar claro para as pessoas para onde você está indo e por que. A Visão e Estratégia de produto são essenciais para trazer este significado e dar um direcionamento ao time, para ele possa trabalhar de forma autônoma.

Visão de Produto

A visão de produto descreve o futuro que queremos criar, em 2 a 5 anos. A importância desta visão é setar um norte inspirador e delimitar um contexto de atuação. Em startups, é muito comum o foco do produto principal ir se perdendo ou o escopo de atuação ficar muito amplo. Isto acontece principalmente quando empresas recebem investimentos e começam a diversificar o portfólio. Sem uma visão para guiar e delimitar as fronteiras, os times de produto podem ficar sem foco, não atingirem resultados e a liderança voltar a assumir o estilo comando-controle.

Estratégia de Produto

A estratégia define qual caminho precisa ser seguido para se alcançar a visão. Um erro comum na definição da estratégia é não fazer uma reflexão do momento atual e traçar uma estratégia pouco realista. Em Escaping the Building Trap, Melissa Peri apresenta um framework bem interessante para definição de estratégia.

Outro artefato, o Product Principles, também ajuda a delimitar o contexto e facilita decisões em priorização. Os princípios descrevem a natureza dos produtos que pretendemos desenvolver e reflexões sobre nossas crenças sobre o que é importante.

Exemplo de coisas que podem ser interessantes explicitar no Product Principles:

• Vamos aceitar desenvolver customizações (features específicas para alguns clientes)?
• Se o produto tem mais de um cliente (vendedores e compradores, por ex), quem vamos priorizar?
• O que é mais importante, velocidade ou qualidade?
• Queremos desenvolver tudo sozinhos ou vamos fazer parcerias?

Uma vez que a Visão e Estratégia estejam definidas, como garantir que elas sejam seguidas? Em empresas com muitos times, como desdobrar a estratégia para os diversos times e manter o alinhamento? No artigo How to Run a Quarterly Product Strategy Meeting, Gibson Biddle, apresenta um processo bem interessante para definição de estratégia de times e também um passo a passo de como estruturar uma reunião de “review” de produto.

Mais sobre o jeito certo de trabalhar

Outras fontes interessantes para entender este jeito certo de trabalhar:

• Escaping the Building Trap, Melissa Perri. Apresenta uma boa explicação da relação entre Customer, Business e o papel do Product Manager em Product-led e Sales-led organizations. As dicas para desenhar estratégia também são valiosas.
• Product team vs Feature Team, Marty Cagan. Reforça de forma bem didática e enfática os conceitos já apresentados em Empowered Product Teams. Feature team é o jeito errado de se trabalhar, no qual os times de produto existem somente para entregar features já priorizadas em um roadmap.
• Coach – Customer Centricity, Marty Cagan. Explica quem são os verdadeiros clientes de um Product Manager: as pessoas que usam o produto! Stakeholders internos (vendas, CEO, etc) não podem ser considerados clientes. Afinal, o time de produto não existe para servir ao negócio!
• Digital or Traditional, Joca Torres. Reflete sobre a diferença do escopo de atuação do Product Manager em empresas Digitais (que tem como core do negócio um software), empresas Tradicionais (que tem como core outros tipos de produto) e empresas que não vendem software, mas tem o software como parte vital do negócio, denominadas born-digital traditional company.

Resumindo

Uma das responsabilidade principais de um líder de produto é definir um norte para o produto e garantir que toda empresa esteja alinhada à ele. Para isso:

• Defina a visão e estratégia de produtos.
• Divulgue para toda a empresa, não apenas para os times de Produto e Engenharia.
• Desdobre a estratégia para todos times.
• Crie cerimônias para garantir o alinhamento entre todos os times.

Caso isso já esteja sendo feito, mas mesmo assim os times não estejam trabalhando com autonomia e alcançando resultados, vale refletir:

• Existe resistência da liderança para empoderar os times?
• Existe um entendimento sobre o papel de um time de produto?
• Se não existe confiança no time, qual é o plano para desenvolver e empoderar este time?

Como tem sido a liderança de produto na sua empresa? Deixe sua impressão nos comentários abaixo.

The post O Papel do Líder de Produto first appeared on Plataformatec Blog.

Neste blogpost vou mostrar a vocês como gerar previsibilidade para o Story Mapping a partir das métricas. Bora lá?

Recapitulando o Burnup

Primeiro, vamos falar brevemente sobre o gráfico de Burnup, a métrica que iremos utilizar como ferramenta.
O Burnup permite acompanhar o progresso e o montante de trabalho concluído versus o tamanho total de um escopo de trabalho, fazendo uma projeção linear baseada no histórico de produtividade do time. Através dele, podemos ter uma noção do quão próximo ou distante estamos de atingir um objetivo, ou seja, o popular “quanto falta para terminar o projeto”.

A leitura deste gráfico é feita da seguinte forma:

• No eixo vertical temos duas representações gráficas, sendo a primeira a quantidade de novos itens inseridos no backlog do projeto/produto, representado pela área colorida (neste caso, em amarelo), e a segunda a quantidade de itens deste backlog que foram finalizadas pelo time, representado pelas barras verticais sequenciais;
• E no eixo horizontal temos uma escala de tempo para visualizar o crescimento dos valores descritos no eixo vertical (neste caso medido em semanas).

Ou seja, conseguimos aqui acompanhar tanto o crescimento do backlog semana a semana quanto o valor de throughputs acumulados que o time vem entregando.

Dados estes valores, podemos projetar três diferentes cenários:

• O Pessimista: projetar a performance futura da equipe com base no menor Throughput histórico;
• O Mais provável: considerar que a equipe terá no futuro um comportamento semelhante ao Throughput “médio” performado;
• O Otimista: considerar que a equipe performará nas próximas semanas igual ao valor de maior Throughput histórico ja registrado pelo time.

Caso queira se aprofundar um pouco mais sobre Throughput e Burnup, recomendo a leitura deste blogpost do Raphael Albino. Agora vamos unir os assuntos!

E o que o story mapping tem a ver com isso?

Uma das etapas finais do story mapping, é fatiar o backlog levantado em objetivos menores e que em um curto prazo já podem entregar valor ao usuário final ou persona cujo problema estamos tentando resolver. Segue um exemplo onde foram definidos os três primeiros objetivos e abaixo o backlog não priorizado (imagem desfocada para preservar a confidencialidade dos dados).

Dado que nós já temos as fatias de entregas mapeadas, e se ao invés de incluirmos o backlog levantado como uma única stack dentro do nosso Burnup, utilizarmos do mesmo artifício de fatiamento e criarmos as visões de entrega de cada release?
Basicamente nós temos a seguinte visão:

Cada fatia entra individualmente como uma porção de backlog isolada. Como a leitura deste gráfico é feita de baixo para cima, logo, a primeira fatia do Story Mapping (a que está no topo e representa o primeiro objetivo de entrega), virá acima do objetivo atual do time (representado pela porção azul do Burnup), e assim sucessivamente, conforme a indicação das setas.
Podemos observar que é possível obter hipóteses de data de entrega, pessimista, provável e otimista, para cada uma das fatias do nosso Burnup, esteja o time já trabalhando nelas ou não. Com isso, torna-se possível setar ou controlar expectativas com pessoas que têm interesse no projeto ou em uma entrega, tanto de forma interna (para o próprio time) como externa (ex: Um patrocinador do projeto).

Munindo o time com estas informações, a equipe será capaz de assumir estratégias melhor direcionadas de acordo com a necessidade. Ex: Negociar escopo caso seja necessário cumprir uma data de entrega específica ou alinhar estratégias de lançamento de um produto dadas as perspectivas de finalização do trabalho que está em vista.
Porém, existem alguns pontos que devemos ter atenção quando utilizamos o burnup como ferramenta de previsibilidade, vamos ver a seguir.

Premissas que impactam diretamente as estimativas/previsibilidade

• As datas de projeção consideram o tamanho atual do backlog e a vazão do time dentro de uma linearidade. À medida que estes valores avançam, estas datas também sofrerão alteração (Ex: um crescimento no backlog ou uma mudança drástica no padrão de entregas do time);
• Mantenha os valores de throughput utilizados para a projeção sempre atualizados. É sempre importante considerar a realidade do time em relação à cadência de entregas para se ter previsibilidade. Afinal, não faz muito sentido eu projetar estimativas de entrega considerando um padrão de comportamento que não condiz mais com a realidade do time, certo?
• Se o time ainda não possuir um histórico de throughput relacionado ao projeto, o ideal seria coletar esta métrica durante algumas semanas para utilizar estes dados como insumo antes de criar-se a expectativa com datas e prazos. Caso seja de fato necessário ter esta ideia de prazo para pelo menos se ter uma perspectiva do quando a entrega seria feita, pode-se utilizar do histórico de outros projetos que o time ja trabalhou. Porém, é preciso levar em consideração diversas variáveis que impactam diretamente na assertividade em utilizar estes valores passados (tais como tamanho da equipe, se a composição do time é a mesma, tecnologias utilizadas, experiências que o time tem neste tipo de projeto, etc.
• Sinalize corretamente a qual releases cada tarefa pertence. É muito importante que cada uma das tarefas do backlog esteja enquadrada dentro do objetivo ao qual ela pertence, não só para as tarefas que foram originadas no story mapping mas também para todas as demais que podem surgir ao longo do caminho devido a processos como o Refining ou task splitting;

Como as datas de projeção/previsibilidade de entrega são extremamente sensíveis, conforme vimos nas premissas acima, minha dica final é fuja de utilizar estas datas como prazos determinantes e utilize como probabilidades de cenários (Ex: Se tudo der certo e nada diferente do habitual acontecer, temos boas chances de entregar por volta do dia DD/MM, mas é esperado que seja perto de DD/MM (de acordo com as linhas de projeção).
Desta forma, caso algo inesperado ou emergencial aconteça, o time consegue responder de forma adequada sem comprometer fortemente as expectativas geradas sobre as entregas.

Resumindo

Utilizando estas duas ferramentas em conjunto, conseguimos ter de forma mais concreta um cenário de previsibilidade que pode ajudar o time a setar expectativas com quaisquer stakeholders que estejam dependentes destas entregas ou possuem algum tipo de interesse sobre elas. Além disso, as próprias pessoas do time terão uma maior sensação de progresso em relação aos objetivos que elas mesmas mapearam e isso os ajudará a tomar melhores decisões ao longo do tempo.
Esta é apenas uma das formas de obtermos melhor previsibilidade das entregas do time. Existem diversas outras ferramentas que podem ajudar também, como o Reality Check 

O que achou desta abordagem? Deixe aqui seu comentário sobre como você trata previsibilidade de entregas dentro do seu time ou nos escreva enviando para contagil@plataformatec.com.br. Caso queira começar a utilizar o Burnup, nós disponibilizamos uma versão gratuitamente através da Planilha de métricas da Plataformatec. 

Abraços e até a próxima!

The post Extraindo previsibilidade à partir do Story Mapping first appeared on Plataformatec Blog.

A delay in a single week of a project creates two different cost types:

• The first is the cost of the team, since they will need to work another week.
• The second is the Cost of Delay, which is the income not collected due to the delay. For instance, suppose the new feature this team is working on would generate a daily income of $100, the Cost of Delay would be $700 ($100 * 7 days).

Since these costs can be high, using tools that provide more visibility on delivery dates is necessary. One tool that can help solve this problem is the Gantt Chart. With the Gantt Chart it’s possible to identify the most frail points of the project (the critical path) where more effort should be made to prevent delays, since a delay in any step of those points will impact the project as a whole.

Even though this tool is great for some types of projects (normally when there is a low uncertainty level), it’s not ideal for projects where the predictability is low due to the variance of the deliverables, as in projects that happen in the field of knowledge (writing a book or software development, for example).

Here at Plataformatec, we have always done our best to make our delivery predictions based on data and ensure they follow proven scientific methodology. The two methods we use the most are:

• Linear Progression
• Monte Carlo Simulation

LINEAR PROGRESSION

In linear progression, we do data analysis on the delivered work items during some time period (in software development we normally work with weeks) and through the study of this information we come up with the best values for the progression. For example: suppose we have the following historic values of work items by week, as shown below:

A value that could be used as a pessimistic projection would be to assume a delivery of 1 work item per week, seeing as we’ve had 5 cases where the throughput was 1 or 0. For the optimist projection we could use either the value of 3 or 4, or even 3.5, as we’ve had 4 instances where the throughput was 3 or higher. Lastly, for the likely projection, a good value would be 2, as it’s the median and the mode of this dataset.

The biggest problem with the linear progression is that we are inputting the values for each scenario, something that can be dangerous if the person operating the linear progression doesn’t have a good grasp of data analytics. Furthermore, linear progression ignores variance. Thus, in work systems with high variance of deliveries, the linear progression tool might not be the best approach.

MONTE CARLO

Another technique we can use is called Monte Carlo, which runs random picks from our historic throughput data to try and find the likelihood of delivery.

I’m having success using this method, however a question that keeps coming to my mind is: “How many interactions are necessary to make the method statistically valuable and the results reliable?”. Looking for an answer to this question, I’ve researched some statistics books, and also the internet, but wasn’t able to find any information that would help.

So I decided to run a study on this subject. Monte Carlo’s objective is to infer the probability of an event, “forcing” it to happen so many times, in order to use the law of large numbers in our favor. For example, if you flip a coin a thousand times, count how many times it falls as “heads”, and divide by a thousand, you will get an inference of the probability of getting “heads”.

To check the quality of the method, I first ran tests over probabilities for which I already knew the expected results. After that, I started increasing the complexity of the problem, in order to see if there was any correlation between the difficulty of a problem and the number of interactions necessary for the inferred value from Monte Carlo to be as close as possible to the calculated one.

The objective of the tests is to see how many interactions are necessary for the inferred value to be close enough to the calculated value that the gain of running more interactions would be too low to compensate the computer power necessary to run it (for a project probability standpoint an error in the first or second decimal values would be acceptable). I’d like to highlight that this blog post is not a scientific study of the subject, and the objective is to understand through inference a good value for project predictions.

THE TESTS

The tests were performed using the programing language R, which can be downloaded in this link. If you would rather use an IDE, I recommend using RStudio.

In each test, I’ve run the algorithm 100 times using the following interaction values: 100 (one hundred), 1000 (one thousand), 10000 (ten thousand), 100000 (one hundred thousand), 1000000 (one million), 10000000 (ten million), 100000000 (one hundred million) e 200000000 (two hundred million). The results of these 100 “rounds” are then consolidated.

THE COIN

The first test that I’ve run was the flipping of a single coin. In a coin flip, there is a 50% chance of it landing on any side, and this is the value we want the Monte Carlo to infer. For that I’ve used the following R code:

FLipCoin  <-  function(iterations)
{
  # Creates  a  vector  with  the  possible  values  for  a  coin  1  =  Heads  and  0  =  Tails
  coin  =  c(0,1)
  result  =  0

  # Flips  a  number  of  coins  equal  to  the  interaction  value  and  sum  up  all  the  times  where  the  coin  landed  in  "Heads"
  result  =  sum(sample(coin,  iterations,  replace=T))

  # Turns  the  value  in  a  percentage  of  the  coin  flips
  result  =  (result/iterations)  *  100

  return(result)
}

# Initiates  variables
result_vector  =  0
time_vector  =  0
control  =  0

# Controls  the  interaction  quantity
iterations  =  100

# Alocates  the  percentual  of  "Heads"  results  in  a  100  size  vector  and  the  execution  time  in  another
while(control  !=  100)
{
  start_time  =  Sys.time()
  result_vector  =  append(result_vector,  FLipCoin(iterations))  
  finish_time  =  Sys.time()

  time  =  finish_time  -  start_time
  time_vector  =  append(time_vector,  time)  

  control  =  control  +  1
}

# Shows  the  percentual  of  "Heads"
result_vector

# Shows  the  execution  times
time_vector

Code language: PHP (php)

Changing the values of the iterations and compiling the results, I’ve got the following table:

• Iterations	Min result	Max result	Expected result	Average result	Average result - Expected result	Result's median	Result's median - Expected	result | Result's Standard deviation
  100	33.00000	67.00000	50.00000	50.02000	0.02000	50.00000	0.00000	5.09368
  1000	43.60000	56.20000	50.00000	49.99440	0.00560	50.00000	0.00000	1.59105
  10000	48.35000	51.78000	50.00000	50.01263	0.01263	50.02000	0.02000	0.51001
  100000	49.58000	51.78000	50.00000	49.99110	0.00890	49.99350	0.00650	0.15805
  1000000	49.85170	50.15090	50.00000	49.99883	0.00117	49.99785	0.00215	0.04811
  10000000	49.95433	50.05807	50.00000	50.00013	0.00013	50.00010	0.00010	0.01564
  100000000	49.98435	50.01637	50.00000	50.00004	0.00004	49.99989	0.00011	0.00516
  200000000	49.98890	50.01195	50.00000	49.99981	0.00019	49.99987	0.00013	0.00345

In the instance of a simple problem, like the flipping of a single coin, we can see that a good iteration value could be:

• between 10M and 100M if you are ok with having an error in the third decimal,
• between 100k and 1M in the second decimal
• between 1k and 10k in the first decimal.

ONE DICE

With the coin test it was possible to infer the number of necessary interactions, based on the desired degree of reliability. However a question remains regarding if this behavior changes for more complex problems. Because of that, I’ve run a similar test with a single six-sided die that has a 16,67% chance of landing on any side.

RollDie  <-  function(iterations)
{
  # Creates  a  vector  with  the  possible  values  of  the  die
  die  =  1:6
  result  =  0

  # Alocates  the  die  roll  results
  result  =  sample(die,iterations,replace=T)

  # Sum  up  every  instace  where  the  die  landed  on  6
  result  =  sum(result  ==  6)

​
  # Turns  the  value  in  a  percentage  of  the  die  rolls
  result  =  (result/iterations)  *  100

  return(result)
}

# Initiates  variables
result_vector  =  0
time_vector  =  0
control  =  0

# Controls  the  interaction  quantity
iterations  =  100

# Alocates  the  percentual  of  "6"  results  in  a  100  size  vector  and  the  execution  time  in  another
while(control  !=  100)
{
  start_time  =  Sys.time()
  result_vector  =  append(result_vector,  RollDie(iterations))  
  finish_time  =  Sys.time()

​
  time  =  finish_time  -  start_time
  time_vector  =  append(time_vector,  time)  

  control  =  control  +  1
}

# Shows  the  percentual  of  "6"
result_vector

# Shows  the  execution  times
time_vector

Code language: PHP (php)

Changing the values of the iterations and compiling the results , I’ve got the following table:

We can see that in this case, the iteration values are the same as for the instance of the coin toss, where a good value could be something between 10M and 100M if you need to have an error in the third decimal, between 100k and 1M for an error in the second decimal and between 1k and 10k for an error in the first decimal.

This test result shows that, either the complexity of the problem has no influence on the number of interactions or that both problems (coin toss and single die roll) have similar complexity levels.

Analyzing the execution times for both problems, it’s possible to see that they took about the same time. This also corroborates with the hypothesis that they have similar complexity levels.

TWO DICE

To test the hypothesis that the complexity of the above problems were too close, and this was the reason for the interaction values to be close, I’ve decided to double the complexity of the die roll problem by rolling two dice instead of only one (it’s important to note that doubling the quantity of functions doesn’t always mean that the complexity order will double as well, as it depends on the Big-O Notation). The highest probability value for two dice is 7, with a 16,67% chance of occurrence.

RollsTwoDice <- function(iterations)
{
  # Creates a vector with the possible values of the die
  die = 1:6
  result = 0
	
  # Alocates the die roll results
  first_roll = sample(die,iterations,replace=T)
  second_roll = sample(die,iterations,replace=T)

  # Sum the vector values position-wise
  result = first_roll + second_roll

  # Sum up every instace where the dice landed on 7
  result = sum(result == 7)

  # Turns the value in a percentage of the dice rolls
  result = (result/iterations) * 100

  return(result)
}

# Initiates variables
result_vector = 0
time_vector = 0
control = 0

# Controls the interaction quantity
iterations = 100

# Alocates the percentual of "7" results in a 100 size vector and the execution time in another
while(control != 100)
{
  start_time = Sys.time()
  result_vector = append(result_vector, RollsTwoDice(iterations)) 
  finish_time = Sys.time()

  time = finish_time - start_time
  time_vector = append(time_vector, time) 

  control = control + 1
}

# Shows the percentual of "7"
result_vector

# Shows the execution times
time_vector
Code language: PHP (php)

Changing the values of the iterations and compiling the results, I’ve got the following table:

Again we find the same interaction quantity for each error level. In the case of this problem it’s possible to identify that it was more complex since the execution for 200M took on average 7.47 seconds longer when compared to the single die roll.

FIVE DICE

The inference that I’ve built until this point is that the complexity of the problem influences very little in the iteration quantities, but to be sure of that, I ran one last test with 5 dice. The highest probability when rolling five dice is the values of 17 and 18, with 10.03% probability each.

Since this problem is a lot more complex than the others I’ve decided to run only 10 times each instead of 100.

RollsFiveDice <- function(iterations)
{
  # Creates a vector with the possible values of the die
  dado = 1:6
  result = 0
	
  # Alocates the die roll results
  first_roll = sample(dado,iterations,replace=T)
  second_roll = sample(dado,iterations,replace=T)
  terceira_rolagem = sample(dado,iterations,replace=T)
  quarta_rolagem = sample(dado,iterations,replace=T)
  quinta_rolagem = sample(dado,iterations,replace=T)

  # Sum the vector values position-wise
  result = first_roll + second_roll + terceira_rolagem + quarta_rolagem + quinta_rolagem

  # Sum up every instace where the dice landed on 18
  result = sum(result == 18)

  # Turns the value in a percentage of the dice rolls
  result = (result/iterations) * 100
	
  return(result)
}

# Initiates variables
result_vector = 0
time_vector = 0
control = 0

# Controls the interaction quantity
iterations = 10

# Alocates the percentual of "18" results in a 100 size vector and the execution time in another
while(control != 100)
{
  start_time = Sys.time()
  result_vector = append(result_vector, RollsFiveDice(iterations)) 
  finish_time = Sys.time()

  time = finish_time - start_time
  time_vector = append(time_vector, time) 

  control = control + 1
}

# Shows the percentual of "18"
result_vector

# Shows the execution times
time_vector
Code language: PHP (php)

Changing the values of the iterations and compiling the results, I’ve got the following table:

Once again we can see that the values for the iterations are the same as above. It’s possible to notice that this problem is clearly more complex, as it took 35 seconds longer when compared to the roll of a single die.

CONCLUSION

After running those tests, it’s possible to conclude that for the use on project management, a good iteration value would be somewhere between 1k and 100M, depending on the error level as shown below:

• Error in the first decimal: 1k to 10k
• Error in the second decimal: 100k to 1M
• Error in the third decimal: 10M to 100M

The value that I’ve been using is 3M, for stakeholder reports. However, when I’m running the method for my own analysis, I use a lower value, somewhere between 250k and 750k.

How about you? Have you tried to run Monte Carlo Simulations? How many iterations are you using? Tell us in the comment section below or on Twitter @plataformatec.

The post Monte Carlo in Practice: Finding the ideal iteration value first appeared on Plataformatec Blog.