…As coisas estão funcionando bem, pois todos fazem o que precisa ser feito por pura paixão, de forma tão perfeita que um observador pode concluir que todos têm a capacidade de ler a mente uns dos outros. Contudo, à medida que a organização e o produto crescem, cresce também a quantidade de informação que as equipas têm de dominar, gerir e partilhar para que o seu trabalho seja feito. As decisões estão se tornando mais sensíveis ao contexto (tanto das equipes quanto dos produtos), com uma complexidade que implora algum tipo de estrutura para manter as coisas funcionando bem à medida que a organização amadurece. Você está buscando uma estrutura organizacional que otimize a capacidade da equipe de fazer as coisas para criar o Maior Valor.

✥ ✥ ✥

A comunicação e o feedback efetivos estão no centro do desenvolvimento eficaz de sistemas complexos, e a estrutura da organização deve ser otimizada para os caminhos mais cruciais da comunicação. Comunicação e feedback regular, juntamente com a auto-organização, são o coração ágil. A interação de pessoas com preocupações diversas e transversais está no coração da inovação ().

Equipes de desenvolvimento que trabalham com produtos complexos lutam continuamente com a natureza dual da função e da forma. Tendemos a criar fronteiras entre as actividades de desenvolvimento e as unidades organizacionais ao longo destas linhas. No entanto, função e forma são apenas categorias socialmente construídas e um tanto arbitrárias: a confiabilidade pode ser igualmente atraente para um determinado sistema, enquanto a beleza, a compatibilidade retroativa, ou alguma outra preocupação pode dominar um determinado esforço de desenvolvimento. Em cada caso, o negócio será melhor atendido se a Equipe de Desenvolvimento se organizar em torno das preocupações mais cruciais do negócio – sejam elas quais forem.

Como sua equipe apenas começa a amadurecer em seus primeiros dias e começa a se mover para a construção de uma Equipe Scrum, você tem mais pessoas que podem trabalhar convenientemente como uma unidade organizacional para cobrir todas as funções de um negócio (planejamento de lançamento, desenvolvimento e crescimento profissional). Mas o crescimento e a maturidade também causam desconforto, pois as equipes anseiam pela eficácia não-estruturada dos dias simples de trabalho informal. No entanto, crescer e gerir adequadamente o produto no mercado requer uma estrutura organizacional algo disciplinada e alguma governança leve.

Culturas têm uma necessidade intrínseca de estrutura para o funcionamento eficiente do todo. A comunicação mais eficaz acontece sempre localmente dentro do domínio do familiar, por isso é crucial localizar o processo de tomada de decisão em torno das preocupações organizacionais mais cruciais. É importante em qualquer organização social não trivial que as pessoas sejam rapidamente capazes de associar qualquer domínio de interesse com o “lugar para ir” mais eficiente quando precisam de informações sobre essa área ou precisam tomar medidas nessa área.

Uma simples partição organizacional (ou seja, uma hierarquia) é suficiente em domínios simples que devem lidar com apenas um conjunto de preocupações separáveis. Mas a abordagem hierárquica se decompõe no caso mais típico de esforços de desenvolvimento com múltiplas preocupações sobrepostas. Isto empurra para unidades organizacionais maiores e mais complexas que tentam corrigir o problema com economias de escopo. No entanto, as equipes de trabalho mais eficazes são Pequenas Equipes, e você precisa dividir o trabalho de alguma forma.

No entanto, nenhuma equipe é uma ilha, e uma nação de desenvolvimento é mais do que um conjunto de ilhas. As equipas desenvolvem individualmente a sua própria identidade, onde um sentido natural de xenofobia (necessidade do familiar) faz com que as equipas dêem apenas uma estatura secundária às preocupações vindas de fora do seu círculo social. Se você limitar o empreendimento a um conjunto de interações sociais, com base em uma única partição simples, você encerra as idéias fora dos limites que alimentam a inovação.

A velocidade da tomada de decisão é primordial. Algumas questões são urgentes (“Estamos sendo atacados por outra tribo e devemos montar uma defesa contra eles”), enquanto outras, embora importantes, toleram ou mesmo imploram uma deliberação mais longa (“Qual é o melhor local para o novo salão de reuniões?”). O termo camadas de tosquia descreve processos relacionados que se movem em velocidades diferentes, após a noção de placas tectônicas que se movem umas sobre as outras, como por exemplo, levar a um terremoto. Tanto arquitetos de edifícios () como o campo da arquitetura de software (ver ) adotaram a frase para descrever estruturas ou preocupações com diferentes taxas de mudança em um sistema fortemente acoplado. Uma empresa deve estruturar sua organização para ser capaz de responder rapidamente às questões da primeira categoria sem destruir sua eficácia para as questões da segunda.

Um outro princípio ágil é que estamos enfrentando o exterior: ou seja, nosso foco e preocupação são o usuário final, o mercado e os clientes, e não as ferramentas e tecnologias que usamos para fazer nosso trabalho. A organização deve refletir essa preocupação também, pois é a chave para a proposição de valor e a construção de todo o fluxo de valor do desenvolvimento.

No final, a estrutura da organização deve ter tanto a ver com a estrutura do processo quanto com a estrutura do produto.

Então,

Organizar a força de trabalho em Pequenas Equipes de mais ou menos cinco pessoas, divididas de acordo com as preocupações mais importantes para a criação de valor pela empresa. Complementar esta estrutura com um pequeno número de estruturas transversais para preocupações secundárias mas importantes, nunca esquecendo que estas estruturas são apenas optimizações num ambiente aberto de cooperação sem restrições.

Considerar uma empresa que está a construir um telemóvel. Eles podem organizar suas equipes Scrum em torno dos principais produtos ou opções de compra. Assim, pode haver uma equipe para a agenda, outra para o calendário e outra para a funcionalidade mais tradicional do telefone: veja Área de Valor. Essas são as principais preocupações do negócio. Mas pode haver grupos que se reúnem para definir práticas, políticas e padrões corporativos (por exemplo, a aparência da interface do usuário), incluindo representantes de cada equipe Scrum. Esses grupos não constroem produtos, mas servem como trocas de informações e como fontes de padrões que orientam o desenvolvimento. Em organizações saudáveis existe uma sobreposição quase completa entre os membros destes últimos grupos e os membros da equipe de desenvolvimento.

Na maioria dos ambientes, a estrutura organizativa primária reflete a estrutura dos principais stakeholders, que normalmente é o mercado. Por esta razão, nós não organizamos Scrum Teams ao longo da partição de artefatos internos, nem de acordo com os loci de conhecimento do domínio, mas sim de acordo com os resultados do mercado, tais como recursos. Organizar em torno de recursos ou outros produtos de mercado também é uma vantagem para a resposta ao mercado e reduz o tempo de colocação no mercado, pois a equipe é o local de todo o trabalho necessário para implementar um recurso. Isso mantém a coordenação dentro de um limite organizacional. Se as subassembléias de trabalho ou competências centrais impulsionarem a estrutura organizacional, então mudanças no mercado ou na natureza do produto provavelmente implicarão em coordenação entre várias equipes ou organizações – reduzindo a capacidade de resposta e aumentando o tempo de tomada de decisão.

Se esta for a única estrutura, ela suporta apenas a visão do mercado e marginaliza uma série de outras preocupações comerciais válidas. Para que essa estrutura funcione, ela deve ser complementada por estruturas transversais que suportem um segundo nível de eficiência de comunicação, por exemplo, aquelas relacionadas às competências essenciais. Assim, este padrão aparece quase sempre em conjunto com um padrão como Birds of a Feather e o padrão descrito em Domain Expertise in Roles. A estrutura organizacional de papéis corta as paredes que naturalmente se formam entre as equipes. Envolva os esforços do produto dentro de uma empresa para se conectar entre si e com a gestão executiva através do MetaScrum. Equipas que tenham desenvolvido um grau de orgulho da equipa (ver Orgulho da Equipa) serão mais eficazes, uma vez que esta ou outra força equivalente irá encorajar a responsabilidade. Isto ajuda a garantir que estas estruturas permaneçam em jogo, apesar dos efeitos xenófobos da adesão à equipa.

Agregar tudo isto num ambiente aberto, sem paredes e sem portas. Equipes de desenvolvimento são unidades apenas de compromisso de desenvolvimento, e não deve haver interferência limitando o livre interfuncionamento entre os desenvolvedores entre as equipes. Adicione pequenas salas próximas por curtos períodos de silêncio, reflexão séria e pequenas reuniões.

Ainda componente de valor é um jogo justo como critério de organização. Por exemplo, o Scrum valoriza muito a colocação dos membros da equipe, portanto os limites organizacionais mais básicos provavelmente corresponderão às Equipes Colocadas.

✥ ✥ ✥

Note que existem dois níveis da Lei de Conway em um bom Scrum: um motivado por um foco no produto, e outro motivado por um foco nas áreas de competência. No nível da superfície organizamos a equipe de acordo com o processo; essa é a principal preocupação tanto para os aspectos internos como externos do processo. Assim, as três esferas de domínio do processo são:

• a Equipe de Desenvolvimento que detém as decisões sobre o uso adequado da tecnologia e técnica na construção do produto;
• o Proprietário do Produto, que detém a definição e direção do produto; e,
• o ScrumMaster que é responsável por que o processo apoie a entrega regular da Equipe de Desenvolvimento.

As Equipes de Desenvolvimento de Crum são equipes de características (produto). Ou seja, o principal princípio organizador de uma equipe Scrum é que ela se alinha com um trem de entrega de recursos ao longo de um fluxo de valor. Existe uma organização hierárquica fraca e rasa dentro do Scrum que acomoda várias Equipes de Desenvolvimento dentro de cada desenvolvimento de produto, compartilhando um Proprietário de Produto comum, em uma organização chamada Scrum of Scrums. Cada equipe de desenvolvimento dentro de um único produto desenvolve um conjunto de funcionalidades de cada vez. Ao longo do tempo, os principais drivers de negócio, conhecimento de negócio compartilhado e artefatos de Value Stream irão unir essas funcionalidades. Não há títulos ou subdivisões reconhecidas dentro da Equipe de Desenvolvimento.

Existem muitas maneiras de dividir o trabalho em equipes de recursos. Uma Equipe de Desenvolvimento pode entregar recursos para um determinado mercado (veja Organização Segue o Mercado), ou desenvolver produto para algum subconjunto do espectro tecnológico da empresa (uma equipe para telefones e outra para tablets, embora ambas compartilhem muito do mesmo software). Em geral, cada equipe deve ser formada em torno de algum produto que represente um componente do valor da empresa: veja também Value Stream Fork. Entretanto, Scrum desencoraja uma estrutura de Equipe de Desenvolvimento onde cada equipe possua uma parte do produto, ou apenas um subconjunto do produto. Se os membros de qualquer equipe podem desenvolver apenas uma parte do sistema, então eles precisarão coordenar mais decisões de desenvolvimento com outras equipes. Torna-se difícil para as equipes tomarem decisões localmente, e os resultados incluem retroalimentação e handoffs.

No segundo nível da Lei Conway dentro do Scrum, as pessoas se organizam em torno de áreas de competência nas quais a proficiência impulsiona o valor. Estas Aves de uma Pena ajudam os membros a aprofundar as suas instalações em alguma área profissional ou técnica à medida que partilham ideias ou recebem formação. A maioria das pessoas tem um desejo inato de melhorar (ver ), e estes grupos alimentam o orgulho individual à medida que os membros da equipe aprendem e crescem. Mas, mais uma vez, estes grupos não formam uma estrutura de relatórios, e qualquer membro da equipe pode pertencer a várias Aves de uma Pena, bem como à sua própria equipe Scrum. Veja também Domain Expertise in Roles.

Development Team boundaries, and identity, as well as Scrum Team boundaries and identity, are explicit. A noção de identidade da equipe é fundamental para o Orgulho da Equipe e para o funcionamento eficiente da organização, já que a identidade da equipe traz o contexto social que ajuda a otimizar a tomada de decisões. Qualquer noção de identidade organizacional além dessas duas deve ser tácita, e não explícita ou administrada. Novamente, não há títulos formais dentro da Equipe de Desenvolvimento que não sejam “Desenvolvedor”. Se existe apenas uma regra inviolável, é que nenhum indivíduo pode usar seu posto tácito de especialização para anular um consenso de equipe ou de qualquer outra forma diminuir um espírito de trabalho em equipe, como em O Espírito do Jogo. Uma norma de conduta desenvolvida em conjunto é um forte prenúncio da identidade da equipe.

Existe experiência em funções a nível individual, mas é importante completar este padrão com Equipes Intersfuncionais sempre que possível para otimizar a possibilidade de tomada de decisões locais.

A Lei original da Conway saiu do software (ver , pp. 28-31). Há muitos mitos associados à origem e à prática do Direito da Conway. Durante muito tempo foi sustentado que a orientação a objetos apoiava a Lei da Conway ao localizar as preocupações do mercado dentro das classes. Isso é meia verdade; as classes tendem a encapsular as preocupações de longo prazo do núcleo de competência organizacional. No entanto, a orientação a objetos parece focar na conexão entre a experiência dos desenvolvedores e os artefatos que eles desenvolvem e não em qualquer conexão com o mercado ou casos de uso. As preocupações com o alinhamento com a estrutura de mercado devem prevalecer sobre as preocupações dos desenvolvedores com a visão de mundo de seus processos e produtos.

O estilo de desenvolvimento em cascata teve seu apogeu. Nas organizações em cascata, a estrutura organizacional primária seguiu etapas de processo: análise de requisitos, projeto, implementação e teste (, pp. 1-9). Segundo a Lei Conway, a estrutura organizacional refletia essas preocupações do processo. O software pode muito bem refletir essas fases também: por exemplo, uma Arquitetura Orientada a Serviços (SOA) irá evidenciar a maioria dos requisitos de valor agregado na camada de integração de serviços, enquanto os serviços individuais são encontrados em outra camada. Waterfall coloca todos os recursos nas mãos dos desenvolvedores de uma só vez, o que suporta o raciocínio sobre as interações entre os recursos. Enquanto as abordagens de design de software da era da cascata tentavam alinhar as preocupações do mercado (casos de uso) com a arquitetura, a estrutura organizacional atravessava essa taxonomia. O mesmo pode ser dito sobre a organização da linha de montagem nas fábricas.

Porque as equipes de desenvolvimento são equipes de recursos, elas devem se concentrar em um recurso de cada vez (como em Swarming). O mercado primário de Scrum é uma funcionalidade, e neste sentido, há um bom alinhamento entre a estrutura da equipe e o mercado. Scrum é silencioso sobre a forma da arquitetura do produto, mas no espírito de ágil tende a desencorajar a propriedade individual do código. Toda equipe de desenvolvimento tem licença para trabalhar em qualquer parte do produto. Podemos dizer que Scrum equilibra os benefícios organizacionais do encapsulamento com os benefícios de alinhar a equipe com o mercado entregável. O Proprietário do Produto, com suporte da Equipe de Desenvolvimento, gerencia como lidar com interações de recursos que surgem ao longo do tempo.

Considerando, por exemplo, que uma equipe pode implementar o recurso Call Waiting para um sistema de telecomunicações enquanto outra implementa o Call Forwarding. Devido à emergência, nem sempre é possível prever o custo da resolução de dependências entre dois determinados Itens de Backlog de Produto (PBIs), pelo que é, em geral, impossível ultrapassar este problema através da atribuição de PBIs a equipas. Em qualquer caso, a atribuição prematura de trabalho às equipas pode impossibilitar que as pessoas trabalhem eficazmente nas partes difíceis (especialmente aquelas relacionadas com a interacção entre as partes) e limitar a auto-organização ao nível da Equipa Scrum. As duas características podem ser altamente interdependentes, mas a estrutura Scrum não dá uma estatura de primeira classe a essas interações. Neste caso, provavelmente seria melhor se uma única equipe desenvolvesse ambas as características. Como alocar trabalho às equipes se baseia no planejamento contínuo e na tomada de decisão compartilhada, começando com o planejamento Sprint. Uma boa equipe Scrum se esforça para dividir o trabalho entre as equipes de desenvolvimento através de interações íntimas, mas com tempo limitado, entre o proprietário do produto e a equipe de desenvolvimento, como em eventos para restabelecer continuamente um Backlog Refinado de Produtos, bem como através do Planejamento Sprint.

Gestão é normalmente um componente do mix organizacional, embora existam alguns desenvolvimentos Scrum que rodam sem nenhum gerente (por exemplo, veja o vídeo recente sobre a transformação ágil na Bosch Software Innovations. ) O ethos Scrum tende a focar nas pessoas e no produto, e o foco é corporificado nos papéis Scrum e nas organizações (como a Equipe de Desenvolvimento e a Equipe do Proprietário do Produto) que eles representam. Se uma organização com gestores pré-existentes se propõe a introduzir Scrum, é muito fácil para o esforço Scrum descartar a parte de gestão da organização como de outro mundo. Em tais situações onde uma organização sem gerenciamento não é uma opção, é crucial envolver os gerentes.

Steven Johnson. De onde vêm as boas ideias. De Nova Iorque: Riverhead Trade, 2011.

Marca Stewart. Como os Edifícios Aprendem: O que acontece depois de serem construídos. Nova York: Penguin, 1995.

Brian Foote e Joseph Yoder. “Big Ball of Mud.ˮ Em Pattern Languages of Program Design 4, Brian Foote et al., eds. Londres: Pearson, 2000.

Daniel Pink. Drive: A incrível verdade sobre o que nos motiva. Nova York: Riverhead Books, 2011.

Melvin E. Conway. “How do committees invent?ˮ In Datamation 14(4), April, 1968, pp. 28-31.

Dr. Winston W. Royce. “Managing the Development of Large Software Systems.ˮ Em Proceedings IEEE WESCON, agosto de 1970, pp. 1-9. (Originalmente publicado por TRW.)

Bosch Software Innovations. “Lições aprendidas: Agile organization at Bosch Software Innovations.ˮ YouTube.com, 15 de Junho de 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Créditos de fotografia: Imagens fornecidas por PresenterMedia.com.