Agile é o novo microgerenciamento?

Essa pergunta está me incomodando há um tempo, então eu queria perguntar àqueles que estão seguindo as práticas ágeis / scrum em seus ambientes de desenvolvimento.

Minha empresa finalmente se aventurou a incorporar práticas ágeis e começou com uma equipe de 4 desenvolvedores em um grupo ágil, em caráter experimental. Foram 4 meses com 3 iterações e eles continuam a fazê-lo sem ficar totalmente ágil para o resto de nós. Isso se deve ao fato de a confiança da gerência atender aos requisitos de negócios com uma solicitação bastante ad-hoc do tipo acima.

Recentemente, conversei com os desenvolvedores que fazem parte dessa iniciativa; eles me dizem que não é divertido. Eles não têm permissão para conversar com outros desenvolvedores pelo seu Scrum master e não têm chamadas telefônicas na área de trabalho (o que pode ser bom até certo ponto). Por exemplo, se eu quiser conversar com meu amigo sobre chutes que faz parte do time ágil, não tenho permissão sem a aprovação do Scrum master; que está sentado ao lado da equipe ágil.

A idéia de tudo isso ou o ágil é fornecer um vácuo completo para os desenvolvedores ágeis de qualquer interrupção e tê-los em boas 6 ou mais horas produtivas. Bem, pessoal, eu não sou um guru ágil, mas o que eu li sobre o documento de distribuição ágil do Yahoo e similar para outras organizações, me dá a sensação de que o ágil não é barato. Requer recursos e orçamento para instilar as equipes de maneira ágil e corrigir os problemas à medida que chegam para colocá-los de volta aos trilhos.

Para iniciantes, requer treinamento para desenvolvedores e treinamento para gerentes e etc, etc ... O atual Scrum master era um gerente que fazia alguns dias de aulas de treinamento ágil, pagas pela gerência, que agora lideram essa equipe ágil. Eu também ouvi na reunião que o manifesto ágil não determina que o ágil não é imutável e é personalizado de maneira diferente para cada empresa. Bem, tudo soa bem e razão.

Em conclusão, sempre achei que o ágil deveria trazer harmonia às equipes de desenvolvimento, o que resulta em desenvolvedores felizes. No entanto, estou tendo uma sensação muito oposta ao conversar com os desenvolvedores da equipe ágil. Eles estão tristes por não poderem falar nada além de trabalhar, ficarem quietos o dia todo trabalhando, e sentem que é apenas outra maneira de a gerência fazê-los trabalhar mais.

Diga-me, por favor, se este é um dos exemplos de boas práticas usadas com o objetivo de obter uma vantagem egoísta por mais dólares? Ou talvez, somos apenas nós, os desenvolvedores como eu, e essa equipe ágil acha que não gosta de trabalhar em um ambiente em que apenas respira trabalho porque está trabalhando.

É uma empresa no domínio da saúde, com escritórios nos EUA. Definitivamente, parece um estilo ágil de caubói, o que me faz realmente não querer ser ágil, principalmente na minha empresa atual.

Tudo isso tem a ver com a gestão ser completamente barata. Cortar café caro para uma versão mais barata, ênfase na economia e ser produtivo, mantendo-se o mais enxuto possível.

Meu sentimento é que alguém da gerência atrás da porta jogou fora essa ideia, que o ágil faz você produzir mais para que possamos mostrar aos nossos chefes que estamos produzindo mais com o mesmo número de funcionários. Ou, talvez, nos permita reduzir o número de funcionários, se for esse o caso.

Eles estão tendo sua reunião diária de 5 minutos. Mas não é permitido conversar ou conversar com alguém fora da equipe. Todo o foco está no trabalho.

Você está descrevendo a ditadura gerencial, não a agilidade. Agile é sobre desenvolvimento incremental em um campo de requisitos em mudança, não sobre ditar as pessoas como elas individualmente realizam seu trabalho.

Eles não têm permissão para conversar com outros desenvolvedores pelo seu Scrum master e não podem receber chamadas telefônicas na área de trabalho

Isso realmente não faz parte das práticas ágeis - e uma questão separada.

Uma grande motivação das metodologias ágeis é o aumento da comunicação entre os desenvolvedores. Restringir a comunicação do desenvolvedor <-> desenvolvedor é um problema separado das práticas ágeis. Não estou dizendo que isso não está acontecendo - obviamente está, e está sendo rotulado como parte do lançamento "ágil" da sua organização, mas esse é realmente um problema separado do ágil (e um pouco contra o espírito do desenvolvimento ágil, OMI).

Isso soa como uma implementação bastante perversa do ágil. O Agile, se houver, deve reduzir o microgerenciamento, não aumentá-lo. A equipe se compromete e parte do processo é que a gerência confia que a equipe o cumprirá. O scrum diário é uma maneira de os desenvolvedores se comunicarem entre si e uma maneira de informar o que eles fizeram, não como eles gastaram seu tempo (que é um erro que eu já vi em alguns lugares). Mesmo o processo de estimativa deve remover o tempo explícito, mantendo as estimativas, já que você deve estimar a complexidade relativa, não o tempo que uma história levará (outro erro comum). Controlar o tempo gasto pelos desenvolvedores é a marca do microgerenciamento, e remover o tempo do processo é um dos princípios básicos do ágil.

O ambiente que você descreve parece uma besteira pseudo-ágil de variedade de jardim .

Eu me envolvi com o Agile antes que fosse Agile. Por volta de 2000, eu estava esgotado com a codificação, ouvi falar sobre Extreme Programming, tentei e gostei. Ele me proporcionou como desenvolvedor um contexto em que a produção de software sólido era a coisa mais importante e me deu ferramentas para minimizar muitas besteiras que estavam me deixando louco. Eu amei.

O problema hoje, que explico em detalhes em outro lugar , é que a maioria das pessoas que "adota o Agile" hoje em dia não está interessada em melhorar nada, se isso as deixa desconfortáveis. Então, para eles, "Agile" é apenas um novo recurso para vencer os desenvolvedores da mesma maneira antiga. Em vez de, digamos, uma maneira de aumentar radicalmente a produtividade e remover todas as besteiras que estão atrasando o desenvolvimento.

Agora mesmo. Estou iniciando uma empresa e vou usar muito XP, além de vários outros truques que aprendi no mundo ágil. Mas, precisamente por causa de histórias como a sua, eu me encolho sempre que ouvi sobre uma adoção do Agile hoje em dia.

Então, para responder sua pergunta diretamente: Agile não deve ser o novo microgerenciamento. Deveria ser sobre capacitar as pessoas que estão fazendo o trabalho real para fazer merda. Mas no seu caso, o Agile parece a mentira mais recente que eles estão dizendo, enquanto desfrutam de seus próprios instintos ruins. Pelo qual realmente sinto muito.

Isso não é ágil.

Em primeiro lugar, Scrum não é ágil . Scrum, francamente, é besteira. Fui criado em uma casa de Extreme Programming (literalmente - tive Kent Beck sentado no sofá do meu pai e conversando comigo sobre os testes), e posso dizer diretamente que Scrum não é. Scrum é uma ferramenta de gerenciamento de projetos - um ritmo definido para um projeto de desenvolvimento. Mas não há nada a dizer sobre o desenvolvimento em si e muito pouco a dizer sobre requisitos, planejamento e relacionamento com o cliente. XP tem muito a dizer sobre tudo isso; qualquer outra metodologia que queira se chamar ágil precisa ter algo a acrescentar à conversa. Os proponentes do Scrum o descreveram não como um processo, mas como um invólucro para um processo. Um homem sábio uma vez apontou que um invólucro é a coisa que você remove e descarta para obter as coisas boas.

Ok, scrum falou alto!

Em segundo lugar, um princípio fundador do XP, que acredito ser fundamental para qualquer processo ágil, é que ele esteja centrado no desenvolvedor . É uma maneira de dar aos desenvolvedores o poder de fazer o trabalho que eles sabem que precisam fazer, e são frequentemente impedidos de fazer. Uma equipe ágil pode ser estruturada como uma democracia ou uma autocracia, mas os líderes são desenvolvedores. Existem funções para gerentes de projeto e assim por diante - funções vitais - mas não são de liderança de equipe. Ter um gerente - desculpe, 'scrum master' - sentado lá mandando as pessoas ao redor é um sinal claro de que a equipe não está agilizando.

Eu sinto que deveria haver um terceiro. Não existe.

Scrum é o filho bastardo de Agile. É o estilo mais cascata de todas as metodologias ágeis, e é por isso que é o mais popular entre os gerentes.

Todos os métodos ágeis são sobre a produção de código de trabalho sem porcarias. Leia isso de novo. E de novo.

Qualquer coisa que atrapalhe esse objetivo, independentemente das "regras ágeis", é ruim. Se as regras atrapalharem, mude as regras f * * ! Essa é a maneira ágil, é o que a torna relevante e eficaz.

O melhor exemplo disso é dado por Alistair Cockburn (um dos criadores do manifesto ágil):

“Coloque 4-6 pessoas em uma sala com estações de trabalho e quadros brancos e acesso aos usuários. Faça com que eles entreguem software testado e em execução aos usuários a cada um ou dois meses e os deixem em paz. ”

Se isso funciona para a qualidade dos caras que você tem, então é tudo o que você precisa. Você não precisa de um scrum master ou de qualquer metodologia "ágil". Se sentar-se em um scrum diário funciona para você, então f * * * fazê-lo. Fazer você se levantar é apenas uma revogação patética de sua capacidade de pensar por si mesmos.

Há uma resposta para o tipo de agilidade que você está fazendo. É isso. Imprima e prenda em algum lugar quando não houver mais ninguém por perto e deixe que descubram por si mesmos.

O atual Scrum master era um gerente que fazia alguns dias de treinamento em ágil, pago pela gerência, agora lidera essa equipe ágil.

Esse é o seu problema. Os gerentes querem um pouco de Agile, não sabem realmente o que é e o impõem às equipes. Isso é basicamente o que fazer quando você deseja diminuir significativamente a produtividade de seus desenvolvedores;)

A nova proposta de processo deve vir dos desenvolvedores. Ou pelo menos ser revisto e aprovado por eles, se for uma idéia da gerência.

De qualquer forma, se os desenvolvedores recusarem, não implemente ! Ou será o desastre que você descreve.

O "Agile" e todas as outras "metodologias de gerenciamento" são frequentemente abusadas para forçar o microgerenciamento das pessoas. Às vezes, também é abusada a OTOH para defender o acabamento inadequado.

"somos ágeis" é a desculpa mais frequente que escuto por falta de planejamento, falta de pensamento sobre design, recursos, qualidade e ciclos de lançamento. Isso geralmente é de desenvolvedores e gerenciamento inferior. É loucamente também a desculpa mais usada que ouço de gerentes de nível médio, arquitetos, vendedores etc. para microgerenciamento, prazos e listas de características sempre em constante mudança, forçando horas extras do massiver nas pessoas (os prazos e características constantes em constante mudança garantem que, é claro) etc. etc. .

Os dois obviamente estão em contradição direta e podem acontecer no mesmo projeto.

Para responder à sua pergunta original, o Agile é o novo microgerenciamento, eu diria que não.

Primeiro, leia este (manifesto Agile) e você notará que não está falando com seus co-desenvolvedores não está listado.

Na verdade, "Indivíduos e interações" é exatamente o oposto de não falar com seus co-desenvolvedores.

Agile deve ser o novo autogerenciamento. Se o ágil for praticado corretamente, muitas das decisões serão tomadas por um cliente e desenvolvedor que trabalha com uma história de usuário com escopo razoavelmente adicionado ao backlog à medida que as tarefas são identificadas.

O scrum diário é sobre comunicação, não gerenciamento. Haverá algumas discussões sobre prioridade e balanceamento de carga, mas a pessoa gerenciada no scrum é esperançosamente o mestre do scrum. Como desenvolvedor, assisto, digo o que fiz, o que vou fazer e de que ajuda preciso. Então o scrum master deve entrar em ação, eliminando impedimentos ao meu progresso.

As equipes ágeis não devem sentir que o trabalho diário é gerenciado hierarquicamente. Se as decisões são tomadas de longe por alguém no topo de uma organização hierárquica, é hora de descentralizar a tomada de decisões! Para algumas pessoas e algumas organizações, isso pode ser uma ponte longe demais. Se o seguinte não se aplica à sua organização:

Viva o manifesto ágil

"Estamos descobrindo maneiras melhores de desenvolver software, fazendo isso e ajudando outras pessoas a fazê-lo".

Evite "Conheça o novo chefe, o mesmo que o antigo chefe". Crie o Agile de dentro da equipe o máximo possível. Às vezes, isso acontece escolhendo uma coalizão de dispostos a participar de um projeto de teste usando o Agile. Se você pode formar sua equipe Agile a partir de voluntários ou membros convidados que tenham um histórico de bom trabalho em equipe, eles podem resolver isso. Use uma equipe pequena em um projeto curto, talvez para um cliente interno ou altamente acessível.

Aceite a mudança. Talvez você possa fazer algum treinamento, mas talvez seu orçamento seja pequeno e o dinheiro simplesmente não esteja lá. Outras oportunidades também podem melhorar. Faça alguma leitura, peça aos membros da equipe que aprendam o que podem sobre o Agile e ensinem uns aos outros. Você pode encontrar uma equipe nova ou existente qualificada para modelar e liderar na adoção do Agile.

Equipes ágeis são como times de futebol trabalhando em direção a um objetivo comumente entendido. Faço parte de equipes ágeis há alguns anos e a chave é a comunicação eficaz e eficiente entre todos os interessados. Os gerentes / mestres de Scrum são meros facilitadores da equipe e a gestão / microgestão tradicional matará o espírito da equipe.

Nas equipes em que trabalhei, somos incentivados a jogar jogos em equipe após o horário de trabalho para melhorar a camaradagem entre os membros. Eu coletei esses pensamentos aqui .

Para responder à sua pergunta: Não. O Agile não é uma forma de microgerenciamento. Mas, como qualquer ferramenta, as pessoas podem usá-la incorretamente. O Agile é maravilhoso quando implementado corretamente e quando as pessoas são consistentes com ele.

Meus pensamentos sobre o tópico "Os desenvolvedores não estão falando com ninguém além do scrum master":

Eu trabalhei em um lugar onde isso era uma regra antes. No entanto, a regra estava mais relacionada a pedir às pessoas para concluir tarefas. Por exemplo, não posso ir aleatoriamente a um testador de desenvolvimento e pedir que ele faça alguns testes para mim nas próximas horas. Preciso conversar com o scrum master para que eles possam discutir com o membro da equipe como esse trabalho se encaixará no sprint se for uma emergência (ou se precisar ser enviado ao backlog para um sprint futuro).

Nesse caso, entendi o conceito de "desenvolvedores que não falam um com o outro" porque ele realmente se traduzia em canalizar tarefas por meio de um ponto de verificação, para que um desenvolvedor em particular não estivesse sobrecarregado ou estivesse tão ocupado executando tarefas de emergência que não conseguiria planejar Trabalho feito.

Caso contrário, os desenvolvedores DEVEM estar conversando entre si. Sempre. Ele ajuda você a resolver os problemas mais rapidamente, se aproximar como uma equipe e entregar mais rapidamente.

Só para oferecer outra perspectiva: eu também já estive em um ambiente em que as pessoas pensavam que os desenvolvedores "conversavam demais". Após uma sessão, descobrimos que, na verdade, traduzidos para "desenvolvedores não são independentes o suficiente para realizar seu próprio trabalho. Como tudo é tão fragmentado, os desenvolvedores precisam procurar outras três pessoas para realizar tarefas pequenas".

Portanto, quando os gerentes decidiram mudar para o ágil, eles esperavam que isso ajudasse a levar as informações aos lugares certos e interromper muita fragmentação dentro da organização. Algumas pessoas ficaram meio decepcionadas que, depois que o Agile foi implementado, os desenvolvedores ainda estavam correndo um para o outro. Mas o que eles não perceberam é que isso acontecia cada vez menos. Demorou um pouco. Então, talvez se isso é o que está acontecendo na sua organização, pode ser que as pessoas esperem que sejam ágeis para consertar as coisas da noite para o dia. Não é assim que funciona.

O autor original Smith Janes pode ter dado experiência. Mas esses são os problemas típicos que encontrei no projeto Agile.

1. Na maioria das organizações, os desenvolvedores devem trabalhar em vários projetos, no Agile / Scrum. Sprints nunca são considerados esse fato. seu Scrum Master assume que você deve terminar suas histórias no final do sprint. Seu Scrum Master pode ser dedicado a apenas um projeto, mas não aos desenvolvedores. ESTA É A DISTRACÇÃO-- não precisa ser apenas uma ligação telefônica ou permitindo uma ligação.
2. Eu vi projetos Agile nos quais o Sprint é planejado, as histórias incluídas no Sprint, sem ser encolhidas ... no meio ou no meio dos sprints .. desenvolvedores descobrindo dependências não resolvidas, requisitos ou história não concluída, narrada ... é um dos abusos na maioria dos projetos ágeis.
3. Teste: TTD .. sim, é muito bom .. mas eu vi a maioria dos projetos Agile confiando totalmente no TTD ... nenhum escopo ou tempo permitido para testes funcionais ou humanos .. Outro abuso ... Muitos Scrum Masters também não conhece nem entende a importância dos testes funcionais. Seu pedaço de código pode estar funcionando perfeitamente, se não atender às necessidades da empresa .. é inútil .. Isso acontece quando a empresa não participa bem à frente .. ou a participação existe ... mas não reflete a tomada de decisão da empresa .. No final, os desenvolvedores são culpados, você não entregou a funcionalidade .. ou ela terminará com alterações de última hora ... horas extras porque o mestre do Scrum não quer se responsabilizar pela história não concluída.

Abuso aqui ... baixa participação de negócios ou participante não totalmente conhecedor ou pessoa de negócios que está desistindo no meio do sprint.

1. Nem todos os projetos são adequados para o Agile ... A maioria dos gerentes ou scrum master não sabe disso. Projetos de manutenção. Um defeito pode ser inicialmente assumido, que pode ser feito em 8 horas, aceito no sprint. Depois de quatro horas, descobri que este é o Java / outro produto ... (recentemente, enfrentei um defeito relacionado ao Quartz Scheduler .. dentro do nosso projeto) e esse defeito pode levar à atualização do produto / pacote .. lidar com burocracia, aprovação, financiamento, nova versão ou atualização deve ser aprovada pela Engenharia Interna etc., 5.Retrospecção: somente alguns projetos Agile executam esta etapa.
2. Emparelhamento .. Muitos desenvolvedores tratam o emparelhamento como um local para abusar dos colegas de trabalho .. criticam outro design, práticas de codificação .. avaliam o tratamento como trabalho em equipe. Aprendem uns com os outros ... Outra maneira de abusar do Agile / Scrum.

Agile é definitivamente uma boa metodologia. A menos que sua organização não siga completamente ou não seja treinada ... É abusada .... efeitos colaterais 60+ horas / semana de trabalho, jogo de culpa, baixa moral.

Agile é microgerenciamento disfarçado. Não há lugar para iniciativa ou criatividade no Agile, ele removeu a diversão da programação para permitir que gerentes incompetentes mantivessem o controle, mesmo sem ter uma pista do ponto de vista técnico.