Como recupero o controlo de gestão da minha equipa "auto-organizadora"?

Dás um olhar estranho ao scrummaster e dizes “adeus Felicia”, e no dia seguinte convocas uma reunião de toda a equipa e perguntas-lhes que raio de disparate foi esse.

Se isto acontecesse, eu despedia o idiota do scrummaster num minuto de Nova Iorque. Este scrummaster é perigoso, pouco profissional e extremamente inapto para o seu trabalho. A maneira de “despedir o seu manager” é desistir: ele basicamente só apresentou demissões para toda a equipa.

Não percebo porque estás preocupado. Estão todos sob a sua hierarquia e não têm poder para o despedir.

Mais importante, tem de perceber o que raio se está a passar. O próprio mestre do scrum pode precisar de ser extinto, dependendo da situação.

Faça-o antes que seja demasiado tarde, antes que o seu chefe (ou CIO) lhe diga a mesma coisa.

Embora tenha trabalhado com várias equipas que seguiram esta mesma linha de acção, não me parece que isto tenha sido tratado com o cuidado que merece. Gostaria de partilhar o que vi para ver se isso ajuda a dar um caminho em frente.

Primeiro, Scrum incentiva as equipas auto-organizadoras. O que o Guia Scrum diz especificamente sobre equipas auto-organizadas é o seguinte:

Eles são auto-organizadores. Ninguém (nem mesmo o Scrum Master) diz à Equipa de Desenvolvimento como transformar o Backlog do Produto em Aumento de Funcionalidades Potencialmente Desbloqueáveis;

Que, juntamente com um bom negócio sobre ser multifuncional e amplamente responsável, pretende encorajar os membros da equipa a fazerem a si próprios duras perguntas sobre o quão bem estão preparados para responder a quaisquer pedidos que lhes sejam dirigidos. Vale definitivamente a pena dar ao Scrum Guide uma leitura - é curto.

Quanto a um gestor, se você descobriu que o seu trabalho no passado tem sido atribuir tarefas e rastrear itens de trabalho, o Scrum pede-lhe que dê um passo atrás. Francamente, se o Scrum Master não lhe falou sobre isto muito antes da primeira retrospectiva, isso pode ter sido um pouco errado da sua parte. Uma dura realidade, porém, é que muitas equipas que estão habituadas a que um gestor organize as suas tarefas para eles não estão bem preparadas para simplesmente saltar para esta abordagem. Se sente que a sua equipa se encontra nesta situação, recomendo que fale com o Scrum Master sobre o assunto. Existem muitas técnicas para facilitar esta transição. Em particular, eu olharia para a Escada de Liderança de David Marquet e talvez até para o seu livro Turn the Ship Around. Verá que em ambos, nenhum gerente é despedido.

Finalmente, vejamos porque quereria fazer esta transição se teve sucesso a gerir pessoas no passado. A versão curta é que você terá ainda mais sucesso ajudando-os a aprender a gerir a si próprios. Há tanta pesquisa e dados sobre isto que é difícil saber por onde começar - mas direi que é um facto bastante bem demonstrado que todas as pessoas são potencialmente capazes de se auto-organizarem e numa equipa de, digamos, dez, onze cérebros (incluindo o seu) resolverão sempre os problemas com mais eficácia do que um e ter outros dez de lado à espera de lhe colocar a culpa se a solução estiver errada.

Já vi muitos gestores de sucesso em ambientes Scrum. Eu sempre advertiria uma equipa contra o “despedimento”. Mesmo que você seja intimidante como diz a sua pergunta e administre todas as tarefas à sua frente, já trabalhei com muitos gestores como esse, que ainda são activos espantosos para a equipa. Nestas equipas auto-organizadas, passa-se de passar todo o tempo a dirigir as acções da equipa para garantir que o caminho para o seu sucesso é claro e sai sempre melhor em toda a linha, com equipas que entregam mais e gestores com reputação de criar estrelas do rock.

Boa sorte, espero que isto lhe dê alguns ângulos para trabalhar.

• No contexto do scrum: O que diz o proprietário do produto? Não é função do mestre do scrum pedir mais (ou menos) recursos. Isto é algo que o proprietário do produto precisa de alinhar com as partes interessadas

• No contexto do scrum: Uma retrospectiva é sobre o processo e a equipa e o projecto (não sobre “como me sinto em relação ao meu chefe”). Se fizesse parte da equipa, deveria ter sido convidado. Se não fizeste parte da equipa, a retrospectiva só deveria ter tratado do teu papel no projecto.

• scrum masters dizendo aos gestores de linha o que fazer são pelo menos tão absurdos como os gestores de linha envolverem-se directamente no scrum

Por isso o scrum master ultrapassou claramente os seus limites. A sua função era manter a retrospectiva focada na identificação de problemas específicos que precisam de ser tratados.

Como proceder:

• Fala com a equipa em sessões individuais e pergunta-lhes o que se está a passar. Explica claramente que o scrum master é não uma função de linha e que ele faz não montar as equipas. Pergunte também onde acham que deve ter ficado fora do negócio diário

• esclareça à equipa a quem devem ser endereçados os problemas

• vá para o próximo da fila (se for o CIO, é o CIO - não é aceitável que não tenha um gestor durante meses), afirmando que a situação tem de ser resolvida imediatamente (despedindo o mestre scrum ou o CIO tendo uma palavra com ele de que será despedido no curso actual), caso contrário põe em perigo o projecto - parece-me que o mestre scrum não compreende os seus deveres e limites. Uma resposta profissional à equipa que tenta “despedir” o seu director como parte de uma retrospectiva teria sido “Não me compete resolver a relação entre si e o seu chefe, e definitivamente não é para isso que o projecto nos paga”.

Sublinhei à equipa os benefícios da auto-organização das equipas e do empoderamento da equipa.

Bem, eles certamente tomaram _ essa_ parte a peito.

Parece claro que estão numa situação muito emocional neste momento. Aparentemente, a sua equipa tem alguns problemas importantes com a actual relação entre si e eles. Foi provavelmente uma coisa boa não ter estado na retrospectiva, porque essa é normalmente a razão pela qual as pessoas estão subitamente dispostas a falar sobre o que as está realmente a incomodar. Se estão dispostas a fazê-lo em torno de um Scrum Master com quem só trabalham há algumas semanas, então ou já confiam no tipo ou estão tão irritadas que não se importam com as consequências.

Seja como for; este não é um problema novo que surgiu subitamente quando mudaste para Scrum ou contrataste uma nova pessoa. Este é um problema que se tem vindo a agravar há muito tempo. É frequente dizer-se que trabalhar [ Agile não cria tanto novos problemas, como torna os já existentes extremamente óbvios. (http://brainslink.com/2011/12/agile-development-wont-solve-your-problems/) Este é provavelmente um caso disso.

Dito isto; o seu Scrum Master deixou cair a bola, com força. O seu trabalho é ajudar a equipa a crescer para ser auto-organizadora, claro. Mas este não é o caminho certo. Para começar, ele não pode actualmente despedir-te, e dizer-te apenas “é isto que a equipa quer” é completamente não construtivo. Não tenho a certeza do que ele pensa que vai ser resultado disto, mas não pode muito bem ser o que a equipa pensa que é.

Além disso, remover pessoas é a escolha mais difícil que uma equipa ou Scrum-Master ) pode fazer e deve nunca ser levada de ânimo leve e sem falar (repetidamente) com os envolvidos. Não se pode simplesmente sair e remover alguém que não tem a menor ideia de que alguém está a ter problemas com eles. Se nada mais, vai deixar todos com muito medo de que, se falharem uma retrospectiva, possam de repente voltar ao trabalho para descobrirem que foram expulsos da equipa. Vai criar uma atmosfera de medo, não de confiança. Uma atmosfera de confiança e abertura é o que se quer quando se trabalha com Agile.

Então com o seu Scrum Master a não trabalhar numa atmosfera aberta (pelo menos fora da equipa; ele parece ter conseguido que as pessoas se abrissem um pouco internamente) e a não procurar uma solução construtiva, parece que é a si que cabe fazê-lo.

Neste momento, não creio que nada baseado em autoridade vá ser útil. O Scrum e o Agile têm a ver com dar poder às pessoas para fazerem as suas próprias coisas, e afirmar a sua autoridade nesta altura vai provavelmente acabar com toda a equipa a ser despedida. A equipa já declarou que está no ponto em que quer que as pessoas se vão embora, por isso, embora possam ter-se enganado na pessoa, ir de frente com ela irá provavelmente acabar com pelo menos algumas pessoas a sair. (E lembre-se da regra mais importante sobre sair: as pessoas mais valiosas serão as primeiras a ir.)

Então, se você realmente quer fazer Scrum com esta equipe, é aqui que você tem que aceitar a capacidade deles de decidir como eles querem trabalhar e ter uma discussão aberta sobre como eles querem organizar sua equipe. Eles não podem despedi-lo, mas deixaram bem claro que o que está a fazer agora não está a trabalhar para eles. Você precisa ter uma conversa sobre qual será o seu papel no futuro, o que eles precisam de você, o que você precisa de você, e como tudo isso vai ser organizado. Tenha em mente que eles podem decidir como trabalhar, mas em última análise ainda há um produto que precisa de ser entregue; eles _serão julgados pela qualidade do que eles entregam. E se há coisas organizacionais que você precisa deles, eles terão que fazer essas coisas também. (Dito isto; trabalhe com eles na forma dessas coisas, e certifique-se de que são realmente necessárias antes de as fazer cumprir).

Certifique-se de que nessa reunião, não aborde as coisas com a sua autoridade; a ideia geral é colocar todos no mesmo nível. São colegas e indivíduos que têm todos um trabalho a fazer, todos querem fazer um bom trabalho e todos têm de trabalhar em conjunto no dia-a-dia. Ser um autoritário normalmente só torna as pessoas antagónicas umas com as outras, o que não é produtivo. Portanto, tentem ser vulneráveis aqui e estejam dispostos a admitir as coisas que fizeram mal. Você precisa descobrir como sair daqui como seres humanos.

Parece que a sua equipa atingiu a Storming Phase do seu desenvolvimento como uma equipa, e eles atingiram-no hard. Agora cabe à equipa (e eu estou a incluir-te nela, pelo menos por agora) descobrir como ir a partir daí. Estejam avisados; nem todas as equipas saem desta fase e eu não posso prometer que esta abordagem vai resolver o problema. Posso garantir que não será pior do que desistir ou despedir toda a gente, no entanto.

E não se esqueça de ter uma conversa com o Scrum Master separadamente. Não tenho a certeza do que o levou a abrir com uma primeira mensagem tão pouco construtiva, mas ele precisa de trabalhar na sua capacidade de comunicação e resolução de problemas.

Boa sorte com o seu situação. Vive certamente tempos interessantes; tire o melhor partido deles e aprenda o que puder com isto.

(Também estou a assumir aqui que o Scrum Master não fará com que toda a equipa se revolte contra si sem alguns problemas graves subjacentes. Se ele consegue e está a tentar fazer o seu trabalho, ele é um mestre-manipulador. Assim que chegares ao ponto em que pensas que é isso que se passa, tens de te livrar do tipo asap. Esse é provavelmente o único caso em que eu consideraria apenas usar a tua autoridade como a pessoa que o contratou e despedir o tipo).

Quer tenham ou não poder efectivo para o despedir como seu gerente, o senhor trouxe esta situação a si próprio ao ordenar uma mudança para o scrum simplesmente porque o prefere. Não a discutiu com eles. Pode ter estado dentro dos seus direitos como gerente, mas mesmo assim foi uma coisa estúpida de se fazer, e claro que agora questionam se querem continuar a trabalhar para si.

Não vê o sarcasmo na sua reivindicação de auto-empoderamento e auto-organização como a sua base para tomar tal acção?

Tem de convocar uma reunião amanhã às 9:15 e pedir desculpa por tomar uma decisão tão importante sem ter em consideração o seu contributo. Pode então pedir o seu feedback sobre como eles pensaram que o seu primeiro sprint correu e o que poderia ter sido feito de forma diferente.

Se quiser introduzir um novo fluxo de trabalho no processo desta equipa, pode tentar em menor escala, com tarefas específicas como um programa piloto, com alguns membros da equipa suficientemente abertos para lhe dar uma avaliação justa.

Com funcionários com poder de decisão, é melhor persuadir, incluir e encorajar do que mandatar.

Uma perspectiva diferente: ocorreu-te que eles estão simplesmente a gozar com o processo Scrum e com o seu aspecto “auto-organizador”? Francamente, não consigo imaginar que eles estivessem a falar a sério e tenham dado uma boa gargalhada enquanto liam o seu post. Os programadores de software (eu sou um) tendem a ser pessoas bastante cínicas com um sentido de humor seco que nem todos gostam ou mesmo reconhecem. Tenho a certeza que estavam simplesmente a dizer que não gostam de Scrum.

Talvez o melhor seria tentar falar informalmente com alguns deles sobre Scrum e as razões pelas quais não gostam.

Como @Sascha correctamente observou , isto não se parece nada com o Scrum:

• Uma equipa Scrum não tem um gestor, eles respondem a um Proprietário do Produto em vez disso. O Proprietário do Produto representa os interesses dos accionistas em relação à equipa, organiza os resultados para o sprint no início do mesmo, aceita os resultados no final e esclarece as coisas sobre os pedidos da equipa entretanto. Ele é essencialmente um representante entre a equipa e a empresa.
• Se fizesse parte da equipa Scrum, participaria numa reunião retrospectiva. Se não faz parte da equipa Scrum, a reunião deveria ter-se limitado ao seu papel em relação à equipa dentro do modelo Scrum.

Assim, a questão é: ** Onde se encontra nesta fotografia? Qual é o seu papel dentro do modelo Scrum?** Como foi você* cuja ideia de experimentar Scrum foi em primeiro lugar, você definitivamente pesquisou Scrum e pensou sobre isto antes de o sugerir, no?

E se não o fez, está na altura de fazer isto now. Arguivelmente, a transição mais perfeita para um gestor se este não for considerado parte da equipa quando se muda para Scrum* é o Proprietário do Produto.** Continuará a fazer a mesma coisa - mas agora a equipa responde-lhe colectivamente e não a cada membro individualmente, e deixa de os microgerir a menos que eles o peçam especificamente (este último é indiscutivelmente uma coisa boa para ambas as partes).

Visto que, aparentemente, fez uma pesquisa crítica falhada quando sugeriu o Scrum, calculo que não tenha arranjado um Proprietário de Produto dedicado - por isso está exactamente na posição de assumir esta função agora.

** Isto não nega o facto de que o Scrum Master ou não faz ideia do que está a fazer, ou está atrás do seu trabalho*** - que outras respostas cobriram adequadamente como fazer.

Como posso desactivar esta situação e restabelecer a minha autoridade como seu gestor, mantendo-me fiel aos princípios da auto-organização e do empoderamento da equipa?

Desde quando é o gestor desta equipa? Não creio que uma equipa se revolte contra o gestor directo por um desentendimento sobre apenas 1 tópico. A questão pode ser mais grave do que apenas o método ágil.

Isto é algo crítico para um gestor e precisa de o abordar, deve ser a sua prioridade número um para as próximas semanas.

O seu n+1, n+2 está de licença durante vários meses? talvez tenha influenciado a sua equipa a rebelar-se. Qual é a situação financeira da sua empresa? (se for má, os empregados podem pensar que está a fazer um mau trabalho e podem fazer melhor sem si)

o que fazer : - organizar uma reunião com toda a equipa : “o scrum master disse-me que me quer despedir, o que se passa? (é muito importante que dirija o tema a toda a gente, uma vez que todos o conhecem e se afecta o trabalho diário). -identificar o verdadeiro problema (apenas este método ágil ou se tem algum problema com a equipa antes?). -se conhece o verdadeiro problema, precisa de investigar: quem tem razão? você ou os seus colaboradores? -identificar quem é o líder desta rebelião (há sempre um funcionário que desafia mais as autoridades do que os outros). Se pensa que ele está a passar das marcas, precisa de tomar medidas disciplinares.

Não sei bem o que significa um “gestor” na sua empresa, mas, em geral, penso que significa alguém que ajuda as equipas a precisar e a aumentar o seu desempenho. Agora:

Sou um grande defensor da agilidade, por isso contratei um scrum master e disse que iríamos seguir o scrum.

Soa mais a ‘eu tenho uma grande ideia’, quero que o façam. Em vez de consolidar a equipa primeiro sobre a vossa ideia. Penso que todas as equipas têm o direito de criticar a vossa ideia e de abrir buracos na vossa ideia. se a vossa ideia não se aguentarem, não há problema em largá-la.

Não é certo que a ideia se aguente possa dizer à equipa que querem um período de teste e/ou migrar lentamente para a nova estrutura do projecto.

Desta forma podem ainda encontrar resistência, mas provavelmente não tanto como têm agora.

Penso resumir: Você é o seu gerente, não o seu chefe. esses são dois trabalhos muito distintos!

“O código é mais o que se pode chamar de "directrizes” do que regras reais". - Capitão Barabossa

Parece-me que tem uma situação difícil e está a tentar manter alguns ideais pouco razoáveis.

Sublinhei à equipa os benefícios da auto-organização das equipas e do empoderamento da equipa.

Explique aos seus filhos que a auto-organização e o empoderamento não significa que eles possam fazer o que quiserem. Se a sua equipa decidiu ir roubar algumas armas automáticas e roubar um banco, não é obrigado a seguir em frente com eles só porque eles têm poder.

Eles não podem “disparar” contra si. Esse é o papel do seu treinador. Os disparos vêm sempre de cima da cadeia, não de baixo. Claro, eles podem saltar degraus na hierarquia e trabalhar com o seu chefe para o remover, mas como aparentemente o seu chefe e o seu chefe estão ambos de licença sem ter colocado qualquer alguém na sua ausência, não há muita hierarquia a que ir. Tens alguns meses.

Eu disse ao scrum master que gostaria de falar com a equipa sobre isto, mas ele ficou firme que eles se sentiram “intimidados” quando eu estava na sala, e não quis discutir isso comigo.

Bem, isso é muito mau para eles. Fale com eles de qualquer maneira. O auto-poder pode dar-lhe a capacidade de tomar as suas próprias decisões, mas não o liberta da responsabilidade de estar à altura dessas decisões. Se eu tivesse uma equipa assim, falar com eles seria o nível de resposta mais kindest que eu consideraria.

Poder-se-ia dizer “Oh, mas o mestre SCRUM é suposto resolver impedimentos como este. Tudo deveria passar por ele”. Bem duro. Ele estragou tudo quando foi ter contigo para te dizer que foste despedido e não o fizeste de uma forma suficientemente cortês para que o aceitasses. Espera-se que um mestre de SCRUM tenha melhores competências do que isso.

Então o que dizes?

Primeiro, queres descobrir se eles decidiram realmente “despedir-te”. Tem a palavra de uma pessoa sobre isso, e eu acredito que este é o tipo de situação em que a equipa deve ser capaz de dizer directamente a sua parte.

Em segundo lugar, considere o que significa “despedir”. V. Exa. afirma ser um treinador, mas eles querem que vá embora. Não estão a escrever os cheques, por isso a decisão de te despedir não é uma decisão do tipo “oh eles não estão a fazer o seu trabalho”. É uma decisão do tipo “esta pessoa está a meter-se activamente no caminho”. Algo realmente não está a fazer sentido aqui. Você necessário que faça soma para você antes de tomar qualquer decisão significativa. Sendo uma pessoa anónima na internet, não posso dizer se é você ou eles ou o mestre do SCRUM, mas alguma coisa está realmente muito errada neste cenário, e é melhor saberes o que é quando acabares de falar com eles.

Trabalha com eles. Seja um gerente. Encontre uma maneira de resolver o problema. Encontre uma forma de poder fazer o seu trabalho, enquanto eles fazem o deles. Faça acontecer.

Agora, se as respostas deles lhe derem o encerramento suficiente para honrar o seu auto-poder, agora tem de mostrar à equipa o que acontece quando se “despede” uma liderança como essa. Diga “Muito bem”. Eu deixo de agir como seu gerente. Você não pode actualmente despedir-me, porque essa não é a sua posição, mas se quiser jogar este jogo, nós podemos jogar. Eu fui o teu manager, ajudando a isolar-te da política da empresa e do stress de reportar à gestão superior. Agora, eu sou a sua gestão de topo e já não tem esse isolamento. Agora, uma vez que não me consigo afastar desta posição, vou simplesmente começar a transmitir as tarefas do alto". Explique que só porque a equipa votou, isso não significa que não tenha obrigações para com a gestão superior que tenha de cumprir, e continuará a fazê-lo.

Então, procure ajuda.

Um motim não é uma coisa pequena. Toda a sua equipa acabou de votá-lo para fora da ilha. Não o subestime. Procura alguém acima de ti para te ajudar. Talvez chames o teu chefe de licença. Talvez você fale com o seu CIO. Alguém precisa de saber que há um problema maior de pessoas na tua empresa, e que estás a resolvê-lo. A segunda metade é claramente importante. Nunca vá à liderança com problemas, vá a eles com soluções.

A solução que eu recomendaria é criar a sua imagem de “gestor com requisitos”, escolhendo coisas que exijam que a liderança (ou seja, o CIO) queira, que é criada para construir alguma auto-realização para ir com esta auto-potência. Eles podem pensar que são livres de fazer o que querem, mas você ainda é obrigado a fazer deles uma equipa de sucesso._ Se você tem de o fazer de longe, faça-o de longe. Descubra o que é que a sua abordagem de mãos livres foi tão intimidante e certifique-se de que nunca o faz.

O objectivo final é levá-los a perceber que você está do lado deles. Se eles são verdadeiramente auto capacitados, então eles precisam de chegar à conclusão de que você é uma parte benéfica da equipa. Eles só chegarão a essa realização se forem bem sucedidos. Se eles forem inundados pelo impossível prazos e burocracia sem esperança, eles nunca o verão.

Basta ter a certeza de que tudo se soma. 2+2=4. Um gerente “mãos fora” é “despedido” pelo novo mestre SCRUM por ser demasiado intimidante enquanto dois níveis de gestão estão de licença? Algo não faz sentido a partir daqui. Está mais próximo da situação. Descubra o que não bate certo, e resolva-o.

Ou: a) Eles têm razão e o senhor não conseguiu justificar a sua existência. (Eles ainda não te podem despedir) ou b) O scrum master quer o teu trabalho.

Penso que a melhor coisa a fazeres é ires fazer um curso de scrum master de 2 dias e livrares-te do teu scrum master. Provavelmente podes receber um bónus no final do ano por fazeres dois trabalhos.

Não existe um papel de gerente numa equipa scrum. A verdadeira questão é porque pensou que era um membro da equipa em primeiro lugar. Se não está a participar na entrega de funcionalidades, não tem lugar nessa equipa - por isso o que a equipa fez foi correcto.

Se eles o consideram um impedimento, descubra porquê - o cenário provável é que estava a interferir, e a solução é que se desmarque e os deixe fazer o seu trabalho.

O que é que você pensa que o seu papel é na equipa? Arranje uma resposta útil que esteja alinhada com os objectivos do scrum, e depois sublinhe à equipa que pretende fazer esse trabalho, e não interfira com o deles.

Então não vejo por que razão não pode ver isto como algo positivo? O meu entendimento é que o objectivo de uma equipa de autogestão ** é não precisar de um gestor**.

O que precisa de fazer é olhar para as oportunidades que isto apresenta. Basicamente tem uma super equipa que consegue gerir-se a si própria e agora é capaz de fazer o seguinte:

• É capaz de responsabilizar a equipa pelos compromissos da empresa mais facilmente. Se eles não conseguem cumprir os objectivos da empresa, então simplesmente não podem ser auto-gerentes
• Você é capaz de aumentar as competências da equipa. Por isso agora pode concentrar-se mais no aspecto das pessoas da equipa. Crescimento de carreira, capacitação e esse tipo de coisas.
• Perceba que a equipa + scrum master ainda são responsáveis perante si na hierarquia da empresa, nos orçamentos e no processo de avaliação de desempenho. Por isso não é como se eles pudessem passar por cima de si.

Pense nisto como um sucesso por agora. Pense mais nas oportunidades de como você pode fortalecer a equipe. ** Também perceba que precisa de estar presente no cenário em que esta abordagem de autogestão falha.**

Lao Tzu disse

O líder mau é s/he que o povo despreza,

O bom líder é s/he que o povo venera,

Quando um grande líder lidera, as pessoas dizem “nós próprios o fizemos”.

Um líder é melhor quando as pessoas mal sabem que ele existe,

quando o seu trabalho é feito, o seu objectivo cumprido,

eles vão dizer: nós próprios o fizemos.

e eu tenho seguido esta máxima basicamente desde o primeiro dia de liderar equipas de desenvolvimento. Se todos sabem o que fazer, então eu não sou necessário e o meu trabalho é melhor servido desta forma - desfrutar da vida fora do escritório.

Segue as métricas, audita o seu código, faz pequenas correcções de curso, encoraja e permite o que quer que seja necessário - comunicação, cooperação, testes de escrita, etc., protege-os da gestão superior e dos clientes - e, idealmente, nunca age.

Mas quando o fazes, fazes e dás pontapés nos narizes quando necessário, afinal és o responsável pelo seu trabalho - as pessoas são despedidas por tua recomendação e despedem-te, e a tempo.

Não tenho a certeza porque é que qualquer programador despediria alguém que não está no seu caminho e que está basicamente lá para os consertar e proteger dos clientes e, ocasionalmente, até mesmo dos mais altos, toma conta da disponibilidade do equipamento, da documentação, dá um empurrão cada vez mais leve para serem melhores programadores e melhores pessoas e permite-lhes concentrarem-se no código.

Você continua a ser o mais alto - ainda pode despedi-los se precisar, não foi despedido desta posição. Só foste considerado inútil ou prejudicial ao esforço de desenvolvimento e eles preferem jogar sem ti.

Ou isto ou há alguma patologia séria a acontecer com a cultura da equipa.

Eu diria que é uma oportunidade incrível para alguma grande reflexão e crescimento.

Posso ver aqui dois pontos de vista:

• Você foi o director de linha de uma equipa de desenvolvimento numa organização matricial, e continua a ser o gestor de linha. O seu trabalho pode ter mudado um pouco, mas é fundamentalmente o mesmo - fornece dias-homem de desenvolvimento ao PO de acordo com os processos de orçamentação/RH da empresa, trata da contratação (e se necessário, despedimento), agenda folhas em cooperação com a equipa, etc. Num desenvolvimento ágil, o seu papel pode ser um pouco menos maluco do que costumava ser, mas especialmente se existirem múltiplas equipas de scrum, o seu papel incluirá agora coisas como encorajar “comunidades de prática” ou “guildas”. Como tudo, o scrum pode ser prejudicial se levado a extremos, e alguém deve ter cuidado, por exemplo, que as pilhas de tecnologia permaneçam compatíveis, a menos que haja uma razão muito boa para abrir uma excepção. Essa é a função da gestão de linha numa organização deste tipo.
• Você era um membro da equipa de desenvolvimento e tinha um contributo directo para as decisões tecnológicas, arquitectura, etc. Nesse caso sugiro que faça asneira por não se ter envolvido o suficiente neste primeiro sprint, porque eles não vêem como vai contribuir com as suas competências para a equipa. No próximo sprint, trabalhe com a equipa.

Sou um gestor de uma equipa de desenvolvimento.

Sou um grande defensor da ágil

Boa! Se por “ágil” quer dizer “Scrum” (porque teria contratado um Scrum Master, senão…), então está tudo bem.

Eles têm seguido historicamente uma metodologia muito cascata e têm sido resistentes à mudança.

a equipa concordou colectivamente em “despedir-me” como seu manager

Óptimo! Eles mudaram os seus caminhos; deixaram cair a sua resistência (não nos disse a que resistiam, antes…). Eles aprenderam os papéis que envolvem uma Equipa Scrum.

Como certamente sabe, um gestor só tem uma responsabilidade muito remota no contexto de uma Equipa Scrum; você não é o Scrum Master, nem o Dono do Produto, nem um dos Stakeholders, nem parte da própria Equipa Scrum. Lembro-me quando recebi o meu certificado Scrum Master num seminário de 3 dias; o papel de “manager” nem sequer estava no gráfico.

Se a sua empresa utiliza a típica estrutura matricial de gestão de linhas verticais vs. gestão horizontal relacionada com o projecto (ou produto) (i.e. line manager <> gestores de projecto/produto), então tudo parece estar a correr de acordo com o planeado. Você ainda terá responsabilidades de gestão, ou seja, gerir tudo o que está fora do trabalho produtivo diário da sua equipa.

Deixe-me repetir a sua frase chave:

Eu sou um grande proponente do agile

Agora é um bom momento para abraçar isso, e aprender o que significa gerir uma Equipa Scrum. As suas responsabilidades também se alteraram agora. Você faz as coisas do costume (entrar com novos membros, lidar com o salário, ajudar a sua equipa a poder trabalhar (arranjar-lhes o hardware/software/etc. e um bom ambiente de trabalho), talvez colaborar com outros gestores Scrum). O facto de a sua empresa parecer reconhecer as unidades organizacionais não mudou. Os membros da sua equipa continuarão a precisar de falar consigo; apenas não sobre o trabalho deles.

Dependendo do que fez antes como o seu trabalho diário (distribuir pacotes de trabalho para os diferentes departamentos), talvez queira olhar para outras coisas que possa fazer. Por exemplo, você pode ter uma palavra a dizer em que projetos a sua equipe(!) trabalha, ou se um Proprietário de Produto ficar desagradável de alguma forma, pode ser o seu trabalho acalmá-lo. Podes ser responsável pela gestão dos contratos dos clientes (vendas, etc.). Você será um parceiro e um escudo para a sua equipa em caso de escaladas. Você está a gerir. Gerir não é o mesmo que desenvolver software; e atribuir tarefas a pessoas individuais é apenas uma pequena parte.

Francamente, eu diria que tem muita sorte. Ande na onda. Deixe-os fazer o que têm a fazer. Evite gerir o seu novo Scrum; o Scrum foi feito exactamente para tornar a equipa auto-suficiente e capaz de actuar sem uma microgestão constante do exterior. Muitas partes do Scrum são feitas para proteger uma equipa de uma gestão indesejada.

O seu trabalho pode agora ser muito fácil. Se tudo funcionar como planeado, eles vão lidar com muitas coisas que você tinha que fazer antes. Todos podem ficar muito felizes a partir de agora, especialmente se não gostaram da sua microgestão antes.

a equipa concordou colectivamente em “despedir-me” como seu director

Obviamente, estou a assumir que desde que citou a palavra “fogo”, eles não enviaram literalmente um e-mail para os RH para o excluir da folha de pagamentos, mas disseram-lhe que querem viver Scrum em toda a sua extensão (e intenção). Obviamente, estou a assumir que eles não querem realmente cortar as linhas do organigrama da sua empresa. Mesmo uma equipa Scrum pura precisa de estar enraizada algures na empresa, isto é, fazer parte da gestão de linhas, e isso é você. Você simplesmente não está mais envolvido no dia-a-dia da empresa.