finito

Tag: Sprint

  • 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
  • Sistema de Blindagem Inteligente, Parte II

    Sistema de Blindagem Inteligente, Parte II

    Caso tenha perdido, aqui está a primeira parte. A encerrei relacionando quatro impedimentos para a adoção do Scrum na empresa YYZ (nome alterado). Importante lembrar: mais que ao Scrum, são impedimentos para a realização de sete objetivos da área de TI daquela empresa. O Scrum é só (!) um possível meio de atendê-los. Dos quatro ‘bloqueios’, um é mais crítico: os times consomem aproximadamente 80% de seu tempo cuidando de problemas do dia a dia. Como proteger os times? Há uma forma de blindagem minimamente inteligente? Abaixo, o desenrolar do enrolado causo.

    ?

    O impedimento crítico foi apresentado para uma equipe de coordenadores – quase todos os responsáveis pelos onze times que formam aquela unidade de TI. Seguiu-se um debate sobre alternativas de solução – opções de blindagem.

    A primeira, aparentemente bastante simpática aos coordenadores, considerava a alocação de poucos membros (20%) de cada vertical para o atendimento das demandas emergentes / urgentes. Além disso, todos os times dedicariam cerca de 20% de seu tempo para essas questões. Era, com certeza, a alternativa que menor impacto causaria na estrutura atual.

    O diagrama¹ acima destaca duas restrições principais para a sugestão. A primeira é “matemática”: mesmo que destacássemos 20% dos membros do time mais 20% do tempo de toda a equipe para cuidar dos requisitos urgentes, não seria possível atender todas as demandas (lembre-se: elas consomem atualmente 80% do tempo útil de todo o time). A consequência natural seria o acúmulo de demandas não atendidas, seguido do aumento da insatisfação dos usuários e assim por diante. Além disso, há o aspecto cultural que não pode ser negligenciado. Ele foi destacado na primeira parte: a empresa YYZ tem uma (honorável) política de portas abertas. Todo mundo pode falar com todo mundo praticamente a qualquer hora do dia (e da noite!). Fazer com que os usuários falassem apenas com determinados membros e/ou em período pré-determinado vai contra uma cultura estabelecida de longa data.

    A mesma questão cultural aparece como impedimento para a alternativa #2. Nela, conforme sugerido pelo responsável pela área de TI, todas as demandas seriam encaminhadas para a área de help desk. Muitos dirão que já deveria ser assim. De certa forma, é. A área de suporte da YYZ recebe uma média de seis mil (6k!) chamados por mês, 1500 deles relacionados ao ERP. E consegue fechar (bem) algo em torno de 85% deles. O resto? Sobra para as verticais de negócios. E junta-se aos requisitos que os usuários preferem apresentar de maneira direta (em uma mistura de demandas ditas “evolutivas” com simples alterações de telas, pequenos bugs etc). Como adiantei, há a questão cultural: os usuários não podem ser impedidos de se relacionar com as verticais que os espelham em TI. Mas há uma segunda e mais grave restrição para a segunda alternativa. Falta gente. Mais: falta gente qualificada. Cheguei a sugerir o deslocamento de analistas de negócios e desenvolvedores para lá. Propus engolindo. E engoli seco. Ninguém aceitaria um movimento que tinha cara e jeito de “rebaixamento”, por nobre que seja o serviço de suporte. O treinamento de novos integrantes foi cogitado. Mas, como o diagrama tenta indicar, é coisa que toma tempo. Muito tempo.

    Sobrou a terceira alternativa. Aquela que, como consultor, defendi. Partindo do princípio de que a blindagem total dos times é impossível, não resta outra opção que não seja a criação de um novo time. Um time que seja desconhecido pelo negócio e respectivos representantes. Ou seja, além de blindado ele também é invisível². Desta forma as verticais de negócios cuidariam exclusivamente do cotidiano – atendimento aos usuários e solução de pequenos problemas. Seriam também a porta de entrada para as chamadas “demandas evolutivas”. Para tanto, seguiriam contando com pessoal capaz de executar atividades de análise de negócios. Talvez um pouco mais que isso. O coordenador de cada área poderia vir a ser um Dono do Produto (Product Owner ou simplesmente PO, como queira). Eu sei, eu não curto muito esse papo de dublê de PO. Mas, neste caso, dado o invejável conhecimento do negócio que cada coordenador apresenta, os riscos inerentes ao desenho eram consideravelmente reduzidos. E haveria outro benefício: o novo time seguiria de fato invisível. Mas, quem integraria o novo time?

    Você se lembra que os coordenadores estavam dispostos a “sacrificar” 20% de seu time para cuidar exclusivamente das demandas não previstas? Bom, se pegarmos 20% de cada uma das sete verticais de negócios (que têm, em média, 8 integrantes) mais o time de controle de qualidade (pelo menos 60% dele – seis profissionais) temos uma nova composição com cerca de 17 pessoas. Praticamente 3,5 times de Scrum (considerando o tamanho ideal sugerido: 5 (+/- 2)). Claro, este time seria multidisciplinar, auto-organizado, dono de seus processos e, o mais importante, orientado por um e apenas um Product Backlog. Quase sem querer (querendo!) já atendemos o objetivo #1 da lista que foi apresentada na primeira parte: “Ter uma fila única de demandas”. Dois coelhos, talvez alguns mais, numa única porretada. Parecia tudo muito bom para ser verdade. Quais restrições para esta alternativa foram apresentadas?

    “Esse time não teria real domínio do negócio”, disseram alguns. Oras, para isso existem os PO’s e seus asseclas (analistas de negócios e afins), certo? Além disso, o novo time é formado por gente que já tem, em média, três anos de casa. E são provenientes de todas as verticais de negócios, o que representa um certo conhecimento e visão do todo. Sinceramente, isso não é restrição que se apresente. Porque ela não para em pé. Então, uma segunda restrição – aparentemente mais forte – foi colocada: “O <nome_do_responsável_por_ti> não quer que demandas evolutivas sejam separadas das corretivas”; “Além disso, o <nome_do_responsável_por_ti> não permite em hipótese nenhuma que duas equipes trabalhem nos mesmos artefatos“. Quantos traumas, quantas noites mal dormidas e quantos sistemas bisonhos de controle de versões são necessários para criar restrições tão… sei lá. Prefiro não adjetivar. Assim como preferi não gastar meu tempo com um estudo antropológico daquelas raízes pré-históricas. Me limitei a lembrar Peter Senge: “Os problemas de hoje vêm das soluções de ontem.”

    Percebi que não se tratava apenas de restrições do <nome_do_responsável_por_ti>. Os próprios coordenadores não gostaram nadinha da ideia de um novo time. Um time que provavelmente viveria sem a figura de um coordenador e que ficaria com o filé, enquanto eles seguiriam com o feijão com arroz do cotidiano. A antipatia deles pela sugestão é perfeitamente compreensível. Mas não é justificável.

    Faltou a eles enxergar um pouquinho além e entender que este desenho, como todos os outros, é temporário. Não entenderam que o novo time seria um “super” prestador de serviços para eles. E faltou acreditar que, com o tempo, o novo time poderia ser gradativamente incorporado às suas unidades. E que isso seria possível tão logo o tempo de resposta fosse reduzido para prazos que excedessem minimamente as expectativas dos usuários; o que os levaria para a fixação de acordos de níveis de serviços (objetivo #4 da lista original). Antes que você me chame de ingênuo e/ou simplório: resumi veredito e consequências.
    {Mas, caso queira explorar um pouco mais esta parte, por favor, comente! Acho que o assunto é bom demais para morrer aqui, só com minhas palavras.}

    Algumas Referências para a Alternativa #3

    Pois é, o artigo está ficando mais longo que o usual. Mas não quero fazê-la(o) esperar por uma terceira parte. Conto com mais um pouco de sua atenção.

    Já tem um bom tempo, creio que quatro ou cinco anos, que li um artigo sobre uma grande mudança que estava acontecendo na Promon. Eles estavam “duplicando” várias gerências. Uma cuidaria do dia a dia. A outra, nova, trabalharia apenas no “amanhã”. Me apaixonei pela ideia mas, infelizmente, não vi mais nada a respeito. Sei lá se foi mantida, muito menos o que conseguiram. Temo que, por considerar apenas os gerentes, a coisa não tenha vingado.

    Mais recentemente começaram a pipocar artigos e teses sobre “organizações ambidestras“. Apesar de algumas interpretações meio tortas e rebuscadas, a proposta central parece ser a mesma: separar o presente do futuro. E fazer com que as organizações trabalhem nas duas frentes com a mesma atenção e dedicação. Não necessariamente com o mesmo volume de recursos. Mas, desejavelmente, com princípios e processos em comum.

    Sinceramente, não vejo alternativa que não passe por uma divisão assim. O problema com esse tipo de mudança é que ela é drástica. O que significa dizer que a resistência a ela será igualmente forte. Pensando Scrum ou, mais precisamente, pensando Lean, não estamos mais falando de Kaizen (melhoria contínua) e sim de Kaikaku (mudança radical). E o que é necessário para a implementação de uma mudança radical? Coragem; sangue frio; apoio dos altos escalões; comprometimento com a solução… A lista é longa e não é estranha para você que conhece mudanças. Por isso vou tocar em um ponto relativamente incomum: quem promove uma mudança radical não alimenta a ilusão de que não haverão “mortos” e feridos. Muitos pularão do barco. E isso não é necessariamente ruim.
    {Está aqui outro ponto que podemos discutir bastante, não?}

    Epílogo

    Se você respeita o jeito Lean de pensar, então sabe que não pode tratar problemas (impedimentos ou bloqueios) com remendos rápidos e muito menos fazer vista grossa para eles. Você deve, literalmente, “parar a linha”, analisar as raízes do problema, encontrar e implantar uma solução para ele. Foi o que aconteceu com este serviço de consultoria. Interrompemos o processo, eu parei meu “relógio”, apresentei e propus discussões sobre os impedimentos. Um mês. Dois meses. Três meses…

    Fiquei sabendo que o <nome_do_responsável_por_ti> foi transferido para outro negócio da YYZ. Não sei dizer se as restrições que ele defendia permaneceram. Creio que não. Mesmo assim, não acredito que minha sugestão tenha uma nova chance. É assim mesmo: quantas vezes já fomos aconselhados a ter uma vida mais saudável, menos sedentária, mais preocupada com o amanhã? E quantas vezes seguimos os conselhos? São poucos os consultores, pais, esposas, médicos e afins que são de fato escutados. Menor ainda é o número dos que recebem prêmios milionários por seu poder de persuasão e objetivos alcançados.

    ?

    Observações:
    1. Não julgue o “diagrama” rabiscado, please! É só um resumo da apresentação das três alternativas e respectivas restrições. E, sim, é um Causal Loop Diagram (Diagrama de Círculos Causais). Caso você não conheça, a “o” (bolinha) ao lado de uma linha significa força (ou feedback) contrário (ou negativo). O “c” significa uma restrição (ou constraint). É uma ferramentinha que, pelo visto, está ganhando novo impulso. Na última segunda vi Jurgen Appelo utilizá-la para mostrar como esse negócio de desenvolver software é “doomed”. Mas pode ser salvo! Craig Larman também usou e abusou dela em seu último livro, “Scaling Lean & Agile Development” (Addison-Wesley, 2009).
    2. O aspecto “invisível” (do novo time) é desejável neste caso específico. Não o indicaria em ambientes que não tenham uma política tão aberta e generosa de “relacionamentos muitos-para-muitos 24×7”. Insisto, na YYZ o time só estaria 100% blindado se fosse “invisível”.
    3. “Trainee hatchings” é o título do cartoon de hoje. Como sempre, foi surrupiado do HikingArtist.
    4. Aquele xampu segue me provocando com o seu “Sistema de Blindagem Inteligente”.
  • Sistema de Blindagem Inteligente, Parte I

    Sistema de Blindagem Inteligente, Parte I

    Não é piada: o “sistema” que dá nome a este post aparece em uma embalagem de xampu. E me incomoda, a cada banho, há algumas semanas. Até xampu consegue fazer uma blindagem inteligente! Então por que seria tão difícil para algumas organizações isolar e proteger, ou seja, blindar um time de projetos? A questão passou a me atazanar com mais frequência depois que publiquei uma breve compilação sobre problemas mais comuns na adoção do Scrum. Aquele artigo passou batido pelo problema. Tentarei corrigi-lo agora. E vou fazê-lo através de um causo real minimamente maquiado por razões óbvias¹.

    ?

    A empresa YYZ, um imenso conglomerado com presença global, desenvolveu seu próprio ERP. Lá se vão anos desde que aquele imenso monolito viu a luz. Ele fora concebido para cuidar do núcleo do negócio e, claro, das finanças. Com o passar do tempo, ganhou inúmeras novas responsabilidades, da produção até a logística de armazenamento e entrega passando por tudo o que é possível existir entre estes polos. Ou, melhor dizendo, quase tudo. Não se aventurou a cuidar do RH, por exemplo. Apenas um detalhe. O fato é que o ERP, cimentado firmemente em um desenho Cliente/Servidor (de duas camadas e milhares de Stored Procedures), é grande. Quase imensurável.

    São onze os times que cuidam da manutenção e evolução do sistema. Sete deles cuidam de verticais específicas, como Vendas, Administração e Produção, por exemplo. Os outros quatro “prestam serviços” para eles. Bem, para dizer a verdade, eles não são vistos assim na maior parte do tempo. Um deles é o Controle de Qualidade. E não é tão comum assim ver este “departamento” sendo percebido ou se apresentando como um “Prestador de Serviços”. A verdade é que ninguém lá dentro precisava de um consultor para informar que a qualidade e seu respectivo controle deveriam ser incorporados aos times. Acho que apenas a própria área de qualidade. Consultor? Retomemos o causo.

    “Paulo, você nos ajuda a implantar o Scrum?” Claro, por que não? Mas, diga aí, por quê? Ops… perguntinha maldita, não? Alguns meses se passaram até que a contratação fosse fechada e, mais importante, até que a perguntinha maledeta fosse respondida:

    1. Ter uma fila única de demandas
    2. Saber o esforço que cada demanda consumiu
    3. Reduzir o tempo de entrega
    4. Fechar acordos de níveis de serviços (SLA) com áreas usuárias
    5. Tornar as demandas visíveis para as áreas usuárias
    6. Ter tempo para o planejamento estratégico
    7. Medir o desempenho dos integrantes das equipes

    Rabisquei o diagrama acima para determinar uma sequência de trabalho. Conclui que a realização do item 3, a redução do tempo de entrega, favoreceria a satisfação de todos os outros requisitos. E que o fechamento de SLA’s (item 4) só seria possível depois que todos os outros objetivos fossem minimamente atingidos. Portanto, o próximo passo era descobrir a razão das entregas serem tão demoradas (60 dias, em média, entre o registro da demanda e sua entrega definitiva para os usuários).

    Não nos custou um dia o diagnóstico dos quatro principais fatores que retardavam as entregas:

    • As especificações, elaboradas por analistas de negócios, são muito extensas (e de pouca ou nenhuma utilidade após as entregas);
    • A área de qualidade só sabe que algo é prioritário quando ouve gritos. No mais, administra uma fila que mistura tudo das sete verticais de negócios. E tem pouca gente para tanto trabalho, apesar de não cobrir 20% dos tipos de testes possíveis;
    • Dada a complexidade da distribuição – várias unidades espalhadas geograficamente – é compilada e entregue apenas uma “versão” por mês; e
    • Os desenvolvedores são atropelados diariamente por problemas, de bugs até o mal entendimento de determinadas funcionalidades pelos usuários, passando pelo que é mais grave: novas demandas urgentes.

    Me sinto à vontade para descrever o causo principalmente porque sei que os quatro problemas acima podem apontar para um sem número de empresas ao redor do globo. Não há nada de particular aqui, o que pode tornar este artigo realmente útil. Voltando para a história.

    Seria relativamente fácil solucionar os três primeiros problemas. Existe um padrão único para especificação de demandas. Requisitos imensos e minúsculos recebem o mesmo tratamento (burocrático), o que não faz sentido. Mais: toda a análise de impacto e definição do “como” (protótipos de telas, lista de alterações nos bancos de dados etc) é realizado pelos analistas de negócios, o que torna a vida dos desenvolvedores um sossego (e uma chatice só). Qualidade, o segundo problema, deveria ser incorporada (de fato e de direito) pelas verticais de negócios. Que deveriam ganhar também autonomia em relação a atualização de versões. Apesar do jeitão monolítico do ERP, vimos que era perfeitamente possível gerar mais de uma versão por mês. Daí a estimar (salivando) que seria possível uma redução de 60 para 15 dias do tempo médio de entregas foi um pulinho. Ingênuo pulinho.

    O quarto problema – o atropelo das verticais de negócios por questões do dia a dia – se apresentou monstruoso logo no primeiro dia da experiência com o Scrum. A empresa YYZ tem uma bela política de “portas abertas” para todos. Aliás, mal existem portas (e paredes). O que gera um efeito dramático na área de TI: usuários aparecem a qualquer momento com seus choramingos e requisitos. E não atendê-los está fora de questão.

    “Oras, Paulo, parece que fazes tormenta numa pequena caneca d’água! Não bastaria separar alguém do time ou parte do tempo de todo o time para o atendimento das demandas imprevisíveis?” Como, respondo perguntando, em um cenário onde elas consomem cerca de 80% do tempo útil de toda a equipe?

    O papo segue na parte II. Inté!

    ?

    Observações:

    1. Não revelo a identidade de meus clientes de consultoria exatamente para ter a liberdade de tratá-los como causos, aqui no {finito} e em meus cursos e palestras.
    2. Não, o xampu com “Sistema de Blindagem Inteligente” não é meu, ok?
    3. “getting away from it all” é outro cartoon que surrupio do HikingArtist.com