Se por um lado, as startups (modelo enxuto e pouca dependência com sistemas legados) tiveram muita facilidade em adotar um modelo experimental e empírico, muitas outras organizações ainda enfrentam dificuldades em alavancar a transformação ágil, em razão da estrutura atual, competências, sistemas fortemente acoplados, aplicabilidade, entre outros.

Enquanto o Lean Startup, Lean UX e Lean Enterprise propõem o modelo experimental, baseado em validação de hipóteses e MVPs para lidar em domínios de extrema incerteza, o modelo projetizado enfatiza o processo linear, documentações e o upfront planning. A tríplice restrição em projetos tradicionais é estruturada com o tempo e custo variáveis, já o escopo fixo (com alterações via change request).

Software projects are a popular way of funding and organizing software development. They organize work into temporary, build-only teams and are funded with specific benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams working on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their end-to-end cycle time, and allows validation of actual benefits by using short-cycle iterations while maintaining the architectural integrity of their software to preserve their long-term effectiveness.

https://martinfowler.com/articles/products-over-projects.html

As principais diferenças entre a estrutura projetizada e “produtizada”:

Não é o objetivo desse post discutir a melhor abordagem. O foco é compartilhar alguns drivers que ajudam a quebrar paradigmas na reestruturação organizacional (e viabilizar o trabalho as abordagens).

• Qual é a melhor estratégia para transformar uma organização projetizada em produtizada? É aplicável a minha empresa?
• É possível conviver com ambas na mesma organização?
• Qual seria a função do PMO e outros departamentos nesse contexto?

O Cynefin framework é muito utilizado para entender e distribuir os projetos e portfólios no domínio de acordo com a sua complexidade e evitar os problemas que surgem quando seu estilo de gerenciamento preferido os leva a cometer erros. A gestão e distribuição adequada é fundamental.

Ok. Agora você já distribuiu os projetos nos domínios adequados e viu que a sua organização pode precisar de mais de um modelo (ágil e phase gate) para gerenciar o portfólio organizacional da melhor forma. Se for aplicável o uso de métodos Ágeis em todos os projetos, mas ainda necessária a transição, saiba que ela não pode acontecer somente a nível de time. Priorize a entrega de valor! A gestão estratégica de portfólio é essencial para alcançar o Business Agility, alinhando a estratégia e execução, baseado no Lean e systems thinking.

Descubra quantos flight levels existem na sua organização. Muitas possuem três níveis – operacional, coordenação e estratégico. Traga o top management on board e comece pelo nível estratégico de portfólio com foco nos problemas que precisam ser resolvidos e time to market. O TTM precisa incluir a nível de projetos, e não somente nas tarefas dos times.

A gestão da dependência entre os times (e não do time) é essencial no fluxo do produto. Também a criação de value streams, que são as etapas necessárias para prover serviços ou produtos aos clientes. Evite a gestão em silo com os times, controlando somente suas atividades interna.

Para as organizações que não se aplicam a transição ágil total, os projetos podem ser estruturados conforme a distribuição citada anteriormente. Em cenários preditivos, o modelo tradicional (waterfall) será utilizado com planejamento detalhado na fase inicial e requisitos claros. O escopo é fixado e o time trabalha para cumprir as datas de entrega no prazo.

Mesmo com a fase de planejamento realizada no modelo tradicional (custo, escopo, tempo, riscos, etc.), nada impede o time de adotar práticas ágeis na fase de execução para obter alguns benefícios, conforme a figura abaixo. A simples adoção de Sprints e cerimônias ágeis já trariam mais visibilidade e redução de riscos na execução. Claro, que a maioria dos benefícios vem da cultura/mindset (being agile), e não apenas de práticas (doing agile).

Como ficam os times nesse contexto? Para atender projetos gerenciados em modelos diferentes. Muitas vezes, não há como capacitar ou modifcar a estrutura hierarquica de imediato, o que dificulta a execução, já que não terá times totalmente dedicados e estruturado para entrega contínua. Sem contar os demais benefícios que being Agile poderia trazer.

A adequação é o único caminho nesse caso. Ajustar a capacidade do time, as responsabilidades, as cerimônias, entre outros. Não deixe atribuições sem um responsável. Por exemplo, no Scrum, o Product Owner é o responsável pelo backlog e priorização. Na ausência desse papel, essa atribuição deve estar com alguém no time.

A cadência em múltiplos níveis é uma opção a ser utilizada, permitindo a execução (a nível de Squads) com práticas ágeis e a sincronização dos times no nível intermediário (Scaled). A camada executiva é voltada ao report do projeto em nível estratégico.

Muitas empresas ainda possuem o portfólio com mais de um modelo de gerenciamento e utilizam o PMO para ajudar a priorizar e dar visibilidade ao nível estratégico. O SAFe prescreve muita coisa boa a nível de portfólio. Também sugiro a leitura de livros e artigos sobre como o PMO se modificou em meio a transformação ágil.

Nesse cenário, a FBS (Feature Breakdown Structure) é um recurso que representa o produto (Epic – Feature – User Story) e facilita a comunicação com os times. Também apoia na prorização baseada em valor de negócio e acompanhamento do trabalho realizado vs valor produzido.

No status report executivo, uma página que consolide os resultados da Sprint, com os dados qualitativos e quantitativos, além dos riscos e melhorias discutidos na retrospectiva do time.

* sabemos que há muitos contrapontos em reportar story points como medição de performance do time. Trata-se de uma sugestão (mediante o contexto de maturidade do time).

Conclusão
Mesmo que a organização “produtizada” tenha características, propósito, fundamentação e aplicabilidade bem distintas da projetizada, vimos que a transição ágil não é algo trivial, e por isso, deve-se distribuir os projetos em domínios de complexidade e avaliar a melhor forma de gerenciá-los para obter êxito nas entregas de cada um.

Em cenários complexos, em que os problemas são difíceis de serem previstos, utilizamos métodos ágeis por ser fundamentado no empirismo, onde é realizada uma pequena quantidade de trabalho para adquirir experiência (iteração) e mudança rápida, se necessário. Em cenários preditivos, segue o conceito de Big Design Up Front (BDUF).

Quando há ambos, e não é feita a criação de uma Business Unit dedicada a inovação ou outros meios para gerar independência de recursos e formato de atuação, pode-se ainda utilizar as recomendações feitas nesse post.

Leitura recomendada