Agile exige forma homogénea de funcionar

Adopção de diferentes metodologias num mesmo projecto esbarrar nas dependências entre equipas, nota Steve Denning, especialistas em gestão das organizações.

Steve Denning, autor e consultor em gestão

Apesar de o contexto das metodologias Agile levar a um maior propensão para auto-gestão das equipas, Steve Denning alerta para alguns riscos da prática, em entrevista para o Computerworld. Algumas empresas menos normativas enfrentam problemas na gestão de dependências entre equipas das organizações, diz o especialista em gestão.

E quem pensa que os gestores podem ser dispensados, desengane-se. Têm de redefinir o seu papel e funções, diz o autor convidado pela consultora Agile 21 para a conferência organizada em conjunto com a IDC.

Outro aviso de Denning: reservar um período de desenvolvimento de um projecto, como precaução para recuperá-lo se algum processo correr mal, é contraproducente

Computerworld ‒ Conhece já muitas empresas que evoluíram para a adopção de metodologias Agile de desenvolvimento e gestão. Quais são os elementos de um hipotética receita?

Steve Denning ‒ Não há receitas. Mas há padrões que funcionam e outros que não. Existem dois tipos de empresas.

As que nasceram ágeis e têm o desafio de saber como se manterão ágeis. Mas o padrão com maior sucesso nas outras, que têm burocracias e hierarquias, nasce de um movimento com origem nas camadas mais baixas ou médias da organização, que parte do reconhecimento que alguma coisa tem de mudar e começam a fazer experiências com a metodologia.

As experiências são bem sucedidas e assim ganham o apoio da administração superior ou alguma área próxima. [A adopção] Torna-se oficial e se o suporte se mantiver, a transformação continua.

Os padrões não têm sucesso quando a mudança é apenas na base da organização e não ganha apoio. Há outro que não sobrevive: quando é a administração a introduzir a metodologia e ela não vinga nas camadas inferiores. Portanto é preciso uma combinação de transformação em dois sentido convergentes.

CW ‒ Exceptuando esses erros o que estão as empresas a fazer mal na adopção de metodologias Agile?

SD ‒ Num consórcio de empresas que se juntou para aprenderem umas com as outras, incluindo a Microsoft, Ericsson, Barclays, entre outras empresas enormes gigantes, todas revelam problemas variados.

CW ‒ Quais são os mais frequentes?

SD ‒ Uma decidiu adoptar uma metodologia Agile mas estava preocupada com a possibilidade de que não funcionasse. E então decidiu organizar três “sprints” (períodos de trabalho específico) e outro para recuperar o projecto no caso de as coisas correrem mal, para resolver os problemas.

Algumas equipas completaram o seu trabalho em cada “sprint”, mas outras foram menos zelosas porque havia um de recuperação e deixaram problemas por resolver. Fizeram as coisas da mesma maneira de sempre e quando chegaram ao sprint de recuperação, tinham tantos problemas que tiveram de pedir ajuda às outras equipas. E todos perceberam ter sido um desastre estar previsto um “sprint” de recuperação.

CW ‒ E que outros problemas pode referir?

SD ‒ Algumas empresas supuseram que, se as equipas deviam auto-organizarem-se, então não eram necessários tantos gestores. Dispensaram muitos deles e descobriram que se instalou o caos.

Contrataram novos, mas com papel diferente. E com efeito a função tem de mudar. Passa a ser a de inspirar [os trabalhadores], de perceber e resolver dependências entre equipas, de estabelecer uma missão clara para a organização, identificar resultados e olhar para a agilidade estratégica, na qual os gestores anteriores nunca pensam.

CW ‒ Fala de um problema frequente, e especificamente na evolução da Scrum, que é o da interligação das equipas. Pode aprofundar quais são os desafios associados a isso?

SD ‒ Há muitos. Um deles é que as equipas têm o seu objectivo particular, embora falem de um objectivo organizacional. Estão sobretudo interessados no primeiro. Começam a acreditar que são a melhor equipa e isso leva a muito pouca colaboração entre os conjuntos.

É preciso quebrar isso e criar uma visão clara sobre o todo. Há um livro do general Stanley McChrystal, “Team of Teams” que explica como ele resolveu isso.

Outro problema que afecta as empresas nascidas com a metodologia Agile, como a Spotify, é que não eram normativas nem impositivas. “Não vos diremos para usar Scrum, ou Kanban, Lean.. Decidam vocês, estão em autogestão, Só queremos ver resultados”, dizem.

Se estes estiverem debaixo de controlo de uma só equipa resulta bem. Mas quando há uma série delas a usar metodologias diferentes, como são geridas as dependências?

Ocorrem problemas sérios relacionados com estas. Uma das formas de lidar com isso é fazer vingar que no todo existe uma equipa maior e definir como se vai funcionar.

Uma organização em trânsito para as metodologias Agile, tal como a equipa de desenvolvimento da Microsoft, para o Visual Studio, decidiu adoptar “sprints” de três semanas. Mas isso é fácil de definir com a estrutura hierárquica desse fabricante e não da Spotify. Mas acabam por ter menos problemas de dependências.

CW ‒ Nas iniciativas em contexto de Administração Pública e eGovernment quais são os maiores desafios?

SD ‒ Tipicamente o sector público não lidera a adopção de novos métodos de gestão. Espera pelo privado. Agora que as maiores organizações estão a adoptar Agile, acaba por ser politicamente viável a sua adopção.

Mas ainda é difícil encontrar exemplos, talvez porque mesmo assim não queiram falar do assunto.
Não há centenas de iniciativas por aí…

CW – Ainda é invulgar.

SD ‒ Sim. Outra coisa é que as metodologias Agile têm a ver com satisfazer clientes e no sector público nem sempre é claro quem são. Há muitos clientes e partes interessadas e é preciso satisfazê-los a todos.

Por isso há sempre o perigo de a administração sentir que será muito difícil e decide fazer as coisas como já se faziam.

CW – Então qual será o maior factor de sucesso para de metodologias Agile no sector público?

SD ‒ Como disse na minha apresentação, tem tudo a ver com mentalidade, o papel do cliente, descobrir quem é a parte interessada… Conseguir organizar equipas de competências cruzadas e em auto-gestão.
Os princípios são os mesmos do que no sector privado.

CW ‒ Como se lida com a necessidade de haver retorno de investimento?

SD ‒ Estamos num mundo de deflação originada na tecnologia. Por isso é preciso pensar em termos de agilidade estratégica como expliquei, para criar mercados novos.
Se ficarmos apenas pela redução de preços e melhoria de produto arranjamos um grande problema.

CW ‒ Como é que acha que a Scrum precisa de evoluir para ser melhor?

SD ‒ Temos de pensar além da Scrum. Nos primeiros dez anos desde o manifesto para o Scrum até 2010, o enfoque esteve em como constituir equipas pequenas.

Mas isso resolveu-se em grande parte até esse ano, embora ainda haja detalhes [por melhorar]. Nos cinco anos seguintes a evolução focou-se em como tornar central o cliente.

A fronteira actual está na “lei da rede”, como se torna toda uma organização Agile, não só equipas individuais. Nessa área há menos modelos bons do que pode ser uma organização Agile. Alguns até são muito maus e pouco ágeis.

CW ‒ E quais são?

SD ‒ O SAFE (“seguro”, se a sigla for lida em inglês) é muito “inseguro”, mas não é a única. Quando se procura uma solução numa matriz, para uma organização, já se está com problemas.

É preciso olhar com uma mentalidade Agile e pensar: dado o nosso cenário e os nossos desafios, como nos devemos organizar para funcionar. Os recursos financeiros, de back office, legal e procurement, essas funções tornaram-se num problema maior face ao que se pensava.

Escapavam ao alcance do manifesto Agile. Conforme as empresas se tornam ágeis, essas funções tornaram-se mais um impedimento. Portanto muitas estão a falar mais em dar maior atenção às funções de backoffice também.

E nessas áreas ainda não há bons de modelos do que poderá ser por exemplo uma função Agile de recursos humanos. É trabalho em curso.

A fronteira actual é por isso a “lei da rede” e depois a da agilidade estratégica.

CW ‒ Uma das críticas que se fazem à Scrum é a tendência que tem para desencadear maior ansiedade entre os recursos humanos, com as estruturas de “sprints”, por exemplo, de duas semanas. Como é que as equipas devem lidar com isso?

SD ‒ Bom o ambiente actual é mais exigente. Numa burocracia é possível esconder-se.

Pode-se sobreviver durante anos sem fazer quase nada ou escrever relatórios que explicam porque nada está a acontecer. Tudo muda quando se começa a implantar Scrum e torna-se transparente.

Não se consegue passar dois anos a dizer que se está a trabalhar no assunto. No final de duas semanas não se produz um relatório, mas sim trabalho acabado e mostra-se.

O desafio é maior para as equipas e para os gestores porque estes têm de decidir o que é importante. Numa burocracia pode-se pedir esclarecimentos aos responsáveis, abaixo ou acima na hierarquia, e não há responsabilidade por nada.

Com Agile são responsabilizados. Contudo se os recursos humanos são confiantes e competentes a metodologia é excitante porque de repente eles passam a mandar na sua nossa vida.

Mas no caso de serem incompetentes é de facto um ambiente difícil.

CW ‒ É altura de fazer outra coisa…

SD ‒ Sim, ir para um área em que se é competente ou podem tornar-se competentes, lidando com o problema.

CW ‒ Que tecnologias mais são úteis para as metodologias Agile? Cloud Computing?

SD ‒ Essa sim, mas não se pode falar de tecnologias individuais.

CW ‒ Mas a EDP diz que a cloud como sendo um factor muito importante.

SD ‒ Obviamente que se procura algo ágil e flexível e a cloud é muito melhor do que se ter um disco, com actualizações de um programa a cada cinco anos.

CW ‒ Portanto os sistemas legados podem ser um impedimento importante.

SD ‒ Sim, podem ser.




Deixe um comentário

O seu email não será publicado