PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Scrum

  • A Sprint Ideal tem Duas Trilhas?

    A Sprint Ideal tem Duas Trilhas?

    Já rabiscamos a estrutura de uma Sprint Ideal. Falamos sobre início e fim,  cerimônias, duração e a necessidade de folgas. O papo de hoje é sobre o que acontece dentro de uma sprint. Gente muito boa¹, como Marty Cagan e Jeff Patton, sugeriu o trabalho em duas trilhas (dual track). Há controvérsias, claro. Além de ideias que merecem dois ou três giros experimentais. 

    Não estamos em uma corrida de revezamento, como aquele quadro kanban/scrum parece sugerir de vez em quando. Esse jeito de ver o desenvolvimento de produtos e soluções deveria ter sido definitivamente escanteado lá em meados dos anos 1980, quando Takeuchi e Nonaka nos apresentaram o jeito scrum de pensar – ou, melhor dizendo, o jeito japonês de desenvolver produtos².Outro trabalho seminal da dupla, Gestão do Conhecimento (Bookman, 2008), inspirou a matriz ao lado. No eixo horizontal navegamos do entendimento de um problema (análise) até a criação da solução (síntese). Na vertical diferenciamos a natureza de nossas fontes, matérias-primas e artefatos. Eles podem ser concretos (gentes, fatos, problemas) ou abstratos (hipóteses, personas, planos).  É uma bela coincidência o encaixe sem gambiarras do ciclo OODA (Observe, Oriente, Decida, Aja) nesta matriz. Observação e Ação ocorrem aqui, no mundo real, concreto. Elas lidam com fatos e envolvem e afetam gente de carne e osso. Do outro lado, lá em cima, estão os trabalhos baseados em ideias e possibilidades. Na Orientação nós criamos opções para, logo depois, tomarmos Decisões. Os termos originais falavam com pilotos de combate. A partir deste ponto vamos chamar os trabalhos de Descoberta, Exploração, Desenvolvimento e Entrega. 

    Aos Trabalhos

    Os proponentes do modelo Dual Track falam em dois tipos de trabalho: descoberta (discovery) e desenvolvimento (development). Veja o desenho sugerido por Jeff Patton:Patton, no mesmo artigo, reconhece a existência de um terceiro tipo de trabalho, o design tático. Ele defende que os trabalhos são diferentes porque requerem um jeito de pensar diferente. Vamos retomar a matriz sugerida anteriormente? Não são dois ou três tipos de trabalho. São quatro! Em cada quadrante temos fontes e materiais distintos. Mais que isso, temos objetivos bastante diferentes:

    • Descobrir: revelar, jogar luz, tomar conhecimento, fazer conhecer.
      É neste momento que delineamos o problema ou parte dele. É aqui que conhecemos as pessoas envolvidas (holders) e temos o primeiro contato com seus interesses (stakes) e dores. É aqui, no mundo real, que descobrimos o que precisa ser feito.
    • Explorar: percorrer (região, território) para estudar, pesquisar, conhecer.
      O entendimento do problema continua e se enriquece quando começamos a cogitar alternativas de solução. Brincamos com hipóteses, rabiscamos arquiteturas e validamos protótipos. É no campo das ideias que exploramos o como fazer. 

    Aquilo que Patton e Cagan apresentam como a trilha discovery é a combinação de dois trabalhos. Pense no OODA original. Observação e Orientação são trabalhos distintos. Complementares, com certeza, mas muito diferentes. Fechando a matriz:

    • Desenvolver: elaborar, criar. No OODA original, é o momento das tomadas de decisão. Dentre as diversas opções sugeridas durante a Exploração, algumas começarão a ganhar vida neste quadrante. Para encontrar o mundo real logo depois. 
    • Entregar: para muita gente seria apenas uma questão de “colocar em produção”, “subir pra nuvem”, “mudar de assunto”… É claro que a entrega é muito mais que isso. Pode envolver a preparação das pessoas que receberão aquela mudança. Deveria incluir o monitoramento de indicadores que vão comprovar ou não a solução do problema dado. Enfim, é botando para rodar e quebrar que nós aprendemos e justificamos nossos ganhos e choros. É aqui, no mundo concreto, que encerramos e começamos tudo de novo.

    Patton e Cagan tratam os dois trabalhos acima na trilha de desenvolvimento. Nossa matriz, mais colorida abaixo, mostra como Desenvolvimento e Entrega são movimentos/momentos diferentes:

    Quatro Trabalhos / Duas Trilhas

    Durante muito tempo convivemos com o ciclo PDCA (Plan/Do/Check/Act) como se ele fosse o único ou o melhor molde para todos os nossos métodos. Apesar do berço esplêndido e de teimosos ilustres³, faz tempo que o PDCA deu o que tinha que dar. Os problemas que merecem a nossa atenção pedem por novos modelos mentais.

    O ciclo OODA nasceu da necessidade de fazer com que pilotos de caça voltassem para casa sãos e salvos. O ciclo, naquele contexto, poderia girar dezenas de vezes em uma única missão. Tente calçar aqueles coturnos. Pense em como deve ser um combate nas alturas controlando uma máquina a, sei lá, 3.000 km/h?  Pois é, o OODA parece ser uma ideia – um jeito de pensar – bastante adequado para nossos tempos velozes e furiosos. Se você topa este entendimento, então aceita o fato de que temos quatro e não dois trabalhos. 

    Quatro trabalhos em duas trilhas: Divergente e Convergente. Surrupio os termos sugeridos por Tim Brown em Design Thinking (Alta Books, 2017). Na primeira nós criamos opções. No outra, tomamos decisões. Você prefere usar Upstream e Downstream? Fique à vontade.

    Como?

    Reclamações acerca das dificuldades de trabalhar com “ágil” – feitas por designers, analistas de negócios e afins – foram sumariamente ignoradas por muito tempo. Foi necessária a intromissão de nomes mais conhecidos – Marty Cagan, James Coplien, Peter Morville e Jeff Patton, por exemplo – para que a sugestão do trabalho em duas trilhas fosse percebida. Aceita não, percebida. 

    Confesso que ainda não vi o dual-track rodando em sua plenitude. Muitos times preferem apostar em coisas como o refinamento ou workshops de requisitos. Repare: esses eventos parecem ser espaços abertos na agenda do time – concessões? – para a realização dos trabalhos de descoberta e exploração. Como se a realização deles fosse possível em dois ou três encontros por sprint. Sei não, mas isso tem jeito e cheiro de cascata.

    Descoberta e exploração deveriam acontecer todo santo dia. É por isso que a convivência diária do time com gente do negócio é um requisito para o bom uso do XisPê, Scrum etc. 

    A gente tentou encaixotar o trabalho criativo em timeboxes que fazem muito sentido para desenvolvimento e entrega, mas nenhum sentido para descoberta e exploração. São ritmos diferentes, paradas e roteiros variados. 

    “Em vez de considerar essa característica ad hoc como um dado de inferioridade do design, creio que isso atesta a independência epistemológica da área – o design não é necessariamente científico, mas pode estabelecer diálogos muito fecundos com a ciência”.
    – Caio Adorno Vassão em Metadesign (Blucher, 2010)

    Sigo confiando na proposta das duas trilhas. Aliás, dadas as críticas mais recentes?, estou disposto a dobrar a aposta. Porque elas partem de um engano: há dois times trabalhando, um em cada trilha, cada um com seu backlog!? Não foi isso que Cagan e Patton escreveram. Caramba, basta ler os artigos: há duas trilhas, não dois times. Tá todo mundo junto, o tempo todo! O tempo todo? Veja bem…

    Notas

    1. Marty Cagan escreveu Inspired: How to Create Tech Products Customers Love (Wiley, 2018) e Patton ficou famoso por causa de User Story Mapping (O’Reilly, 2014). Cagan escreveu o artigo Dual-Track Agile há oito anos. Patton voltou ao tema logo depois.
    2. No artigo The New New Product Development Game, publicado na edição de jan-fev/1986 da Harvard Business Review.
    3. O ciclo PDCA é cria de W. Edwards Deming e defendido, na comunidade Lean-Agile, por gente grande como Mary e Tom Poppendieck. Em Implementando o Desenvolvimento Lean de Software (Bookman, 2011), por exemplo. É risível a forçada de barra dada para justificar o P (plan).
    4.  We Need One Complete Product Team, de Todd Lankford (27/ago/20).
        Time to Say Goodbye to Dual Track Agile?, de Alex Ballarin (12/set/20).
    5. Foto de Henry & Co. surrupiado no Unsplash
  • Sprint Ideal

    Sprint Ideal

    O sprint ou A sprint? Nunca sei. Uso a segunda opção para combinar com a tradução mais comum: A iteração. Escrevendo ou falando, nem sempre me lembro disso. Mas, quem dera nosso maior problema com as sprints fosse determinar seu gênero na versão aportuguesada. A sprint, conceito que está no núcleo da proposta Scrum, é vítima e causa de muitos mal entendidos. Este artigo tenta esclarecê-los enquanto rabisca sugestões para uma Sprint Ideal.Para começar, uma sprint ideal não se chamaria sprint. Porque o termo é ruim. Sprint significa uma corrida curta executada em velocidade máxima. Em corridas de longa distância, a sprint ocorre apenas no último trecho. Ou seja, o nome parece fazer muito mais sentido em trabalhos guiados pela mentalidade cascata. É neles que vemos uma correria que fica cada vez mais insana na medida em que nos aproximamos da linha de chegada. 

    O desenvolvimento de produtos e projetos é, em boa parte das vezes, um empreendimento de prazo indeterminado ou longo. Fazer com que cada pequeno trecho seja executado como se fosse uma sprint – uma disparada na maior velocidade possível – é comprometer seriamente um dos princípios da Ideia Ágil: o desenvolvimento sustentável. Nenhum sistema, seja ele humano ou não, consegue operar de forma constante perto dos 100% de sua capacidade. E todos os sistemas, biológicos ou não, merecem folgas de vez em quando.

    Folgas

    Problema apenas resvalado em artigo anterior: a nossa mania de emendar uma sprint atrás da outra sem um mínimo intervalo entre elas. Não precisa ser assim. Aliás, se a preocupação com a sustentabilidade é real, então não pode ser assim. Ou abrimos um intervalo de tempo entre sprints ou alocamos algo entre 25% e 35% de folga dentro das sprints. Pensando bem: uma sprint Ideal deveria contemplar as duas possibilidades. Explico.

    A folga interior é o que a gente já chamou de buffer, slack time, gordurinha e afins. Trata-se de uma reserva – uma margem de segurança. Desconfio que todo mundo, instintivamente, já faz algo parecido. Seria apenas questão de formalizar. Porque o que é ágil de verdade é transparente de verdade. Incertezas ou riscos assumidos justificariam flutuações no percentual aplicado. O time vai aprender e fazer ajustes a cada sprint. Também não deveríamos nos preocupar com a subutilização deste recurso. É muito pouco provável que isso aconteça.

    O intervalo entre sprints tem outra utilidade: é só para descanso mesmo. E deveria ser formalizado assim: DESCANSO. 

    Descanso não quer dizer, necessariamente, dois ou três dias inteiros na praia ou em campeonatos de videogame. Já vi times descansando e se divertindo enquanto faziam spikes (pequenos experimentos) e até refatoração. Coisas que clientes e POs não veem com bons olhos quando não são bem instruídos.  

    Enfim, o descanso pretendido aqui é uma folga dos prazos, das cobranças, da dívida (backlog). O time descobrirá a melhor maneira de aproveitá-lo . Se for com uma maratona de videogames e séries, que seja. Se isso renovar o pique para a próxima sprint, o descanso estará muito bem pago. 

    Qual deveria ser o tamanho da folga? É outra variável que pode ser negociada dependendo de quão estressante tenha sido a sprint anterior. O esquema Brasília-DF – folga na segunda E na sexta – é um bom ponto de partida. 

    As Cerimônias

    Uma sprint tradicional é delimitada por cerimônias: uma na abertura (planejamento) e duas no fechamento (revisão e retrospectiva). Não são raros os casos em que os três eventos são enfileirados em um único dia. Por conveniência. Porque isso evitaria deslocamentos, por exemplo. Não sei dizer até que ponto a imposição do trabalho remoto mudou isso. De uma forma ou de outra, uma sprint Ideal não espreme suas cerimônias em um único dia / encontro. A separação fica muito lógica quando adotamos a sugestão anterior, de um intervalo entre sprints. O planning só ocorreria após o descanso, aproveitando a cuca fresca de todo mundo. 

    Há um outro tipo de evento que vem sendo confundido com cerimônias: é o refinamento, antigo grooming. A confusão é tão grave que talvez mereça um artigo só para ela. Por enquanto, apenas uma provocação¹: o refinamento ocorre diariamente durante uma sprint Ideal. Aliás, deveria ser assim em qualquer sprint, ideal ou não.

    As Entregas

    Um engano tão danoso quanto o da sprint vista como uma carreta sem freios é o entendimento de que as entregas ocorrem apenas uma vez a cada sprint. Isso quer dizer que um item que está pronto para entrar em produção e gerar valor fica esperando porque a sprint está longe do final? De onde veio essa ideia? O que compensa o atraso? 

    As entregas congestionadas no término de uma sprint podem esconder outros problemas. Dentre eles, eventuais deficiências nos trabalhos de entendimento, quebra e priorização das histórias, o que nos leva de volta à conversa sobre o refinamento. Parece que a gente não vai escapar de conversar sobre isso. Outra hora. Porque, agora…

    Por que Sprints?

    Afinal, se as sprints não servem para forçar as entregas, então qual é o sentido delas²? 

    A duração fixa de uma sprint é uma das poucas certezas, se não a única, que podemos oferecer aos clientes, usuários e times. Não é absoluta – pequenas variações podem acontecer. Mas, ainda assim, uma certeza. A pergunta seria: por que não?

    Os encontros regulares, margeados por cerimônias bem definidas, podem nos oferecer benefícios que tendem a ficar mais caros e menos prováveis quando buscados por outros meios. Por exemplo:

    • É mais fácil destacar o que funcionou e o que não funcionou dentro de um intervalo limitado de tempo (retro!). Se os intervalos são regulares, a aprendizagem fica cadenciada. Ao que tudo indica, nossos cérebros gostam disto: organização, ritmo e alguma previsibilidade³.
    • Clientes costumam gostar dessas coisas também. E pagar por elas. Por isso faz sentido falar em uma prestação de contas formal (review!) atrelada ao término de cada sprint. 
    • O trabalho criativo fica caótico ou muito bagunçado quando ocorre sem nenhum tipo de restrição. Além das limitações orçamentárias e tecnológicas, calendários e relógios podem ajudar bastante.
    • Por fim, mas não menos importante: Sprints facilitam a definição do que seriam pequenas vitórias, a sua eventual comemoração e a consequente recarga motivacional. Que não sejam fakes nem as vitórias e nem as recargas! E que as ressacas sempre caibam nas folgas.

    A Duração

    Somos humanos. Além das certezas da morte e dos impostos que a antecedem, temos outra que justifica essa verborragia toda: nós vamos errar. Muito! 

    Por isso não faz muito sentido falar em sprints com duração maior que duas semanas. O volume de cagadas pode ser assustador. Lembre-se: a Ideia Ágil “é sobre saber, o quanto antes, o quão ferrados estamos”. A sprint pode representar o mais longo ciclo de feedback em uma iniciativa Ágil. Defina sua duração com obcecada moderação.

    A Orientação

    Não é porque a jornada é curta que ela pode ser feita sem o apoio de bússolas e mapas. Dada a alta nebulosidade de quase todos os empreendimentos que valem a pena, a navegação sem rumo – uma sprint sem objetivo claro – é um contrassenso total. Inexplicavelmente comum.

    Um time deve se comprometer com a realização de um ou mais objetivos do negócio a cada sprint, não com a entrega de n pontos, tarefas ou itens do backlog. É isto que a gente celebra: o gol, não o número de passes trocados.

    A reincidência do aviso acima deveria nos preocupar mais. Qual é a raiz desse problema tão estranho, aparentemente bobo e muito comprometedor?

    A Sua Sprint Ideal

    Pode ser que a sua sprint Ideal não contemple nenhuma das sugestões acima. Talvez você nem use ou finja não usar sprints. E daí? Seja como for, já que você chegou até aqui, considere o seguinte:

    1. O time já está na segunda ou terceira sprint e o cliente ainda está a ver navios. Como ele não comprou nenhum tipo de embarcação, essa canoa furada pode ser tudo, mas ágil ela não é não.
    2. O time já está na segunda ou terceira sprint e ainda não mudou uma vírgula em seu jeito de trabalhar. Como perfeição não existe, a única conclusão possível é a de que o time não está aprendendo nada. E se não aprende, ágil não é.
    3. O time ainda está na segunda ou terceira sprint e já está cansado e/ou desmotivado e/ou zangado. Se está assim, ágil não está. Se não mudar, ágil não ficará.

    Notas

    1. Também reservo um tempo para conversar sobre o refinamento e respectivos mal entendidos na Aula de Histórias.
    2. A reincidência desta pergunta é curiosa: se não é para forçar entregas, para que servem as sprints?
    3. Veja, por exemplo, A Mente Organizada de Daniel Levitin (Objetiva, 2015).
    4. Foto de Clark Gu no Unsplash
  • O Quão Ferrados Estamos?

    O Quão Ferrados Estamos?

    Tempo de espera. Tempo de ciclo. O dobro do trabalho na metade do tempo. Nenhuma dessas preocupações é nova. Elas estavam com Ford e Taylor lá no início do século passado. Também acompanharam Taiichi Ohno, um dos pais do Sistema Toyota de Produção, por toda a sua vida. Já velhinho, perguntado sobre o que estava fazendo, ele respondeu¹: “pensando em maneiras de reduzir o tempo gasto entre o pedido colocado pelo cliente e o tilintar do dinheiro entrando no caixa”. Essa pressa não disfarçada é vício antigo. A Ideia Ágil não tem nada a ver com isso.

    Robert ‘Uncle Bob’ Martin gasta um tempinho em seu Clean Agile (Pearson, 2020) para nos lembrar:

    “Algumas pessoas acham que Agile é sobre ir mais rápido. Não é. Nunca foi. Agile é sobre saber, o quanto antes, o quão ferrados estamos.” 

    Saber, o quanto antes, o quão ferrados estamos. Esse é o espírito da coisa Ágil. Pragmático e poético como ele só. Na Toyota há um mecanismo que ilustra bem essa atenção com as más notícias. É a Corda Andon, que pode – deve! – ser puxada por qualquer pessoa que veja qualquer problema na linha de produção. O acionamento da corda simplesmente para tudo. Ela funciona bem em um fluxo linear, previsível pra chuchu e de baixa variabilidade. Ou seja, funciona em fábricas. Uma versão adaptada da corda funcionaria em um contexto não linear, cheio de incertezas e dependente de variedade? É pouco provável.

    Ainda que a gente faça de conta que as nossas burocracias não detestam más notícias. Ainda que todos trabalhemos em ambientes psicologicamente seguros onde as cagadas são recebidas sem choro nem vela, sem chiliques nem berros. Ainda assim, qual é a chance de nossas organizações ou times desenvolverem um reflexo que simplesmente pare tudo quando se deparar com um problema? 

    Um reflexo é automático, inconsciente e inconsequente. Apesar de mirar isto, funcionar como se fosse um reflexo, o acionamento da corda Andon é uma reação. É um hábito que precisou ser treinado. Ainda mais lentas que as reações são as respostas. Porque elas sempre significam um esforço consciente, uma tomada de decisão. Respostas requerem o uso do nosso lento e preguiçoso Sistema 2².

    Uma típica instância Ágil dedica pelo menos três cerimônias para a celebração das más notícias: a Diária, a Revisão e a Retrospectiva. Nenhuma delas aparenta a ambição de ser um reflexo ou pelo menos um reação. São respostas e isso não é necessariamente ruim. Desde que a gente saiba que:

    • Diária: é totalmente desnecessária quando o time coopera de verdade. Por favor entenda que POs, ANs e/ou outros representantes do negócio são parte indissociável de um time. De uma maneira ou de outra, tratar as Dailys como se fossem um tipo de prestação de contas para um cliente ou gerente é desvirtuar sua intenção original: saber o quão ferrados estamos ou podemos ficar. Quando um time de fato co-opera, os problemas e riscos pipocam na cara de todos, dispensando um evento ou comunicação formal. O distanciamento de membros ou pares pode justificar a realização das Diárias. Ainda assim, é bom entender que má notícia que se preze não pode e não vai esperar pela manhã seguinte.
    • Revisão: Encontro periódico que deveria envolver o maior número possível de interesses. Na Revisão nós validamos a eficácia do time, ou seja, se ele está fazendo a coisa certa. Tem potencial para se transformar em um festival de saias justas se este for o único momento da iteração ou sprint em que a turma do negócio vê a evolução de sua cria. Tanto pior se a experiência se resume à uma demo pilotada por devs. O time, neste encontro, deveria ser a parte passiva. O comando da festa deve ficar com quem está pagando. Enfim, a Review deveria ser uma celebração totalmente livre de surpresas. Isso só vai acontecer se a patota de negócios interagir diariamente com o time e o produto. Testando – ou seja, gerando más notícias. Todo santo dia.
    • Retrospectiva: Tem má notícia que a gente só entende plenamente em retrospecto, depois de um certo tempo. Com calma é possível avaliar causas e efeitos. É por isso que todos os times, particularmente os piores, merecem um refresco recorrente chamado Retro. É um momento de reflexão, quando o time avalia a sua eficiência, ou seja, se ele está trabalhando do jeito certo. A gente sabe, ele nunca está! Sempre, sempre haverá algo para melhorar. Uma boa retrospectiva não fica ensanduichada entre uma review e uma planning. Refresco, gente. Entre sprints, todo time merece um refresco. Senão não aprende, não melhora, e as más notícias seguirão evoluindo como bolas de neve.

    PS, post-mortem

    Alguém pode concluir que a reincidência desse assunto, nesta altura do campeonato, é uma prova de que estamos bem ferrados em relação ao entendimento da Ideia Ágil. Pode até ser. Mas a teimosia também pode confirmar que o assunto vale a pena, a atenção e o nosso tempo. Afinal, acho que ninguém em sã consciência quer voltar para a época em que as más notícias só circulavam formalmente, com muitos choros e velas, numa reunião chamada post-mortem. 

    Notas

    1. Anedota contada por John Seddon no ótimo Freedom from Command and Control: Rethinking Management for Lean Service (Productivity Press, 2005). Ótimo ao ilustrar o Lean funcionando bem longe do chão de fábrica.
    2. O papo sobre reflexos, reações e respostas eu aprendi com Russell Ackoff em Differences that make a Difference (Triarchy, 2010). O preguiçoso Sistema 2 é apresentado por Daniel Kahneman em Rápido e Devagar (Objetiva, 2012).
    3. Foto de Jan Kop?iva no Unsplash.
  • Agile, pra que te quero?

    Agile, pra que te quero?

    Te quero para fazer o dobro do trabalho na metade do tempo. Topo tudo por eficiência$ – para fazer bem mais com muito menos. Para seguir retorcendo e esticando a corda colocada por Taylor e Ford lá no início do século passado. 

    Te quero para dar roupa e nomes novos para meus velhos hábitos e habitats. Quero tribos, guildas e esquadrões bem alinhados em minha mal disfarçada organização matricial. Assim mantenho o statu quo de um jeito SEGURo. Com certificados e atestados de maturidade. E daí se a ideia original era cancelar esse mindset de certificações e modelos de maturidade? Entenderam nada, inocentes!

    Nosso rocambole é pós-moderno. Vou provar através de uma matriz 2×2 que não pode ser chamada de matriz 2×2 com um buraco no meio – saca Magritte? – que a nossa metodologia é o única que está pronta para lidar com essa tal complexidade. Prontinha: Out-of-the-box!

    Ah, $cara agilidade, te quero como sombrinha e sombreiro. Faça chuva ou faça sol, seja qual for a pergunta, você será a resposta. Devidamente embrulhada num pacote de jargões, nomes esquisitos e anglicismos que vão separar nitidamente os fortes dos fracos, os verdadeiros agilistas dos céticos e patéticos cascateiros. Que venham os épicos!

    Terra Arrasada

    Não é por acaso que Kent Beck, um dos pais dessa ideia sem mãe, recentemente disse¹ que o Ágil “virou terra arrasada. A vida foi toda sugada para fora dele. Virou um conjunto de rituais religiosos realizado por gente que não entende o propósito original desses rituais”. 

    Não é de hoje que os signatários do Manifesto Ágil lamentam o estado deplorável de sua cria. Assim como acontece com o rock’n’roll, pela enésima vez vão anunciar a morte do Agile². Só para confirmar, pela enésima vez, sua teimosia. Apesar de todos os sopapos e mal entendidos. Apesar do marketing desastrado/desastroso que o acompanha desde o berço.

    Anarquistas, graças ao marketing

    Dezessete caras pançudos de meia idade se reuniram em um resort para “esquiar, relaxar, colocar o papo em dia e encontrar pontos comuns em suas ideias sobre o desenvolvimento de software”. O processo durou três dias e gerou um documento de duas páginas. Em agosto de 2001 a Software Development anunciou a boa nova com a capa ao lado. O artigo, de onde surrupiei as aspas anteriores, foi escrito por Jim Highsmith e Martin Fowler, dois dos dezessete barrigudos. O que nos permite entender que eles não se incomodaram com a tag anarquistas nem com a mensagem da capa. 

    Hoje, quase vinte anos depois, o manifesto segue sendo mal apresentado pra chuchu. Há poucos dias a revista EXAME colocou na conta da pandemia um crescente interesse por uma metodologia ágil. Dá a entender, por exemplo, que a adoção do modelo Spotify, algo que nem a empresa sueca faz, seria condição para a agilidade. A sucessão de mal entendidos não é exclusividade nossa. Saca só um recorte da Harvard Business Review:

    Pois é, creditam Sutherland como grande liderança por trás da “invenção” da ideia ágil. Sutherland é o mesmo que promete na capa de um livro “a arte de fazer o dobro do trabalho na metade do tempo”. O faz porque parece estar apostando corrida contra o cara que pegou um time CMMI nível 5 na Índia e aumentou sua produtividade em 200%! 

    Quem resiste a tanto apelo? Que pessoa de negócios em sã consciência pode se dar ao luxo de ignorar propostas tão ambiciosas? 

    Só tem um probleminha: o Ágil nunca prometeu nada disso. 

    Agilidade, para que serves?

    Ao priorizar a gente e as nossas conversas, o resultado concreto de nosso trabalho e respostas rápidas – ciclos bem curtos de feedback, o Manifesto Ágil aponta para uma grande inimiga: a Complicação.

    Nossos negócios ficaram 35 vezes mais complicados nos últimos cinquenta anos³. Esta foi a nossa resposta inconsequente à crescente complexidade: Inventamos departamentos, seções, funções, tribos, capítulos, guildas, escritórios disso e daquilo; Desenhamos processos cada vez mais prescritivos, minuciosos e paranóicos; Despejamos um sem número de políticas e regras que são cada vez mais efêmeras e frágeis; Impusemos uma enxurrada de indicadores que atestam um único fato: a nossa insegurança. Enfim, bagunçamos o coreto do negócio dificultando a convivência interna e comprometendo todas as relações que existem da porta para fora. 

    A “ideia Ágil” não foi a primeira nem será nossa última invenção para combater as burocracias que emperram nossas organizações e nos dão tanta canseira. Cedo ou tarde ela merecerá uma lápide bonitinha no museu de grandes novidades onde descansam a Reengenharia, TQM, BPM, SOA, KM…

    Até lá – até que se invente algo melhor – faz sentido que a gente tente tirar o melhor possível da ideia. As exigências são mínimas: 1) alinhamento: saber o que precisa ser feito e por que; e 2) autonomia: para definir a melhor maneira de realizar aquele objetivo. Repare, há apenas uma condição para a realização dos dois fatores: confiança. E como saber se podemos confiar nas pessoas? Oras, como ensinou o ágil Papa Hemingway, confiando nelas.

    PS

    Se a velha guarda pançuda estivesse mesmo abandonando sua cria, por que então se preocuparia em escrever e receber tão bem um trabalho como Clean Agile – Back to Basics (Robert Martin – Pearson, 2020)? É claro que a Ideia Ágil merece uma nova chance. Porque, quando bem entendida, ela é muito boa. 

    Curioso é vê-la muito bem entendida e aplicada numa seara que não tem nada a ver com software nem com negócios. É o que documenta Zaid Hassan no livro The Social Labs Revolution (Berrett-Koehler, 2014) sem disfarçar seu entusiasmo: “o Ágil come cisnes negros no café da manhã”. 

    Notas

    1. Nesta entrevista publicada pela Built In no último dia 18/08/2020.
    2. Há uma extensa coletânea de obituários neste artigo publicado no LinkedIn.
    3. Segundo pesquisa do Boston Consulting Group apresentada em Six Simple Rules, de Yves Morieux e Peter Tollman (HBR Press, 2014 – p. 7).
    4. Foto de Kelly Sikkema no Unsplash
  • Grandes Times Maduros

    Grandes Times Maduros

    Encerrei o post anterior afirmando que um time de verdade exala maturidade. Não porque algum cartório garante isso através de um caro certificado, longe disso. Acontece que é fácil distinguir um time maduro. Tanto quanto é relativamente simples identificar uma pessoa madura. Basta a convivência por algum tempo. Um time, assim como uma pessoa madura, tem forte presença / identidade, autoconhecimento e “a esperteza que só tem quem está cansado de apanhar”¹. 

    Um time maduro sabe o que quer e se garante. Ele é necessariamente viável – capaz de sobreviver e prosperar de forma autônoma. O que não faz dele uma bolha. Porque um time verdadeiramente maduro sabe que é um sistema aberto e entende que não tem utilidade fora de seu ambiente ou deslocado de seu propósito. Um time de verdade não é apenas reativo – orgânico – na má interpretação dada a essa palavra. Um time maduro exerce influência e coevolui com seu meio. Ele experimenta, aprende e propõe mudanças. Um time maduro não copia, rouba.

    Grandes Times Roubam

    Pablo Picasso: “Bons artistas copiam, grandes artistas roubam”. Eles não roubam o produto final, a obra prima. Isso dá cadeia e não tem graça nenhuma. Assim como não tem graça chamar times de squads porque isso parece moderno ou bonitinho. Esquadrão nunca foi um sinônimo simpático para TIME. 

    Grandes times, assim como os grandes artistas, roubam a inspiração que levou àquela obra ou produto. Chamar time de squad é só perfumaria. Aliás, a cópia do modelo Spotify entra no rol dos problemas que causamos porque estávamos apressados demais para acionar o nosso senso crítico². Os chapters e guildas – outros termos vendedores porque diferentes – nada mais são do que releituras das antigas Comunidades de Prática³. Pequenas adaptações que foram apresentadas de forma a justificar ou disfarçar uma organização matricial4. Quem copia sabe que o modelo não funcionou nem no Spotify?

    Escalar a agilidade – um dos objetivos originais do modelo Spotify – é um problema que já mereceu zilhões de palavras escritas e algumas berradas. Não tenho a menor pretensão de apresentar uma visão alternativa. Até porque nunca fui além de alguns poucos times e dezenas de pessoas sob minha responsabilidade. Entretanto, depois de trinta e tantos anos de carreira, posso falar sobre times maduros e suas ideias roubadas.

    Por  Exemplo

    Guildas e chapters são soluções para qual ou quais  problemas? O assunto me é particularmente caro porque ele justificou a criação deste finito há dezesseis anos. Criei este espaço para desenvolver e apresentar um trabalho sobre o Aprendizado inter-projetos. Em suma:

    • Como fazer com que os times troquem experiências e evitem a reincidência de erros e problemas?
    • É possível promover uma evolução homogênea dos times ao mesmo tempo em que lhes é oferecida a máxima autonomia?

    As comunidades de prática e todas as suas versões pós-modernas – guildas, chapters etc – correm o mesmo risco. Passado o entusiasmo inicial, muito rapidamente elas podem ficar irrelevantes e vazias. Há um motivo bem quente para isso: o inferno nosso de cada dia. A correria tende a matar tudo o que não tenha aplicação imediata, promissora e barata. 

    Na melhor versão dessas comunidades a participação é voluntária. O que tende a aumentar o interesse e a qualidade das conversas. No entanto, a participação é voluntária… Já me deparei com gente que deixou de ir aos encontros quinzenais por medo de ser percebido como alguém com a agenda folgada.

    Conclusão: esses mecanismos de incentivo ao aprendizado são elegantes e cheios de boas intenções. O problema é que raramente encontram um ambiente que os favoreça. Insistimos em variações da mesma ideia desde o início dos anos 1990. Chamar encontros ou reuniões de lean coffee e ser generoso nos comes e bebes não adiantou muita coisa. Passa da hora de tentarmos coisas diferentes.

    Por exemplo: 

    • Pense em uma dupla ou time que você pode plugar em um time fixo de forma a oferecer funcionalidades adicionais por um certo período. 
    • Pode oferecer, por exemplo, o necessário olhar de gente “de fora” em busca de oportunidades de melhoria. Se estamos falando de um time de desenvolvimento de software, temos aqui um plugin para a Refatoração Oportunista. Além do potencial ganho de qualidade, podemos esperar:
      • Polinização cruzada – difusão mais rápida e ampla de conhecimentos
      • Mais gente com condições de participar daquele projeto/produto
      • Treinamento com a finalidade de cobrir férias, licenças ou qualquer outra ausência minimamente previsível
    • Na correria do dia a dia, quantos times têm tempo e recursos para fazer pesquisas e experiências? Falando novamente de software, quantos spikes em média os times realizam a cada sprint? Um time plugável pode oferecer tal possibilidade sem comprometer o que já foi combinado com clientes e usuários. 
    • Em um prestador de serviços, esses spikes podem ser utilizados para a descoberta de novas oportunidades de negócio. Se tornam Spikes Interesseiros. Criam argumentos de vendas que vão muito além do blablablá “somos ágeis f*ckin’ black belt acreditados pra chuchu etc”.
    • Pense nisso: times livres e plugáveis, sem formação ou propósito fixos, podem fortalecer os times fixos ao mesmo tempo em que promovem a troca de conhecimentos e experiências. Com a mão na massa, não em auditórios ou cafés.
    • Por fim, mas não menos importante: os times livres parecem ser bastante adequados para os processos de on-boarding, para a acolhida e preparação de novos colaboradores.

    Um time ou organização exala maturidade ao explorar alternativas e criar soluções. Os exemplos acima não sanam todas as questões colocadas. Não era essa a intenção. Assim como a originalidade absoluta não é meta de ninguém, nem dos artistas mais picassos. Porque ela, a originalidade total, não existe. Já a maturidade, seja de um time ou organização, não só existe como é fácil de ser percebida.

    Assim como é fácil de ser destruída. DeMarco e Lister5 criaram até um nome para isso: Timecídio. Tema do próximo post. Até lá!

    Notas

    1. Trecho da música Selvagem dos Paralamas do Sucesso (Selvagem?, 1986).
    2. Há tempo sapateamos nessa calçada infame. Em 1970, por exemplo,  interpretamos muito mal um artigo de Winston W. Royce e glorificamos o modelo Waterfall. Agora, apesar dos inúmeros avisos (compilados neste artigo, em inglês), fizemos o mesmo com o modelo Spotify.
    3. https://pt.wikipedia.org/wiki/Comunidade_de_pr%C3%A1tica
    4. https://pt.wikipedia.org/wiki/Departamentaliza%C3%A7%C3%A3o_matricial
    5. Peopleware: Productive Projects and Teams (Dorset House, 1987|2013).
    6. Foto de Anna Samoylova no Unsplash
  • 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.