Toda organização que esteja de fato engajada e, mais do que isso, tenha compreendido a proposta central da agilidade (é triste constatar, mas a maioria ainda não captou a mensagem), deveria concentrar grande parte de seus esforços e investimentos, na capacitação do capital humano inserido no Time de Desenvolvimento, provendo-lhes os meios e as ferramentas necessárias e não obstante ensinando-lhes as técnicas e as práticas que proporcionem a efetiva construção de software com alto valor de negócio, sem desrespeitar os dois mandamentos principais da “Agileland”: sustentabilidade e qualidade.
Uma organização que não esteja minimamente preocupada em garantir a integridade destes dois mandamentos fundamentais e, por outro lado, decidem concentrar grande parte de sua energia e de seus esforços “sofisticando” os modelos de gestão existentes… cedo ou tarde terá um encontro marcado com alguns dos velhos e conhecidos problemas crônicos do sub-mundo do desenvolvimento de software, quais sejam: o aumento do custo total de propriedade (TCO) e a diminuição dramática da satisfação do cliente e, por consequência, de suas receitas.
Neste sentido, com o intento de não ficar apenas no discurso, resolvi avançar (em tempo; assim espero) na sequência de posts iniciada pelo post Os cinco estágios do Product Owner (se ainda não leu, deixo aqui o convite) para que assim, caríssimo leitor, você possa entender os estágios pelos quais um Time de Desenvolvimento geralmente passa, além de compreender algumas características encontradas em cada estágio. Avancemos!
Identificando os estágios do Time de Desenvolvimento
Os estágios a seguir são aplicáveis tanto para o contexto de um Time Scrum (PO, SM e Time de Desenvolvimento) quanto apenas para o contexto de um Time de Desenvolvimento. Contudo, como a proposta inicial deste post é se restringir às fronteiras do Time de Desenvolvimento, com as devida vênias, concentrarei seu escopo nos aspectos inerentes a este papel.
Um outro ponto importante a se considerar é que, qualquer organização que tenha como objetivo central melhorar continuamente a satisfação de seus clientes (customer satisfaction índex), de modo a transformar satisfação em receita, deveria estar mandatada basicamente a perseguir o equilíbrio entre dois pilares, isto é: 1) a melhoria sistemática de seus serviços por intermédio de modelos e métodos e 2) o aperfeiçoamento constante do nível de capacitação do capital humano, garantindo desta forma máxima excelência dos serviços prestados.
Formed
Pra quem já ouviu falar na Escada de Tuckman, certamente terá uma maior compreensão deste e do próximo estágio. Neste estágio, pelo qual todo Time obrigatoriamente passa, membros geralmente compartilham suas experiências, as tecnologias e as ferramentas que conhecem e dominam e aproveitam para identificar coisas em comum. Muitas vezes neste estágio, membros mais seniores esclarecem dúvidas e apresentam os desafios do produto ou do projeto. É válido ressaltar ainda que times que estejam fisicamente distribuídos, não estão isentos de passar por este estágio.
Uma técnica bacana para se aplicar neste estágio, e não perder a oportunidade de inspecionar os skills do Time de Desenvolvimento, é “rodar” a Matriz de Competência. Sem me estender, esta técnica visa mapear tudo o que um Time de Desenvolvimento multidisciplinar precisa conhecer e/ou dominar, para construir incrementos de software, versus o nível de conhecimento que cada membro possui ante aos itens mapeados.
Storming
Superado o estágio da formação; o couro geralmente começa a comer! E aqui gente boa, vai a primeira dica amizade: se por ventura como um membro de um Time, como um SM, Agile Coach, Gestor ou seja lá o que for… você perceber que o estágio da formação ficou pra trás e não há o menor sinal de conflitos no intramuros, convém ficar de anteninha ligada porque é bem provável que a transparência esteja apenas “ouvindo a conversa” e a partir daqui, se nada mudar, espere por problemas que certamente tirarão o seu sono.
O importante é saber que neste estágio mimimis aqui e acolá são normais e fazem parte e, se a coisa começar a descambar para a pancadaria (no sentido figurado), tente ao menos manter o mínimo de respeito sem abrir mão de capturar as oportunidades de melhoria.
A boa notícia é que superar este estágio é apenas uma questão de tempo e de maturidade… e a má notícia é que este estágio aparecerá com a mesma frequência com que a organização resolve alterar organicamente a formação dos times e/ou se o turnover for muito alto.
Co-operative
Neste estágio Times de Desenvolvimento começam a experimentar os resultados positivos de um amadurecimento, ainda em fase inicial. É neste estágio que os membros cooperam entre si e esta mútua cooperação, ainda que restrita ao time, resulta geralmente em alguns comportamentos positivos como por exemplo a preocupação em escrever códigos que sejam de fácil entendimento por todos, a busca incessante pela simplicidade nas soluções propostas — fortalecendo assim a sustentabilidade (de médio e longo prazo) — e o desejo quase que incontrolável (risos) de não se produzir tantos débitos técnicos.
Neste estágio o melhor a ser feito pelos, digamos, porta-vozes da gestão sênior seria: 1) apoiar a maioria das decisões tomadas pelo Time de Desenvolvimento — estimulando desta maneira atos de liderança que são fundamentais para evolução de qualquer organização — mesmo que, sob o “olhar de quem está fora”, elas pareçam estar erradas e 2) perseguir melhorias constantes nas métricas relacionadas ao valor atual (current value), como por exemplo a satisfação dos membros do Time (employee satisfaction).
Em resumo, Times neste estágio passam a se preocupar mais com o todo e não simplesmente em fazer “funcionar em suas máquinas”. Além disso, é bem comum ver neste estágio a utilização de práticas como o pair programming (XP) e o uso do TDD.
Ps.: A maioria dos Times que tive a felicidade de trabalhar transitavam na maior parte do tempo entre este e próximo estágio. Sou grato por isso!
Commited
Costumo dizer que Times de Desenvolvimento que navegam nas águas calmas (as vezes nem tão calmas assim) deste estágio, passam a se comprometer basicamente com os objetivos e os interesses que estão “dá porta pra fora”. O que quero dizer com isso é que os Times neste estágio já fizeram toda a lição de casa, ou seja, resolveram, se não todos, grande parte do problemas que ocorrem “da porta pra dentro”, como por exemplo dominar muito bem as práticas dos dois anéis mais ao centro do “Círculo da Vida” do XP e entender exatamente o valor e a responsabilidade que giram em torno de cada commit em produção.
Em outras palavras… Times neste estágio tendem a optar por releases frequentes com alto valor de negócio, possuem sólidas habilidades para, rapidamente, esboçar uma hipótese, construir e entregar esta hipótese (produto) aos usuários finais — privilegiando assim o binômio fail fast X learn faster — e ainda são capazes, como consequência dos altos padrões de qualidade de código adotados, de detectar e corrigir defeitos num curto espaço de tempo melhorando assim a eficiência “do todo” e cultivando um time-to-market aceitável.
Ademais, senhoras e senhores… Times neste estágio costumam começar a coletar os reais benefícios da famigerada auto-organização.
Collaborative
Para descrever este último estágio tomo a liberdade de iniciar afirmando categoricamente, e sem medo de qualquer tipo de censura, que Times de Desenvolvimento que metem o pé na porta e “caem pra dentro” do estágio da colaboração experimentarão a tão prometida (e comercializada à preços de pai para filho por alguns vendilhões de ilusão) ALTA PERFORMANCE.
Times “colaborativos” geralmente ganham “vida própria”; por esta razão conseguem neutralizar eventuais barreiras, muitas vezes difusas, da cultura organizacional a qual estão inseridos. Multidisciplinaridade e auto-organização são características que estão no DNA de Times em estágio de colaboração. Um exemplo disso é que os Times neste estágio são capazes de facilmente aprender com uso do produto e de interpretar desejos e necessidades dos clientes e usuários, independentemente dos papéis que se propõe a promover a interlocução.
Trocando em miúdos… o estágio da colaboração é a “auto-suficiência” de um Time que emerge a partir da relação quase que simbiótica entre desenvolvedores, clientes e usuários. (Associação Protetora dos Papéis, me julgue!)
Em adicional, Times neste estágio se organizam em torno de todo o trabalho que precisa ser feito, se auto-gerenciam promovendo alta visibilidade… e todo o ciclo de vida do desenvolvimento passa a estar assentado em práticas globais que garantam SUSTENTABILIDADE e QUALIDADE.
FINALMENTE paciente leitor e aqui concluo… enquanto as organizações não compreenderem, a partir de expansivas auto-reflexões (de preferência), que para conquistar Agilidade ou o tal Business Agility (a nova moda do momento) é imprescindível estruturar os mecanismos necessários para “desengargalar” o fluxo que conecta demanda e delivery — e para isso acontecer é fundamental identificar em que estágio os Times se encontram e prover os caminhos para que eles evoluam — continuaremos ouvindo notícias de iniciativas e “transformações ágeis” miseravelmente fracassadas.
Gostou do artigo? Conheça o curso completo clicando aqui.
Artigo escrito por Pedro Paulo Oliveira, professor do LIT, originalmente publicado aqui.
