Como a Scrum Team, o Product Owner, o Scrum Master e os Developers trabalham como uma única unidade coesa, autogerenciável, focada em um Product Goal e responsável pela criação de valor
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender a estrutura da , as três responsabilidades do , a ausência de hierarquias internas e subequipes definidas pelo , a responsabilidade coletiva pela criação de valor, o tamanho recomendado da equipe e por que um único oferece uma direção coerente ao time.
Introdução: o substitui silos internos por uma única equipe coesa
O não organiza as pessoas em torno de uma cadeia de comando. Ele organiza um pequeno grupo de profissionais em torno de um produto, de um objetivo compartilhado e de responsabilidades explícitas.
Organizações tradicionais frequentemente dividem o trabalho de produto entre departamentos especializados. Analistas de negócios definem requisitos, arquitetos projetam soluções, implementam, testadores validam, a equipe de operações realiza implantações, gerentes coordenam as passagens de responsabilidade e líderes de projeto acompanham o progresso entre os grupos. Essa estrutura pode criar grande especialização, mas também pode gerar filas, otimizações locais, feedback lento e uma pergunta recorrente: quem é responsável pelo resultado do produto como um todo?
O responde a essa questão tornando a a unidade fundamental do framework. O time contém um , um e . Eles não são três departamentos dentro de uma organização de projeto em miniatura. São três responsabilidades distintas dentro de uma única equipe coesa. O Scrum Guide descreve explicitamente a como uma equipe sem subequipes e sem hierarquias internas definidas pelo .
Esse desenho é mais importante do que parece à primeira vista. Um não consegue maximizar o valor de maneira eficaz se as decisões de produto estiverem desconectadas das pessoas que criam o . Os não conseguem se adaptar de forma inteligente se receberem instruções imutáveis por meio de uma cadeia de intermediários. Um não consegue melhorar a eficácia se for tratado apenas como administrador de reuniões, sem acesso ao sistema organizacional. O aproxima essas perspectivas para que decisões de produto, processo e entrega sejam orientadas por conhecimento real.
O Scrum Guide de 2020 reforçou essa ideia ao abandonar o conceito anterior de um “” separado dentro da . O modelo atual descreve uma única com três responsabilidades: , e . Isso reduz a separação mental entre “o lado do negócio” e “o lado da entrega” e enfatiza a responsabilidade coletiva pelos resultados do produto.
Para quem se prepara para a , compreender essa estrutura é essencial. Muitas respostas incorretas se baseiam em hábitos organizacionais familiares: o atuando como chefe dos , o distribuindo tarefas, testadores formando uma subequipe, arquitetos aprovando todas as decisões de design ou gerentes decidindo como o trabalho deve ser realizado. Esses arranjos podem existir em empresas, mas não fazem parte do .
A : a unidade fundamental do
A é um pequeno grupo de pessoas responsável por transformar objetivos e oportunidades de produto em resultados valiosos e utilizáveis. Segundo o Scrum Guide, ela é composta por um , um e . A equipe é e : em conjunto, seus membros possuem as competências necessárias para criar valor a cada e decidem internamente quem faz o quê, quando e como.
não significa que cada indivíduo possua todas as habilidades. Um especialista em banco de dados pode continuar tendo conhecimento mais profundo nessa área. Um designer pode ter competências especializadas em experiência do usuário. Um engenheiro de segurança pode compreender modelagem de ameaças melhor do que os demais membros da equipe. significa que a equipe, como um todo, consegue criar o sem depender estruturalmente de uma cadeia de departamentos externos especializados para cada etapa.
Autogerenciamento também não significa ausência de objetivos, padrões, estratégia ou responsabilidade. O oferece direção. O é responsável por maximizar valor. Os são responsáveis pelo plano e pela qualidade do . O é responsável por estabelecer o e melhorar a eficácia da equipe. Políticas organizacionais, padrões profissionais, requisitos de segurança e a podem estabelecer limites importantes. Dentro desses limites, a equipe gerencia o próprio trabalho.
A é responsável por toda a gama de atividades relacionadas ao produto que possam ser necessárias: colaboração com stakeholders, verificação, manutenção, operação, experimentação, pesquisa, desenvolvimento e muito mais. O não cria um modelo em que os “jogam o software por cima do muro” e então declaram sucesso. A equipe é responsável por criar um valioso e utilizável a cada .
Ponto-chave para a
A não é um mais um supervisionando um grupo de entrega. É uma única equipe coesa e com três responsabilidades diferentes.
O : responsabilidade por maximizar o valor do produto
O é responsável por maximizar o valor do produto resultante do trabalho da . Trata-se de uma responsabilidade de produto, não de uma função de administração de projeto. O precisa tomar continuamente decisões de valor sob incerteza: qual objetivo importa, qual problema vale a pena resolver, o que deve ser feito a seguir, o que deve ser adiado e o que não deve ser construído.
Uma parte essencial dessa responsabilidade é o gerenciamento eficaz do . O desenvolve e comunica explicitamente o , cria e comunica com clareza os itens do , ordena o e garante que ele seja transparente, visível e compreendido. Parte desse trabalho pode ser delegada, mas a responsabilidade continua pertencendo ao .
O é uma pessoa, não um comitê. Essa regra protege a capacidade de decisão e a transparência. Muitos stakeholders podem ter necessidades legítimas, mas o não pode ser ordenado de forma eficaz se cinco executivos puderem alterar prioridades de maneira independente. Stakeholders influenciam o por meio de colaboração, evidências, estratégia e persuasão; eles não ignoram o para gerenciar diretamente o trabalho dos .
Isso não transforma o em um ditador. Maximizar valor exige aprender com , clientes, stakeholders, dados de mercado, restrições técnicas, realidades operacionais e resultados do produto. O possui a responsabilidade pelas decisões de valor, mas boas decisões dependem de colaboração. Em ambientes complexos, autoridade sem feedback rapidamente se transforma em suposição.
Uma confusão frequente na é imaginar que o distribui tarefas aos . O atribui aos a responsabilidade pelo plano da e pela forma como o trabalho é realizado. O traz a perspectiva de produto: objetivos, valor, ordenação e clareza sobre o que importa. Os decidem como transformar os itens selecionados do em um Done.
Comportamento esperado do
Criar uma direção clara de produto, tomar decisões de ordenação, manter o transparente, colaborar com stakeholders e e usar evidências dos resultados para refinar decisões de valor.
Comportamento contrário ao
Tratar o como gestor de tarefas, secretário de requisitos, porta-voz de um comitê sem autoridade de decisão ou alguém que pode ordenar aos como executar o trabalho.
O : responsabilidade pelo e pela eficácia da equipe
O é responsável por estabelecer o conforme definido no Scrum Guide. Isso significa ajudar as pessoas a compreender a teoria e a prática do dentro da e em toda a organização. O também é responsável pela eficácia da , ajudando a equipe a melhorar a forma como trabalha dentro do framework.
Essa responsabilidade costuma ser mal compreendida porque muitas organizações traduzem “” para funções gerenciais familiares. O pode ser tratado como gerente de projeto, organizador de reuniões, coordenador de entregas, secretário da equipe ou pessoa encarregada de fazer todos seguirem um processo. Essas interpretações enfraquecem a função porque deslocam o para o controle, em vez da habilitação.
Um ajuda os membros da equipe a evoluir em autogerenciamento e . Ajuda a a manter o foco em Increments de alto valor que atendam à . Ajuda a causar a e a garantir que os eventos do ocorram e sejam produtivos. Também serve ao e à organização mais ampla por meio de coaching, facilitação, ensino e melhoria das interações com a .
A expressão “causar a ” é importante. Ela não significa que o resolve pessoalmente todos os problemas. Se o se tornar a única pessoa autorizada a contatar outro departamento, atualizar um ambiente, negociar uma dependência ou resolver um conflito, a equipe passará a depender dele. Uma abordagem melhor é aumentar a capacidade do sistema de remover obstáculos, ainda que o aja diretamente quando necessário.
O , portanto, não está acima dos nem do em uma hierarquia. A responsabilidade é diferente, não superior. Um forte pode desafiar o , orientar ou influenciar gestores seniores, mas essa influência vem do serviço, do conhecimento, da facilitação e da liderança, e não de controle posicional dentro do .
Comportamento esperado do
Ensinar e estabelecer o , orientar o autogerenciamento, melhorar a eficácia, facilitar quando útil, tornar impedimentos sistêmicos visíveis e ajudar a organização a criar condições para que a tenha sucesso.
Comportamento contrário ao
Distribuir trabalho, controlar pessoas, ser dono do , coletar relatórios de status para a gestão, transformar todo evento em uma cerimônia ou tornar a equipe dependente do para decisões rotineiras.
: responsabilidade por criar um utilizável
são as pessoas da comprometidas em criar qualquer aspecto de um utilizável a cada . A palavra “” não deve ser interpretada de forma restrita como “programadores de software”. O é usado em muitos domínios e, mesmo em produtos de software, o trabalho pode exigir design, análise, testes, dados, segurança, operações, pesquisa, arquitetura, redação ou outras competências. Se uma pessoa contribui diretamente para a criação do como parte da , ela se enquadra na responsabilidade de no .
O Scrum Guide identifica quatro responsabilidades centrais dos . Eles criam o plano da , representado pelo . Incorporam qualidade ao aderir à . Adaptam seu plano diariamente em direção ao . E responsabilizam uns aos outros como profissionais.
Essas responsabilidades importam porque o autogerenciamento sem responsabilidade pela entrega seria incompleto. Os não recebem apenas liberdade; eles assumem a responsabilidade pelo plano, pela qualidade, pela adaptação e pela colaboração profissional necessárias para transformar a direção do produto em um resultado utilizável.
Especialização é permitida. Um Developer pode ter profundo conhecimento em testes, UX, engenharia de dados, infraestrutura ou arquitetura. O que o rejeita é transformar essas especialidades em subequipes internas que fragmentam a responsabilidade. Um especialista em testes não constitui uma “equipe de QA” separada e posterior dentro da . Toda a equipe deve se importar com o utilizável, e os compartilham a responsabilidade pelo trabalho necessário para criá-lo.
Essa responsabilidade coletiva muda o comportamento. Se os testes estiverem atrasados, programadores não podem simplesmente dizer: “Minha codificação está pronta”. Se um problema de produção tornar o inutilizável, o fato de um especialista ter concluído sua tarefa individual não significa que a teve sucesso. O desloca a atenção da conclusão individual de tarefas para um resultado compartilhado do produto.
Comportamento esperado dos
Colaborar entre especialidades, criar e adaptar o plano da , atender à , focar no , concluir trabalho utilizável e responsabilizar uns aos outros como profissionais.
Comportamento contrário ao
Esperar que um gerente distribua tarefas, otimizar apenas uma especialidade individual, tratar testes ou operações como problema de outra pessoa ou declarar sucesso porque tarefas pessoais foram concluídas enquanto o ainda não é utilizável.
Três responsabilidades, um único resultado de produto
Responsabilidade
Responsabilidade principal
Foco principal
Pergunta central
Maximizar o valor do produto
e gerenciamento eficaz do
Qual resultado e direção geram mais valor?
Estabelecer o e melhorar a eficácia
Compreensão do , autogerenciamento, interações e práticas eficazes
Como a equipe e a organização podem usar o com mais eficácia?
Criar um utilizável a cada
Plano da , qualidade, adaptação diária e responsabilidade profissional
Como criaremos um Done que avance o ?
Sem hierarquia interna definida pelo e sem subequipes
O Scrum Guide afirma que não existem subequipes nem hierarquias dentro de uma . Isso não significa que o empregador não possua estrutura organizacional. Uma empresa ainda pode ter níveis de cargo, faixas salariais, gestores de linha, comunidades de prática, líderes funcionais ou relações formais de reporte. O simplesmente não utiliza essas estruturas para definir autoridade dentro do trabalho da .
Um engenheiro sênior pode ter mais experiência técnica do que um engenheiro júnior. Um líder de design pode ter conhecimento reconhecido de domínio. Um engineering manager pode ser membro da e também possuir responsabilidades organizacionais fora do framework. Nada disso altera as responsabilidades do . O não cria uma hierarquia em que pessoas mais seniores distribuem trabalho da para pessoas mais juniores.
A ausência de subequipes tem propósito semelhante. Se a se dividir em grupos de análise, desenvolvimento, testes, arquitetura e operações, cada qual com seus próprios objetivos internos e filas, o produto pode ficar preso em mini-Waterfalls. O trabalho passa entre especialidades em vez de ser concluído colaborativamente. O desempenho local pode melhorar enquanto a entrega ponta a ponta se torna mais lenta.
A não elimina a especialização; ela elimina a ideia de que a especialização deve fragmentar a responsabilidade pelo produto. A equipe ainda pode pedir à pessoa com maior conhecimento de segurança que conduza uma conversa de modelagem de ameaças. O que o evita é uma estrutura em que “segurança não é nossa responsabilidade até a subequipe de segurança receber o ticket”.
Nuance importante
O não proíbe títulos organizacionais. Ele apenas não define hierarquia interna do por meio desses títulos. As responsabilidades no são , e .
Responsabilidade coletiva: uma equipe é dona do resultado
A responsabilidade coletiva da fica mais clara em uma afirmação: toda a é responsável por criar um valioso e utilizável a cada . Isso cria um resultado compartilhado, embora as três responsabilidades permaneçam distintas.
Responsabilidade compartilhada não deve ser confundida com responsabilidade indistinta. O continua responsável por maximizar valor. Os continuam responsáveis pelo plano da e pela qualidade. O continua responsável por estabelecer o e melhorar a eficácia. Responsabilidade coletiva significa que ninguém pode otimizar sua própria área ignorando o fracasso do resultado do produto.
Considere uma em que os criam uma funcionalidade tecnicamente excelente que os stakeholders já não precisam. O trabalho técnico pode ser bom, mas o valor falhou. Considere um que escolha trabalho de alto valor, mas a equipe não consiga produzir um Done porque as práticas de qualidade são fracas. A direção de produto pode ser boa, mas a entrega falhou. Considere um que conduza eventos impecáveis enquanto impedimentos organizacionais bloqueiam o progresso. A cerimônia teve sucesso; a eficácia, não.
O torna deliberadamente visíveis essas tensões. As três responsabilidades precisam umas das outras. Valor sem entrega permanece uma ideia. Entrega sem valor é desperdício. Um framework sem adoção eficaz se transforma em cerimônia. A coesa integra essas preocupações.
Tamanho recomendado da : normalmente dez pessoas ou menos
O Scrum Guide descreve Teams como normalmente compostas por dez pessoas ou menos. O raciocínio é prático, não simbólico: a equipe deve ser pequena o suficiente para permanecer e se comunicar com eficiência, mas grande o bastante para concluir trabalho significativo durante uma .
A complexidade da comunicação cresce rapidamente à medida que a equipe aumenta. Mais pessoas criam mais caminhos possíveis de interação, mais coordenação, mais interpretações concorrentes e mais dificuldade para manter entendimento compartilhado. Grupos muito grandes também tendem a recriar subequipes, filas de especialistas e camadas gerenciais simplesmente porque a colaboração direta se torna mais difícil.
A expressão “normalmente dez pessoas ou menos” não é um convite, na prova, para inventar um mínimo ou máximo universal rígido que o Scrum Guide atual não estabelece. Versões anteriores usavam linguagem diferente sobre o tamanho do . Quem se prepara para a deve usar o Guide atual: a geralmente possui dez pessoas ou menos, e equipes menores costumam se comunicar melhor.
Quando uma se torna grande demais, o Guide sugere considerar múltiplas Teams coesas focadas no mesmo produto. Essas equipes devem compartilhar o mesmo , e . O objetivo não é criar departamentos independentes, mas preservar a eficácia de equipes pequenas mantendo a coerência do produto.
Atenção para a prova
Use a redação do Scrum Guide atual: Teams normalmente têm 10 pessoas ou menos. Evite memorizar regras antigas sobre um com 3 a 9 integrantes.
Um : uma direção compartilhada para a
A é uma unidade coesa focada em um objetivo por vez: o . Isso é mais do que um detalhe de gerenciamento do backlog. Um objetivo compartilhado impede que a equipe se transforme em um conjunto de especialistas trabalhando em solicitações não relacionadas.
O descreve um estado futuro do produto que pode servir como alvo para o planejamento. É o objetivo de longo prazo da . A equipe deve cumprir ou abandonar um antes de assumir o próximo. Isso cria coerência estratégica sem impedir que o mude à medida que novas evidências surgem.
Sem um , a priorização tende a se tornar reativa. Cada solicitação de stakeholder passa a competir de forma independente. A equipe pode dedicar uma à retenção, outra à redução de custos internos, outra a uma campanha de marketing e outra à infraestrutura sem uma direção clara de produto conectando essas decisões. Resultados locais se acumulam, mas o produto pode não avançar em direção a um estado significativo.
Um forte também melhora o autogerenciamento. Equipes tomam melhores decisões locais quando entendem por que o trabalho importa. Se os enfrentarem duas opções de implementação, o e o oferecem contexto para avaliar trade-offs. Se o precisar rejeitar uma solicitação de stakeholder, o oferece uma base transparente para a priorização. Se o perceber que a organização puxa a equipe em várias direções, o objetivo oferece um ponto de referência para coaching e facilitação.
Responsabilidade pelo valor: além da entrega de funcionalidades
O propósito do é ajudar pessoas a gerar valor por meio de soluções adaptativas para problemas complexos. A , portanto, não pode definir sucesso apenas como concluir tarefas ou entregar funcionalidades. O valor precisa ser examinado pelo efeito produzido pelo produto.
O possui a responsabilidade explícita por maximizar o valor do produto, mas toda a contribui para a criação de valor. podem revelar que uma funcionalidade solicitada é tecnicamente cara em comparação com o benefício provável. Um pode expor uma restrição de processo que atrasa o aprendizado com o cliente. Designers e engenheiros podem identificar uma solução mais simples. Stakeholders podem trazer evidências de mercado. O valor emerge da combinação dessas perspectivas.
Uma funcionalidade tecnicamente perfeita pode ter valor negativo se gerar confusão, aumentar custos operacionais, expor riscos ou resolver um problema que os usuários não possuem. Da mesma forma, trabalho técnico invisível pode ser altamente valioso quando melhora confiabilidade, segurança, manutenibilidade ou a velocidade de aprendizado futuro. O deixa a definição exata de valor para o contexto, mas mantém o valor no centro das decisões de produto.
É por isso que a equipe deve inspecionar resultados, e não apenas comemorar produção. Uma não é simplesmente uma demonstração de tickets concluídos. É uma oportunidade de inspecionar o resultado da , mudanças no ambiente, progresso em direção ao e o que deve acontecer a seguir. A estrutura da favorece essa conversa porque produto, entrega e eficácia do estão representados em uma única equipe.
Exemplo prático - um produto de abertura digital de conta
Imagine um banco construindo um produto para abertura digital de contas. O é permitir que clientes elegíveis abram e ativem uma conta remotamente, com o mínimo de atrito, ao mesmo tempo em que atendem aos requisitos de identidade, fraude e regulamentação.
A é composta por um , um e sete com competências em desenvolvimento front-end, serviços back-end, desenvolvimento mobile, UX, testes, segurança, dados e operações em cloud. Essas são especialidades, não subequipes. A equipe trabalha em direção a um e a um por vez.
Durante a , o apresenta evidências de que clientes abandonam o fluxo durante a verificação de identidade. Os discutem opções técnicas e selecionam itens do que acreditam poder concluir enquanto atingem um : reduzir o abandono na verificação de identidade tornando o fluxo mais claro e resiliente.
O não distribui “tickets de front-end” e “tickets de teste” para indivíduos. Os criam o e organizam o trabalho. O especialista em UX trabalha em parceria com mobile. Um Developer com foco em segurança ajuda a projetar a captura de evidências. O conhecimento de testes é usado durante toda a implementação, em vez de aguardar uma fase final de QA.
No meio da , a equipe descobre que um provedor externo de identidade retorna códigos de erro inconsistentes. Os adaptam seu plano. O ajuda a esclarecer quais cenários de falha importam mais para clientes e para compliance. O ajuda a remover um facilitando acesso mais rápido à equipe técnica do fornecedor.
Em nenhum momento o se torna o chefe do projeto. O apoia a eficácia. Em nenhum momento o decide como o código deve ser escrito. O protege o valor e a direção. Os permanecem responsáveis por criar o utilizável e atender à .
Na , o é inspecionado com os stakeholders. Os dados mostram que o novo fluxo reduziu um ponto de abandono, mas revelou outra mensagem de consentimento confusa. O é adaptado. A equipe não apenas concluiu funcionalidades; ela aprendeu algo sobre valor.
Na , a identifica que dúvidas relacionadas ao fornecedor externo ainda geram espera excessiva. Eles concordam em realizar um experimento para melhorar o escalonamento técnico e a documentação. A melhoria do produto e a melhoria do sistema da equipe continuam juntas. Essa é a estrutura da funcionando como pretendido: responsabilidades distintas, um único resultado compartilhado de produto.
Antipadrões estruturais comuns
Antipadrão
Como se apresenta
Por que é um problema
como gestor da equipe
O PO distribui tarefas e avalia entregas individuais.
Confunde a responsabilidade por valor com autoridade sobre como os trabalham.
como gerente de projeto
O SM aloca trabalho, coleta status e controla prazos.
Enfraquece o autogerenciamento e transforma o em .
Subequipe de QA
Os testes acontecem depois que os dizem que a codificação terminou.
Cria handoffs e fragmenta a responsabilidade pelo trabalho Done.
Subequipe de arquitetura
Todas as decisões de design exigem aprovação de uma autoridade interna separada.
Pode separar a autoridade de decisão das pessoas que criam o .
Divisão negócio versus TI
O PO representa o “negócio”; os representam a “tecnologia”.
Recria campos opostos em vez de uma única equipe coesa de produto.
Múltiplos Product Owners para um
Stakeholders diferentes priorizam partes distintas de forma independente.
Destrói a clareza da responsabilidade e da ordenação.
enorme
Muitos membros exigem camadas de coordenação e grupos internos.
Reduz a agilidade e frequentemente recria subequipes.
Sucesso por tarefa individual
Indivíduos otimizam apenas a conclusão de seus próprios tickets.
Desvia a atenção de um valioso e utilizável.
Como raciocinar sobre questões de estrutura da na
Quando uma questão da descreve um problema de estrutura de equipe, primeiro identifique qual responsabilidade está realmente envolvida. O problema é valor do produto e gerenciamento do ? Pense no . É sobre como os se organizam e criam o ? Pense em e autogerenciamento. É sobre compreensão do , eficácia, facilitação ou impedimentos organizacionais? Pense no .
Em seguida, procure hierarquia escondida. Respostas erradas frequentemente introduzem um gerente onde o espera autogerenciamento. Um distribui tarefas. Um diz aos como implementar uma funcionalidade. Um líder técnico decide no que todos trabalharão. Um gerente altera o . Essas ações podem parecer eficientes porque centralizam o controle, mas entram em conflito com as responsabilidades definidas pelo .
Depois, procure silos internos. Se uma resposta cria um grupo separado de testes, arquitetura, análise ou “equipe de negócio” dentro da , pergunte se isso fragmenta a responsabilidade pelo . Competências especiais são perfeitamente aceitáveis. Subequipes definidas pelo , não.
Por fim, pense em nível de produto. A existe para criar Increments valiosos e utilizáveis e avançar em direção ao . Uma resposta que otimiza utilização individual, eficiência departamental ou distribuição de tarefas à custa do resultado compartilhado geralmente se afasta do desenho do .
Quatro perguntas para a
1. Qual responsabilidade é dona desta decisão? 2. Isso preserva o autogerenciamento? 3. Mantém uma única equipe coesa em vez de criar subequipes? 4. Melhora a de criar valor em direção ao ?
Responsável por maximizar o valor do produto e pelo gerenciamento eficaz do .
Responsável por estabelecer o e melhorar a eficácia da .
Responsáveis por criar um utilizável, pelo , pela qualidade, adaptação e responsabilidade profissional.
Hierarquia
O não define hierarquia interna entre os membros da .
Subequipes
O não define subequipes dentro da .
Tamanho
Normalmente 10 pessoas ou menos.
Direção
Um por vez.
Resultado compartilhado
Toda a é responsável por criar um valioso e utilizável a cada .
Escala
Se as equipes se tornarem grandes demais, considere várias Teams coesas compartilhando o mesmo , e .
Conclusão: responsabilidades diferentes, uma equipe, uma direção de produto
A estrutura da é intencionalmente simples. Um , um e formam uma unidade pequena, coesa, e . O não adiciona uma camada interna de gestão, subequipes funcionais nem uma cadeia de comando para distribuir o trabalho da . Em vez disso, cria responsabilidades explícitas em torno de valor, eficácia do framework e entrega.
O mantém visíveis o valor e a direção do produto. O ajuda o a se tornar eficaz, e não meramente cerimonial. Os transformam objetivos de produto em Increments utilizáveis, sendo responsáveis por seu plano e pela qualidade. Toda a compartilha a responsabilidade por produzir um valioso e utilizável a cada .
A ausência de hierarquia interna do não elimina especialização nem a realidade organizacional. As pessoas podem ter habilidades, níveis de experiência, títulos e responsabilidades diferentes fora do framework. O que o evita é usar essas diferenças para fragmentar a responsabilidade pelo produto ou substituir o autogerenciamento por internos.
O tamanho da equipe e o reforçam a mesma ideia. Uma equipe relativamente pequena pode se comunicar diretamente e se adaptar com rapidez. Um único oferece direção compartilhada. Quando equipes se tornam grandes demais, o favorece várias equipes coesas alinhadas ao mesmo produto, em vez de um único grupo superdimensionado dividido em departamentos internos.
Na minha avaliação, essa estrutura representa uma das diferenças mais significativas entre o e a organização tradicional de projetos. Ela pede que as organizações parem de otimizar funções separadas e, em vez disso, criem uma equipe capaz de assumir a responsabilidade por um resultado completo de produto. Isso é mais difícil do que renomear funções ou agendar eventos do , porque altera onde vivem as decisões, as responsabilidades e a colaboração.
Para a preparação da , mantenha este modelo mental: o não é o chefe, o não é o gerente, não são apenas programadores e a não é um conjunto de subequipes. Ela é um único sistema responsável por transformar problemas complexos de produto em resultados valiosos e utilizáveis.
Principais aprendizados
A é a unidade fundamental do .
Ela é composta por um , um e .
O não define subequipes nem hierarquias internas.
A é e .
O é responsável por maximizar o valor do produto e pelo gerenciamento eficaz do .
O é responsável por estabelecer o e melhorar a eficácia da .
Os são responsáveis pelo plano da , pela qualidade, pela adaptação diária, pela responsabilidade profissional e pela criação de um utilizável.
não se limitam a programadores; o termo abrange as pessoas que criam o .
A normalmente possui 10 pessoas ou menos.
Teams grandes devem considerar se reorganizar em várias equipes coesas alinhadas ao mesmo produto.
A se concentra em um por vez.
Toda a é responsável por criar um valioso e utilizável a cada .
