BT

A comunidade Agile está se tornando irracional?

por Amr Elssamadisy , traduzido por Felipe Torres em 17 Mar 2010 |

O Yahoo! group pmiagile é um lugar onde as duas comunidades caminham juntas. Os colaboradores desse grupo vêm de uma grande variedade de "backgrounds". Recentemente, ocorreu uma discussão sobre a aplicabilidade das práticas agile em ambientes de gerenciamento de projetos tradicionais como descrito pelo Project Management Body of Knowledge (PMBOK).

Michael James cita o PMBOK:

A cada estação eu encontro alguém que acredita que o PMBOK não contradiz o agile. Seria ótimo se fosse verdade. Aqui estão algumas citações do PMBOK Guide Fourth Edition sugerindo a inadequação do gerenciamento de projetos para desenvolvimento de produtos com Scrum:
  • "Projetos não são esforços contínuos."
  • "O propósito de um projeto é atingir seu objetivo e então terminá-lo."
  • "Reconhecimento e recompensas. Critérios justos para recompensas e um sistema planejado para seu uso irá promover e reforçar comportamentos desejados."
  • "Parte do processo de desenvolvimento do time envolve o reconhecimento e recompensa de comportamentos desejados. Os planos originais tem formas relativas de recompensar pessoas que desenvolveram durante o Planejamento de Recursos Humanos (seção 9.1). As premiações são feitas, formal ou informalmente, durante o processo de gerenciamento do time através de avaliações de performance. (...) Por exemplo, se o prazo é encurtado, o orçamento precisa ser aumentado para adicionar novos recursos para completar o mesmo trabalho em menos tempo.

E Wayne Mack mostra sua frustração com a comunidade Agile sobre como foram interpretadas suas recomendações de deixar os times se auto-gerenciarem:

Parece um pouco precipitado se nossas recomendações aos Project Managers é não gerenciar projetos.

Meu ambiente de trabalho atual é exatamente descrito no post abaixo do Michael. Antes que eu inicie um projeto ou mesmo monte um time, eu preciso apresentar um cronograma, orçamento, e escopo para aprovação. Mesmo que o cliente tenha solicitado e aprovado alterações no escopo, eu preciso justificar essas mudanças no cronograma e orçamento. Esse é o motivo pelo qual muitos project managers encontram sugestões de escopo dinâmico como quase incompreensíveis.

Para aliviar um pouco, acho o ALPN e o Agile COP interessantes e revigorantes, mas não acho informação alguma dizendo que isso é aplicável às minhas atividades diárias no trabalho. Também sinto como se estivesse lutando com um homem e gostaria de compartilhar informação com outros nessa mesma situação.

Minha esperança é que nós possamos discutir várias estratégias para aplicar o Agile em projetos baseados no PMI PMBOK. Isso ofereceria um real benefício aos membros do Agile COP e do PMI.

Brad Murphy reconhece os comentários do Wayne e pondera sobre os pontos fracos das comunidades Agile:

Por favor, saibam que vocês não estão sozinhos. Tendo passado mais de 10 anos defendendo e ajudando grandes empresas mainstream a iniciar e sustentar a transição para o "agility" eu entendo seus sentimentos sobre os "puristas" Agile. Enquanto eu sou um GRANDE fã de muitos princípios e técnicas Agile, o ALPN e outros grupos "Agile" profissionais são muitas vezes ingênuos e às vezes descem perigosamente em seu desprezo pelas realidades complexas de gestão de mudança organizacional, governança, controles financeiros e longo horizonte de planejamento.

Aqui está um simples exemplo da ingenuidade ao qual me refiro. Uma certa indústria líder em Scrum disse que times capacitados tem a característica de expulsar um membro por baixa performance. Essa empresa defende que ao se deparar com um colaborador com baixa performance, o time deve consultar esse membro e se não sentirem que o colega está melhorando seu comportamento devem expulsar a pessoa. Sério? Em qualquer grande organização isso resultará em disputas legais, ações na justiça e RH como nunca.

Eu não estou sugerindo que times capacitados não devem ter voz em modelar seus membros, mas essa simples solução não respeita as bases legais e organizacionais existentes que devem ser redesenhadas de uma maneira mais construtiva ao invés de ser desconsiderado das práticas correntes.

Dan Mezick diz que a resposta de Brad é uma real disfunção:

Você conta uma história sobre disfunção. Literalmente. De um lado, você encoraja a cultura de produtividade dos times Scrum. Do outro..... Essa incapacidade de expulsar pessoas improdutivas (que confirma uma cultura produtiva) é uma disfunção corporativa:

Esse é literalmente o problema. Se uma companhia não é capaz de afirmar que a sua própria cultura de produtividade está repelindo e removendo as pessoas preguiçosas, então o quê esperar? A resposta é, essa empresa continuará atraindo e contratando novas pessoas preguiçosas, enquanto confirma que essas pessoas tem direito de pertencer à empresa.

Essa qualidade do Agile é otimizada para consultorias muito longas.

Se por um lado a empresa pode expressar a (nova) cultura removendo pessoas desocupadas, então ela pode levantar voo, incorpora produtividade, e já não precisa de um exército de consultores "agile" que criarão dependência. Isso ocorre porque a empresa aprende isso e não precisa mais do consultor.

Quantas empresas de consultoria atualmente fornecem "agile coaching" para servir aos clientes incentivando a auto-percepção e, portanto, a independência ... desde o primeiro dia?

Muito poucas. Talvez nenhuma.

E Sanjiv Augustine acrescenta um diferente tom:

Brad, Wayne

Obrigado por essa intensa discussão. Eu estava tão interessado e empolgado que sinto que devo participar. :)

Eu posso realçar sua frustração, tendo em vista determinados desafios e miopia em certos círculos. Por exemplo, havia um diálogo contínuo sobre a regra de gerenciamento em times auto-gerenciados. (...) Wayne - eu reitero o Brad ao dizer que você não está sozinho. Há vários de nós que gastaram a última década ajudando a trazer o Agile para as grandes companhias. Eu acho que é por isso que cada vez mais companhias estão se tornado ágeis.

Então, para finalizar, a comunidade Agile é ideal ou ingênua. Talvez eles tenham um ponto. Talvez o Agile não seja a melhor solução para grandes ambientes. Ou, talvez as técnicas Agile sejam realmente boas em confrontar e trazer coisas à tona que estiveram lá todo o tempo, mas não tinham sido tão prejudiciais assim para serem enfrentadas. Alguma opinião?

O Yahoo! group pmiagile é um lugar onde as duas comunidades caminham juntas. Os colaboradores desse grupo vêm de uma grande variedade de "backgrounds". Recentemente, ocorreu uma discussão sobre a aplicabilidade das práticas agile em ambientes de gerenciamento de projetos tradicionais como descrito pelo project management body of knowledge (PMBOK). Michael James "quotes" the PMBOK: "A cada estação eu encontro alguém que acredita que o PMBOK não contradiz o agile. Seria ótimo se fosse verdade. Aqui estão algumas citações do PMBOK Guide Fourth Edition sugerindo a inadequação do gerenciamento de projetos para desenvolvimento de produtos com Scrum: -"Projetos não são esforços contínuos." -"O propósito de um projeto é atingir seu objetivo e então terminá-lo." -"Reconhecimento e recompensas. Critérios justos para recompensas e um sistema planejado para seu uso irá promover e reforçar comportamentos desejados." -"Parte do processo de desenvolvimento do time envolve o reconhecimento e recompensa de comportamentos desejados. Os planos originais tem formas relativas de recompensar pessoas que desenvolveram durante o Planejamento de Recursos Humanos (seção 9.1). As premiações são feitas, formal ou informalmente, durante o processo de gerenciamento do time através de avaliações de performance. (...) Por exemplo, se o prazo é encurtado, o orçamento precisa ser aumentado para adicionar novos recursos para completar o mesmo trabalho em menos tempo."   " E Wayne Mack mostra sua frustração com a comunidade Agile sobre como foram interpretadas suas recomendações de deixar os times se auto-gerenciarem: "Parece um pouco precipitado se nossas recomendações aos Project Managers é não gerenciar projetos. Meu ambiente de trabalho atual é exatamente descrito no post abaixo do Michael. Antes que eu inicie um projeto ou mesmo monte um time, eu preciso apresentar um cronograma, orçamento, e escopo para aprovação. Mesmo que o cliente tenha solicitado e aprovado alterações no escopo, eu preciso justificar essas mudanças no cronograma e orçamento. Esse é o motivo pelo qual muitos project managers encontram sugestões de escopo dinâmico como quase incompreensíveis. Para aliviar um pouco, acho o ALPN e o Agile COP interessantes e revigorantes, mas não acho informação alguma dizendo que isso é aplicável às minhas atividades diárias no trabalho. Também sinto como se estivesse lutando com um homem e gostaria de compartilhar informação com outros nessa mesma ssituação. Minha esperança é que nós possamos discutir várias estratégias para aplicar o Agile em projetos baseados no PMI PMBOK. Isso ofereceria um real benefício aos membros do Agile COP e do PMI." Brad Murphy reconhece os comentários do Wayne e pondera sobre os pontos fracos das comunidades Agile: "Por favor, saibam que vocês não estão sozinhos. Tendo passado mais de 10 anos defendendo e ajudando grandes empresas mainstream a iniciar e sustentar a transição para o "agility" eu entendo seus sentimentos sobre os "puristas" Agile. Enquanto eu sou um GRANDE fã de muitos princípios e técnicas Agile, o ALPN e outros grupos "Agile" profissionais são muitas vezes ingênuos e às vezes descem perigosamente em seu desprezo pelas realidades complexas de gestão de mudança organizacional, governança, controles financeiros e longo horizonte de planejamento. Aqui está um simples exemplo da ingenuidade ao qual me refiro. Uma certa indústria líder em Scrum disse que times capacitados tem a característica de expulsar um membro por baixa performance. Essa empresa defende que ao se deparar com um colaborador com baixa performance, o time deve consultar esse membro e se não sentirem que o colega está melhorando seu comportamento devem expulsar a pessoa. Sério? Em qualquer grande organização isso resultará em disputas legais, ações na justiça e RH como nunca. Eu não estou sugerindo que times capacitados não devem ter voz em modelar seus membros, mas essa simples solução não respeita as bases legais e organizacionais existentes que devem ser redesenhadas de uma maneira mais construtiva ao invés de ser desconsiderado das práticas correntes. " Dan Mezick diz que a resposta de Brad e uma real disfunção: "Você conta uma história sobre disfunção. Literalmente. De um lado, você encoraja a cultura de produtividade dos times Scrum. Do outro..... Essa incapacidade de expulsar pessoas improdutivas (que confirma uma cultura produtiva) é uma disfunção corporativa: Esse é literalmente o problema. Se uma companhia não é capaz de afirmar que a sua própria cultura de produtividade está repelindo e removendo as pessoas preguiçosas, então o quê esperar? A resposta é, essa empresa continuará atraindo e contratando novas pessoas preguiçosas, enquanto confirma que essas pessoas tem direito de pertencer à empresa. Essa qualidade do Agile é otimizada para consultorias muito longas. Se por um lado a empresa pode expressar a (nova) cultura removendo pessoas desocupadas, então ela pode levantar voo, incorpora produtividade, e já não precisa de um exército de consultores "agile" que criarão dependência. Isso ocorre porque a empresa aprende isso e não precisa mais do consultor. Quantas empresas de consultoria atualmente fornecem "agile coaching" para servir aos clientes incentivando a auto-percepção e, portanto, a independência ... desde o primeiro dia? Muito poucas. Talvez nenhuma. " E Sanjiv Augustine acrescenta um diferente tom: " Brad, Wayne Obrigado por essa intensa discussão. Eu estava tão interessado e empolgado que sinto que devo participar. :) Eu posso realçar sua frustração, tendo em vista determinados desafios e miopia em certos círculos. Por exemplo, havia um diálogo contínuo sobre a regra de gerenciamento em times auto-gerenciados. (...) Wayne - eu reitero o Brad ao dizer que você não está sozinho. Há vários de nós que gastaram a última década ajudando a trazer o Agile para as grandes companhias. Eu acho que é por isso que cada vez mais companhias estão se tornado ágeis. Então, para finalizar, a comunidade Agile é ideal ou ingênua. Talvez eles tenham um ponto. Talvez o Agile não seja a melhor solução para grandes ambientes. Ou, talvez as técnicas Agile sejam realmente boas em confrontar e trazer coisas à tona que estiveram lá todo o tempo, mas não tinham sido tão prejudiciais assim para serem enfrentadas. Alguma opnO Yahoo! group pmiagile é um lugar onde as duas comunidades caminham juntas. Os colaboradores desse grupo vêm de uma grande variedade de "backgrounds". Recentemente, ocorreu uma discussão sobre a aplicabilidade das práticas agile em ambientes de gerenciamento de projetos tradicionais como descrito pelo project management body of knowledge (PMBOK). Michael James "quotes" the PMBOK: "A cada estação eu encontro alguém que acredita que o PMBOK não contradiz o agile. Seria ótimo se fosse verdade. Aqui estão algumas citações do PMBOK Guide Fourth Edition sugerindo a inadequação do gerenciamento de projetos para desenvolvimento de produtos com Scrum: -"Projetos não são esforços contínuos." -"O propósito de um projeto é atingir seu objetivo e então terminá-lo." -"Reconhecimento e recompensas. Critérios justos para recompensas e um sistema planejado para seu uso irá promover e reforçar comportamentos desejados." -"Parte do processo de desenvolvimento do time envolve o reconhecimento e recompensa de comportamentos desejados. Os planos originais tem formas relativas de recompensar pessoas que desenvolveram durante o Planejamento de Recursos Humanos (seção 9.1). As premiações são feitas, formal ou informalmente, durante o processo de gerenciamento do time através de avaliações de performance. (...) Por exemplo, se o prazo é encurtado, o orçamento precisa ser aumentado para adicionar novos recursos para completar o mesmo trabalho em menos tempo."   " E Wayne Mack mostra sua frustração com a comunidade Agile sobre como foram interpretadas suas recomendações de deixar os times se auto-gerenciarem: "Parece um pouco precipitado se nossas recomendações aos Project Managers é não gerenciar projetos. Meu ambiente de trabalho atual é exatamente descrito no post abaixo do Michael. Antes que eu inicie um projeto ou mesmo monte um time, eu preciso apresentar um cronograma, orçamento, e escopo para aprovação. Mesmo que o cliente tenha solicitado e aprovado alterações no escopo, eu preciso justificar essas mudanças no cronograma e orçamento. Esse é o motivo pelo qual muitos project managers encontram sugestões de escopo dinâmico como quase incompreensíveis. Para aliviar um pouco, acho o ALPN e o Agile COP interessantes e revigorantes, mas não acho informação alguma dizendo que isso é aplicável às minhas atividades diárias no trabalho. Também sinto como se estivesse lutando com um homem e gostaria de compartilhar informação com outros nessa mesma ssituação. Minha esperança é que nós possamos discutir várias estratégias para aplicar o Agile em projetos baseados no PMI PMBOK. Isso ofereceria um real benefício aos membros do Agile COP e do PMI." Brad Murphy reconhece os comentários do Wayne e pondera sobre os pontos fracos das comunidades Agile: "Por favor, saibam que vocês não estão sozinhos. Tendo passado mais de 10 anos defendendo e ajudando grandes empresas mainstream a iniciar e sustentar a transição para o "agility" eu entendo seus sentimentos sobre os "puristas" Agile. Enquanto eu sou um GRANDE fã de muitos princípios e técnicas Agile, o ALPN e outros grupos "Agile" profissionais são muitas vezes ingênuos e às vezes descem perigosamente em seu desprezo pelas realidades complexas de gestão de mudança organizacional, governança, controles financeiros e longo horizonte de planejamento. Aqui está um simples exemplo da ingenuidade ao qual me refiro. Uma certa indústria líder em Scrum disse que times capacitados tem a característica de expulsar um membro por baixa performance. Essa empresa defende que ao se deparar com um colaborador com baixa performance, o time deve consultar esse membro e se não sentirem que o colega está melhorando seu comportamento devem expulsar a pessoa. Sério? Em qualquer grande organização isso resultará em disputas legais, ações na justiça e RH como nunca. Eu não estou sugerindo que times capacitados não devem ter voz em modelar seus membros, mas essa simples solução não respeita as bases legais e organizacionais existentes que devem ser redesenhadas de uma maneira mais construtiva ao invés de ser desconsiderado das práticas correntes. " Dan Mezick diz que a resposta de Brad e uma real disfunção: "Você conta uma história sobre disfunção. Literalmente. De um lado, você encoraja a cultura de produtividade dos times Scrum. Do outro..... Essa incapacidade de expulsar pessoas improdutivas (que confirma uma cultura produtiva) é uma disfunção corporativa: Esse é literalmente o problema. Se uma companhia não é capaz de afirmar que a sua própria cultura de produtividade está repelindo e removendo as pessoas preguiçosas, então o quê esperar? A resposta é, essa empresa continuará atraindo e contratando novas pessoas preguiçosas, enquanto confirma que essas pessoas tem direito de pertencer à empresa. Essa qualidade do Agile é otimizada para consultorias muito longas. Se por um lado a empresa pode expressar a (nova) cultura removendo pessoas desocupadas, então ela pode levantar voo, incorpora produtividade, e já não precisa de um exército de consultores "agile" que criarão dependência. Isso ocorre porque a empresa aprende isso e não precisa mais do consultor. Quantas empresas de consultoria atualmente fornecem "agile coaching" para servir aos clientes incentivando a auto-percepção e, portanto, a independência ... desde o primeiro dia? Muito poucas. Talvez nenhuma. " E Sanjiv Augustine acrescenta um diferente tom: " Brad, Wayne Obrigado por essa intensa discussão. Eu estava tão interessado e empolgado que sinto que devo participar. :) Eu posso realçar sua frustração, tendo em vista determinados desafios e miopia em certos círculos. Por exemplo, havia um diálogo contínuo sobre a regra de gerenciamento em times auto-gerenciados. (...) Wayne - eu reitero o Brad ao dizer que você não está sozinho. Há vários de nós que gastaram a última década ajudando a trazer o Agile para as grandes companhias. Eu acho que é por isso que cada vez mais companhias estão se tornado ágeis. Então, para finalizar, a comunidade Agile é ideal ou ingênua. Talvez eles tenham um ponto. Talvez o Agile não seja a melhor solução para grandes ambientes. Ou, talvez as técnicas Agile sejam realmente boas em confrontar e trazer coisas à tona que estiveram lá todo o tempo, mas não tinham sido tão prejudiciais assim para serem enfrentadas. Alguma opnião?ião?

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.