finito

Categoria: Enxuto & Ágil

  • Grandes Times de Verdade

    Grandes Times de Verdade

    Há boa ciência por trás dos grandes times. Existem princípios que guiam o desenho e a evolução de times de verdade. É um trabalho sem atalhos. Passa longe da simples imitação de um modelo – seja o modelo Spotify ou qualquer outro. É um desafio que vale a pena porque times de verdade não enganam nem enrolam, eles entregam valor de verdade. 

    De Verdade

    “De verdade” se tornou um sobrenome necessário porque vulgarizamos a palavra “time”. Qualquer grupo de pessoas é tratado como time. Não é bem assim. 

    O primeiro requisito crucial para a formação e identificação de um time é um objetivo. Apesar de seus diversos interesses – e é importante que um time seja formado por pessoas com interesses diversos¹ – os integrantes do time compram a mesma briga. Isso não se dá de imediato. Em um mundo cada vez mais complexo, objetivos quase nunca são cristalinos nem unânimes. A definição do problema – do objetivo – é parte do problema. E é o primeiro passo para a formação de um time. 

    Buscamos a cooperação – o pleno acordo em relação aos fins e aos meios para alcançá-los. Mas sabemos que a competição, agora e em outros momentos da iniciativa, é mais que necessária. Porque só assim podemos explorar a melhor maneira de realizar aquele objetivo. Da matriz ao lado, o único quadrante que deve incomodar, ainda mais quando recorrente, é o conflito. Os demais fazem parte do dia a dia de um time saudável².

    Um time de verdade não se caracteriza apenas por buscar e alcançar os objetivos – por realizar resultados. Isso um bando (pseudo-time) consegue fazer, mesmo que de vez em quando. Em times de verdade há relacionamentos saudáveis e motivadores. Ou seja, nesta matriz, apenas um quadrante nos interessa. Não queremos estar em alianças temporárias – onde todos os comparsas se dão muito bem e entregam muito mal – e muito menos em celas.

    Por entregar resultados enquanto nutre bons relacionamentos, um time de verdade tende a desenvolver uma identidade única. Às vezes ele ganha até nome, marca e mascote. No entanto, a identidade que interessa – a que fica – geralmente é a sua principal característica: entregador, cascudo, corajoso, atencioso, maduro e por aí vai. 

    Este é o primeiro CDP (Core Design Principle) ou Princípio Fundamental para o desenho de times: Forte identidade e senso de propósito. 

    Princípios Fundamentais

    Elinor Ostrom³, Nobel de Economia em 2009, encontrou em um conjunto com oito princípios uma resposta para a Tragédia dos Comuns4. Estamos começando a descobrir que esses princípios podem explicar a diferença entre times bem e mal sucedidos5. Um time aumenta suas chances de sucesso se:

    1. Desenvolver uma forte identidade e senso de propósito
    2. For justo no rateio de benefícios e custos
    3. Tomar decisões de forma justa e inclusiva
    4. Monitorar o comportamento que foi acordado de antemão
    5. Aplicar sanções progressivas 
    6. Sanar conflitos de maneira rápida e justa
    7. Contar com autonomia local
    8. Tiver a garantia de que todos os demais times e níveis da organização utilizam os mesmos princípios de governança listados acima

    Cada princípio será detalhado oportunamente6. Neste momento é interessante destacar o seguinte: Os princípios 1~6 tratam das questões internas de um time; os princípios 7 e 8 tratam da relação do time com a organização e demais equipes. 

    Releia a lista de princípios fundamentais com calma, por favor. É importante.
    Obrigado.

    Repare como o CDP#7 – contar com autonomia local – é chave. Porque é o grau de autonomia conquistado pelo time que vai guiar a configuração de todos os CDPs anteriores. Autonomia não é carta branca. A auto-organização não acontece quando fronteiras não são definidas. Ou seja, a organização propõe ou impõe limites. A partir deles, cada time desenvolve sua própria cultura – seu jeito de fazer as coisas. 

    Existem três fatores principais delimitando o grau de autonomia que será oferecido aos times. O primeiro é subjetivo: confiança. Cabe aqui um pitaco direto de Hemingway: “Só há uma maneira de saber se você pode confiar em uma pessoa: confiando nela.” Se vale pra gente, vale para times.

    Os outros dois fatores são objetivos: as necessidades de integração e padronização da organização. O grau de autonomia possível é inversamente proporcional à essas necessidades. Considere, por exemplo, quanta autonomia há em uma agência bancária. Ou até onde vai a liberdade de um squad do Spotify ou de um time do Google para escolher ou criar as suas próprias ferramentas. 

    Um time de verdade sabe de cor e salteado o que busca. Ou seja, seu alinhamento é total. Ele estará no quadrante A ou B da matriz ao lado, dependendo da cultura e das necessidades da organização. Que fique claro: um time de verdade sempre persegue o espaço A. Porque é sinceramente comprometido com a melhoria contínua. Mas ele compreende e aceita eventuais restrições. 

    Um time de verdade exala maturidade. Tema do próximo post. Até lá!

    Notas

    1. Porque, como já vimos, “só a variedade absorve variedade”.
    2. O modelo de (Bruce) Tuckman, de 1965, se equivoca ao fixar o estágio Storming (confrontação) como o segundo de um total de cinco que caracterizariam o ciclo de vida de um time. As tempestades são relativamente frequentes e isso não é necessariamente ruim nem indesejável em um time saudável. Sobre o modelo: https://pt.wikipedia.org/wiki/Modelo_de_Tuckman
    3. https://pt.wikipedia.org/wiki/Elinor_Ostrom
      Ela também nos presenteou com a Lei de Ostrom: “um arranjo de recursos que funciona na prática pode funcionar na teoria”.
    4. https://pt.wikipedia.org/wiki/Trag%C3%A9dia_dos_comuns
    5. David Sloan Wilson em This View of Life: Completing the Darwinian Revolution (Patheon, 2019) e Herb Bowie no artigo Agile Software Development and the Core Design Principles for Teams.
    6. Converso sobre todos eles na aula Grandes TIMES Pequenos.
    7. Foto de Shane Rounce no Unsplash
  • Por Querer

    Por Querer

    De propósito; Com intenção; De caso pensado; By design.

    Porque alguém nos vendeu a ideia de que, dada a complexidade galopante, só restaria o improviso just in time. Aquela gambiarra embelezada pelo adjetivo “orgânico”. Quem foi que disse que o que é orgânico não foi pensando nem planejado? Caraca, pra que serve o DNA? 

    O Por Querer aparece na nova assinatura deste finito para não deixar dúvidas: pensar e planejar são verbos que não perderam utilidade no século 21, muito pelo contrário. Estão recuperando seu status. 

    Status que teria sido perdido por causa do Agile. Que bobagem. Nada ali diz: não tenha planos, mapas nem bússolas. Tudo ali ensina: use laços de feedback bem curtos. E seja humilde. Que belo filtro faz essa última frase, não?

    Filtro é tudo o que promete o Lean. Para que a gente possa se concentrar no que é essencial. E só. Como seremos ágeis se não formos enxutos?

    E o que adianta ser enxuto e ágil em um mundo que não existe mais ou que nunca existiu? Ser Sistêmico é ver e entender o mundo da forma como ele realmente funciona. É entender a complexidade e saber usá-la a nosso favor. Até porque não há outra opção: ela é inevitável e invencível. 

    finito: sistêmico, enxuto e ágil. Por querer!

    Porque a gente não vai sair dessa sem querer…

    Nota

    Photo by Tim Graf on Unsplash

  • RenDanHeYi

    RenDanHeYi

    Um pouco antes de morrer, Taiichi Ohno — o pai do Sistema Toyota de Produção — foi perguntado: o que você está fazendo? Ele respondeu: pensando em formas de reduzir o tempo gasto entre o pedido do cliente e a entrada do dinheiro¹.

    Do Sistema Toyota derivamos o Lean e muito do que vemos no mundo Agile. A grande constante — obsessão? — é o tempo. Por isso falamos tanto sobre fazer o dobro do trabalho na metade do tempo, otimizar fluxos, entregar continuamente etc. Talvez tenha chegado a hora da China nos sugerir um modelo — um sistema. A obsessão é outra: espaço. E isso pode mudar bastante as nossas conversas.

    Rén d?n hé y? (????), segundo o Google Translate, significa um único. Se Ohno brigava para reduzir o tempo entre o pedido e a grana embolsada, a proposta chinesa visa eliminar a distância entre o cliente e o negócio. Gary Hamel e Michele Zanini explicam assim²: “transmite a ideia de uma relação estreita entre o valor criado para o cliente e o valor recebido pelos funcionários.” É provável que aqui no ocidente a gente comece a falar em Distância Zero. A conversa já começou³.

    E vem de uma maneira muito diferente da forma como iniciamos o movimento Ágil. Porque tudo na China parece superdimensionado. O RenDanHeYi nasceu grande. Hamel e Zanini estudaram a Haier, a maior fabricante mundial de eletrodomésticos. Ela tem 75 mil funcionários. Todos organizados em microempresas que têm entre 10 e 15 pessoas. Ou seja, aquele imenso dragão é um emaranhado com mais de 4 mil microempresas (MEs).

    Existem apenas três tipos de MEs: usuária (200), incubação (50) e junção (3800). As primeiras estão na linha de frente, voltadas para o mercado. Em incubação ficam as novas ideias e apostas (startups, como queira). As junções (nodes) são contratadas — e demitidas — pelas outras duas. Elas representam todo o resto da organização: vendas, design, manufatura, apoio (RH, contabilidade, TI etc). O artigo de Hamel e Zanini detalha os sete fatores que fazem o modelo funcionar. Não vou chover no molhado².

    Coincidências Felizes

    O modelo, por querer, lembra a Web. São diversas partes pequenas fracamente acopladas e organizadas em plataformas. Existem apenas dois níveis hierárquicos entre as MEs e o CEO. O que sugere bastante autonomia e alinhamento. A organização é fractal e a existência de um sistema 4 de verdade — as MEs de incubação — deixaria Stafford Beer feliz da vida. Não apenas por isso, mas principalmente porque parece que a Haier entende e aplica a Lei de Ashby: “Só a Variedade absorve Variedade”.

    Preciso repetir a primeira frase acima: o modelo da Haier copia a Web. É uma grande fábrica que não se vê em uma cadeia de valor e sim numa Rede de Valor. Tom Stewart, que inspirou este velho post, deve ter dado um sorriso sarcástico: uma fábrica funcionando como rede de valor! Dave Gray, de A Empresa Conectada (Novatec, 2013), rabiscou a diferença e riu junto.

    Não há monopólios internos. As MEs usuárias nunca se tornam reféns de junções que não entregam. Elas têm total autonomia para contratar alternativas, estejam elas dentro ou fora da Haier, num desenho que deixaria Russell Ackoff muito satisfeito. Porque ele escreveu, há muito tempo, que essa seria uma característica fundamental de uma organização do século 21. Oras, se realmente acreditamos na economia de mercado, o que justifica a existência de monopólios dentro das nossas empresas?

    Talvez os links dos três parágrafos anteriores apenas dedurem um viés de confirmação. Eu desconfio que eles apontam padrões que a Haier, em uma década, descobriu ou desenhou de forma empírica.

    Seja como for, o fato é que a Haier não é apenas uma colcha de ideias e padrões relativamente raros. O que dá cola e sentido para todo o modelo é a sua diretriz principal, a Distância Zero. E isso é novo.

    Ainda é muito cedo para dizer se este modelo será tão influente quanto o Sistema Toyota. Mas vale a pena prestar atenção³.

    Notas

    1. Citação encontrada em Freedom from Command and Control, de John Seddon (Productivity Press, 2005). Se você quer ter uma visão mais prática do que significa Lean na área de serviços, este é o livro. Que apresenta outra possível coincidência: Seddon insiste bastante na proximidade com os clientes. Sua leitura do que é ser Lean, se devidamente espalhada no mundo ágil, nos teria poupado de alguns mal entendidos. Como algumas brigas contra a variedade, por exemplo.
    2. Em artigo de capa da edição de nov/18 da Harvard Business Review. A versão em inglês está disponível para leitura. Hamel e Zanini vão detalhar a proposta em Humanocracy: creating organizations as amazing as the people inside them(programado para jan/2020).
    3. Em 9/mar uma busca no Google por rendanheyi retornou 7.410 resultados. Hoje (23/mar) já são 43.300.
    4. O Six Sigma abre espaço para o Rendanheyi na GE. Artigo da Bloomberg, de 8/2/19. (Obrigado Cattai!)
    5. Ilustrei aqueles artigos de cinco anos atrás com imagens do QThomas Bower. Faz sentido manter o padrão com a bela Lemon Lime — Fractal Mosaic.
  • A Caixa de Ferramentas do PO

    A Caixa de Ferramentas do PO

    Não são poucos nem triviais os trabalhos do PO. Para inspirar e orientar o desenvolvimento de produtos ele precisa de boas ferramentas. Estamos cheios delas. E isso não é necessariamente bom. Sobram sobreposições e redundâncias. Faltam interfaces para que as ferramentas se comuniquem e possibilitem a construção de uma narrativa lógica e coesa. A organização da caixa de ferramentas do PO dá trabalho¹.Uma caixa de ferramentas bagunçada é uma contradição. Ferramentas devem nos tornar mais produtivos – ágeis de fato. O problema é que vivemos numa era de grandes ideias isoladas e quase herméticas. JTBD, OKR, canvases mil, jornadas de clientes e usuários, User Stories, Job Stories, Value Stories e por aí vai. Existem diversos livros, artigos ou cursos sobre cada uma delas. Mas não são comuns os trabalhos que proponham um conjunto ou, melhor dizendo, um sistema.

    Sistema: para entendermos que o TODO deve ser maior que a soma das partes; Para fazer com que as ferramentas conversem entre si. Como o JTBD troca ideias com um OKR? De que forma eles se relacionam com épicos e histórias? Como eles apoiam a organização e priorização do backlog? Precisamos de um mapa.

    Mapa Rico

    São duas as principais inspirações para a sugestão que segue. A primeira é o Pensamento Sistêmico. Mais especificamente, a Rich Picture proposta por Peter Checkland somada ao DSRP. A segunda fonte de inspiração é o livro User Story Mapping de Jeff Patton (O’Reilly, 2014). Vejamos.O diagrama é formado por três camadas: Bússola, Mapa e Roteiro.

    Bússola: seja dia ou noite, faça chuva ou faça sol, ela sempre nos dá o norte. Em nosso caso, ela sempre lembra as motivações do produto. Motivações, no plural, porque buscamos criar valor para o cliente (expresso no JTBD) e para o negócio (VS – Value Stories). Um GPS sempre ajuda. Aqui ele atende pela sigla OKR (Objectives and Key-Results). Você informa para onde quer ir (JTBD + VS) e ele te guia, mostrando a sua distância em relação aos Resultados-Chave. O ‘O’ de objetivo é o elo entre as três ferramentas.  

    Mapa: se estamos falando de um produto ou serviço que será comercializado, faz sentido que o mapa capture toda a jornada do cliente. Por isso temos um cabeçalho identificando o que ocorre Antes, no Início, Durante e Depois da compra ou contratação. A inspiração aqui é o Service Blueprint. Na primeira linha desenhamos as ações do cliente na forma de um fluxograma. Na linha inferior colocamos o trabalho interno – tudo o que precisa ser feito para que o cliente tenha aquela experiência. Se você registrou Atividades-Chave em um Business Model Canvas, por exemplo, é nessas duas linhas que elas serão desenhadas. Se você identificou Recursos-Chave no Canvas, faz sentido explicar quando e onde eles serão necessários. Daí a terceira linha do mapa. Jeff Patton é econômico nesta camada, mas não desmerece o seu valor. Tanto que a trata como o Backbone (espinha dorsal).

    Roteiro: ou, para ser menos direto, Roadmap + Product Backlog. Porque um backlog orientado pelo negócio, pela experiência do cliente, faz muito mais sentido do que uma fila indiana. Quando alguém vê um item², entende não apenas o que ele é e deve fazer mas também o seu propósito. O contexto está dado: onde e quando aquela função ou atributo é necessário. A posição vertical dos itens indica prioridades. Quanto mais alto, maior a contribuição do épico/história para a realização dos resultados descritos no OKR. Mas não ficamos só nisso. Em cada item devemos registrar o seu valor³. E, oportunamente, também o seu custo. As linhas divisórias do roteiro são traçadas em outro momento, quando já temos razoável noção do que precisa ser feito. Podemos dizer que a primeira linha representa o MVP/MVS (Minimum Viable Product / Solution). O importante é que cada linha (cada versão do produto) se comprometa com resultados. Daí o lembrete ou detalhamento de OKRs no canto direito do diagrama.

    O mapa é uma ferramenta que pode acomodar, como no exemplo acima, outras ferramentas. Não é uma colcha de retalhos. É um sistema. Ou, caso queira, é uma história que deve ser contada de forma colaborativa. E iterativa. O mapa evolui na medida em que navegamos entre os trabalhos de descoberta, exploração, desenvolvimento e entrega.No exemplo acima tivemos que colocar o roteiro no lado direito. A bússola (post-its no topo e anotações no canto) foi junto.

    As informações (quem, o que, quanto, onde, quando) descobertas, o conhecimento (como) desenvolvido e a compreensão (por que) alcançada com o apoio das ferramentas citadas são essenciais para o desenvolvimento de um produto. O Mapa Rico pode ser a principal ferramenta de um PO. Mas, claro, não pode ser a única.

    Notas

    1. E isso justifica, em partes, o intervalo de dois meses desde o último artigo. As sugestões aqui apresentadas foram testadas em uma turma da oficina FDP e com três times do Ateliê de Software, uma empresa que é 100% Ágil há dez anos. Agradeço ao pessoal do Ateliê pela oportunidade e acolhida. E ao Will pela foto.
    2. O diagrama indica quatro formatos possíveis para itens: Épicos, US – User Stories, JS – Job Stories e UC – Use Cases. Poderia ter citado protótipos também. Não são variações do mesmo tema. Cada formato captura informações e perspectivas diferentes. Vale sempre lembrar: só a variedade absorve variedade. E existe coisa mais variada do que desejos, necessidades, restrições e caprichos de clientes e usuários?
    3. Se você pretende utilizar um conjunto da sequência de Fibonacci ou escalas mais simples não importa. Importante é que isso seja pensado e negociado. E que a régua definida para o Valor seja a mesma utilizada na aferição dos custos. 
    4. Rectilinear, de Stuart Caie, ilustra este artigo.
  • Os Trabalhos Essenciais do PO

    Os Trabalhos Essenciais do PO

    O Dono de Produtos deve inspirar e orientar o desenvolvimento de soluções criativas. Para tanto, ele assume a responsabilidade por dez trabalhos essenciais¹. A matriz ao lado sugere a distribuição dos trabalhos em um ciclo com quatro fases²: Descoberta, Exploração, Desenvolvimento e Entrega. Cada fase requer um tipo de raciocínio e lida com matérias-primas bem diferentes (concreto ? abstrato).Aos trabalhos:

    • Entender o Problema: parece uma coisa à toa, mas como é que a gente voa e gera desperdícios quando não começa direito. Problemas são definidos e compreendidos de forma diferente pelos envolvidos, por isso precisamos
    • Conhecer as Pessoas: e seus interesses. Não é apenas uma questão de gerar um mapinha de stakeholders ou desenhar personas. Sem empatia o PO não vai a lugar nenhum. Se não conhecer os interesses em jogo, como o PO conseguiria
    • Negociar Objetivos: identificar e fixar os (poucos) indicadores que servirão como bússola. Da descoberta passamos para a etapa de exploração. O PO começa a
    • Elaborar Hipóteses: cogitando alternativas de solução, comparando as diversas opções concorrentes e validando tendências. As dúvidas mil – inevitáveis neste momento – são atacadas quando o PO seleciona hipóteses e começa a
    • Criar e Testar Protótipos: levando ideias para o mundo real. Essa peneira, depois de alguns ciclos, permitirá ao PO tomar decisões e
    • Criar a Visão e o Roadmap do Produto: um momento chave. O PO inspira através da visão apresentada. A proposta deve ser comprada por clientes e usuários. O desafio precisa ser comprado pelo time. Passado o decisivo teste, é hora de
    • Desenhar o Produto contando Histórias: User Stories, Job Stories, Use Cases? O que menos importa é o formato. As histórias precisam ser coerentes e mostrar com clareza sua contribuição para a realização dos objetivos. Essas histórias compõem um roteiro, um backlog. É responsabilidade do PO
    • Gerenciar o Backlog: definindo prioridades e informando ao time o que precisa ser feito e quais resultados precisam ser obtidos em determinado momento. Além disso, o PO vai
    • Apoiar o Time: tirando dúvidas, orientando e testando, diariamente, o que está sendo desenvolvido. É o olho do dono que engorda o boi. É a presença e cooperação do PO que orienta o time. Em ciclos bem ou mal definidos, o PO deve
    • Acompanhar a Evolução do Produto: monitorando os (pouco) indicadores; Interagindo com clientes e usuários; Se preocupando com a disposição e evolução do time; e se preparando para começar (quase) tudo de novo.

    Falando assim, até parece que é simples a vida de um PO. Não é. Mas a sua formação não precisa ser complicada. 

    Coincidências

    1. Um trabalho é essencial quando sua falta ou má execução compromete o resultado esperado. O mesmo conceito foi utilizado na elaboração do programa FAN – Formação de Analistas de Negócios. Neste caso, são oito os trabalhos essenciais. Quase há uma coincidência com os trabalhos do PO. Quase! Porque, para o PO, o buraco é mais em cima.
    2. A matriz sugerida coincide com o ciclo OODA (Observe, Oriente, Decida, Aja). O destaque para a etapa de Orientação (Exploração) também coincide. Mas a verdadeira inspiração vem de Takeuchi e Nonaka, os vovôs do Scrum (Gestão do Conhecimento – Bookman, 2008). Para saber mais do modelo, veja este vídeo. Para debatê-lo, participe do evento SEA: Sistêmico, Enxuto e Ágil.
    3. Clay Cutter foi compartilhada via flickr por christy sheffield.
  • Os Trabalhos Essenciais do PO

    Os Trabalhos Essenciais do PO

    O Dono de Produtos deve inspirar e orientar o desenvolvimento de soluções criativas. Para tanto, ele assume a responsabilidade por dez trabalhos essenciais¹. A matriz ao lado sugere a distribuição dos trabalhos em um ciclo com quatro fases²: Descoberta, Exploração, Desenvolvimento e Entrega. Cada fase requer um tipo de raciocínio e lida com matérias-primas bem diferentes (concreto ? abstrato).Aos trabalhos:

    • Entender o Problema: parece uma coisa à toa, mas como é que a gente voa e gera desperdícios quando não começa direito. Problemas são definidos e compreendidos de forma diferente pelos envolvidos, por isso precisamos
    • Conhecer as Pessoas: e seus interesses. Não é apenas uma questão de gerar um mapinha de stakeholders ou desenhar personas. Sem empatia o PO não vai a lugar nenhum. Se não conhecer os interesses em jogo, como o PO conseguiria
    • Negociar Objetivos: identificar e fixar os (poucos) indicadores que servirão como bússola. Da descoberta passamos para a etapa de exploração. O PO começa a
    • Elaborar Hipóteses: cogitando alternativas de solução, comparando as diversas opções concorrentes e validando tendências. As dúvidas mil – inevitáveis neste momento – são atacadas quando o PO seleciona hipóteses e começa a
    • Criar e Testar Protótipos: levando ideias para o mundo real. Essa peneira, depois de alguns ciclos, permitirá ao PO tomar decisões e
    • Criar a Visão e o Roadmap do Produto: um momento chave. O PO inspira através da visão apresentada. A proposta deve ser comprada por clientes e usuários. O desafio precisa ser comprado pelo time. Passado o decisivo teste, é hora de
    • Desenhar o Produto contando Histórias: User Stories, Job Stories, Use Cases? O que menos importa é o formato. As histórias precisam ser coerentes e mostrar com clareza sua contribuição para a realização dos objetivos. Essas histórias compõem um roteiro, um backlog. É responsabilidade do PO
    • Gerenciar o Backlog: definindo prioridades e informando ao time o que precisa ser feito e quais resultados precisam ser obtidos em determinado momento. Além disso, o PO vai
    • Apoiar o Time: tirando dúvidas, orientando e testando, diariamente, o que está sendo desenvolvido. É o olho do dono que engorda o boi. É a presença e cooperação do PO que orienta o time. Em ciclos bem ou mal definidos, o PO deve
    • Acompanhar a Evolução do Produto: monitorando os (pouco) indicadores; Interagindo com clientes e usuários; Se preocupando com a disposição e evolução do time; e se preparando para começar (quase) tudo de novo.

    Falando assim, até parece que é simples a vida de um PO. Não é. Mas a sua formação não precisa ser complicada. 

    Coincidências

    1. Um trabalho é essencial quando sua falta ou má execução compromete o resultado esperado. O mesmo conceito foi utilizado na elaboração do programa FAN – Formação de Analistas de Negócios. Neste caso, são oito os trabalhos essenciais. Quase há uma coincidência com os trabalhos do PO. Quase! Porque, para o PO, o buraco é mais em cima.
    2. A matriz sugerida coincide com o ciclo OODA (Observe, Oriente, Decida, Aja). O destaque para a etapa de Orientação (Exploração) também coincide. Mas a verdadeira inspiração vem de Takeuchi e Nonaka, os vovôs do Scrum (Gestão do Conhecimento – Bookman, 2008). Para saber mais do modelo, veja este vídeo. Para debatê-lo, participe do evento SEA: Sistêmico, Enxuto e Ágil.
    3. Clay Cutter foi compartilhada via flickr por christy sheffield.
  • PO: Quem se Habilita?

    PO: Quem se Habilita?

    Não é fácil ser Dono de Produtos. Mas não precisamos levantar restrições como aquelas colocadas pela Toyota para seus engenheiros-chefe. Doze anos de formação? Não precisamos de tanto. Dez mil horas de prática? Não faria o menor sentido.

    Um PO justifica a oportunidade e o poder que recebe quando demonstra conhecimento, comprometimento, criatividade e todo o pacote de soft skills requerido de quem pretende interagir com um sem número de pessoas. Repare: com exceção do primeiro item, não é o tipo de coisa que validamos através de provas, certificados e afins. Exigir tempo de casa ou de experiência também não faria muito sentido. Quantos com tempo de casa não têm raízes profundas em estruturas e hábitos que precisamos evitar ou questionar? Até que ponto a intervenção de um não-especialista ou de gente de fora não seria desejável? E se ela trouxer aquela dose de criatividade que falta?

    Talvez o melhor caminho seja a busca por voluntários. Dado o desafio, ainda que muito mal definido (e assim ele estará), perguntamos: quem se habilita? É provável que o candidato óbvio surja naturalmente. Assim como é possível que a pergunta gere dois tipos de problemas.

    Pior cenário: ninguém se apresentou! Das duas, uma: 1) o desafio não é nada atraente; ou 2) as pessoas estão sufocadas, desmotivadas, desorientadas. Dependendo do caso e da gravidade, talvez nem seja a hora de lançar uma nova iniciativa. A menos que ela seja uma maneira de reverter a situação. A mensagem é: não finja que não viu fidbeque tão negativo.

    Melhor cenário: várias pessoas toparam o desafio. O problema é bom porque você ganhou opções e sua decisão não precisa ser difícil. Sugestão: peça que cada voluntário apresente seu entendimento do desafio e a forma como pretende lidar com ele. Debata as sugestões com os principais envolvidos. Normalmente, o candidato ideal emerge desse processo. Vá com ela/e.

    Pra pensar

    • Provas, certificações e afins são marcas de um tempo mecanicista e reducionista que a gente tentou deixar para trás através do Manifesto Ágil.
    • As fontes primárias, genuínas e sustentáveis de motivação e inspiração são os bons desafios. O resto é doping.
    • Não é fácil delimitar o stack de conhecimentos e habilidades que um PO deve dominar. Isso é bom. Um PO é antidisciplinar (ou indisciplinado) por definição.
    • Aproveite enquanto ninguém fecha um BoK (corpo de conhecimentos) full stack para POs.  E não fique espalhando esse tipo de ideia por aí, por favor!
  • PO: Quem se Habilita?

    PO: Quem se Habilita?

    Não é fácil ser Dono de Produtos. Mas não precisamos levantar restrições como aquelas colocadas pela Toyota para seus engenheiros-chefe. Doze anos de formação? Não precisamos de tanto. Dez mil horas de prática? Não faria o menor sentido.

    Um PO justifica a oportunidade e o poder que recebe quando demonstra conhecimento, comprometimento, criatividade e todo o pacote de soft skills requerido de quem pretende interagir com um sem número de pessoas. Repare: com exceção do primeiro item, não é o tipo de coisa que validamos através de provas, certificados e afins. Exigir tempo de casa ou de experiência também não faria muito sentido. Quantos com tempo de casa não têm raízes profundas em estruturas e hábitos que precisamos evitar ou questionar? Até que ponto a intervenção de um não-especialista ou de gente de fora não seria desejável? E se ela trouxer aquela dose de criatividade que falta?

    Talvez o melhor caminho seja a busca por voluntários. Dado o desafio, ainda que muito mal definido (e assim ele estará), perguntamos: quem se habilita? É provável que o candidato óbvio surja naturalmente. Assim como é possível que a pergunta gere dois tipos de problemas.

    Pior cenário: ninguém se apresentou! Das duas, uma: 1) o desafio não é nada atraente; ou 2) as pessoas estão sufocadas, desmotivadas, desorientadas. Dependendo do caso e da gravidade, talvez nem seja a hora de lançar uma nova iniciativa. A menos que ela seja uma maneira de reverter a situação. A mensagem é: não finja que não viu fidbeque tão negativo.

    Melhor cenário: várias pessoas toparam o desafio. O problema é bom porque você ganhou opções e sua decisão não precisa ser difícil. Sugestão: peça que cada voluntário apresente seu entendimento do desafio e a forma como pretende lidar com ele. Debata as sugestões com os principais envolvidos. Normalmente, o candidato ideal emerge desse processo. Vá com ela/e.

    Pra pensar

    • Provas, certificações e afins são marcas de um tempo mecanicista e reducionista que a gente tentou deixar para trás através do Manifesto Ágil.
    • As fontes primárias, genuínas e sustentáveis de motivação e inspiração são os bons desafios. O resto é doping.
    • Não é fácil delimitar o stack de conhecimentos e habilidades que um PO deve dominar. Isso é bom. Um PO é antidisciplinar (ou indisciplinado) por definição.
    • Aproveite enquanto ninguém fecha um BoK (corpo de conhecimentos) full stack para POs.  E não fique espalhando esse tipo de ideia por aí, por favor!
  • O PO é uma Solução Simples

    O PO é uma Solução Simples

    Simples, não simplista nem simplória. O Dono de Produtos nos ajuda a lidar com a complexidade sem complicação. Sua função é inspirar e orientar o desenvolvimento de soluções criativas. É fácil explicar e justificar o PO. A gente é que complica.

    O Dono de Produtos é, por natureza, um Integrador¹. Um recurso utilizado pelas organizações para promover cooperação desafiando silos e amarrando pontas soltas. Um integrador é muito diferente dos coordenadores, supervisores e afins. A falta destes não é sentida quando executamos um trabalho. O mesmo não pode ser dito dos integradores. Dependemos deles. E eles têm todo o interesse em participar e cooperar. Porque têm “a pele em jogo”. E, para tanto, têm poder.

    A última palavrinha – poder – sintetiza boa parte dos problemas colocados anteriormente. “Poder” carrega uma bagagem pesada, consequência do mau uso e péssimos exemplos. Não precisa ser assim. Se o poder é utilizado para promover cooperação, ele não tem nada de negativo. Também é preciso entender que o poder, assim como o conhecimento, não é reduzido quando compartilhado, pelo contrário².

    Não é recomendado que gerentes de produtos ou equivalentes assumam a função de PO. Porque eles têm outros compromissos e prioridades. Um PO deve se dedicar exclusivamente à sua criação. Segundo Sutherland³, metade do tempo com os clientes e usuários e a outra metade com o time de desenvolvimento. Podemos ser mais flexíveis no rateio da agenda. Na dedicação em período integral, não.Por isso o gráfico ao lado, sugerido por Mike Cohn em Succeeding with Agile (Addison-Wesley, 2009), é uma entre outras coisas da literatura Agile “clássica” que precisamos desaprender. O PO começa com carga máxima. Aliás, a escolha do PO é o nosso primeiro desafio. Experimente, Meça (inspecione), Desaprenda e Aprenda – sem parar! Quando fortalece o PO um gerente de produtos não está perdendo nem um pouco de seu poder. Além disso, ele está satisfazendo um requisito fundamental para a verdadeira agilidade: autonomia.

    Ah, mas o gerente não confia em ninguém para assumir as responsabilidades de um PO. Ninguém? Quem contratou essa gente? Quem pediu ou autorizou a contratação? Se ninguém serve, pra que serviu o gerente?

    O PO é uma solução simples. A gente é que complica.

    Notas

    1. Reforçar Integradores é a segunda das seis regras simples – Six Simple Rules, de Yves Morieux e Peter Tollman (HBR Press, 2014).
    2. A terceira regra fala em aumentar a quantidade total de poder. Para as outras regras: compre o livro, continue seguindo o finito e considere um mergulho no SEA.
    3. Scrum (Leya, 2014).
    4. Simple & Obvious foi compartilhada por Emma Jane Hogbin Westby no flickr.
  • É Difícil Abrir Mão do PO

    É Difícil Abrir Mão do PO

    Quais são as alternativas ao Dono de Produtos (PO)? Um comitê? Não seria muito ágil. Um portão escancarado para as demandas? Aumentaria exponencialmente os riscos de desalinhamento e desperdício. Analistas de negócios? Não são diferentes dos POs sem poder. Quando entendemos o valor do recurso PO, fica difícil abrir mão dele.

    Imagine que o grupo com todos os envolvidos – clientes, usuários e desenvolvedores – tenha 20 pessoas. Vamos considerar que há apenas um tipo de relação entre elas. Sendo assim, n(n-1)/2, temos um total de 190 relacionamentos possíveis. Aumente o número de pessoas (n) e perceba o tamanho da bagunça – da variedade. POs são filtros de variedade – dos ruídos, interesses conflitantes e picuinhas mil.

    Mas não se trata de um filtro qualquer, desses que a gente pode transformar num algoritmo ou tratar como um processo de triagem. Esse filtro seria apenas uma restrição. E a gente não quer que o PO seja visto assim.

    Uma palavra nos basta: CRIATIVIDADE. Dos limões o PO faz limonada. A partir de toda a cacofonia de desejos, necessidades, vontades e caprichos o PO orienta um processo de criação. Repare, ele não cria nada sozinho. Seu valor está em fazer uso inteligente e criativo de pessoas inteligentes e criativas. Para tanto, o PO inspira essas pessoas.

    Podemos entender, então, que o PO é um tipo de facilitador, coach ou palestrante motivacional? Por favor, não! Porque um pequeno detalhe, formado por quatro letras, o diferencia dessa turma divertida: ele é o DONO do produto. No final das contas, é ele quem presta contas¹. Como diria um Taleb tupiniquim, “é o dele que está na reta”. Isso faz toda a diferença. E nos faz pensar duas vezes antes de abrir mão do PO.

    Notas

    1. Segundo o mestre Clóvis Rossi, é esta a melhor tradução para o termo accountability.
    2. A singela imagem utilizada foi compartilhada no flickr por Direct Relief.