O Agile é o novo microgerenciamento?

76

Esta pergunta está cozinhando na minha cabeça há algum tempo, então eu queria perguntar para aqueles que estão seguindo 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 sem agilidade para o resto de nós. Isso se deve ao fato de que a confiança da administração atende aos requisitos de negócios com um grande número de solicitações de tipo ad hoc do alto.

Recentemente, conversei com os desenvolvedores que fazem parte dessa iniciativa; eles me dizem que não é divertido. Eles não estão autorizados a conversar com outros desenvolvedores pelo seu Scrum Master e não podem fazer chamadas telefônicas na área de trabalho (o que talvez seja bom até certo ponto). Por exemplo, se eu quiser falar com meu amigo sobre os chutes que estão no time ágil, eu não tenho permissão sem a aprovação do Scrum Master; quem está sentado ao lado do time ágil.

A idéia de tudo isso ou do ágil é fornecer um vácuo completo para os desenvolvedores ágeis a partir de qualquer interrupção e fazer com que eles tenham 6 ou mais horas produtivas. Bem, pessoal, eu não sou um guru ágil, mas o que tenho lido o documento de lançamento ágil do Yahoo e similar para outras organizações, dá-me a sensação de que ágil não é barato. Ela exige recursos e orçamento para incutir agilidade às equipes e corrigir o problema à medida que elas chegam para colocá-las de volta nos trilhos.

Para começar, é necessário treinamento para desenvolvedores e coaching para gerentes e etc, etc ... O atual Scrum Master foi um gerente que levou alguns dias e que a classe de treinamento ágil paga pela gerência agora está liderando essa equipe ágil. Eu também ouvi na reunião que o manifesto ágil não dita que o ágil não é definido em pedras e é personalizado de forma diferente para cada empresa. Bem, tudo soa bem e razão.

Em conclusão, sempre achei que o agile deveria trazer harmonia nas equipes de desenvolvimento, o que resulta em desenvolvedores felizes. No entanto, estou tendo um sentimento muito oposto ao falar com os desenvolvedores da equipe ágil. Eles estão insatisfeitos por não poderem falar nada além de trabalhar, sentados em silêncio o dia todo, apenas trabalhando, e acham que é apenas mais uma forma de fazer com que a gerência trabalhe mais.

Diga-me, por favor, se este é um dos exemplos de boas práticas usadas com o propósito de vantagem egoísta por mais dólares? Ou talvez, somos apenas os desenvolvedores como eu e essa equipe ágil sente que eles não gostam de trabalhar em um ambiente onde só respiram trabalho porque estão no trabalho.

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

Tudo isso tem a ver com o gerenciamento ser completamente barato. 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 na gerência atrás da porta jogou fora essa idéia, que á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 o caso.

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

    
por 5 revs, 4 users 68%Smith James 16.08.2018 / 21:23
fonte

14 respostas

87

Você está descrevendo a ditadura gerencial, não é ágil. Ágil é sobre desenvolvimento incremental em um campo de requisitos variáveis, não sobre ditar as pessoas como elas individualmente fazem seu trabalho.

    
por 15.03.2011 / 18:08
fonte
46

They are not allowed to talk to other developers by their Scrum master and are not allowed to take any phone calls in the work area

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 com o < - > é uma questão separada das práticas do Agile. Não estou dizendo que isso não esteja acontecendo - obviamente, e está sendo rotulado como parte da implementação "ágil" em sua organização, mas isso é realmente um problema separado do ágil (e um tanto contra o espírito do desenvolvimento ágil, IMO).

    
por 15.03.2011 / 18:04
fonte
31

Isso parece uma implementação bastante perversa de agilidade. Ágil, se qualquer coisa, deveria reduzir o microgerenciamento, não aumentá-lo. A equipe assume um compromisso e parte do processo é que a administração confia que a equipe irá realizá-lo. O scrum diário é uma maneira de os desenvolvedores se comunicarem uns com os outros 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 das estimativas, uma vez que você deve estimar a complexidade relativa, e não quanto tempo uma história levará (outro erro comum). Controlar o tempo gasto pelos desenvolvedores é a marca do microgerenciamento, e a remoção do tempo do processo é um dos principais princípios da agilidade.

    
por 15.04.2015 / 17:05
fonte
23

Isso não é ágil.

Primeiramente, o Scrum não é ágil . Scrum, francamente, é besteira. Eu fui criado em uma casa Extreme Programming (literalmente - eu tive Kent Beck sentado no sofá do meu pai e conversando comigo sobre testes), e eu posso te dizer que o Scrum não é isso. O Scrum é uma ferramenta de gerenciamento de projetos - um ritmo definido para um projeto de desenvolvimento. Mas não tem nada a dizer sobre o desenvolvimento em si e muito pouco a dizer sobre os requisitos, o planejamento e o 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 defensores do Scrum descreveram isso 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 chegar às coisas boas.

Ok, fale sobre scrum!

Em segundo lugar, um princípio fundador do XP, que acredito ser fundamental para qualquer processo ágil, é que ele está centrado no desenvolvedor . É uma maneira de dar aos desenvolvedores o poder de fazer o trabalho que eles sabem que precisam fazer, e são tão freqüentemente impedidos de fazer. Uma equipe ágil pode ser estruturada como uma democracia ou uma autocracia, mas os líderes são desenvolvedores. Existem papéis para os gerentes de projeto e assim por diante - papéis 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 há.

    
por 16.03.2011 / 00:24
fonte
23

O ambiente que você descreve soa como uma variedade de jardinagem pseudo-Agile bullshit .

Eu me envolvi com o Agile antes de ser Agile. Por volta de 2000, eu estava esgotando a codificação, ouvi falar sobre Extreme Programming, tentei e gostei. Isso me deu como desenvolvedor um contexto onde a produção de software sólido era a coisa mais importante, e me dava ferramentas para minimizar um monte de besteiras que me deixavam louca. Adorei.

O problema hoje, que eu explico em detalhes em outro lugar , é que a maioria das pessoas que "adotam o Ágil" atualmente não está interessada em melhorar nada se isso os incomodar. Então, para eles, "Agile" é apenas um novo recurso para vencer os desenvolvedores da mesma maneira antiga. Ao contrário, digamos, de uma maneira de aumentar radicalmente a produtividade e, ao mesmo tempo, remover toda essa besteira que está atrasando o desenvolvimento.

Agora mesmo. Eu estou começando uma empresa, e eu vou estar usando muito XP, além de um monte de outros truques que eu inclinei no mundo ágil. Mas precisamente por causa de histórias como a sua, eu recuo sempre que ouvi sobre uma adoção Agile nos dias de hoje.

Então, para responder à sua pergunta diretamente: O Agile não deve ser o novo microgerenciamento. Deve ser sobre capacitar as pessoas que fazem o trabalho real para fazer merda. Mas no seu caso, Agile soa como a última mentira que eles estão contando enquanto eles satisfazem seus próprios maus instintos. Pelo que eu realmente sinto muito.

    
por 16.03.2011 / 00:39
fonte
16

Scrum é o filho bastardo do 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 porcaria no caminho. Leia isso de novo. E mais uma vez.

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

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

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.”

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

Há uma resposta para o tipo de ação ágil que você está fazendo. É isso. Imprima e coloque em algum lugar quando não houver mais ninguém por perto e deixe-os descobrir por si mesmos.

    
por 11.06.2011 / 02:01
fonte
11

The current Scrum master was a manager who took a couple days agile training class paid by the management is now leading this agile team.

Esse é o seu problema. As gerências querem um pouco de Agile, elas realmente não sabem o que é, e impõem isso às equipes. É basicamente o que fazer quando você quer diminuir significativamente a produtividade de seus desenvolvedores;)

A nova proposta de processo deve vir dos desenvolvedores. Ou pelo menos ser revisada & aprovado por eles se for uma ideia da gerência.

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

    
por 15.03.2011 / 18:23
fonte
9

"Ágil" e todas as outras "metodologias de gerenciamento" são freqüentemente usadas para forçar o microgerenciamento das pessoas. OTOH também é por vezes abusado para defender o mau acabamento.

"somos ágeis" é a desculpa mais frequente que ouço por falta de planejamento, falta de pensamento sobre design, recursos, qualidade, ciclos de lançamento. Isso geralmente de desenvolvedores e gerenciamento inferior. É também loucamente a desculpa mais usada pelos gerentes, arquitetos, vendedores, etc. para microgerenciamento, sempre mudando os prazos e recursos, forçando as horas extras do massiver para as pessoas (os prazos e características dos turners sempre garantem isso) etc., etc. .

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

    
por 16.03.2011 / 12:55
fonte
7

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

Primeiro, leia este (manifesto Agile) e você notará que não falar 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.

    
por 15.03.2011 / 20:07
fonte
2

O Agile deve ser o novo autogerenciamento. Se o agile for praticado corretamente, muitas das decisões são tomadas por um cliente e um desenvolvedor trabalhando em uma história de usuário com escopo definido adicionada ao backlog como tarefas são identificados.

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

As equipes ágeis não devem se sentir como se o trabalho do dia a dia fosse 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 for o caso da sua organização:

Viva o Manifesto Ágil

"We are uncovering better ways of developing software by doing it and helping others do it."

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

Abrace a mudança. Talvez você possa fazer algum treinamento, mas talvez seu orçamento seja apertado e o dinheiro não esteja lá. Outras oportunidades também podem proporcionar melhorias. Faça alguma leitura, faça com que os membros da equipe aprendam o que puderem sobre o Agile e ensinem uns aos outros. Você pode encontrar pessoal novo ou existente qualificado para modelar e liderar a adoção do Agile.

    
por 20.12.2012 / 05:40
fonte
1

As equipes ágeis são como times de futebol trabalhando para 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. Gerentes / Scrum Masters são meros facilitadores da equipe e o gerenciamento tradicional / microgerenciamento acabará com o espírito da equipe.

Nas equipes em que trabalhei, somos encorajados a jogar em equipe após o expediente para melhorar a camaradagem entre os membros. Eu colecionei esses pensamentos aqui .

    
por 11.06.2011 / 08:58
fonte
0

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

Meus pensamentos sobre o tópico "Devs não está 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 que completassem tarefas. Por exemplo, não posso subir aleatoriamente para um testador de desenvolvimento e pedir que ele faça alguns testes para mim nas próximas horas. Preciso falar 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 para o backlog para um sprint futuro).

Nesse caso, eu entendi o conceito de "devs não conversando entre si" porque ele realmente traduzia tarefas de afunilamento através de um checkpoint para que um desenvolvedor em particular não estivesse sobrecarregado ou estivesse tão ocupado fazendo tarefas de emergência que não faça seu trabalho planejado.

Caso contrário, os desenvolvedores DEVEM estar conversando entre si. Sempre. Ajuda-o a resolver problemas mais rapidamente, a tornar-se mais próximo em equipa e a entregar mais rapidamente.

Só para oferecer outra perspectiva: Eu também estive em um ambiente onde as pessoas achavam que os desenvolvedores "falavam demais". Depois de um sit-down, descobrimos que realmente traduzido para "devs não são independentes o suficiente para ter seu próprio trabalho feito. Porque tudo é tão fragmentado, devs tem que ir para outras três pessoas para completar em pequena tarefa." p>

Assim, quando os gerentes decidiram migrar para o ágil, eles esperavam que isso ajudasse a trazer as informações para os lugares certos e interrompesse grande parte da fragmentação dentro da organização. Algumas pessoas ficaram meio desapontadas que depois que o Agile foi implementado, os desenvolvedores ainda estavam se alternando entre si. Mas o que eles não perceberam é que isso estava acontecendo cada vez menos. Levou tempo embora. Então, talvez se isso é o que está acontecendo na sua organização, pode ser que as pessoas esperem que o agile conserte as coisas da noite para o dia. Não é assim que funciona.

    
por 16.08.2018 / 22:43
fonte
-1

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

  1. A maioria das organizações, os desenvolvedores devem trabalhar em vários projetos, em Agile / scrum. Sprints nunca são considerados este 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 os desenvolvedores. ESSA É A DISTRAÇÃO - não é necessário apenas atender uma chamada telefônica ou permitir uma ligação telefônica.
  2. Eu tenho visto projetos ágeis onde Sprint é planejado, histórias incluídas na Sprint, sem ser encolhida .. no meio do caminho ou meio dos sprints .. desenvolvedores encontrando dependências não resolvidas, requisitos ou história não é concluída narrada ... .. Este é um dos Abusos nos projetos mais ágeis.
  3. Teste: TTD .. sim, é muito bom .. mas eu tenho visto a maioria dos projetos ágeis confiando totalmente no TTD ... nenhum escopo ou tempo permitido para testes funcionais ou humanos. Outro abuso ... Muito Os Scrum Masters também não conhecem ou entendem a importância do teste funcional. Seu pedaço de código pode estar funcionando perfeito, se não serve a necessidade do negócio .. é inútil .. Isso acontece quando os negócios não participam bem à frente .. ou a participação está lá ... mas não refletindo a tomada de decisões de negócios .. No final, os desenvolvedores são culpados, você não entregou a funcionalidade ... ou vai acabar com a mudança de última hora ... horas extras extras porque o seu Scrum Master não quer levar a culpa pela história não concluída.

Abuso aqui ... ou baixa participação de negócios ou participantes que não sejam totalmente informados ou que tenham uma pessoa de negócios desistindo no meio do sprint.

  1. Nem todos os projetos são adequados para Agile ... A maioria dos gerentes ou scrum masters não sabe disso .. Projetos de manutenção .. Um defeito pode ser inicialmente assumido pode ser feito em 8 horas, aceito no sprint. Depois de passar 4 horas, encontrei este é Java / outro produto ... (Eu recentemente enfrentou defeito de negociação relacionado ao Quartz Scheduler .. dentro do nosso projeto) e este defeito poderia levar à atualização do produto / package..deal com burocracia, aprovação, financiamento, nova versão ou atualização devem ser aprovados pela Engenharia Interna etc., 5.Retrospection: apenas um punhado de projetos ágeis faz este passo .. Se de todo feito..Gestão, Scrum Master nunca assumiu qualquer responsabilidade das histórias fracassadas ..
  2. Emparelhamento .. Muitos desenvolvedores tratam o emparelhamento como local para abusar de colegas de trabalho .. criticar outros projetos, práticas de codificação .. tratar como trabalho em equipe., aprender uns com os outros ... Outra maneira de abusar de Agile / Scrum.

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

    
por 10.03.2013 / 21:31
fonte
-3

Agile é microgerenciamento disfarçado. Não há lugar para iniciativa ou criatividade no Ágil, 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.

    
por 02.05.2013 / 00:41
fonte