isabella fonseca et_ms_pmi-mg

1 Evento Técnico Mensal – Maio/2015

Evento Técnico Mensal Maio/2015

Isabella Fonseca 25/05/2015 [email protected]

Palestra: Gestão Ágil de Projetos Usando o método dentro e fora da área de TI e

Casos de sucesso


Apresentação

Isabella Fonseca É Certified Scrum Master (CSM) com 9 anos de prática de Scrum, tendo sido líder no SEPG que conduziu a Powerlogic à certificação MPS.BR Nível F em junho/2007 e MPS.BR Nível C em março/2010 incorporando grande nível de abrangência do Scrum, XP e Lean Principles. É também PMP-‐ACP. Atuou como Scrum Master e Product Owner participando de mais de 150 Sprints (iterações de desenvolvimento ágeis) rodados e aperfeiçoados ao longo dos últimos anos. Formada em Ciência da Computação pela PUC-‐MG com especialização em Redes de Telecomunicações pela UFMG. É consultora de processos de desenvolvimento de Software e Serviços na área de Qualidade da FUMSOFT.

Evento Técnico Mensal – Maio/2015


Bibliografia •  Jeff Sutherland, Scrum: A arte de fazer o dobro do trabalho na

metade do tempo, Leya: 2014

•  Takeuchi & Nonaka, “The New New Product Development

Game”, Harvard Business Review, Jan/Feb 1986 •  Artigo: “Por que SCRUM?”, ESM, 4ª. ed. (Agosto 2008) escrito

por Fonseca, I. e Campos, A. •  Agile Manifesto, http://agilemanifesto.org/ •  http://jeffsutherland.com/Agile2008MoneyforNothing.pdf •  Artigo: “Ideal Day e Priorização?”, ESM, 6ª. ed. (Outubro 2008)

escrito por Fonseca, I., Alves, M. e Alves, F.

•  http://www.scrumcasestudies.com



•  Ken Schwaber and Mike Beedle: Agile Software Development with

SCRUM, Prentice Hall 2001

•  http://www.forbes.com/sites/stevedenning/

•  http://www.infoq.com/br/news/2012/05/agile-‐gerencia-‐tradicional

•  http://www.infoq.com/br/articles/denning-‐radical-‐management

•  http://www.cutter.com/predictions/

•  http://agilemarketing.net

•  http://agilemanifesto.org

•  http://agilemarketingmanifesto.org

Bibliografia



Após 14 anos de Manifesto da Agilidade...


http://www.agilemanifesto.org

Motivações para busca de um modelo híbrido

“O caráter sensato “de ênfase” (e não ruptura) do Manifesto da Agilidade tem sido ignorado em algumas posturas radicais que, precipitadas, chegam a confundir agilidade com mera informalidade.”

Paulo Alvim


TEORIA DAS RESTRIÇÕES “Usando esse processo podemos enfocar nossos esforços nos poucos pontos de um sistema que determinam seu desempenho (nas suas restrições), e assim podemos melhorar significativamente no curto prazo.” Eliyahu Goldratt – A Meta

Escopo

Prazo Preço

Projeto Urgente

Escopo

Prazo Preço

Projeto Crítico

Escopo

Prazo Preço

Sem Orçamento Fonte: Processo de Desenvolvimento de Software da Powerlogic (PDS_P&D_v19)


Planos devem prever a possibilidade de mudança, descoberta e inovação!!!


Fonte: Craig Larman – Agile & Iterative Development

CONE DA INCERTEZA -‐ Planos evolucionários trazem maior possibilidade de acerto.



TEORIA DO CAOS – Trata do funcionamento de sistemas complexos e dinâmicos. Processos Preditivos não são adequados para este tipo de desenvolvimento de produtos. Não garantem sua previsibilidade!! Ser ágil é ser capaz de responder ou impor mudanças estratégicas.



PLANNING CONSTANTE!

Múltiplos PDCAs: Plan -‐ Do – Check – Act Ciclo de Deming tem por princípio tornar mais claros e ágeis os processos envolvidos na execução -‐> Melhoria Contínua Não adivinhe!! Verifique o resultado, aja de acordo com as informações e faça coisas de outra maneira!!



As atividades de planejamento para projetos de

desenvolvimento de produtos quaisquer devem se basear em

cinco níveis:

–  Visão do Produto –  Roadmap do Produto

–  Planejamento do Release

–  Planejamento da Iteração

–  Planejamento Diário

Fonte:http://www.rallydev.com/sites/default/files/5%20levels%20of%20agile%20planning-‐Portuguese-‐Final.pdf



Fonte: http://www.rallydev.com/sites/default/files/5%20levels%20of%20agile%20planning-‐Portuguese-‐Final.pdf



Fonte: Alistar Cockburn -‐ Agile Software Development




Previsões...

“Prevejo que muitas organizações mundo afora continuarão a adotar o ágil. A maioria delas o fará sem orientação de um expert, tendo resultados insatisfatórios, e pouco entendimento do porque destes resultados. As pessoas continuarão a se certificar em ágil enquanto outros questionem o valor e as implicações de tais certificações. As empresas ainda confiarão em caça talentos para contratar coachs ágeis, e se perguntam porque estes coaches não conseguem acertar as implementações ágeis da empresa. As organizações permanecerão agonizando no uso de micro-‐estimativas sobre backlogs super detalhados. Elas continuarão a gastar muito dinheiro na adição de profissionais a projetos cheios de dívida técnica, ao mesmo tempo em que não investirão nas habilidades e hábitos que seus desenvolvedores precisam ter para reduzir ou evitar o aumento da dívida. Os gerentes continuarão a usar termos como "Acabamos de contratar um recurso no desenvolvimento" sem dar a atenção devida a pessoa contratada.”

Gil Broza

Fonte: http://www.cutter.com/predictions/2012.html#brozag

Previsões 2012 – Mundo Ágil

“Muitas empresas adotarão o Scrum ou o Kanban e verão poucos benefícios. Em muitos casos, tratam-‐se de adoções que não recebem o apoio necessário -‐ é uma adoção apenas da boca para fora. Em alguns casos, as empresas começam a usar Scrum mas continuam a usar uma liderança do tipo comando e controle. Em outros casos, o Scrum trará a tona os problemas organizacionais, mas as pessoas argumentarão "Seria muito difícil mudar isso". Melhorias reais de desempenho vêm de um entendimento profundo de como o ágil funciona e de se comprometer de verdade com as mudanças, não de promessas vazias.”

Mark Levinson

Fonte: http://www.cutter.com/meet-‐our-‐experts/levisonm.html


“Há muitas, e eu ressalto muitas, práticas de desenvolvimento ruins por aí. Para cada organização que está acabando com estas práticas por meio do ágil, há outras cinco (meus amigos agilistas falam em dez) organizações que estão com dificuldades, entregando para seus clientes código cheio de problemas, perdendo prazos, ou sem funcionalidades prometidas. Frequentemente as três coisas juntas. Este problema de "Ir para o ágil sem saber como" é provavelmente uma consequência inevitável do sucesso das primeiras equipes que adotaram os métodos ágeis. Por exemplo, quando eu assisto as Olimpíadas, os patinadores fazem a patinação parecer fácil. Quando eu tento andar de patins, pareço desajeitado e me machuco. É difícil parar e lembrar que esses atletas, além da boa genética, gastam anos na pista com os seus treinadores aprendendo, tentando, falhando e melhorando, antes que eles apareçam diante das câmeras de TV. O ágil ficou popular, mas a maioria das organizações ainda têm poucas pessoas, com pouco treinamento, e praticamente nenhum ferramental. Claro, seu chefe não percebe quão inúteis são suas reuniões diárias, e que seu código não está plenamente testado no final do sprint, mas o que ele perceberá no final é que os clientes não estão satisfeitos.”

Lorne Cooper http://accurev.com/blog/author/lorne-‐cooper/


•  Em termos da curva de adoção de inovação, a adoção Agile "cruzou o abismo" e está em fase de inicial de maioridade, a maioria das organizações estão usando técnicas ágeis para, pelo menos, alguns projetos de desenvolvimento de software, um pequeno número fizeram do ágil a sua principal (ou única) abordagem de desenvolvimento e aqueles que fizeram a mudança de mentalidade, juntamente com fortes práticas técnicas, têm definitivamente visto melhorias mensuráveis em tempo de comercialização, qualidade do produto e satisfação do cliente.

•  Em muitas organizações as camadas executivas e de gestão são vistas como impedimentos para uma eficaz adoção ágil -‐ cultura de liderança, a mentalidade e estilos de gestão de comando e controle sufocam a criatividade.

•  Para várias organizações uma segunda onda de adoção do Agile está começando a acontecer, com um foco em disciplinas e práticas técnicas e uma ênfase em "faça certo dessa vez”.

•  Atingir escala é um desafio em muitos níveis -‐ descobrir a necessidade de escalar, o que isso significa em termos de amplitude e profundidade de adoção, e quais frameworks de escala concorrentes adotar, se forem adotados. As opções incluem Scrum de Scrums, SAFe, LeSS, DAD, o modelo Spotify de tribos, esquadrões e alianças.

Fonte: http://www.infoq.com/br/news/2015/01/state-‐of-‐agile?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_news_clk


•  Práticas e princípios ágeis estão começando a se espalhar para além do departamento de TI e agilidade em negócio será um tema quente durante os próximos anos;

•  Kanban está se tornando de uso comum, ou em conjunto com Agile (por exemplo

Scrumban) ou como uma abordagem independente para melhorar o fluxo de trabalho através de equipes de desenvolvimento e além;

•  Mais e mais programas de certificação estão aparecendo, com organismos de certificação

que competem entre si e oferecem credenciais semelhantes: ICAgile, Scrum.org, PMI-‐ACP, Kanban University, SAFe, Scrum Alliance, DSDM, entre outros;

•  Da mesma forma a capacidade de desenvolver mais rápido significa que DevOps vai se tornar uma obrigação para as organizações que querem tirar proveito do potencial para a agilidade que recebem de desenvolvimento rápido

Fonte: http://www.infoq.com/br/news/2015/01/state-‐of-‐agile?utm_source=infoq&utm_medium=related_content_link&utm_campaign=relatedContent_news_clk



Motivações para mudar! No contexto econômico de hoje, um tipo de gestão fundamentalmente diferente é necessário. As práticas existentes não são adequadas nem para atender às necessidades de um mundo moderno em alta velocidade, nem para apoiar a força de trabalho de hoje, que se sente motivada por uma liderança inspiradora. As organizações, reconhecendo que os ganhos com inovações simples são pequenas, estão atingindo vantagens competitivas através de inovação contínua centradas no cliente focando em criar valor mais rapidamente Organização para aumentar a geração de valor. Foco em redução de custo (modelo anterior) x aumento da receita.



Motivações para mudar!

Em um mundo de mudanças rápidas e constantes, a gestão precisa pensar e praticar a inovação contínua. Em uma economia do conhecimento, a empresa deve ser capaz de mobilizar todo o talento e energia dos seus profissionais. Em um mercado em que o equilíbrio de poder migrou dos vendedores para os clientes, a empresa deve ser ágil ao responder a clientes e consumidores.



Resultados Atuais

•  O retorno sobre bens (return on assets ou R.O.A) para as empresas norte-‐americanas tem caído de forma contínua, atingindo níveis próximos a um quarto do que eram em 1965.

•  Apenas 20 por cento dos profissionais estão realmente engajados em seus trabalhos e a rotatividade de executivos está aumentando.

•  Os consumidores estão se tornando cada vez menos fiéis a marcas e

•  A taxa na qual as grandes empresas perdem suas posições de liderança está aumentando.

Fonte: http://www.infoq.com/br/articles/denning-‐radical-‐management




Boas práticas e Estudos de Caso


Equipe Não busque por culpados! -‐> “Erro Fundamental de Atribuição”

•  Respondemos por nós pensando situacionalmente, enquanto os outros são julgados e suas ações são motivadas por seu próprio caráter.

•  São as interações com o ambiente em que vivemos é que estimulam nosso comportamento.

Comportamento = f (P,E) “O comportamento é uma função da personalidade do indivíduo e de seu ambiente.” Kurt Lewin

•  Portanto, não sendo possível mudar a personalidade das pessoas, consegue-‐se mudar seu comportamento através de mudanças no ambiente!



Mude o desempenho de uma equipe no lugar de um indivíduo. Tem um impacto muito maior!

•  Transcedência: Grandes equipes têm objetivo muito maior que o individual -‐> Inspiração.

•  Autonomia: liberdade de tomar as próprias decisões e capacidade de improvisar.

•  Interfuncionalidade: deve ter todas as capacidade de concluir um projeto.

•  Equipes pequenas: trabalham mais rápido que equipes grandes.

•  Não procure pessoas ruins, procure sistemas ruins.


Equipe


Boas Práticas – Plano de Capacitação

Fonte: h2p://www.powerlogic.com.br


Boas práticas: Sistema de Avaliação e Controle

A avaliação e o controle de um Plano de Tecnologia permite reduzir a diferença entre o desempenho esperado e o desempenho real, garantindo sua eficácia. Por isso, devem ser realizados antes, durante e após a implementação do Plano.

!

Desvio'de'esforço'ou'custo'no'projeto'

!

Gráfico'de'BurnDown'!

!

!!


Indicador que mede o progresso do trabalho refletindo diariamente seu trabalho. Sua curva indica se o Scrum Team está se adaptando para o plano definido e comprometido por todos -‐ Sprint Goal e conseguindo trabalhar de forma realmente iterativa ou sofrendo impedimentos em excesso.



Também é interessante armazenar o histórico de sucesso de alcance de goals a cada Sprint. Para isso, sugere-‐se criar um indicador simples de resultado por iteração a fim de manter a equipe focada em melhorar seu desempenho. Além disso, de forma lúdica, pode-‐se criar mecanismos de premiação em caso de alcances sucessivos.

Fonte: h2p://www.powerlogic.com.br/



É de extrema importância medir a efetividade em relação à liberação de máximo valor de negócio a cada entrega efetuada. Dessa forma, deve-‐se medir se o PO está priorizando corretamente as demandas de trabalho nas liberações ao longo do tempo.




Outro indicador também importante é se obter o quão eficaz está sendo o dimensionamento em tamanho dos requisitos. Dado os itens de selected backlog do sprint, comparar tamanhos previstos x realizados após a reunião de Release Review.




Dashboard que acompanha diariamente a evolução de entregas de BV e de esforço restante.

Fonte: Revista Visão Ágil – Gestão Ágil de Projetos com Scrum e FDD – Manoel Pimentel Medeiros



Tempo •  Limite insuperável do empreendimento humano! •  Mas o Scrum torna o tempo algo fundalmentalmente

cíclico. Cada Sprint é uma oportunidade de fazer melhor!!

•  Deve ter ritmo -‐> padrão virtuoso!

•  Somos movidos pelo hábito! Ciclos para promover o que temos de bom e diminuir o que temos de ruim. Feedback constante! •  -‐> Sprints e reuniões diárias.



Fonte: h2p://www.powerlogic.com.br

Tempo: Planning constante!


Tempo: Sprint Review – REAL!

▫ Realizada após cada Sprint, com duração de entre 2 a 4 horas e participação do PO.

▫  Equipe apresenta os resultados obtidos durante o Sprint.

▫ O Sprint Goal é verificado!

▫  Informal -‐> sem slides!!!


Tempo: Retrospective Meeting – REAL!

▫  Reunião com duração de 1-‐2 horas.

Levantamento das lições aprendidas.

▫  Timeline pode ser relembrado em grupo.

▫  2 perguntas: ▫ "O que foi bem?" (WWW-‐What Went Well?) e

▫ "O que pode ser melhorado? (WCBI -‐ What Can Be Improved?).


Tempo: Daily Scrum – viabilidade diária

Para manter o controle sobre o andamento do projeto, sugere-‐se fortemente investir 15 minutos diários para atualizar o status do “o que foi feito ontem“ e reafirmar o compromisso com o trabalho de hoje e da iteração. Problemas devem ser levantados e suas soluções devem ser definidas. A viabilidade é continuamente avaliada.

Nome%do%Release:%Nome%da%Iteração:%O%que%foi%feito%hoje%(tarefas)?%O%que%será%feito%amanhã%(tarefas)?%Que%impedimentos%ocorreram?%Riscos:%Viabilidade%comprometida?%!


Tempo •  Não ao desperdício!

•  Quando trabalhando em algo complexo, deve-‐se fazer uma coisa de cada vez (interferência dual de tarefas)

•  Percepção exagerada da nossa capacidade!

Se você tem 5 projetos, ¾ do seu dia são jogados fora! É uma limitação física do cérebro.


Número de projetos simultâneos

Porcentagem de tempo disponível por projeto

Perda com troca de contexto

1 100% 0%

2 40% 20%

3 20% 40%

4 10% 60%

5 5% 75%


Tempo •  Não ao desperdício!

•  Não fazer pela metade! Só cria inventário... WIP! •  Fazer certo da primeira vez!

•  Corrigir coisas fica mais difícil quando se passa mais tempo! Stop de Line!!

•  Trabalhar demais resulta em mais trabalho.

Produtividade x horas de trabalho. Na maioria das vezes, ao se trabalhar mais,

comete-‐se mais erros, se distraem mais e começam a tomar

decisões ruins.

Fazer qualquer escolha envolve gasto de energia



Tempo

•  Elimine os obstáculos -‐> impedem o avanço!

•  Entendimento de impedimentos: eventos que impeçam o progresso do time dentro do Sprint. •  Problemas pessoais •  Interrupções externas – atividades de

outro projeto, reuniões, atendimento, etc.

•  Devem ser tratados até sua conclusão.


Lista de Pendências •  Explicar o objetivo do que deve ser feito!

•  Fornecer as informações suficientes para que o trabalho seja feito da maneira correta.

•  O cliente deve ser o foco sempre! •  As pessoas pensam em narrativas -‐ histórias! Por isso, devemos nos centrar no personagem. Para quem a tarefa deve ser realizada?

Para quem? O que deve ser feito? Por que? “As necessidades mudam quando temos personagens diferentes.”

•  Priorizar!!! •  As histórias devem ser curtas!



Lista de Pendências -‐ Priorização

Pontos a serem levados em consideração: -  80% do valor de um software vem de 20% das funcionalidades -  Cerca de 60% das funcionalidades entregues em projetos de sucesso são raramente ou nunca utilizadas.

Fonte: h2p://www.soHhouse.se/


Um gráfico de quatro quadrantes de itens do escopo

que foram classificados em função seu BV e sua

facilidade de implementação. Itens que se concentram

no quadrante superior direito são os que devem ser

priorizados e, seguramente, são os que mais

representam a maximização do resultado.

Fonte: http://www.powerlogic.com.br

Lista de Pendências: Priorização


Plano Ágil

Sprint 1 48 SP - 400 BV





Plano de Projeto (Release Plan): Total de 245 SP e 1.000 BV

20%

20%

60%

Lista de Pendências: Priorização

Gaste 60% do tempo elicitando os 20% de itens no "topo da pilha"

Gaste outros 30% estimando os 20%

próximos

Gaste 10% para o restante


Lista de Pendências: Refinamento e Quebra


Lista de Pendências: Release e Sprint Goal

•  Breve declaração que informa o foco do trabalho

durante uma Release dado pelo Product Owner

•  Orienta o time no monitoramento e andamento dos

trabalhos e entrega de maior retorno de valor

•  Deve estar coerente aos itens de backlog da release – Release Backlog

•  Cria alinhamento entre PO, SM e Time e comunica aos

envolvidos em que o time está trabalhando.


Lista de Pendências: Transparência •  Torne tudo visível!!!


Fonte: Livro Scrum e XP direto das trincheiras


Lista de Pendências: Uso do BurnDown

Fonte: http://www.powerlogic.com.br Fonte: http://www.powerlogic.com.br

Fonte: http://www.powerlogic.com.br Fonte: http://www.powerlogic.com.br



Estudos de Caso


Estudos de Caso -‐ http://www.scrumcasestudies.com


Estudo de Caso

▫  FBI – ▫  2001 -‐ sistemas da década de 80 e relatórios de papel.

▫  2004/2005 – Projeto Virtual Case File (VCF) de três anos cancelado – 170 milhões de dólares no lixo!

▫  2005/2009 -‐ Sentinel – novo desastre! Previsão de 450 milhões de dólares. Duraria 4 anos, mas em Março/2010, foi cancelado (já haviam sido consumidos 405 milhões de dólares). Metado do projeto estava pronto e seriam ainda necessários 8 anos e mais de 300 milhões adicionais.


Estudo de Caso

▫  FBI – ▫  2010 – Jeff Sutherland foi chamado. O desenvolvimento foi internalizado e a equipe reduzida (de 400 para 40). ▫ 1100 requisitos priorizados. Novo prazo: 12 meses e 20 milhões de dólares. Estimativa inicial: chute! Era necessário rodar alguns sprints!!! ▫ No fim, foram necessários 20 meses para ter todo sistema funcionando e sendo utilizado pelo FBI.


Estudo de Caso

▫  Escolas holandesas – ▫ EduScrum: ▫ Escolhem equipes interfuncionais (ensina a trabalhar com pessoas e valorizar outras por ter talentos diferentes dos seus!) ▫ Carteiras organizadas em grupos! ▫ Utilização do kanban para planejamento das atividades de aprendizado. ▫ Uns ensinam aos outros!


Estudo de Caso

▫  Escolas holandesas – ▫ EduScrum: ▫ Energia traduz em resultados: aumento de mais de 10% nas notas ▫ Atual: 74 professores e 12 escolas (pretendem ter um crescimento de 60 professores e 15 escolas por ano)


Estudo de Caso

▫  Spotify: Sede atual em Londres e há desenvolvimento de

produto em Estocolmo, Nova York e São Francisco,

distribuídas em mais de 30 equipes.


Estudo de Caso

▫  Spotify: ▫ Uma equipe de desenvolvimento na Spotify é chamada Squad ("Esquadra"). Uma esquadra é similar a uma equipe Scrum, funcionando como uma mini-‐startup. A equipe é auto-‐organizada e possui autonomia suficiente para decidir o seu próprio processo interno. Possui Scrum, Scrumban, Lean startup – MVP, etc.


Estudo de Caso ▫  Spotify:

▫ Contratação de Agile Coaches ▫ Times independentes e pequenos ▫ Remoção sonstante de obstáculos e desperdícios ▫ Promove o hack-‐day: para aprendizado e inovação dedicam em reuniões quinzenais que duram o dia inteiro. ▫ Transparência, informalidade, propósito e missão bem definidos.


Estudo de Caso

▫  Zara: ▫ Agilidade interna: A empresa pode projetar, produzir e entregar peças do vestuário nas lojas pelo mundo todo em 15 dias, o que é impensável no mundo fashion onde designers costumam passar meses planejando a próxima estação. ▫ Não terceiriza: faz toda a produção interna -‐> multidisciplinaridade. Quem projeta e quem executa estão sentado ao lado. ▫ Produz e distribui produtos em pequenos lotes -‐> entregas regulares!


Estudo de Caso

▫  Zara: ▫ Envia as peças às lojas já com a etiqueta reduzindo o tempo de espera. ▫ Total foco no cliente coordenando trabalho em ciclos curtos direcionados pelo feedback do cliente.

▫ Resultado: ▫ Aumento nas vendas – quadruplicou ▫ Lucros operacionais elevados e economia estável apesar do mesmo não ocorrer no país de origem.


Estudo de Caso

▫  Marketing Scrum:


Estudo de Caso

▫  Open View Venture (empresa de capital de risco):

▫ Marketing Scrum: ▫  Definição de SMART goals: ▫ Aumentar acesso ao site 10% mês a mês ▫ Executar 3 eventos de sucesso de no mínimo 100 participantes ▫ Gerar 50 leads (MQL – qualificado) no final do trimestre através de webminars.


Estudo de Caso

▫  Open View Venture (empresa de capital de risco):


Estudo de Caso

▫  Open View Venture (empresa de capital de risco): ▫ Sprint Planning Meetings:


Estudo de Caso ▫  Open View Venture (empresa de capital de risco):

▫ Daily Scrums:


Estudo de Caso ▫  Open View Venture (empresa de capital de risco):


Estudo de Caso

▫  Salesforce: –  8 anos:

• No início: – 3 pessoas no P&D – 4 Releases por ano

• 7 anos mais tarde: – Aumento de 35.000 clientes – Mais de 200 pessoas no P&D, mas mais difícil de entregar...

– 1 Release por ano.


Estudo de Caso

▫  Salesforce: após seu crescimento!


Estudo de Caso

▫  Salesforce: –  Por que?

• Perda de visibilidade em todos os estágios para se completar uma release

• Feedback tardio! • Times grandes -‐> produtividade baixou • Entregas longas e imprevisíveis


Estudo de Caso ▫  Salesforce:

–  Em 3 meses de implantação do projeto Agile + 12 meses de mehoria contínua:


Estudo de Caso ▫  Salesforce:


Estudo de Caso

▫  Salesforce: ▫ Envio de 30 ScrumMasters para a certificação CSM

▫ Envio de 35 Gerentes de Produto para a certificação CSPO

▫ Coaching externo.


Estudo de Caso

▫  Salesforce:


Estudo de Caso

▫  Netflix: Objetivo de aprimorar o negócio e, por isso,

provocam iterações e mais iterações -‐> fast iterative

design approach.

▫ Atualiza seu site a cada 2 semanas com mudanças significativas e, portanto consegue: ▫ Falhar rápido – investe menos tempo em coisas que não irão funcionar ▫ Prover um ambiente de inovação contínua ▫ Aprender rápido ▫ Estimular interesse contínuo ▫ Reduzir risco: faz pequenas mudanças e conhece os riscos!


Estudo de Caso

▫  ING, Hubspot: Marketing Scrum


Estudo de Caso

▫  ING:


Estudo de Caso

▫  Hubspot: Empresa de marketing digital

▫ Quase 5000 clientes gerando 500.000 leads/mês


Estudo de Caso

▫  Hubspot:



Conclusão


Insight #1 – Agile Survey 2013


Insight #2 e #3 – Agile Survey 2013


While our own survey parMcipants are mostly from the IT industry (41%), there is good representaMon from Finance (12%), Government (6%), Healthcare (6%) and TelecommunicaMons (5%), indicaMng the growing interest in Scrum outside IT. We anMcipate this trend to grow in the future.

Outlook #1 – Agile Survey 2013


Outlook #2 – Agile Survey 2013


E por fim...

q Por tudo isso, o Scrum (e outros modelos e metodologias ágeis)

não é milagreiro. Quem contribui, em muito, para o sucesso de

um projeto, são as pessoas envolvidas: sejam desenvolvedores,

gerentes, o corpo diretor ou clientes. Todos devem estar cientes

do porquê utilizar as técnicas.

q Estas são somente algumas práticas que você pode aplicar para

complementar seu dia-‐a-‐dia no gerenciamento de projetos.


Obrigado!

Isabella Fonseca [email protected]

isabella fonseca et_ms_pmi-mg

Leadership & Management