finito

Tag: Ken Schwaber

  • É Fácil se Livrar do PO

    É Fácil se Livrar do PO

    Jeff Sutherland se inspirou¹ no Engenheiro-Chefe da Toyota para criar o papel do Dono de Produtos (PO). O que aproveitamos desse modelo? Um EC é visto como um “super-engenheiro e líder”. Sua formação não dura menos do que doze anos. Sua posição é a mais cobiçada entre os engenheiros daquela empresa japonesa². Quanto disso nós trouxemos para os nossos POs? Quase nada.

    Ok, a nossa realidade é diferente. Não fabricamos carros. E aquele morro ali ao lado não é o monte Fuji. Mas isso não pode justificar o que vemos por aí com relativa frequência. A palavra DONO não carrega nenhuma ambiguidade. Mas não são poucas as organizações que inventaram donos de mentirinha. Gente sem autonomia para dizer nem sim nem não.

    Cansados da situação, alguns simplesmente se livraram do papel. Via Negativa! Isso tem se tornado relativamente comum: jogar fora tudo que parece difícil e não funciona logo. POs, estimativas, sprints e agora projetos. Sabe-se lá quantos bebês vão junto com a água suja. É preciso entender que uma restrição pode ser, sob outra perspectiva, um recurso.

    Um PO, para funcionar bem, precisa ser percebido como um recurso à disposição de todos os envolvidos. Um recurso verdadeiramente útil tanto para clientes e usuários quanto para o time de desenvolvimento.

    Nós não ajudamos a criar essa percepção quando afirmamos que o PO: foca no ROI; cria a Visão (sozinho); é a única voz das partes interessadas perante o time; cria a Visão do Produto e estabelece fronteiras. Essas afirmações, extraídas de alguns best-sellers da área³, reforçam o lado antipático: o PO é uma restrição, gargalo, mala, elo mais fraco, ponto único de falha etc.

    Justificar a eliminação de restrições chatas é fácil.
    Se livrar de recursos úteis, nem tanto.

    Notas

    1. Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo (Leya, 2014). Já tem uns quatro meses que esse livro figura no topo da lista de mais vendidos publicada aos sábados na Folha de São Paulo. Que bom! Mas que não seja pela desastrada promessa do subtítulo.
    2. Segundo James Morgan e Jeffrey Liker em Sistema Toyota de Desenvolvimento de Produto (Bookman, 2008).
    3. Agile Project Management with Scrum – Ken Schwaber (MS Press, 2004).
      Scaling Lean & Agile Development – Larman e Vodde (Addison-Wesley, 2009).
      Essential Scrum – Kenneth Rubin (Addison-Wesley, 2013).
      Succeeding with Agile – Mike Cohn (Addison-Wesley, 2010).
    4. Day 168 / 365 – Post-It Luv Gone Bad, de Anita Hart, decora este texto.
  • Scrum ‘de Raiz’

    Scrum ‘de Raiz’

    Assim como existem o samba e a música sertaneja ‘de raiz’, também existe um Scrum ‘de raiz’: ideias, princípios e práticas que antecederam e deram forma e jeito ao framework como é conhecido hoje. Ajornada antropológica proposta por este artigo tem como principais objetivos: i) Revisitar os pilares do Scrum; e ii) Descobrir se estamos esquecendo alguma coisa importante em nossos trabalhos com ele. Posso adiantar: estamos!

    ?

    O Scrum foi provocado pelo artigo “The New New Product Development Game” publicado na edição de Jan-Fev/1986 da Harvard Business Review (HBR). Escrito por Hirotaka Takeuchi e Ikujiro Nonaka, o artigo descreve o sucesso de empresas como Fuji-Xerox, Honda e Canon no desenvolvimento de novos produtos. Os autores descobriram que as empresas analisadas compartilhavam seis características fundamentais:

    1. Instabilidade intencional: os times de projetos recebem apenas uma diretriz geral, normalmente uma metáfora indicando o tipo de produto que a organização espera receber. Não existem especificações detalhadas ou plano de projeto. Tensão, pressão, ambiguidade e outros efeitos colaterais da prática são compensadas por tolerância aos erros e pela autonomia concedida ao time.
    2. Times auto-organizados: a autonomia, citada acima, é uma das três condições para a criação de um time auto-organizado. Auto-transcendência (equipe parece buscar algo além de seu limite normal) e fertilização cruzada (time é multifuncional e todos aprendem com todos) são as outras duas.
    3. Fases sobrepostas de desenvolvimento: como em um jogo de rúgbi, onde todos correm juntos e passam a bola lateralmente. A metáfora oposta é a corrida de revezamento (desenvolvimento sequencial ou linear), com um participante aguardando a passagem do bastão por outro.
    4. “Multi-aprendizado”: ocorre o aprendizado multiníveis (indivíduo, time e empresa aprendem) e o aprendizado multifuncional (fruto da fertilização cruzada, citada acima. Um especialista é provocado a aprender coisas de outras áreas).
    5. Controle sutil: a autonomia de um time não significa falta de controle, apenas um tipo diferente de gerenciamento.
    6. Transferência do aprendizado: o item 4 acima trata do aprendizado que ocorre entre as partes interessadas de um projeto específico. Aqui se trata do aprendizado interprojetos e também da transferência da e para a organização.

    A derivação da lista acima que hoje conhecemos como Scrum, criada por Jeff Sutherland e Ken Schwaber, parece dar ênfase aos itens 2~5 em detrimento do primeiro e último tópicos. Jim Highsmith, mesmo sem dar nome ao boi, sugere algumas correções (ou avanços) no já comentado “Agile Project Management“. Craig Larman e Bas Vodde, em “Scaling Lean & Agile Development” (Addison-Wesley, 2009) tentam o mesmo. Apesar de valiosas, essas colaborações não são suficientes.

    Enquanto o Scrum era gestado, Takeuchi e Nonaka prosseguiram com suas pesquisas no campo da Gestão do Conhecimento¹. Do segundo a mesma HBR publicou, na edição Nov-Dez/1991, “The Knowledge-Creating Company“. Em 1995 a dupla voltou com outro artigo seminal, “The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“. Por mais que a estagnação da economia japonesa – que já dura duas décadas – tente provar o contrário, esses artigos não poderiam ter sido ignorados como aparentemente foram (pelos “criadores” do Scrum e demais envolvidos com métodos ágeis). Porque eles recolocam e evoluem os temas tratados no trabalho original de 1986.

    A crítica sem rodeios nem meias palavras ao jeito ocidental – cartesiano e taylorista – de ver as organizações talvez explique o fato desses artigos terem passado em branco. Mas é exatamente nesta crítica que está seu grande valor. O tal ‘jeito ocidental’ vê as empresas como “mecanismos para processamento de informações”. Nonaka explica:

    “De acordo com essa visão, o único conhecimento verdadeiramente útil é o formal e sistemático – dados difíceis² (leia-se quantificáveis), procedimentos codificados, princípios universais. E as métricas-chave para mensurar o valor do novo conhecimento são similarmente difíceis e quantificáveis – crescente eficiência, custos mais baixos, melhor retorno do investimento (ROI).”

    Por outro lado, no modo oriental (ou japonês):

    1. Há reconhecimento e valorização do conhecimento tático;
    2. A questão não se limita a “gerenciar conhecimentos” mas, principalmente CRIAR conhecimentos;
    3. Entende que todos os colaboradores, e não apenas os gerentes e diretores, são potenciais criadores de novos conhecimentos; e
    4. Recursos e atividades são organizados e desenhados de forma a facilitar a criação e transferência de conhecimentos.

    Voltemos a um ponto chave que deixei um tanto solto acima: a área de especialização de Takeuchi e Nonaka é a Gestão (ou Criação) de Conhecimentos. Eles entendem que cada projeto é uma oportunidade única para criação de conhecimentos (leia-se Inovação). Por isso depositam boa parte de suas sugestões nas trocas e transformações de conhecimentos. O Scrum, até certo ponto, reflete bem a mesma preocupação. Através de suas reuniões diárias, de revisão (de iterações ou sprints) e retrospectivas. Mas ele peca ao desconsiderar ou dar pouca importância ao que existe fora do time de projeto.

    Takeuchi e Nonaka descobriram um tipo de organização que chamaram “hipertexto”. Convivência, confronto e troca entre a estrutura hierárquica (sistemas de negócios) e times de projetos (forças-tarefa) dão forma a uma “hiper-rede”. Uma rede que não se desliga nunca! Por que isso é importante e muito diferente do que vemos no Scrum?

    O Scrum instituiu um e apenas um ponto de contato (ou interface) entre negócio (estrutura hierárquica) e time de projeto: o Dono do Produto. Se por um lado esse “mecanismo” simplificou o processo de comunicação, por outro ele destruiu a permeabilidade e transparência que existem na proposta original da dupla japonesa. Repare no diagrama ao lado. Times de projetos e o negócio se comunicam constantemente. E essa comunicação não se dá através de um “ponto focal”. Acontece que os times são de fato multidisciplinares, compostos por pessoas de todas as áreas de negócio envolvidas. Takeuchi e Nonaka chegam a falar de times com 20~30 pessoas e um “núcleo duro” de 5 integrantes. Essas 15~25 pessoas “extras” são gente do negócio atuando na força tarefa. Gente que “leva e traz”, no bom sentido, o conhecimento necessário.

    Por favor, não estou sugerindo que a figura do Dono do Produto é desnecessária e muito menos que ela seja redondamente equivocada. Mas precisamos aceitar que ela é um “ponto único de falha” nesse sistema chamado Scrum. Suas vantagens (particularmente a esperada agilidade na tomada de decisões) não a livra de um risco potencial: a falta de conhecimento.

    Existem ainda outros dois fatores que diferenciam essa proposta do Scrum. Os times, apesar de levemente acoplados, mantêm comunicação constante. Sei que isso começou a ser tratado quando pipocaram questionamentos sobre a escalabilidade do Scrum. Aquele papo sobre “Scrum de Scrums” e coisa e tal. O fato é que esse patch não seria necessário se o desenho original³ fosse preservado. O segundo fator é a “Base de Conhecimentos”: aqui temos todo o conhecimento explícito acumulado a cada projeto. A ênfase no conhecimento tácito (e na comunicação direta entre times de projetos e o negócio) não significa o desmerecimento de tudo o que pode e deve ser explicitado (e documentado).

    Resumindo, eu vejo dois grandes problemas no Scrum que não existiriam caso seguíssemos acompanhando os trabalhos de Takeuchi e Nonaka:

    1. O “sistema” original é completo. Ele entende que quem cria conhecimentos são os indivíduos mas quem os amplifica é a organização. Times de projetos são sintetizadores desse conhecimento. O Scrum não pode ignorar ou tratar de forma simplista essas trocas;
    2. A ênfase em dados “duros” e conhecimento explícito (e mensurável) é a prorrogação de uma mentalidade herdada do século XX, de Taylor, Ford e afins. Um pensamento que desemboca em um absurdo que vi na forma de um cartaz no último Agile Vale realizado em São José dos Campos: “Se o miojo fosse ágil ficaria pronto em um minuto e meio”. O Scrum, lá na sua raiz, nunca prometeu a agilidade pela agilidade. Nunca foi uma questão de fazer de maneira ultra-rápida o mesmo trabalho. A busca cega por eficiência está nos desviando de forma muito preocupante do que é fundamental: fazer a coisa certa!

    ?

    Observações:

    1. Os dois artigos citados, de 1991 e 95, podem ser encontrados em “Gestão do Conhecimento“, de Hirotaka Takeuchi e Ikujiro Nonaka (Bookman, 2008). Aproveito a deixa para recomendar outro livro, mais completo, que apresenta a versão original (em inglês) do segundo artigo: “Knowledge Management: Classic and Contemporary Works“, editado por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (The MIT Press, 2000).
    2. Ana Thorell, tradutora do primeiro livro acima, optou por “difícil” ao traduzir “hard”. Mantive a tradução original mas, logo abaixo, falei de “dados ‘duros’”. Não sei qual ficou pior.
    3. Assim como não sei se Takeuchi e Nonaka têm noção do belo monstro que ajudaram a criar, o tal de Scrum. É importante lembrar, antes que levem a culpa por alguma coisa, que eles não tinham a intenção de criar um framework para gerenciamento de projetos ágeis. Miravam a lua. É importante que nossos tiros, a partir do momento que são cópias ou derivações, não se contentem em atingir apenas o topo da montanha.
    4. “Tree-in-Pot” é o nome do cartoon de hoje. Pra variar, do HikingArtist.

     

  • O Dono do Produto

    Tão ou mais complicado do que criar o produto – em meu caso, um treinamento – será o trabalho de ‘criar’ uma freguesia para ele. Sei que o FDP¹(Formação de Donos de Produtos) atrairá gente letrada e com experiência em projetos de software. Ok. Entendo que a maioria delas não vai desempenhar o papel e sim apoiar e orientar os profissionais que o farão. O treinamento deve contemplar esta modalidade de uso e o faz². Mas eu também sei que o evento não será legal se não contar com “não-letrados”, gente que não seja de TI e sim do negócio. Este treinamento foi desenhado principalmente para eles, nossos (frequentemente) mal compreendidos e (invariavelmente) mal tratados usuários. Ok, sei que não vou atrai-los com demagogia barata. Antes de mais nada, é preciso explicar melhor quem é esse tal de Dono do Produto (ou Product Owner), o que ele faz, como, porque etc. É o que tento com este artigo.

    .:.

    O dono do produto é O Cara. O cara que deve gerenciar o escopo de um projeto e garantir que o produto criado realmente gerará valor para o negócio. Do glossário oficial não consta o termo “escopo do projeto” e sim “Product Backlog”. Aqui, para desagradar a gregos e troianos, vamos chamar esse trem de Pauta. Antes que você tenhas ideias criativas e/ou nocivas, retomemos o fio da meada. O dono do produto, como o próprio nome confessa, tem a palavra final sobre funcionalidades, características e formato da obra gerada pelo projeto. E, acima de tudo, ele deve garantir que o produto atenda os objetivos pré-estabelecidos, ou seja, que ele gere valor. Peço sua atenção para o termo “pré-estabelecidos”. Obrigado. Já já conversaremos sobre isso.

    O dono do produto (DP daqui pra frente) deve ser do negócio. Aqui temos duas possibilidades. Se o produto destina-se para uso interno, então o DP será um representante de todos os usuários. Dele será exigido domínio do problema que o produto ajudará a resolver. Ele será escolhido não só pelo (amplo e profundo) conhecimento que detém, mas também pelo bom relacionamento com todas as outras partes interessadas. Deve ser reconhecido e merecedor da autonomia que receberá.

    Quando o produto é dirigido para o público externo, então o DP pode ser o próprio gerente do produto, quando existir, ou então um representante da área de marketing da empresa. É interessante notar que neste contexto o DP, na maioria das vezes, não cuidará de apenas um projeto mas de todo o ciclo de vida de um produto. Desconfio que seja uma possibilidade pouco aproveitada em solo tupiniquim.

    Do DP espera-se autoridade e autonomia em todas as decisões sobre o escopo do produto e as prioridades do projeto. Dele será cobrada disponibilidade para atender os demais membros da equipe do projeto. Recomenda-se que ele dedique, no mínimo, uma hora por dia ao projeto.

    Um DP por Projeto – Um Projeto por DP

    Por óbvio que pareça, é preciso dizer que cada projeto, cada produto tem um e apenas um dono. Invertendo a equação pisamos em terreno não tão óbvio: um DP deveria cuidar de apenas um projeto. Dois, no máximo. E desde que sejam pequenos. As empresas de Pindorama têm a péssima mania de jogar em seus profissionais uma carga de trabalho exagerada. Os profissionais de Pindorama têm o péssimo costume de tentar equilibrar em seus ombros uma carga de trabalho muito além de sua capacidade de entrega. Daí a relevância deste parágrafo.

    Um ponto não tão claro que só agora ganha a devida relevância é a solidão do DP. Segundo algumas interpretações, esta seria função de uma só pessoa. Uma visão mais prática e pragmática nos abre outras possibilidades. O DP pode ser uma pessoa sem disponibilidade para entrevistar n usuários, detalhar n cenários, responder n dúvidas do time etc. Pode ser muito n para uma pessoa só. Por isso autores como Jim Highsmith e Roman Pichler sugerem a existência ou necessidade de um Time do Produto³. Este time, como já foi apresentado aqui no finito, pode ser composto por analistas de negócios, consultores, especialistas no domínio e outros usuários ou partes interessadas. Cabe ao DP manifestar a necessidade de apoio. E ele não pode ser constrangido por dogmas bobos. Ele é o *dono* e, como tal, deve saber do que precisa para fazer seu trabalho bem feito.

    Colocado e Falante

    De boa que é, merece repeteco uma afirmação que fiz em artigo recente: “é o olho do dono que engorda o boi”. Colocando de outra forma: não há DP distante ou remoto. No mundo ideal ele ocupa a mesma sala dos outros integrantes do time. No mundo real ele deve visitar esta sala pelo menos uma vez por dia. E permanecer lá, à disposição e sem interrupções (celular desligado, please!), por pelo menos uma hora.

    Quando apostamos na figura de um DP estamos fazendo uma aposta bem maior: no valor do conhecimento tácito, na eficácia das conversas. Ou, como colocou um freguês, “estamos trocando 10 páginas de documentação por 10 minutos de prosa”. Se o DP não tiver disponibilidade e não for onde o time está não há conversas. Se elas não ocorrem então perdemos a aposta. Simples assim.

    O Passo Esquecido

    Este é o título de um dos capítulos do FAN. Descreve aquele fundamental e mal tratado momento que ocorre entre o entendimento de um problema e o desenvolvimento de sua solução. Aqui ele ganha escopo mais amplo. Trabalhos clássicos que ajudaram a criar e definir o papel do DP – como “Agile Project Management with Scrum“, de Ken Schwaber (Microsoft Press, 2004) – partem de uma visão do produto já definida. Sim, agora estou falando sobre aqueles “objetivos pré-estabelecidos” para os quais chamei sua atenção lá no início do artigo. É razoável supor que o DP participará da criação da visão do produto do qual é *dono*, não? Não me pergunte porque aqueles trabalhos ignoram este momento. Eu não saberia responder. Não sem uma considerável dose de veneno.

    Os conhecimentos do DP são mais exigidos nos momentos iniciais do projeto. Será um sinal de sanidade do projeto a decrescente dependência dos outros membros do time em relação ao DP. Significará que o conhecimento realmente se espalhou pela equipe. Todos passarão a demonstrar de razoável a impecável domínio do problema que tentam resolver. O que não pode significar, de forma alguma, o afastamento ou distanciamento do DP. Ele sempre terá responsabilidade pela manutenção e priorização da Pauta do projeto, do primeiro ao último dia do projeto. E, claro, é ele quem aceita ou não o resultado de cada iteração (ou sprint).

    Os Passos Executados

    Como já vimos, o DP tem duas grandes responsabilidades em um projeto: i) Definir a Visão do Produto e respectiva Pauta – funcionalidades e características de um produto. Fica subentendido aqui que a Pauta é formada por itens devidamente priorizados e que a priorização também é responsabilidade exclusiva do DP; e ii) Garantir que o produto em gestação está definitivamente a caminho de realizar os objetivos do negócio. Cada responsabilidade compreende um conjunto de atividades que fica a cargo do DP.

    A Pauta (lembre-se, o Product Backlog segundo gramáticas oficiais) deriva da Visão do Produto. A criação de ambas é responsabilidade do DP. Espera-se que a Visão, normalmente de alto nível (2km X 2cm…), seja estável durante todo o projeto. Ela explica funcionalidades e características gerais do produto, além de oficializar restrições (escopo, prazos e custos). A visão deve mostrar, principalmente, como o produto gerará valor para o negócio.

    Já a Pauta será desenvolvida de maneira iterativa e incremental. O DP e o time se preocuparão em detalhar apenas os itens necessários no horizonte pré-fixado (da iteração ou sprint). Uma iteração geralmente dura duas ou quatro semanas. Projetos estressados (complexos em sua porção negócio ou tecnologia ou ambas) devem utilizar a primeira opção. Projetos tranquilos se contentam com a calmaria dos ciclos de trinta dias. Espera-se que o DP (e seu opcional Time de Produto) esteja trabalhando no entendimento e detalhamento dos itens que comporão a pauta da iteração imediatamente posterior. Particularidades do projeto, da organização ou a velocidade do time podem pedir que o DP trabalhe com duas ou até três iterações de antecedência. É importante notar que isso não pode significar, em hipótese nenhuma, o não atendimento do time na iteração atual – dirimindo dúvidas e verificando a realização do produto, principalmente.

    Praticamente todos os proponentes de métodos que utilizam a figura do DP sugerem que os itens que compõem a Pauta sejam redigidos na forma de Histórias de Usuários (ou User Stories). Este padrão “força” a realização de conversas. É importante que o DP saiba que existem alternativas (casos de uso, por exemplo) e que ele deve optar pelo formato que lhe deixe mais confortável. Algumas organizações precisam de um pouco mais de formalidade (aka Documentação), por razões mil (sendo que 989 são bullshitagem/burocracia pura). Dependendo de suas exigências, parte do time pode ser destacado para atendê-las. Colocando de outra maneira: da porta (da sala do time de projetos) pra fora é oferecida uma documentação mais formal; Da porta para dentro o time pode optar por um padrão de conversas mais informal e leve. Um bom DP saberá lidar com as duas modalidades de comunicação.

    Em inglês fala-se que o DP é responsável por “grooming the product backlog”. Em tradução literal o verbo groom significa preparar, arrumar (ou adestrar cavalos). Acho que, em português, devemos nos contentar com o termo “manutenção da Pauta”. É crucial que o DP saiba que a Pauta é um (documento? artefato? ferramenta? – são tantos termos detestados, tantas emoções desperdiçadas…) Começando de novo: É crucial que o DP saiba que a Pauta é um trem vivo – um negócio que exigirá sua atenção diária. Itens da Pauta (requisitos, histórias ou casos ou…) ganharão ou perderão prioridade; mudanças surgirão (e não serão tratadas como más notícias); erros serão cometidos (e não significarão pena de morte aos seus causadores). Se o DP não administrar (!) diariamente todas as ocorrências as quais estão sujeitas a sua Pauta, me diga: que p%&R@ o cara está fazendo lá?

    Aos Donos com Carinho

    Por tudo isso e mais um tanto é que se diz que a função do DP é a mais crítica e complexa em um projeto guiado pelo framework Scrum. A vida de um DP não é nada fácil. Mas pode ser muito gratificante e edificante (Houaiss: que conduz à virtude). Quem já entregou projetos e viu os olhos dos usuários brilharem (e seus respectivos negócios lucrarem) sabe do que estou falando. A entrega de um produto pelo DP guarda uma satisfação ainda maior, exatamente porque foi ele quem desenhou e de certa maneira conduziu aquela realização. O bom DP sabe que o sucesso deve ser compartilhado por todos que participaram do projeto. Mas lá no fundo ele guarda algo que não confessará: a impressão digital mais notável deixada no produto é sua. Para o bem ou para o mal.

    .:.

    Observações:

    1. Foi em um belo boteco de Copacabana, bem servido de chopps, que consegui convencer meu parceiro de que a sigla FDP é filhadaputamente excepcional para uma oficina que se propõe a Formar Donos de Produtos. Além do apelo pop, serve também para peneirar e manter chatos ultrasensíveis bem distantes. Quem não güenta o leve tranco d’uma brincadeira boba demonstra não possuir um requisito mínimo que todo DP deve apresentar: bom humor!
    2. Faço questão de frisar na divulgação do FDP que todo o material didático utilizado está liberado para uso. As restrições são mínimas: i) Agradeça publicamente o autor; ii) Compartilhe o material utilizando a mesma licença; e iii) Se você pretende ganhar algum $ com o material, combine antes a comissão que irá me pagar. Preciso salientar isso porque sei que muitos vão querer replicar o treinamento em suas empresas. Em breve vou mostrar aqui no finito alguns dos itens que vão compor aquilo que estou chamando de “Kit do PO moderno” e que você poderá reutilizar.
    3. De longe já são os dois livros mais citados aqui no finito: “Agile Project Management – Second Edition“, de Jim Highsmith (Addison-Wesley, 2010) e “Agile Product Management with Scrum“, de Roman Pichler (Addison-Wesley, 2010). Se eu seguir referenciando-os assim periga eu te dispensar de estudá-los. Hehe.. brincadeira.
    4. Aproveitei o artigo para experimentar mais um pouquinho o método do Pensamento Visual. A sequência utilizada para apresentação do DP – quem, quanto, onde, quando, como e porque – obedece as regrinhas dos 6 W’s propostas por Dan Roam em “The Back of the Napkin” (Portfolio, 2008).
    5. A foto utilizada no topo, “Home Market: 1941 in Worthington, Ohio“, é do Don O’Brien.

    Faltou dizer:

    Caramba, ainda estás por aqui? Este artigo está com o dobro do tamanho padrão (2200 palavras!). Mas faltou dizer… Que o DP não é uma exclusividade dos projetos que são guiados pelo framework Scrum. Aliás, não precisa ser uma exclusividade. Ele é uma adaptação, por exemplo, do Engenheiro-Chefe utilizado pela Toyota há décadas. Pode ser visto também como uma exótica e criativa remixagem das funções do gerente de produtos e do gerente de projetos.

    É claro que, apesar das “licenças poéticas”, baseio boa parte de minhas sugestões no DP conforme definido na gramática oficial do Scrum. Mas preciso dizer que a idéia do DP, de boa que é, não deve ficar limitada ao uso do Scrum. Pronto, disse. Inté!

  • Scrum praticundum burungundum

    A crescente adoção do Scrum por empresas tupiniquins chega a ser surpreendente. Seu uso por pequenas e médias empresas da indústria digital é facilmente justificável. Mas quando vemos grandes negócios – de áreas não relacionadas diretamente com TI – adotando aquele framework ágil para gerenciamento de projetos, devemos entender que algo importante está acontecendo.

    Este artigo é o primeiro de uma pequena série que tem a intenção de ilustrar um pouco o estágio atual de uso do Scrum no Brasil. Nesta primeira parte, um breve panorama – uma fotografia com 2km de extensão por 2cm de profundidade. Na sequência escreverei sobre os probleminhas que tem sido reportados com mais frequência em relação ao uso do Scrum. Questões relativamente pequenas, mas com potencial para batizar o mais novo integrante da família das boas ideias que fracassaram.

    .:.

    O Scrum, na forma como o conhecemos hoje, está quase completando 20 anos de existência. Partiu de ideias e experiências da dupla Takeuchi e Nonaka¹. Mas adquiriu corpo e alma nos trabalhos e escritos pioneiros de Ken Schwaber e Jeff Sutherland². Ganhou trilha e impulso para o mainstream com a publicação do Manifesto Ágil. Dentre as diversas propostas de métodos e processos ágeis, o Scrum se destaca por ser o único que se preocupa exclusivamente com os aspectos gerenciais de um projeto. Por não incorporar nenhuma prática de engenharia, o Scrum possibilita sua combinação com diversas outras propostas, do RUP (Rational Unified Process) ao XisPê (eXtreme Programming), passando pela galáxia que existe entre eles.

    O que vou colocar no próximo parágrafo não tem a força de uma pesquisa estruturada. Por outro lado, a população amostral é suficientemente grande (2000+) para garantir que eu não esteja viajando ou forçando a barra.

    Nas primeiras turmas do FAN, no já longínquo 2007, apenas 5% dos participantes, em média, levantavam a mão quando eu perguntava: “Quem *conhece* o Scrum?” Na última edição do evento em São Paulo, no final de setembro, mais de metade da sala respondeu positivamente. E esta é a média de todas as turmas que encontrei neste ano, em São Paulo, Belo Horizonte e outras praças. Claro que não posso concluir que a adoção do Scrum no Brasil aumentou 1000% em três anos. Mas, pensando bem, desconfio que foi algo com tal magnitude que aconteceu. Aliás, está acontecendo.

    Testemunhei algo parecido, em menor escala, entre os idos de 1998 e 2000 e pedrinha. A moda e elixir para todos os males dos projetos de software de então era o RUP. Foi adotado por grandes empresas, como Petrobras e BankBoston, e estava nas bocas e agendas de todo mundo minimamente antenado com a área. Algum tempo depois, em empresas diferentes e distantes, vi reações parecidas: “Não fala de RUP que me dá urticárias!” Não vale o espaço e muito menos o seu tempo o diagnóstico sobre o que aconteceu com aquele incomensurável corpo de boas ideias (pobres estratégias e falsos evangelistas).
    {Mas merece nosso tempo a preocupação de que algo semelhante aconteça com o Scrum. Neste artigo, publicado em setembro/2009, eu falo um pouco sobre isso.}

    Antes, porém, vale a pena ilustrar um pouco mais a crescente adoção do leve processo de gestão que sugere a divisão das partes interessadas entre “porcos” e “galinhas”. Como já coloquei, não é difícil justificar o uso do Scrum por pequenas e médias empresas prestadoras de serviços de TI. Elas não puderam saborear adequadamente o RUP porque ele era um produto (leia-se: seu uso significava, na maioria das vezes, um pesado investimento em ferramentas que ‘viabilizariam’ o uso do método). Agora, elas ganharam um método que não cobra royalties nem força o uso de (dispendiosas) ferramentas. E, talvez um ponto mais importante: elas ganharam um método cuja implantação é relativamente fácil, rápida e barata. Ou seja, um sonho.

    Surpreendente é o fato de algumas grandes empresas também apostarem no Scrum. Inclusive empresas de ramos que têm a péssima fama de serem conservadoras e burocráticas – pelo menos no que se refere a TI – como bancos e seguradoras. Entre tudo o que é sinalizado em movimentações deste tipo, parece nítida uma grande insatisfação com processos, padrões e metodologias utilizados até então.

    No primeiro semestre apresentei duas palestras para um dos maiores bancos do Brasil. Fui convidado para “provocar” e apresentar “tendências”. A segunda palestra foi motivada pelo “burburinho” gerado na primeira. E foi dirigida para gerentes e afins. Ao justificar o encontro, um dos principais executivos da área disse: “Precisamos de novas ideias”. Em outro momento, nas entrelinhas de uma nova intervenção do mesmo executivo, havia uma mensagem bem direta: “Não dá pra continuar trabalhando da forma como fazemos hoje”.

    Há tempos, esta e diversas outras empresas acreditam que os problemas de comunicação entre áreas de negócios e TI podem ser combatidos com mais documentos, assinaturas, change requests e coisas do tipo. Ao final do evento aquele mesmo executivo brincou concluindo que “cada dez minutos de boa conversa pode eliminar a necessidade de dez páginas de papel”. Para todas as empresas que chegaram neste ponto, e não são poucas³, o Scrum apresenta possibilidades maravilhosas. É difícil ignorar o canto da sereia que cobra tão pouco pelo muito que promete.

    O movimento no mundo dos negócios tem reflexos no universo da educação. Agora, além dos tradicionais cursos relacionados com Scrum e similares, passaremos a ver apostas mais ambiciosas e, de certa forma, mais abrangentes. Um curso de extensão da Universidade Federal de São Carlos (UFSCar), que neste ano fez uma experiência com um método “genérico” baseado no modelo iterativo e incremental, adotará o Scrum para a turma de 2011. Os Donos dos Produtos (Product Owners, ou simplesmente PO’s) já foram nomeados – são funcionários da Universidade – e os projetos já foram definidos. Assim como a grade com a distribuição das disciplinas. É o tipo de experiência com potencial para espalhar ainda mais a “novidade” Scrum. Realizada por uma entidade com o nome e peso da UFSCar, pode significar um impacto ainda maior.

    .:.

    Observações:

    1. Desconfio que Takeuchi e Nonaka nem prestem muita atenção em sua distante “criatura”. Na realidade eles apenas inspiraram a criação do Scrum. O que eles devem realmente lamentar é o fato de outras grandes descobertas e experiências suas não ganharem o impulso “pop” que o Scrum experimenta hoje. A dupla – que digo parecer dupla sertaneja ‘de raiz’ de Piracicaba – publicou alguns dos trabalhos mais relevantes da mal interpretada disciplina conhecida como Gestão do Conhecimento. Vou citar três: “Gestão do Conhecimento“, compilação de artigos organizada pelos dois (Bookman, 2008); “Theory of Organizational Knowledge Creation” e “Reflection on Knowledge Management from Japan“, artigos publicados na obrigatória coletânea “Knowledge Management – Classic and Contemporary Works” (MIT Press, 2000).
    2. De Ken Schwaber: “Agile Project Management with Scrum” (MS Press, 2004) e “Enterprise and Scrum” (MS Press, 2007).
      De Jeff Sutherland: Scrum Log (desde 2002).
    3. Essa coisa que diz que escrever mais é a solução gera situações cômicas. Em uma turma fechada do FAN no Rio de Janeiro, eu explicava os cinco níveis de detalhamento que uma especificação de casos de uso pode ter. Mostrava aqueles cinco ícones sugeridos por Alistair Cockburn em “Escrevendo Casos de Uso Eficazes” (Bookman, 2006). Quando terminei a explicação um aluno falou: “Pra gente, que trabalha com fábricas de software, isso aí não vai funcionar não. Faz o seguinte: depois da ‘ostra’ (o nível mais baixo) vamos colocar mais um ícone. Sete mil metros abaixo do nível do mar. Coloca o símbolo da Petrobras e vamos chamar isso aí de ‘Nível Pré-Sal’. Só assim as fábricas fazem o que a gente precisa”.
      Triste conclusão de outro participante: “Nem assim funciona…”
    4. A foto utilizada, “Vertical Scrum“, foi tirada pelo Jurvetson.