Implementação do ágil na perspectiva de um gerente

Desde a infância, aprendi que para ter sucesso, teria que ser individualmente o melhor. Isso se aplicava principalmente na escola, ao tocar um instrumento musical ou em qualquer lugar em que o elemento de avaliação estivesse presente. Poucas pessoas estavam interessadas em saber se era ou não capaz de cooperar com os outros, se poderia buscar um compromisso, inspirar ou motivar os outros a agir. Ninguém deu atenção especial a isso. Não fomos ensinados a cooperar ou ajudar uns aos outros. Não somos graduados para isso. Acontece espontaneamente, como resultado de nossas características, educação e as circunstâncias que experimentamos.

No entanto, é mais frequente que equipes estejam por trás do sucesso

Assim como em reality shows, as equipes estão por trás do sucesso com mais freqüência do que pessoas individualmente. Por gostar de esportes, utilizo o seguinte exemplo: recentemente, apenas dois jogadores de futebol ganharam o título de melhor jogador - Cristiano Ronaldo e Messi, que individualmente, conquistaram fama em várias competições, torneios e receberam o título de goleador em torneios de liga e internacionais. Porém, eles não conseguiriam conquistá-los sem seus colegas do Real Madrid, do Barcelona, ​​da seleção de Portugal ou da Argentina. Sem o apoio correto do treinador, dos médicos, das relações públicas ou do pessoal de marketing, não haveriam tantos troféus em seus gabinetes de vidro. Ambos são individualmente excepcionais, mas só são capazes de mostrar plenamente suas habilidades em equipes excepcionais. Atualmente, esta é a receita para o sucesso.

Antes do ágil chegar ao mBank...

Neste artigo, compartilho minha experiência como gerente quando implementei o ágil em uma data warehouse no mBank. O que o mBank parecia antes de começar a abordar o desenvolvimento de software de maneira ágil? Simplesmente se gerenciava aplicando o método cascata ou outros menos conhecidos, híbridos de kanban-cascata ágeis.

Na perspectiva de um funcionário...

Do ponto de vista de um desenvolvedor, o processo geralmente envolvia o trabalho sendo delegado a um funcionário por um coordenador de negócios ou por um gerente. O trabalho era, em sua maioria, independente, com apenas algumas interações com outros desenvolvedores, o chamado negócio. Os funcionários não se incomodavam com as reuniões, a menos que iniciadas pelos gerentes. E esperava-se que entregassem no prazo, dentro do orçamento e do escopo definido. Especializações eram necessárias de tempos em tempos. Se o assunto fosse sobre "reembolso de taxas de cartão", todos sabiam que o Chris era a pessoa que conhecia sobre o assunto. Se o Chris não estivesse presente, era necessário esperá-lo voltar das férias. Falha? E o Chris levou seu PC nas férias?

Na perspectiva de um gerente...

Do ponto de vista de um gerente, este trabalho envolve principalmente a delegação e recebimento de tarefas, monitoramento do trabalho e estabelecimento de tarefas a serem implementadas com o negócio. Em vez de uma equipe, o gerente tinha um grupo de individualistas, que de tempos em tempos eram agrupados para as necessidades dos projetos, que eram dissolvidos logo após a conclusão de um determinado projeto. Devido a famosa pressa e correção, havia uma permanente falta de tempo para a visão e estratégia de uma equipe, discussões cíclicas individuais, reuniões sistemáticas com toda a equipe e o estímulo ao desenvolvimento dos funcionários. Mas para mim, o gerenciamento estava sendo realizado, o software desenvolvido e os negócios estavam indo bem.

Como o ágil surgiu na organização?

Um dia, um novo chefe de TI chegou ao mBank e como revelado previamente, implementou com sucesso uma abordagem ágil para a produção de software em várias instituições no passado. Até aquele momento ninguém havia conseguido convencê-lo de que o ágil "não funciona".

O que o autor sabia sobre ágil?

Conheci o ágil através de uma leitura na Wikipedia, de um livro intitulado "Gerenciamento de projetos de TI. Guia de metodologias", e das histórias dos meus amigos. Naquela época também realizei um curso intitulado "Gerenciamento ágil de projetos" e tirei uma certificação em nível fundamental. Dessa forma, tinha muita informação, mas pouca experiência prática. Tinha minhas preocupações, e me perguntava se tal mudança era realmente necessária, uma vez que parecíamos estar realizando o trabalho muito bem.

Receios

Receio de perder a influência sobre o time

Além de levar muito tempo, a delegação de tarefas em andamento e o recebimento e monitoramento do progresso do trabalho também trouxeram uma sensação de perpetração. Agora havia o controle do que meus funcionários estavam fazendo, como e para quando o trabalho seria entregue. Nesta realidade ágil, apareceu um estranho - um product owner - que define prioridades, expectativas e prazos, no meu lugar. Na verdade, o product owner gerencia o trabalho da equipe e eu tive que me retirar, não distrair ninguém; apenas apoiá-los e educadamente perguntar se precisam de algo.

Receio de desperdiçar tempo em reuniões

Durante a sprint de duas semanas, uma equipe deve se reunir todos os dias para a chamada daily (até 15 minutos), refinamentos (uma a duas vezes por semana por 1-2h), revisões (uma vez a cada duas semanas por 1-2h ) e retrospectiva (uma vez a cada duas semanas por 1-2h). Somando todas essas horas durante uma sprint de duas semanas, pode-se concluir que um desenvolvedor é privado de pelo menos 6,5 horas ou até 14,5 horas devido a reuniões (sem considerar as trabalhadas efetivamente) durante o período de duas semanas. No caso de uma equipe de cinco pessoas, isso significa 4-9 homens-horas do desenvolvedor em duas semanas. No começo, parecia que seriam executadas menos tarefas e diversos projetos não seriam concluídos em um ano. A área de negócios não ficaria satisfeita. Scrum não é barato.

Receio sobre os Agile Coaches

O que é esse papel estranho de agile coach? No conselho da organização, apareceu um grupo de pessoas que carregaram a tocha da educação ágil. Deveriam estimular o desenvolvimento ágil de software nas equipes, remover obstáculos, conversar com as equipes e seus gerentes para incentivá-los a pensar de forma diferente sobre o desenvolvimento de softwares e desencorajar o uso de métodos antigos. Começaram a conversar com minha equipe, realizando diversas perguntas ao time. Estavam sentados juntos em espaços abertos e observando o que estava acontecendo. Surgiram algumas dúvidas: O que estavam falando com a equipe? Ou ainda pior, quem estavam informando e sobre o quê? Os agile coaches participavam de uma reunião ou outra como um misterioso agente Smith. O que estava acontecendo?

Receio das mudanças

Por que mudar algo que funciona? Não vi a necessidade de introduzir o Scrum, pois minha equipe estava atingindo os objetivos estabelecidos. O melhor é o inimigo do bem, não toque nele porque vai se queimar.

Receio de que não seria capaz de separar o produto

Haviam pessoas na minha equipe que vinham criando toneladas de software por muitos anos - relatórios, extratos de sistemas, aplicações, sistemas de TI, data marts, etc. Sabendo que o Scrum, em sua essência, foca no desenvolvimento de produtos interativos, fiquei imaginando como encontrar um produto neste ambiente no qual as equipes individuais devem se concentrar, pois existem dúzias de tais sistemas na empresa. Não há possibilidade de oferecer à equipe o conforto de trabalhar em um grande projeto. Pode-se apenas tentar agrupar os sistemas e lidar com categorias de assuntos. Então, vale a pena tentar criar equipes em torno dessas coleções de sistemas?

Receios sobre geografia

Talvez não seja uma boa ideia lutar com a "geografia". Como se pode criar equipes com funcionários trabalhando em duas cidades, Lodz e Varsóvia, a mais de 130 km uma da outra? Obviamente, isso é possível. Porém, seria melhor se os de Lodz trabalhassem com os de Lodz e os de Varsóvia trabalhassem com os de Varsóvia. Mas e se isso não for possível? Talvez seja possível no Excel, mas na realidade é difícil.

Receio com a falta de scrum masters experientes na equipe

Assumindo que o Scrum decole, um produto seja separado, as equipes sejam criadas e que seja aceito por mim a falta de controle total sobre as pessoas e suas tarefas, como é possível obter Scrum Masters para cada equipe? Onde se pode encontrar pessoas que cuidarão da aplicação dos princípios do Scrum em equipes específicas? Posições são fixas. Não podia empregar ninguém novo, mas por outro lado, tinha alguma esperança.

Esperava ter mais tempo

Gostaria que a agitação e a pressa levassem menos do meu tempo. Lidando com a delegação de tarefas, estabelecendo prioridades, verificando o progresso do trabalho, respondendo a priorização de assuntos... esse era meu cotidiano; uma tarefa importante e muito necessária. A questão era, deveríamos estar fazendo isso do começo ao fim? Nunca houve tempo suficiente para trabalhar na visão da equipe, no desenvolvimento dos funcionários, etc. Sempre havia algo mais importante a ser feito, como se o desenvolvimento dos funcionários e da equipe não fosse o trabalho do gerente. É verdade, mas somente depois de completar o "trabalho real".

Esperava introduzir a substituibilidade

Se um funcionário estivesse de férias, esperava que em 99% algo poderia dar errado, pois não tinha todas as funções da equipe compartilhada entre as pessoas. Como resultado, os riscos aumentaram e ocorreram falhas. Esperava que o resultado do espírito de equipe permitisse a permutabilidade de posições e que as pessoas se substituíssem de maneira eficiente.

Esperava construir verdadeiros times

Como mencionado anteriormente, gerenciei uma equipe de individualistas. Havia uma boa oportunidade para mudança; para incentivar as pessoas a cooperar umas com as outras, transferir conhecimento, aprender umas com as outras, perceber as melhores soluções que seus colegas aplicaram. Graças a isso, foram capazes de produzir um software melhor escrito, menos defeituoso, de forma ideal, pelo qual um grupo é responsável em vez de um indivíduo.

Esperava que o negócio assumisse a responsabilidade de estabelecer prioridades

É um prazer quando os clientes externos solicitam que um desenvolvedor seja delegado para implementar uma tarefa. Você se sente importante e necessário como gerente. É menos agradável quando solicitam que o desenvolvedor faça isso duas vezes mais rápido do que a estimativa que foi fornecida. É pior ainda se não houver desenvolvedores, e os stakeholders começarem a ameaçá-lo com penalidades ou lembrá-lo de estar familiarizado com o CEO. Obviamente, é uma norma corporativa diária e é comum a demanda de homens-horas exceder o suprimento de recursos. Por outro lado, é tentador simplesmente abandonar e deixar nas mãos de um product owner que entenda de TI e conheça seus produtos e negócios - é um sonho Ágil.

Receios ou esperanças?

Levei um tempo para decidir se meus receios ou esperanças seriam controlados. No entanto, sabia que precisava arriscar, dedicar algum tempo à preparação, obter algumas respostas, e o resto cuidaria de si mesmo.

Por onde comecei?

Realizei reuniões com praticantes que costumavam trabalhar com ágil. Pessoas que puderam mostrar como seria o processo de transferência do modelo cascata para o ágil. Perguntava e dúvidas começaram a desaparecer. No ano seguinte, selecionei uma área que poderia tentar "tornar ágil", junto com uma nova equipe e um agile coach. A área de relatórios foi escolhida. Uma reunião inicial foi feita e assim começou. Primeiro, uma equipe decolou e, a cada poucos meses, equipes subseqüentes em outras áreas de data warehouse foram transformadas. Ativei quatro equipes no total. Uma das equipes passou pela jornada de Scrum para Kanban. Os outros três trabalharam no Scrum o tempo todo. Cada um deles tinha sua especificidade, seus desafios e seus atributos. Uma equipe se separou para retornar em uma configuração diferente e se tornou uma das melhores equipes a bordo.

Qual foi o elemento mais difícil?

"Droga de Scrum"

Um dia, um colega product owner de uma das minhas equipes, disse depois de uma retrospectiva: "Droga de Scrum. Antes, eu apenas pedia, agora tenho que perguntar". No Scrum, se deseja construir bases sólidas para que a equipe se torne independente, não pode simplesmente ordenar que façam algo. É preciso perguntar e apresentar argumentos. Isso obviamente leva tempo; por outro lado, ensina as pessoas a serem responsáveis. Isso foi um grande desafio quando tive que pedir a um product owner, uma pessoa de negócios, para permitir que a equipe implementasse uma tarefa importante (para mim)... o que está relacionado ao seguinte ponto ...

Dar preferência ao product owner (PO)

O que significa permitir que o PO estabeleça prioridades, converse com os stakeholders, seja o rosto da equipe. Tive que me retirar e implementar outras tarefas (desenvolver e integrar os funcionários, estimular o desenvolvimento da equipe, visão e estratégia do time, gerenciar grandes projetos, orçamentos, etc).

Combinando o papel de um gerente e PO

Da teoria para experiência, aprendi que é muito mais saudável para sua psique e para o trabalho em equipe se o gerente e o PO forem dois indivíduos, e não uma única pessoa. Uma das tarefas não padronizadas que tive que cumprir foi a função de PO. O PO oficial teve um longo período de licença médica (vários meses) e sem encontrar uma alternativa, concordei em substituí-lo. Foi bom para as primeiras semanas; no entanto, comportamentos inadequados posteriores começaram a aparecer - microgerenciamento, pressões desnecessárias na equipe, etc. Como resultado, meus subordinados pediram para que não comparecesse às reuniões diárias e retrospectivas, o que foi difícil para ambos.

Scrum Masters precisam de tempo

Para mim, isso foi uma revelação. Para uma pessoa que respeita os princípios do Scrum precisa de metade do seu tempo, ou seja, aproximadamente 5 homens-horas em uma sprint quinzenal, para o trabalho de scrum master. Como minhas equipes não tinham scrum masters - este papel foi cumprido pelos desenvolvedores - significava que em um time havia meio homem a menos para trabalhar. Isso foi muito doloroso para mim, já que cumpria o papel de PO e de gerente ao mesmo tempo, lidando com a pressão dos stakeholders sobre a questão dos homens-horas preciosos.

E os resultados?

Dificuldades, receios e esperanças ... isto é, como tudo terminou e quais foram os resultados das mudanças introduzidas?

No que diz respeito aos data warehouses, haviam quatro equipes com três Scrum Masters e um Kanban Master. Perdi um pouco de poder, uma vez que os POs delegavam as tarefas. Por outro lado, recuperei tempo para outras operações como o desenvolvimento e integração de funcionários, o estímulo ao desenvolvimento de equipes, o gerenciamento de grandes projetos e a educação de sucessores.

Meu medo era de que o tempo gasto em reuniões, em particular no caso do Scrum, ocupasse os homens-horas de desenvolvimento, o que tornou-se realidade de certa forma. Por outro lado, a organização ganhou algo que é difícil de quantificar - propagação de conhecimento sobre sistemas, soluções de TI melhores elaboradas - pois como discutido em grupo, os erros constituem material para aprender e não devem ser varridos para debaixo do tapete. Fui convencido de que o tempo investido foi totalmente pago nos projetos implementados e em sua manutenção. A substituibilidade nas equipes apareceu e o risco operacional de gargalo basicamente deixou de existir.

Acontece que os agile coaches não eram meros informantes, mas pessoas muito gentis que queriam ajudar... o sucesso alcançado foi também o sucesso deles. Não deveríamos ter medo de mudanças, pois, embora causassem alguma confusão, também introduziram nova qualidade e energia adicional. Agora, ninguém quer voltar ao método antigo.

Não foi possível implementar tudo do jeito que gostaría e a separação de um produto por equipe ainda está em andamento.

As equipes de Lodz e Varsóvia estão funcionando. Seria ideal se estivessem no mesmo local, mas não precisamos mendigar isto. Skype, telefones, carros e trens fazem o trabalho acontecer.

Depois de algum tempo (aproximadamente 2 anos e meio), sucessores e gerentes que queriam introduzir mudanças adicionais apareceram, permitindo que os acionistas da empresa agrupassem produtos, dando aos desenvolvedores a chance de mudar a equipe em que trabalham. Mudanças geram mudanças... mas isso é outra história.

Não é necessário mudar. A sobrevivência não é obrigatória. William Edwards Deming

Sobre o autor

Tomasz Dutkowski é gerente de TI sênior com experiência na área de data warehouse do mBank, para clientes de varejo e corporativos. Possui 14 anos de experiência no setor bancário, tanto no lado de negócios quanto de TI. Líder na transformação da produção de software ágil no nível de equipe e entusiasta da inovação no trabalho em equipe. Na vida pessoal, marido e pai de dois filhos.