PMI e Scrum Gap de Paradigmas

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 adopção o que acontecia a muitos anos quando tivemos a coragem de começar fazer os primeiros treinamentos de scrum no pais, justamente pelo contrario.

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 existira 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 pratica, 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 é que 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 porem 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 ate 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 a uns 22 anos atras, mudar o meu paradigma (o sistema de verdades, credenças e premissas) que lamentavelmente nos 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.

5 comentários:

Parzianello, L.C. 27 de maio de 2009 18:06  

Belo texto Juan! Parabéns!

Toledo 1 de junho de 2009 11:44  

É isso ai Juan! Quando terminou a palestra eu te procurei para dizer que você tinha feito "A pergunta"...
Believe in People!

[]s,
Rodrigo de Toledo

Daniel Wildt 3 de junho de 2009 00:51  

Estava com um "problema" estes dias, de uma equipe que não tinha um "chefe". Tinha sido requisitado para definir um chefe. Ao invés disto, adotei um processo de auto gestão, e a coisa tomou forma na mesma hora!

Dê poder ao time e o time vai responder!

Claro que cada situação é diferente, e não acho que o que deu certo neste caso daria em todas equipes. Tudo depende! :-)

O problema é que as pessoas se assustam com o que pode acontecer em times que se auto gerenciam.

O problema maior é que elas não visualizam os problemas que ocorrem hoje com as equipes comando/controle.

Equipes auto gerenciáveis criam conhecimento e comprometimento!

André Dourado 11 de junho de 2009 17:44  

Coloquei esse post em meu blog (blog.adsystems.com.br) e o Ricardo Vargas adicionou um comentário. Segue o comentário:

http://www.ricardo-vargas.com/

Oi pessoal

Adorei ver que não só o meu podcast como também a minha apresentação no Scrum Gathering geraram um ótimo nível de discussão. Ficou realmente muito feliz com isso. Eu gostaria apenas de dar clareza a alguns pontos aqui mencionados no que refere a alguns comentários meus.

Inicialmente eu acho extremamente viável e válida qualquer iniciativa de agilidade. O dicionário aurélio define agilidade como o desembaraço, ligeireza, presteza de movimentos, mobilidade, perspicácia e vivacidade. Não tive a intenção de simplificar o conceito falando apenas de velocidade.

Quanto ao conceito de equipes auto-geridas, minha resposta ao Juan Bernabó foi diante do meu cenário de trabalho. Esse cenário não é um cenário PMI tradicional, mas sim um cenário de quem NÃO ATUA NO DESENVOLVIMENTO DE SOFTWARE OU TECNOLOGIA.

Eu, em mais de 100 projetos, nunca tive a oporturnidade de ter um SDWT (Self Directed Work Team). Agora os meus projetos são de infraestrutura, tais como plataformas de petróleo, aeroportos, rodovias, industria aeroespacial. O menor projeto desses envolveu mais de 800 pessoas, muitos deles com 3, 4, 5000 pessoas e alguns bilhões de dólares. Não falo de equipes de projeto que envolvam 10, 20 pessoas.

A realidade da equipe auto gerida é muito diferente. Por isso meu comentário. Estou absolutamente convicto de que o uso e valor de scrum em tecnologia é certamente incontestável.

Minhas dúvidas são na aplicação dos mesmos conceitos em um projeto conduzido em 6 diferentes países, envolvendo perto de uma dezena de bilhões de dólares e cerca de 5000 pessoas. Esse é um real desafio na minha perceção.

Um grande abraço a todos e obrigado por permitirem meus comentários.

Sucesso.

Alercio Bressano 17 de agosto de 2009 23:58  

Juan,

comentei que você que sou da linha PMI e minha realidade é de equipes entre 2 e 5 componentes e trabalhando com projetos de software. Após curso que tive com você aqui em Aracaju, achei muito bacana a filosofia ágil e a forma como o SCRUM implanta uma série de atitudes diferenciadas e adequadas a essa realidade de Tecnologia.
Interessante que publiquei no meu blog uma comparação do meu quadro pessoal de metas e como ele ficou enxuto realmente me assustou (fica nítido nas duas imagens).
Bom, estarei incorporando essa filosofia ao meu dia-a-dia e também com minha equipe de desenvolvimento e espero ter bons resultados!
Acredito que cada um deve buscar sua verdade e adequar o que cada filosofia tem de bom (seja PMI, RUP, SCRUM, etc.) ao seu ambiente de trabalho, com o objetivo de atender expectativas!

Abraços,
Alércio Bressano
http://alercio.spaces.live.com

About us

Teamware é uma empresa nascida da visão que a industria de TI esta precisando ser reformada.
Que a Gestão 1.0 (da era industrial) esta sendo o maior gargalo para a mudança de paradigma necessária para elevar a eficacia em projetos de software.
Estamos trabalhando a vários anos para transformar organizações e implantar um novo modelo de gestão, a Gestão 2.0 (da era do conhecimento) e crescendo a nossa influencia na industria de TI. Para isso usamos abordagens ágeis, scrum, xp, toc, lean para realizar a visão e aumentar o valor que TI agrega para os profissionais, organizações e a sociedade como um todo.

Últimas Fotos