Se você quer realmente entender Scrum, esta literatura pode ajudar muito. Para começar, tem os Scrum Papers, que dão a introdução.
Se fez isso então já esbarrou em termos como “Emergência”, “Beira do Caos”, “Sistemas Complexos Adaptativos”, “Auto-Organização”. E se passou por esses termos e ficou por isso mesmo, pense mais uma vez: qual a vantagem de ler sem entender?
Eu também ainda não sei tudo, mas estou inteiramente dedicado a entender isso direito. Sem entender os princípios, só resta “seguir uma receita” e isso é muito pouco. Quem procura por regras ou receitas está tentando retirar a própria responsabilidade, pois se o método, o procedimento, o processo “falhar” ou não der resultados, você sempre pode cair nas desculpas “mas eu segui o método à risca, a culpa não é minha”. E isso foge completamente ao ponto; que resultado você está procurando: seguir regras ou atingir resultados?
Digo isso com “agressividade” mas certa relutância porque eu mesmo já pensei dessa forma. Enfim, depois de passar um tempo lendo mais artigos acadêmicos, neste momento estou lendo estes livros:
- Systems Thinking, Second Edition: Managing Chaos and Complexity: A Platform for Designing Business Architecture – caindo no assunto Complexidade, também saímos do pensamento clássico reducionista e determinista e temos obrigatoriamente que entender pensamento holístico de Sistemas. Pensamento em Sistemas, inclusive, já passou por vários paradigmas. Este é muito recomendado, começa descrevendo com perfeição os diferentes modelos de gerenciamento e sua evolução.
- The Essence of Chaos – Sistemas Complexos Adaptativos cai no assunto mais amplo conhecido como “Complexidade” e isso leva necessariamente ao assunto “Caos”. Eu preferia ler um livro do Ilya Prigogine, mas como estou com um Kindle, só achei disponível livros como este, de ninguém menos que Edward Lorenz, um dos “pais” do Caos.
- Surfing the Edge of Chaos: The Laws of Nature and the New Laws of Business – Sistemas, Complexidade também obrigam o entendimento de Beira do Caos.
- The Greatest Show on Earth: The Evidence for Evolution – um dos exemplos mais claros de Sistemas Complexos Adaptativos é a natureza ao nosso redor. Você precisa entender o que é a Teoria da Evolução de Darwin. A maioria “acha” que entende isso, mas cuidado, muito é folclore e muitos ainda duvidam disso. Se você ainda tem dúvidas sobre Evolução, nem comece.
Mais do que isso? Por experiência, toda vez que alguém me fala palavras como “caos”, “equilíbrio” percebo que elas estão baseadas na definição casual e não técnica delas. Primeiro, muitos acham que “caos” é simplesmente bagunça, ao totalmente indesejado. Pior ainda: acreditam que o “segredo” está em atingir equilíbrio e ficar nele, confundem a meta como sendo buscar equilíbrio. Não é bem isso.
Segundo a introdução do livro Surfing the Edge of Chaos, veja:
Equilíbrio é o precursor da morte. Quando um sistema vivo está em um estado de equilíbrio, ele é menos responsivo a mudanças acontecendo ao seu redor. Isso o coloca em risco máximo. Quando encarado por ameaças, ou quando é motivado por uma oportunidade, coisas vivas se movem em direção à Beira do Caos. Essa condição evoca altos níveis de mutação e experimentação, e soluções frescas e novas são mais comuns de serem encontradas.
Quando esta excitação se inicia, os componentes de sistemas vivos auto-organizam e novas formas e repertórios emergem do distúrbio.
Sistemas vivos não podem ser dirigidos sobre um caminho linear. Consequências não planejadas são inevitáveis. O desafio é criar distúrbio de uma maneira que faz se aproximar do resultado desejado.
Esta, é uma definição tanto da evolução biológica de seres vivos, mas, se você já leu pelo menos o básico de Scrum e Agile, também é uma forma de descrever o processo Ágil. Releia os Princípios do Manifesto Ágil e vai encontrar textos similares.
Quanto a Sistemas Complexos Adaptativos:
Um sistema complexo adaptativo é formalmente definido como um sistema de agentes independentes que podem agir em paralelo, desenvolvem “modelos” sobre como as coisas funcionam em seus ambientes e, mais importante, refinam esses modelos através de aprendizado e adaptação. O sistema imunológico humano é um sistema complexo adaptativo. Assim também é uma floresta tropical, uma colônia de formigas e um business.
Existe vasta literatura. Procure na Amazon por termos como “Complexity”, “Edge of Chaos”, “Systems Thinking” e verá que faz décadas que pesquisadores das mais diferentes áreas e indústrias vem refinando esse corpo de conhecimento. Técnicas como o Toyota Production System/Lean, Six Sigma, Scrum, Theory of Constraints e outros são todos derivados dessa escola de pensamento.
Da minha lista anterior, reforço a necessidade de leituras como:
- The Machine that Changed the World: The Story of Lean Production – entenda como surgiu o processo Lean na Toyota
- The Goal – engenharia de processos, controle de custos, sem entender TOC é uma futilidade
- The End of Management, and the Rise of Organizational Democracy – um resumo de todos esses assuntos e talvez uma introdução provocativa a todo o resto.
Mais preocupantes: técnicas como Lean, TOC, Six Sigma e derivados como técnicas de Kanban, todas são termos que muitos usam de forma errada hoje em dia. Elas foram todas criadas e refinadas em Engenharia de Produção. Estamos sempre falando em “linha de produção”, “manufatura” de bens de consumo materiais, coisas “físicas”. Agora, em Agile, estamos falando de “Software”, algo abstrato e sem paralelo no mundo físico, portanto, sem nenhuma das mesmas referências.
É impossível migrar ipsis literis quaisquer das técnicas de Engenharia de Produção. Não funciona de forma tão simples assim. Um Sprint de Scrum é uma adaptação consciente do Sutherland e Schwaber, sabendo dessa limitação e tentando uma aproximação no mundo abstrato. Mas isso não é óbvio e nem trivial de entender, eu mesmo ainda não entendi completamente e acredito que a maioria das pessoas do mundo ágil não parou para estudar essa diferença.
Muito cuidado: o assunto “Gerenciamento” é muito mais do que mera “experiência” ou “bom senso”. Assim como um bom programador deveria ler muito e pesquisar muito para melhorar sua técnica, assim também deve um gerente. E aqui estou dizendo isso para mim mesmo.