0

Fibonacci, User Story Points e Frutas

Um time de profissionais com alguma experiência em desenvolvimento de software tem plenas condições de planejar sprints em algumas horas ou dias, a única premissa é desapegar dos detalhes e discutir apenas a complexidade, o suficiente para comparar e inferir o seu tamanho.

É claro que precisamos ter antes um tanto de auto-conhecimento e clareza no fluxo de trabalho necessário, responsabilidades, DoR e DoD, o restante é básico, como profissionalismo, empatia, senso de pertença e evitar erros conhecidos.

Na chincha, o tipo de estimativa é irrelevante, quer seja T-Shirt Size, User Story Points, Dias Ideais ou Jujubas, … a técnica usada para estimar não muda em nada a quantidade de software que uma equipe é capaz de construir em uma sprint de 10 dias.

Independente de ter sido estimado com tamanho M ou ter 5 pontos, ser 4 dias ideais ou precisar de 7 jujubas, não mudará o fato mais importante que é saber se ele junto de algumas outras histórias cabem ou não em um sprint de 10 dias úteis.

User Story Points

User Story Points usa a série de Fibonacci, uma sequência de números inteiros, começando por 1 e 1, com os subsequentes correspondendo à soma dos dois anteriores [1, 1, 2, 3, 5, 8, 13, 21, …], que em estimativas de software é usual fixar um teto, com frequencia 13 ou 21.

O uso desta série para estimativas de histórias tem o objetivo de desapegar dos detalhes e nos preocuparmos apenas com aspectos que determinem a mudança de patamar. Desta forma, quanto maior a incerteza, maior a história e maior a distância entre os números da escala.

Salada de frutas

Vejamos uma boa analogia sobre a arte de estimar usando Fibonacci e o estabelecimento de referências e comparações. Para visualizar o que estou afirmando proponho um exercício com a imagem abaixo, uma mesa com vários tipos de frutas.

Se o nosso projeto é desenhar e colorir frutas, posso estimar a partir do tamanho em área, perímetro, volume, mas existe também a existência de detalhes, número de cores, a abstração disso tudo podemos chamar de complexidade.

Complexidade diz respeito ao todo, shape, diâmetro, cores, mas se antigamente estimávamos listando cada um e todos estes detalhes, em metologias ágeis uma breve discussão sobre suas peculiaridades é suficiente para perceber se é mais ou menos complexo que outros.

Após discutir sobre as frutas, é possível estabelecer o que seria a menor fruta em sua complexidade geral, para desenhar, pintar e entregar. Feito isso, vamos estimando comparativamente cada uma das outras.

Na prática, não há uma regra óbvia, cada time poderá estabelecer uma base e comparação para a sua estimativa, semelhante mas não necessariamente igual. Mesmo assim, se realizada de forma adequada e consciente, responsável, é provável que tudo dê certo.

Usando pontos sob o paradigma de complexidade relativa, a estimativa não é pelo tamanho da fruta, nem número de côres, mas pela complexidade comparativa, na percepção de esforço que teremos quando tivermos que desenha-las e colori-las.

Talvez o limão fosse o tamanho 1, será nossa referência de unidade, porque é liso, todo amarelo, o morango é menor, mas mais difícil de desenhar e colorir, por isso o 3, o abacaxi se equivale a abóbora grandona, bem maior, mas com shape menos complexo.

Isso não é muito diferente de software, as principais informações são as integrações, excepcionalidades inerentes a regras de negócio, sofisticação diferenciada, não queremos saber detalhes daquilo que é comuns, apenas do incomum.

Parafraseando Pareto e Juran, entre tantos detalhes triviais em cada tela de um sistema, haverá poucos detalhes vitais que as diferenciem em complexidade … uma percepção que se apura a cada experiência, porque afinal, estimativa se aprende estimando.

Já participei de projetos em que o time tinha alçada e decidiu não mais estimar, apenas discutir, entender e decidir quais caberiam em cada sprint. conforme prioridade e valor. Não é muito diferente dos outros tipos de estimativas, porque no final queremos apreender o que cabe ou não.

Mas por hora não entrarei muito nesta discussão, porque números, métricas, PxR e outras matemáticas ainda são necessárias para a maioria aprender, crescer e aperfeiçoar-se como profissionais … com números tudo fica um tanto mais explícito.

2

No TDC POA 2017 falei sobre o SSC e DJM

No dia 11/11/17 tive o prazer de participar novamente da trilha Agile do TDC Porto Alegre, ano passado da abertura e este ano com o encerramento. No ano passado fiz uma palestra provocativa sobre Agile Transformation, este ano sobre a necessidade de materializar nossa estratégia e tática, metodológica, tecnológica e humana.

TDC POA 2017 – SSC & DJM

Scrum Setup Canvas – Antes de entrar em um planejamento de releases e suas sprints é preciso materializar aquelas informações que o excelente Project Model Canvas do Prof Finocchio nos oferece como termo de abertura. É essencial estabelecermos parâmetros como pontos de atenção do mapa de tecnologia, formato, DoR e DoD, sprints e etc:

Doc Journey Map – Pesquise e analise as boas práticas sobre artefatos e documentação, mas faça isso para subsidiar uma análise crítica sobre a sua realidade, cultura, tecnologia e pessoas. Para cada documentação utilizada ou desejada é possível fazer um canvas A3 discutindo a origem, sustentação e destinação, seu custo x valor x benefício:

Sobre estes artefatos, tenho outros posts, vídeos e manual de uso:

02/04/17 – Spoiler da minha palestra para o Agile Trends
13/04/17 – Vídeo de  25 min no Agile Trends
07/06/17 – Versão pdf tamanho A3 para impressão
31/07/17 – Agile Trends Gov – Relato do evento
30/08/17 – Guia de uso para o SSC
06/09/17 – Aprenda com sua documentação

Tenho uma foto logo após minha palestra com parte da galera que assistiu com os coordenadores da trilha:

0

Tem o 5W2H, Managing Dojo, Learning 3.0, mas não esqueçam do A3 Report

É fundamental ter diferentes técnicas que orientem e organizem discussões para resolução de problemas, aproveitamento de oportunidades, desafios de inovação e superação. Eu chamo de Toolbox 360º, lancei um livro e um jogo de tabuleiro com este objetivo, provocar profissionais a refletirem sobre o mix de técnicas que domina e lança mão conforme necessidade.

Tenha e amplie sua toolbox permanentemente, lembre-se da alegoria da caverna de Platão e do ditado popular, porque para alguém que só conhece o martelo, todo problema parecerá um prego:

O uso de técnicas de gestão visual, mapas mentais, 5w2h, managing dojo, learning 3.0, entre outras, conta também com a dinâmica Lean conhecida como A3 Report. Trata-se do instanciamento dos princípios básicos do Lean – fracionar, descentralizar, antecipar mais valor, alta performance, eliminar desperdícios, aprender e melhorar continuamente, ver o todo, …

PDCA – Estabelecido um desafio, o tema da discussão, direcionamos a discussão a resultados, iniciando pelo entendimento, efeitos e causas, alternativas e plano de ação, como monitorar sua evolução e resultados, de forma iterativo-incremental, aprendendo e melhorando a cada ciclo.

Plan – Qual o desafio e sua relevância, valor; histórico, se algo já foi feito e se há contingenciamento; se possível incluindo algo explícito e visual como dados diagramáticos, números; com exercício de análise causal, 5W2H, CSD, Ishikawa ou Pareto;

Do – Frente as causas e efeitos analisados, qual o plano de ação, contando com aquelas informações necessárias para entendimento mínimo ne planejamento, como tempo, recursos e responsável, qual o resultado esperado a cada passo e final;

Chek – Quais as métricas e indicadores a serem utilizados para monitoramento e controle, com que frequência serão medidos, preferencialmente de forma auto-organizada pelo próprio time; favorecendo percepção de riscos e correções de rumo;

Act ou Learn – Aproximando participantes e stakeholders, com comunicação explícita e assertiva frente a objetivos de valor, com gestão do conhecimento (tácito-explícito) e conversão em aprendizado e correções para um novo ciclo de sucesso;

Ao procurar na internet por A3 report, explicitamente recebemos centenas de páginas sobre o uso desta técnica e assemelhadas, não só no contexto Lean fabril, mas até mesmo em referências ágeis como na Scrum Inc em um exercício sobre a não entrega de valor por sprint:

Uma página me chamou a atenção, com múltiplos exemplos e boa didática, impossível ler este post do Edson Miranda da Silva e não entender a técnica em sua plenitude – https://qualityway.wordpress.com/2017/05/04/a3-passo-a-passo-com-exemplos-reais-por-edson-miranda-da-silva/

 

2

Ao invés de perguntar sobre documentação, aprenda com ela

Que tal um Doc Journey Map, como um Customer Journey Map inspirado em 5w2h e SIPOC?

Conforme o porte da empresa, envolvem-se Governança, PMO, área de processos e representantes das equipes, trata-se de uma necessidade e responsabilidade da organização estabelecer alguns padrões e GQA necessário.

Lembra SIPOC, trabalha uma espécie de 5w2h de origem a destino de cada artefato, incluindo uma reflexão sobre custo (empenho), confiabilidade, redundância e validade, quer temporária ou permanente.

Como todos os canvas e artefatos ágeis, são experienciais, o objetivo não é seguir o roteiro, mas estabelecer uma discussão focada em desperdícios e valor, assertiva, da melhor forma possível, caso-a-caso.

Não se preocupe com o número de campos, o preenchimento é orgânico, preencher é fácil e rápido se as pessoas envolvidas estiverem presentes, promovendo um debate não sobre certo e errado, mas uma auto-avaliação, momento e necessidades.

DOC JOURNEY MAP II

Baixe o canvas acima em tamanho A3

Em startups e pequenas empresas nunca usei, nunca precisou, esta é uma técnica para grandes empresas, quando há áreas de processo, governança e PMO, pois a discussão sobre métodos ágeis sempre envolve também documentação.

Um exercício que pode gerar muita empatia e sinergia, todos buscando potencialmente passar a gerar artefatos com maior conhecimento do processo, o mínimo realmente necessário, considerando origem, destino e relevância.

Eu sempre começo pelo processo, é quase um aquecimento, de forma simplificada, garantindo sempre que seja divertido e descontraído, direto no quadro branco. O resumo é o passo-a-passo da documentação em questão, eu coloco inclusive os nomes da galera.

Artefato – Nome do artefato
GT – Grupo de trabalho
Data – Datas de discussão

Quem cria – papel ou equipe
Onde/como – ferramenta e repositório
Conteúdo/objetivo – informações
Custo/energia – Tempo e envolvimento
Redundância – Único ponto ou não

Quem usa – papel ou equipe
Quando/porque – momento e para que
Valor agregado – qual o seu valor
Validade – temporário ou permanente
Confiabilidade – é confiável, timing

Processo – fluxo simplificado de manipulação desta documentação
Meta/futuro – qual a projeção, melhoria, mudanças, novas práticas, substituição

Não tem um roteiro rígido, mas bom senso, eu uso uma folha para cada artefato utilizado ou proposto, preenchendo com postits pequenos, pelos olhos de quem faz e quem consome … estruturando um mapa de docs na parede, da esquerda para a direita representando tempo.

Uma folha para cada documento ou artefato, entre as pessoas interessadas, em um GT, não impondo certo ou errado, mas provocando uma reflexão e debate sobre cada oportunidade, construção e manutenção, custo x benefício.

No mercado tem uma variedade de artefatos e documentos, alguns bem tradicionais, alguns ágeis, muitos em transição – Visão, análise de negócio, casos de uso, ER, histórias do usuário, product backlog, BDD, protótipos, cenários de testes, …

Não é um autor que vai dizer o que é bom ou não para o momento de vocês, afinal estamos todos em transição, os livros, artigos e debates em fóruns e CoP’s ajudam a ter maior discernimento neste debate sobre o que manter, mudar, abandonar, um passo cada vez.

O campo de meta/futuro é exatamente identificar alternativas futuras para substituição ou mesmo eliminação, quem sabe boas práticas como histórias do usuário, seguindo DDD, partindo de BDD, código auto-documentado e clean code, uma boa orientação a serviços, automação de testes funcionais, etc.

Documentação é inversamente proporcional às suas boas práticas ágeis
Acredite, documentação é muito mais que as tais histórias do usuário

1

Scrum Setup Canvas no Agile Trends Gov 2017

Mais uma rodada de compartilhamento do Scrum Setup Canvas, desta vez na capital federal durante o Agile Gov 2017. Foi minha primeira apresentação usando como pano de fundo o Savana SCRUM, mas mantendo a pegada de diferenciação entre Go Horse e SCRUM.

Sala lotada, um bloco onde quem me precedeu foi o Allison Vale, iniciei apresentando uma das alegorias que mais curto, do Andy Glover onde o product backlog é um cesto enorme com todas as suas roupas sujas e o sprint backlog é a roupa que necessitamos para amanhã.

Valor é garantir ter a roupa adequada para seus compromissos do dia seguinte, de nada adianta lavar um cesto de cuecas ou as roupas mais caras ou as maiores ou menores, valor é ter aquela muda necessária e adequada para o dia seguinte, quer para frio, calor, longa ou curta.

SCRUM SETUP CANVAS

O mote do Scrum SetUp Canvas começa com as informações, combinações e restrições, como o tipo de máquina de lavar e secar, a capacidade de ambas, o tipo de sabão, para roupas brancas ou coloridas, se a expectativa é a entrega delas passadas e dobradas, …

Sempre trago minha maior convicção sobre o conceito de ToolBox 360º, que diz respeito a seu processo, ferramental, boas práticas, qualidade, excelência, destacando a certeza de que cada decisão acarretará ganhos ou perdas, que deverão ser transparentes e realistas.

Relembrei conceitos básicos sobre o Agilo romântico defendido por alguns e o Agila realista das grandes organizações, os conceitos básicos do SCRUM e suas variações, praticados em meio a complexidade e vicissitudes de empresas, governança de TI, PMO, GP e times.

  • Elevator Statement
  • Equipe e envolvidos
  • Aproveitamento e formato dos sprints
  • Arquitetura e Integrações
  • Indicadores e Métricas
  • Boas Práticas e Ferramentas
  • DoR (Definition of Ready)
  • DoD (Definition of Done)
  • Feriados e Férias
  • Sprint Zero
  • Reserva Técnica (%)

DESAFIO TOOLBOX 360°

Ao final dos 25 minutos, um convite ao jogo das 17:30 na mesma sala, quando 25 pessoas participaram até as 19:00 do Desafio ToolBox 360°, sempre com muitos insights, debates, argumentações e aprendizado. Tudo isso concorrendo com o happy-hour e cerveja no saguão ao lado.

SCRUM SETUP CANVAS
02/04/17 – Spoiler da minha palestra para o Agile Trends
13/04/17 – Apresentação em 25 min no Agile Trends
07/06/17 – Versão pdf tamanho A3 para impressão

TOOLBOX 360º
01/03/17 – Página Desafio ToolBox 360° / 5W2H  🙂
08/03/16 – ToolBox 360°, um guia de referência geral de boas práticas
03/04/17 – Desafio Toolbox – Agile Trends 2017 – ppt – relato

0

De Taylor a James Shore, de Deming a Eric Ries

A pedido, uma aluna me pediu uma revisão conceitual sobre princípios e trabalho a partir da revolução industrial, da escola clássica, mecanicista, da linha de produção, o Lean Toyota, os métodos lightwave, o manifesto ágil, até o Design Thinking e Lean Startup.

De artesãos a especialistas

No século XIX ainda tínhamos uma era artesanal, mestres, oficiais e aprendizes, uma época em que mestres regulavam profissões, atuação e preços. Período pressionado pela concentração urbana e inventividade humana, consolidando um período tão intenso de mudanças que ficou conhecido como uma revolução.

Uma necessidade histórica frente à máquina a vapor, crescimento das demandas e mão de obra abundante, encontrando soluções baseadas em mecanicismo e padronização, inclusive humana, com departamentos e especialistas, estabelecendo que cada um deveria fazer uma parte.

A ideia de termos especialistas contrapunha o modelo artesão, ao invés de pessoas que conheciam grande parte ou todo o ciclo de produção, exigindo anos de treinamento, a proposta eram especialistas que sabiam exclusivamente aquilo para que eram treinados.

Esta proposição os tornavam facilmente cambiáveis, rapidamente treinados, aproveitando imediatamente a mão de obra desqualificada disponível e trocada conforme necessidade. Cada especialista sabia realizar sua função repetidamente, sendo medido pelo número de vezes que fazia.

Grandes nomes como Taylor, Fayol, Ford e o casal Gilbreth, tempos e movimentos, pessoas como partes de uma máquina, parar para pensar era desperdício, era preciso apenas aprender como executar repetitivamente, um pensa para muitos executarem, chamamos de comando-controle.

De especialistas a colaboradores

O século XX foi marcado pelo florescimento exponencial da inventividade humana, mas também da concentração urbana, foco em bens e consumo, diferenças sociais e leis trabalhistas, duas guerras mundiais e os primeiros 50 anos da “computação”.

As máquinas evoluíram, semi-automatizadas, automatizadas, informatizadas, sempre reforçando os modelos fabris do século XIX, baseados em especialização de papéis, até o momento histórico do esforço pós-II guerra mundial que encontrava um Japão falido, em completo colapso.

No japão e alemanha, emissários Europeus e Americanos em áreas como de governo, bancário e produção, se esforçavam no esforço de gerar estabilidade e riqueza para evitar que países em ruínas viessem a gerar uma insatisfação social que geraria a terceira guerra mundial.

Nomes estrangeiros como Deming e Juran trabalharam em prol do crescimento japonês, somado a uma cultura disciplinada e um legado dos anos 20 de Sakichi e Kiichiro Toyoda baseado em “autonomação” e Kaizen, uma automação com toque humano para melhoria contínua.

O programa de qualidade japonês floresceu, com a Toyota enxugando todo o desperdício de seus processos, adotando equipes auto-organizadas  e colaboradores que conseguiam ver e opinar além da “sua” tarefa … era a revolução fabril Lean liderada pela Toyota nos anos 70.

De colaboradores a profissionais do conhecimento

Toda aquela base de novos conceitos protagonizados pelo clã Toyota e seus colaboradores transformaram-se em inspiração na década de 80 para o início de métodos conhecidos como Lightwave, que passaram a ser conhecidos como métodos Ágeis a partir do manifesto de 2001.

Em Fevereiro de 2001 dezessete profissionais que vinham experimentando métodos de desenvolvimento de software como Scrum, Crystal, DSDM, XP, inspirados nos princípios de produção enxuta da Toyota chamavam a atenção do mundo pelos ótimos resultados obtidos.

. 1992 – Crystal Clear Method – Cockburn
. 1993 – Scrum – Shuterland, Schwaber e Beedle
. 1994 – Analysis Patterns, UML Distilled, XP – Fowler
. 1996 – XP – Kent Beck, Cunningham e Jeffries
. 1997 – DSDM (Dynamic Syst. Dev) – Bennekum e outros
. 1997 – FDD – Feature-Driven Dev. – Jeff De Luca e Peter Coad
. 1997 – ASD – Adaptive SW Dev.. – Jim Highsmith e Alistair Cockburn
. 1999 – The Pragmatic Programmer – Andrew Hunt e Dave Thomas
. 2003 – Lean Software Development – Mary e Tom Poppendieck

Nos 16 anos que sucederam o Manifesto Ágil vimos o crescimento dos métodos ágeis, especialmente Scrum, XP e Kanban, no Brasil consolidou-se a partir de 2008, conquistando a partir de 2012 as grandes empresas com propostas racionais como a TI Bi-Modal do Gartner.

Ao mesmo tempo, também vimos a gestão por competências e a gestão do conhecimento somando, o surgimento do Lean Startup, do Design Thinking, o conceito e papeis como UX, espaços como Open Spaces (Concept Of Ba Offices), Business Model Generation, …

Nos últimos anos vimos um sincretismo cada vez maior entre diferentes metodologias, frameworks e conceitos, quer tradicionais ou mais recentes, na direção de proporcionar maior empatia, agilidade, equidade, eliminação de desperdícios, antecipando resultados e taxas de sucesso.

Hoje, data estelar de Agosto de 2017, o mercado busca algo que chamamos de Agile Transformation, empresas ágeis respondendo rapidamente ao mercado, tecnologia, globalização, não mais apenas equipes e projetos ágeis, mas empresas Lean, tanto quanto criativas e ágeis.

A seguir algumas das metodologias ágeis com as quais me envolvi desde 2008, lembrando que nenhuma per si é suficiente, normalmente há um método de gerenciamento de projeto, o uso de quadros seguindo os princípios Kanban e boas práticas típicas do XP:

SCRUM – Framework para gerenciamento de projetos ágeis apontado por pesquisas como o método ágil mais praticado no mundo;

Scrum Of Scrum – Propõe mecanismos simples para planejamento e execução cooperativa quando o projeto necessita várias equipes;

KANBAN – Método baseado em gestão visual de fluxo que se utiliza de cartões e regras inspiradas no conceito de sistemas puxados;

LEAN Office – Propõe a filosofia Lean às equipes de escritório para melhorar sua produtividade e qualidade, luxo, + valor e – desperdício;

XP – Extreme Programming originou-se nos grupos de OOP, valoriza iteratividade, refatoração, pair, feedback, testes automatizados;

SAFe e Nexus – Frameworks ágeis em escala, para muitas equipes no projeto, quando Scrum of Scrum já não atende a necessidade;

DSDM – Metodologia de Desenvolvimento de Sistemas Dinâmicos, originado em Desenvolvimento Rápido de Aplicação (RAD).

Business Model Generation – Modelar rapidamente com o máximo de empatia é premissa para projetos ou sustentação ágil, conhecendo o cliente e o desafio;

Design Thinking – Um conjunto de técnicas e artefatos 100% focados no entendimento do cliente, quer problema, oportunidade ou objetivos;

Lean Startup – Quer inovação e empreendedorismo em startups, quer capacidade absortiva em empresas, não dá para ficar parado nem desperdiçar;

Management 3.0 – Um novo modelo mental para empresas e suas equipes exige a reinvenção de nossas lideranças do século XXI;

Temos muito o que andar, mas a história nos inspira e dá a entender que estamos no caminho certo!

 

0

Quem foi rei, não quer perder a majestade!

Para mudar ou melhorar, é preciso questionar velhas receitas, experimentar novas, aprender com elas e prosseguir neste ciclo virtuoso! Se você já sabe tudo e não abre mão disso … fica mais difícil 🙂

Ao migrarmos para métodos ágeis como SCRUM ou Kanban alguns conceitos são basilares, como o fundamento de auto-organização e premissa de confiança, delegação ou negociação. Todos os envolvidos aprenderão a trabalhar sob um paradigma racional de trabalho colaborativo, geração de valor, eliminação de desperdícios, baseados em comunicação e argumentação.

Para muitos profissionais o desafio maior é abrir mão do individualismo, competição e falsa sensação de poder ou controle. Isso vale especialmente a quem não estava acostumado a ter que embasar e justificar sua decisão, seu trabalho ou conduta. Muitas vezes são exatamente aqueles profissionais mais sênior, viciados em ribalta e poder.

A estes caberá entenderem que serão tão ou mais valorizados quanto melhor o resultado de todos, do time, do projeto, que inexiste a “sua” parte, mas sim o resultado do conjunto. Em determinados momentos sua colaboração transversal será muito mais percebida que “suas” tarefas. Basicamente, se cada um fizer a “sua” parte, provavelmente não vai dar certo.

Um gestor ou líder que não sabe delegar, que não consegue confiar em seu time, que trata problemas de seus times como se ele mesmo não tivesse nada a ver com isso. Mandos e desmandos, relações com pouca transparência, falta de feedback seguido de muito teatro e reações pouquíssimo “ágeis” e colaborativas, focadas ainda em buscar culpados ao invés de soluções.

Profissionais que buscam a ribalta, estão acostumados nos processos antigos em estarem na ribalta sozinhos, muitas vezes competitivos dentro do próprio time, disputando com o cliente ter a razão e eximindo-se sempre que possível da co-responsabilidade. Brinco que em muitas oportunidades meu maior desafio é mudar o mindset do mais senior e não dos mais juniores.

Aquele cliente que acha que pressionando, reclamando, exigindo ou isentando-se, gera um clima em que todos farão mais que fariam caso o ambiente fosse amigável e construtivo. Acreditando que é o cliente, sempre tem razão, “está pagando”. No seu entendimento, não confia, não envolve suas equipes, decide tudo sozinho, o fornecedor é um problema e não uma solução

Empresas acostumadas ao paradigma de negócios ganha-perde, sempre buscando uma brecha, reinando, usando sua experiência para aplicar a Lei do Gerson, a Lei Ricúpero, tirando vantagem de parceiros, colaboradores, fornecedores ou clientes. Muito teatro e artes cênicas nos seus relacionamentos e interações.

Conclusão

Todo e qualquer método ágil inspira-se em colaboração cliente-fornecedor, equipes auto-organizadas, geração de valor em equidade, eliminação de todos os tipos de desperdícios em um trabalho e relacionamento profícuo, harmônico, cadenciado, onde todos os envolvidos engajam-se em agir da melhor forma em prol de sinergia.

Daí surgem nos meios organizacionais termos como ecossistema, auto-eficácia, equipes de alta performance, líder-servidor, colaboração pró-ativa, melhoria contínua e tantos outros termos e temas que precisam ser entendidos, internalizados e praticados diariamente.