Viagens, opiniões e afins

A gente sabe quando está mais consciente de algo quando é capaz de ver as falhas dele. Hoje está na moda dizer que é ágil ou que sua empresa usa algum “método ágil”.  E por aí segue as diversas sopas de letrinhas e nomes pomposos.  A pouco tempo atrás a tábua de salvação era o Scrum que agora já é “jogado a fogueira” pelos seus antigos defensores e em seu lugar ouço muito de Kanban, lean, etc.  Eu pessoalmente não gosto de modas, prefiro seguir aquilo que me facilite a vida e torne-me mais produtivo, feliz, etc.

Antes de mais nada, deixem eu dizer qual é o significa, para mim, de ser ágil: Pelo dicionário, ser ágil é alguém que se move com facilidade e preteza; para mim ser ágil é ser rápido e resiliente as mudanças; é ir além de aceitar as mudanças… é entender que ela é uma característica da vida.  Quando falamos de TI isso fica mais focado ainda na questão de ser rápido. Gosto de usar a figura de barcos: ser ágil é ser como um pequeno veleiro que pode mudar de direção facilmente.

Frente a isso fica mais fácil entender o que vou dizer a seguir: acredito que nem 1% das empresas que dizem ser ágeis se encaixam na “minha definição”.  Penso, sinceramente, que elas apenas trocaram de nomes, no fim é exatamente as mesmas coisas só que trocaram suas roupas. Antes eram cronogramas, agora são cartões com bluetaks pelas paredes, burns downs e quadro brancos.  Antes tinhamos gerentes, agora temos os Scrum Masters.

Uma outra coisa que considero ruim é que as pessoas não conseguem entender que devemos fazer aquilo que nos torna mais feliz e produtivos. Se controle em cascata deixa a nossa equipe mais produtiva será isso que irei usar. Simples assim. Seguir os processos ips letri é bom quando a gente não está acostumado e ainda não está maduro nele. Entretanto, depois de certo tempo seguir o processo e fazer as coisas só por que dizem que deve ser feito não é nada inteligente.

Uma vez ouvi uma história dos macacos que são colocados numa jaula. Cada vez que algum deles tentava pegar uma banana, todos tomavam uma descarga elétrica. Assim, com o tempo, foram trocando os macacos um a um. Eles desenvolveram um comportamento interessante de bater naquele que tentasse acessar a banana para evitar os choques.  Mesmo tempos depois tendo desligado os choques, os novos habitantes da gaiola batiam naquele que tentava acessar as bananas reproduzindo o comportamente sem nem mais saber porque.

Isso acontece o tempo todo em nosso meio. As pessoas fazem daily meetings e nem sabem mais porque… fazem por que tem que ser assim e ponto final. Cara se na sua equipe já existe a comunicação o daily pode ser uma grande perda de tempo. Pense nisso.  Reviews e retrospectivas também podem ser perdas de tempo. O próprio XP diz que é interessante que os conflitos sejam resolvidos o quanto antes e que a comunicação deve ser permanete e fluída. Assim ter uma reunião para conversar, para mim, por si só é um contra senso.

Ultimamente, o meu time tem usado algo que se assemelha mais ao kanban: kanban é a ferramente visual e não o processo. O processo é algo mais Lean – tentamos sempre manter o fluxo de entregas de forma constante e sem interrupções.  Procuramos sempre o que é melhor para nossa produtividade. Eliminar desperdícios mesmo que isso seja parte do próprio processo como se diz no livro. Inteligência é usar algo e adaptá-lo a sua necessidades. Seguir processos sem questioná-los é escolher não evoluir e correr o risco de acertar.

Colar post it na parede não diz que você é ágil. Ser ágil, para mim, é ser adaptativo. Mudar e procurar sempre o gradiente máximo.  Toda vez que leio o manifesto ágil, vejo ali um pedido para sermos mais inteligentes e produtivos. Usar processos não é ser ágil.. trocar waterfall por scrum não vai magicamente fazer entregar mais. É algo mais perto da cultura que deve ser mexida.

Hoje a moda é dizer que sua empresa é ágil.  Todo mundo agora tem quadro branco nas paredes, um monte de  post-it coloridos espalhados por todos os lados,  etc.  Todo mundo faz Scrum, Kanban, entre outras coisas mais. A questão é quantas empresas de fato são ágeis. Quantas de fato estão trabalhando no sentido de mais qualidade (no produto e na vida dos funcionários)?

A um certo tempo atrás o “mercado”acreditava que deveria padronizar, engessar e burocratizar os seus processos como forma de agradar mais seus clientes. Assim nasceu uma miriade de teorias, livros, bíblias, padrões, siglas e etc. Qualquer empresa que quisesse competir teria que de alguma forma se adequar a algum deles.  Imagine então as consultorias que vivem de vender serviço? Me lembro bem das pilhas de papéis que eram feitos sem nem se questionar se valia a pena ou não. Lembro-me bem das inúmeras reuniões para fecharmos escopo antes de ter escrito ao menos uma linha de código, nem um protótipo para validarmos se havia razão em manter o investimento.  E nada disso acabou com o maior problema que temos no mercado de TI: clientes infelizes!

PAUSA : Isso mesmo que você leu. O maior problema do mercado de TI é que nossos clientes estão infelizes. Eles pagam caro por algo que não é bem o que eles queriam e que chega num prazo muito acima para ter algum valor.  Por isso, não é dificil de entender por que temos tantas empresas que simplesmente optam por não comprar ou desenvolver uma solução mesmo sabendo que ela poderá ajudar.

Trabalhei 3 anos em indústria num departamento de engenharia. Era responsável pela parte de TI mais próxima da máquina (chamado de supervisórios, scada, etc). Com isso tive a oportunidade de lidar com grandes projetos que envolviam números realmente impressionantes.  Os projetos, em todos, tinham ciclos de vida de até 4 anos… Isso mesmo os projetos duravam em média 2 a 3 anos desde a sua concepção até a sua entrega, devido a lidarmos com fabricação de máquinas, construção de prédios, e outros serviços parecidos.  Nesse tipo de ambiente é certo concluir que a pressão é grande e a margem de erro é pequena, por isso, muitos diriam que isso seria um “prato cheio” para processos rígidos, escopos fechados, etc.

Acredito que para a surpresa de todos, o que eu vi foi exatamente o contrário:  As coisas mudavam muito e isso era muito bem absorvido, pois todos sabíamos que isso poderia acontecer .  Não tínhamos quadros brancos, não tínhamos post-its (eu até tinha ) tudo era controlado por um cronograma.  Entretanto, sentia que de certa forma éramos ágeis.  Quando chegávamos mais perto da entrega (chamávamos de partida da fábrica), contávamos com uma reunião diária com todos os técnicos/engenheiros envolvidos onde discutíamos o que tinhamos feito, os problemas,  as soluções, etc.  O que realmente estragava toda a brincadeira era o fato dos administradores/diretores nos entupir de formulários a preencher e assim toda a agilidade de equipe ia “por água abaixo”.

Cito esse exemplo para dizer que agilidade nada tem a ver com a ferramenta ou processo adotado. Tem muito mais relação com RESIlÊNCIA, ou seja, a sua capacidade de aceitar um “porrada” sem se deformar; sua capacidade de aceitar que as coisas mudam e ser aberto a elas; sua capacidade de não esconder os problemas, entender que eles existem e fazem parte de tudo, e que o grande lance não é procurar culpados e sim formas de resolver. É entender que tudo é negociável (menos a qualidade por favor).

RÓTULOS SÃO BONS PARA EMBALAGEM NÃO PARA FAZER SOFTWARE

Tenho começado a vislumbrar que tudo não passa de rótulo. Empresa que antes eram CMM ou RUP doentes hoje dizem que usam SCRUM e são ágeis. O que mudou foi o  RÓTULO, nada mais.  Ainda tem um monte de gente fazendo coisas sem sentido (zero de valor para o cliente), equipes fazendo horas extras para caramba, chefes mega autoritários e por aí segue.  Tem uma palestra do Jeff Patton entitulada “Eu não quero seus processo estúpido” que fala algo nessa linha.

Dane-se o nome.  O que importa é gente feliz: cliente feliz, funcionário feliz, chefe feliz, enfim todos felizes. Não é o quadro branco ou a pilha de documentos que irá garantir isso É muito mais atitude!  O que importa que vamos entregar mais valor para o nosso cliente e com isso fazê -lo ganhar mais dinheiro. É termos um ambiente que propicie que o cara que está fazendo esteja feliz e motivado pois sei que com isso ele irá fazer o seu 100% para ter algo bom e de qualidade na ponta. E se tudo funciona todos ficam felizes.

Seus processo, solução ou de qualquer jeito que queira chamar, dever como um lubrificante: deve facilitar o funcionamento para obter o máximo rendimento.

NÃO IMPONHA PROVE QUE SERÁ MELHOR

Um dos maiores erros é impor. Nada imposto dura muito ou é feito com alegria. Prove que se fizer daquele jeito será melhor e esteja preparado para estar errado.  Não será em todos os lugares que fazer par para programar será a melhor coisa. Isso depende das pessoas quererem. Eu particularmente gosto.  Não será em todos os lugares que não ter cronograma será a melhor escolha.

Sugiro, experimente, erre, mude. Siga evoluindo. Um colega de trabalho, Bernardo Heynemann, num tech talk, falou que uma coisa legal da cultura japonesa que ajuda muito o jeito Toyota de fazer as coisa é que eles sempre buscam a excelencia e evolução continua. Isso para mim é ser ágil. Aceitar o movimento e fazer uso dele.

Muito tenho escutado neste últimos dias sobre a questão do sucesso ou não do uso de metodologias ágeis.Principalmente com relação a entregas. Primeiro preciso dizer que não sou um doutor no assunto, nem pretendo ser, muito menos um profundo conhecedor, mas considero que tenho uma pequena vivência no assunto que me permite tecer alguns comentários sobre o assunto.

A alguns dias atrás, fiz um workshop sobre metodologias ágeis com o Juan Bernabó na Globo.com. Recomendo fortemente a todos fazerem mesmo que já tenham certo conhecimento sobre o assunto, apliquem nos seus times ou qualquer outro caso.

Durante todo o workshop feito por ele, cujo o objetivo é de apresentar as metodologias principalmente o Scrum, vários jogos, dinâmicas e outras tantas coisas são feita. Entretanto, para mim, o mais interessante  foram as discussões que ocorreram entre as atividades.

Houve um momento que o pessoal colocou os problema encontrados no dia a dia de cada um e suas expectativas quanto ao uso de metodologias ágeis.  A primeira coisa que ficou bastante evidente foi uma expectativa que ao colocar em prático algo ágil todos os problemas desaparecerão, como que por mágica, e que todos serão felizes num ambiente super ideal.

A questão que o curso colocou, e que realmente achei genial, é que Scrum não é uma ferramenta somente de soluções. Ela tem muito mais um aspecto de mostrar os problemas e forma simples e rápida procurar resolvê-los.

Sendo assim, quem não está preparada para ver os problemas, gargalos, etc de sua empresa, ao adotar qualquer coisa no sentido, vai achar que a ferramenta não serve. Isso porque tem a expectativa errada. Verá muito mais problemas do que solução.

Uma outra coisa que o Bernabo falou que me fez mudar a forma de pensar foi que ser ágil não significa não ter problema : a questão é exatamente contrária, evidenciam os problemas e procura-se soluções. Contra medidas nas palavras do Juan.

Enfim, ao vermos a questão ágil não como mais um processo e sim como uma forma de levantar os problemas e buscar contra-medidas, fica claro a razão do sucesso e que simplesmente seguir uma cartilha não é o perfil ideal a buscar.