Uma equipe pode ter 150 pessoas? FAST Agile diz que sim

FAST ágil é a prática organizacional mais interessante que aprendi há algum tempo. Hoje compartilho o que é FAST ágil e exploro se vale a pena experimentar. TL;DR? Bastante atraente, mas ainda experimental.

O que é FAST Ágil?

1. FAST Agile é uma variante de software ágil. O FAST se concentra na auto-organização em equipes muito grandes. Essas grandes equipes são chamadas de Coletivos. Eles podem ser algumas pessoas, até 150 pessoas [1].

Duas vezes por semana, o Coletivo se reúne. Na reunião:

• Os membros da equipe mostram e contam o progresso que fizeram .
• O líder de produto reitera a visão e define a direção . Eles fornecem contexto sobre os principais projetos. Eles introduzem novas prioridades conforme o trabalho é concluído ou as prioridades mudam. E normalmente mostram as prioridades de forma visual, em uma parede ou equivalente virtual.
• As pessoas dentro do Coletivo se auto-organizam e se auto-selecionam em equipes menores para entregar o trabalho de alta prioridade.

A parte mais interessante do FAST ágil são essas equipes auto-organizadas, então vamos descrevê-las com um pouco mais de detalhes.

A cada reunião, as pessoas se voluntariam para liderar equipes e as pessoas se voluntariam para participar dessas equipes. Quando alguém se oferece como voluntário para liderar uma equipe, dá um passo à frente e diz: “Vou trabalhar em [um dos principais projetos]”. As pessoas então se juntam às equipes que foram criadas e trabalham naquela área. O tamanho mínimo da equipe é de dois, então você precisa que as pessoas “votem com os pés” para formar a equipe.

As equipes formadas fazem não tem que estar em torno das prioridades que o produto estabeleceu. Por exemplo, uma equipe pode se formar para melhorar o pipeline de implantação ou melhorar o monitoramento de alguns serviços instáveis.

Fora de uma hora por semana em reuniões, as pessoas passam a maior parte do tempo em equipes auto-organizadas e auto-selecionadas. Teoricamente, você poderia mudar de equipe duas vezes por semana. Mas, na prática, as pessoas acabam descobrindo com quem gostam de trabalhar e as equipes tendem a se estabelecer após o primeiro mês ou mais .

Eles permanecem fluidos o suficiente para que as pessoas possam se mover à medida que as necessidades de negócios mudam ou pessoas com experiência são necessárias em diferentes áreas. Mover equipes é uma mudança esperada e de baixo esforço. Então o que isso significa é que durante as reuniões do Coletivo, existe um padrão de pessoas recriando suas equipes, mas a composição tende a não mudar tanto quanto você imagina.

Há muitos outros detalhes, como como os bugs e os plantões são tratados. Abordarei alguns desses tópicos mais tarde. Mas o núcleo básico do FAST ágil são essas equipes auto-selecionadas, trabalhando dentro de um Coletivo maior, em projetos. As reuniões coletivas são estruturadas e focadas em contextualizar as necessidades do negócio e comunicar o progresso em relação a essas prioridades.

Resumo das diferenças

O FAST é muito diferente da maneira como a maioria das organizações de software ágeis executa hoje. Aqui estão as diferenças como eu as vejo:

Como você pode ver, o FAST é uma abordagem muito diferente do que a maioria das empresas está fazendo hoje.

Então, quais são as compensações?

A meu ver, essas são as compensações do FAST ágil:

• FAST pode oferecer melhor escalabilidade organizacional
• O FAST pode ser experimentado de forma incremental
• O FAST deve resultar em menos reorganizações
• O FAST torna mais fácil responder às mudanças de prioridades
• FAST poderia ser melhor para motivação intrínseca e retenção

Mas…

• Muitos ambientes são incompatíveis com o FAST
• Você pode ter que gerenciar o autogerenciamento
• RÁPIDO requer muito trabalho
• Os materiais do FAST estão cheios de jargões

Discutiremos cada um deles por sua vez.

FAST pode oferecer melhor escalabilidade organizacional

Quando você dimensiona as organizações, normalmente o faz dimensionando-as “horizontalmente”. Você aumenta a organização uma equipe de cada vez. Cada uma dessas equipes possui uma fatia do produto, e muitas vezes você tem uma organização de plataforma que torna as equipes de produto mais eficazes.

A complexidade da organização explode à medida que o número de pessoas aumenta. Se você tiver dez pessoas na engenharia, todas elas podem se comunicar umas com as outras. Cem pessoas na engenharia não podem falar umas com as outras. E a base de código não cabe na cabeça de ninguém. Então você segmenta essa complexidade em equipes, e cada equipe tem uma área na qual pode se concentrar.

O FAST é interessante porque é uma tentativa de escalar as organizações “verticalmente”. Em vez de adicionar mais equipes, o FAST tenta criar equipes maiores , chamadas de Coletivos. Os Coletivos ainda possuem código, mas as equipes auto-organizadas dentro desse Coletivo não. E você ainda tem que segmentar a comunicação. Mas as equipes estão mais dinâmicas e em constante evolução. Em vez de remodelar as equipes por meio de reorganizações, é uma parte contínua e esperada da maneira como você opera.

O tamanho da equipe é um tópico familiar para muitos chefes de engenharia. Qual deve ser o tamanho das equipes? Vamos nos aprofundar um pouco neste tópico, pois ele nos ajuda a entender como o FAST afirma ser melhor dimensionado.

Qual deve ser o tamanho das equipes?

Quando você passa algum tempo com o pessoal do vice-presidente de engenharia, ocasionalmente surge o tópico do tamanho da equipe de engenharia. Você ouvirá argumentos para equipes pequenas e argumentos para equipes grandes. Ambos os lados têm méritos.

Vantagens de equipes pequenas

• Menos sobrecarga de coordenação e comunicação dentro da equipe.
• Pode se mover rapidamente como resultado.
• Menos fluxos de trabalho, portanto, mais fácil de focar e produzir resultados.
• Mais fácil de gerenciar.

Vantagens de equipes grandes

• Organização mais plana. Uma organização de engenharia com 150 engenheiros terá de 3 a 4 diretores com equipes de dez pessoas. Terá 6-8 diretores e 1-2 VPs com equipes de cinco pessoas. De onde vem a confusão em uma organização? Provavelmente a liderança, então equipes grandes podem reduzir a confusão.
• Mais resiliência. Alguém pode tirar férias e a equipe pode continuar bem.

Portanto, equipes pequenas são ótimas dentro de sua equipe, mas menos ideais porque são tantas que aumentam a complexidade organizacional. Equipes maiores são melhores para a complexidade organizacional geral, mas menos ideais para o desempenho dentro de cada equipe.

A abordagem que muitos líderes adotam é formar equipes grandes que se concentrem em menos fluxos de trabalho. Isso reduz a complexidade da equipe interna e também reduz a complexidade organizacional.

Você pode ver o FAST como uma abordagem que tenta alcançar uma simplicidade organizacional ainda maior por meio de equipes ridiculamente grandes. E também tentou obter os benefícios de ter pequenas equipes automontadas.

Escalar organizações é um trabalho desafiador

Grande parte do meu negócio de consultoria é ajudar as organizações a lidar com a escala. Existem várias fases de desafios de dimensionamento que as organizações enfrentam.

A primeira barreira está tipicamente na marca do engenheiro 15-25. Este é o momento em que sua ameba ficou muito grande e precisa se dividir. Você vê esses tipos de problemas:

• Os canais de comunicação tornam-se ineficazes.
• A engenharia começa a ter problemas de entrega e/ou qualidade.
• Gerentes ou líderes se sentem sobrecarregados. Adicionar mais pessoas tornará tudo pior, não melhor.

E uma segunda barreira está em torno de sessenta engenheiros. Neste ponto, você começa a ver muito mais problemas de coordenação :

• Projetos entre equipes raramente são bem-sucedidos.
• O trabalho do produto inunda as equipes de plataforma ou vice-versa.
• Incapacidade de concluir grandes iniciativas.

Já vi pessoas brilhantes falharem repetidas vezes ao navegar por essas mudanças graduais na complexidade organizacional. Meu palpite é que esses aumentos de complexidade na ordem das etapas correspondem a quando você adiciona uma camada adicional de gerenciamento.

Desenvolver organizações de engenharia é uma habilidade real. Requer uma compreensão profunda de como as organizações e as pessoas funcionam. Você aprende sobre coisas como:

• Modelos de coordenação para fazer com que grupos de pessoas trabalhem juntos.
• Equipes alinhadas ao fluxo versus equipes projetadas funcionalmente.
• Como fazer reorganizações, onde você muda as pessoas e codifica conforme as prioridades de negócios mudam.
• Como dividir os produtos em áreas de responsabilidades técnicas que se sobrepõem ao investimento no produto.
• Criação de canais de comunicação em torno das equipes.
• Configurando programas de chamada e confiabilidade para dar suporte ao seu produto de forma eficaz.
• Criação de organizações de plataforma e iniciativas de experiência do desenvolvedor para combater a complexidade.
• etc.

Mesmo que você tenha pessoas com esse conhecimento, é necessário muito esforço da sua equipe de gerenciamento para lidar com o dimensionamento. Portanto, se o FAST puder escalar melhor, você liberará muito do potencial de sua equipe de gerenciamento para se concentrar em outra coisa. E, como suas alterações na ordem das etapas ocorrem com muito menos frequência, você pode estar tornando sua organização muito mais fácil de gerenciar.

Um experimento mental sobre FAST ágil

Então, imagine que você pode dimensionar o tamanho da equipe. Em vez de equipes de cinco ou dez pessoas, e se você pudesse ter equipes eficazes de vinte pessoas? Ou equipes de sessenta pessoas?

Em face disso, esta é uma proposição ridícula. Equipes tão grandes não são eficazes. Mesmo equipes de doze pessoas são um exagero. Às vezes, vejo os currículos de pessoas que tiveram vinte ou trinta subordinados. Minha reação imediata é pensar que eles trabalharam em uma empresa terrível. Ter tantos subordinados diretos é um “cheiro organizacional”.

A premissa central do FAST ágil é que, se você adicionar equipes de auto-organização e auto-seleção dentro desse Coletivo maior, poderá escalar suas equipes de forma mais horizontal . Cada equipe (o FAST os chama de Coletivos) pode ser muito maior. E então as equipes com as quais as pessoas trabalham no dia a dia são auto-montadas dentro desses Coletivos.

Se os coletivos maiores fossem eficazes, eles reduziriam significativamente a complexidade organizacional. A inicialização típica de software pode levar anos a mais antes de ter que se dividir em áreas de responsabilidade. A base de código não precisaria ser rigorosamente segmentada em áreas pertencentes a cada equipe. Isso liberaria um tempo significativo de gerenciamento que os gerentes poderiam usar para se concentrar no produto e nas equipes.

Portanto, esta é a coisa central que precisamos testar: a automontagem e a autoorganização oferecem uma maneira de operar tão eficaz quanto equipes menores projetadas?

Em caso afirmativo, oferecerá uma maneira de dimensionar organizações que é potencialmente uma ordem de grandeza melhor em dimensionar organizações. Por que tanto? Vamos comparar uma organização em crescimento com equipes de seis pessoas versus uma organização em expansão com “equipes/coletivos” de sessenta pessoas.

Há muitas suposições incorporadas a esse argumento, e você pode encontrar alguns buracos nele. Mas mesmo se você fizer isso, o FAST está essencialmente permitindo que uma unidade organizacional maior possua uma área do produto e da base de código.

O FAST é novo, então não há muitas evidências no momento sobre se as equipes FAST operam de forma tão eficaz quanto as equipes ágeis convencionais. Mas suspeito que a resposta para essa pergunta seja sim. Tenho algumas razões para acreditar nisso. Em primeiro lugar, a experiência preliminar de Jim Shore com ele foi bastante positiva, e ele é alguém em quem confio.

Uma segunda razão pela qual estou otimista com o FAST é que tive alguma experiência com grandes grupos de pessoas fazendo auto-organização. E fiquei surpreso com o quão bem funcionou.

Em pequenas empresas, é claro, você vê muita auto-organização. Mas à medida que as empresas crescem, você padroniza as coisas e remove a auto-organização, exceto dentro das equipes. No entanto, um dos experimentos mais interessantes de que participei foi um evento de auto-organização em grande escala na New Relic. Redesenhamos todas as nossas equipes e pedimos a todos em cinquenta equipes de software que selecionassem de qual equipe gostariam de fazer parte. Tínhamos restrições nas habilidades necessárias para cada equipe e definimos o que todos precisavam possuir. Acabou tendo muito mais sucesso do que qualquer um esperava, até mesmo nós, organizadores.

Portanto, embora o júri tenha decidido sobre isso, meu palpite é que essa prática tem muito potencial nos contextos certos.

O FAST pode ser experimentado de forma incremental

Isso não é mencionado nos materiais do FAST, mas uma coisa que me chamou a atenção como sendo interessante sobre o FAST é que você pode experimentá-lo de forma incremental.

Você pode implementar o FAST Agile em uma equipe como um experimento e, em seguida, usar uma abordagem blob na qual você engole equipes adicionais ao longo do tempo. Se tudo correr bem, continue a engolir equipes adicionais. Se isso não acontecer, aborte o experimento.

O FAST deve resultar em menos reorganizações

A mudança acontece nas organizações. As prioridades mudam, as pessoas saem, as áreas do produto têm um crescimento inesperado. As decisões técnicas anteriores o incomodam e você precisa fazer um trabalho adicional. Surgem novas oportunidades que exigem investimento.

Todas essas coisas têm um impacto na estrutura da sua organização. Você tem um conjunto de equipes, cada uma com suas próprias áreas de propriedade. À medida que essa mudança acontece, você refatora sua organização ao longo do tempo para ter o melhor desempenho possível. Essas refatorações são “reorganizações” e, em organizações em crescimento, elas podem acontecer com frequência!

As reorganizações devem ser muito menos frequentes com o FAST. A unidade de reorganização é tão grande que você não deveria ter que fazer isso com tanta frequência.

Uma possível desvantagem disso é que você não tem equipes com áreas de responsabilidade definidas. Então você pode ter uma difusão de responsabilidade e ter um código comum mal mantido. (Falaremos sobre isso um pouco mais tarde)

O FAST torna mais fácil responder às mudanças de prioridades

Quando as prioridades mudam em equipes estruturadas convencionalmente, você tem equipes configuradas para fazer o trabalho. Se essa estrutura de equipe não suportar as novas prioridades, você terá que refatorar sua organização.

Para o FAST, as mudanças de prioridade são mais fluidas e contínuas. Desde que as responsabilidades sejam do Coletivo, as equipas apenas se organizam em torno do trabalho, e é como se fosse outro dia.

A estrutura da reunião Coletiva também torna a mudança de prioridades menos dramática. Você basicamente tem um All Hands embutido duas vezes por semana. Nas reuniões coletivas, você pode comunicar continuamente o contexto e educar sua equipe sobre seus clientes e mercado. Isso deve ajudar a manter sua equipe melhor alinhada.

Quando comparo essa abordagem com algo como OKRs trimestrais, parece mais fluido e faria um trabalho melhor de alinhar as pessoas. Requer um esforço comprometido do líder do produto para compartilhar continuamente o contexto e as prioridades. Mas algumas das melhores equipes das quais fiz parte tinham um líder de produto agindo dessa maneira, então suspeito que seja um tempo bem gasto.

FAST poderia ser melhor para motivação intrínseca e retenção

Muitas equipes podem sentir que seus processos são projetados como ferramentas para controlar as pessoas. E pode ser como trabalhar em uma linha de montagem.

O FAST adota a auto-organização como um componente fundamental de seu projeto. É tão fundamental que não funcionará sem auto-organização. Ele requer um kit de ferramentas completamente diferente para gerenciamento e é principalmente (embora não completamente) incompatível com abordagens hierárquicas de cima para baixo.

Daniel Pink destacou três aspectos da motivação intrínseca :

• Autonomia – Um desejo de ser autodirigido, o que aumenta o engajamento sobre a conformidade.
• Maestria – O desejo de se tornar mais habilidoso.
• Propósito – O desejo de fazer algo que tenha significado e seja importante. As empresas que se concentram apenas nos lucros sem valorizar o propósito acabarão com um atendimento ao cliente ruim e funcionários insatisfeitos.

Com o FAST, você pode autodirigir seu trabalho, o que o ajuda a sentir autonomia. Você pode optar por se concentrar no trabalho que melhora suas habilidades, alcançando uma sensação de domínio. E você é constantemente lembrado de como seu trabalho está conectado ao que é importante para o negócio, ajudando você a ter um senso de propósito. Portanto, embora não seja garantido, vejo um potencial para as organizações que implementam o FAST observarem altas taxas de retenção.

A auto-organização também fornece alguns sinais úteis que podem manter uma comunidade de pessoas trabalhando melhor juntas. O tipo de pessoa “gerente idiota” recebe um sinal de que seu comportamento não é bem-vindo. Como? Eles avançam para liderar uma equipe e dizem o trabalho que desejam fazer. Se ninguém entra na equipe, o trabalho não acontece e a equipe não se forma (as equipes têm no mínimo duas ou três pessoas, ou não acontecem).

A auto-organização também permite que as pessoas lidem com aspectos dolorosos do trabalho que podem não receber atenção em outras empresas. Por exemplo, se o conjunto de testes for péssimo, alguém pode se apresentar para liderar uma equipe que corrige esse problema. É perfeitamente razoável fazer um trabalho que não seja explicitamente uma prioridade comercial. Mas está em aberto e outros precisam se juntar para que isso aconteça. Isso pode ajudar a evitar a sensação de estar em uma fábrica de recursos .

Finalmente, você pode escolher as pessoas com quem trabalha todos os dias. Quando vi equipes auto-organizadas no passado, este foi um benefício inesperado: as pessoas escolheram trabalhar com pessoas com quem gostariam de trabalhar. E essas equipes eram muito mais fortes do que eu esperava.

O que tudo isso seria contrabalançado é qualquer nova dor que as pessoas experimentariam com o FAST. Um desafio pode ser a dinâmica de poder informal ou a política potencial.

Muitos ambientes são incompatíveis com o FAST

Como o FAST é tão novo, é mais arriscado implementá-lo. FAST não fará sentido em todas as situações. E há mais incógnitas. É melhor pensar nisso como uma abordagem experimental.

Quais ambientes são mais propícios para experimentar o FAST? E onde você deve evitar FAST?

Quanto mais qualidades desta lista sua empresa tiver, melhor será a adequação ao FAST:

• Interesse em inovação e experimentação em gestão.
• Ambientes de alta confiança e baixo medo. Ou pelo menos um desejo de evitar comando e controle na liderança.
• Um bom guia ou facilitador do processo. Alguém que pode conduzir uma reunião Coletiva eficaz, configurar o processo, avaliar e gerenciá-lo ativamente. Alguém que entende a dinâmica organizacional e como os humanos em grupos trabalham juntos. (Você poderia me contratar para isso).
• Uma taxa média a alta de mudança nas prioridades. O FAST é menos útil se as prioridades não estiverem mudando.
• Uma equipe colaborativa, autodirigida, de alto desempenho e que aprende continuamente.
• Uma equipe de liderança que pode descobrir suas prioridades.
• Você tem um líder de produto que pode falar sobre as prioridades e o contexto do negócio em cada reunião do Coletivo. E eles podem se comunicar de forma eficaz.

Quanto menos essas características forem verdadeiras, mais ventos contrários você enfrentará com o FAST. Eu não acho que você precisa estar em um ambiente perfeito para isso. De certa forma, acho que querer ser essas coisas é mais importante do que realmente ser essas coisas. Portanto, talvez o fator de sucesso mais importante seja que a liderança esteja envolvida em criar espaço para isso.

Você pode ter que gerenciar o autogerenciamento

Os sistemas auto-organizados podem funcionar de forma eficaz. Mas eles não são gratuitos. Eles são mais como gerenciar uma comunidade.

Você precisará criar restrições e meios para incentivar o comportamento correto. E você precisará observar cuidadosamente e controlar para garantir que as coisas não saiam dos trilhos.

Qualquer organização pode ter maus atores ou pessoas que não estão alinhadas com os interesses daquela comunidade. Lembro-me de uma vez ter conversado com um engenheiro que me disse (não estou brincando) que não achava que tinha a obrigação de produzir valor para seu empregador. Alguns engenheiros podem querer se concentrar em coisas que desenvolvem suas habilidades ou torná-los um funcionário mais valioso, em vez de coisas que são boas para a empresa que os emprega.

Com FAST, você está se inscrevendo para gerenciar uma comunidade de pessoas.

Em situações convencionais, a hierarquia deixa claro quem é o responsável por isso. No FAST, eu suspeito que seria fácil tentar evitar conflitos e “deixar os membros descobrirem”. Isso pode resultar em redes informais de poder dominando em uma espécie de tirania de falta de estrutura . Se você usar o FAST, isso é algo contra o qual eu me protegeria.

O outro extremo seria não permitir que o grupo resolvesse os problemas e fazer com que a gerência cuidasse disso completamente. Isso também pode ser prejudicial.

Portanto, o FAST exigirá boa facilitação, observação cuidadosa e intervenção ocasional.

RÁPIDO requer muito trabalho

O maior motivo pelo qual você pode não querer experimentar o FAST é que há muito trabalho oculto com o FAST. Requer muitas mudanças em sua organização, para uma maneira desconhecida de operar.

Você pode comparar o FAST a trabalhar em uma nova linguagem de programação de computador. A nova linguagem parece promissora porque tem tantos novos recursos ergonômicos que parece muito melhor do que qualquer coisa que você já viu antes. Mas você não tem estruturas e bibliotecas escritas nessa nova linguagem. Então você terá que construir muito disso sozinho.

Portanto, a maior desvantagem do FAST é que não é uma prática bem estabelecida. Você precisará inventar muitas coisas para lidar com as incompatibilidades entre a forma como o FAST opera e as práticas convencionais. aqui estão alguns exemplos:

Como funciona a gestão de desempenho?

Nas equipes convencionais, você tem um gerente que supervisiona o trabalho e treina os indivíduos. Você tem avaliações de desempenho e, se alguém não se encaixa bem, o gerente pode intervir. Embora existam problemas com as avaliações de desempenho, a maioria das pessoas entende como elas funcionam e servem a um propósito na organização.

Em equipes FAST, não há realmente uma maneira óbvia de fazer análises de desempenho. O gerente da pessoa sabe o que está fazendo ou como está trabalhando? Não dá nem para avaliar “times”, porque são transitórios.

Portanto, toda a noção de gerenciamento de desempenho precisa ser reinventada. Embora isso possa ser uma boa ideia de qualquer maneira, é algo que exigirá reflexão e invenção.

Qual é o papel dos gerentes de engenharia no FAST?

Existem várias maneiras de estruturar uma função de gerente de engenharia. Eu geralmente recomendo ter o gerente de engenharia como responsável pelo gerenciamento do projeto , pois isso faz com que eles trabalhem lado a lado com sua equipe, sem colocá-los em uma área onde o diferencial de energia cause problemas. Existem muitas maneiras válidas de definir a função de gerente de engenharia, mas essa é uma que eu costumo usar.

No FAST, a função do gerente de engenharia é menos clara. Você não tem equipes duradouras, então é mais difícil para o gerente de engenharia trabalhar lado a lado com seus subordinados diretos.

Você poderia ter gerentes de engenharia liderando as equipes auto-montadas. Ou você pode fazer com que sejam gerentes de pessoas puros. Ou você pode tê-los como jogadores-treinadores.

Tudo isso tem compensações e algumas desvantagens bastante grandes. FAST parece diminuir a necessidade de tanto gerenciamento de engenharia. Você ainda precisa de pessoas para contratar, fazer gerenciamento de desempenho e supervisionar o processo. Mas talvez não tanto quanto em uma organização convencional?

Já vi muitas organizações sofrerem porque não valorizam o gerenciamento como uma disciplina. Mas eu acho que as organizações FAST precisam de menos gerenciamento.

Estou muito curioso para ver se isso acontece e quero ouvir as organizações que experimentam o FAST. O que você faz com a gestão?

Como você garantirá a qualidade do código sem áreas de propriedade?

A propriedade do código fornece incentivos naturais para manter a qualidade do código alta. É do seu interesse, porque seu futuro eu tem que trabalhar em seu código atual.

Em uma situação de propriedade de código compartilhado, você precisa ir além para garantir a qualidade do código. Minha recomendação seria emparelhar ou mobbing como uma prática obrigatória.

Você também precisará de padrões mais fortes para padrões de código. Você precisará de linting de código. E você precisará de algum tipo de tomada de decisão arquitetônica. Você não quer ter vinte padrões de como seu código de front-end lida com o estado. Esses são problemas que você terá na maioria das organizações de software, mas serão muito mais urgentes em uma organização que usa o FAST.

Uma coisa em que muitas organizações não investem é em treinamento e comunicação sobre padrões eficazes de design de software. E conversas para garantir que todos estejam alinhados sobre quais abordagens usar e quando. Estes são provavelmente ainda mais importantes em uma organização FAST.

A propriedade de código compartilhado é uma prática que tem alguns precedentes. Valeria a pena gastar tempo para descobrir como ter sucesso com ele se você continuar com o FAST.

O que acontece com múltiplos Coletivos e cruzando os limites Coletivos?

O trabalho que cruza os limites coletivos é essencialmente indefinido no FAST. E grandes iniciativas que exigem altos graus de coordenação também são subespecificadas pelo FAST. Então você teria que inventar soluções para essas situações.

Qualquer organização grande o suficiente para ter vários Coletivos usando o FAST executará projetos entre Coletivos. Os padrões para lidar com essas coisas serão semelhantes ou análogos a como você resolve isso em uma escala menor. Mas este é um território amplamente desconhecido, até onde eu sei. Portanto, você precisará usar alguns modelos de coordenação para resolver esses problemas quando eles surgirem. Será um ato de invenção.

Como a FAST lida com os plantões?

O plantão não é especificamente mencionado no guia FAST . Portanto, você precisará inventar um esquema para lidar com isso.

Em equipes convencionais, o conselho padrão para plantões é que cada equipe seja responsável por suas próprias operações. E ter todos na equipe de plantão. Isso significa que você deve ter equipes de pelo menos quatro pessoas para que o fardo não seja tão ruim. O pensamento é que ter equipes de plantão para seu produto de trabalho os incentiva a aumentar a confiabilidade. Isso os ajuda a garantir que tenham um cronograma de plantão decente.

Com o FAST, você pode criar uma rotação de plantão com níveis (siga este runbook e encaminhe se isso não resolver). E você precisará manter explicitamente um mapa de quem é capaz de apoiar o quê. Isso não será mapeado para suas equipes.

Isso não é muito difícil de fazer, mas é menos comum do que as práticas convencionais de plantão e exigirá atenção da gerência.

Que tal corrigir bugs e escalações de suporte?

O FAST tem uma função opcional chamada “Feature Steward”. Eles são uma espécie de especialistas em um determinado recurso e são o ponto de contato em torno desse recurso para as partes interessadas. Eles não são obrigados a trabalhar continuamente nesse recurso, mas precisam ter um entendimento contínuo dele.

Como no plantão, você precisará de um mapeamento de recursos para pessoas com experiência nesses recursos. Isso será importante para bugs e escalonamentos de suporte. E você também pode combiná-lo com o plantão. Você precisará de alguma maneira de triar os problemas para as pessoas certas.

Você também precisará certificar-se de ter um mecanismo para preencher as lacunas de conhecimento quando a experiência for isolada para uma ou duas pessoas.

Uma coisa que você terá que decidir é sua política para corrigir bugs. Você quer que eles sejam sempre corrigidos, retardando o trabalho de outros recursos? Os bugs são corrigidos pela pessoa que os introduziu ou você quer algum outro esquema? E como você determinará quem é responsável pela triagem de bugs? Provavelmente uma rotação de algum tipo?

Escalações de suporte também exigirão algum esforço. O ponto de contato é o Feature Steward de uma área. Mas e se o Feature Steward estiver de férias? Você provavelmente quer mais de uma pessoa com conhecimento sobre cada área. E se a questão do suporte acabar exigindo trabalho? Você apenas faz o trabalho ou o alimenta nas prioridades centrais?

Nenhum desses são problemas difíceis de resolver, mas são trabalhos de gerenciamento. E tudo o que você fizer terá compensações de foco versus capacidade de resposta.

E os incidentes de confiabilidade e retrospectivas de incidentes?

O FAST não define como os incidentes são tratados. Seus padrões de plantão determinarão em grande parte como os incidentes são tratados e provavelmente envolverão quem sabe como consertar a situação sendo puxado para consertá-la.

O FAST não descreve como lidar com retrospectivas de incidentes. Eu recomendaria fazer algo como o seguinte: agende uma retrospectiva de incidente para acontecer antes da próxima reunião coletiva. Um dos objetivos da retrospectiva seria identificar alguns trabalhos que poderiam ser feitos para reduzir a probabilidade ou a gravidade do que quer que tenha causado o incidente. Outra seria aprender tudo o que puder com o incidente.

Na reunião do Coletivo imediatamente após o incidente, eu compartilharia o que aprendemos e também tornaria uma prioridade automática para o próximo ciclo fazer parte do trabalho identificado na retrospectiva.

Na New Relic, não usamos o FAST, mas tínhamos uma política semelhante. Chamamos isso de “Não Repetir Incidentes” (DRI). Foi uma das melhores coisas que já fizemos para confiabilidade. A regra era que o trabalho DRI era automaticamente mais importante do que outras prioridades. Assim, um incidente sempre resultou em menos escopo ou em um prazo adiado.

Como os designers trabalham no FAST?

Um desafio que muitos projetistas têm é se concentrar em trabalhar com a equipe de engenharia ou fazer o trabalho à frente da equipe de engenharia. Ou faça com que operem nos dois sentidos. Você ouvirá fortes argumentos para ambas as formas de trabalho.

FAST não especifica como isso deve funcionar, então você terá que decidir por si mesmo. Os designers se inscrevem nas equipes para trabalhar? Ou eles são uma organização de serviços, que trabalham com antecedência e atuam como consultores quando as pessoas precisam de algo deles? Você precisará decidir. Eu provavelmente faria com que os designers se inscrevessem e fizessem parte das equipes, mas, novamente, este é um exemplo do tipo de decisão que você precisará tomar ao adotar o FAST.

Como os gerentes de produto trabalham no FAST?

A função do produto no FAST é principalmente priorizar e comunicar as prioridades. Há muito que não está realmente descrito no manual do FAST sobre o trabalho fora disso.

A suposição no manual do FAST parece ser que os gerentes de produto inspiram e comunicam, e então os engenheiros trabalham nos recursos.

Na medida do possível, eu faria com que os engenheiros conversassem com os clientes e fizessem com que ganhassem experiência na área de produto em que estão trabalhando. Idealmente, eles estariam fazendo o trabalho, demonstrando-o aos clientes e obtendo feedback deles. . Fazer com que os gerentes de produto facilitem isso e aumentar a capacidade dos engenheiros de fazer isso com eficiência pode ser uma parte valiosa de seu trabalho.

Há muita flexibilidade neste modelo. Você pode fazer a transferência típica do produto para a engenharia ou pode fazer com que eles descubram e resolvam o problema do espaço juntos, com os clientes.

Como você pode ver, há muitas lacunas no FAST. Você precisará resolver o resto.

Os materiais do FAST estão cheios de jargões

Você pode achar o site FAST e o manual confusos. Você terá que lidar com muitos jargões e terminologia irritante para chegar ao ouro do FAST Agile. Como exemplo, aqui está a terrível definição de FAST Agile que tenta definir a prática na versão 2.12 do FAST Guide :

“O que é tecnologia de dimensionamento de fluidos? A Fluid Scaling Technology combina Open Space Technology e Open Allocation para criar um método leve, simples de entender e simples de dominar para organizar as pessoas em torno do trabalho - que é dimensionável. FAST é a sigla para Fluid Scaling Technology. A tecnologia Fluid Scaling para Agile é FAST Agile.”

Então. Ruim. E isso é muito representativo. Você verá muitas referências a Coletivos, Ciclos de Valor, Tecnologia Aberta, transformação Teal, Teoria Y, etc. Tudo isso é apresentado sem nenhuma explicação e, mesmo que fosse explicado, não seria útil. Eles estão falando para um público de nicho de teóricos ágeis e focando na atribuição em vez da utilidade.

Conclusão

Então, onde isso nos deixa? Vale a pena experimentar o FAST ágil?

Acredito que a resposta seja sim, mas com cautela e nos contextos certos. Você pode brincar com isso dentro de equipes individuais. E se você tiver apoio de liderança, experimente-o gradualmente em organizações maiores.

Por favor, compartilhe comigo se você experimentar. E se você precisar de ajuda para implementá-lo em sua organização, entre em contato comigo. Vou ajudá-lo diretamente ou conectá-lo com outras pessoas que podem ajudar.

Obrigado

As primeiras versões deste post eram... muito ruins. Gostaria de agradecer a Seth Falcon e Davy Stevenson por suas críticas. Ambos apontaram alguns problemas importantes com o post que me fizeram recuar e repensar minha abordagem. E eles fizeram alguns pontos excelentes que incorporei em suas próprias seções do post. Por fim, reescrevi a maior parte do post e fiquei muito mais feliz com o resultado. Obrigado! Seth tem um boletim informativo sobre liderança em engenharia que vale a pena conferir, e Davy (como eu) faz consultoria e treinamento para startups .

Jim Shore me apresentou ao FAST ágil. Ele tem algumas palestras excelentes sobre suas experiências com ele. E nos encontramos algumas vezes e discutimos as implicações e a implementação do FAST. Jim é o autor de The Art of Agile Development .

Imagem de Kanenori do Pixabay

notas de rodapé

1. Acredito que 150 pessoas provavelmente é difícil para um Coletivo. Suspeito que sessenta pessoas seja um tamanho máximo melhor.