seis modelos propostos tem uma teoria bem fundada, mas sao pouco praticos. Para a Concrete Solutions, o que serviu de inspiracao foi o modelo do Spotify, que explicaremos em detalhes a seguir.HistoricoQuando iniciamos, nossa pratica era baseada em equipes de engenharia que respondiam diretamente a um socio. Neste experimento, o papel de Product Owner (PO) ficava a cargo dos nossos clientes. Ofereciamos uma equipe multidisciplinar e o cliente coordenava essa equipe e o produto a ser desenvolvido. Entretanto, a falta de uma estrutura de produto formal na maior parte das empresas acabou se tornando um desafio, porque sobrecarregava o socio que precisava administrar inumeros backlogs, alem de desempenhar o papel de Scrum Master. Neste periodo, passamos tambem a ter mais contato com algumas referencias de produto e chegamos a conclusao de que a nossa funcao e a gestao agil de produtos, nao apenas a organizacao de equipes multidisciplinares.Era a hora de adotar o papel de PO e trabalhar com ele dentro da equipe. Passamos, entao, da pratica de engenharia (experimento 1) a uma pratica de produto (experimento 2), como exposto na figura a seguir. O modelo funcionou bem ate determinado numero de pessoas. Com o aumento da equipe e o surgimento novos projetos, as figuras dos POs e dos socios ficaram sobrecarregadas com tantas referencias e com a necessidade de apoiar a melhoria continuada das pessoas e das equipes e tivemos que procurar uma forma de escalar a estrutura ate chegarmos no modelo do Spotify.Em linhas gerais, o experimento 1 mostrou uma escalabilidade de celulas de ate 20 pessoas e o experimento 2 de ate 50 pessoas. Uma variavel que tambem foi modificada no segundo experimento foi a quase totalidade de equipes com integracao e publicacao continuas e o uso extensivo de testes automatizados. Essa melhoria de fluxo e diminuicao do lote tambem permitiu que a estrutura do experimento 2 escalasse mais.Visao GeralAs celulas base da Concrete atualmente sao quatro praticas, mostradas na figura a seguir e determinadas por dominio tecnologico ou criterio geografico, uma vez que temos escritorio no Rio e em Sao Paulo. Sao elas:Cloud;Web/API Sao Paulo;Web/API Rio e Mobile.A ideia e que cada uma dessas celulas tenha uma area de produto e uma area de engenharia. Os integrantes de cada celula nao precisam necessariamente estar no mesmo lugar, sao razoavelmente autoorganizados e autogeridos e usam as mesmas tecnologias.No contexto atual da Concrete, todas as celulas tem pelo menos um socio responsavel pela area de produto e/ou engenharia. Note que a celula de "Cloud" nao e dividida e isso acontece porque a computacao na nuvem nao gera um produto, mas ajuda no desenvolvimento dele.Equipe baseA Concrete Solutions vende equipes multidisciplinares que tem o objetivo de desenvolver e evoluir um produto para um cliente. Para que possamos ser efetivos nesse posicionamento, temos que garantir que um conjunto minimo de papeis esteja sempre incluido na equipe. Essa equipe pode sofrer algumas variacoes dependendo da necessidade ou nao de desenvolvimento de uma API ou de tecnologias envolvidas. A seguir, temos um exemplo de equipe de desenvolvimento movel padrao. Dentro do possivel, tentamos manter