Postado por Juan Bernabó para o Blog teamware blog
em Maio 27, 2009

Depois de ouvir o podcast de Ricardo Vargas, Chairman do PMI, sobre Agile Project Management ficou claro que será necessario um trabalho grande para continuar desmistificando Scrum e Agile, agora não porque não exista interesse ou demanda para adoção, o que acontecia há muitos anos quando tivemos a coragem de começar fazer os primeiros treinamentos de scrum no país, justamente pelo contrário.

Como o interesse esta crescendo, um dos aspectos que podem ser banalizados mais rapidamente, é de que para poder usufruir dos benefícios de Scrum e Agile, é necessário uma mudança de paradigma, e é esse nosso principal desafio.

Eu vejo com muito bons olhos que aqueles que de alguma forma tem pautado suas carreiras a gestão de projetos (os gestores de projetos) e são associados do PMI, e tem um objetivo de avançar a ciência da gestão de projetos, possam começar a ser expostos a métodos inovadores de gestão como Scrum, que tenho certeza vai aumentar muito o valor da sua caixa de ferramentas, porem minha experiencia me diz que temos que tomar cuidado com um aspecto fundamental.

Alguns desafios pela frente

Gestores de projetos sobre tudo que passam numa certificação onde existem perguntas extremamentes claras sobre qual deveria ser a forma de pensar correta sobre um assunto, vão provavelmente manifestar uma elevada taxa de concordância sobre algumas premissas fundamentais, certamente entre elas existirá diferente capacidade ou habilidade porem algumas crenças, verdades e premissas fundamentais serão similares.

Muitos dos gestores que tenho feito coaching, e tinham recebido treinamento formal em gestão tradicional de projetos, apresentavam mais o menos a mesma forma de pensar sobre ser possível ou não detalhar todas as atividades de um plano de projeto para desenvolvimento de software.

O que tenho visto, é que existe um gap entre o discurso e a prática, ou seja as teorias esboçadas e as teorias em uso tem divergencias muito grandes e isso pode ser a causa de muitos problemas, como a falta de reflexão sobre alguma premissa fundamental, e assim a falta de aprendizado.

Peter Senge, autor do livro A Quinta Disciplina, fala que o problema das organizações não é que não conseguem resolver os seus problemas, o problema é não conseguir “enxergar” seus problemas, o seu paradigma os cega.

Como as teorias aprendidas acabam sendo reforçadas, já que são as respostas certas para exames de certificação, elas passam a ser tratadas como “verdades” e como Scrum e Agile partem de premissas em alguns casos opostas da gestão tradicional, é necessário quebrar a ilusão que foi criada, para permitir o aprendizado de uma ferramenta que tem como premissa outras “verdades” que conflitam com aquelas adquiridas anteriormente.

O nosso trabalho tem sido basicamente nos últimos anos, criar duvida suficiente das “verdades” aprendidas, porém que estão criando problemas não deixando as pessoas conseguirem olhar para a realidade e refletir sobre os problemas que estão tendo realmente.

Conceitos para complementar o podcast do Ricardo

Aqui vão alguns comentários sobre o podcast que creio que podem ajudar a entender melhor e complementar o que Ricardo disse.

Ser ágil não se trata de velocidade, se trata sobre ser enxuto. Ou seja, imaginem algo que tem muita massa, pode ganhar extrema velocidade e ser muito rápido, porem terá muita inercia e terá dificuldade de mudar de direção rapidamente sem muito esforço.

Então a rapidez na verdade não é o objetivo de Scrum e sim reduzir a massa.

Para poder ser ágil e flexível será necessário reduzir a massa, ficar mais enxuto, e isto a gente faz em Scrum usando o conceito de One Piece Flow (criar um fluxo de produção de uma única peça) por exemplo se faz fluir um único requisito funcional desde o detalhamento até o teste funcional no menor tempo possível, fazendo que toda a equipe se concentre na menor quantidade possível para abaixar o estoque de trabalho em progresso (um conceito de Lean – Toyota – Just in Time) para poder responder a mudanças sem stresse.

O desafio para quem passou por treinamento formal em gestão tradicional de projetos será poder re-avaliar as premissas e crenças fundamentais, digo isto depois de ter reciclado centenas de pessoas formalmente treinadas em gestão de projetos tradicionais, não como uma hipótese e sim como um fato, nosso maior desafio é como o que tive com orientação a objetos há uns 22 anos atrás, mudar o meu paradigma (o sistema de verdades, crenças e premissas) que lamentavelmente nós humanos não fomos projetados para mudar muito frequentemente na nossa vida.

Existem milhares de implementações meia boca de Lean, existem milhões de analistas e desenvolvedores OO que programam em linguagens OO porem continuam pensando de forma estruturada, como eu já vi esta historia varias vezes o desafio maior é que não tenhamos milhares de PMPs usando Scrum sem mudar o seu paradigma, sem realmente conseguir retirar todo o valor da ferramenta já que para poder retirar a maior quantidade de valor é necessário pensar diferente.

Uma pergunta para develar uma premissa

No Scrum Gathering apos a palestra do Ricardo Vargas, eu Juan Bernabó, acabei fazendo uma pergunta chave, conhecendo as premissas dos gestores tradicionais eu fiz só uma pergunta para tentar entender melhor se o discurso era um discurso de quem tinha passado por um entendimento profundo, mudança de paradigma, ou simplesmente de quem ainda so conhece os artefatos mais não as premissas fundamentais de Scrum.

A pergunta foi “O PMI parece ser muito centrado no papel do gestor de projetos, certo? Porem o PMI esta preparado para um mundo de equipes auto-geridas?”

O Ricardo contesto de forma totalmente transparente uma “verdade” que ele tem “experimentado” e que se eu não tivesse tido tanta experiencias reais com Scrum também teria, ele disse que a idéia de equipes auto-geridas é romântica, mais nunca viu uma funcionando direito, logico sem Scrum e Ágil eu vi uma porem era uma raridade.

Eu já transicionei mais de 80 equipes auto-geridas, por isso tenho plena convicção, porem sem essa experiencia seria difícil ter tanta certeza, sobre todo quando usamos processos que não estão ajustados para a auto-gestão, e que os ciclos de controle são muito grandes.

Pela primeira vez com Scrum tenho a oportunidade de criar em larga escala equipes auto geridas, que se comportam relativamente dentro de parâmetros, e que tem um resultado muito superior a qualquer outra forma de organização que eu já tinha visto.

Pela resposta do Ricardo deu para entender que ainda não foi exposto e ainda precisara passar por uma mudança de paradigma.

Por exemplo da para entender claramente o que um gestor tradicional acredita sobre times auto gerenciados, como ele nunca viu funcionando de forma eficaz então deve ser porque é necessário um time extremamente maduro.

Porem a auto gestão só é possível não porque as pessoas são muito maduras, mais porque usamos de alguns mecanismos que permitem que um grupo de pessoas normais (na media) tenham comportamentos emergentes (do sistema) inteligentes, isso se chamam gestão empírica com ciclos curtos (2 a 4 semanas), equipe holística sem papeis que permite que os pares possam se auto-regular, e feedback binário e concreto através da demonstração de produto pronto que é facilmente verificável, que passa nos testes de aceitação automatizados por exemplo.

Scrum nada mais é do que o nosso velho amigo o PDCA levado extremamente a serio por exemplo, 1 dia de Sprint “Planning” (Plan), 8 dias de “Sprint” (DO), 4 hrs. de Sprint “Review” (Check), e 2 hrs. de Sprint “Retrospective” (ACT).

O controle na gestão empírica não esta no processo e sim em definir claramente a entrada (item do backlog) e verificar rigorosamente a saída (features prontas testadas), e não mexer no processo durante o momento onde o processo esta executando (Sprint), só ajustar o processo depois de verificar a saída (ou seja no Sprint Retrospective).

A outra diferencia é que o papel das equipes mudou de co-adjudantes para papeis principais, elas planejam taticamente no Sprint Planning, e melhoram seu processo no Sprint Retrospective ao invés de simplesmente executar planos planejados por algum gestor, e ver seus processos melhorados por alguma área ou responsável por processos.

Como vemos Scrum esta sendo bem aceito inclusive na comunidade de gestão de projetos tradicional, logico não sem algumas preocupações, o papel do gestor de projetos como o conhecemos em Scrum muda de forma radical, PM irão precisar adquirir novos skills, novas formas de pensar, é muito mais legal e interessante do que assustador, porem precisa se ter consciência que para termos resultados no mundo ágil uma transição será necessária.

Já hoje e mais no futuro o que ira agregar valor é ser aquele facilitador que saberá criar o ambiente certo e os processos certos para que equipes possam se auto-gerir, um profissional com estas habilidades nunca deixara de ter valor no mercado.

Boa noticia

Donella Meadows fala em seus 12 pontos de alavanca para intervir num sistema
que o paradigma é um dos mais fortes, porem mais forte do que o paradigma é o poder de transcender a paradigmas, como a física clássica não deixou de ser útil nem perdeu validade com o advento da física quântica, a gestão tradicional e muito do seu corpo de conhecimento não perdeu relevância o problema é tentar usar uma única ferramenta (paradigma) para tentar resolver todos os problemas.

Fonte: teamware blog

Nesse podcast Ricardo apresenta o gerenciamento ágil de projetos e os conceitos de Scrum. Ele teve um contato inicial com Agile e Scrum e tenta nesse podcast falar um pouco sobre como funciona o Agile e Scrum. Importante ressaltar que Ricardo não é um especialista no assunto. O objetivo nesse podcast é apresentar para os não especialistas em Agile e Scrum alguns dos principais conceitos envolvidos na técnica. Ele tb comete um pequeno deslize no podcast onde fala que scrum é do jogo de futebol americano. Na verdade Scrum é a formação do Rugby.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

25/05/2009 Gerenciamento Ágil de Projetos e Scrum 1 de 2

Nesse podcast, Ricardo mostra suas percepções sobre o uso de gerenciamento ágil e como isso pode ser utilizado em conjunção com o PMBOK Guide e outros padrões e/ou metodologias para uma prática bem sucedida de gerenciamento de projetos. Segundo podcast sobre o tema.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

01/06/2009 Gerenciamento Ágil de Projetos e Scrum 2 de 2

Ricardo Viana Vargas é especialista em planejamento, gerenciamento e controle de projetos. Atualmente atua como presidente da Macrosolutions, uma empresa de consultoria de gerenciamento de projetos no Brasil com mais de 20 perfis complexos de projetos do Brasil e América Latina, abrangendo um portifólio de investimentos de mais de $5 bilhões. Ricardo Vargas é membro do PMI desde 1997, e atualmente ocupa a posição de diretoria do Board do PMI. Participou da revisão do PMBOK®, Project Management Body of Knowledge (PMBOK® Guide), e foi membro da equipe do projeto de atualização do PMBOK® Guide em 2004. Também foi presidente do Comitê de Verificação de Tradução para língua portuguesa do PMBOK® Guide 2004.

Fonte: Ricardo Vargas – Five Minutes PM Podcast

Matthew Hotle
8 de maio de 2009

Descobertas chave

• Mudar sua estrutura organizacional deveria ser o último recurso.
• Recursos humanos qualificados e determinação são mais importantes do que uma melhor estrutura organizacional.

Recomendações

• Não faça mudanças organizacionais para solucionar problemas nos processos. Foque primeiro o próprio processo.
• Use atribuições rotativas de tarefas e outros incentivos para gerar determinação se a segmentação for sua opção.
• Assegure-se de que os acordos de nível de serviço (SLAs) tenham sido implementados antes de realizar a mudança organizacional.

O QUE VOCÊ PRECISA SABER
Os clientes costumam perguntar se deveriam dividir seu pessoal entre projetos (geralmente associados a desenvolvimento, na verdade se referem a trabalho líquido e novo, e a projetos de aperfeiçoamento) e suporte. As empresas que já se encontram nessa situação perguntam se seria melhor dividir o pessoal ou se deveriam voltar a ser uma empresa de estilo misto. Se isso soar mais como um estilo de tomada de decisões do tipo “será que a grama está mais verde”, então é mesmo. A maioria das empresas que cogita dividir suas estruturas organizacionais seguindo esses preceitos está na verdade tentando solucionar uma de várias questões relativas a seus processos:

• Os projetos estão atrasados (embora sem ultrapassar o orçamento) porque os recursos alocados para eles foram transferidos para a área de suporte.
• As qualificações da área de suporte estão totalmente unificadas, sem nenhum backup ou contingência.
• Os requisitos de recursos para suporte estão fragmentados.
• O pessoal qualificado para a área de suporte ou não está disponível, ou logo não estará mais disponível devido a aposentadorias ou transferências.
• Relacionamentos problemáticos entre os diferentes grupos geram problemas significativos de gestão e estado de espírito.

Mudar simplesmente a estrutura organizacional não irá solucionar nenhum desses problemas. De fato, mudar a empresa irá, todas as outras coisas mantendo-se as mesmas, tornar os problemas ainda piores durante seis a 18 meses, simplesmente porque, além de possuir processos problemáticos, a empresa enfrentará a distração de um novo quadro organizacional. Há bons motivos para mudar um empresa (esta pesquisa não se refere a quando mudar, mas a como mudar), mas fazer isso deve ser algo cuidadosamente avaliado e ponderado com o potencial das mudanças nos processos de solucionarem efetivamente os problemas, e não apenas mudarem o pessoal de lugar.

ANÁLISE
A primeiro regra para mudar um desenho organizacional: Não faça isso!

É claro, isso nem sempre é verdade. Porém, modificar os relacionamentos de reporte e o lugar das pessoal com certa freqüência é um dos principais problemas que as divisões de aplicações enfrentam. É relativamente fácil porque os relacionamentos e a dimensão do controle são algo sobre os quais os gestores têm controle direto, e o mais importante, é fácil ver que uma mudança está sendo feita. Porém, há dois problemas aqui:

• Mudar a estrutura de uma empresa resultará entre 6 a 18 meses de ruptura. Alguns se associam a seus chefes; enquanto outros não se sentem à vontade com eles. Independente disso, quando os relacionamentos de reporte organizacional forem modificados, haverá um período de acomodação entre os novos associados e sua gestão. Haverá também um período de tempo em que as partes da empresa sujeitas às modificações deverão se realinhar para que o trabalho possa fluir novamente pela nova estrutura de gestão.
• Os maus processos continuam sendo maus. Isso é realmente fundamental aqui. Muitas empresas tentam mudar seus quadros organizacionais para solucionar um problema dos processos, mas isso não funciona. Solucione o problema primeiro, e então escolha uma estrutura organizacional que funcione.

Grande parte das atividades nas empresas tem origem em relacionamentos informais e em processos implícitos. Status ou poder já foram atribuídos nas estruturas já existentes. Muitas empresas têm muito pouca consciência desses aspectos, e os danificam ou destroem durante os processos de reorganização. Infelizmente, algumas das estruturas e processos que deveriam ter sido modificados sobrevivem ao processo de reorganização.

Para colocar isso tudo no contexto desta discussão, muitas empresas estão de problemas de RH e de planejamento através da segmentação de suas estruturas organizacionais. Vamos presumir que haja bons motivos para dividir a empresa, incluindo aqueles citados acima. Qual é a mecânica dessa separação?

Aspectos Fundamentais de uma Divisão das Áreas de Projetos/Suporte
Se você estiver prestes a segmentar sua empresa, então o seguinte conjunto de passos será crucial ao fazer isso:

• Defina claramente o que é um projeto e quais atividades serão atribuídas à área de suporte. Isso poderá parecer fácil, mas muitas empresas referem-se a um projeto como alguma espécie de massa amorfa de trabalho, ou como qualquer coisa que precise ser administrada. Para os fins desta discussão, vamos presumir que um projeto é algo que contenha um mínimo de 320 horas. Há algum sentido nisso: usando o mínimo necessário de oito horas para o planejamento de tarefas estabelecido pelo Project Management Institute (PMI), vamos presumir que um projeto possua cinco fases (requisitos, análise/design, código, teste e implementação), e que cada uma dessas fases possua apenas três atividades. Cada atividade possui três tarefas associadas a ela. Temos agora um total de 15 tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que gera um total de 320 horas. Tudo o mais fica a cargo da área de suporte. Geralmente, há três tipos de atividades de suporte: reparo de defeitos, pequenas mudanças ou aperfeiçoamentos, e outros trabalhos necessários para atender aos SLAs. O trabalho de conformidade ou observância regulatória poderá na verdade entrar em qualquer uma das categorias de projetos ou suporte. Se houver uma necessidade consistente de pessoal para realizar essas mudanças, então essas mudanças poderão ir para a área de manutenção. Se a demanda for esporádica, então será melhor lidar com elas como se fossem projetos, colocando-as no topo da cadeia de prioridades.
• Para cada aplicação ou grupo de aplicações, crie um SLA. Ou seja: Suporte consiste no reparo de defeitos, pequenos aperfeiçoamentos, e outros trabalhos necessários para prover suporte aos SLAs (resposta a questões corporativas, realização de análises conjunturais e assim por diante). Aqueles serviços devem ser claramente definidos e codificados em um SLA que proveja à empresa e à divisão de aplicações um mecanismo para atender aos níveis de serviços desejados pela empresa. Isso proverá também um mecanismo para dimensionar a divisão de suporte.
• Com base nos requisitos dos SLAs e de trabalho, dimensione a estrutura organizacional. Infelizmente, é daqui que parte a maioria das empresas que desejam segmentar seu pessoal. Determinar quantas pessoas devem estar na divisão de suporte é um terreno desconhecido até que você determine: (1) a taxa de contratação segundo a gravidade dos defeitos; (2) quantas pessoas a empresa está disposta a pagar para realizar os pequenos aperfeiçoamentos; e (3) quais outros serviços devem ser realizados, quando e como (veja “Administrando a Inexorável Demanda por Trabalho em Aplicações”).

Até agora, tudo isso é razoavelmente simples. Agora, porém, chegamos ao que é talvez o maior impedimento para a realização de uma segmentação: os próprios associados. O reparo de defeitos requer pessoas que estejam acostumadas e dispostas a trabalhar sob pressão, e que sejam muito bons solucionadores de problemas. Geralmente não há pouca oferta de tais recursos humanos, mas é algo que vale a pena observar porque poderá haver pessoas dispostas a realizar o trabalho de suporte e que não possuam as qualificações básicas. O maior problema, porém, é que muitos profissionais de TI simplesmente não desejam realizar somente o trabalho de suporte. Eles consideram uma tarefa de suporte como uma via sem saída, um predecessor da terceirização ou uma mudança que limitará suas perspectivas. Por outro lado, os que pertencem à comunidade de desenvolvedores poderão vir a ver a si mesmos como superiores aos profissionais da divisão de suporte. Ao realizar o trabalho de segmentação, as empresas precisam pensar em como poderão fazer com que seu pessoal se sinta confortável realizando uma tarefa de suporte e disposto a aceitá-la. Há um alguns mecanismos chave para fazer isso:

• Pague um bônus ao pessoal de suporte. Muitas empresas recusam-se a fazer isso, pois consideram que o trabalho de suporte não possui valor agregado.

Fonte: Info Corporate

Na sua empresa quando se fala em gerenciamento de projetos todos pensam em PMBok. Você acha que Scrum pode ajudar seus projetos mas não consegue enxergar como fazer isso em um ambiente completamente tradicional de projetos. O que fazer? Onde foi parar o Gerente de Projetos? E o PMO, como fica? Tenho práticas ágeis que se equivalam às áreas de conhecimento do PMBok? Nesta palestra a filosofia ágil é apresentada de forma a fazer entender como Scrum pode ser aplicado nestes ambientes, e qual o caminho a ser seguido pelos Gerentes de Projeto acostumados com práticas PMI para conseguir serem bem sucedidos em projetos Scrum.

Palestra do Alexandre Magno para o Falando em Agile 2008.

Assista a palestra aqui.

Fonte: Falando em Agile 2008

Ontem foi o primeiro dia da primeira edição de 2009 do Scrum Gathering. Organizado pela Scrum Alliance, este é o maior e principal evento de Scrum do mundo.

Durante o almoço aconteceu um pequeno pronunciamento de Gregory Balestrero, Presidente e CEO do PMI – Project Management Institute.

Gregory mostrou bastante bom senso ao falar do que a comunidade Scrum tem feito:

“Vocês tem mostrado ao mundo como obter bons resultados em projetos. Encorajo PMPs a buscarem conhecimento e certificações na área de Scrum, pois realmente acreditamos nisso.”

Fonte: aXMagno

Esse filme de um comercial de televisão já tem algum tempo e é muito mencionada em treinamentos de metodologia de gerenciamento de projetos, em relação a implantação de projetos enquanto o resto da empresa continua em seu dia a dia normal.

A propaganda se chama “Airplane” e é da empresa de consultoria EDS.

O aumento da procura por esse tipo de gestor cresce na medida em que boa parte dos projetos de TI (75%) não alcançam o sucesso esperado, segundo estudo da The Standish Group

Kristin Burnham, CIO EUA
Publicada em 27 de fevereiro de 2009 às 09h10

Com a promessa de reduzir o tempo e o dinheiro das organizações para executar projetos de TI, a figura do project manager (ou gestor de projeto, em português) vem ganhando espaço dentro das organizações, as quais têm demandado, cada vez mais, esse perfil de profissional.

Na prática, o project manager serve como um link entre a área de TI e os indivíduos envolvidos com um determinado projeto, com o intuito de assegurar o andamento das iniciativas, de acordo com Katherine Spencer Lee, diretora-executiva da Robert Half Technology – empresa especializada em recrutamento de profissionais ligados à Tecnologia da Informação.

Esses gestores de projeto tipicamente examinam o processo e a metodologia em andamento, identificando as melhores práticas para garantir o sucesso das iniciativas, gerenciando as exigências e atuando como mediadores entre a Tecnologia da Informação e os processos.

Por que as empresas necessitam de um project manager?
“Existe uma forte demanda no mercado por profissionais que demostrem habilidade de execução”, considera David Foote, CEO e CRO (Chief Research Officer) da consultoria em TI Foote Partners. Ainda segundo ele, um dos principais responsáveis pelas falhas nos projetos está nos problemas de relacionamento, comunicação e cooperação.

Nesse sentido, a missão principal dos gestores de projeto é, exatamente, manter o cronograma das iniciativas e garantir uma implementação apropriada e eficiente. O que é especialmente importante nesse momento, quando apenas 35% dos projetos de TI têm sucesso absoluto, de acordo com estudo da The Standish Group.

Quais os conhecimentos necessários para a função?
A característica primordial para um project manager é a organização, segundo Jim Lanzalotto, vice-presidente de estratégia e marketing da Yoh, uma firma de outsourcing e recrutamento. Além disso, ele informa que esses profissionais precisam ter conhecimentos de TI e negócios, um histórico na área de desenvolvimento de aplicações e cinco anos – ou mais – de experiência em gestão de projetos complexos.

Os potenciais candidatos ao cargo devem também apresentar as seguintes características, de acordo com Lanzalotto:
- Boa comunicação
- Capacidade de resolver problemas
- Facilidade de relacionamento
- Atuação em múltiplas tarefas
- Habilidade para gerenciar as expectativas dos clientes

Como encontrar esse profissional?
Para o vice-presidente da Yoh, a melhor forma do CIO encontrar um project manager qualificado é a partir de indicações e contatos. “Pergunte às pessoas que trabalharam em iniciativas similares se elas têm alguém para recomendar”, explica Lanzalotto. Já Foote sugere que essa procura comece por empresas certificadoras de profissionais na área de gestão de projetos.

Fonte: CIO