No post anterior contei sobre a origem do livro “Sprint a Sprint”. Neste post, contarei como foi o processo de escrita.
Ao escrever o livro, Paulo Caroli e eu buscamos adotar diversas práticas e princípios utilizados por equipes ágeis no desenvolvimento de produtos digitais. Sim, isso mesmo, agilidade não funciona só com TI!
A seguir, abordarei alguns pontos que considero fundamentais para o sucesso do livro:
Integração contínua (CI) e entrega contínua (CD)
Os primeiros acordos que fizemos quando começamos a escrever o livro foram: “se adicionar, remover ou alterar algo, salve o arquivo” e “as alterações devem ser feitas diretamente nos arquivos compartilhados no Dropbox”. Ou seja, sempre que eu incluía algo novo ou alterava qualquer coisa, essa alteração ficava disponível para o Caroli rapidamente. Nós não ficávamos segurando o conteúdo de um capítulo, por exemplo, até que estivéssemos 100% satisfeitos com ele (até porque isso talvez nunca tenha acontecido).
Neste caso, não existia o componente de automação executando testes como temos com CI em desenvolvimento de software. Porém, garantíamos o componente cultural da integração contínua e integrávamos com frequência o que tínhamos escrito.
Após certo tempo, passamos também a aplicar o componente cultural da entrega contínua. Depois de finalizarmos o conteúdo base do livro (MVP), passamos a disponibilizar o ebook no Leanpub. A partir daí, a cada correção/alteração, por menor que fosse, publicávamos uma nova versão.
Produto Mínimo Viável (MVP)
“Se você não tem vergonha da primeira versão do seu produto, você demorou demais para lançá-lo”
Reid Hoffman, fundador do LinkedIn
Quando lançamos a primeira versão do ebook, ele não era nem de longe um ebook que eu consideraria como concluído, porém, era bom o bastante para atingir o seu objetivo: validar se existia o interesse por aquele tipo de conteúdo.
Nosso MVP, ou Livro Mínimo Viável neste caso, realmente me deixava com bastante vergonha. Apesar desse desconforto, o Caroli foi um ótimo mentor e me ajudou a manter o foco no que realmente importava. Alguns exemplos de itens que não priorizamos para o MVP:
- Capa: A capa era simplesmente horrorosa, criada com um gerador de capas online em 10 minutos.
- Título: A verdadeira história de um time em formação após a Lean Inception. Tratava-se de um ótimo subtítulo, mas como título era longo demais e sempre me confundia. Cada vez que eu ia citar o livro acabava falando um título diferente (A história de um time em formação após a Lean Inception, A verdadeira história de um time ágil após a Lean Inception, A verdadeira história de um time após a Lean Inception, A verdadeira história de um time em formação depois da Lean Inception, etc).
- Ilustrações e imagens: As ilustrações maravilhosas que vocês podem ver no livro também não existiam. Ao invés disso, tínhamos prints de tela e fotos do time com emojis substituindo o rosto das pessoas.
- Organização do conteúdo, ortografia e gramática: Existiam muitos erros de português e a leitura não era fácil. Alguns conteúdos não se conectavam e outros não tinham sido bem explicados.
Todos esses pontos, e vários outros, não foram priorizados para o MVP. Apesar disso, sabíamos que teríamos que trabalhar neles caso o MVP tivesse sucesso.
Simplicidade
“Simplicidade — a arte de maximizar a quantidade de trabalho não realizado — é essencial”
10o princípio do Manifesto Ágil
Esse princípio guiou muito o nosso trabalho. Sempre que precisávamos apresentar algum conceito, tentávamos fazer isso em um parágrafo ou pouco mais do que isso. Para tornar isso viável, adicionamos referências para outros conteúdos mais detalhados. Buscar a simplicidade nem sempre foi fácil, mas ao fazermos isso, reduzimos bastante a quantidade de trabalho e mencionamos outros livros e artigos já existentes que possivelmente abordam esses assuntos de forma muito melhor do que nós teríamos feito.
Foco no usuário
Outro ponto que trabalhamos durante a escrita do livro foi o foco no usuário, ou seja, nas pessoas que vão ler o livro.
Nosso objetivo nunca foi escrever um livro avançado sobre times ágeis, mas sim contar um case real e os principais aprendizados que tivemos com ele. Para que mais pessoas pudessem absorver esses aprendizados, foi fundamental explicar alguns conceitos básicos que tínhamos em mente durante a execução do projeto.
O conteúdo foi organizado de forma a permitir que mesmo pessoas com nenhuma ou pouca experiência em métodos ágeis, pudessem entender e tirar proveito do livro. Essa organização também permite que pessoas com mais experiência possam pular direto para o dia a dia do time e se beneficiar de outras perspectivas ao ler sobre as práticas adotadas, o que funcionou e o que não funcionou tão bem assim.
Além de mantermos esse foco durante a escrita do livro, também buscamos envolver usuários na tomada de decisões importantes: título, subtítulo, capa e cores. Nós obviamente tínhamos nossas preferências, mas entendemos que estávamos escrevendo um livro para outras pessoas e não para nós mesmos. Para saber o que essas pessoas queriam, nós literalmente perguntamos. Foram pelo menos 4 enquetes diferentes no LinkedIn, Instagram e Twitter, com centenas de respostas.
Pessoas não são recursos
“Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.”
5o princípio do Manifesto Ágil
Apesar de ter muito mais experiência como autor do que eu, o Caroli nunca pediu para revisar o que eu escrevia antes de disponibilizarmos o conteúdo. Ao invés disso, nós conversávamos sobre a ideia, ele me dava diversas dicas com base em sua experiência e confiava em mim para fazer o trabalho.
Aplicamos o mesmo princípio com a Juliana (coordenação editorial e preparação) e a Vanessa (projeto gráfico, diagramação e capa). Em vez de tentarmos dizer exatamente como elas deveriam fazer o trabalho, compartilhamos a visão e criamos um ambiente em que elas tinham liberdade para fazer o trabalho da melhor forma que acreditavam ser possível.
Ter perspectivas, habilidades e competências diferentes sendo aplicadas neste processo foi fundamental para chegarmos a um produto final de sucesso. Muito provavelmente a qualidade do produto final seria baixa se uma única pessoa tivesse determinado como tudo deveria ser.
Responder a mudanças mais que seguir um plano
Além dos princípios ágeis já mencionados aqui, também colocarmos em prática o 4o valor do Manifesto Ágil. Nós sempre trocávamos feedbacks entre nós e fazíamos mudanças em busca de maior valor para a comunidade ágil brasileira. Sem apego às nossas ideias iniciais, por melhores que elas parecessem ser.
A maior parte do conteúdo foi alterado de alguma forma desde a primeira versão do ebook. Se me perguntassem, lá no início, qual era o plano, a minha resposta seria algo bem diferente e que possivelmente não estaria fazendo o mesmo sucesso.
Além de praticarmos esse valor durante todo o processo, também colocamos em prática a essência do seguinte princípio:
“Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.”
2o princípio do Manifesto Ágil
Fizemos alterações mesmo nas últimas revisões antes de mandarmos o livro pra gráfica. Segundo o nosso plano e cronograma, isso não deveria acontecer, mas entendemos que tratavam-se de alterações relevantes e que ajudariam as pessoas a ligarem os pontos durante a leitura, ou seja, fariam toda a diferença.
Melhoria contínua
“Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.”
12o principio do Manifesto Ágil
O pilar de todo esse processo foi a busca constante pela melhoria contínua. Desde o início, procurávamos informações que nos ajudassem a identificar o que poderia melhorar e como poderíamos fazê-lo. Testamos, experimentamos, erramos, acertamos e aprendemos muito. Sempre buscando maior eficácia e fazendo os ajustes necessários para alcançá-la.
O case do livro ocorreu em 2018. Hoje, já fazemos diversas coisas de forma diferente ao trabalharmos com um time ágil, mas a essência é a mesma. Se estivéssemos começando a escrever o livro hoje, possivelmente, ele seria bem diferente. O importante é a melhoria contínua. Ao compartilhar agora nossas experiências e aprendizados atuais, podemos aprender, evoluir e vivenciar situações novas no futuro.
Adorei ler sobre o processo de elaboracao do livro. E a forma colaborativa como voces trabalharam. Fiquei curiosa em como voces passaram a visao de voces para a elaboracao da capa. Foi um briefing tradicional, uma conversa?
Obrigada, Jeanne!
Nos fizemos uma conversa bem informal no inicio. Contamos a mensagem que queríamos passar e falamos sobre o tema do livro. A partir daí, a Vanessa nos apresentou algumas opções de capa que já eram incríveis e fomos só fazendo pequenos ajustes com base nos feedbacks da comunidade, pois postamos algumas opções para votação nas redes sociais.
Posts como esse me aproxima do seu trabalho e vejo que a aplicação é vasta 😉
Parabéns pelo livro e pela vontade de compartilhar conhecimento. Que incentive ainda mais pessoas a fazerem o mesmo.
O que são histórias ratos ou elefantes? 🙂
Marlon,
Histórias ratos ou elefantes são histórias muito pequenas (ratos) ou muito grandes (elefantes).
Vi o André Suman usando animais para falar de work items e achei a ideia interessante pra ajudar o time a entender diferentes tamanhos. Você pode encontrar mais detalhes sobre isso no blog dele: https://andresuman.com/pt/upstream-kanban-picture-pt/