Esta cultura tem tornado cada vez menos rígida a fronteira entre o desenvolvimento e as operações de TI necessárias para manter os sistemas no ar.

Diante dos muitos benefícios trazidos pela adoção das práticas de DevOps, principalmente em times ágeis, quais seriam as razões para que esta cultura tenha ganhado força somente num passado recente? Que fatores motivam as práticas de DevOps? Que fatores permitiram que o DevOps se tornasse uma realidade?

No post de hoje vamos elicitar 3 grandes motivadores da cultura DevOps na atualidade.

O conflito histórico entre equipe de infra e equipe de desenvolvimento parece estar com os dias contados. As práticas de DevOps vem com o objetivo de facilitar a integração entre atividades de desenvolvimento, como criar novas features, resolver bugs, etc, e as operações de infra para manter o sistema no ar como manutenção dos servidores, sincronização e deploy do código, etc.

Realizar estes dois tipos de tarefas de forma coordenada pode trazer diversos benefícios através da colaboração entre os profissionais que criam e testam as aplicações e as equipes que mantém todo o ambiente de produção no ar. Para mais informações sobre DevOps, leio o post "Já Ouviu Falar em DevOps?".

Como falei no início do post, os processos de DevOps começaram a marcar presença mais fortemente nos times de TI somente nos últimos anos. Principalmente pela constante necessidade de mudanças e, consequentemente, pela maior necessidade de agilidade nas entregas, o cenário que encontrado em muitos times de desenvolvimento praticamente "pedia" a aplicação dos processos de DevOps.

Entender os motivos que levaram a ascensão destas práticas pode ajudar na aplicação das mesmas de forma a extrair o máximo dos benefícios trazidos com as técnicas de DevOps. Abaixo, enumeramos 3 grandes fatores que ajudam a entender o porquê da adoção e valorização das práticas de DevOps atualmente:

1. Cultura Ágil

Dentre tantas melhorias, como os avanços nos meios nos setores de telecomunicação e tecnologia da informação tornaram a realidade das organizações cada vez mais dinâmicas.

Com ambientes mais dinâmicos surge a necessidade de maior flexibilidade e respostas mais rápidas às mudanças. Mais especificamente na área de TI, é preciso que os sistemas sejam desenvolvidos e mantidos de maneira que mudanças possam ser aplicadas com agilidade.

É necessário estar continuamente entregando valor. Para que isso seja possível é preciso que, uma vez desenvolvido, um sistema possa ir para produção rapidamente e com qualidade. Um gargalo que pode ser comumente encontrado é na burocracia muitas vezes imposta pelas equipes que mantém os sistemas no ar. Para estas equipes, a priori, mudanças não são bem vindas e estão sempre associadas a riscos. Porém, para o negócio as mudanças tem se tornado cada vez mais necessárias.

O tempo entre o desenvolvimento de um recurso e o deploy em produção pode ser um fator determinante para o sucesso ou fracasso de uma iniciativa de uma organização. Diante deste cenário é possível notar os processos de DevOps surgem como uma prática interessante na medida em que permitem que as mudanças sejam levadas rapidamente para produção de forma coordenada e com qualidade, reduzindo o time to market.

As práticas de DevOps tratam de tornar mais eficientes e, quando possível, automatizar todas as operações necessárias para que um código saia do desenvolvimento e chegue em produção com rapidez e qualidade, que é o que se pretende dentro da cultura ágil.

2. Tecnologia

Operações como realizar deploy de forma bem controlada, gerar de pacotes, executar testes, automatizar scripts para sincronização de pacotes, dentre outras operações não são desejos recentes na TI.

Antes mesmo do crescimento da cultura ágil e da necessidade de entregas contínuas, a automatização de operações de TI já era um desejo em muitos times. Podemos nos perguntar: Então por que estas operações ganharam maior atenção agora com as práticas de DevOps?

O primeiro ponto que me vem em mente é o fator financeiro. Antigamente, responder rápido a mudanças era algo não tão "lucrativo" quanto hoje. Primeiro porque o custo para automatizar estas operações era mais alto.

Segundo, por que a necessidade por respostas rápidas a mudanças não era tão grande quanto hoje.

Outro ponto é a tecnologia. Atualmente com a virtualização e computação na nuvem, além da alta capacidade de processamento das máquinas, ficou facilitada a construção de ferramentas voltadas para o apoio às operações de TI, como automatização de testes e gerência de configuração,por exemplo. Além disso, os crescentes investimentos em aplicativos para dispositivos móveis tem impulsionado criações e atualizações que precisam ser lançados frequentemente com agilidade e qualidade.

3. Infra estrutura mais complexa

Manter os sistemas de uma organização no ar tem se tornado uma tarefa cada vez mais complexa. Atualmente, muitas são as formas de disponibilizar as aplicações no ar. A manutenção, que antes era feita somente sobre as máquinas físicas, hoje é feita sobre máquinas físicas, máquinas virtuais, além da nuvem.

Estes novos recursos permitem que as equipes responsáveis por manter os sistemas no ar tenham maior previsibilidade, garantias e SLA bem definidos na manutenção de seus sistemas.

Por outro lado, a complexidade decorrente destes serviços requer que as operações de TI estejam bem definidas e automatizadas na medida do possível, para garantir que os benefícios alcançados com estes serviços sejam alcançados.

A partir destes 3 grandes fatores fica fácil perceber a necessidade e os benefícios que o DevOps pode trazer às organizações atuais.

Para o desenvolvimento ágil é importante que as operações sejam feitas com a colaboração de todo o time, conferindo mais rapidez nas entregas, e economizando nas burocracias.

Métricas importantes como o Time to market são afetadas diretamente com a implantação das práticas de DevOps, que pode reduzir significativamente o tempo necessário para que um produto seja disponibilizado no mercado.

The post 3 Motivadores para a Cultura DevOps appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Muito tem se ouvido falar de Coaching no ambiente corporativo.

As organizações tem investido em mecanismos que focam no desenvolvimento pessoal dos seus colaboradores com o objetivo de atingir melhores resultados através da otimização do uso de seus recursos humanos. Em organizações onde se adotam a Mentalidade Enxuta (Lean), o Coaching pode ser uma importante ferramenta na medida em que leva os seus colaboradores e produzirem o máximo que podem, gerando os seus melhores resultados.

No post de hoje, apresentamos 3 razões para se adotar o Coaching, evidenciando 3 aspectos importantes na cultura ágil.

Existem diversos conceitos para o termo Coaching, mas todos convergem para mecanismos que focam no desenvolvimento pessoal e/ou profissional de um indivído.

O coaching é um processo onde um indivíduo (coach) apóia um outro indivíduo(coachee) na realização de um projeto ou solução de um problema.

Apesar de ser uma prática relativamente recente no meio corporativo, o Coaching é praticado a mais tempo no meio esportivo, onde é comum um treinador ajudar um atleta em sua caminhada num determinado esporte, motivando-o, ajudando-o a identificar o que faz de melhor, a encontrar a melhor forma de fazer o seu melhor.

No mundo dos negócios o mecanismo é o mesmo. O treinador (coach) ajuda um colaborador ou grupo de colaboradores a se autoconhecer, fazendo com que este colaborador ou grupo aprenda a identificar e lidar com as suas dificuldades, e reconhecer e potencializar suas virtudes profissionais e pessoais.

O coach não ensina nada ao coachee. Ele ajuda o coachee a aprender consigo mesmo, a partir do autoconhecimento e de questionamentos cujas respostas levem o coachee a desenvolver e aprimorar suas habilidades e a questionar e lidar com suas crenças limitantes.

A seguir, levantamos 3 pontos importantes na cultura ágil que são enriquecidos pelo processo de Coaching.

1. Confiança

A confiança é um ponto chave nas metodologias ágeis.

A confiança é imprescindível para o bom funcionamento de uma equipe auto organizada. Para se ter confiança na equipe, é importante que cada colaborador tenha condições de confiar em si mesmo.

Um que é muito trabalhado no processo de coaching é o autoconhecimento.

Uma das principais atribuições do coach é levar o coachee a refletir sobre si mesmo, a se autoconhecer. A partir do autoconhecimento, o coachee adquire confiança na medida em que identifica seus pontos a serem melhorados e os pontos a serem potencializados. A partir desta auto análise, o coachee, junto ao coach, podem elaborar um plano de ação com o objetivo de vencer as dificuldades e aprimorar suas qualidades, o que ajuda o coachee a aumentar a confiança em si mesmo e na equipe, facilitando a auto organização. Além disso, o autoconhecimento torna a equipe mais madura, facilitando o planejamento dos trabalhos e estimativas de esforço das tarefas.

2. Melhoria contínua

Um ponto importante na cultura ágil é o aprendizado que se deve alcançar a partir do processo iterativo.

No Scrum, por exemplo, ao fim de cada iteração, ou Sprint, o time se reúne para fazer uma retrospectiva. Nesta cerimônia, a partir da experiência adquirida na iteração que está terminando, os colaboradores discutem os pontos que podem melhorados e os pontos que devem ser mantidos nas próximas iterações.

O processo de coaching é baseado em um foco, que leva o colaborador ou grupo de colaboradores a executar ações, que geram resultados, que podem ser melhorados continuamente. Esta melhoria contínua nos resultados evidenciada pelo processo de coaching figura como um fator importante no mundo ágil na medida em que pode ser sinônimo de melhoria contínua no processo e no produto em desenvolvimento em uma organização.

3. Resultados – Valor Agregado

Um dos princípios do Manifesto Ágil trata da entrega contínua de software com valor agregado.

O resultado de cada iteração deve, necessariamente, entregar valor para o cliente. Para que se atinja o resultado de um Sprint, por exemplo, é preciso que a equipe converta seu trabalho e suas habilidades em valor agregado ao produto em desenvolvimento.

O coaching facilita este processo na medida em que o coachee é apoiado pelo coach com o intuito de atingir resultados. São os resultados desejados que norteiam as etapas do processo de coaching.

O coach ajuda o coachee levando-o a um caminho até a realização dos seus objetivos. Tanto o processo de coaching, quanto as iterações em metodologias ágeis, são norteados por objetivos.

Os objetivos traçados no processo de coaching, em geral não são os mesmos traçados para um Sprint ou para um projeto em desenvolvimento, pois em geral pertencem a domínios e escopos diferentes. Mas os resultados relacionados ao desenvolvimento pessoal de uma equipe alcançados a partir do processo de coaching podem influenciar diretamente os resultados desejados a cada iteração no processo de desenvolvimento. O aprimoramento de habilidades individuais ou coletivas alcançados com o coaching pode ter influência direta na geração de valor agregado em um projeto.

No post de hoje apresentamos brevemente o conceito de coaching e enumeramos 3 aspectos importantes na cultura ágil que podem servir de motivação para a adoção do processo de coaching nas organizações.

A partir da análise dos aspectos Confiança, Melhoria Contínua e Resultados/Valor Agregado, apresentamos 3 possíveis pontos de interseção entre os benefícios do processo de coaching e os valores da cultura ágil.

The post 3 Razões para o Coaching em Equipes Ágeis appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

A modelagem de processos figura como uma importante ferramenta de apoio neste desafio, permitindo que as organizações conheçam cada vez melhor o seu negócio. Principalmente em startups, conhecer o seu negócio, rodeado de incertezas, é fundamental para a sobrevivência da organização.

Em um post publicado aqui no blog recentemente, falei sobre os principais erros cometidos pelas organizações no que se refere à modelagem de processos.

No post de hoje vou falar um sobre notações utilizadas para modelagem de processos e mostrar 3 grandes razões para utilizar o BPMN, uma notação padrão.

Como mencionado no post 3 grandes erros na modelagem de processos, a modelagem de processos utiliza uma linguagem, ou notação, para representar o comportamento de uma organização.

Existem diversas notações, que foram sendo criadas em diferentes épocas e com diferentes objetivos e motivações: SPEM, Redes de Petri e BPMN, dentre outras, são exemplos de notações utilizadas na modelagem de processos.

Destacamos neste post a notação BPMN, Business Process Model and Notation. Como sugerido pelo próprio nome, foi criada originalmente para modelagem de processos de negócio. Apesar de ter o objetivo de ser um padrão, o BPMN tem se mostrado interessante até mesmo para a modelagem de processos mais específicos. Há pesquisas que mostram que o BPMN se mostrou eficiente nos processos de software, mais até do que o SPEM, criado especificamente para esta finalidade.

A seguir, apresento 3 razões pelas quais é interessante adotar o BPMN como notação para a modelagem de processos:

1a – Forma Gráfica

Um modelo expressado graficamente tende a ser menos subjetivo do que modelos em formato textual.

Em uma representação gráfica, a compreensão do processo como um todo é facilitada. Além disso, as fronteiras entre as responsabilidades dos colaboradores de uma organização e as entradas e saídas previstas em cada fase do processo ficam bem evidenciadas.

Abaixo temos um exemplo de processo modelado através do BPMN. Olhando a figura abaixo fica claro saber as responsabilidades de cada departamento e o que cada um deve consumir, processar e gerar como saída.

Order Fulfillment – Trisotech

(Order Fulfillment – Trisotech)

2a – Simplicidade

Para entender um processo descrito na notação BPMN, não é necessário ser especialista da área em questão. Profissionais de diferentes áreas e níveis podem compreender o comportamento da empresa representado em um modelo BPMN.

Os elementos gráficos, combinados aos labels facilitam o entendimento, minimizando a subjetividade. Os responsáveis por cada atividade, as entradas e as saídas são descritos de forma simples através dos elementos disponíveis nesta notação.

O entendimento do processo por parte dos variados setores e níveis de profissionais é importante na medida em que permite a cada colaborador compreender o seu papel na organização, abrindo espaço para melhorias em todos os níveis.

Em times auto-organizados é importante que todos conheçam bem o funcionamento da organização. O bom funcionamento da organização depende desta equipe. E para isso é importante que todos, nos mais variados níveis e funções, possam compreender o comportamento da organização em que colaboram.

3a – Notação Aberta

Esta é uma das principais e mais importantes características do BPMN.

Trata-se de uma notação não proprietária, de forma que não é necessário pagar para construir uma ferramenta para utilizar esta linguagem.  Por conta desta característica, dispõe-se hoje de diversas ferramentas BPMN, gratuitas ou pagas, disponíveis no mercado.

Por ser um padrão aberto, é possível construir modelos em uma ferramenta e exportar para outras, o que dá liberdade para que colaboradores possam trabalhar em um mesmo modelo utilizando ferramentas de sua preferência e de forma distribuída. Além disso, torna a organização independente de um fornecedor deste tipo de ferramenta.

Dentre as variadas notações para modelagem de processos disponíveis no mercado, o BPMN tem destaque por ser uma iniciativa com o objetivo de ser um padrão para modelagem de processos.

A ideia é ser uma notação genérica o suficiente para acomodar os principais elementos dos mais variados tipos de processo e, ao mesmo tempo, ser uma linguagem simples, que facilite a construção de desde os modelos mais simples até os mais complexos.

No post de hoje, destaquei 3 características do BPMN que o tornam uma escolha interessante como notação para modelos de processos. A sua forma gráfica, a simplicidade e o fato de ser uma notação aberta, fazem com que esta linguagem figure como uma escolha indicada para modelagem dos mais variados tipos de processo, principalmente quando é importante que todo o time de colaboradores conheça o funcionamento do negócio de sua organização.

E você, como norteia a escolha de notação para modelagem de processos da sua organização. Compartilhe conosco nos comentários! Até o próximo post!

The post 3 Razões para usar BPMN appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Muitas são as organizações que investem na gestão de processos com o intuito de conhecer, documentar, sistematizar, utilizar e retroalimentar o seu processo de negócio. Porém, existem alguns erros muito comuns na gestão de processos que podem torná-la uma ferramenta ineficiente e custosa.

No post de hoje apresentamos 3 dicas do que NÃO fazer na modelagem de processos.

O que é modelagem de processos?

De uma forma bem breve, podemos descrever um processo como aquilo que ocorre em uma sequência de etapas. Por exemplo, o processo de compra em uma loja virtual pode se dar pela sequência de etapas:

1. Acessar a loja virtual
2. Busca pelo produto
3. Visualização do Produto
4. Inserção do produto no carrinho de compras
5. Finalização da compra
6. Preenchimento de dados cadastrais
7. Escolha da forma de pagamento
8. Confirmação da compra

Este é um exemplo simples e representa apenas uma possibilidade de processo de compra em uma loja virtual. Muitas são as variações que este processo pode ter de acordo com o tipo de produto, de acordo com a loja, entre outros fatores.

A modelagem de processos trata exatamente de representar um processo em diferentes níveis de acordo com o que se deseja com a modelagem. De acordo com o objetivo, uma modelagem mais superficial pode ser suficiente. Por outro lado, podem ter objetivos que tornem necessária uma modelagem em nível mais detalhado.

Por que modelar processos?

Conhecer os pontos fortes e fracos de uma organização é necessário para que uma organização possa tomar ações no sentido de melhorar o que pode ser melhorado e garantir a manutenção do que funciona bem. A modelagem de processos é uma ferramenta que permite à organização visualizar a situação atual do seu processo de negócio, ajudando a identificar gargalos, pontos de falha, problemas de interface, dentre outros itens. Além disso, a partir de uma modelagem de processos fica mais fácil identificar possibilidades de melhoria mesmo em pontos que não sejam um problema, mas que podem ser melhorados.

Notação

A modelagem de processos utiliza uma notação (ou linguagem) para representar o comportamento de uma organização. Redes de Petri, SPEM e BPMN são exemplos de notações utilizadas na modelagem de processos. Por terem sido desenvolvidas em épocas diferentes e com objetivos diferentes, as notações podem apresentar diferenças. Assim, de acordo com o objetivo da modelagem, uma notação pode ser mais vantajosa do que outra. Em futuros posts discutiremos as principais diferenças entre as notações mais utilizadas na modelagem de processos e apresentaremos dicas de como conduzir a escolha de uma notação.

3 erros comuns na modelagem de processos

Alguns erros são muito comuns na construção da modelagem de processos nas organizações. Neste post apresento 3 deles:

1-Tentar modelar todo o processo em um único nível

Seja em grandes organizações, seja em pequenas, muito dificilmente o processo poderá ser representado completamente em um único nível. Os modelos devem ser construídos em diferentes níveis de abstração, que correspondem aos diferentes graus de abstração da realidade. Por mais difícil que pareça, é comum encontrarmos organizações onde os responsáveis pela gestão de processos tentam construír um modelo do processo inteiro em um único nível. Quando isto ocorre, o modelo tende a ser mais complicado de entender, dificultado a visualização do processo e a comunicação entre as partes envolvidas através do modelo.

2- Confundir um expert em ferramentas de gestão de processos com um gestor de processos

Outro erro comum é a confusão que se faz entre um bom usuário de ferramentas de modelagem de processos e um bom gestor de processos. Saber usar uma determinada ferramenta ou conhecer a fundo uma notação são muito importantes na modelagem de processos. Porém, é muito importante também que o responsável pela modelagem esteja qualificado para construir modelos adequados. Aprender uma notação, ou ser expert em uma ferramenta de modelagem não são garantia de que o processo será bem modelado. É preciso qualificação para construir bons modelos independente de notação ou ferramenta.

3- Não deixe a modelagem de processos somente com o pessoal de sistemas

Uma prática comum nas organizações atualmente é envolver cada vez mais o pessoal de TI na modelagem de processos de negócio da organização. De fato, é interessante que o pessoal de sistemas esteja envolvido na modelagem, afinal são eles quem vão construir os sistemas que podem tornar o processo mais automatizado e garantir que, na prática, as etapas previstas na modelagem sejam cumpridas. Porém é preciso cuidado para não deixar a modelagem do processos toda na mão da TI. Em geral o pessoal de TI participa da modelagem de processos de negócio com o objetivo de definir o escopo de sistema e seus requisitos. Quando a modelagem fica toda sob responsabilidade dos responsáveis pelo sistema, a tendência é que o modelo construído seja mais um modelo do sistema que vai ser construído ao invés de ser o modelo do processo de negócio da organização.

A modelagem de processos permite às organizações descreverem o seu processo de negócio e identificar pontos de falha e oportunidades de melhorias. A construção de um modelo do processo de negócio organizacional não é uma tarefa trivial e exige cuidados para que os objetivos pretendidos com a modelagem não sejam prejudicados.

No post de hoje apresentamos 3 erros comuns na modelagem de processos de uma organização. E vimos como cada um deles pode prejudicar a organização quanto aos objetivos pretendidos pela organização.

E você? Como trata da modelagem de processos na sua organização?

Deixe um comentário! Até o próximo post!

The post 3 Grandes Erros na Modelagem de Processos appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Muitas organizações encontram dificuldades para adotar metodologias ágeis, como o Scrum. Em muitos casos apenas algumas técnicas de agilidade são adotadas na prática, levando o time a não obter as principais vantagens do uso de metodologias ágeis. Na tentativa de usufruir de alguns benefícios do Scrum, algumas organizações realizam adaptações no framework a fim de adequá-lo a sua realidade. Estas adaptações, também conhecidas como ScrumButs tem se tornado muito comuns nas organizações.

No post de hoje compartilho com vocês alguns ScrumButs que tenho encontrado por aí.

O formato básico do ScrumBut é:

Nós usamos Scrum, mas <por alguma alguma razão>, <fazemos um certo workaround>.

A razão, em geral, é alguma dificuldade ou fruto da falta de entendimento sobre o framework Scrum. O workaround pode ser visto como a saída escolhida pelo time para tratar uma determinada dificuldade.

Muitos podem ser os ScrumButs. A seguir destacamos alguns bem comuns:

ScrumBut 1: “Nós usamos Scrum, MAS a reunião diária é muito longa, então nós fazemos reunião diária uma vez na semana.”

A reunião diária deve ser um breve resumo do status da Sprint. Apresentações técnicas, discussões, etc, devem ser feitas em outros momentos. Algumas equipes deixam de fazer a reunião todos os dias porque quando o fazem, levam muito tempo. O que deveria ser feito neste caso é buscar reduzir o tempo da reunião para que ela possa ser realizada diariamente, ao invés de deixar de fazê-la porque está sendo demorada.

 ScrumBut 2: “Nós usamos Scrum, MAS não gostamos de todas as práticas, então adotamos apenas as práticas mais atraentes”.

Segundo Kent Beck, engenheiro americano, criador do Extreme Programming (XP) e TDD, nenhuma prática isolada funciona bem por si só. Uma prática precisa da outra para manter o equilíbrio de todas. Usar apenas alguma(s) práticas(s) propostas pelo Scrum pode levar o time a não poder usufruir dos benefícios da agilidade, uma vez que pode não haver equilíbrio entre as práticas propostas pelo Scrum.

ScrumBut 3: “Nós usamos Scrum, MAS não estamos confiantes quanto ao nosso planejamento, então aumentamos o tempo do nosso planejamento.”

O planejamento de um projeto pode se tornar uma tarefa difícil e demorada quando o Product Backlog não está preparado. Em muitos casos, pela falta de histórias preparadas e priorizadas, a tarefa de planejar a Sprint pode ser prejudicada, ou até inviabilizada. Portanto, é preciso cuidar do Product Backlog para que o planejamento possa ser feito de forma eficiente. Este exemplo reflete a questão do equilíbrio entre as práticas do Scrum, mostrando como uma prática interfere na outra.

ScrumBut 4: “Nós usamos Scrum, MAS nós não conseguimos desenvolver uma história dentro de uma Sprint, então, aumentamos o tempo da Sprint para podermos implementar esta demanda.”

Scrum é TimeBox. Logo deve-se alterar o escopo da Sprint ao invés de se alterar a sua duração. Caso uma história seja muito grande, é recomendado que ela seja fragmentada em histórias menores que possam ser acomodadas dentro de uma Sprint sem que o tempo da Sprint tenha que ser modificado.

Alguns ScrumButs podem não ter workaround envolvidos, como o exemplo a seguir.

ScrumBut 5: “Nós usamos Scrum, MAS não gostamos, pois tornou nossa vida mais difícil.”

Em muitos casos, a transparência que se alcança pela adoção do Scrum, evidencia possíveis problemas no projeto em questão. Porém, ao invés de solucionar o problema, buscando primeiramente conhecer a sua real causa, algumas organizações culpam a metodologia, como se esta fosse a responsável pelos problemas que já existiam, porém só se tornaram conhecidos após o uso de técnicas ágeis. É preciso muito cuidado para avaliar a verdadeira causa dos problemas e não “culpar o carteiro pela má notícia da carta que ele apenas entregou”.

Apesar de atuarem como um grande obstáculo para o sucesso do uso Scrum, os ScrumButs são muito comuns.

No post de hoje apresentei alguns exemplos pelos quais já passei em uma organização que vem tentando adotar o Scrum. Podemos perceber que dentre outras dificuldades, as modificações no framework Scrum impedem que os benefícios do seu uso possam ser alcançados. Portanto é necessário que o framework seja utilizado adequadamente, sem alterações nos seus elementos básicos.

Você se identificou com algum destes ScrumButs? Conhece outros? Compartilhe conosco nos comentários! Até o próximo post!

The post Qual a sua desculpa? Conheça os 5 ScrumButs mais comuns por aí appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.