Transformação Ágil – Como Adaptar sua Empresa à Era Digital

A transformação ágil nas empresas é uma abordagem que tem sido cada vez mais adotada para aumentar a eficiência, reduzir custos e aumentar a satisfação do cliente. A transformação ágil consiste em uma série de práticas e metodologias que permitem que as empresas se adaptem rapidamente às mudanças do mercado, respondendo de forma rápida e eficiente às necessidades dos clientes.

Modelos de Transformação Ágil

Existem várias abordagens que as empresas podem utilizar para implementar a transformação ágil, sendo as mais comuns o Scrum, Kanban, Lean e Design Thinking. O Scrum é uma metodologia ágil para desenvolvimento de software, enquanto o Kanban é uma abordagem para gerenciamento de projetos. O Lean é uma filosofia que visa a redução de desperdícios, e o Design Thinking é uma metodologia para desenvolvimento de produtos.

Kanban para os céticos: analisando e derrubando mitos negativos

Como um agente de mudanças, devemos assegurar as pessoas de que vale realmente a pena seguir o caminho escolhido. Essa necessidade se torna aparente em críticas e perguntas difíceis. Vejo isso com frequência atuando como coach de equipes ágeis. O mesmo acontece ao se introduzir o Kanban. Porém percebi que a partir do momento em que as pessoas aprendem o básico e começam a explorar o assunto por conta própria, surgem questões muito mais difíceis, em níveis de gestão e liderança. Um exemplo: “Como podemos planejar já que medimos em vez de estimar?”

O Kanban é o novo Scrum?

Por vários anos, muitas pessoas consideraram o Scrum como o ponto de partida ao se iniciar uma implementação ágil. De fato, muitos acreditam (de forma equivocada) que Scrum e Agile são a mesma coisa. Pela atual popularidade e extensa adoção, o Scrum tem sido a escolha ágil padrão de muitas organizações. Entretanto, com o recente crescimento da adoção do Kanban, alguns o veem como o próximo passo na evolução do Agile.

Abby Fichtner declarou em seu artigo que o Kanban é o novo Scrum:

Talvez seja pelo tempo que passei em startups, mas apesar de valorizar muito as ideias do Scrum como a auto-organização das equipes e do feedback contínuo, não posso deixar de pensar no Kanban como o próximo nível de agilidade, permitindo mais flexibilidade e aprendizado com as lições que temos extraído do Lean.

Como adotar Scrum na sua empresa

Existem muitas discussões nos grupos que tratam de Scrum e Agile sobre qual é a melhor maneira de começar a fazer Scrum. Vou falar um pouco sobre o meu ponto de vista sobre como iniciar com Scrum na sua organização.

Primeiramente você deve se perguntar: Estou pronto para iniciar a mudança com Scrum? Deve saber que não é fácil iniciar essa mudança, mas a recompensa é valiosa.

Você irá precisar de apoio e suporte para a mudança, possivelmente de alguém acima de você na organização, sem esse suporte não é possível iniciar a mudança a que se propôs, mas também irá precisar de apoio de pessoas do seu dia dia, do seu grupo de trabalho. Forme uma equipe com espírito vencedor. Scrum pode ajuda com isso, mas há muitos outros fatores que contribuem. Lembre-se que a principal mudança está nas pessoas e estas sim podem fazer toda a diferença.

Use algumas métricas para mostrar que você está fazendo progresso (Ciclo de entregas mais rápidos, quantidade de bugs conhecidos, funcionalidades entregues por iteração, por exemplo) . Não deixe que eles insistam em métricas perfeitas (nunca irão existir) e certifique-se que as pessoas usam de bom senso na interpretação dos indicadores. Mas cuidado, métricas mal aplicadas tendem a se virar contra você.

Seja extremamente agressivo sobre a remoção de impedimentos pois isso é fundamental. Na equipe, pelo ScrumMaster, pelos gestores. Difícil prever de antemão qual será o seu maior impedimento, mas podem ser: as pessoas, falta de disciplina ao fazer Scrum (ScrumBut), práticas de engenharia, o fluxo de informações de negócios para a equipe (por exemplo, PO fraco, especialistas de negócio inacessíveis).

Construir o sucesso fora da equipe. Percorra a meta de sucesso do negócio (o cliente está realmente feliz) e não apenas de sucesso técnico (nós fizemos mais rápido o que dissemos que faríamos X meses atrás). Eu não sei o que vocês fazem hoje, mas posso apenas garantir que depois de 3 Sprints, algum grau de sucesso relativo vocês terão.

A ‘mudança de gestão ” quando adotamos Scrum é bastante significativa. É interminável. As pessoas pensam que eles entendem bem de Scrum, mas acho que a mudança de paradigma é realmente difícil, sair de um modelo tradicional para um modelo ágil não é feito da noite para o dia. Normalmente as empresas precisam de treinamento para as equipes. Saia do seu cubículo e vá procurar alguém que conheça bem essas práticas. Pense que não apenas você, mas que o time todo, talvez muitas pessoas da sua organização precisem de treinamento para poderem entender a mudança que o Scrum irá trazer à organização.

Cuidado com a dívida técnica. Adote as boas práticas (TDD, BDD, design patterns e outros), pois isso será será muito importante, mais cedo ou mais tarde. Comece a atacá-los desde cedo. Se o seu time não escreve testes automatizados, ele não é ágil. O verdadeiro sucesso com Scrum deve ser medido como 5x-10x melhor do que sua base atual. Algumas empresas fazem isso muito bem e, muitas vezes, mas a maioria nunca chega lá. Acho que o segredo não é tanto as práticas do Scrum, mas as pessoas fixando melhor os valores e princípios subjacentes. Sem os valores e princípios, uma “reunião diária”, por exemplo, pode ser quase um desperdício de tempo.

Depois de ter certeza que você realmente quer adotar Scrum, comece. Não espere ter o backlog perfeito, nem o PO perfeito e muito menos o ScrumMaster perfeito, você no início provavelmente não terá nenhum deles, isso vem com o tempo. Adote as mudanças e perceba seus resultados, procure sempre a melhoria contínua. Fazendo isto os resultados serão notados e você perceberá que todo o esforço valeu a pena.

Fonte: http://micajeho.wordpress.com

Scrum é framework e não metodologia

Um dos erros mais comuns ao se falar em Scrum é defini-lo como uma metodologia, algo que de fato ele não é, e vou explicar porque. Uma metodologia é o estudo de métodos e técnicas embasados científicamente utilizadas em processos de investigação. Diferente de um processo mais tradicional o Scrum não irá te dizer o que fazer, você tem a liberdade para fazer o que melhor funcionar dentro da suas necessidades e possibilidades.

Os pilares do Scrum, transparência, inspeção e adaptação é que nos fazem melhorar nosso processo e isso vem apenas com tempo, com as evidências de melhoria contínua. Isso já afirma que nosso processo necessita desses três pilares para garantir sua sustentabilidade e evolução. Sendo assim podemos dizer que não temos a solução nem mesmo a pretensão de prever tudo ou ter a resposta para todas as perguntas.

Em uma metodologia todos os processos são conhecidos e previamente definidos, ou seja, prescritivos, diferentemente do Scrum onde o processo de aprendizado é empírico. Acreditamos que cada experiência traz um aprendizado que deve ser levado em consideração dentro do processo de controle.

A Adaptworks, referência brasileira em Scrum, possui a seguinte definição : “Scrum é um framework iterativo e incremental para o desenvolvimento de qualquer produto ou gerenciamento de qualquer trabalho.”

Já Ken Schwaber da Scrum.org e criador do Scrum, defende que o este foi feito para desenvolvimento de softwares complexos, embora é conhecido que muitas empresas utilizam algumas práticas do Scrum e tem noticiado que tem sentidos os efeitos que as mudanças após a adoção Scrum proporcionaram para suas organizações. Quando começamos a usar Scrum não conhecemos todos os possíveis eventos, nem todo o negócio, nem mesmo os impedimentos que irão surgir durante o desenvolvimento.

Eu acredito tanto no Scrum que afirmo ser é viável adotar esse poderoso framework em outros ramos de atividade que não apenas desenvolvimento de software. Penso eu que numa empresa de marketing, por exemplo, é possível criar um product backlog com items de uma determinada campanha, e dele derivar as tarefas que devem ser realizadas assim como sua ordem de prioridade e retorno, definido sprints curtas para entrega de valor e por ai vai.

O Scrum irá te dar uma base de onde a partir dela poderá criar sua metodologia de acordo com as necessidades e peculiaridades da sua empresa. É permitido e digo até desejável aliás juntar práticas de outros métodos ágeis com o Scrum, como é muito comum o pair programming que vem do XP, por exemplo.

Por essa flexibilidade é que dizemos que o Scrum é um framework e não uma metodologia. Assim com qualquer framework o Scrum pode ser extendido, tendo algumas de suas práticas removidas se for o caso, mas cuidado ao remover alguma prática, pois o seu valor pode ser perder durante o processo. Tenha em mente os benefícios que tais práticas trazem para somente depois se julgar necessário remover algo. A Scrum.org já sinalizou que irá validar possíveis extensões no Scrum, para ver as propostas que já foram feitas sobre extensões por membros da comunidade basta acessar o site.

Fonte: http://micajeho.wordpress.com

Kanban! a Gestão Visual

 Kanban na realidade já é uma prática antiga muito utilizada, talvez a sua empresa já utilize está técnica e você não tenha notado, mas os seus resultados ajudam e muito no dia a dia, facilitando o processo de produção em todas as suas etapas, então vamos agora entender um pouco mais sobre sua origem e tambem de sua prática.

Kanban é uma palavra japonesa que tem como definição os termos Registro ou Placa invisível, isso mesmo, é através da identificação no fluxo do processo que o mesmo auxilia, podendo ser cartão, luzes ou caixas entre outras tantas técnicas utilizadas.

O Kanban é muito utilizado nas industrias automotivas em linhas de produção ajudando a controlar a Quantidade necessária entregue para cada etapa de um fluxo de manufatura e estoque, em caso desta quantidade se esgotar o aviso retorna ao seu ponto de origem gerando um novo pedido de mais peças ou não, criando assim um fluxo automático de produção, gerando resultados na produtividade.

Temos 2 tipos de Kanbans, sendo eles Kanbans de Produção ou Kanbans de Movimentação, agindo diretamente ao local de armazenagem de matéria prima, onde no uso deste acaba não sendo necessário a utilização de formulários, sistemas e até outra prática utilizada pela empresa.

O investimento para implementação é consideralvemente baixo, claro, isso depende do porte da empresa ao qual o mesmo será utilizado, mas no caso de uso de Quadros de cartões de sinalização ou identificação para os processos, o Kanban acaba se tornando a melhor ferramenta na busca pela sintonia perfeita da produção e estoque, pois além de sua didática o mesmo ajuda diretamente a não deixar o estoque sem produto, evitando atrasos ao clientes.

Quando no uso de caixas ou cartões para a produção, o objetivo é produzir somente o necessário para o estoque um determinado produto, retirando assim o excesso na produção e também no estoque.

Diretamente ligado ao sistema de produção o Kanbam ajuda no sucesso do Sistema Enxuto ou Just in Time, não tendo claramente a mesma técnica do Just in Time.

Pesquisando descobri um termo que define claramente o que é o  Kanban, gestão visual no controle de produção e estoques.

No caso de Kanban realizado através de Quadro de Cartões, o cartão poderá estar em no máximo dois locais, ou ele estará anexado ao Quadro ou estará na produção, ou seja, quando o mesmo estiver anexado ao produto, após seu uso ele retorna para o Quadro, logo após o mesmo fará parte de uma nova solicitação de fornecimento deste produto em questão.

Através da Gestão visual deste cartões, podemos nos orientar com as cores, como no quadro abaixo, onde podemos identificar a criticidade de produção definida pelo estoque.

 

Além do cartões tambem temos o sistema de caixas empilhadas na vertical, estando em locais demarcados com cores diferentes, funcionando da mesma maneira que o Quadro, ou seja, quando o nivel chegar ao máximo ou na cor vermelha quer dizer que haverá a falta de peças para o cliente.

Em caso de não houver mais caixas vazias no local, siguinifica que não a mais necessidade de produção de uma determinada peça para o cliente, pois as mesmas estão em produção ou em estoque.

Fica a dica do Kanban, talvez você já tenha visto ou utilizado, esta técnica apesar de simples é uma das grandes ferramentas utilizadas em indústrias de automoveis entre outras.

Algumas razões para utilizar um quadro Kanban

1. Visibilidade

Eu já falei aqui por que eu prefiro minhas atividades no caderno, pois ele estará sempre ao alcance da mão e dos olhos, pra me lembrar de todas as pendências que tenho pra resolver.

Com o controle das atividades expostos a todos, é como se tivéssemos um grande e coletivo caderno aberto. Todos os envolvidos podem ter uma visão de como as coisas estão, quais são os gargalos do processo, que precisam de atenção para melhorar a qualidade do desenvolvimento.

2. Facilidade de uso

Os cartões podem ser bem simples, de forma que novos integrantes na equipe, gestores ou clientes consigam visualizar e entender sem a necessidade de treinamento, “manual” ou softwares de gerenciamento de projeto.

O próprio quadro, quando bem utilizado e formatado, fornece uma representação gráfica do estado em que está o projeto. Simples assim.

3. Auto-organização e Colaboração

Consequência da visibilidade, a auto-organização deve acabar surgindo naturalmente. Se você tiver problemas do tipo: Gente sobrecarregada Vs. Gente desalocada, e o seu quadro permitir visualizar graficamente a alocação, a própria equipe vai ver essas diferenças e isso pode ajudar a criar uma cultura de colaboração.

Em equipes mais maduras, alguém desalocado pode se oferecer para ajudar alguém atarefado, e vice-versa. Em equipes menos maduras ou problemáticas, essa “exposição” pode facilitar o trabalho do líder em apontar os problemas e buscar soluções em conjunto com o time.

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

Scrum ou Kanban, qual escolher?

Imagine esse cenário: Um ambiente onde há muitos produtos legados, código que requer manutenção constante e que necessita de fluxo contínuo, não podendo aguardar até determinada data para realizar um deploy. Neste cenário é evidente que o Kanban melhor ser adapta, pois com ele é possível visualizar esse fluxo e proporcionar um ambiente onde é possível organizar o trabalho a ser feito.

Por ser menos prescritivo que o Scrum, que tem suas cerimônias, papéis e artefatos, o Kanban é mais lean e menos complexo, talvez por isso, sua adoção é mais suave que o Scrum.

Porém se você necessita de um certo grau de controle, ciclos mais definidos possivelmente com necessidade de sincronia com outros departamentos, talvez ai o Scrum se encaixe melhor. Acredito que não há uma regra para definir qual método ágil é melhor. Não é porque estou em um projeto novo que devo usar Scrum e nem porque estou em um projeto de manutenção de sistemas legados que devo usar Kanban.

Aqui na empresa quando escolhemos adotar Kanban para manutenção, era evidente que não seria possível manter um backlog com itens de vários produtos legados com complexidades distintas e necessidades de negócios divergentes. Por este motivo foi-nos sugerido pelo Giovanni Bassi durante uma consultoria usar Kanban neste ambiente.

O que percebemos ao adotar Kanban:

• Possibilidade de manter itens de vários produtos diferentes ordenados e juntos;
• Marcando com post-its de cores diferentes cada produto visualizamos qual era o que mais demandava esforço;
• Limitações nas marcações permitem visualizar onde estão os gargalos na execução de tarefas;
• Deploy mais rápidos, entregando valor mais cedo;

Há outras coisas que podem ser evidenciadas também, como tempo médio de realização de uma tarefa, onde o trabalho está enroscando. Isto nos permite tratar as causas destes gargalos e ser mais eficientes na entrega de valor, não apenas seus efeitos. Um exempo pode ser o QA acumulando ou travando o fluxo de trabalho. Talvez seja aconselhável treinar melhor os executores do QA ou melhorar as práticas ao invés de contratar mais duas pessoas para realizar estas tarefas mais rápido.

Legal também citar que o Kanban não serve apenas para manutenção de código legado. Perceba que ao trabalhar com Kanban é possível ao final do ciclo realizar deploy da aplicação, logo, o valor daquilo que foi realizado já está disponível para o cliente, seja ele uma correção ou até mesmo uma nova feature. Assim notamos que assim é muito ágil seja para ambientes de desenvolvimento ou manutenção de software.

Agora imagine este cenário: Um produto novo, com um time to market predefinido, equipe com pouco conhecimento do negócio e da arquitetura e ainda em estado de forming, necessidade de alguma previsibilidade de deploy. Penso que este ambiente é bom para aplicação do Scrum, por muitos fatores, mas o principal é por ele ser mais prescritivo e assim garantir um pouco mais de controle do processo, mas veja que negritei o processo justamente por isso, para que não seja confundido com controle das pessoas envolvidas.

Se na sua empresa há uma necessidade de estimar projetos para que o departamento comercial ou o marketing possam se organizar seja para uma determinada campanha, pré-lançamento ou mesmo plano de posicionamento de produto por exemplo, recomendo estruturar as releases de forma a atender essa necessidade. O Scrum fornece meios para realizar esse tipo de colaboração mais facilmente.

O Kanban assim como Scrum permite usar partes de outros métodos ágeis, por exemplo reuniões diárias, do Scrum ou Pair Programing do XP. Lembre-se que sempre será necessário que alguém diga dentre as tarefas existentes no quadro, qual é a mais prioritária e assim por diante. Chamar essa pessoa de Product Owner ou não dependerá de você, não há regra quanto a isso, aliás a única regra evidente no Kanban é que os limites das marcações devem ser respeitados.

Usar Scrum ou Kanban vai depender de muitos fatores, que variam de produto e suas necessidades até empresa e seu meio ambiente. Quando pensar em um processo ágil, leve em consideração quais pontos proporcionarão mais desempenho em termos de negócio e técnicos e seja feliz. Lembre-se que fazer software também pode ser divertido e, aliás, deve ser divertido.

Algumas pessoas na comunidade concordam que Scrum e Kanban são facilmente combináveis, a Professional Scrum Trainer KaTe Terlecka, explica em seu blog  a maneira como ela combina esses dois métodos gerando o Kate-Ban, que segundo ela tem funcionado bem.

Fonte: http://micajeho.wordpress.com/