Ciclo Duplo de Aprendizagem

A justificativa para se trabalhar com equipes menores são muitas. Uma das mais aceitas é que a complexidade na comunicação é drasticamente diminuída quando temos menos pessoas em um time.

Times muito grandes também tem dificuldades de se chegar ao consenso. Quanto mais gente, mais opiniões e quanto mais democrático os times, mais lenta é a tomada de decisão.

Quando eu falo na tomada de decisão, faço referência a dois conceitos básicos pelos quais as equipes de alto desempenho devem se comunicar: advogar e inquirir.

Este conceito foi desenvolvido pelo Chris Argyris e está no livro: Organizational Learning: A Theory of Action Perspective. Argyris argumenta que o ato de advogar é feito pela maioria das pessoas. Acontece quando alguém apresenta suas verdades e seus próprios pontos de vista. O ato de inquirir é mais raro e certamente é mais importante que advogar.

Inquirir significa buscar a clareza na posição dos outros. Acontece quando fazemos perguntas para trazer a tona os modelos mentais que estão por trás de certas posições.

Quando temos uma equipe muito grande a tendência é querer defender nossos pontos de vista, pois não sabemos quando teremos a chance de falar novamente. Em uma equipe menor, as pessoas tendem a fazer perguntas para buscar a clareza dos fatos. Pense em uma empresa grande e pesada com uma dezena de diretores e compare com uma conversa em uma startup!

Inquirir pontos de vista é uma excelente maneira de se evitar opiniões polarizadas e muitas vezes um conflito que não vai levar a lugar nenhum. Para Argyris o aprendizado vem justamente dos questionamentos que fazemos, o que ele chama de aprendizado de cliclo duplo.

#chrisargyris #doublelooplearning #learningorganization

Mudança

Peter Senge tem uma frase que eu sempre falo em sala de aula: As pessoas não resistem a mudança, elas resistem a serem mudadas. O fato é que a mudança é um processo sistêmico. Mudar processos e rotinas em um determinado setor da organização, não implica necessariamente em mudanças em outros setores, mas as chances que isso ocorra são bem perto a 100%.
 
O Status Quo é resistente e se ninguém fizer nada ele vai ficando cada vez mais forte. Ele nos da certeza, e esse é um ponto chave. Mudar gera muitas incertezas. É melhor errar fazendo a coisa certa do que acertar nas coisas erradas.
 
Para que a mudança seja bem sucedida, precisamos antes de mais nada traçar os objetivos. Saber o porquê de querermos que a transformação aconteça. Não é simplesmente mudar por mudar.
 
Um caminho possível e eficaz é encontrar pessoas motivadas para aprender e torná-las agentes de mudança. Uma vez que outros funcionários vejam que seus colegas estão motivados para apoiar a mudança, isso ajudará a reduzir a resistência.

Limitar os 3 níveis

Um ponto muito importante na arquitetura do sistema kanban!

Se você fatia seus projetos, em épicos, histórias de usuários e por fim tarefas, você terá um efeito limitado se limitar as tarefas e não limitar as histórias, limitar as histórias e não limitar os épicos, e limitar os épicos e não limitar os projetos.

Quanto mais alto o nível na hierarquia de trabalho for limitado maior será o ganho sistêmico, maior a alavancagem. Precisamos nos concentrar em políticas que otimizam o todo em vez de cada uma das partes. O pensamento sistêmico é uma disciplina de mudança coletiva.

Os itens grandes, neste exemplo, os projetos devem ser reduzidos para se obter o feedback mais rápido na ponta!

Imagina que você tem um número ilimitado de projetos iniciados e um número limitado de histórias de usuários. Os projetos não serão concluídos rapidamente, mesmo com as histórias limitadas.

Você precisa trabalhar o limite WIP em todos os níveis.

Para usar o kanban precisa passar pelo scrum?

Bom, muitos alunos me perguntam se para usar o kanban é necessário passar pelo scrum. Minha resposta é um sonoro não! Um dos problemas mais críticos que eu vejo em relação ao scrum é a dificuldade de lidar com o trabalho que não foi planejado durante a planning.

Quando se está trabalhando na primeira versão de um produto, você terá pouco ou nenhum trabalho não planejado para tratar. À medida que este desenvolvimento avança, certamente vão começar a aparecer trabalhos não previstos em sua planning. E aí, o que fazer?

Imagina que seu time nas primeiras plannings se compromete com 10, 12 histórias, e até então não temos o trabalho que não foi planejado interferindo. Com o avanço, bugs, feedbacks, atividades urgentes aparecem e aí você tem trabalho não planejado, interferindo no planejado. Agora, ao invés das 12 histórias, seu time se compromete com 7 e deixa “espaço” para o que aparecer.

Quanto mais trabalho não planejado entrar no sistema, mais tempo levará para o trabalho planejado ser concluído. Nesse caso, a primeira coisa que você tem a fazer é dar transparência a este trabalho. Coloque no mesmo quadro o que foi planejado e também o que não foi!