Muitas empresas querem ser iguais ao Spotify. Estamos spotifizando nossas equipes… estamos fazendo squads, chapters, guilds, CoPs… mas o ponto é que nada disso representa o modelo Spotify. Tem perguntas que você precisa responder, e uma questão importante para compreender:

Primeiro a questão importante:

O modelo Spotify é baseado em duas questões: Confiança e Autonomia. A confiança deve ser maior que a necessidade de controle.

E importante: vão existir diversos controles. Estamos falando aqui da necessidade de controlar o outro. É diferente quando se consegue perceber a responsabilidade de ter uma missão para fazer acontecer. Os controles ajudam a pessoa a guiar o seu processo de trabalho. Em uma estrutura de responsabilidade > hierarquia, você precisa de indicadores para poder guiar o seu trabalho.

O grande ponto aqui é entender que ao tentar inovar, iremos fazer coisas que não são úteis, e vamos errar. O ponto é como errar rápido? Rápido significa coletar feedbacks e poder mudar a direção do que estamos fazendo, buscando entregar melhor valor. Você pode buscar este tipo de ação através de entrevistas, pesquisas em campo, testes de usabilidade e features falsas (ao clicar no menu / botão você avisa o usuário que esta feature não existe ainda, e pede para ele te contar o que motivou o click – ele é curioso ou precisa disso?) são exemplos disso.

Junto com isso, gosto muito da definição do 3P de Jim Womack: Purpose, Process, People. Processos existem para conectar pessoas no seu propósito. Se você tem uma cultura de inovação, isso vai fazer parte da missão, do propósito das pessoas que fazem parte da sua equipe. Com isso, elas precisam ter espaço para estudar, praticar, conectar, colaborar e entrar em modo de descoberta (discovery). Somente o modo execução (delivery) não vai garantir isso.

E aqui as perguntas que tinha comentado:

• O processo de desenvolvimento de software da sua equipe, permite adicionar funcionalidades em produção somente para determinados usuários?
  >> Use o conceito de Feature Toggle. Com ele, você consegue ativar funcionalidades para apenas alguns usuários e consegue levar para produção testes a serem validados com alguns usuários. O Moip por exemplo usa o ifman/curtain para alcançar estes resultados. 
• Sua entrega está baseada somente em datas ou em percepções de valor a serem alcançadas com os usuários?
  >> Você pode e deve ter datas definidas. Eu gosto de trabalhar na visão de trimestres. O ponto é que o usuário deve receber N updates de uma funcionalidade, e em cada uma destas entregas deve existir uma percepção de valor adicionado. O ponto de fazer estes checkpoints, é que o seu usuário vai indicar quando ele já tem o suficiente para poder entregar o valor que ele precisa entregar. 
• O valor a ser entregue é comunicado aos usuários chave ou coletado em conjunto com eles?
  >> Entenda o quanto você “acha” que sabe o que o seu usuário precisa e o quanto você está realizando de conversas/entrevistas para entender o que o seu projeto/produto precisa agora. Quem da sua equipe estiver no papel de Product Owner ou alguma função equivalente, deveria ter entre 30-50% do tempo da semana trabalhando com usuários reais do produto e pessoas que estão em contato com usuários reais do produto. 
• A sua previsibilidade de entrega existe para necessidades governamentais ou para manter a pressão na equipe?
  >> O ritmo deve ser sustentável. Isso não quer dizer que eu seja contra horas extras. Elas devem existir para alguma necessidade de governança ou alguma entrega que seja vital para a empresa. Portanto, elas são exceções. Fora isso, é necessário / obrigatório que as equipes técnicas entendam a sua cadência e trabalhem para entender a sua capacidade de entrega. O jogo aí passa a ser de entender o que pode ser priorizado e o que pode existir de conversas / cortes de escopo para ajudar nas entregas a serem realizadas. Quando a equipe se importa com o cliente e com o produto, a fluidez passa parte do vocabulário das equipes. 
• Após a entrega, sua equipe mede que a funcionalidade colocada em produção está trazendo o resultado esperado? 
  >> O deploy é apenas um item que permite começar a testar se o que foi feito realmente resolve o problema originalmente levantado pelos usuários que foram entrevistados. É importante entender a diferença entre deploy e release. Deploy é a instalação. E ela pode acontecer a cada atualização de código fonte se for o caso. Release é a liberação de funcionalidades para clientes. Essa sim precisa de mais controles, para se entender quem está tendo acesso e que feedbacks estamos recebendo destas liberações. Esses feedbacks servem para identificar se podemos liberar funcionalidades para mais usuários ou se devemos desligar para todos por algum ajuste que se faz necessário.  

— Daniel Wildt (entenda diferentes tipos de inovação)

P.S.: O nome deste post foi inspirado em um artigo que li, de 2012 (Os CIOs precisam de um alerta).

P.S.2: Este post estava em rascunho desde 26/Set/2012. 🙂