Como validar PDUs do PMI em treinamentos da Adaptworks?

Para renovar a certificação PMP (Project Manager Professional) do PMI (Project Management Institute), o profissional precisa coletar um total de 60 PDUs (Professional Development Unit).

Se você particiou das turmas de:

• Certified ScrumMaster
• Certified Scrum Product Owner
• Certified SAFe Agilist
• Certified SAFe Product Manager – Product Owner
• Certified SAFe Scrum Master

• Certified SAFe Advanced Scrum Master
• Management 3.0
• Certified Agile Professional

na Adaptworks, você pode solicitar a quantidade equivalente de horas de treinamento em PDUs.

Isso mesmo, todos os treinamentos acima podem lhe adicionar preciosos PDUs!

Se você estiver em busca de PDUs e fez um destes treinamentos conosco, segue os passos para solicitação dos PDUs:

1) Acesse o site do CCRS e faça login.

2) Clique em Report PDUs na barra de navegação a direita para iniciar o processo.

3) Clique em Course Training

4) Em Provider digite o nome da Adaptworks.
Provider: Adaptworks Treinamentos

5) Em Activity digite o nome do treinamento que você cursou.
Provider: NOME_DO_TREINAMENTO

6) Em description digite a descrição do treinamento que você encontra no site da Adaptworks.
Drescription: DESCRIÇÃO

pdu-adapt-pmi-cap-csm-cspo-artigo7) Preencha a data de inicio do seu treinamento.
Date started: DATA_INICIO

8) Preencha a data de fim do seu treinamento.
Date started: DATA _FIM

9) Preencha o endereço do nosso website.
URL: adapt.works

10) Preencha o nome do nosso contato comercial.
Contact Person: Marcio Santos

11) Preencha o telefone para contato na Adaptworks.
Contact Phone: (11) 2507-3563

12) Preencha o endereço de contato da Adaptworks.
Contact Email: contato@adaptworks.com.br

13) Clique em próximo

14) Em PDUs claimed, distribua o número de horas do treinamento entre Tecnhical, Leadership e Strategic. Recomenda-se 10 para Tecnhical, 3 para Leadership e 3 para Strategic. Totalizando 16 PDUS.

15) Clique em “I agree the claim is accurate” e pressione “Submit”.

16) Terminado, agora é só esperar a resposta do PMI.

Este fluxo é uma tradução livre das instruções do próprio site do PMI

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Certified Agile Professional, Management 3.0, PDU, SAFe, Scrum

5 lessons learned Coaching big companies

kratos-cover

Over the last year, Rafael Nascimento and I have been helping a big company through its global transformation towards the Agile state. This initiative has been a great experience for the whole Adaptworks team. We spent a lot of energy and we’ve got a lot of insights into how agile could be adopted by big companies. So, we would love to share with you our 5 key lessons from this case.

We won’t talk about the process or any internal decision made at this company but we’ll discuss in the next few paragraphs about our perspective as Agile Coaches. For this reason, the aim of these tips is to help other Agile Coaches to improve the action through some changing processes.

Let’s go to the tips:

  1. Combine the two hats – Agile Coaching is actually a combination of two approaches – Coaching and Mentoring. Remember that there’s a huge difference between both. When you’re acting as a Mentor, you provide the correct answers to solve some kind of problem. When you’re acting as Coach, you provide a set of questions to help people to find out the answers by themselves. So, it’s important to make this difference pretty clear to the audience. In addition, it’s vital that the Agile Coach recognises in which kind of situation Coaching and Mentoring could be applied.
  2. Pull coaching instead push coaching – After the startup phase, let people pull the Coaching or the Mentoring on demand. I mean, avoid pushing your service to people. Most of the time, only when people become aware of their problems, do they get the sufficient awareness and the motivation to accept Coaching. This is also a basic principle in Coaching. Many coaches get anxious to make the process work and don’t apply the right amount of patience that is needed to help a solution fit for that company and even for a specific team to flourish. So, keep your days busy talking to people about their environment, their problems and even about possible solutions to their problems. Keep yourself busy holding relevant talks and even internal webinars. Let people know that you’re capable of helping them, and they’ll talk to you when the time is right for them. And then you get (for free) a great opportunity to focus your energy, instead of wasting it chasing people that don’t want to listen to you.
  3. When you act as mentor, don’t start with magic solutions – Many coaches start their mentoring process by offering specific frameworks or specific tools to people. Agile, project management, business management and product development are really huge and have an amazing variety of tools that can be used in specific situations, using different mindsets. So, as a coach, really use the tools and frameworks that you have mastered from the toolbox. Again, invest most of your time listening to people’s problems, and offer them the tool or framework that may better fit their specific need and watch them walk away smiling.
  4. When you argue about the “why”, you’ll fail  –  When we’re in a change process we can organise the challenges into two big questions – why change?  and how to change? The “why”, most of the time, is compounded by values, beliefs and assumptions etc. The “how” is more related to operational stuff.  Due to these aspects, in our experience, if you as an Agile Coach are trying to argue about why the Coachee must change, you’ll fail. When you argue about the “why” you are trying to prove to someone about “my point of view is better than your point of view, so just accept what I’m saying!”  It’s quite dangerous because most of the time, it sounds like “my why is better than yours” or in other words, “my values are better than yours”. For sure, this kind of approach causes resistance and difficulty in the change process. For this reason, as an Agile Coach, help the people with questions. Especially open questions to help them explore their mental model and to find their own why.
  5. Don’t forget the software  –  Although Agile transformations have a great focus on management processes and leadership/operations roles, it’s highly important that you, as a coach/mentor, don’t forget you’re aiming to optimise processes for software development. What’s more, delivery/quality processes’ automation play a greatly important role here. It doesn’t matter how wonderfully the teams are following the agile processes or how we’ve been able to teach great Product Owners or Scrum Masters, or even if we’ve been able to create a set of metrics that make total sense with the new value delivery mindset. If the teams (and their processes) are really fast in executing, but are getting stuck when they try to deliver or assess an increment quality, you’ll gain a beautiful bottleneck and effective management processes just won’t make it. So, be obsessed with teaching and even provoking people about delivery/quality automation showing them tools you’ve used and cases you know about, always keeping the subject  alive and bothering them.

I hope you have enjoyed these lessons. We will share more tips soon. See you :-)

Nenhum comentário »

Categorias deste post

Agile, Coaching, Extreme Programming, SAFe, Scrum

Maior Escalabilidade de Agile com o SAFe 4.0

Hoje foi liberado pela Scaled Agile Academy a versão 4.0 do SAFe (Scaled Agile Framework).  O SAFe é um framework que vem evoluindo desde 2011 e nos últimos anos, tem se tornado uma importante referência para apoiar grandes organizações no processo de adoção de métodos ágeis em larga escala.
Essa versão 4.0, assim como suas antecessoras, é fruto da observação de como que as grandes organizações estavam endereçando algumas questões específicas do desafio de escalar métodos ágeis. De maneira geral, a versão 4.0 é baseada numa abordagem muito mais escalável do que as versões anteriores, como é de se esperar. Isso se deve ao fato de que tem sido muito frequente a adoção de SAFe em ambientes de larguíssima escala que rodam vários ARTs (Agile Release Train) de forma simultânea e integrada.  Por esse tipo de contexto, se fez necessário incorporar algumas importantes mudanças do framework.
SAFe40-BigPicture
(Clique para ver imagem em tamanho grande)
Dentre as várias mudanças, destaca-se aqui as  mais significativas:
  1. Adição do Value Stream Level –  Este novo nível enfatiza  o conceito de Value Stream, que já estava presente nas versões anteriores mas, que era pouco explorado/detalhado na BigPicture. Dessa forma, a versão expandida da BigPicture passa a contar com 4 níveis (Portfolio, Value Stream, Program e Team). Este novo nível se faz importante para organizações que estejam adotando Agile em cenários de alta escala (vários ARTs, adoções envolvendo milhares de pessoas, diferentes produtos, diferentes linhas de negócios etc). Vale reforçar que esse novo nível é opcional. Para muitos casos, a estrutura baseada em Portfolio, Program e Team será suficiente.
  2. Nesta nova versão existe a possibilidade de usar os sistemas Kanbans em todos os 4 níveis.  Nas versões anteriores, Kanban oficialmente constava apenas para apoiar a gestão de Portfólio. Mas na versão 4.0, é possível gerenciar o fluxo de trabalho usando Kanban nos 4 níveis (Portfolio, Value Stream, Program e Team).
  3. Spanning Palete – Alguns artefatos e papéis que já constavam nas versões anteriores, agora, (oficialmente) compõem um tipo de repositório de ferramentas opcionais, que podem ser usadas (ou não) em diferentes níveis e em diferentes formas.  Isso amplia as possibilidades de customização do framework.
  4. E por final, uma das mudanças que mais se destacou positivamente: o conceito de Community of Practices (Comunidade de Práticas) que agora foi incorporado oficialmente à BigPicture. Para quem não conhece esse conceito, vale a pena destacar que, trata-se de um grupo informal composto por representantes de diferentes times, que tem como principal objetivo, trocar figurinhas sobre problemas e soluções acerca de um assunto específico.
Tive a honra de acompanhar de perto o processo de discussão e validação da aplicabilidade das mudanças do framework. Por essa razão, vejo de uma forma extremamente positiva toda a forma como framework tem evoluindo buscando aumentar ainda mais a sua congruência com a realidade de grandes organizações.
Para entender mais sobre as mudanças, leia esse post que explica mais detalhes sobre melhorias desta nova versão.
Nenhum comentário »

Categorias deste post

Kanban, Mudança organizacional, SAFe

e-Book sobre SAFe

Nesse e-book Manoel Pimentel dá dicas para quem  está interessado em dar seus primeiros passos em direção a escalar ágil dentro de grandes organizações.

Se você já roda Scrum com vários times em sua empresa, mas ainda não descobriu uma forma de interagir e expandir a mentalidade ágil para as demais áreas da empresa e camadas mais estratégicas, então chegou o momento. Esse material é um bom começo!

Nenhum comentário »

Categorias deste post

SAFe

SAFe – Dicas para um AgilePMO

Nesse vídeo, Manoel Pimentel compartilha sua experiência e visões acerca de AgilePMO. Esse vídeo de cerca de 17 minutos, foi gravado para uma breve participação especial no Learning Shot da HappyMelly Brazil realizado em outubro de 2014 e apoiado pela Adaptworks.

Nenhum comentário »

Categorias deste post

Agile, SAFe, Scrum

SAFe com Manoel Pimentel e Alexandre Magno – #Videocast

SAFe com Manoel Pimentel e Alexandre Magno!

No videocast dessa semana, Manoel Pimentel recebe Alexandre Magno para baterem um papo e exporem os seus insights sobre escalabilidade (Scaled Agile Framework – SAFe).
Como o SAFe está ajudando as grandes organizações? Scrum e SAFe, como as duas práticas conversam entre si? Assista agora em mais um Videocast Adaptworks.

Obrigada por estar nos acompanhando, e na próxima semana mais Kanban com Rodrigo Yoshima – confiram!

Inscreva-se no treinamento “Safe”: http://www.adaptworks.com.br/TreinamentoDetalhes/certificacao-SAFe-agilist/

Conheça os outros treinamentos da Adaptworks: http://www.adaptworks.com.br/Treinamentos/.

Nenhum comentário »

Categorias deste post

Agile, SAFe, Videocasts

SAFe – FAQ #1

Com esse post, daremos início a uma série com FAQs (Frequently Asked Questions) sobre o SAFe (Scaled Agile Framework). As perguntas dessa série nasceram no grupo SAFeBrazil.  Os participantes do grupo já sugeriram várias questões, mas pesquei apenas algumas delas para começar a série de posts. Veja abaixo essas quatro perguntas e suas respectivas respostas. Se você deseja sugerir mais perguntas, entre no grupo e contribua com as suas dúvidas e questionamentos.

01) Como começar a implantação do SAFe?

Existem alguns caminhos possíveis para se começar uma adoção ágil. O SAFe trabalha com uma forma de tangibilizar os benefícios de Agile à todo o pensamento estratégico da organização. O SAFe busca criar um ambiente seguro para romper as  barreiras organizacionais e para gerar os ganhos em escala.  Isso acontece através de uma forte sensibilização da abordagem ágil às necessidades e anseios das pessoas que estão no topo das grandes corporações.

Observe que isso não significa que é obrigatório que essas pessoas (normalmente executivos, diretores, C-levels) se tornem agilistas da noite para o dia. Na verdade, trata-se de buscar uma forma em que a abordagem Ágil fale a mesma língua desse topo das organizações.

Para falar essa mesma língua é necessário entender e alinhar todos os potenciais ganhos, relacionados à métodos ágeis, à questões como redução de custo, menor custo de delay, aumento de qualidade, engajamento de colaboradores, redução de time-to-market ou, por um melhor aproveitamento das janelas de mercado.

Então, um dos possíveis primeiros passos é exatamente buscar esse alinhamento político sobre as expectativas da adoção de Agile e principalmente, criar uma integração efetiva do ciclo de desenvolvimento de software com esses anseios estratégicos e econômicos da organização (e vice-versa).

02) Como começar a aprender SAFe efetivamente?

O SAFe traz uma compilação de diversas abordagens já existentes, como por exemplo: pensamento Lean, os princípios do Product Development Flow, Scrum, XP e outras coisas.

Dessa forma, muito provavelmente você já conhece algum desses ingredientes.  E se esse for seu caso, você já começou a aprender SAFe. Contudo, o SAFe, através de uma boa combinação dos ingredientes citados acima, introduz uma completa estrutura metodológica de cerimônias e papéis para garantir uma sincronização e coordenação entre diferentes frentes de desenvolvimento de um mesmo produto/objetivo de negócio.  Então, além da própria experimentação diária que você pode fazer no front de batalha da adoção ágil, você pode participar dos treinamentos licenciados/certificados pela Scaled Agile Academy (instituição por trás do SAFe).  A Adaptworks, mais uma vez está sendo pioneira no Brasil e está ofertando em primeira mão os treinamentos para certificação em SAFe. Esses treinamentos são um excelente ponto de partida para que você se instrumente de ferramentas para rodar Agile em grandes corporações.

03) Pergunta que não quer calar… Qual é a relação de SAFe com o Scrum, um substitui o outro?

Scrum e SAFe muito mais cooperam do que competem nesse caso.  Como falei na resposta anterior, o SAFe é uma forte espinha dorsal que, através da combinação de Lean/Kanban/Scrum/XP, integra o pensamento estratégico organizacional ao dia-a-dia de trabalho do time.  Dessa forma, o SAFe tem um Scrum dentro de si.  Mas observe que isso é diferente de ser um Scrum estendido.

Dentro dos níveis de Portfolio, Programa e Time, o SAFe baseia o nível de Time fortemente em Scrum. Então no SAFe há papéis como Product Owner, ScrumMaster e Time. Além disso, existem as cerimônias de Planning, Daily, Review (Sprint Demo no SAFe) e Retrospective.  E principalmente,  um dos alicerces de todo o trabalho com o Scrum está fortemente presente: O reconhecimento do fenômeno da auto-organização. E por o SAFe ser um framework para gestão do trabalho em escala, ele também se baseia nas reuniões de Scrum-of-Scrums para uma das reuniões de sincronização e alinhamento do trabalho de diferentes times.

Então em resumo, o SAFe reconhece a eficiência que o Scrum introduz no dia-a-dia de trabalho de um time de desenvolvimento de produto, contudo, também reconhece que o Scrum sozinho é insuficiente para responder às perguntas organizacionais de grandes empresas. Por isso, o SAFe introduz outros elementos para ajudar uma empresa ter ganhos em escala com métodos ágeis.
Dessa forma, o SAFe ajudará a estruturar uma forma de resolver a necessidade de escalar e integrar a autoridade de conteúdo nos produtos, também introduzirá meios para sincronizar o resultado do trabalho de cada time, bem como, criar um cultura de priorização e planejamento ágil baseados em critérios econômicos.

04) Qual é o conceito de Time para o SAFe?

O conceito de time é algo universal e o SAFe não muda ou tem seu próprio conceito de time.  Então vamos assumir que um time é grupo de pessoas, que trabalham numa mesma direção, em prol de um mesmo objetivo e, que tem os resultados computados mutuamente.

A principal diferença que SAFe possui, é que existe um nível inteiro no framework dedicado ao trabalho dos times. Assim, o SAFe reconhece que haverão vários times trabalhando para um mesmo objetivo de entrega estratégica.  Esse trabalho precisará de um alto grau de colaboração, comunicação e comprometimento desses times.  Para isso, o SAFe evidencia  que é necessário  ter um estilo de liderança (em todos os níveis do framework) compatível com o processo  motivacional de times criativos.

O SAFe também trabalha fortemente com o conceito de Agile Teams ( ou Scrum Teams, caso prefira), nesse caso, teremos um time composto por pessoas com skill técnico de desenvolvimento,  uma pessoa no papel de ScrumMaster e outra pessoa no papel de Product Owner.  Mas também, o SAFe reconhece que existem, em diferentes níveis da organização, outros times. E esses times precisam ser considerados e integrados ao trabalho em escala de métodos ágeis. Dentre esses times que já existem na organização, podemos citar por exemplo, uma espécie de time de sistema (que na verdade pode ter outros nomes em sua empresa). Esse time de sistema normalmente cuida de questões como integração do produto com outros partes legadas do sistema, ou então questões relacionados à infraestrutura, produção, incidentes,  processo de deploy, testes integrados,   integridade e reuso arquitetural e outras coisas. Entenda, o SAFe é um framework fortemente baseado em integração.  Isso significa dizer que além dos típicos times ágeis, também precisaremos integrar, nos momentos  e assuntos certos, com o trabalho de outros times (até mesmo não ágeis) de sua organização.  Se você tem alguma experiência em grande empresa, saberá que isso é uma questão crítica para todo o trabalho com métodos ágeis.

Mas voltando ao nível de time (no framework), outro ponto importante, principalmente para a visão em escala, é que o trabalho nesse nível  é guiado por instâncias diferentes (mais integradas) de um artefato chamado Team Backlog.  Um Team Backlog é uma coleção de coisas que um time precisa fazer para avançar um incremento do produto/solução em desenvolvimento. Como teremos vários times trabalhando, então teremos vários Teams Backlogs. O conteúdo de um Team Backlog é uma derivação de um Program Backlog (que está no nível de programa). Um Program Backlog é uma lista única de Features (em alto nível) que comporão uma release gerada pelo ART (ver sobre esse assunto no artigo SAFe – Uma visão inicial de como escalar Agile)

Até a próxima pessoal!

Bom, por enquanto é só pessoal. Acredito que essas perguntas iniciais ajudem nossa comunidade a entender um pouco mais sobre como escalar uma adoção ágil através do SAFe.  Até a próxima rodada de perguntas e respostas sobre esse assunto.

Nenhum comentário »

Categorias deste post

FAQ, SAFe

SAFe – Escalando o Product Development Flow

Como mencionei no artigo anterior,  o SAFe – Scaled Agile Framework, é baseado em princípios Lean, em Scrum, em práticas XP (Extreme Programming) e, em uma considerável experiência de campo de uma ampla comunidade mundial. Ao aprofundarmos essas bases, vamos encontrar um elemento chamado de The SAFe House of Lean  (ver figura abaixo), que é uma variação do famoso House of Lean.  No The SAFe House of Lean, veremos os pilares e valores Lean.    E também veremos que o SAFe é fortemente orientado aos princípios do Product Development Flow (Fluxo do Desenvolvimento de Produto). Esses princípios foram muito bem sintetizados  por Don Reinertsen no livro Principles of Product Development Flow. Nesse nosso post, vamos ter uma visão inicial sobre  esse núcleo do SAFe.

SAFe-House-Of-Lean

Os princípios do Fluxo de Desenvolvimento de Produto são baseados em 08 temas. São eles:

1 –  Take an economic view (Adote uma visão econômica)

Apoie suas decisões sobre o portfolio de produtos e sobre toda a cadeia de desenvolvimento em critérios econômicos.  Adotar critérios econômicos não é algo trivial, pois envolve variáveis como Lead Time,  Custos e Despesas do Desenvolvimento, Geração Valor e também Risco.  O próprio Don Reinertsen reforça que se você tiver que quantificar uma única coisa, quantifique o Custo do Delay (CoD – Cost of Delay). Ou em outra palavras: Qual o custo ou prejuízo de sua organização demorar ou atrasar determinado produto ao mercado?

2 –  Actively manage queues  (Gestão ativa das filas)

Desenvolver, em diferentes níveis organizacionais, uma gestão inteligente sobre as filas de demandas é algo crucial para o sucesso de um portfolio de produtos.  Para isso, para cultivar uma forma inteligente de gerir as filas, é importante entender questões como o efeito que a Lei de Litle  exerce nas demandas, os efeitos de um processamento rápido sobre o tempo de espera e principalmente e ter o controle do tempo de espera através da gestão do tamanho das filas.

3 –  Understand and exploit variability (Entenda e explore a variabilidade)

Admite-se que não é possível gerar valor sem adicionar variabilidade no sistema de trabalho. Isso faz com que assumir riscos seja a base central para criação de valor. Dessa forma,  o SAFe reforça a necessidade de fazer Spikes. O termo spike é uma prática muito forte na XP (Extreme Programming) e ajuda a explorar variabilidade desejada e também ajuda evitar a variabilidade não desejada. Podemos dizer que encontrar esse equilíbrio entre variabilidade desejada e não desejada, é a essência de toda a busca ágil.

4 –  Reduce batch sizes  (Reduza o tamanho dos lotes)

Partindo do princípio econômico que grandes lotes de trabalho aumentam a variabilidade,  retarda o feedback e faz com  que o cycletime (tempo de ciclo) do processo seja igualmente grande, trabalhar com lotes menores, ajuda a reduzir o cycletime,  promove feedback mais rápido e, diminui a variabilidade e o risco do desenvolvimento. Lotes menores também otimizam a forma, o tempo e o custo de handoff (transporte entre etapas) dentro do sistema de geração de valor.

5 –  Apply WIP constraints  (Aplique restrições WIP – Work-in-process)

Gerenciar o WIP é parte central do Kanban. Na verdade, limitar o WIP é uma forma de aplicação do conceito Lean chamado de  Heijunka,  que em uma tradução livre, significa algo mais ou menos como: “Nivelar a carga de trabalho”.  O SAFe, por ser fortemente baseado em Lean, também estimula uma aplicação de Kanban em nível de Portfolio. Dessa forma, reconhece-se que restringir a capacidade de trabalho através uma política de WIP, aumenta a capacidade de entrega e torna o sistema mais fluído e, curiosamente, um pouco mais previsível.

6 –  Control flow under uncertainty: cadence and synchronization (Controle do fluxo sob a incerteza: Cadência e Sincronização)

Cadência torna os eventos imprevisíveis em eventos previsíveis. Já sincronização, estimula que múltiplos eventos aconteçam no mesmo momento. Entender essas diferenças básicas é importante para combiná-las de maneira efetiva em ambiente de escala. Para controlar o fluxo, mesmo sob a incerta, o SAFe  faz a distribuição dessa combinação nos níveis de  Portfolio, Programa e Time.  Essa distribuição  faz com que a organização tenha sensíveis ganhos de planejamento e aprendizado sobre os desvios gerados ao longo do caminho.

7 –  Get feedback as fast as possible (Obtenha feedback o mais rápido possível)

Aumentar a feedbackabilidade, não é algo novo para comunidade ágil. E para o SAFe, isso é o mantra vital a ser propagado em todos os níveis organizacionais. Isso é importante pois loops de feedback locais são inerentemente mais rápidos que os loops de feedbacks globais. Contudo, os loops globais se beneficiam do aprendizado obtido nos locais.  Esse efeito faz com o que a organização gerencie melhor o risco, corrija o rumo dos investimentos e cultive de maneira assertiva a inovação em toda a sua cadeia.

8 –  Decentralize control  –  (Descentralize o controle e as decisões)

A descentralização do controle e das decisões é o elemento crítico para cultivar times auto-organizados e, principalmente, criar um ambiente com maior fluidez na hora de responder às variações dos mercados, dos produtos e do próprio trabalho criativo. O SAFe reconhece que esse é um assunto crítico para que uma empresa possa de fato obter benefícios ágeis para o seu negócio. Dessa forma, as ideias do SAFe estimulam um pragmático reconhecimento de quais decisões, de efeito local, podem e precisam ser tomadas de maneira distribuída e quais as decisões, de efeito global, que ainda precisam ser mantidas de forma centralizada na organização.

 

Bom, essa foi a síntese sobre como o SAFe incorpora os  Princípios do Product Development Flow,  que é uma importante base para se conseguir escalar uma adoção ágil. Como mencionei,  esses princípios estão distribuídos por todos os detalhes do Scaled Agile Framework e norteiam todo o ciclo de desenvolvimento de produtos, desde o nível de portfolio, até o nível do dia-a-dia do time.  Obviamente, que o SAFe empacota esses princípios para que os mesmos sejam vividos de maneira plena, desde pessoas com papéis de C-level,  até todos os envolvidos desde da etapa da identificação de uma oportunidade de negócio, até a implementação da solução para aquela oportunidade. Caso queria mais informações sobre o SAFe, você pode fazer parte do grupo SAFeBrazil (grupo de discussões no facebook) e acompanhar discussões ou contribuir com novas dúvidas sobre o assunto. Até o próximo artigo!

1 Comentário »

Categorias deste post

Agile, Lean, Portfólio, SAFe

SAFe – Uma visão inicial de como escalar Agile

Imagine uma pessoa solteira por opção, que acredita que é uma péssima decisão casar e ter filhos. Imagine essa pessoa tentando aconselhar as ações e decisões de um casal com 4 filhos e que está tendo todos aqueles desafios típicos de uma grande família. Nesse cenário é fácil visualizar o solteiro emanando críticas, que no fundo, vão na linha de “vocês estão errados! Vocês deveriam era ter adotado a filosofia de não de ter filhos! É melhor para a sociedade etc.”.

O que você acha de uma abordagem como essa? Você há de concordar comigo que é, no mínimo, nada produtiva uma eventual discussão entre o solteiro e esse casal.  Baseados nessa metáfora, vamos analisar uma situação do mundo corporativo.  Tomando como referência uma empresa grande (casal com vários filhos) e um  time de desenvolvimento de software (solteiro),   seria igualmente pouco produtivo tentar ajudar a empresa grande, apenas com as ferramentas voltadas ao dia-a-dia do time e/ou do desenvolvimento de um produto. O ponto central da incongruência não é que uma empresa é mais importante ou mais complexa que um time, mas sim, os problemas de ser ágil em uma empresa inteira, com vários times, com diferentes partes de produtos, são diferentes (não melhores) de ser ágil em apenas um time autossuficiente.

É com o reconhecimento de que precisamos de uma abordagem apropriada para os desafios de adotar ágil em larga escala, que o SAFe vem ganhando um considerável número de experimentações ao redor do mundo.

Mas afinal, o que é o SAFe?

SAFe é um acrônimo para Scaled Agile Framework. É um modelo criado por Dean Leffingwell e mantido e evoluído pela Scaled Agile Academy . O SAFe é baseado em Scrum, XP (Extreme Programming), Lean e muita experiência de campo,  para a implementação de práticas ágeis em grande escala. Ele reconhece o que tipicamente tem funcionado bem no trabalho de times ágeis, na forma de fazer gestão de programa e na maneira  ágil tratar um portfólio de demandas organizacionais.  O SAFe fornece um conjunto de práticas para ajudar grandes organizações a responderem perguntas do tipo:  Como rodar ágil em contextos envolvendo vários times? Como sincronizar o trabalho desses times? Como coordenar o resultado do trabalho de times distribuídos geograficamente?  Como priorizar demandas em produtos robustos e dinâmicos? Como escalar uma arquitetura ágil? Como tratar, de maneira ágil, os riscos de um projeto complicado? Como ser ágil e estar em conformidade com modelos de governança?

SAFeBigPicture 

Um modelo de transformação respeitando o jeito de ser das empresas

Uma das características mais fortes do SAFe, é que o mesmo reconhece o jeito de ser de uma organização.  Isso dentro de uma empresa de grande porte, significa que o SAFe introduz a filosofia ágil na cultura organizacional e ajuda a empresa a gerar resultados, sem bater de frente com a estrutura e papéis existentes ou até mesmo, com a cola social vigente na organização.  Então, do ponto de vista estratégico, por ser um modelo que respeita o jeito de ser e a cultura das organizações, o SAFe tem ajudado o movimento ágil a chegar em empresas e em esferas que nunca conseguimos chegar antes.

O que difere o SAFe das demais abordagens ágeis. 

Como falei anteriormente, o SAFe bebe da fonte do Scrum, adota o XP com abordagem padrão para o time e, é fortemente inspirado pelo pensamento Lean para uma abordagem mais enxuta do portfólio de produtos. Então muito mais do que diferenças, o SAFe tem coisas complementares à todas essas abordagens.

Mas claro que o SAFe não é apenas um mix dessa práticas/abordagens. O SAFe oferece em encadeamento lógico de como ligar a estratégia da empresa (alto nível) à um ciclo de desenvolvimento realmente ágil (e vice-e-versa). Lembra da diferença entre os problemas e soluções de um casal com filhos para os problemas e soluções de um solteiro? Então, o SAFe obviamente introduz uma série de atividades, regras e papéis diferentes ao da abordagem pura do Scrum ou XP.   Essas peculiaridades, estão distribuídas principalmente nos níveis de Programa e Portfólio.  Por exemplo, se olharmos para maneira como o SAFe faz a gestão de portfólio, veremos que temos papéis mais específicos para o trabalho nesse nível,  então além de um trabalho forte de Program Portfolio Management,  também há o papel de Epic Owners. De uma maneira resumida, entenda que um Epic Owner é o responsável por grandes assuntos de negócio dentro um determinado objetivo de negócio (tema de negócio).

Mas o SAFe tem várias outras peculiaridades,  que em breve, escreverei com mais detalhes.

SAFe e Scrum

Note que na “cebola” do SAFe organizada em Portfolio Level, Program Level e Team Level,  o último nível (Team Level) é baseado em Scrum. No nível de time, ele trabalha com tudo aquilo que estamos acostumados no Scrum, então elementos como auto-organização, empoderamento da micro-gestão e colaboração são partes essenciais para o funcionamento do SAFe. Assim como o Scrum é um framework para a gestão do trabalho de times em ambientes complexos, o SAFe também é um framework para ajudar na gestão  ágil de vários programas organizacionais, de forma a fornecer para a empresa, uma maneira enxuta (maximização de valor e eliminação de desperdício) de gerar resultados em todo o seu portfólio de produtos.

SAFeScrumAndXP

Orientado à produto

O SAFe, ao contrário do que pode se imaginar, eleva ao máximo o conceito de organizar o trabalho por um forte senso de geração de valor. Uma das provas disso, é que dentro do SAFe, a disciplina clássica de gestão  de projetos (aquele conceito com início, meio e fim) praticamente desaparece.  No lugar dessa disciplina, o SAFe introduz fortemente a disciplina de gestão de produtos. Isso representa um salto gigantesco na maturidade com o qual as empresas devem lidar com a gestão de portfólio de seus produtos.   Para o SAFe, a forma de organizar a execução dessas demandas de trabalho sobre os produtos, é através de um conceito chamado ART.

ART – O coração do SAFe.

Na verdade, espero produzir vários e vários pequenos posts explicando os principais detalhes do SAFe, mas no momento, vamos entender o elemento central de todo o funcionamento do SAFe.

Esse elemento, nos termos do SAFe chama-se ART. ART é um acrônimo para Agile Release Train. ART é a forma do SAFe organizar a entrega de um épico de negócio (grande assunto em nível de Portfólio) dentro de um conjunto cadenciado e sincronizado de várias ações envolvendo diferentes times.

Sem entrar (ainda) nos pormenores de como funciona o ART, vamos nos ater na metáfora principal dele: O trem (train, em inglês).

A metáfora vem da ideia de: Um trem parte de uma estação e chega na próxima estação com um confiável agendamento.  Nesse caso, em termos práticos, teremos uma cadência fixa, uma velocidade “normalizada” e releases previsíveis.

Para colocar em prática essa metáfora, é necessário uma abordagem específica para organizar pessoas e processos ao redor da construção do ART.

Pessoas, pois um ART pode ser trabalhado por vários e diferentes times (cada um com sua respectiva Sprint). Então, vamos precisar de novos papéis para suportar a integração técnica e processual desses diferentes times. Essa é missão de um RTE (Release Train Engineer) – Em breve escreverei sobre esse papel também.

Processos, pois para entregar o incremento de produto gerado por um trem, que tem vários times trabalhando nele, será preciso trabalhar com mais de uma Sprint com a mesma cadência de início de fim para todos os times. Além de claro de outros detalhes que em breve escrevei aqui no blog.

Apenas uma coceira no cérebro

Bom, a ideia desse breve texto, foi gerar apenas uma pequena coceira no seu cérebro sobre o SAFe. Por tratar de um assunto crítico para as organizações (Agile em larga escala),  SAFe é um assunto realmente vasto. Portanto, conto com  feedbacks vindos por comentários, e-mails, tweets para me ajudar a compor um norte dos próximos assuntos que escreverei sobre o mesmo.

Também aproveito para convida-lo, a fazer parte do grupo SAFeBrazil (grupo de discussões no facebook – http://www.facebook.com/groups/SAFeBrazil).  Lá poderemos trocar mais figurinhas sobre o assunto e até mesmo esclarecer mais alguns detalhes sobre o SAFe e sobre o assunto Agile em larga escala de maneira geral.

Mais referências:

scaledagileframework.com

1 Comentário »

Categorias deste post

Agile, Mudança organizacional, Portfólio, SAFe, Scrum