Conforme as empresas crescem, escalando Ágil o desenvolvimento de produtos se torna mais difícil. De acordo com 52% dos entrevistados no 13º Relatório do Estado do Agile , as diferenças entre cultura organizacional e valores Agile são a principal desvantagem em seu trabalho.

Os líderes organizacionais são capazes de alavancar a cultura Agile para melhorar o desenvolvimento de produtos. Uma cultura Agile robusta envolve autonomia da equipe na abordagem de problemas complexos, trabalho próximo aos clientes e visão e estratégia de longo prazo.

Esses valores abstratos são difíceis de avaliar e nos envolver. Em uma organização, implementar uma estratégia eficaz para aproveitá-los torna-se um trabalho não trivial. A abordagem Mission Driven Development (MDD) surgiu a partir de startups de estágio intermediário como uma alternativa para desenvolver essa cultura.

Dimensionando Desafios

Vários padrões de desaceleração podem surgir durante o dimensionamento. A motivação da equipe pode diminuir com projetos que têm um final incerto. Os gerentes de produto podem se sentir perdidos em reuniões operacionais e, portanto, perder tempo para projetar caminhos de produtos estratégicos. A implantação de novos recursos e produtos pode diminuir à medida que os sistemas se tornam cada vez mais complexos.

Essas barreiras devem ser abordadas de uma perspectiva cultural e prática. Superá-los envolve abrir mão do controle, aumentar a autonomia da equipe, implementar transparência radical e configurar uma estrutura de desenvolvimento de produto eficiente para gerar resultados.

Padrões de desaceleração	Alavancas de gerenciamento
A motivação da equipe diminui.	Abandonando o controle e aumentando a autonomia da equipe
Os gerentes de produto se sentem sobrecarregados com as reuniões operacionais.	Implementando transparência radical
A implantação de novos recursos fica mais lenta.	Configurando uma estrutura de desenvolvimento de produto eficiente

Desafios de escalonar frameworks Agile tradicionais

Ao dimensionar o Agile, os níveis de gerenciamento e equipe precisam ser sincronizados. O nível de gestão é responsável por desenvolver a estratégia da empresa, criando e comunicando a visão do produto, executando as decisões de pessoal e promovendo o desenvolvimento da equipe. O nível da equipe realiza as tarefas necessárias para traduzir com eficiência essa visão e estratégia em produtos e recursos valiosos.

Os frameworks Agile tradicionais (XP, Scrum e Kanban) são otimizados para operar no nível da equipe, deixando as relações de gerenciamento principalmente sem solução. Uma nova onda de frameworks Agile dimensionados evoluiu para preencher essa lacuna, ou seja, SAFe, LeSS, Scrum de Scrums, Nexus, DAD, etc. No entanto, essas abordagens requerem muito planejamento para implementar e esforço para gerenciar e manter.

Uma abordagem leve, a estrutura de Desenvolvimento Orientado à Missão fornece diretrizes suficientes para implementar uma estrutura robusta em torno do desenvolvimento de escala e do aproveitamento de valores Agile.

Elementos Centrais do Desenvolvimento Orientado à Missão

Missões

O ponto de partida é a descoberta da missão. Uma missão empresarial exige tempo e esforço e deve identificar um problema latente, um espaço de solução e o resultado comercial desejado. Quando definida com precisão, uma missão impulsiona a motivação, estimula a colaboração e promove a pesquisa em espaços de design mais amplos.

Esquadrões

Os atores responsáveis ​​pelo sucesso de cada missão são os esquadrões. Em colaboração com os gerentes de produto, pequenas equipes de 2 a 4 pessoas conduzem as atividades necessárias para entregar soluções que atendam ao objetivo da missão e às restrições de tempo.

Ciclo de 6 semanas

O cronograma de 6 semanas permite que todos os esquadrões sigam o mesmo cronograma para o planejamento da base, ao mesmo tempo que dá tempo suficiente para entregar um resultado significativo.

Período de Buffer

A estrutura do MDD geralmente inclui um período de buffer de uma ou duas semanas para integrações e implantações finais, treinamento e desenvolvimento de habilidades, atividades de inovação e planejamento do próximo ciclo, entre outras coisas.

A importância do ciclo de 6 semanas

Embora o período de seis semanas possa parecer muito para alguns praticantes do Agile, ele contém vários benefícios importantes.

As equipes que trabalham em ciclos curtos tendem a perder o envolvimento com a visão do produto, pois sentem que estão verificando uma “lista de lavanderia” de correções, bugs e pequenos recursos. Isso ameaça a autonomia das equipes para explorar e escolher a melhor maneira de entregar soluções.

À medida que os ciclos se prolongam, a precisão da estimativa do produto diminui. Como resultado, requer grandes esforços de planejamento pelas equipes de produto.

Seis semanas foi chamado de Cachinhos dourados de prazos de produtos , fornecendo tempo suficiente para entregar um Produto Mínimo Viável por meio de pensamento inovador, prototipagem rápida e entrega contínua.

O ciclo de 6 semanas aumenta ainda mais o engajamento da visão da equipe, aproveitando a autonomia. O microgerenciamento não é necessário, desde que as missões sejam claramente definidas e os ciclos sejam curtos o suficiente para que as equipes se concentrem apenas nos resultados desejados.

Finalmente, os gerentes de produto podem se envolver em atividades de planejamento a cada seis semanas, mantendo previsibilidade suficiente para que as equipes se mantenham no caminho certo em direção à missão. Como resultado, mais tempo pode ser dedicado às dimensões estratégica e exploratória do desenvolvimento de produtos.

Implementação de Desenvolvimento Orientado à Missão

Vejamos, por exemplo, uma startup de estágio intermediário que tem um produto B2B que oferece otimização de preços de rede, o que aumenta a receita do cliente por meio do uso de aplicativos de inteligência artificial. Recentemente, o negócio fechou uma nova rodada de financiamento, com o objetivo de se consolidar como um ator relevante do setor e aumentar sua participação de mercado em 300%.

Nesse cenário, existem vários desafios de desenvolvimento de produto:

• Como o feedback de clientes atuais e potenciais pode ser obtido para validar a hipótese de valor pendente?
• Quais recursos devem ser criados ou removidos da plataforma para uma experiência do usuário atraente?
• Como a estrutura de gerenciamento pode ser configurada para lidar com o dimensionamento e alavancar os valores culturais para acelerar o crescimento?

No final, para evitar frameworks complexos, a empresa decide aplicar o framework Mission Driven Development. Em Mission Driven Development, os detalhes da “última milha” são definidos por cada organização. Os principais elementos a serem definidos são:

• Descoberta da missão
• Estrutura da missão
• Montagem de esquadrão
• Inspeção e adaptação
• Iteração de buffer
• Planejamento de capacidade

Descoberta da missão

O ponto de partida é a descoberta da missão. Tim Herbig descreve descoberta como o processo iterativo de redução da incerteza em torno de um problema ou ideia para garantir que o produto certo seja construído para o público certo. Antes de qualquer missão ser comprometida em um ciclo de iteração, ela deve ser validada da forma mais abrangente possível.

O processo de descoberta da missão é conduzido por equipes especificamente alocadas. A equipe de descoberta é liderada pelo gerente de produto e consiste em pesquisadores de produto, analistas de negócios e designers. Quando existem vários gerentes de produto, eles se reportam ao Diretor de Produtos (CPO), que garante uma visão comum entre os produtos, adequação dos produtos e estratégia global da empresa e entrega pontual.

O ponto de partida recomendado para a descoberta da missão são desafios, problemas ou oportunidades. Partir de um desafio, por exemplo, ajuda a equipe a explorar mais espaços de design, ampliando finalmente as possibilidades de solução.

A validação da missão envolve várias atividades que ajudam a empresa a entender melhor as necessidades do cliente:

1. Realizar pesquisas de mercado e análises de concorrentes
2. Compreender o espaço do problema no qual a missão é definida
3. Projetando esboços e protótipos de baixa fidelidade
4. Definindo um escopo claro para a missão
5. Coletando feedback e validação do cliente

Essas atividades ajudam a missão de ser uma diretriz sólida para o time de desenvolvimento e garantem a criação de valor para os usuários.

Como resultado, algumas missões são validadas para entrar no Mission Backlog, que evolui continuamente com atividades de descoberta e coleta de feedback.

No exemplo, vamos aceitar este desafio: quais recursos devem ser desenvolvidos a partir da plataforma para produzir uma experiência de usuário atraente? Apenas uma equipe de descoberta, liderada pelo gerente de produto, seria adequada para enfrentar esse desafio.

Vamos supor que, atualmente, a plataforma da empresa de exemplo pega os dados brutos do cliente e retorna uma rede de preços otimizada em arquivos de dados processados. No entanto, a UX da plataforma não foi otimizada para uma experiência cativante. O objetivo neste ponto é determinar se o valor para o cliente virá do aprimoramento da UX, do desenvolvimento de novos recursos ou do aprimoramento dos serviços da plataforma.

Após a pesquisa de mercado inicial, a decisão é desenvolver novos recursos. Os recursos candidatos para a plataforma são:

• Reprecificação ultrarrápida
• Interface rápida e responsiva
• Regras de repricing inteligentes e avançadas
• Histórico de preços e vendas

Para fins de descoberta, a empresa decide tomar um design sprint abordagem: um processo de cinco dias para responder a perguntas críticas de negócios por meio de design, prototipagem e ideias de teste com usuários. O processo de descoberta é executado para cada recurso candidato para ver qual criará mais valor para os clientes atuais e potenciais. O principal recurso selecionado para desenvolvimento são regras de repricing inteligentes e avançadas.

Estrutura da Missão

Alcançar uma definição de missão sólida não é uma tarefa trivial. Ele deve representar um desafio de negócios claro e definir limites para seu resultado, ao mesmo tempo que oferece espaço suficiente para que as equipes cheguem a uma solução inovadora e eficiente. Uma missão clara e precisa:

• Afirma claramente um desafio de negócios, tendo identificado e delineado o espaço do problema.
• Sintetiza todas as informações e percepções descobertas nas fases anteriores.
• Links para um resultado comercial desejado.
• É orientado para resultados, indicando claramente a imagem do sucesso da missão.
• É realista e alcançável dentro da oportunidade do ciclo de 6 semanas.
• É estreito o suficiente para garantir o foco e amplo o suficiente para ficar longe dos detalhes.

No exemplo, após uma semana de descoberta, as informações e o feedback do usuário foram coletados e sintetizados.

Usuário-alvo: Analistas de preços de clientes.

Espaço do problema: Os usuários desejam definir e gerenciar regras inteligentes e avançadas de precificação, para que possam ajustá-la automaticamente em determinadas condições.

As condições mais valiosas para as regras são preço do concorrente, urgência de remessa, total do pedido, estoque disponível e desconto para clientes premium.

Intuições: As regras devem ser aplicadas em prioridades personalizadas e podem ser modificadas, se necessário.

Os analistas gostariam de ver facilmente quais regras se aplicam em determinados momentos para um determinado produto.

Resultado de negócios desejado: Aumente o envolvimento do usuário com a plataforma em 25%, conforme medido pelo tempo gasto na plataforma.

Montagem de esquadrão

O processo de formação da equipe é feito ad hoc para cada ciclo de desenvolvimento. A autonomia da equipe e os princípios de auto-organização permanecem centrais. A montagem da equipe é guiada por uma combinação de fatores, que vão desde a complexidade da missão, habilidades do desenvolvedor e designer, interesses e química do esquadrão.

O processo de formação do time é facilitado pelos treinadores Agile. Antes de qualquer decisão, cada pessoa é questionada sobre que tipo de trabalho gostaria de realizar nas próximas seis semanas. Em seguida, com base na experiência, conhecimento e habilidades, os esquadrões são construídos garantindo que eles tenham o conhecimento e as habilidades necessárias para enfrentar com sucesso a missão.

Os treinadores Agile trabalham com vários times ao longo do ciclo de desenvolvimento, ajudando-os a aumentar os impedimentos e dependências. Quando existem vários coaches Agile, eles se reportam ao Chefe do Agile, que é responsável pela montagem do time, melhoria contínua e entrega de produtos Agile.

O tamanho do esquadrão recomendado é de 2 a 4 pessoas: geralmente, um designer e um ou dois desenvolvedores, dependendo da complexidade da missão. Um engenheiro de QA é considerado para auxiliar um ou mais esquadrões a atingir os padrões de qualidade desejados.

Os esquadrões costumam ser misturados após cada ciclo, para que todos possam cooperar com pessoas diferentes, difundir conhecimento e trabalhar em diferentes dimensões do produto, embora um esquadrão de alto desempenho possa trabalhar juntos por alguns ciclos.

O esquadrão específico no exemplo deve considerar pessoas com recursos de design de IU, processamento de dados e visualização de dados.

Inspecionando e adaptando dentro do ciclo

Transparência, inspeção e adaptação devem ser incentivadas continuamente pelos coaches Agile por meio de práticas Agile padrão.

São realizadas reuniões semanais curtas para organizar o trabalho e facilitar o levantamento de impedimentos e dependências. O tratamento é feito, se necessário, para garantir que os esquadrões entendam totalmente a missão e as histórias de usuários. Curtas retrospectivas são realizadas no final de cada semana para identificar e implementar mudanças e melhorias.

As práticas de entrega contínua devem ser mantidas ao longo do ciclo. O objetivo da missão poderia ser alcançado mais cedo, já que o timebox de ciclo de 6 semanas é uma abordagem baseada na cadência para definir as regras básicas enquanto ajuda a alcançar a previsibilidade do esquadrão.

Uma boa prática para aumentar a transparência é uma demonstração no final da quarta semana, com base em um marco acordado entre esquadrões e gerentes de produto. O objetivo dessas demonstrações é adaptar, reduzir ou aumentar o escopo conforme necessário.

Para a missão de exemplo, um plano de lançamento foi acordado entre o esquadrão e o gerente de produto em quatro lançamentos diferentes:

1. Versão 1:
   • Nova IU de recurso de regra
   • Regras de preços do concorrente
2. Versão 2:
   • Regra de urgência de envio
   • Regra total do pedido
   • Prioridades de regras
3. Versão 3:
   • Regra de inventário disponível
   • Regra de aplicativo de visualização
4. Versão 4:
   • Desconto para clientes premium

A versão 3 foi aprovada como demonstração para a quarta semana. Como as liberações foram realizadas ao longo do ciclo de desenvolvimento, o resultado comercial desejado (neste caso, o envolvimento do usuário) deve ser rastreado a partir do momento em que o ciclo de desenvolvimento começa. Graficamente, o progresso seria esperado da seguinte forma:

Período de Buffer

Tomar uma ou duas semanas como um período intermediário é uma prática replicada por meio de implementações de Desenvolvimento Orientado à Missão, bem como por meio de outras abordagens de dimensionamento, como SAFe.

No SAFe, um inovação e iteração de planejamento é feito em cada ciclo de desenvolvimento. Ele serve como um alternador de contexto, permitindo processos e atividades de exploração e inovação geralmente deixados de fora por outras estruturas focadas na entrega. Exemplos de atividades implementadas nesta semana tampão:

• Integração final da solução . Ao implantar perto do final do ciclo de 6 semanas, é provável que a integração, verificação, documentação e validação permaneçam pendentes. O tempo dedicado ajuda a garantir uma integração eficaz e sem problemas de novas soluções em produtos existentes.
• Planejamento e priorização da missão . As missões são refinadas, classificadas em pequenos ou grandes lotes e priorizadas para o próximo ciclo de desenvolvimento. Ao priorizar missões, algumas empresas implementam dias de apresentação durante os quais as principais missões são apresentadas à empresa e então - de forma colaborativa - comprometidas para o próximo ciclo de desenvolvimento.
• Hackathons . Hackathons têm ganhado popularidade crescente entre startups e empresas graças à sua capacidade de fomentar a inovação, criar comunidades e construir novos conhecimentos e habilidades de uma forma divertida. Os resultados são apresentados a outras pessoas e se tornam candidatos ao Backlog da missão.
• Desenvolvimento de protótipos experimentais ou projetos paralelos . É prática comum dar aos engenheiros e projetistas tempo para trabalhar no que quer que decidam, contanto que mostrem o trabalho realizado no final do tempo de buffer.
• Trabalho de engenharia . Normalmente, são realizados trabalhos de engenharia pura, como desenvolvimento de infraestrutura, automação de testes, redução de dívidas técnicas e migrações de sistemas.
• Desenvolvimento de novas habilidades e conhecimentos . O ritmo acelerado da evolução do conhecimento força os desenvolvedores a se manterem atualizados sobre as tendências globais. O buffer time é adequado para a realização de treinamentos presenciais, comunidades de prática e oficinas de tecnologia, entre outros.

Os períodos de amortecimento devem contar com lacunas de conhecimento identificadas, objetivos de inovação e necessidades para o próximo ciclo. Por exemplo, um período de buffer de uma semana pode ser assim:

	Segunda-feira	terça	Quarta feira	Quinta feira	Sexta-feira
SOU	Integrações finais	Retrospectiva do ciclo anterior	Hackathon	Demonstração Hackathon	Dia da missão
PM	Documentação	Treinamento e workshops		Treinamento e workshops	Planejamento da próxima iteração

Planejamento de capacidade

Ao decidir o compromisso da missão para o próximo ciclo de desenvolvimento, uma prática comum, de acordo para o co-fundador da Basecamp, Jason Fried, é primeiro identificar lotes pequenos ou grandes. Lotes grandes referem-se a grandes recursos ou funcionalidades do produto, enquanto lotes pequenos se referem a iterações ou tarefas menores. No exemplo dado, a missão selecionada para um novo recurso pode ser considerada um grande lote.

A recomendação aqui é direta: sempre tenha uma mistura de lotes pequenos e grandes. Lotes pequenos são missões estimadas em 3-4 semanas, e lotes grandes podem levar seis semanas ou mais.

Se uma equipe de pequeno lote cumpriu sua missão na semana 3 ou 4, a demonstração acordada é a oportunidade de avaliar se o esquadrão deve continuar trabalhando para melhorar a solução implementada, ajudar outro esquadrão, realizar uma nova missão de pequeno lote ou começar trabalho não planejado.

Uma boa mistura de lotes grandes e pequenos impede que as pessoas trabalhem a 100% da capacidade, permitindo-lhes manobrar e adaptar-se em caso de trabalho não planejado. As equipes de lote grande obtêm o máximo de foco possível durante o ciclo, enquanto as equipes de lote pequeno podem lidar com tarefas ad hoc que surgem de trabalho inesperado.

Combinar lotes pequenos e grandes também reduz o risco. Ter apenas lotes grandes pode aumentar a probabilidade de um impacto negativo na experiência do usuário. Se vários novos recursos forem lançados próximos uns dos outros, eles devem ser acompanhados por um bom gerenciamento de mudanças. Além disso, em caso de trabalho não planejado, haverá menos capacidade disponível. Por último, se várias equipes de lote grande falharem, a iteração pode ser sentida como improdutiva e, assim, desmoralizar as equipes.

Riscos do Desenvolvimento Orientado à Missão

Há muitos benefícios na implementação do Desenvolvimento Orientado à Missão, mas, como qualquer estrutura prescritiva, há vários riscos inerentes que precisam ser considerados.

Escopo da missão

As missões devem ser realistas, visando um bom ajuste entre a complexidade do desafio e as habilidades do esquadrão; caso contrário, o impacto sobre os resultados do desenvolvimento pode ser significativo.

Uma missão excessivamente ambiciosa pode gerar frustração e ansiedade, afetando negativamente o desempenho do time. Por outro lado, uma missão sem entusiasmo pode causar desmotivação e tédio ao time. Assim, uma mentalidade de Produto Mínimo Viável deve permanecer constante dentro da estrutura.

O porquê de uma missão

Missões de negócios robustas devem ter uma definição abrangente do espaço do problema e sua relação com a visão da empresa. Se esta relação não for clara, percepções valiosas podem ser perdidas devido à falta de compreensão de como a resolução de problemas afeta os objetivos da empresa.

Armadilha para Cachoeira

Cair em um modelo em cascata durante as seis semanas é uma tendência natural para os times. Existem dois fatores principais para isso. Primeiro, a pressão para implantação é mais forte perto do final do ciclo. Em segundo lugar, os esquadrões querem espremer o máximo de escopo possível dentro de uma missão, resultando em uma urgência de desdobramento no final do ciclo de desenvolvimento. Portanto, as práticas de entrega contínua devem ser encorajadas a alcançar lançamentos Agile ao longo do ciclo e evitar riscos relacionados a cascata.

Operação do Produto

As tarefas de operação do produto, como gerenciamento de infraestrutura, serviços ou monitoramento de componentes, devem ser mantidas fora do escopo dos esquadrões, pois podem afetar a velocidade. Baseando-se em padrões de desenvolvimento e práticas como design atômico reduz os esforços de desenvolvimento e, consequentemente, acelera o dimensionamento. Outra prática comum nessa estrutura é uma equipe central de operações que lida com a infraestrutura, além de gerenciar as operações e o monitoramento do produto.

Ciclo de 6 semanas como uma estrutura míope

Alguns cenários não serão adequados para a estrutura. Isso se torna especialmente verdadeiro quando se lida com sistemas grandes e complexos que podem ter um enorme impacto na experiência do cliente, como projetos de P&D ou migração de sistemas críticos.

Uma opção leve para escalonamento ágil

Escalar o Agile para manter o ritmo de desenvolvimento de produtos e crescimento da empresa é um desafio latente para os praticantes do Agile. Como uma abordagem ágil desenvolvida recentemente, a estrutura de Desenvolvimento Orientado à Missão ganhou popularidade entre as empresas por sua facilidade de uso e implementação. O framework MDD coloca em movimento um processo de inovação de produto transversal de ponta a ponta, da descoberta à entrega, que preenche as lacunas presentes nas estruturas Agile tradicionais. O Desenvolvimento Orientado à Missão tem o potencial de ser o novo Scrum para empresas em crescimento.

Compreender o básico

Quais são os diferentes frameworks Agile?

Existem muitos frameworks Agile diferentes adequados para diferentes situações. Estruturas tradicionais para uma ou poucas equipes incluem Scrum, Kanban e XP. Frameworks Agile escalados incluem SAFe, LeSS, DAD, [email protegido] , Desenvolvimento orientado para a missão, etc.

Quais são as etapas do ciclo normal de desenvolvimento?

O ciclo normal de desenvolvimento, de acordo com SDLC, consiste em planejamento, análise, projeto, implementação e manutenção.

Quais são os seis estágios do processo de desenvolvimento de produto?

Os seis estágios do processo de desenvolvimento de produto são geração de ideias, pesquisa de mercado, desenvolvimento de conceito, design e desenvolvimento de produto, teste e lançamento.

Quais são os estágios de um ciclo de projeto?

Os cinco estágios de um ciclo de projeto são iniciação, planejamento, execução, monitoramento e encerramento.

Quais são os elementos de um ciclo de projeto?

Os elementos de um ciclo de projeto são escopo, recursos, cronograma, qualidade e riscos.