A mítica dicotomia PMBOK x SCRUM

Em uma aula de Gerenciamento de Projetos, me desafiei a explicar a pseudo dicotomia entre o trabalho de um GP que segue o guia PMBOK e um time ágil quanto a planejamento, monitoramento e controle. A origem desta proposição foi o prognóstico do Gartner, sobre 75% das empresas estarem praticando métodos ágeis até o ano de 2018. Apesar de alguns afoitos terem entendido que seria o fim das metodologias tradicionais, quem acompanha o Gartner e conhece os conceitos da TI Bi-Modal e Pace Layered, sabe que isto significa um consistente misto entre práticas ágeis e tradicionais.

ent312-should-you-build-or-buy-cloud-infrastructure-and-platforms-aws-reinvent-2014-6-638

Eu cheguei mais cedo à sala de aula e preparei o quadro, a metade esquerda do quadro contendo todas as cinco fases do PMBOK e seus principais processos, enquanto na direita montei um diagrama ágil baseado no SCRUM, acrescentando boas práticas que não constam do Scrum Guide, mas que são muito utilizadas … um relato muito amplo, que não cabe em um post, mas não quero deixar passar sem um registro casual:

20150828_222307

São guias distintos, especialmente pela menor ou maior interação entre todos os envolvidos, de clientes até a equipe, em especial no tocante a tomadas de decisão mais hierarquizada ou colaborativa. Este post NÃO é sobre semelhanças sócio-técnicas, mas sobre semelhanças nas áreas e metas de planejamento e execução.

Para começo de conversa, nas áreas de conhecimento, seguindo Lavoisier, nada se criou ou se perdeu, apenas seguimos novas abordagens, se utilizando de uma construção iterativo-incremental-articulada, mais leve, com muita gestão visual transportada para ferramentas ALM, wikis e repositórios de dados e fotos.

FRAMEWORK

Uma visão transversal para cada grupo de processos do PMBOK, discutindo como o mesmo é trabalhado em SCRUM e Agile. A priori, PMBOK ou SCRUM não dizem exatamente qual deve ser o artefato, qual o layout dele, qual a técnica, menos ainda um roteiro exato a ser seguido por todos que o praticam. Além disso, desde o lançamento da PMI-ACP em 2013, percebe-se empenho em enxugar o esforço dedicado a tentar antecipar e garantir cada detalhe futuro.

Com certeza o manual do guia PMBOK é mais detalhado e extenso que as 16 páginas do Scrum Guide, mas o guia do SCRUM deixa muita coisa em aberto, declarando apenas em alto nível os critérios e objetivos de cada papel, timeboxe, artefato e regras. Por isso mesmo, incluí artefatos e técnicas comuns em equipes ágeis, como técnicas de elicitação, visão, empatia, modelagem, riscos e qualidade.

Importante alinhar a expectativa que Agile também possui planejamento em todas as 10 áreas do PMBOK e que é temerário para qualquer empresa achar que é possível negar o famoso triângulo do PMI (tempo, custo e escopo), na verdade o Agile apenas explicita um segundo triângulo, tendo o primeiro como um vértice de restrições e outros dois, qualidade e valor (equânime p/cliente e fornecedor).

triângulos

INICIAÇÃO

Na fase de iniciação do PMBOK trabalhamos o termo de abertura e declaração de stakeholders, enquanto em Agile temos o documento de visão e mapa de stakeholders. O objetivo é tornar explícita as bases iniciais, percepções e expectativas do cliente e organização, informações que embasaram a aprovação do início deste projeto. Ambos procuram balizar algo na linha de um 5W2H.

Enquanto em Agile é comum termos aqui o acréscimo de um Business Model Canvas ou Lean Canvas, complementado com um mapa de riscos, nos últimos anos temos visto no PMI o Prof Finocchio apresentar uma folha A3 com seu Project Model Canvas, artefato visual para termo de abertura, 100% ágil e aderente à uma documentação mínima viável, relativa a valor da informação.

PLANEJAMENTO

O planejamento diz respeito às disciplinas de escopo, tempo, custos, riscos, qualidade, aquisição, comunicação e RH. Tanto em uma abordagem quanto em outra, estas disciplinas são exercitadas, mais ou menos detalhadas, mais ou menos rigorosas, mais ou menos colaborativas, cada qual seguindo suas premissas e princípios pelos quais são muito valorizados pelo mercado.

ESCOPO e EAP

Quanto a declaração de escopo, há a divergência histórica do quanto os requisitos devem ser detalhados com muita antecedência, mas seguindo diferentes níveis de abstração, ambos tentam entender o que acredita ser necessário para modelar, estimar e construir software de valor e com sucesso.

Neste quesito, enquanto o PMBOK acredita em uma declaração com clareza e detalhes daquilo que precisará ser feito durante o projeto, no SCRUM usamos o conceito de abstração de funcionalidades, minimamente detalhadas, o suficiente para possibilitar que os profissionais possam comparar cada necessidade com funcionalidades e soluções passadas, de forma que todas as experiências sejam calibradas colaborativamente e assim construam um entendimento comum.

A WBS ou EAP do PMBOK equivale-se a nossa User Story Mapping, de um lado uma lista ordenada funcional de tudo o necessário a ser feito para atingimento dos objetivos do projeto, por outro um mapa visual de histórias do usuário e tudo o mais necessário para a construção e sucesso dos mesmos objetivos.

O primeiro passo em uma User Story Mapping é exatamente a EAP, que em seguida é redistribuída, priorizadas pelos critérios de valor e cronologia de projeto. Os passos seguintes de uma boa User Story Mapping, Inception ou Direto ao Ponto dirá respeito a planejamento de tempo, riscos e qualidade, a seguir diagramado superficialmente:

passo-a-passo-release-plan

CRONOGRAMA

Se o PMBOK nos orienta a construir um cronograma, baseado no escopo, dimensionamento de equipe e restrições, ao fazermos uma inception ágil a orientação é exatamente a mesma, pois dimensionamos a equipe, levantamos riscos e resytrições, para então estimarmos nossas histórias ou funcionalidades de forma a estabelecer entregas quinzenais e definir uma agenda clara de iterações, releases e encerramento.

Talvez a granularidade seja outra, no PMBOK uma necessidade de ter maior número de certezas, no Agile a certeza que é inútil investir tempo demais tentando entender os detalhes, porque em alto nível é possível estimar o suficiente para dimensionar, programar e entregar com sucesso. Mas mesmo isso já não é tabu falar com muitos GP’s, que vem se esforçando em tentar não detalhar tanto, de forma a poder começar antes e ajustar-se a certeza que software é complexo e surgirão mudanças e adequações.

Ambos se preocupam em entregar valor, mas como agilista tenho a convicção de que vivemos uma pirâmide de abstração a cada projeto, iniciando de cima para baixo, planejamos releases com um mínimo de informações viáveis de forma colaborativa, planejamos sprints com detalhes claros de cada história que será desenvolvida nos próximos dias e saberemos exatamente o que fazer no dia-a-dia, discutindo design, desenvolvimento e revisão do código construído.

PLANO DE RISCOS E QUALIDADE

O planejamento de risco e qualidade é uma disciplina muito intensa nos métodos ágeis, uma discussão cotidiana em que os riscos e qualidade dizem respeito aos pilares de transparência, inspeção e adaptação do método SCRUM, presentes também no KANBAN e XP. Pedra fundamental do Lean Toyota, da Tríade de Juran, nos preceitos de Deming.

Eu sugiro um quadrante mágico, onde temos a probabilidade e impacto utilizados na matriz PMBOK, entretanto visível na parede com postits e selos para o planejamento e planos de ação possíveis, necessários e eventualmente executados. O nome que dei para o artefato abaixo é radar de riscos, a qualidade está mais afeita a tomada de decisões, ao planejamento de execução, aos planos de ações discutidos a cada sprint, dojo, pair, peer review, etc:

il_570xN.611273200_2499b

AQUISIÇÃO e RH

Muda muito pouco, trata-se via de regra de uma responsabilidade de gestão, a contratação e coach aos colaboradores, as contratações de fornecedores, mesmo havendo nuances significativas quanto aos métodos ágeis terem um viés mais transparente e colaborativo, uma percepção maior de integração e não distinção entre diferentes crachás no dia-a-dia, esta diferença estará presente em questões contratuais e decisões gerenciais e executivas a nível estratégico.

COMUNICAÇÃO

Pessoalmente, acredito ser este um gap significativo no Agile, um bom plano de comunicação, com a especificação de status reports e relatórios relevantes aos stakeholders e demais envolvidos. Tenho em alguns projetos remotos ou com equipes distribuidas o hábito de implementar status reports diários sobre o andamento da sprint e quinzenais com o andamento do nosso plano de sprints e releases. Desconheço stakeholder que não agradeça, especialmente se o projeto tem “alguma” relevância.

status report censurado

LIÇÕES APRENDIDAS

Muitas vezes temos um desleixo neste quesito em equipes ágeis, mas o que esperamos é que os dados, métricas e lições aprendidas em retrospectivas de sprints e releases sejam persistidas em um bom repositório, assim como é sugerido pelo PMBOK. Quer seja em uma ferramenta ALM, uma wiki, uma solução proprietária ou aberta, estas informações gerará a base de conhecimento organizacional que suportará as suas comunidades de prática, treinamento de novos colaboradores, grupos de usuários, etc.

MONITORAMENTO e CONTROLE

O registro de mudanças possui uma abordagem bem diferente, mas tem o mesmo objetivo, quer via change request ou pela atualização do product backlog, acompanhando o andamento dos artefatos, dailys, reviews e retrospectivas, através do uso de dashboards e registrando em quadros de portfólio.

A grande diferença é a alçada, que no PMBOK envolve uma análise de impacto e negociação explícita, enquanto no Agile é um trabalho de equipe a cada passo. Não se deixa de avaliar impactos, causas e efeitos, desdobramentos, a diferença é mais decorrência do tipo de contrato firmado, com escopo aberto ou fechado.

Uma equipe ágil que atue em um contrato de escopo fechado realiza estas análises de impacto e gera os registros, de acordo, conforme definido em clausulas contratuais. O contrato fará com que a documentação e registro formal aconteça, mesmo que internamente a equipe conduza seu trabalho de forma colaborativa e ágil, conheço várias situações deste tipo … faz parte!

SCRUM e PMBOK

Curto muito o livro SCRUM e PMBOK, juntos na gestão de projetos, do Fábio Cruz, uma análise lúcida sobre a relevância e complementariedade entre estes dois guias de boas práticas nos dias de hoje, especialmente para grandes empresas, a aquelas que atuam em editais ou prestando serviço a corporações que exigem em seus contratos artefatos do PMBOK.

A cada dia aumentam os pontos de contato, quem enxerga uma solução futura única para tudo, está idealizando um cenário para o qual as grandes corporações ainda não estão preparadas, talvez nunca estejam e nem queiram estar … aí não estamos falando de futuro próximo, mas do próximo filme do Shrek, pois está “tão tão distante”.

Anúncios

5 Respostas para “A mítica dicotomia PMBOK x SCRUM

  1. Me lembra a discussão sobre ágil e CMMI. Já viu essa?

    • Claro, mas é aceitável que não se biquem, tanto CMMI quanto MPS-Br sã originariamente bem engessados … Mas assim como o PMBOK a tendência é ir aliviando para que seja possível uma coexistência pacífica. 🙂

      • Ágil e CMMI, na sua opinião, são compatíveis? Na minha, são, e devem ser adotadas em paralelo.

      • Está na linha de uma das minhas maiores defesas quando em grandes empresas, é preciso manter, apenas ajustar, mas manter uma boa governança, um bom processo, PMO, documentação viva e inteligente. Não vejo nada disso como antagônico ao Agile, apenas é certo que há um esforço em equalizar tudo isso a luz de equipes ágeis de alta performance, time to market, em ciclos iterativos-incrementais-articulados … Normalmente as grandes empresas já possuem CMMI, MPS-Br ou processos mais ou menos rígidos, precisam apenas rodar alguns pilotos e gradualmente acoplar os princípios, métodos e técnicas, aos poucos, sem rupturas. Concordo contigo!

      • Legal! Eu sempre vi CMMI como uma espécie de livro de receitas, das quais eu posso selecionar práticas que todo projeto precisa. Assim, quando eu monto e toco um projeto Scrum, eu sempre faço documentação e GC (CMMI 2), mas raramente faço Treinamento ou Gestão de Aquisição. E sempre que eu adoto uma prática CMMI, faço no espírito de maximizar o trabalho não-feito. 🙂

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s