Um modelo para gestão de mudanças , onde o conhecimento é o que mais importa

Um modelo para gestão de mudanças onde precisamos ter consciência da mudança, desejo de mudar, buscamos conhecimento para mudança, habilidade e reforço. A soma desses elementos aumentam a chance de uma boa mudança!

Um modelo para gestão de mudanças onde precisamos ter consciência da mudança, desejo de mudar, buscamos conhecimento para mudança, habilidade e reforço.O produto das relações desses elementos aumentam a chance de uma boa mudança!

ADKAR É um framework de agilidade praticado no mercado

.Indivíduos e interações mais que processos e ferramentas

.Colaboração com cliente mais que negociação de contrato

.Responder as mudanças mais que seguir um plano

.Produto funcionando mais que documentação abrangente.

Software rápido é a solução

Ferramentas otimizadas trazem os melhores resultados

SCrum é o caminho para dobrar a produtividade.

Coragem, respeito, transparência e adaptação

Todas as anteriores

Que a eficácia é um pressuposto e a eficiência é o que buscamos.

Que a eficiência é um pressuposto e a eficácia é o que buscamos. para trabalhos mecânicos

Que precisamos assumir que tudo que nos pedem são hipóteses e que precisamos reduzir o tempo de validação dessas hipóteses.

Que Eficácia só tem valor com a eficiência junto.

é um método ágil que ajuda a fazer o dobro do trabalho na metade do tempo.

É uma metodologia ágil usada para gestão de projetos exclusivamente de natureza de software

É um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos.

é um framework que tem como principal valor tem um conjunto de reuniões bem definidas e com regras claras para ajudar a entregar mais software em produção.

Scrum é baseado no empirismo e lean thinking. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado. O lean thinking reduz o desperdício e se concentra no essencial.

O framework Scrum é baseado em processos bem definidos e prescritivos que ajudam a dar intervisibilidade sobre as entregas.

O framework Scrum é propositalmente bem completo, definindo tudo que é necessário para implementar a teoria Scrum. O Scrum é construído sobre artefatos e processos bem definidos.

O framework Scrum é propositalmente incompleto, apenas definindo as partes necessárias para implementar a teoria Scrum. O Scrum é construído sobre a inteligência coletiva das pessoas que o utilizam

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada do produto com valor agregado.

Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.

As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizáveis.

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

Mudanças nos requisitos não são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem dos escopo fixo visando vantagem competitiva para o cliente.

Coragem, foco , e transparência

Melhoria contínua, coragem e transparência

Inspeção, adaptação e transparência

Inspeção, adaptação e melhoria contínua

Foco, respeito, coragem e transparência

Compromisso, Foco, Abertura, Respeito e Coragem

Inspeção, adaptação e transparência

Melhoria contínua, foco, coragem e respeito.

Um Scrum Master, um Product owner e Developers

Um Scrum Master, Um Product owner, o devteam e o gerente de projetos

O Scrum Master, Desenvolvedores, QAs, e o Product owner.

O Scrum Master, gerente de projetos, Desenvolvedores , QAS e o Product Owner

multifuncionais, o que significa que os membros possuem todas as habilidades necessárias para criar valor a cada Sprint.

São autogerenciáveis, o que significa que decidem internamente quem faz o quê, quando e como.

O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo dentro de uma Sprint, normalmente 10 ou menos pessoas

O Scrum Team é responsável por todas as atividades relacionadas ao produto, desde a colaboração com stakeholder, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento

Developers são as pessoas do Scrum Team que estão comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint.

O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team.

O Product Owner também é responsável pelo gerenciamento eficaz do Product Backlog

O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar as necessidades de muitos stakeholders no Product Backlog.

Scrum Masters são verdadeiros líderes que servem ao Scrum Team e à organização como um todo.

Scrum Master são responsáveis por treinar os membros do time em autogerenciamento e cross-funcionalidade;

O Scrum Master deve garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do Timebox.

O Scrum Master substitui o gerente de projetos em times Scrum.

Liderar, treinar e orientar a organização na adoção do Scrum;

Planejar e aconselhar implementações de Scrum dentro da organização;

Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos; e,remover barreiras entre stakeholders e Scrum Teams.

O Scrum Master deve se focar apenas no seu time e não na organização

A Sprint é um contêiner para todos os outros eventos

Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os artefatos do Scrum.

Os eventos são projetados especificamente para permitir a transparência necessária.

Os eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum

O propósito da Daily Scrum é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado.

A Daily Scrum é um evento de 15 minutos para os Developers do Scrum Team. Para reduzir a complexidade, é realizado no mesmo horário e local, todos os dias úteis da Sprint

As Daily Scrums melhoram as comunicações, identificam os impedimentos, promovem a rápida tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões.

A Daily Scrum não é o único momento em que os Developers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais detalhadas sobre a adaptação ou replanejamento do resto do trabalho da Sprint.

inspecionar o resultado da Sprint e determinar as adaptações futuras.

O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido.

Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o que mudou em seu ambiente. Com base nessas informações, os participantes colaboram sobre o que fazer a seguir.

Nela o Product Backlognão pode ser ajustado para atender a novas oportunidades

Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais informações. Assim, todos os que os inspecionam têm a mesma base para adaptação.

Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso pode ser medido:

Para o Product Backlog, é a Meta do produto, Para o Sprint Backlog, é a Meta da Sprint. e para o incremento a emta é a definição de pronto

Esses compromissos existem para reforçar a prescritividade e os valores Scrum para o Scrum Team, e seus stakeholders

O Product Backlog é uma lista ordenada e emergente do que é necessário para melhorar o produto. É a única fonte de trabalho realizado pelo Scrum Team.

Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma Sprint são considerados preparados para seleção no evento Sprint Planning.

O Product Backlog adquire uma grau de transparência após as atividades de refinamento.

O Product Owner e o Scrum Master que farão o trabalho são responsáveis pelo dimensionamento.

A Meta do Produto é o objetivo de longo prazo para o Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo.

O Sprint Backlog é composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como).

O Sprint Backlog é um plano feito por e para o Product Owner

A Meta da Sprint é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso dos Developers, esta fornece flexibilidade em termos do trabalho exato necessário para alcançá-la.