No artigo “Brief, Sense & Design: A contextualização da agilidade nos negócios”, além de apresentar as etapas do BUILD (BUsiness agILity Design) eu fiz uma introdução ao conceito de scaffolding diferenciando-o do trabalho com frameworks:
“No BUILD, trabalhamos com scaffolds (andaimes) ao invés de frameworks (estruturas), considerando que a base da estratégia para sua agilidade organizacional deva ser o seu negócio e não o meu framework preferido. Ou seja, partimos do seu contexto e não da nossa prática.
Os trabalhos de Ann M. Pendleton-Jullian e John Seely Brown, têm sido uma importante referência para a forma com que organizamos o BUILD, e, certamente, foi através dos seus trabalhamos que passamos a entender a importância de nos distanciarmos do conceito de framework quando trabalhando na agilidade dos negócios, mesmo reconhecendo o seu valor quando em situações mais concretas, como por exemplo no desenvolvimento de software.
Sobre frameworks
Frameworks são estruturas permanentes desenhadas para suportar ou cercar algo. Eles dão forma para tudo que vêm depois, servindo portanto como base central da solução a ser construída. Ou seja, o framework dita e é parte irremovível da solução.
No mundo do desenvolvimento de software trabalhamos bastante com frameworks, tanto nas práticas de construção (análise, programação, testagem) como nos processos de gestão. Isso faz bastante sentido, visto que tais frameworks são construídos com um problema e contexto claro em mente.
Por exemplo, Rails é um framework para desenvolvimento web que nasceu com um contexto claro: ajudar desenvolvedores a terem mais agilidade, produtividade e leveza no desenvolvimento de soluções web. Ele atinge tal objetivo ao eliminar o esforço necessário na parte tediosa e repetitiva desse trabalho, o que faz com que o desenvolvedor foque na parte lógica.
No entanto, o Rails irá dar forma a cada linha de código escrita, determinará até onde tecnicamente o desenvolvedor pode ou não pode ir e, certamente, todo código gerado pelo Rails fará parte da solução final.
Se mudarmos o contexto para a gestão de desenvolvimento de produtos, o mesmo valeria para Scrum, por exemplo; e ao navegarmos para o universo literário da escrita criativa encontraríamos dezenas de frameworks à nossa disposição, todos propondo uma estrutura central para a escrita do seu próximo livro.
Framework é uma ótima alternativa quando temos um contexto claramente definido no qual se possa estabelecer uma solução escalável e repetível.
Frameworks para Business Agility
No entanto, como mencionei em “Não existe business sem agility”, quando o assunto é agilidade nos negócios não temos como definir uma estrutura livre de contexto, visto que o negócio em si é o contexto. Como posso definir qual deve ser a base para a sua agilidade se não conheço as características e objetivos do seu negócio?
Utilizar a estratégia de framework para agilidade nos negócios exige o discurso de “terra arrasada”, visto que para utiliza-la precisaríamos eliminar a “velha” forma de trabalhar, ou seja “implodir o prédio”, para então implantar a “nova” forma de trabalhar, ou seja “construir o novo prédio”.
Novamente, isso faz muito sentido quando temos contexto e solução repetíveis. Mas e quando o contexto é diferente? E em negócios quase sempre ele é diferente. E quando o que foi solução para uma empresa tem potencial para arruinar o negócio de outra? Será que vale a pena o discurso de “terra arrasada” para o que trouxe o seu negócio até aqui?
No BUILD utilizamos cidade como uma metáfora para as organizações. Nessa linha, quem visita cidades europeias aprende que, ao invés de demolirem ou descaracterizarem os prédios antigos, eles os modernizam — mantendo suas características históricas e até culturais. Ou seja, eles aproveitam os novos conhecimentos e tecnologias para melhorar, e não eliminar, aquilo que os define.
Sobre scaffolding
Scaffold, ou “andaime” em um tradução livre para o português, é uma estrutura externa e temporária para dar suporte a algo. Essa estrutura não é primária e não fará parte do resultado final, devendo ser removida assim que o objetivo de um trabalho for alcançado.
Na arquitetura e engenharia, tais andaimes são úteis para dar acesso aos trabalhadores e seus materiais a alguns lugares de difícil acesso, ou para sustentar uma parte da construção enquanto esta não possui sustentação própria.
Na imagem de destaque que utilizei neste post, temos o famoso Big Ben em Londres circundado por andaimes, pois passa por um período de manutenção. Tais andaimes ficarão ali apenas durante este período, e não passarão a fazer parte permanente do Palácio de Westminster. Perceba que neste trabalho, o foco está no Big Ben, e não nos andaimes.
Na mesma linha, entendemos que quando o assunto é Business Agility, o que deve estar no centro é o negócio da sua empresa e não o framework preferido de um consultor, afinal, assim como o Big Ben, sua empresa precisa de reformas e não de um implosão.
Os andaimes do BUILD
Quando utilizamos o BUILD em nossos clientes, o foco é a construção ou melhoria de um modelo de agilidade para os negócios daquela empresa, levando em consideração todo o contexto que se apresenta para nós.
Se você perguntar para as pessoas em uma dessas empresas “O que vocês utilizam para business agility?”, a resposta será “o nosso próprio modelo” e não “BUILD”. Isso justamente pelo fato de trabalharmos com scaffolds, e não com frameworks.
Lógico, ao longo de um projeto com BUILD, todos nossos “andaimes” estarão lá, e serão essenciais para construirmos o modelo do cliente. No entanto, uma vez o modelo estando pronto, tudo que faz parte do BUILD é removido, e o modelo construído passa a conduzir a agilidade nos negócios daquela empresa.
Um desses exemplos é o que aconteceu na Opus Software, uma empresa que a partir do trabalho com o BUILD conseguiu construir seu próprio modelo e avançar com agilidade de forma estratégica por toda a empresa — vale a pena ler esta história completa.
