Desenvolvimento Orientado à Missão

À medida que as empresas crescem, dimensionar o desenvolvimento de produtos Agile se torna mais difícil. De acordo com 52% dos entrevistados no 13º State of the Agile Report, as diferenças entre a cultura organizacional e os valores do 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 ágil robusta envolve autonomia da equipe na abordagem de problemas complexos, trabalho próximo com os clientes e visão e estratégia de longo prazo.

Esses valores abstratos são difíceis de avaliar e adotar. Em uma organização, a implementação de uma estratégia eficaz para alavancá-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.

Desafios de dimensionamento

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, assim, perder tempo para projetar caminhos estratégicos de produtos. A implantação de novos recursos e produtos pode desacelerar à 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.

Desafios de dimensionar estruturas ágeis 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, criar e comunicar a visão do produto, executar as decisões de pessoal e promover o desenvolvimento da equipe. O nível de equipe realiza as tarefas necessárias para traduzir com eficiência essa visão e estratégia em produtos e recursos valiosos.

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

Uma abordagem leve, a estrutura Mission Driven Development fornece diretrizes suficientes para implementar uma estrutura robusta em torno do dimensionamento do desenvolvimento e da alavancagem dos valores Agile.

Elementos Centrais do Desenvolvimento Orientado à Missão

Missões

O ponto de partida é Mission Discovery. Uma missão de negócios leva tempo e esforço e deve identificar um problema latente, um espaço de solução e o resultado de negócios desejado. Quando definida com precisão, uma missão impulsiona a motivação, promove 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 realizam 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 prazo de 6 semanas permite que todos os esquadrões sigam o mesmo cronograma para o planejamento básico, ao mesmo tempo em que dá tempo suficiente para entregar um resultado significativo.

Período de buffer

A estrutura 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 de 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 forma de entregar soluções.

À medida que os ciclos se prolongam, a precisão das estimativas do produto diminui. Como resultado, exige grandes esforços de planejamento por parte das equipes de produto.

Seis semanas foram chamadas de Cachinhos Dourados dos prazos do produto, 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 envolvimento 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.

Por fim, os gerentes de produto podem se envolver em atividades de planejamento a cada seis semanas, mantendo previsibilidade suficiente para que as equipes mantenham o rumo da missão. Como resultado, mais tempo pode ser focado nas dimensões estratégicas e exploratórias do desenvolvimento de produtos.

Implementação do Desenvolvimento Orientado à Missão

Tomemos, por exemplo, uma startup de estágio intermediário que possui um produto B2B oferecendo otimização de preços de rede que aumenta a receita do cliente por meio do uso de aplicativos de inteligência artificial. O negócio assinou recentemente uma nova rodada de financiamento, com o objetivo de se consolidar como um ator relevante do setor e crescer em 300% a participação de mercado.

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

• Como obter feedback de clientes atuais e potenciais para validar a hipótese de valor pendente?
• Quais recursos devem ser criados ou removidos da plataforma para uma experiência de 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. No Desenvolvimento Orientado à Missão, os detalhes da “última milha” são definidos por cada organização. Os principais elementos a definir 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 é Mission Discovery. Tim Herbig descreve a descoberta como o processo iterativo de reduzir a incerteza em torno de um problema ou ideia para garantir que o produto certo seja construído para o público certo. Antes que qualquer missão seja confirmada em um ciclo de iteração, ela deve ser validada da maneira 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 Chief Product Officer (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, finalmente ampliando 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. Realização de pesquisas de mercado e análise 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. Definir um escopo claro para a missão
5. Coleta de feedback e validação do cliente

Essas atividades ajudam a missão a 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 criados 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 pegue os dados brutos do cliente e retorne uma rede de preços otimizada nos arquivos de dados processados. No entanto, o UX da plataforma não foi otimizado para uma experiência cativante. O objetivo neste momento é determinar se o valor do cliente virá da melhoria do UX, do desenvolvimento de novos recursos ou do aprimoramento dos serviços da plataforma.

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

• Remarcação ultrarrápida
• Interface rápida e responsiva
• Regras de repactuação inteligentes e avançadas
• Recriação e histórico de vendas

Para fins de descoberta, a empresa decide adotar uma abordagem de design sprint: um processo de cinco dias para responder a perguntas críticas de negócios por meio de design, prototipagem e teste de ideias com usuários. O processo de descoberta é executado para cada recurso candidato para ver qual criará mais valor para clientes atuais e potenciais. O principal recurso selecionado para desenvolvimento são as regras de reavaliação 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 comercial claro e estabelecer limites para seu resultado, ao mesmo tempo em que oferece espaço suficiente para que os esquadrões 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 insights descobertos nas fases anteriores.
• Links para um resultado de negócios 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.
• É suficientemente estreito para garantir o foco e suficientemente amplo para evitar 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 do cliente.

Espaço do problema: os usuários querem poder definir e gerenciar regras inteligentes e avançadas de preços para que possam ajustar automaticamente os preços em determinadas condições.

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

Insights: as regras devem ser aplicadas em prioridades personalizadas e ser modificáveis, 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 engajamento do usuário na plataforma em 25%, conforme medido pelo tempo gasto na plataforma.

Montagem do 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 mistura de fatores, que vão desde a complexidade da missão, habilidades de desenvolvedor e designer, interesses e química do esquadrão.

O processo de formação de esquadrões é facilitado por treinadores ágeis. Antes de qualquer decisão, pergunta-se a cada pessoa que tipo de trabalho gostaria de fazer nas próximas seis semanas. Então, 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ários para enfrentar a missão com sucesso.

Os coaches ágeis trabalham com vários esquadrões ao longo do ciclo de desenvolvimento, ajudando-os a levantar impedimentos e dependências. Quando existem vários coaches Agile, eles se reportam ao Head of Agile, que é responsável pela montagem do esquadrão, melhoria contínua e entrega de produtos Agile.

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

Os esquadrões geralmente são misturados após cada ciclo, para que todos possam cooperar com pessoas diferentes, espalhar conhecimento e trabalhar em diferentes dimensões de produtos, embora um esquadrão de alto desempenho possa trabalhar em conjunto por alguns ciclos.

O esquadrão específico no exemplo deve considerar pessoas com recursos de design de interface do usuário, 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 ágeis por meio de práticas ágeis padrão.

Curtas reuniões semanais são realizadas para organizar o trabalho e facilitar o levantamento de impedimentos e dependências. A preparação é feita, se necessário, para garantir que os esquadrões entendam completamente a missão e as histórias dos usuários. Pequenas retrospectivas são realizadas ao final de cada semana para identificar e implementar mudanças e melhorias.

As práticas de entrega contínua devem ser mantidas durante todo o ciclo. O objetivo da missão pode ser alcançado mais cedo, pois o timebox de ciclo de 6 semanas é uma abordagem baseada em cadência para definir 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 versões diferentes:

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

A versão 3 é acordada como a demo para a quarta semana. Como os lançamentos foram realizados ao longo do ciclo de desenvolvimento, o resultado de negócios desejado (neste caso, o engajamento do usuário) deve ser rastreado desde o início do ciclo de desenvolvimento. Graficamente, o progresso seria esperado da seguinte forma:

Período de buffer

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

No SAFe, uma iteração de inovação e planejamento é feita 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 lado 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 suave de novas soluções em produtos existentes.
• Planejamento e priorização da missão . As missões são refinadas, classificadas em lotes pequenos ou grandes e priorizadas para o próximo ciclo de desenvolvimento. Ao priorizar missões, algumas empresas implementam pitch days durante os quais as principais missões são apresentadas à empresa e, em seguida, de forma colaborativa, comprometidas com o próximo ciclo de desenvolvimento.
• Hackathons . Hackathons ganharam popularidade crescente entre startups e empresas graças à sua capacidade de promover a inovação, criar comunidade e construir novos conhecimentos e habilidades de uma maneira divertida. Os resultados são apresentados a outros e tornam-se candidatos para o Backlog da Missão.
• Desenvolvimento de protótipos experimentais ou projetos paralelos . É uma prática comum dar aos engenheiros e projetistas tempo para trabalhar no que decidirem, desde que mostrem o trabalho feito no final do tempo de buffer.
• Trabalho de engenharia . Trabalhos de engenharia puros, como desenvolvimento de infraestrutura, automação de testes, redução de dívida técnica e migrações de sistemas, geralmente são realizados.
• 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 in loco, comunidades de prática, workshops de tecnologia, entre outros.

Os períodos de buffer devem contar com as 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:

Planejamento de capacidade

Ao decidir o compromisso da missão para o próximo ciclo de desenvolvimento, uma prática comum, de acordo com o cofundador da Basecamp, Jason Fried, é primeiro identificar lotes pequenos ou grandes. Grandes lotes referem-se a grandes recursos ou funcionalidades do produto, enquanto pequenos lotes referem-se 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. Pequenos lotes são missões estimadas em 3-4 semanas, e grandes lotes 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, assumir uma nova missão de lote pequeno 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 manobras e adaptações em caso de trabalho não planejado. Equipes de grandes lotes obtêm o máximo de foco possível durante o ciclo, enquanto equipes de pequenos lotes podem lidar com tarefas ad hoc que surgem de trabalho inesperado.

Combinar lotes pequenos e grandes também reduz o risco. Ter apenas grandes lotes 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 de um bom gerenciamento de mudanças. Além disso, em caso de trabalho não planejado, haverá menos capacidade disponível. Por fim, se várias equipes grandes falharem, a iteração pode ser percebida como improdutiva e, assim, desmoralizar os esquadrões.

Riscos do Desenvolvimento Orientado à Missão

Há muitos benefícios na implementação do Desenvolvimento Orientado por 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 nos resultados do desenvolvimento pode ser significativo.

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

O porquê de uma missão

Missões empresariais robustas devem ter uma definição abrangente do espaço do problema e sua relação com a visão da empresa. Se essa relação não for clara, insights valiosos podem ser perdidos devido à falta de compreensão de como a resolução de problemas afeta os objetivos da empresa.

Armadilha de Cachoeira

Cair em um modelo em cascata durante as seis semanas é uma tendência natural para os esquadrões. Existem dois fatores principais para isso. Primeiro, a pressão para a 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 incentivadas para obter lançamentos ágeis ao longo do ciclo e evitar riscos relacionados à 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. Confiar em padrões e práticas de desenvolvimento, como design atômico, reduz os esforços de desenvolvimento e, consequentemente, acelera o dimensionamento. Outra prática comum nessa estrutura é uma equipe de operações central que lida com a infraestrutura, além de gerenciar as operações e o monitoramento do produto.

Ciclo de 6 semanas como quadro míope

Alguns cenários não serão adequados para a estrutura. Isso se torna especialmente verdadeiro ao lidar 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 dimensionar o Agile

Escalar o Agile para acompanhar o ritmo de desenvolvimento de produtos e crescimento da empresa é um desafio latente para os praticantes do Agile. Como uma abordagem ágil desenvolvida recentemente, o framework Mission Driven Development 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 ágeis tradicionais. O Mission Driven Development tem o potencial de ser o novo Scrum para empresas em crescimento.