Entretanto, apesar da gestão tradicional atuar fortemente sob a égide do respeito às pessoas, existe uma outra dimensão neste polígono: comprometimento. Não existe agilidade com galinhas. A liberdade está delimitada por um conjunto de restrições que são as regras do jogo. Como em um jogo de futebol, as pessoas tem a liberdade de criar, driblar, passar, lançar, mas respeitando as regras do jogo, como a bola não sair das quatro linhas, não fazer falta, não colocar a mão na bola (se não for o goleiro), etc.
Infelizmente, o que percebemos é o problema causado pelo excesso de liberdade que tem origem na má interpretação dos conceitos ágeis. É sobre isso que eu quero falar aqui.
Controle
Se enganam os que pensam que na gestão moderna não existe controle. O fato é que o controle muda de foco e se dá sobre outras variáveis. A não ser em projetos pessoais, projetos corporativos possuem prazos. Seria ótimo que estes prazos fosse cumpridos. Quando não são, precisamos entender os motivos e gerar um plano de contingência.
A diferença aqui é que o time ou informa o escopo que cabe neste prazo ou informa o prazo necessário para este escopo. Sabemos que a incerteza neste momento do projeto é grande, ainda mais se estivermos lidando com um time recém formado (os adeptos de Tuckman como eu que me perdoem). Mas, como eu disse na introdução deste post, projetos ágeis só funcionam com porcos e não com galinhas. É necessário que as pessoas se sintam comprometidas com o escopo que disseram que cabia no prazo, sem buscar muletas.
As muletas são a variabilidade inerentes ao sistema altamente complexo onde os projetos de software estão normalmente inseridos. A responsabilidade pela entrega superestimada precisa ser divida com todos e não é justo que caia apenas sobre os ombros da gestão. Se ficar claro que um prazo poderá não ser cumprido, o cliente precisará verificar a priorização e mudar caso seja necessário. Gestores precisarão agir como facilitadores e atuar fortemente na remoção dos bloqueios do trabalho do time e o time precisa aumentar o esforço.
O controle somente sobre o time funciona muito bem em times auto-organizados. Nestes times, mais uma vez, existe sim o microgerenciamento entretanto, antes que os monges agilistas me condenem ao fogo do inferno ágil (parodiando meu amigo Mauricio Aniche), este microgerenciamento é feito pelo próprio time. Para que isso aconteça, o nível de comprometimento do time precisa estar muito elevado e as pessoas de fato precisam se cobrar visando a entrega. O problema é que não é muito comum, principalmente em empresas tradicionais, encontrarmos este tipo de comportamento.
A variabilidade não pode ser utilizada como justificativa para acomodação.
Comando
O comando nos projetos ágeis também existe. Ele se dá através das restrições criadas pela organização. Se um débito técnico precisa ter prioridade sobre uma história, então ele deve ser puxado antes e o mais rápido possível. Se bugs possuem prioridade acima dos débitos técnicos, eles devem ser puxados antes de qualquer outra coisa.
Infelizmente é bastante comum observarmos times puxando os work itens que bem entende e quando você pergunta o motivo, recebe a resposta característica de quem acha que projeto ágil é a casa da mãe Joana: "Eu estava com vontade de trabalhar neste e não naquele, algum problema?" Sim, meu caro, existem diversos problemas.
Nosso objetivo é tornar o nosso trabalho o mais fluido possível. Bugs e débitos técnicos travam esta fluidez. Nosso objetivo é terminar o que começamos e não ficar começando sem terminar. É mais importante chegarmos com 5 work itens completos e com qualidade no fim do nosso fluxo que chegarmos com 100 no final do prazo faltando build, teste e com excesso de bugs.
Pensando nisso é que existem as políticas de controle de fluxo, que devem estar explícitas, e ditam como agir se o fluxo estiver doente. Como uma receita médica elas nos informam como agir no caso de doenças. E as doenças são os débitos técnicos, bugs e impedimentos.
***
O grande desafio do gestor moderno é descobrir inserido em grandes corporações com cultura tradicional é descobrir o equilíbrio entre liberdade, responsabilidade e comprometimento.
Este gestor precisa conhecer muito bem a teoria dos sistemas e vasculhar fundo a relação causa-efeito. Ele precisa conhecer muito bem a teoria das redes, para saber como as partes se relacionam. Ele precisa conhecer muito bem a teoria das filas e a teoria de gerenciamento de fluxo para conseguir identificar facilmente quando um fluxo não está saudável e o que fazer. Ele precisa conhecer muito bem os fatores que criam a motivação intrínseca em seus funcionários e parar de achar que ameças de demissão e bônus realmente vão motivar alguém. Ele precisa conhecer muito bem a teoria dos sistemas complexos para aprender a identificar fontes de variabilidade e aprender a lidar com elas, aprender também a utilizar as métricas corretas para trabalhar a sua previsibilidade.
Enfim, é um grande desafio e uma grande mudança de mindset, é uma nova forma pensar e gerir pessoas. É por isso que tantos resistem.
[1] Appelo, Jurgen - Management 3.0
Parabéns pelo post, foi direto ao ponto, a falta de comprometimento das pessoas. Um ponto que também deve ser analisado é a falta de tato das empresas com pessoas comprometidas. Como você mesmo disse bônus ou ameaça não motivam ninguém, ao contrario, bônus só faz o cara correr que nem um louco sem olhar qualidade para ter um salario mais polpudo no final do mês e ameças só servem para desmotivar e fazer a equipe procurar outro emprego.
ResponderExcluirPerfeito, Celso. Semana passada, numa retrospectiva de Sprint que ajudei a conduzir, um membro do time questionou uma conduta gerencial alegando que no Ágil as pessoas são auto-gerenciadas.
ResponderExcluirTentei ajudá-lo a entender que não se trata disso. No Ágil, o >>time é auto-organizado<<; auto-gestão é outra ciência.
Como mentores da transição um dos desafios é esclarecer que agilidade e anarquia são coisas distintas.