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?