Hoje continuo a falar mais um pouco das questões de gerência tradicional de projetos e o Scrum.

Particularmente, vamos tratar do papel do Gerente de Projetos em contrapartida a gerência de projetos com Scrum.

Tenho lido muitas publicações em fóruns e blogs de discussões sobre o tema, com opiniões as mais diversas possíveis.

Mesmo na prática, em organizações nas quais tivemos a oportunidade de auxiliar no processo de implantação do Scrum, há uma percepção inicial de que “sem gerente não pode haver gerência”.

Já identificamos em trabalhos anteriores que as barreiras culturais têm sido consideradas como uma das principais dificuldades na adoção do Scrum.

Nas nossas experiências, essas dúvidas e ansiedades foram se dissipando com a prática e com a evidenciação dos resultados alcançados.

O framework Scrum  especifica uma estrutura com cerimônias, artefatos e papéis definindo como as equipes devem trabalhar em ambientes com constantes alterações e com surgimentos de novos requisitos.

E é com base nessa especificação que chegamos a um entendimento de que mudam os papeis, mas as atividades de gerência permanecem, só que agora atribuídas ao SM, P.O. e Equipe.

Vamos tomar como exemplo algumas das atividades mais peculiares do Gerente de Projetos:

•  Atribuição de tarefas e prazos aos membros da equipe.

Times também são auto-organizáveis. Ninguém – nem mesmo o ScrumMaster – diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis.

• Identificação, documentação, gerenciamento e solução todos os problemas que possam surgir.

As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto.

• Controle da qualidade num nível de qualidade aceitável.

O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtosde maior qualidade. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.

• Cobrança de cada membro da equipe para que as tarefas atribuídas estejam sendo realizadas com sucesso.

Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente.

• Verificação das etapas do projeto visando a evolução para as fases seguintes.

  As Sprints contêm e consistem na reunião de Planejamento de Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas.

•  Verificação e a finalização do projeto e a realização de um levantamento dos erros e acertos.

Durante a Revisão da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. A reunião inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos.

A finalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores.

Vimos, portanto, que podemos redistribuir e atribuir as diversas outras atividades do Gerente de Projetos aos papeis do Scrum em suas cerimônias. Apesar de suas naturezas diferenciadas, o Scrum pode se alinhar a esses aspectos da gerência tradicional de projetos repensando os papeis e as atividades no processo.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Encontro vocês num próximo post. Até lá!

The post O Gerente de Projetos e os papeis do Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Hoje vou falar um pouco de outra questão frequentemente discutida que é o Scrum e a gerência tradicional de projetos, pois considero um assunto bastante interessante e polêmico.

Sempre que visitamos um cliente ou potenciais clientes ou conversamos com pessoas e profissionais que gerenciam ou trabalham em projetos, sempre se fala das questões da gerência tradicional comparativamente aos métodos ágeis.

Por um lado, dentre as metodologias ágeis o Scrum é a mais usada e com grandes perspectivas de aumento na sua adoção.

O framework Scrum não especifica nem ferramentas e nem técnicas de desenvolvimento, mas sim uma estrutura com cerimônias, artefatos e papéis definindo como as equipes devem trabalhar em ambientes com constantes alterações e com surgimentos de novos requisitos.

Ele propõe alguns níveis de gerenciamento em maior ou menor nível de detalhe, desde o planejamento diário, o gerenciamento da Sprint e até o gerenciamento do projeto.

Por outro lado, sabemos que o gerenciamento de projetos de software é, sem dúvida, um aspecto essencial para o seu sucesso e que por inúmeras causas os projetos falham, sejam eles ágeis ou tradicionais. A falta de entendimento, a experiência, os fatores culturais, as pressões externas, o treinamento insuficiente, dentre outras causas de falha são comuns a ambas as abordagens. Também sabemos que cronogramas irreais são provavelmente um dos principais fatores que influenciam no aumento das taxas de projetos rotulados como contestados ou fracassados.

O Scrum atua fortemente no gerenciamento de tarefas, no planejamento diário e no planejamento da Sprint. Dependendo do projeto e da organização isso talvez não seja suficiente e a adaptação do Scrum tem tudo a ver com essa necessidade, pois ela nos fala do “ajuste do processo ou do material sendo processado”.

O Scrum que foi originalmente concebido para o desenvolvimento de software, atualmente tem sido adotado em diversas áreas como: Recursos Humanos, Finanças, Publicidade, Engenharias, Laboratórios e em muitas outras.

Além disso, ele tem evoluído em termos de simplicidade e de adaptação.

Contudo, o Scrum não é o mais adequado para todo tipo de projeto e nem poderá atender integralmente a todas as necessidades de adaptação de todos os processos do PMBOK.

Até hoje, sempre que foi demandado, conseguimos adequar o framework Scrum aos requisitos dos projetos tradicionais. Já tivemos algumas oportunidades de falar disso em outros posts sobre Versões Scrum e Cronogramas Macros de Projetos, Um pouco mais sobre Versões Scrum e Cronogramas Macros de Projetos  e Diferenças entre Valores Ágeis e Tradicionais, somente para citar alguns.

No final das contas, fica tudo bem quando tudo acaba bem ou mesmo, mais ou menos bem. Mas, quando as coisas dão errado há que se eleger os “culpados” e é claro que as pessoas não têm culpa de nada. Daí a culpa é das ferramentas, ou dos processos ou dos modelos ou do método…

Quanto maior e mais complexo o projeto, mais difícil poderá ser gerenciá-lo. A verdade é que dentre os vários aspectos gerenciais importantes destaca-se o fato que alguns projetos exigem “gerentes” e “equipes” mais experientes e comprometidas, sejam eles ágeis ou tradicionais.

Enfim, apesar de possuírem naturezas diferenciadas no que se refere ao foco, escopo e aos princípios, o Scrum pode atender aos aspectos da gerência tradicional de projetos de forma complementar. Evidentemente, dependendo do esforço requerido e dos benefícios a serem alcançados.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Encontro vocês num próximo post. Até lá!
 

The post O Scrum e o Gerenciamento Tradicional de Projetos appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Recentemente publiquei um post relacionado às Versões do Scrum e Cronogramas Macros de Projeto apresentado como uma das dificuldades encontradas pelos usuários na adoção do Scrum. Falei um pouco da nossa experiência prática em projetos de nossos clientes, com os quais desenvolvemos um trabalho de capacitação e implantação do Scrum em seus processos de desenvolvimento de software.

Vimos que para atender a essa demanda no  Scrum, normalmente após a definição e estimativa do backlog inicial, podemos estimar o tempo restante com base na velocidade definida para a equipe na primeira sprint e elaborar um cronograma com essas estimativas.

Ainda sobre essas estimativas e, descendo um pouco mais no nível de abstração sobre como realizá-las, li há algum tempo um post no blog do Mike Pearce que propõe dois caminhos para estimativas macros de projeto: um baseado em pontos e outro baseado em horas, sendo esse último o que nos interessa, pois está alinhado, de alguma forma, com a abordagem discutida.

Não trabalhamos exatamente dessa maneira, mas caso seja possível adotá-la, achei a proposta bem organizada e interessante.

Muito bem! Tomemos como exemplo a definição e estimativa de um backlog inicial com 240 pontos de histórias. Vamos estimar o tempo do projeto considerando a velocidade da equipe que foi definida para a primeira sprint (20 pontos). Como resultado teremos 12 sprints com base em pontos de história, ou seja, 24 semanas. Evidentemente, trata-se de uma ideia muito aproximada  do tempo de duração do projeto, mas nada nos impede de elaborar um cronograma com essas estimativas.

Então, veremos a seguir o passo à passo (adaptado de Mike Pierce), assumindo-se que já existe um backlog ordenado por prioridades e agrupado em sprints :

1. Peça a cada membro da equipe para estimar um número máximo e mínimo de horas que eles podem trabalhar por dia no projeto (ex: Wakim: 4 – 5; Diego: 5-6 e Pedro: 6-7). Isto irá funcionar como horas por sprint. Por exemplo, Wakim poderá fazer 40-50 horas por sprint e a equipe de 140-180 horas por sprint;
2. Reponha todas as histórias no backlog ordenadas por prioridade;
3. Pegue a primeira história e pergunte a equipe: “Podemos fazer essa história em uma sprint?” Se a equipe disser que sim, agrupe-a. Se a equipe discordar se uma história cabe ou não na sprint, assumir que não;
4. Em seguida, quebre essa história em tarefas e estime essas tarefas em horas;
5. Execute os passos 3 e 4 até que a equipe diga que não cabe mais histórias na sprint com base no número total de horas (somando-se todas as tarefas) e suas horas de trabalho estimadas por sprint (ou seja: 140-180 horas por sprint). Como margem de risco deve-se parar na média de 160 horas;
6. Some o número de horas estimadas e agora teremos quantas horas a equipe pode realizar em uma sprint;
7. Some os pontos de história para a sprint, e teremos a velocidade da equipe.

Com isso, o gerente do produto pode ter uma estimativa do número mínimo e do número máximo de sprints do projeto  estimada em horas (assumindo-se que as sprints têm duas semanas de duração):

• (Total de horas para o projeto) / (menor estimativa horas semanais) = número máximo de sprints
  • Ex: 1920h / 140h = 14 sprints (aproximadamente)
• (Total de horas para o projeto) / (superior estimativa horas semanais) = número mínimo de sprints
  • Ex: 1920h / 180h = 11 sprints (aproximadamente)

É sempre bom lembrar que os projetos são planejados para semanas, meses ou anos e, em nenhuma das abordagens (tradicional ou ágil) sabemos exatamente o que acontecerá no final. A melhor coisa a fazer é fornecer atualizações contínuas para o gerente do produto.

Depois de ter realizado algumas sprints, teremos uma idéia melhor de velocidade da equipe e devemos rever e re-estimar o backlog, sempre que possível, para manter as estimativas de entrega atualizadas.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Encontro vocês num próximo post. Até lá!

The post Um pouco mais sobre Versões Scrum e Cronogramas Macros de Projetos appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá pesoal!

Temos publicado aqui no blog uma série de posts referentes às dificuldades encontradas pelos usuários na adoção do Scrum.

Uma dessas dificuldades está relacionada à definição de um cronograma macro do projeto, já que no Scrum o “cronograma” é definido por versões.

Nossa experiência prática também nos defronta com essa questão em projetos de nossos clientes, com os quais desenvolvemos um trabalho de capacitação e implantação do Scrum em seus processos de desenvolvimento de software.

Muito bem! Sabemos que no gerenciamento de projetos de software o planejamento é um aspecto essencial para o seu sucesso. Por outro lado, também sabemos que cronogramas irreais são provavelmente um dos principais vetores que influenciam no aumento das taxas de projetos rotulados como contestados ou fracassados.

A alocação dos recursos e a definição do cronograma são algumas dessas atividades de planejamento consideradas muito importantes, porém complexas, pois abrangem aspectos como prazos, custos, dependências entre as atividades, estimativas e alocação direta de recursos humanos.

Mesmo com as ferramentas e as técnicas disponíveis, os gerentes de projetos continuam responsáveis por soluções de qualidade alinhadas aos objetivos das organizações. Via de regra, tais soluções ainda observam as boas práticas, o sentimento, o conhecimento e a experiência pregressa desses gerentes.

No PMBoK, conhecido guia de boas práticas da gerência de projetos, esta atividade enquadra-se no processo denominado desenvolvimento do cronograma.

Do lado do Scrum, ele vem sendo utilizado para o desenvolvimento de produtos complexos desde o início dos anos 90 e o Guia do Scrum descreve como usar o Scrum para desenvolver esses produtos.

Lá encontramos também que o Scrum é fundamentado na teoria de controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos: a transparência, a inspeção e a adaptação.

Pois bem! E as Versões Scrum e Cronogramas Macros de Projetos como ficam?

Ainda nos reportando ao Guia do Scrum podemos aprender que:

Os Eventos com Duração Fixa (Time-Boxes) no Scrum são a Reunião de Planejamento da Versão para Entrega, a Sprint, a Reunião de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Reunião Diária.

Destacamos aqui a Reunião de Planejamento da Versão para Entrega, que é a que mais nos interessa no momento.

O propósito do planejamento da versão para entrega é o de estabelecer um plano e metas que o Time Scrum e o resto da organização possam entender e comunicar.

Uma das questões a serem respondidas pelo planejamento da versão para entrega é:

Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre Investimento (ROI) desejados?

O plano da versão para entrega estabelece a meta da versão, as maiores prioridades do Backlog do Produto, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para entrega a cada Sprint.

Muitas organizações já possuem um processo de planejamento de versão para entrega, e na maior parte desses processos o planejamento é feito no início do trabalho da versão e não é modificado com o passar do tempo. No planejamento de versão para entrega do Scrum, são definidos uma meta geral e resultados prováveis.

Esse planejamento geralmente não requer mais do que 15-20% do tempo que uma organização costumava utilizar para produzir um plano de versão para entrega tradicional. No entanto, uma versão com Scrum realiza planejamento no momento da execução de cada reunião de Revisão de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento diário no momento da execução de cada Reunião Diária.

De forma geral, os esforços para uma versão para entrega com Scrum provavelmente consomem ligeiramente mais esforço do que os esforços para um planejamento de versão para entrega tradicional.

Planejamento de versão para entrega requer estimar e priorizar o Backlog do Produto para a Versão. Há diversas técnicas para fazê-lo que estão fora do alcance do Scrum, mas que apesar disso são úteis quando usadas com ele.

Esse é um assunto interessante a ser tratado, pois para algumas pessoas há a impressão de que quando trabalhamos com o Scrum, não podemos lançar mão de outros recursos por falta de compatibilidade ou por alguma outra razão.

No Scrum, normalmente após a definição e estimativa do backlog inicial, podemos estimar o tempo restante com base na velocidade da equipe para a primeira sprint. E nada nos impede de elaborar um cronograma com essas estimativas.

Os projetos são planejados para semanas, meses ou anos e, em nenhuma das abordagens (tradicional ou ágil) sabemos exatamente o que acontecerá no final.

Como exemplo, num projeto com prazo de seis meses fixos com orçamento pré-definido, podemos estabelecer o número máximo de sprints para o esse período. Pode ocorrer do projeto terminar antes desse número máximo de Sprints ou algumas funcionalidades serem replanejadas ou mesmo excluídas do Backlog do produto, como já ocorreu, de fato, em alguns dos nossos projetos.

Com o Scrum, o Product Owner pode saber e corrigir periodicamente erros e acertos do projeto, visto que as entregas são parciais (transparência, inspeção e adaptação.

Voltando ao Guia do Scrum:

Ao se utilizar Scrum, os produtos são construídos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vão adicionando incrementos ao produto. Cada incremento é um pedaço potencialmente entregável do produto completo.

Quando já tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto é entregue.

E finalmente, mas não menos importante, não podemos nos esquecer que o Scrum não é um processo ou uma técnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro do qual você pode empregar diversos processos e técnicas. O papel do Scrum é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro do qual produtos complexos podem ser desenvolvidos.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Não esqueçam que, se precisarem, estamos prontos e experientes para ajudá-los nessa transição. Fale conosco em http://gpetec.com.br/informacoes.asp.

Encontro vocês num próximo post. Até lá!

The post Versões Scrum e Cronogramas Macros de Projetos appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá pessoal!

Nesse mês de fevereiro realizamos uma série de promoções para comemorar o aniversário de um ano do ScrumHalf. Numa das promoções sorteamos um jogo de cartas de planning poker para os participantes que respondessem a seguinte pergunta:

Quais foram as dificuldades encontradas para adotar o Scrum em sua empresa?

Quase que em sua totalidade todos os participantes responderam que uma das maiores dificuldades é de fato a mudança cultural, tanto para as pessoas como para a organização em si.

Relato a seguir alguns trechos de algumas respostas. Omiti propositadamente as autorias em atendimento às questões de privacidade dos participantes.

– “Mudar algo cultural é muito complexo. E quando se trata de gestão pior ainda, tem que ir por partes. A maior dificuldade é encontrar a rotina certa para migrar pouco a pouco (projeto por projeto), adotando de uma vez por todas a metodologia ágil”.

– “A empresa está tendo que se adaptar e está passando por mudanças culturais para se adequar a este novo método de trabalho. A maior dificuldade em adotar o Scrum, foi fazer com que os Gerentes de Projetos (PMO) entendessem como se trabalha com SCRUM, afinal o cliente exigia receber cronogramas baseados no PMI para gerir os projetos, sendo assim nossos PMO tiveram que se adequar para entender completamente o processo de SCRUM e assim refletir para o cliente em cronogramas o nosso trabalho”.

– “Foi difícil de convencer a todos a começarmos um piloto para pelo menos testar um processo baseado em Scrum. Depois, foi difícil de realizar a implantação no processo: antes, o pessoal que cuidava das funcionalidades faziam todas as especificações (documentos de requisitos extremamente detalhados), as enviava para um Gerente, que delegava tarefas para algumas pessoas, não havia interações entre os desenvolvedores, e no final juntavam os pedaços e iniciavam os testes. Nesse cenário, foi difícil de começar a criar histórias, fazer reuniões de planejamento, reuniões diárias e de não ter mais um Gerente”.

– “Tínhamos gerentes que delegavam as tarefas para as pessoas. Depois, com o Scrum não teríamos mais gerentes e sim um time auto-organizado. Acabamos tendo que colocar os gerentes com o papel SM/Time, porém o time acabava respondendo para ele nas diárias, sendo assim o time perdeu o autogerenciamento. Mas como o Scrum é empírico, um dia percebemos a falta de comprometimento do time, e identificamos que o motivo era que o time apenas respondia para o antigo gerente. Removemos o gerente das reuniões diárias, e aí tudo ficou bem melhor”.

– “Mas, todas essas dificuldades estão relacionadas à cultura da empresa. Em todas as dificuldades comparei com modelos de processo fechado devido à cultura da empresa está associada a ela, ou seja, desconhecem as metodologias ágeis e julgam como verdade as dos modelos fechados”.

-“Mudar o mindset dos gestores funcionais, que são controladores e não abrem mão de atribuir tarefas e fazer à micro-gestão”.

– “A maior dificuldade enfrentada pelos líderes de projeto da empresa foi a assimilação dos paradigmas preconizados pela metodologia ágil, frente às metodologias com ciclos de vida de projeto em Cascata (Simples ou com Sobreposição) e Iterativo-Incremental”.

– “Em nosso grupo encontramos dificuldade para adotar o modelo da autogestão num grupo acostumado à cadeia de comando tradicional”.

Na realidade, as respostas vieram a confirmar o que nós já esperávamos, em vista das experiências que obtivemos nos nossos trabalhos de capacitação e implantação do Scrum no processo de desenvolvimento de software realizados com os nossos clientes. Incluo aí a experiência de implantação na nossa própria empresa, onde hoje adotamos o Scrum na gerência de todos os nossos projetos, inclusive o projeto de comunicação e marketing.

Sabendo disso buscamos apoiar as organizações no processo de capacitação e implantação do Scrum, tornado essa transição o mais suave possível.

Em primeiro lugar fazemos uma campanha de disseminação da cultura Scrum na organização ou para o maior número de setores envolvidos. Divulgamos as principais informações sobre os benefícios, as vantagens e as possibilidades da metodologia em relação às abordagens tradicionais. Essas informações devem ser adequadas aos níveis organizacionais ao quais se destinam, sejam eles diretores, gerentes ou equipes de desenvolvimento. Pois afinal, de diferentes formas todos saem lucrando em termos de tempo, custo e qualidade nas entregas.

Em seguida é a hora e a vez do Treinamento & Prática das equipes Scrum. Treinadas as equipes, vem a última e mais importante fase do processo que é o acompanhamento na definição e execução de um projeto piloto real e imediato. Evidentemente, aqui temos que ter na eleição desse piloto um forte critério de abrangência em termos de escopo e profundidade, em razão das expectativas de entrega de valores aos clientes.

Depois da segunda ou terceira sprint os bons ventos começam a soprar, pois a transparência, a inspeção e a adaptação já denotam os seus benefícios reais, como tive oportunidade de abordar em outro post (E o Scrum para manutenção de sistemas? Podemos usar?).

Não havendo nenhuma restrição por parte do cliente, essa fase é totalmente suportada por nossa ferramenta, o ScrumHalf. A experiência nos mostrou que ela torna mais transparente e facilita bastante a transição para a prática do Scrum.

O bom de tudo é que, ao final do projeto piloto, apesar de todos os contratempos e dificuldades que irão ocorrer, é bem provável que se tenha uma equipe Scrum treinada, um projeto ou uma release entregue e um contingente de pessoas acreditando na Metodologia.

Além do impacto cultural outras dificuldades foram mencionadas das quais podemos citar:

– Projetos de escopo variável X prazo fixo;

– A mudança nos Papéis;

– Utilização de outras ferramentas para gerência projetos que não trabalham com o Scrum;

– Comprometimento do PO;

– Falta de conhecimento dos processos Scrum;

– Derrubada dos mitos sobre documentação, expectativas de prazo e estimativas por pontos  X horas;

– O time de desenvolvimento ser auto-organizável e multifuncional; e

– Decomposição em unidades de um dia de duração ou menos para as tarefas das histórias;

Mas, esses são tópicos que trataremos em outros posts mais específicos futuramente.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Não esqueçam que, se precisarem, estamos prontos e experientes para ajudá-los nessa transição. Fale conosco em http://gpetec.com.br/informacoes.asp.

Encontro vocês num próximo post. Até lá!

The post A adoção do Scrum e o Impacto Cultural para as Pessoas e as Organizações appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.