Não, esse não é mais um texto sobre agilidade e seus princípios. Percebi que muito barulho foi feito em cima dessa nova forma de desenvolver software, muitas empresas nasceram ágeis, mas muito pouco foi falado sobre como realizar uma transição do modelo tradicional para o modelo ágil.
Não, não tenho uma formula ou uma receita infalível, além de não ter inventado nada. Sem a pretensão de ser um David Anderson ou um Jurgen Appelo, notei que, com experiencia prática e algumas leituras de livros que considero chave, consegui consolidar, para as realidades onde estive inserido, uma forma interessante de levar a cabo uma transição.
Como o que veremos aqui não é uma receita prática, mas uma forma de comportamento baseada nos princípios mais fundamentais do Lean, não vejo o tamanho da empresa como um restrição a esse modelo de comportamento.
As teorias que ajudaram na consolidação deste modelo se intercalam, sendo as principais: A Teoria dos Sistemas, Pensamento Complexo, o Lean e Teoria das Restrições. As secundárias, mas não menos importantes: Management 3.0 e o Kanban. As chamo de secundárias para este contexto, pois as considero também como consolidações de ideias e teorias anteriores.
Quando iniciamos uma transição, dia 1, hora 1, minuto 1, precisamos de uma conversa franca mostrando que estamos lidando com um sistema. A empresa, a corporação é um sistema: um conjunto de partes que interagem entre si para atingir um determinado objetivo. Mais que um sistema, ela é um sistema complexo, ou tende para ser. Quando eu digo que algumas "tendem" se dá por se situarem no caos e, o primeiro passo, é migrar, no Cynefin Model, para um sistema complexo. Não pretendo me estender demais nesse assunto, tendo em vista que muitas pessoas já falaram sobre isso. Uma pequena busca na WEB elucidará as suas dúvidas.
O próximo passo, depois dessa conversa, é iniciar a observação do sistema. Você não pode sugerir mudanças em um sistema sem antes observar o comportamento do mesmo. Nunca! Não importa se estamos falando de uma empresa de 5 pessoas ou de uma multinacional com 50.000 funcionarios. Não apareça com formulas práticas prontas, dizendo que a forma atual está toda errada, que os funcionarios não prestam. Isso vai gerar resistencia emocional e o sistema vai reagir e, inclusive quem comprava a ideia da transição no início, pode mudar de lado. Qualquer descuido nesse aspecto pode ser fatal para o objetivo final. O sistema é elástico e sempre está tentando voltar ao seu estado "natural", sua zona de conforto.
Dividi a transição em 3 etapas e estas podem ser mapeadas para os 3 estágios mencionados exaustivamente no livro Theory of Constraints (ToC) do Eliyahu M. Goldratt: Classification, Correlation e Effect-Cause-Effect. Ter feito essa divisão, não implica no fato de que elas não se sobrepõem ou que não precisamos revisitar cada etapa constantemente. Na verdade, é isso que acontece. O processo é cíclico.
Dependendo do tamanho da empresa, essa observação pode durar dias, semanas ou até meses. Não negligencie essa etapa, pois ela fornecerá grande parte dos insumos para a criação da estratégia para a mudança.
Podemos dividir essa etapa, que mapeei na ToC para a etapa de "classificação", em duas fases:
1) O Gemba Walk, onde deveremos andar por toda linha produtiva, observando e tomando notas/fotografando como, em alto nível, o sistema se comporta. Como os times interagem? Como o middle management interage com os times? Como os times são demandados? Como os times entregam? Podem ser necessárias algumas caminhadas pelo gemba para uma boa observação destes comportamentos;
2) Sentar em uma baia próximo a cada time por vez. Alguns dias de trabalho perto dos times podem ser suficientes para observarmos como o sistema se comporta em baixo nível. Lembrando que a organização (o sistema) muda quando é observado. Não é como observar a Lua ou as estrelas, mas a organização é um organismo vivo, que detecta que está sendo observado e reage, muitas vezes mudando o seu comportamento.
Com os dados colhidos da observação, identifique o que é(são) valor(es) para a organização. Verbalize e deixe claro e exposto para todos, do topo à base da pirâmide. Mapeie todos os fluxos identificados da organização. "Você não consegue melhorar o que você não vê." Nestes fluxos, tente identificar o que não agrega valor para o(s) resultado(s) final(is). Mapeie, destes desperdícios, o que é necessário e o que não é necessário. Comece eliminando o que não é necessário, depois reduza ao máximo o desperdício que é necessário e não pode ser eliminado. Esta etapa, mapeei na ToC para a correlação
Com o fluxo mapeado e os principais desperdícios eliminados, observe o sistema rodando. 1)Surgirá um gargalo importante. 2)Submeta os esforços no estudo deste gargalo, 3)resolva-o. 1)Este gargalo migrará para outro ponto do fluxo. Repita o passo 2 em diante. Isso se chama kaizen. Isso é a tão falada melhoria contínua. Isso é a busca pela perfeição, um dos princípios do Lean. Quanto mais rodar o kaizen, seu(s) processo(s) ficará(ão) melhor(es) e, consequentemente, você estará entregando muito mais valor para o seu cliente, com menos desperdícios. Finalmente, mapeei esta etapa para o Efeito-Causa-Efeito.
Não é o foco deste artigo, mas nada disso é possível sem o pilar principal do Lean/Agilidade que é o respeito às pessoas. Sem esse pilar principal em mente, podemos jogar todas as nossas tentativas no lixo, sempre! São as pessoas e as interações entre elas que compõem a parte principal do sistema. Você pode argumentar: "Mas na minha fábrica, já tenho quase todo o operacional automatizado." Sim, mas as maquinas precisam de pessoas para operar.
Este é o resumo e o encadeamento da sopa de princípios que vemos hoje por aí. Não existe fórmula prática. Como observar melhor o sistema? Fazendo perguntas. Mas que perguntas? Depende. Cada organização tem a sua identidade e quem transportar praticas/formulas magicas de um contexto para outro, na maioria das vezes, vai falhar. As perguntas certas derivam sempre da sua observação daquele sistema. Confronte o que você vê com os princípios do Lean, com os valores ágeis.
Por fim, mes passado, conversei com o Sidney Lima, no fórum RioAgile, se a denominação de "transição" seria a mais correta. Ele prefere chamar de evolução, pois entende que é um processo sem fim, uma vez que você adotou a agilidade.
Como agente de mudança, na minha visão, o processo de transição tem sim um fim. Esse momento é definido pelo completo conhecimento da organização de que ela é um sistema complexo e, portanto é preciso que ela saiba identificar e trabalhar com a variabilidade e imprevisibilidade, e de que o kaizen é necessário. Uma vez que essa realidade é entendida e existem pessoas capazes de rodar o kaizen eu, como change agent, não sou mais necessário e vou pousar minhas asas sobre outras paragens, noutro contexto, noutra realidade e iniciar outra transição.
Esse é o meu mindset ao iniciar uma transição.
Edit: Eu preciso concordar com o Yoshima, pois a questão de falar sobre sistemas complexos ou não para as pessoas da organização não ficou clara. A primeira reunião (mencionada no parágrafo onde falo sobre isso) normalmente acontece com change agents locais. São pessoas que te chamaram para um determinado objetivo. Essas pessoas se tornarão suas aliadas e apontarão outros aliados dentro da organização. Esses aliados são extremamente importantes na disseminação das ideias que guiam o processo de transição. Estas pessoas precisam ter atenção especial e ajudadas no entendimento do contexto que está sofrendo essa transição.
As demais pessoas, como o Yoshima bem disse, perceberão a importancia do pensamento sistêmico naturalmente, talvez até sem perceberem isso como a metáfora, que tenho usado bastante, do boiled frog.
Esse texto, também precisa ficar claro, diz respeito a uma transição auxiliada por agentes externos, normalmente em sistema de consultoria. Para mudanças internas, de dentro para fora, eu escrevi aqui e aqui.
Celso,
ResponderExcluirMe incomoda muito a utilização de observação visível do elemento humano para a identificação do status quo. Me faz lembrar o Hawthorne effect. Como você mesmo observou o sistema muda ao ser organizado. Se ele muda, isso comprometerá as premissas iniciais e poderá direcionar a transição a um caminho equivocado. O que fazer então? Gosto da ideia da observação indireta (hidden observation). É um modo mais efetivo de observarmos o ambiente, minimizando influência sobre os elementos observados.
Entendo o seu ponto de vista, mas discordo que a observação indireta seja mais efetiva. Sou um pouco cetico com relação a essa abordagem. Sabemos que em um ambiente coorporativo, poucas coisas ficam escondidas por muito tempo. Penso que menos ainda com observadores. Quando esse observardor for "descoberto" vai ser dificil estabelecer uma relação de confiança, pois voce enganou as pessoas, faltando com um principio basico, a transparencia, que nos remete a um principio ainda mais basico, o pilar: respeito as pessoas.
ExcluirE que moral você terá para falar de transparencia quando nem voce mesmo foi transparente?
Sim, o sistema muda quando observado. É por isso que eu disse que precisamos de tempo, para nos inserir no sistema, para que a corporação confie no nosso trabalho, desde a direção até o operacional. Se voce perde o operacional (quebra a confiança) qualquer tentativa de mudança será sabotada.
Prefiro conquistar a confiança das pessoas para que o sistema passe a acreditar que eu não estou ali. Se as pessoas entenderem que a ideia é melhorar para todo mundo, fica mais facil inserir novas ideias e propor novas maneiras de interação.
Abs!
Celso muito bom o texto. Também acho que a transição acaba sim e começa a evolução 'melhoria constante'. A observação me lembra um filme da Jornada nas Estrelas no qual o Data observa a comunidade de um planeta 'Sistema' com um traje invisível por que a federação não quer que a observação interfira no meio e quando as pessoas descobrem ocorre a quebra de confiança. O mais importante da transição ao meu ver e a transparência e principalmente que todos estejam comprados na ideia e queiram mudar. Excelente texto abs
ResponderExcluirObrigado Gustavão!
ExcluirMuito bom o texto Celso. Temos estudado também sobre adoção do Agile. Estamos traduzindo no InfoQ o livro An Agile Adoption and Transformation Survival Guide (que, em particular, gostei muito) http://www.infoq.com/minibooks/agile-adoption-transformation
ResponderExcluirSobre complexidade, tenho o seguinte post para recomendar: http://blog.kudoos.com.br/uncategorized/teoria-da-complexidade-na-copa-de-2014/
Grande abraço e parabéns!
Obrigado Rafael. Ótimas referencias!
ExcluirConcordo que o respeito ao elemento humano é essencial para qualquer iniciativa dentro ou fora da organização. Porém a presença de um elemento estranho em um contexto organizacional é afetado. É fato.
ResponderExcluirO que não sai da minha cabeça são as seguintes perguntas: quanto tempo realmente dispomos para nos inserir no sistema para que as pessoas deixem de lado a resistência e possam ser observadas agindo naturalmente? Como e quando medir se o ambiente está apto a ser observado? Isso pode demorar e nem sempre se tem tempo para isso. Essa é uma crítica minha ao gemba walk, embora eu o defenda como prática extremamente válida.
Quando mencionei a observação indireta e invisível, me refiro a observação declarada e sabida por todas. Observação com transparência de atitude e propósito. Porém, sem o elemento humano presente. É como quando você está no shopping fazendo compras. Você sabe que está sendo filmado (observado!) e nem por isso você deixa de agir naturalmente. Pelo contrário, ser observador em um shopping é visto como requisito para segurança. Se ser observado for entendido como válido e as pessoas se sentem confortáveis com isso, não vejo problemas. A questão é que todos entendam e concordem. Esse trabalho de pré-observação de conscientização é fundamental para o sucesso.
É claro que por ser observado todo comportamento muda.
Opa Marcelo,
ExcluirA situação do shopping é um bom exemplo. Alem das cameras existem os seguranças. Mas é um contexto bem diferente, já que, como voce bem mencionou, o fim é bem entendido por todos: a segurança.
Na situação organizacional, o gemba walk serve para voce ter uma visão de alto nivel do sistema. Nesse ponto, a mudança de comportamento não impacta tanto. O que sugeri como observação mais proxima aos times, que acredito que a mudança de comportamento tenha um impacto maior. Situações informais podem auxiliar neste ganho de confiança. ALmoçar junto, chopp depois do trabalho, piadas de fora do contexto de trabalho, conversas sobre futebol podem ajudar bastante e, depois de uma ruptura do comportamento normal, ocasionada pela sua presença, o comportamento pode aos poucos voltar para o que era.
Dessa forma, lentamente, voce passa a ficar invisivel para o sistema. Esse lentamente, pelo que tenho observado, não passa de um mês, podendo ser bem menos.
Por isso que também acredito que o observador/change agent precise possuir algumas caracteristicas psicologicas muito importantes, como um otimo relacionamento interpessoal. Não adianta colocar uma pessoa timida, sem uma boa capacidade de comunicação, turrona em suas opiniões, sem capacidade de ceder um passo para conquistar dois, sem uma boa visão estratégica para fazer esse trabalho. Esse perfil só vai gerar mais resistencia.
Abs meu amigo!
Senhores, para sistemas compostos por pessoas, uma vez inserido um novo elemento no sistema, ele nunca será mais o mesmo. Esse é o intuito de se inserir algo novo no sistema.
ResponderExcluirO foco deve ser em qual é o comportamento que queremos alcançar, um processo de educação e conscientização. Descobrir o comportamento anterior das pessoas requer gastar uma energia preciosa em algo que não agrega muito valor.
Poucas entrevistas com as pessoas certas já te dão a ideia necessária sobre o comportamento.
O Gemba Walk foi pensado para linha de produção composta por máquinas, onde a obsevação não afeta o comportamento. Não é válido para um sistema dinamico, onde as pessoas mudarão seu comportamento irrecuperavelmente assim que ouvirem que 'o processo vai mudar'. Não quero dizer que não devemos observar. Devemos sim. Mas o esforço é observar a entropia do sistema. Observar a mudança de comportamento. Não é necessário observar como as coisas eram feitas antes. O comportamento original não interessa. Não estamos estudando macacos na selva. Estamos lidando com pessoas. Não precisamos nos camuflar e gastar esforço em algo sem valor.
Na prática, como agentes de mudança, devemos ganhar a confiança das pessoas para orientar o novo comportamento.
Salve Felipero,
ExcluirConcordo com quase todas as suas colocações. Só discordo que o Gemba Walk só sirva para linha de produção. Ele nasceu em chão de fábrica, mas acho muito válido para outros contextos também. Tenho feito algumas vezes em contextos diferentes, com bons resultados, inclusive quando tentei inserir mudanças, as pessoas estavam mais receptivas. Eu não era "um cara que acabou de entrar no onibus e queria sentar na janela."
Outro ponto é que imprescindível não dizer, também dependendo do contexto, que o processo vai mudar. É a historia do boiled frog que mencionei no meu post anterior. Inserir pequenas mudanças sem alarde e, se possível, de forma gradual.
E acho sim observar o comportamento atual do sistema. Isso vale para as situações onde estive inserido, é claro. Como eu disse, devemos analisar criteriosamente cada contexto. Nas principais empresas grandes onde estive, isso foi sim muito importante e, com o ganho de confiança, ajudou na quebra de resistencias e me ajudou também a não criar mais resistencias.
No mais, concordo com o que voce falou.
Abs
Artigo interessante.
ResponderExcluirCelso, conforme prometido, segue meu comentários:
ResponderExcluir1. Em primeiro lugar, o artigo está muito bom! O Débito Técnico está ficando para trás no conteúdo sobre transição de processos. Parabéns!
2. Eu geralmente nos meus trabalhos de consultoria/menthoring em transições, inicialmente não jogo teoria de sistemas complexos e Cynefin para o colo da equipe/gestão, inicialmente porque vejo no mindset atual das pessoas uma resistência emocional muito forte à variabilidade inerente. Eu inicio o trabalho com Kanban diretamente, e deixo o sistema e a variabilidade se revelar. Com isso, principalmente a gestão, começa a concordar melhor com variabilidade pela experiência e naturalmente saem do famoso paradigma "Esforço x Capacidade". A partir daí a teoria de sistemas complexos passa a fazer mais sentido, pela experiência.
3. Na verdade o teu artigo é sobre Kanban. Não entendi direito porque você coloca Kanban como secundário. Para falar a verdade, não entendi como você usa TOC sem usar as três primeiras propriedades do Kanban como suporte. Na verdade eu vejo você usando Kanban como principal e TOC como seu modelo de melhoria (a quinta propriedade do Kanban). Kanban suporta vários modelos de melhoria: TPS, TOC, Agile, Conhecimento sobre Variabilidade...
Celso, conforme prometido, segue meu comentários:
ResponderExcluir1. Em primeiro lugar, o artigo está muito bom! O Débito Técnico está ficando para trás no conteúdo sobre transição de processos. Parabéns!
2. Eu geralmente nos meus trabalhos de consultoria/menthoring em transições, inicialmente não jogo teoria de sistemas complexos e Cynefin para o colo da equipe/gestão, inicialmente porque vejo no mindset atual das pessoas uma resistência emocional muito forte à variabilidade inerente. Eu inicio o trabalho com Kanban diretamente, e deixo o sistema e a variabilidade se revelar. Com isso, principalmente a gestão, começa a concordar melhor com variabilidade pela experiência e naturalmente saem do famoso paradigma "Esforço x Capacidade". A partir daí a teoria de sistemas complexos passa a fazer mais sentido, pela experiência.
3. Na verdade o teu artigo é sobre Kanban. Não entendi direito porque você coloca Kanban como secundário. Para falar a verdade, não entendi como você usa TOC sem usar as três primeiras propriedades do Kanban como suporte. Na verdade eu vejo você usando Kanban como principal e TOC como seu modelo de melhoria (a quinta propriedade do Kanban). Kanban suporta vários modelos de melhoria: TPS, TOC, Agile, Conhecimento sobre Variabilidade...
Rodrigo, deve ser ao contrário. Kanban é uma ferramenta. TOC, TPS são processos que podem usar o Kanban para gerenciar a fila ou podem usar outro sistema.
ResponderExcluirTOC e TPS vão muito além do que o Kanban pode ir e não devem ser categorizados somente como um processo de melhoria contínua.
O conceito todo do Kanban é um capítulo dentro do conceito de TPS/Lean/JIT.
Vale citar:
Kanban is a system to control the logistical chain from a production point of view, and is not aninventory control system. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. Kanban is one method through which JIT is achieved.[Ohno, Taiichi (June 1988). Toyota Production System - beyond large-scale production. Productivity Press. pp. 29. ISBN 0-915299-14-3.]
Opa Yoshi.
ResponderExcluirNo post, eu deixei claro que não menosprezei o Management 3.0 e o Kanban, apenas mencionei "segundo plano" (e talvez eu tenha sido infeliz na escolha das palavras) por considerar essas obras, na verdade, uma consolidação de ideias anteriores. Tenho a impressão que o David e o Jurgen não tenham inventado nada. Minto, acho que a maior invenção tenha sido a propria consolidação, criteriosa e importante.
Me surpreendi com o livro do Goldratt, que li apenas recentemente. Me surpreendi ao ver conceitos como lead time nele. Eliminação de gargalos e tecnicas de Evaporating Clouds eu já esperava. O Goldratt também cita variabilidade e esse conceito, na verdade, vem do estudo da teoria dos sistemas complexos. Mais uma vez, não foi um conceito cunhado pelo David.
Mais uma vez, não estou desmerecendo essa consolidação. Acho que coloca-las todas juntas e *interagindo* tenha sido uma mega sacada.
Apenas mais uma correção. Escrevi este texto sob forte impressão da ToC, livro em leitura neste momento, do Lean e da teoria dos sistemas complexos. Talvez voce tenha visto essencialmente Kanban nele, por este sistema derivar principalmente destas três correntes de pensamento.
No mais, obrigado pelos elogios! =)
Abs!
Celso, eu tentei escrever e guardar no gedit mas não rolou, então vou colocar aqui um pouco da minha visão.
ResponderExcluirEu falei exatamente sobre esse tema, no ultimo RioAgile Talks (http://rioagile.com.br/agiletalks_2013_03.html) pois eu percebia que além das ferramentas, o fator humano estava em pleno diagonal oposta ao movimento que acreditamos.
Na apresentação eu mostrei que a comunicação é o fator que mais causa falhas no processo, atualmente percebo que quando falo de Kanban, Scrum, XP, etc. Já tem uma informação deturbada, as pessoas acham que Kanban é um quadro com post-its, Scrum é o waterfall do waterfall e XP é um bando de programadores carentes que precisam sentar um do lado do outro. As pessoas não querem entender plenamente o que resolve o problema.
Lá no grupo do Rio Agile, nós chegamos a discutir sobre transição x evolução, eu até citei que entendo a existência de transição, mas vejo as empresas como absorvidas numa espiral perniciosa de gestão que o Jurgen chamou de 1.0, então a adoção de agilidade nessas empresas acaba sendo como um ex-fumante tentando parar de fumar, onde sempre existe uma força latente dizendo para voltar ao modelo anterior.
Gosto de chamar a transição ágil de evolução, por vários motivos um deles é uma frase que li um tempo atrás do "Robert F. Kennedy" (não é o presidente, mas um ex-senador) que dizia o seguinte: “Progress is a nice word, but change is its motivator. And change has its enemies.”, quando quero engajar pessoas para o processo eu chamo para uma transformação agil, mas quando falo com os resistentes, chamo de evolução, ou seja, comunicação.
No teu post eu gostei que você citou as táticas necessárias para o processo, para muitas pessoas isso é importante, mas com relação a estratégia? Senti falta disso.
Todas as vezes que converso com pessoas sobre agilidade eu não gosto de falar de metodologias, conceitos, nem ferramentas, pois em 99% dos casos ou as pessoas querem vender suas idéias/consultorias ou tem um entendimento errado do assunto, neste ponto eu me aproximo da psicologia como visão diametralmente oposta preparar as pessoas, afinal estamos falando de humanos e os sistemas criados por eles para gerar valor a outros humanos.
Neste ponto onde o alicerce mental está construido, eu começo o processo seguindo uma teoria que ouvi do Alisson Vale um tempo atrás que é o ciclo de avaliação de suposições, eu pego uma "verdade absoluta" de cada vez e desmistifico ela, usando o ferramental que você citou.
Apenas uma de cada vez, sem BuzzWord, sem teorias de doutorado e sem metodologias.
Esqueci de comentar sobre o ponto 2. Concordo com a sua abordagem, mas o que talvez eu não tenha deixado claro, é que não jogo a teoria dos sistemas no colo das pessoas. Acho a teoria de extrema importancia para formar o mindset do change agent e, assim, moldar o seu comportamento.
ResponderExcluirSidney, muito bom o seu comentário.
ResponderExcluirComo eu disse na RioAgile, eu não concordo em trocar o nome de transição para evolução, pelos motivos que já citei. Mas não acho errada a sua abordagem.
Com relação a comentar aos envolvidos sobre transição e evolução, se tende a ter resistencia e esse movimento não partiu da empresa (pressuposto, pois se assim fosse, a nomenclatura do que está acontecendo já estaria definida: transição ou evolução) para que citar que uma transformação está em curso? Boiled frogs. =)
Como um bom enxadrista, pela linda perspectiva desse maravilhoso jogo, descrevi mais estrategia que tática, já que as táticas estão mais ligadas a práticas e a estratégia à preparação do terreno para executar o golpe tático (agora, me desculpe, usando totalmente os termos do xadrez).
Como eu também mencionei, as cicatrizes irão ajudar a definir que tipo de caminho seguir, quais teorias usar e quando. E todo esse comportamental guiará as ferramentas e só então, entraremos nas questões táticas. Até o observar o sistema, que é um ato, considero uma estrategia. Um ato estrategico.
Abs meu amigo!
Sei que quando falamos Kanban, sofremos de um problema semântico. Creio que para a discussão aqui, Kanban se refere ao "Kanban Method" de David Anderson. Bastante relacionado com kanban do TPS, mas definitivamente não é a mesma coisa. Hoje, o Kanban Method é um modelo de melhoria contínua para Knowledge Work, que pode plugar TOC, TPS e etc... A última propriedade do Kanban Method é "use um modelo cientifico para avaliar melhorias, cientificamente". É nisso que plugamos TOC, TPS e etc...
ResponderExcluirÉ bem provável que o Jurgen não tenha inventado nada, e nem tenha juntando uma consolidação tão interessante na minha opinião. O Jurgen juntou um conjunto de idéias em um livro e adicionou uns desenhos estranhos. O David montou um processo de mudança e melhoria consistente, útil e completamente aplicável baseado em ideias anteriores e com ideias novas e complementares. A maior contribuição para o Kanban foi as dicas do Don Reinertsen para o David, incluindo a questão "batch sizing". O David foi inovador na minha opinião, e bem superior em relação a ciência, literatura e liderança da comunidade comparado ao Jurgen. Kanban é um método que está sendo aplicado em diversas empresas, há sucesso comprovado cientificamente da abordagem. O tempo irá dizer se o Management 3.0 é um mito.
ResponderExcluirTOC tem algumas limitações importantes para Knowledge Work e alta Variabilidade. No livro do Don Reinertsen há esses remarks. Infelizmente não estou com meu exemplar aqui para pegar o que grifei, mas o que vejo na prática, é que TOC deixa de ser útil no Kanban quando o fluxo é otimizado, e a maior restrição não é mais tão bem identificável.
Yoshi, não sei quais foram esses conselhos. Não li ainda o livro do Don Reinertsen. Vamos abrir uma thread na kanbandevbr para entendermos melhor essas questões? Entendo que esse assunto é importante, mas não é o foco principal do post. Estou abrindo uma thread lá.
ResponderExcluirNa verdade o Jurgen, explicitamente assume que não criou nada do zero. Pelo contrário, em seu último livro "How change the world" ele comenta que é adepto ao que ele chama de Mojito Method (uma espécie de AgileMMA "mais sofisticado", kkkk) para misturar e combinar diferentes ideias para resolver algum problema.
ResponderExcluirIMHO, acredito também que o David está nesse mesmo barco (talvez até mesmo sem admitir). Muita coisa que o Kanban tem é na verdade originado em ideias e ferramentas como o The Five Focusing Steps (da TOC, como o Felipero citou).
Mas observem que isso não desmerece em nada essas abordagens. Qualquer abordagem, na medida e no propósito certo, podem ajudar bastante uma empresa.
Manoel, a diferença básica que eu vejo entre o Jurgen e o David é que o David formalizou seu método baseado na observação da aplicação prática do mesmo. Isso eu considero ciência. O Management 3.0 é uma coletânea de excelentes ideias e explicações que tinham comprovação ciêntifica, minha critica é que o Jurgen empacotou isso como algo novo, dando até um label a isso. Achei isso pouco científico e tendenciosamente comercial.
ResponderExcluir1) "Absence of evidence is not evidence of absence" - Talvez nem tudo seja ciência quantificável, provável etc.
ResponderExcluir2) Acho que tudo se trata de rótulos e tem interesse comercial para esses gringos. Inclusive, para o próprio David. Afinal se não fosse assim, qual a necessidade de devanear sobre a semântica do K (maiúsculo) ou do k (minúsculo)?
3) Eu não entendi bem o pq desse embate MGT3.0 x Kanban. Qual o problema? MGT3.0 está roubando mercado de Kanban?
Na verdade, na verdade, IMHO, errados somos nós que ficamos babando o ovo nessas "invenções" dos gringos e consumindo (ou vendendo) esses rótulos empacotados pelos gringos.
:-)
Manoel, concordo com sua visão, esse é exatamente meu ponto. IMHO, o MGT3.0 me fez entender ideológicamente muitos aspectos que o Kanban já tinha me mostrado na prática. Um não desmereceu o outro. Até nós mesmos aqui na discussão pelo blog, falamos de rótulos (e somos rotulados o tempo inteiro)
ResponderExcluirNós daremos um salto gigantesco quando as pessoas pararem de usar a falácia (ad Verecundia) para tentar mostrar resultado.
Felipero,
ResponderExcluirConcordo contigo que o foco deve ser a observação da entropia do sistema. Porém, não acho entrevistas uma maneira eficiente de se observar e descobrir comportamentos. Fazendo isso você examina elementos individuais do sistema. O que eu faço quando observo é ficar atento a entropia e as propriedades emergentes do sistema. Essa sim tem muito a me dizer. Com o sistema em funcionamento, e não olhando parte dele individualmente, consigo observar e destacar partes que eu devo trabalhar para promover a alavancagem.
Um exemplo é quando você leva o carro na oficina. A primeira coisa que o mecânico vai dizer é: "Doutor, liga o carro para vermos o que está acontecendo". Você liga o carro e ele observa o funcionamento.
Outro questionamento: será que realmente o gemba walk foi pensado apenas em máquinas? Não são as pessoas que operam essas máquinas elementos importantes e influenciadores desse sistema complexo e, portanto, elementos necessários a observação?
Grande abraço,
Marcelo Neves
Antes do mecânico ligar seu carro, ele vai lhe entrevistar, perguntando: "O que há de errado?". A partir daí, a observação passiva acontece.
ResponderExcluirMas comparar um sistema complexo e composto por pessoas com o funcionamento de um motor é um tanto equivocado. O motor é uma máquina, por isso o 'gemba walking' funciona bem.
De qualquer forma, a observação pode e deve ser feita, mas não sem conversar com as pessoas. O contato face-a-face é um dos princípios do agile. Extramamente importante.
Sobre o gemba walking ser somente para máquinas: Eu disse que o gemba walking foi pensado para sistemas de produção compostos por máquinas. Não disse que não serve para ambientes 'livres de pessoas'. A diferença é que uma linha de produção possui previsibilidade de comportamento muito maior. Mas tenho absoluta convicção de que mesmo durante o gemba walking, eles conversavam e entrevistavam as pessoas envolvidas.
Manoel,
ResponderExcluirSua conclusão foi bem bacana:
"ficamos babando o ovo nessas "invenções" dos gringos e consumindo (ou vendendo) esses rótulos empacotados pelos gringos."
Mas, parando pra pensar, quer saber realmente porque nós fazemos isso? Por que nós também temos interesses comerciais. Nós vendemos os "kanbans", "agiles", "management 3.0" e tudo mais porque ganhamos "o leitinho das crianças" com isso. É verdade que encontramos soluções "gringas" efetivas, mas tem muito blá blá blá por aí.
Acho essas iniciativas válidas, porém, novamente voltamos ao assunto da bala de prata. Temos a tendência de achar que nossa solução é a bala de prata e que ela é a mais efetiva. Será mesmo? Percebo muito profissional no mercado caindo no confirmation bias. Por colherem evidências parciais as interpretam de maneira bem tendenciosa.
Grande abraço,
Marcelo Neves
Sim, mas o mecânico consegue resolver o problema apenas entrevistando o motorista? Não. A entrevista dá uma visão diminuta da visão que o mecânico realmente precisa ter do sistema.
ResponderExcluirNão comparei um sistema complexo com um sistema simples (motor de carro). O sistema utilizado na comparação é um pouco mais complexo: carro+motorista. O problema pode estar na forma como o motorista dirige e pode ser que isso esteja afetando o funcionamento do subsistema (motor).
O contato face-a-face é de suma importância sempre. E, para tal a observação é de grande valia.
Marcelo Neves
Marcelo,
ResponderExcluir"Percebo muito profissional no mercado caindo no confirmation bias. Por colherem evidências parciais as interpretam de maneira bem tendenciosa."
Tem algum exemplo?
Fala Celso, tudo bom?
ResponderExcluirNão sei se já bebeu desta fonte, mas tem um conteúdo muito bom sobre adoção e transformação para o Agile neste livro: http://www.infoq.com/minibooks/agile-adoption-transformation by Michael Sahota
Logo devemos lançar a versão em português no InfoQ.
Sobre a questão da nomenclatura que você comentou da "transição", o livro prefere usar "Transformação" para o Agile.
Vale a pena.
Abs,
Buzon
Legal Rafael. Não conhecia. Vou dar uma olhada com carinho.
ResponderExcluirTambém gosto do termo transformação.
Abs!