Ágil na Red Hat

Uma história de como a Red Hat adotou o ágil contada através do novo projeto de conversão da equipe Red Hat Mobile

Mudar de uma abordagem tradicional em cascata, com papéis e fases predefinidos para um modelo de equipe proprietária do produto é uma experiência onerosa para a maioria. No entanto, é uma experiência que mais equipes e produtos encontrarão conforme o movimento em direção à computação em nuvem ganha impulso. Publicações na nuvem, incorporadas no modelo SaaS (Software as a Service) de construir e consumir serviços estão se tornando mais acessíveis e mais desejáveis da perspectiva do cliente, em que a necessidade de responder rapidamente às mudanças é um valor central de negócios. A Red Hat está fazendo essa transição no momento, assim como clientes e consumidores se movem de um modelo autogerenciado de soluções locais para o poder e flexibilidade da nuvem.

A resistência natural a perder propriedade técnica, combinada com o ritmo rápido de desenvolvimento, e prazos incrementais curtos, é uma das principais razões do porquê as conversões ágeis falham em uma empresa. Em 2014, a Red Hat adquiriu a FeedHenry, uma plataforma móvel baseada em SaaS que se juntou a uma equipe de desenvolvimento experiente em SaaS e uma equipe de qualidade experiente na cadência do modelo em cascata. Este artigo é a história de uma jornada da conversão bem-sucedida que tivemos, e as curvas de aprendizado que enfrentamos conforme navegávamos na única e nova casa que a Red Hat nos proporcionou. Este artigo também pontua a jornada ágil na Red Hat como um todo conforme essa história vai sendo replicada com sucesso pela suíte de produtos que a Red Hat oferece. Do sistema operacional ao servidor de aplicação e às diversas camadas entre eles, a Red Hat é uma verdadeira organização ágil e vem fazendo essa transição do jeito open source.

Uma aquisição

A FeedHenry era uma startup de Waterford, Irlanda, que surgiu como um produto bem maduro de SaaS no mercado mobile. No final de 2014 eles foram adquiridos pela Red Hat. A equipe ex-FeedHenry estava bem acostumada a trabalhar de uma maneira muito rápida e poderia ter lançado várias versões por semana, disponibilizando funcionalidades rapidamente aos clientes e operando naquela mentalidade frenética de startup em que toda hora e todo dia importa.

A aquisição pela Red Hat foi um sonho para a equipe ex-FeedHenry e os meses iniciais de adaptação da equipe foram similares ao padrão de trabalho anterior, pois ainda tinham requisitos de clientes e um roteiro a seguir. Enquanto isso, a Red Hat começou a colocar em prática os blocos de construção fundamentais que formaram sua reputação. Diversas equipes de suporte foram introduzidas para auxiliar a equipe FeedHenry a evoluir o seu produto e a ajudar na transição para a Red Hat Mobile Application Platform (RHMAP). Isso incluiu a introdução de especialistas dedicados em segurança - que protegiam as vulnerabilidades dos clientes Red Hat, um gerente de programação - que atuava como coordenador e integrador, uma equipe de internacionalização - que traduzia a plataforma para japonês, e a junção da equipe Red Hat mobile existente (projeto Aerogear) - que liderava as mudanças com ferramentas mobile open source, tudo isso dentro da grande equipe RHMAP.

A maior aquisição foi o acesso a uma equipe de QE (Quality Engineering) mais rigorosa - que olhou tudo sobre qualidade, desde as ferramentas,às suítes de testes até o início de liberação. A equipe de QE da Red Hat é diferente de uma equipe regular de QA (Quality Assurance) que outras empresas têm. A equipe de QE está muito mais focada na criação e manutenção de suítes de testes, a automação da execução dos testes e a qualidade de questões vitais de um produto como um todo. Uma equipe de QA tradicional, por outro lado, tem uma validação mais suave, geralmente seguindo um conjunto de passos para verificar que o erro foi corrigido e que o problema esteja realmente resolvido, ou um conjunto de passos para mostrar a nova funcionalidade incluída. O valor real, de uma perspectiva de qualidade, está no lado das equipes de QE, que trazem maior valor e segurança. Isso não diminui a importância dos testes de QA em funcionalidades. A FeedHenry tinha agora uma equipe de qualidade mais rigorosa e rígida, que só beneficiaria nosso produto e nossos clientes.

Essa foi uma grande oportunidade de aprendizado para ambos os lados. A equipe ex-FeedHenry trouxe muito conhecimento sobre como uma plataforma SaaS deveria rodar. Isso incluiu um profundo conhecimento de mobile, os conceitos, a linguagem e ecossistema do Node.js, bem como os papéis críticos de devops e uma NOC (Networks Operation Center), que foram de alguma forma estranhos às soluções tipicamente auto-gerenciadas ou nos padrões que a Red Hat historicamente tinha. Esse cenário levou ao primeiro ano como sendo de troca de informações, com as equipes de suporte ganhando habilidades no mundo mobile, da linguagem aos processo e ajudando a estabelecer uma estrutura de trabalho de sucesso. Por outro lado, tínhamos a equipe FeedHenry se ajustando a uma vida de empresa open-source com uma vasta rede de apoio disponível. Uma das mudanças foi abandonar o controle de áreas que eles, como startup, teriam de se habilitar e gerenciar. Agora na Red Hat, equipes dedicadas estavam aptas a tomar controle e permitir que a equipe FeedHenry focasse em suas forças. Ter a chance de se tornar open source e compartilhar seu conhecimento de domínio foi um grande acontecimento para a equipe. Eles abraçaram essa mudança ao mesmo tempo lutavam para deixar a mentalidade de startup para trás. Esse foi um clássico problema de conversão no qual a Red Hat já estava acostumada, e a ajuda que a equipe FeedHenry recebeu foi surpreendente.

A Transição para o Ágil

Nos pegamos fazendo essa pergunta o tempo todo: como fizemos a transição para o ágil? A resposta é: lentamente! Infelizmente não existe um botão mágico, ou um mapa pré-definido de transição. A jornada, por si mesma, se torna mais clara conforme navegamos sobre cada obstáculo, porém o ponto de início da jornada é a parte mais vital. Esse é o ponto no tempo em que você sabe que a transição é necessária e, mais importante, é o ponto de referência para futuramente olhar pra trás e ver o quão longe chegou.

Para a Red Hat Mobile (RHMAP), 12 meses depois da aquisição a lua de mel estava bem e finalizada. As equipes de suporte na Red Hat, primeiramente dirigidas pela equipe de QE, se tornaram íntimas da plataforma FeedHenry e lançaram pequenas versões da RHMAP para se sentirem confortáveis com o processo. O primeiro grande lançamento sob a direção da Red Hat, nossa fabulosa versão 3.6, foi estabelecido para ficar no ciclo de QE por 20 dias. Levou mais de três meses para colocar aquela versão em forma. A codificação foi contínua durante esse ciclo, conforme os requisitos mudavam e a equipe como um todo achava difícil dizer não ao seus clientes mais fiéis. A equipe de QE estava encontrando problemas e como estavam trabalhando com o desenvolvimento em cascata, o custo de alteração era alto e a implementação de correções lenta, devido ao tempo que se passava e às mudanças de contexto necessárias para abordar um erro em um pedaço de funcionalidade desenvolvido muitas semanas antes. A equipe já tinha problemas o suficiente. Agora tínhamos nosso ponto de referência e a motivação correta para ditar uma mudança positiva. Entendemos que tínhamos que lançar versões rapidamente e a necessidade de rigorosos ciclos de QE como parte do orgulho da Red Hat sobre a qualidade de seus produtos. Fundamentalmente, entre as equipes de engenharia e QE, entendemos como ligar as necessidades com as expectativas enquanto lutávamos para nos mover em direção ao ágil. Eles precisavam de ajuda e foi um momento pessoal oportuno para o Griffin, que se juntou à equipe para orientar a transição. Embora as expectativas fossem bem definidas de que a conversão completa seria um projeto de 12 meses.

Tomamos a conversão por dois ângulos: da equipe e do gerenciamento.

A conversão da equipe

As primeiras seis semanas foram usadas em iniciação com o produto e ouvindo as histórias de conflitos que causaram mais turbulência e sofrimento nas versões mais recentes. Conseguimos recolher bastante conhecimento, recomendações e reclamações, e todos tinham pontos válidos, a Red Hat é construída sobre a meritocracia, em que cada voz tem força igual e as melhores ideias prevalecem! Fiz algumas anotações e observações, como alguém de fora da Red Hat, e no espírito típico de qualquer equipe ou produto iniciando uma jornada no ágil, fiz pequenas alterações e comecei com uma única equipe (de um total de sete equipes). A equipe já estava acostumada a seguir uma interpretação rasa do Scrum, então paramos nesse ponto, mas começamos a cumprir as cerimônias Scrum, e conscientizar as pessoas do valor que essas cerimônias carregam. Introduzimos uma definição de pronto (definition of done) e ajudamos a ligar as necessidades com as expectativas entre as equipes de QE e engenharia sobre o trabalho de QA (Quality Assurance). Esse foi o momento pivô, em que as equipes perceberam que seus trabalhos não podem ser simplesmente passados para a frente. A equipe de QE trouxe grande valor ensinando aos outros sobre processos de qualidade e investiu bastante tempo construindo conjuntos de testes de regressão e ferramentas que ajudam a proteger o produto. O tempo consumido e o trabalho geralmente tedioso de realizar testes manuais de QA passaram a garantir que o trabalho realizado realmente cumpra os requisitos definidos e distribuídos entre as equipes. O peso da qualidade é dividido entre todos, e esse foi o verdadeiro momento de acender a lâmpada em nossa jornada. Nas semanas e meses seguintes vimos grandes melhorias na velocidade de desenvolvimento de funcionalidades e felicidade geral da equipe, que ajudou no patrocínio gerencial. Isso nos permitiu acelerar nossos planos, e que mais equipes embarcassem até que todas as nossas sete equipes de QE e engenharia estivessem seguindo uma metodologia ágil.

A Conversão Gerencial

Geralmente falamos de pessoas como sendo a parte mais difícil de qualquer transformação. Lidar com hardware e software é fácil, mas com "peopleware" precisamos tomar mais cuidado. Isso se torna ainda mais verdadeiro quando lidamos com pessoas em níveis gerenciais e seniores, muitas das quais esculpiram suas carreiras baseadas em decisões e processos que terão de ser desfeitas numa conversão ágil! Com isso em mente, a mudança para uma metodologia ágil precisa ser aceita em todos os níveis; o gerenciamento não pode simplesmente ordenar essa mudança, tampouco ser uma abordagem de baixo para cima. Quando vendemos ágil para ambos: gerentes e engenheiros, temos de ser transparentes e abertos sobre nossas intenções. Podemos explicar todos os benefícios, mas igualmente temos de expor o fato de que haverá muito desconforto nessa jornada. Tivemos de encorajar a equipe a falhar (com razão!!) e aprender com isso. Na essência, tivemos de refazer as expectativas e permitir que a gerência e a equipe encontrassem seu próprio equilíbrio. Felizmente, a responsabilidade é um dos valores fundamentais na Red Hat e a equipe rapidamente percebeu que podia orientar uma sprint para as pedras ou para a segurança baseados em suas próprias decisões. Nosso caminho para as equipes auto gerenciáveis foi construído mais facilmente por essa virtude e pelo estilo de gerenciamento incorporado na Red Hat. Somos gerentes de pessoas, e na Red Hat isso carrega muito peso e expectativa. Temos naturalmente diversas ocasiões em que ficamos cara a cara com as equipes e temos oportunidades de orientação, mentoria e coaching como parte do nosso dia a dia. Da perspectiva de um agile coach, é um trabalho dos sonhos. Vemos mudanças positivas reais e trabalhamos próximo às equipes e indivíduos, e nosso estilo gerencial e interações irradiam para nossos pares, gerentes, e para cima, nos níveis executivos. Temos total apoio do gerenciamento para essa jornada e nossos sucessos como uma equipe ágil de SaaS permitiu a proliferação de nossos pensamentos e processos para uma iniciativa muito mais extensa da Red Hat. As pequenas mudanças e pequenos passos estão se tornando uma revolução ágil muito maior na Red Hat, uma revolução da qual temos orgulho de termos atuado em uma pequena parte.

Ágil Acelerado

Doze meses depois de introduzido o ágil, todas as nossas equipes da Red Hat Mobile estavam seguindo um estilo de metodologia ágil, com a maioria das equipes rodando um scrum modificado e outras, kanban. Isso não significou que a transição estava completa; ajustes eram necessários. Depois de um período inicial de implementação ágil, conduzimos uma retrospectiva muito mais rigorosa de nossa jornada, tendo nos aniversários a tendência de serem bons pontos de pivô para essa tarefa. Nossas buscas nos levaram a questionar algumas de nossas abordagens, e a focar nossos esforços em melhorar diversas áreas. Implementamos uma variação de scrum escalado para garantir alinhamento, conforme as equipes realizavam melhorias, implementavam funcionalidades e faziam correções em nossas versões principais. Isso nos deu um controle muito melhor sobre nossas versões. O limite das sprints foi definido para as quartas ao invés da tradicional sexta-feira. Percebemos que muitos membros das equipes saiam cedo às sextas, principalmente em feriados, e isso afetou negativamente os eventos scrum com base em um fim de sprint. Foram adotadas sprints de três semanas para lidar mais facilmente com influências externas, faltas inesperadas, reuniões externas e nos tornar mais reativos às necessidades de nossos clientes. Do ponto de vista semanal, vimos um aumento na velocidade do desenvolvimento.

Agora que tínhamos alcançado um nível de maturidade na transição para o ágil em todas as sete equipes, procuramos tentar essa transição em pequenas equipes dinâmicas. Nos movemos lentamente para fora do conceito de equipes estáticas, que teriam o mínimo de rotatividade por causa de habilidades bem enraizadas e de requisitos específicos. Com o passar do tempo, quebramos os silos de informação e habilidades e tornamos as equipes multifuncionais para permitir uma visão mais holística na composição das equipes. Começamos a juntar as habilidades certas com os trabalhos certos, e apesar das dores de cabeça com o tempo de quando começar e parar um trabalho, começamos a enxergar o verdadeiro potencial das equipes. As funcionalidades eram entregues rapidamente, a equipe estava mais engajada e mais reativa aos clientes do que nunca. Atingimos os objetivos em nosso horizonte e nossos pequenos ajustes se espalharam com o tempo, ajudando as equipes na transição de uma variação do ágil para realmente no ágil tanto em pensamento como em ação. A jornada nunca está completa; nosso objetivo no horizonte se estendeu novamente e sempre nos desafia a nos adaptar e a evoluir.

Lições Aprendidas

Dizer apenas que aprendemos não é suficiente, então vamos tentar focar no que aprendemos em três áreas.

Quebrar as conotações negativas do termo ágil. Muito da dor que encontramos foi causada por experiências negativas no passado de pessoas que trabalharam em empresas que tentaram a transição ágil e falharam. Eles tentaram mudar muito rápido e depois de um treinamento de apenas um dia esperavam que as equipes se transformassem e melhorassem a performance. O ágil se tornou mais uma forma de controle do time, então minhas semanas iniciais foram usadas em conversas cara a cara e retrospectivas com cada membro da equipe para tentar entender suas experiências e negatividade sobre trabalhar de maneira ágil.

As pessoas são o coração do que você faz. Podemos ter toda a tecnologia e processos do mundo, mas até termos as pessoas certas com a atitude correta, não temos nada. Na transição para o ágil precisamos de pessoas que se auto-gerenciam, inovadoras, de mente aberta, capazes de serem parte de um time e o mais importante, terem a capacidade de comunicar. Na Red Hat, colocamos uma grande ênfase nas pessoas; é nossa filosofia fundamental e algo do qual nos orgulhamos. Como um coach ou facilitador ágil, é imperativo que eu consiga comunicar no mesmo nível com os membros de todas as equipes interconectadas. O que isso significou para a transição ágil foi que tivemos de ser capazes de dar e receber feedbacks, tanto positivos quanto negativos. Precisamos da habilidade de explicar racionalmente e sustentar nossas decisões, e aceitar quando erramos. Falhamos como facilitadores diversas vezes, e nossa reação quando isso acontece é o mais importante para a saúde da equipe e para o bem maior do projeto de transição. Definir o tom correto, mostrar respeito, e nunca ordenar e ouvir deve ser o mantra a ser adotado.

A terceira área em que aprendemos é a importância de um grupo de suporte. Tivemos sorte de encontrar um grupo de agile coach na Red Hat. Isso possibilitou um lugar seguro para conversar, trocar experiências, problemas, e compartilhar meu próprio conhecimento. O valor de um grupo de pares foi enorme para mim e me deu material adicional e inspiração que pude levar às equipes. A FeedHenry estava há 12 meses em sua jornada na Red Hat, isso nos permitiu lidar com algumas nuances de trabalhar e viver no mundo open source: o desafio da comunidade e expectativas dos produtos, a mentalidade dos desenvolvedores open source, a interconexão do ecossistema Red Hat. Não teríamos alcançado isso sem ter um grupo de pares forte e abertos para nos conectar. Eu encorajo qualquer defensor do ágil a buscar um meetup (ou iniciar um!) ou ir a grandes conferências como o Agile Cambridge onde podemos nos encontrar e nos conectarmos e trazermos algo novo para nossas equipes. A conversão ágil é tanto uma conversão e uma jornada para você como pessoa quanto é para a equipe ou o produto que traz consigo. Encontrar produtos com ideias semelhantes, empresas ou equipes que são similares em estilo realmente ajudará você e sua equipe a crescerem na tarefa que têm em mãos.

Uma palavra sobre a cultura e o mundo remoto em que vivemos

A cultura é uma variável que mais e mais empresas devem se preocupar quando entram em uma jornada ágil. Culturas diferentes podem e vão ditar as interações assim como os comportamentos da equipe. Pessoas de diferentes experiências ou culturas terão diferentes perspectivas, e essas perspectivas podem geralmente se intensificar quando os membros da equipe não estão co-alocados. A Red Hat tem como base uma cultura remota e tem crescido com indivíduos talentosos espalhados ao redor do globo. Metade da nossa equipe está co-alocada e a outra metade distribuída em fuso horários amigáveis. É imperativo que mantenhamos um bom canal de comunicação com nossos membros remotos e envolvê-los em cada oportunidade como se estivessem no escritório conosco. Fazemos isso com conferências semanais cara a cara com todos os membros remotos da equipe. Acreditamos que é muito importante se conectar às pessoas em um nível pessoal, tanto quanto muitas empresas e gerentes veem os membros das equipes como recursos. Um recurso para nós é um laptop ou uma instância na nuvem. Nossa equipe é formada de indivíduos talentosos que carregam uma personalidade única e uma combinação de habilidades para jogar. Devemos potencializar isso para construir equipes de sucesso. Precisamos nos conectar a nossas equipes e entender suas experiências, e o mais importante, para onde estão direcionando suas carreiras. Mantemos todas as nossas reuniões com meios de comunicação remota, mesmo que 99% da equipe esteja no escritório, resistimos à urgência de manter uma reunião física e fazer uma ligação para alguém. Ao invés disso, ligamos de nossas próprias mesas e adotamos uma mentalidade remota para garantir paridade na equipe.

Dedicamos muito tempo toda semana nisso e vemos as recompensas no sucesso das nossas equipes e produtos. Uma grande ajuda para nós, da Red Hat, é o fato de que temos uma cultura única que quase supera as culturas individuais. Tem sido um enorme foco em comunidade e nos valores open source, que se alinham muito bem com os valores e princípios consagrados no manifesto ágil. Acredito que trazer ou formar uma cultura abrangente ajuda a lidar com qualquer problema cultura individual. Acolhemos a diversidade na nossa equipe e também as diversidades culturais que nos ajuda a crescermos e aprendermos como uma equipe.

Sobre os autores

Dr. Leigh Griffin é um gerente de engenharia na Red Hat Mobile com base em Waterford, Irlanda. Griffin tem uma extensa experiência com software conquistada na última década na indústria, no meio acadêmico e em pesquisas. Nos últimos anos, uma especialização em transformação ágil o fez aplicar sua experiência em grandes projetos de conversão.

Brendan O’Farrell é um gerente de engenharia na Red Hat Mobile com base em Waterford, Irlanda. O'Farrell tem mais de 25 anos no gerenciamento de processos e negócios em várias indústrias. Tendo mais tarde se convertido em Engenheiro de Software, ele agora ajuda a Red Hat a transformar mais equipes em direção ao ágil e compartilhando seu vasto conhecimento sobre o tema.