O roteiro DMAIC na melhoria dos processos – Six Sigma – parte II

Continuando o post anterior sobre o roteiro DMAIC, onde tivemos a introdução de conceitos e as fases D (Define) e M (Measure), nesse aqui iremos abordar as fases seguintes que são A (Analyze), I (Improve) e C (Control).

4. Analyze

O objetivo da fase Analyze é desenvolver as mudanças e encontrar a causa raiz do problema. A análise é essencial para trazer conhecimento ao processo atual, por isso veremos técnicas que ajudam a criticar o processo atual e sugerir mudanças que resultarão em melhorias.

Evite procurar a perfeição (síndrome da utopia e da paralisia) e fazer mais do mesmo, pois são problemas conhecidos no desenvolvimento da mudança.

Comparação entre os dois tipos de mudança:

1ª ordem2ª ordem
SistemaNão é alteradoÉ alterado
Percepção do clienteSolução do problemaMelhoria
PrazoImediato, curtoMédio, longo

4.1. Diagrama de Causa e Efeito

Também conhecido como Diagrama Espinha de Peixe ou Ishikawa, o Diagrama de Causa e Efeito é uma técnica para descobrir, organizar e agrupar conhecimento a respeito das causas que contribuem para um determinado efeito. É muito usada no início do desenvolvimento de mudanças para alinhar o conhecimento da equipe a respeito do problema.

Há seis causas “comuns” (método, mão-de-obra, máquina, meio-ambiente, material e medição) proposta pela técnica. É claro que, ao aplicar na área de TI, pode haver outras causas necessárias a testar, coletando dados e realizando experimentos.

4.2. Lean

Enquanto o Six-Sigma está mais relacionado ao controle da qualidade, o Lean é uma filosofia de gestão inspirada nas práticas do Sistema Toyota, focada no controle da quantidade de produção para reduzir os desperdícios. Os sete desperdícios considerados são: superprodução, transporte, movimentação, excesso de processamento, estoque, defeito e tempo de espera.

A imagem abaixo resume os 4 P’s e os 14 princípios do TPS, além do JIT (Just in time) e Jidoka, pilares do Lean.

A análise de valor é percepção do cliente para determinar o que é desperdício:

  • Atividade que agrega valor (AV): atividade necessária p/ produzir um produto ou serviço e adiciona valor sob o ponto de vista do cliente
  • Atividade que não agrega valor (NAV): atividade realizada para produzir um produto ou um serviço, mas que não adiciona valor sob o ponto de vista do cliente.

4.2.1. A Casa do Lean

Assim como uma casa, que precisa ser construída apropriadamente para ter êxito, o Lean considera o uso adequado de estratégias para obtenção do sucesso.

A fundação inicia-se pela confiança, objetivos e o buy-in dos colaboradores e da liderança, sendo o suporte aos demais processos. As paredes, em geral, servem para otimizar os processos (eliminar desperdícios, melhorar a eficiência e a qualidade). O telhado é o foco no cliente e protege o resto da estrutura de encontrar problemas.

4.3. Sistema empurrado e puxado

No sistema empurrado, cada atividade entrega o resultado quando está pronto. Isso pode resultar em acúmulo de lotes com muitos intervalos.

Já o sistema puxado, cada atividade entrega o resultado apenas quando a próxima atividade precisa de sua entrada.

  • Disparado pelo cliente (externo e interno)
  • Minimiza o inventário e retrabalho devido a defeitos
  • Há poucos desperdícios
  • São ágeis em responder à demanda do cliente

4.4. VSM (Value Stream Mapping)

O Mapeamento do Fluxo de Valor é utilizado para apoiar os times a construir o fluxo de valor, que concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente. Facilita a identificação de desperdícios, gargalos, custos, etc.

É aplicável quando se busca oportunidade de melhoria em uma linha de produção, segundo a teoria dos desperdícios.

4.5. Poka Yoke

É uma ferramenta que ajuda a prevenir falhas humanas nos processos. “Tornar fácil fazer certo e difícil (quase impossível) fazer errado”. Muitas vezes é mais fácil alterar sistema do que o comportamento humano para prevenir os erros.

Os métodos Poka Yoke são: lembretes, diferenciação, restrições e exibições.

Tipos de Poka-Yoke

A prova de erro (preventivo)A prova de falha (detectivo)
Elimina a possibilidade de ocorrência da falha ou defeito específico, através do projeto   Detecta a falha ou defeito, caso ocorra, e previne que a não-conformidade continue no processo

5. Improve

A mudança como uma predição. Nessa fase, as soluções são criadas para resolver os problemas identificados na fase de Analyze (causa raiz de cada um). As principais ferramentas e praticas utilizadas são:

  • Plano de Ação – 5W2H
  • Kaizen
  • Matriz de Priorização
  • 5S

E verificar o grau de convicção da mudança: desenvolvendo, testando (em ciclos) e implementando as mudanças. Utiliza-se base de comparação histórica / simultânea e verificação de pontos vulneráveis.

Adicionar estágios para exibir mudanças no processo - Minitab

6. Control

O objetivo de monitorar os resultados obtidos é de perpetuar os conhecimentos e as melhorias conquistadas. Um plano de controle recomendado para manter as melhorias:

  • Realizar o plano de implementação com a abordagem 5W2H
  • Documentar o novo sistema
  • Treinar os envolvidos
  • Monitorar o sistema: manter o resultado e fonte de aprendizado. Existem técnicas simples, como a elaboração check-lists, e técnicas mais complexas, como o uso de controle estatístico de processos.
  • Estender o conhecimento e as melhorias conquistadas
  • Reconhecimento das pessoas envolvidas

Leitura recomendada

Lean Mastery Collection: 8 Manuscripts - Lean Six Sigma, Lean Startup, Lean Enterprise, Lean Analytics, Agile Project Management, Kanban, Scrum, Kaizen ... DSDM XP & Crystal Book 9) (English Edition) por [Jeffrey Ries]

O roteiro DMAIC na melhoria dos processos – Six Sigma – parte I

O roteiro DMAIC (Define-Measure-Analyze-Improve-Control) é um componente do Six-Sigma utilizado para melhorar os processos existentes da empresa, e assim apoiar as mudanças para que resultem em melhorias, tais como redução de problemas, defeitos e desperdícios.

Possui cinco etapas e um objetivo de conclusão para cada uma, afim de garantir a progressão do projeto de melhoria.

  • Define: definição do problema e prioridades
  • Measure: medição do estado atual
  • Analyze: encontrar a causa raiz do problema
  • Improve: mudança como uma predição
  • Control: perpetuar os conhecimentos e as melhorias conquistadas

1. Mudança e melhoria

Como é essa relação? Sabemos que a mudança nem sempre resulta em melhoria, mas a melhoria requer mudança. Por isso, os modelos de melhoria são utilizados para apoiar a realização da mudança, com análise de dados e entendimento de variabilidade.

Que mudanças podemos fazer que resultarão em melhoria? A mudança de fato somente é uma melhoria se ela é duradoura. A análise crítica sobre o processo atual, o uso de novas tecnologias e o pensamento criativo são alguns conceitos de mudança utilizados pelos modelos de melhoria.

Veja uma comparação (resumida) das fases do PDCA, DMAIC e MASP:

2. DMAIC – Define

É a fase de definição do escopo do projeto de melhoria. A elaboração do contrato do projeto declara o patrocinador / stakeholders envolvidos, contexto, objetivos, indicadores, prazos, restrições e o business case. As principais ferramentas que ajudam nas tarefas dessa fase:

  • SIPOC (suppliers – inputs – process – outputs – customers): uma representação dos aspectos relevantes do processo, onde será o foco de melhoria.
  • Diagrama direcionador: é uma ferramenta para organizar as ideias a respeito das possíveis mudanças.
  • Matriz RACI: definição de papeis e responsabilidades para as tasks do projeto

3. DMAIC – Measure

É imprescindível mensurar a mudança para determinar se houve uma melhoria significativa ou não. A confiabilidade da informação é essencial para apoiar as decisões e refletir a realidade. O time decide o que deve ser medido e como medi-lo. Alguns indicadores de aferição:

  • Medidas de resultado: as mudanças estão levando à melhoria?
  • Medidas de processo: estamos fazendo as coisas certas para atingir o nosso objetivo?
  • Medidas de equilíbrio: contra indicadores. A melhoria não pode gerar impacto em outros processos.

3.1. Ferramentas

3.1.1. Fluxograma

Identificar desconexões e oportunidades de melhoria no fluxo de trabalho. Inicia-se por um nível macro e verifica se já há oportunidades de melhoria, adicionando detalhes conforme necessário. Existe o fluxograma vertical e o multifuncional.

3.1.2. Gráfico de tendência e controle

O gráfico de tendência é uma ferramenta analítica simples para estudar a variação nos processos (eixo horizontal e vertical). O gráfico de controle é usado para analisar se um processo está ou não sob controle, e identificação das causas (comuns ou especiais) das variações.

Gráfico de tendência
Gráfico de controle

Exemplos de variações (observadas em gráficos de controle):

  • Um ponto muito afastado dos demais
  • Uma sequência de dez ou mais pontos acima da média

3.1.3. Gráfico de tendência

O Dot Plot é um gráfico que consiste em pontos de dados plotados em uma escala simples (conjuntos de dados de tamanho pequeno a moderado). O seu uso é para destacar clusters e gaps, além de discrepantes. A distância entre a média e os pontos máximo e mínimo são bons orientadores.

Dot plot
Histograma
Adding fitted distribution lines - Minitab

O histograma é usado para grande quantidade de dados (mais de 50 pontos) e checar a simetria dos dados. A diferença entre o ponto máximo e mínimo demonstra que este gráfico é pouco simétrico.

3.1.4. Gráfico de barras e setores

São ferramentas para estudar a distribuição de dados classificatórios (qualitativos).

Selecione as opções de exibição para Gráfico de barra - Minitab

3.1.5. Gráfico de pareto

Conhecida como regra 80/20, onde 80% das consequências provêm de 20% das causas. Também chamado de Vitais vs Triviais, onde a maioria dos problemas acontece muito pouco, e um pequeno grupo das categorias representa a maioria da frequência dos problemas.

Pareto se aplica
Exemplo de Gráfico de Pareto - Minitab
Pareto não se aplica
Fundamentos do gráfico de Pareto - Minitab

3.1.6. Estratificação

É a separação em grupos e classificação dos dados, de acordo com fatores ou variáveis selecionadas. O objetivo é encontrar padrões que auxiliem na compreensão dos mecanismos causais de um processo.

Quando utilizar? Sempre que houver interesse em estudar se o “comportamento” é o mesmo em todos os grupos definidos pelos fatores ou variáveis.

3.1.7. Gráfico de controle (Shewart)

Identificar a causa (comum e especial) das variações no processo. A partir de cálculos estatísticos estabelece três linhas: LC (limite central), LSC (limite superior de controle) e LIC (limite inferior de controle). Os tipos de variáveis são dados contínuos ou de classificação/contagem.

  • Gráfico U: usado para contar o número de defeitos. O indicador é uma taxa e pode ter valores maior que 1.
  • Gráfico P: usado para contar o número de unidades defeituosas. O indicador é uma proporção e precisa ser menor que 1.
  • Gráfico X: em dados contínuos com tamanho do subgrupo 1 e a distribuição dos dados é normal.
  • Gráfico X-barra/R ou X-barra/S: em dados contínuos coletados em subgrupos (amostras) de tamanho constante ou variável (/S).

3.1.8. Capabilidade

São medidas que indicam a capacidade de um processo atender às especificações de clientes. O Histograma é uma forma de representar graficamente a distribuição dos dados de uma amostra – capabilidade para variáveis contínuas.

Dentre as distribuições contínuas usadas em estatística, a distribuição normal (Gaussiana) é a mais usada. A distribuição normal possui dois parâmetros: a média (μ), ou seja onde está centralizada e a variância (σ ² > 0) que descreve o seu grau de dispersão. A dispersão ainda é referida em termos de unidades padrão, ou seja desvio padrão (σ).

Standard error - Wikipedia

No próximo post (parte II), continuaremos o roteiro DMAIC, detalhando as etapas de Analyze, Improve e Control.

Leitura recomendada

Lean Mastery Collection: 8 Manuscripts - Lean Six Sigma, Lean Startup, Lean Enterprise, Lean Analytics, Agile Project Management, Kanban, Scrum, Kaizen ... DSDM XP & Crystal Book 9) (English Edition) por [Jeffrey Ries]

VSM (Value Stream Mapping) – do current ao future state

Após a introdução do Value Streams Mapping e seus benefícios, veremos aqui as etapas de criação, sequenciando as atividades que a empresa realiza para atender as demandas do cliente. O fluxo de valor percorre todas as áreas da organização, rompendo silos (entre áreas), em busca de oportunidades de melhoria e redução de desperdícios.

O mapeamento, em geral, envolve colaboradores experientes (e de áreas chaves) por ser um processo complexo e multifuncional. O cliente é a principal razão de acontecer o VSM. Por isso, verifique os benefícios e melhorias que podem ser feitas para os clientes. Quais os problemas que estamos resolvendo? Estamos melhorando a nossa capacidade de entregar valor e remover desperdícios?

O VSM é mais aplicável a processos repetíveis, especialmente quando houver handoffs (tempo de espera) entre os times, que é onde a maioria das demoras e desperdícios se encontram. O mapeamento possui três principais etapas: current state (estado atual; identificar os processos core business), future state (onde devemos estar em alguns dias com os recursos atuais) e next future state (visão estratégica “ideal” de onde poderia estar com recursos e automações ainda não disponíveis).

Um exemplo clássico, representado no desenho abaixo, demonstra todas as etapas de um processo para concluir a entrega do cliente. O value added time é tempo gasto em atividades que agregam valor ao produto. E o Lead Time é a soma de todos os tempos, do início ao fim do processo (inclui os tempos de espera entre as etapas). Percebe-se então a presença de gargalos no fluxo, devido a somente 15 minutos em atividades que agregam valor ao produto, e 68 dias para concluir o processo.VSM

Entre as principais métricas consideradas no VSM que ajudam a compreender os fluxos de entrega ao cliente estão: 

  • Lead Time: tempo decorrido entre o pedido e a entrega, medindo seu processo de produção da perspectiva do cliente.
  • Cycle Time: considera entre o tempo de inicio do trabalho e termina quando está pronto para entrega.
  • Takt Time: é a taxa de demanda do mercado (o ritmo do mercado), ou seja, o que precisa ser cumprido para atender à demanda do cliente.

lead-time-cycle-time

Current state
O desenho abaixo é um exemplo real de como era o ciclo de desenvolvimento em uma empresa, onde o Lead Time era de 19 horas – tempo médio entre o recebimento de uma demanda (via abertura de ticket) e o deploy em produção. Por questões de compliance, a empresa precisava de algumas aprovações e documentos durante o processo.

ALM-analise

Foram identificados alguns gargalos nesse fluxo:

  • Tempo de espera alto para validação do usuário e aprovação da mudança (change management). Causa: documentos preenchidos manualmente durante o processo geravam um checklist demorado.
  • Deploy manual demandava tempo de preenchimento do documento de publicação e do publicador em seguir as etapas.
  • A fase inicial (planning design) exigia a preparação de documentos que seriam utilizados no decorrer das etapas.


Future state

Ao reunir os colaboradores para discutir o future state do fluxo de valor, lembre-se de seguir alguns princípios Lean, tais como a criação do Flow (fluxo), processos vinculados aos clientes, eliminar os desperdícios, evitar super produção (seguir o takt time) e lotes grandes.

Existem diversas ferramentas que ajudam a mapear o fluxo de valor. O desenho abaixo é somente para ilustrar o fluxo to be com as principais mudanças (sem o uso de uma ferramenta específica para VSM), automatizando o deploy e simplificando o registro das informações das RDMs. Essas ações reduziram significativamente os tempos de espera entre trabalhos e o tempo que era gasto com preenchimento manual de documentos (documento de teste técnico, homologação e publicação).

change-management-process

VSM Symbols
Para conhecer melhor os símbolos que podem ser utilizados no VSM, recomendo assistir esse vídeo abaixo:


Playbook
Após ver todos esses conceitos importantes no VSM, como você planeja reunir as pessoas e conseguir mapear os fluxos de valor da sua organização? Um Workshop de VSM (2-3 dias) seria muito apropriado para isso, desde que considere alguns pontos:

  • Identificar um facilitador com experiência em VSM.
  • Identificar e priorizar Value Streams que tenham impacto no cliente e na estratégia organizacional. Escolha a que mais atenda a necessidade da empresa.
  • Envolver um Sponsor (ou champions) comprometido com o future state.
  • Empoderamento do time para realização das mudanças.
  • Na dinâmica, considerar o uso de Charter para discutir escopo, declaração do problema, objetivos e métricas.
  • Considerar a visão ideal future state (de longo prazo) com tecnologias e automações que ainda não estão disponíveis, mas que a visão estratégica deseja ter.
  • Levantar oportunidades e atribuir owners para as implementações.
  • Governança para acompanhamento das ações e planejamento de melhorias.

Também acordar uma reunião com o Sponsor e stakeholders para revisar os objetivos do Workshop, treinamentos (caso seja necessário), atividades Pre Workshop, facilities e a logística dos colaboradores.

VSM-agenda


Outcomes
Os resultados esperados com o VSM incluem melhorias nos tempos de entrega e percepção do cliente (lead time e cycle time), da qualidade e experiência de uso, além da redução de desperdícios no processo. Após a execução da agenda citada acima, os outcomes gerados são:

  • Mapa do fluxo current state
  • Mapa do fluxo future state (e ideal future state)
  • Métricas de performance
  • Plano de transformação para atingir o future state

VSM-outcomes

Leitura recomendada

Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation (English Edition) por [Karen Martin, Mike Osterling]

Value Streams – geração de fluxos de valor

No contexto do Business Agility, onde as empresas precisam se adaptar rapidamente ao mercado e ao ambiente, a gestão das Value Streams é fundamental para otimizar a entrega contínua de valor ao cliente. Sem o value stream thinking, as empresas falham em organizar os objetivos Lean e fornecer o valor máximo ao cliente, assim como não são Customer-Centricity.

A técnica VSM (Value Stream Mapping) é oriunda do Lean Six-Sigma (roteiro DMAIC) e já é utilizada há muitos anos na indústria. Atualmente, também é amplamente utilizado em Agilidade e DevOps para apoiar os times a construir o fluxo de valor, que concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente.

value-stream-mapping

Veja uma comparação rápida entre a gestão funcional e gestão do fluxo de valor:

Gestão funcional (clássica) Gestão do fluxo de valor
Informação restrita a poucos (silos) Informação compartilhada (interfaces)
Foco maior em departamentos Foco nos objetivos dos processos
Comunicação vertical Comunicação transversal
Metas departamentais Objetivos organizacionais
Pouco foco no cliente dos processos Foco total nos clientes dos processos
Delegação de autoridade limitada Alto grau de empoderamento
Processos podem não agregar valor Melhoria contínua nos processos
Estruturado nas habilitações e poderes Estruturado no modo de fazer o trabalho

O que é

Value Streams (ou fluxos de valor) são as etapas que ocorrem para prover serviços ou produtos aos clientes. Por isso, o SAFe (Scaled Agile Framework) identifica como a construção primária para entendimento, organização e entrega de valor.

Um trigger inicia o fluxo de valor, e ao final, há alguma forma de monetização ou valor entregue. As etapas intermediárias são as atividades usadas para desenvolver ou entregar o valor.

enterprise-value-stream-mgmtFigura: Collabnet

Tipos de Value Streams

Existem dois tipos de Value Streams:

  • Operational value streams: são as pessoas e as etapas usadas para fornecer bens ou serviços a um cliente.
  • Development value streams: são as pessoas e as etapas envolvidas no desenvolvimento de novos produtos, soluções e serviços. Esses são os fluxos de valor que constituem um portfólio SAFe.

Em Identifying Value Streams and ARTs, você encontra um artigo adicional e bem completo para ajudar a identificar as Value Streams na sua organização. O Development Value Stream Canvas ajuda no entendimento junto aos stakeholders em relação as pessoas, fronteiras, entregáveis e outras informações da value stream.

Benefícios

O fluxo de valor deve delinear tudo entre a concepção do produto à implantação. Crie seu diagrama usando as principais métricas para determinar como você define e mede o sucesso, melhorando continuamente.

Entre os principais motivos pelo qual as equipes devem utilizar VSM (Value Stream Mapping):

  • Ajuda a identificar gargalos, desperdícios e handoffs
  • Permite acelerar o aprendizado e reduzir o time to market
  • Elimina processos redundantes e desnecessários
  • Promove a colaboração multifuncional e a entrega de valor (ao invés de projetos com foco em concluir tarefas)
  • Contribuem para melhorias na qualidade e produtividade
  • Melhora o feedback integrado e mais rápido

Outros

Após essa abordagem inicial que tivemos sobre as value streams, recomendo também a compreensão de outros conceitos, que são importantes, mas que não serão explicados com profundidade nesse artigo:

  • Lean Budgets: após a definição das value streams, o Lean Portfolio Management (LPM) gerencia os respectivos budgets, com base nos princípios Lean-Agil budgeting, acelerando ainda mais o fluxo.
  • KPIs: os indicadores são utilizados para avaliar os investimentos realizados nas value streams.
  • Coordenação: por mais que a estrutura em value streams empoderem decisões descentralizadas (e com maior independência), a coordenação é necessária para garantir alinhamento das value streams com os objetivos da empresa e do portfólio.
  • ARTs (Agile Release Trains): após identificar as value streams, o passo seguinte é entender como realizá-los. Os ARTs possuem as pessoas e recursos necessários para aprimorar o fluxo de valor.
  • VSM (Value Stream Mapping): a ferramenta ajuda a identificar os desperdícios e atuar nas restrições. Em DevOps, o fluxo de valor concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente.

Book Review: “Lean Enterprise: How High Performance Organizations Innovate At Scale”

Book Review: “Lean Enterprise: How High Performance Organizations Innovate At Scale” (Jez Humble, Joanne Molesky, Barry O’Reilly)


PART I: ORIENT

Chapter 1 – Introduction
Starts explaining the importance of management and people and an approach in Toyota Production System. An alternative to command and control and other highlighted topics are:

A Lean Enterprise is primarily a human system:

  • Pathological organizations: are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
  • Bureaucratic organizations: protect departments. Those in the department want to maintain their “turf”, insist on their own rules, and generally do things by the book – their book.

How organizations process information:

Pathological (power-oriented) Bureaucratic (rule-oriented) Generative (performance – oriented)
Low cooperation Modest cooperation High cooperation
Messengers shot Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to enquiry
Novelty crushed Novelty leads to problems Novelty implemented

The three gaps, and how to manage them:

Effects gap Knowledge gap Alignment gap
What is it? The difference between what we expect our actions to achieve and what they actually achieve The difference between what we would like to know and what we actually know The difference between what we want people to do and what they actually do
Scientific Management Remedy More detailed controls More detailed information More detailed instruction
Auftragstaktik remedy “Everyone retains freedom of decision and action within bounds” “Do not command more than is necessary or plan beyond the circumstances you can foresee” “Communicate to every unit as much of the higher intent as is necessary to achieve the purpose”
Directed opportunism remedy Give individuals freedom to adjust their actions in line with intent Limit direction to defining and communicating the intent Allow each level to define how they will achieve the intent of the next level up, and “backbrief”

The key to the Principle of Mission is to create alignment and enable autonomy by setting out clear, high-level target conditions with an agreed time frame. This principle is applied in multiple contexts:

  • Budgeting and financial management
  • Program management
  • Process improvement

 

Chapter 2 – Manage the Dynamics of the Enterprise Portfolio

This chapter explain the lifecycle of businesses and how companies can balance the exploration of new business models with the exploitation of proven ones.

Technology adoption lifecycle

Technology adoption lifecycle

Once the market has assimilated a disruptive new technology or idea, a whole range of product offerings gets spawned.

Exploring new opportunities and exploiting existing ones are fundamentally different strategies requiring different structure, competencies, processes, and mindset. It is hard to overemphasize this key point: management practices that are effective in the exploit domain will lead to failure if applied to exploring new opportunities – and vice versa. The difference between these two domains:

Explore Exploit
Strategy Radical or disruptive innovation, new business model innovation Incremental innovation, optimizing existing business model
Structure Small cross-functional multiskilled team Multiple teams aligned using Principle of Mission
Culture High tolerance for experimentation, risk taking, acceptance or failure, focus on learning Incremental improvement and optimization, focus on quality and customer satisfaction
Risk management Biggest risk is failure to achieve product / market fit A more complex set of trade-offs specific to each product / service
Goals Creating new markets, discovering new opportunities within existing markets Maximizing yield from captured market, outperforming competitors
Measure of progress Achieving product/market fi Outperforming forecasts, achieving planned milestones and targets

Exploring New Ideas

Less than 50% of startups are alive five years after they start. The Lean Startup details a method for working in conditions of extreme uncertainty – to discover and operationalize new and potentially disruptive business models, and quickly discard those that will not work.

Every entrepreneur has a vision of their business. And for this vision to become reality, there are two key assumptions that must be tested:

  • Values hypothesis: asks whether our business actually provides value for users by solving a real problem.
  • Growth hypothesis: tests how fast we can acquire new customers and whether we have that.

Investing a fixed amount of time and money to investigate the economic parameters of and idea-be it a business model, product, or an innovation such as a process change-is an example of using optionally to manage the uncertainties of the decision to invest further. We limit our maximum investment loss (“downside”) on any individual idea, with the expectation that a small number of ideas will pay off big time, and offset or negate investment in those that did not.

The principle of optionality
The principle of optionality

The other part in this chapter is related to Enterprise Portfolio – balancing (using an economic model), matrix portfolio management (1. Emerging 2. Growth 3. Mature 4. Decline), managing a portfolio with the three horizons model (1. Current Business 2. High Growth Businesses 3. Growth Options).

 

PART II: EXPLORE

Chapter 3 – Model and Measure Investment Risk

Here is presented the principles and concepts that enable us to take a systematic approach to managing the risk of planned work, by gathering information to reduce uncertainty. Model Investment Risk using Business Case or Monte Carlo are discussed in this chapter to verify how useful they are in scenarios of uncertainty.

We should stop using the word “requirement” in product development, at least in the context of nontrivial features. What we have, rather, are hypotheses. In the case of business model and product innovation, the Lean Startup movement provide us with a framework for operating in conditions of extreme uncertainty:

  • Do not spend a lot of time creating a sophisticated business model. Instead, design a simplified business model canvas with captures and communicates the key operating assumptions of your proposed business model.
  • Gather information to determine if you have a problem worth solving.
  • Then, design an MVP (minimum viable product)-an experiment designed to maximize learning from potential early adopters with minimum effort.
  • Throughout this process, update the business model canvas based on what you learn from talking to customers and testing MVPs.

Traditional product lifecycle versus Lean Startup lifecycle:

Traditional project-planning process Lean Startup discovery process
What data do we have to make the investment decision? A business plan based on a set of untested hypotheses and assumptions, backed by case studies and market research Real data based on evidence complied from a working product or service tested with real customers
What happens next? We must create detailed requirements, if we haven’t already, and then starts a project to build, integrate, test, and finally release the system We already have a validated MVP which we can build upon immediately with new features and enhancements based on customer feedback
When do we find out if the idea is any good? Once the project is complete and the product or service is live We already have this evidence based on the data we have collected

Principles for exploration
The OODA loop, a model of how humans interact with their environment which forms the basis of Boyd’s theory of maneuver warfare. OODA stands for observe, orient, decide, act, the four activities that comprise the loop.

 

Chapter 4 – Explore uncertainty of detect opportunities

In the chapter four, tools and techniques are shared to safely create and test hypotheses to solve real business problems identified and validated in our customer development process. Discovery is a rapid, time-boxed, iterative set of activities that integrates the practices and principles of design thinking and Lean Startup, used intensively at the beginning of the explore phase of a new initiative.

Creating a shared understanding (Dan Pink – Drive):

  1. Success requires a shared sense of purpose in the entire team
  2. People must be empowered by their leaders to work autonomously to achieve the team objectives
  3. People need the space and opportunity to master their discipline, not just to learn how to achieve “good enough”

With workshops, you can co-create ideas aligned to business goals. The process, starting with divergent thinking until convergent thinking can generate multiple ideas for discussion and debate.

Structured exploration with divergent and convergent thinking

Structured exploration with divergent and convergent thinking

The Business Model Canvas can share the understanding about business problem to inform the Business Plan. It includes nine essential components of an organization’s conceptual business model – customer segment, value proposition, channels, activities, resources, partnerships, cost and revenue.

business-model-canvas
Business Model Canvas

In this chapter, also is covered MVPs and how to accelerate experimentation with them. Cagan defines an MVP “the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available-also known as valuable, usable and feasible”.

MVPMinimum Viable Product: build a slice across instead of one layer at a time

example set of types of MVPsexample set of types of MVPs 02example set of types of MVPs 03
An example set of types of MVPs

 

Chapter 5 – Evaluate the product/market fit

This chapter discuss how to identify when a product/market fit has been achieved and how to exit the explore stage and start exploiting our product with its identified market. Also, how to use customized metrics to understand whether we are achieving measurable business outcomes while continuing to solve our customers problems by engaging them throughout our development process.

Some examples of vanity metrics and corresponding actionable metrics:

vanity versus actionable metricsExamples of vanity versus actionable metrics

Example innovation scorecardExample innovation scorecard

The pirate metrics helps you to model any service-oriented business. Measuring pirate metrics for each cohort allows you to measure the effect of changes to your product or business model, if you are pivoting. The Votizen’s pirate metrics represents the effect of incremental change and pivots.

AARRR pirates

A story map can help you to tell the narrative of the Runway of our vision. Can be used to plan e prioritize by visualizing the solution as a whole. It provides an effective means to communicate the narrative of our solution to engage the team and wider stakeholders and get their feedback.

sroty-mapping
A user story map

The five critical enablers of growth when transitioning from explore to exploit are:

  • Market
  • Monetization model
  • Customer adoption
  • Forget “big bang” launches
  • Team engagement

 

PART III: EXPLOIT

Chapter 6 – Deploy Continuous Improvement

In most enterprises, there is a distinction between the people who build and run software systems and those who decide what the software should do and make the investment decisions. Ultimately, we aim to remove this distinction. In high performance organizations today, people who design, build, and run software-based products are an integral part of business.

In this chapter is described how to achieve the balancing (the work we do to improve our capability against delivery work that provides value to customers) at program and value stream levels, by putting in place a framework called Improvement Kata. The other part, covers practices in CI/CD as branching versus trunk-based development and other. For more details, I recommend to access my blog.

A good example, in the HP LaserJet Firmware Case Study, we can see how allocating costs to the activities the team is performing.

% of costs Activity
10% Code integration
20% Detailed planning
25% Porting code between version control branches
25% Product support
15% Manual testing
~5% Innovation

The Improvement Kata needs to be first adopted by the organization’s management, because it’s a management philosophy that focuses on developing the capabilities of those they manage, as well as on enabling the organization to move towards its goals under conditions of uncertainty. There are four stages that we repeat in a cycle:

The Improvement KataThe Improvement Kata

  • Understand the direction: derived from the vision set by the organization’s leadership.
  • Grasp the current condition: after the direction, we incrementally and iteratively move towards it at the process level.
  • Establish the next target condition: as we continuously repeat the cycle, we reflect on the last step taken to introduce improvement.
  • Iterate toward the target condition

Three years after the initial measurements (in HP LaserJet case), a second activity-accounting exercise offered a snapshot of the results the FutureSmart team had achieved with their approach:

% of costs Activity
2% Continuous integration
5% Agile planning
15% One main branch
10% Product support
5% Manual testing
23% Creating and maintaining automated test suites
~40% Innovation


Chapter 7 – Identify value and increase flow

Most enterprises are drowning in a sea of overwork, much of which provides little value to customers. In the previous chapter was showed how to implement a program-level continuous improvement strategy to improve productivity and quality and reduce costs. In this chapter, the purpose is showing how the five lean principles can be adopted to reduce the cycle time, increasing quality and return on investment.

In high-performing organizations, leadership and management has a sharp focus on the value the organization is creating for its customers.

The value stream map helps to reflect the current condition in a determined product or service we want to evaluate. This exercise must gather people from every part of organization involved in the value stream.

value stream mapOutline of a value stream map showing process blocks

After concluded, we record three key metrics:

  • Lead time: the time from the point a process accepts a piece of work to the point it hands that work off to the next downstream process
  • Process time: the time it would take to complete a single item of work if the person performing it had all the necessary information and resources to complete it and could work uninterrupted
  • Percent complete and accurate (%C/A): the proportion of times a process receives something from an upstream process that it can use without requiring work

Also is presented Kanban concepts to share a comprehensive way to manage the flow of work:

  • Visualize workflow (creating a board)
  • Limit WIP (work in progress)
  • Define classes of service (for different types)
  • Create a pull system (by agreeing on how work will be accepted into each process block when capacity becomes available)

And a Cost of Delay – a framework for decentralizing economic decisions, to identify and prioritize the work with the highest opportunity cost.

cost of delay.png

How do we prioritize Tasks A and B with Cost of Delay? 


Chapter 8 – Adopt Lean Engineering Practices

“Cease dependence on mass inspection to achieve quality. Improve the process and build quality into the product in the first place”. W. Edwards Deming.

In this chapter there are important concepts to allow the organizations deploy new releases in production frequently, necessary to test ideas with real users and enable effective innovation process (learn and update based on feedback). For more details from other concepts like continuous integration, test automation, continuous deliver and deployment pipeline, access my blog.

Deployment g-forcesDeployment g-forces

 

Chapter 9 – Take an Experimental Approach to Product Development

Up to now, the others chapters show how to improve the speed at which can deliver value to customer. In this chapter, the focus is to discuss alignment – how to use capabilities we have developed to make sure we are building the right things for customers, users, and our organization.

So, concepts as creating hypothesis, hypothesis-driven development and user research are described to focus on the outcomes we wish to achieve, rather than solutions and features.

user research

Different types of user research

Also for more details, please visit my blog.


Chapter 10 – Implement Mission Command

The organizational and architectural concerns are often the biggest barriers to executing the strategy for moving fast at scale based on the principles of Mission Command (described in Chapter 1). Amazon has a famous memo to technical staff directing them to create a service-oriented architecture:

  • All teams will henceforth expose their data and functionality through service interfaces
  • Teams must communicate with each other through these interfaces
  • There will be no other form of interprocess communication allowed. The only communication allowed is via service interface calls over the network
  • It doesn’t matter the technology they use. HTTP, Corba, Pubsub, custom protocols.
  • All services interfaces, without exception, must be designed from the ground up to be externalizable
  • Anyone who doesn’t do this will be fired

A key principle of service-oriented architecture (SOA) is decomposing systems into components or services. Each component or service provides an interface (also known as an API – application programming interface) so that other components can communicate with it.

Here are some strategies enterprises have successfully applied to create autonomy for individual teams:

  • Give teams the tools and authority to push changes to production
  • Ensure that teams have the people they need to design, run and evolve experiments
  • Ensure that teams have the authority to choose their own toolchain
  • Ensure teams do not require funding approval to run experiments
  • Ensure leaders focus on implementing Mission Command

traditional enterprise organizationExample of traditional enterprise organization

product teamsProduct teams working together, with a service layer for performing deployments

Creating small, autonomous teams makes it economic for them to work in small batches. When done correctly, this combination has several important benefits:

  • Faster learning, improved customer service, less time spent on work that does not add value
  • Better understanding of user needs
  • Highly motivated people
  • Easier to calculate profit and loss

 

PART IV: TRANSFORM

Chapter 11 – Grow an innovation culture

Culture is the most critical factor in an organization’s ability to adapt to its changing environment. The main topics in this chapter are:

  • Model and measure your culture: important to consider layers of organizational culture
    • Artifacts: visible, observable aspects of culture such as organizational structures and processes, and how people dress and behave. Hard to decipher.
    • Espoused values: strategies, goals, philosophies, such as the “value statements” you find in the company lobby
    • Underlying assumptions: unconscious beliefs, perceptions, thoughts, feelings (which ultimately govern values and behavior)
  • Change your culture: Old and new approaches to cultural change – Shook offers his own interpretation of Schein’s model, showing how people normally approach cultural change in contrast to the approach taken at NUMMI.
    Shook Change your culture
  • Make it safe to fail
  • There is no talent shortage: Dweck’s two mindsets, showed through a series of experiments that our mindset determines how you decide your goals, how to react to failure, what are our beliefs about effort and strategies, and what is our attitude towards the success of others.
    two mindsets
  • How Google recruits
    how google recruits.jpg
  • Growing talent: there are many ways in which enterprises can invest in people
    • Help employees create and update personal development plans
    • Separate performance reviews from compensation reviews
    • Facilitate regular feedbacks
    • Give employees access to training funds
    • Give employees time to pursue their own goals
  • Eliminate hidden bias: the effects of implicit gender bias on hiring. Here is a selection of strategies that haven proven useful
    • Ensure equitable pay
    • Create target conditions for recruitment and promotion
    • Monitor tenure, rate of advancement and job satisfaction
    • Regularly review policies, interactions and HR processes

effects on hiring

Chapter 12 – Embrace Lean Thinking for Governance, Risk and Compliance

The chapter is to guide you through the maze that is GRC (Governance – Risk – Compliance), particularly as it relates to managing the concepts and practices required to be a lean enterprise. Governance is about keeping our organization in course. It is the primary responsibility of the board of directors, but it applies to all people and other entities working for the organization. It requires the following concepts and principles to be applied at all levels:

  • Responsibility
  • Authority and accountability
  • Visibility
  • Empowerment
  • Risk management and compliance

Apply Lean Principles to GRC processes: visualizing the value stream, increasing feedback, amplifying learning, empowering teams, reducing waste and delays, limiting work in process, making small incremental changes, and continuously improving to achieve better outcomes.

Good Governance requires everyone to focus on discovering ways to improve value and provide accurate information on which to base our decisions. We start with leadership and direction from the Board and Executives, and rely the ability of employees to embrace their responsibility to make good decisions at work. A culture of openness, trust, and transparency is required for good governance.

 

Chapter 13 – Evolve Financial Management to drive Product Innovation

Centralized budgeting process are typically used to plan, forecast, monitor and report on the financial position and overall performance of an organization. However, the traditional annual budget cycle can easily:

  • Reduce transparency
  • Remove decision from the people doing the work
  • Direct costs away from value creation
  • Measure performance by the ability to please the boss or produce output

budget purpose
Approaches to achieving the goals of budgeting

The Dynamic Resource Allocation creates more frequent checkpoints for funding decisions, and each decision has less risk associated with it. All decisions are based on the empirical evidence, so they become easier to make. When done correctly, access to funding expands to more teams, gets more frequent, has less associated risk, and brings better results. We thus encourage more innovation and reduce financial risk associate with large initiatives.

dynamic resource allocationDynamic resource allocation

In the other part, the chapter describe:

  • Avoid using budgets as the Basis for performance measurement: bonuses and rewards for good bottom-line financial results work better when they are shared equally. Working teams will eventually cripple the organization by inertia and subterfuge when their contributions are not acknowledged and rewards are based on a process perceived as unfair.
  • Stop basing business decisions on CAPEX versus OPEX: there are tax advantages and positive financial impacts from reporting organization expenditures appropriately in these different buckets, so a lot of attention is paid to it.
  • Modify your IT Procurement Processes to gain greater control over value delivery: this painful, highly detailed contractual process has several negative side effects
    • It’s a poor way to manage the risks of product development
    • It favors incumbents
    • It favors large service providers
    • It inhibits transparency
    • It is inaccurate
    • It ignores outcomes

 

Chapter 14 – Turn IT into a competitive advantage

This chapter is discussed some strategies to increase the responsiveness of IT to changing business needs, improve the stability of IT services, and reduce the complexity of our IT systems and infrastructure.

Rethinking the IT Mindset: IT has historically been seen as a cost center and an internal enabler of the business, not a creator of competitive advantage. In the 2014 State of DevOps Report, over 9,000 people worldwide were polled about what creates high-performance organizations, whether IT does in fact matter to the business, and what factors impact the performance of IT departments.

rethinking it mindsetWhat business leaders think about the business-IT relationship

The practices most highly correlated with high IT performance (increasing both throughput and stability) are:

  • Keeping systems configuration, application configuration, and application code in version control
  • Logging and monitoring systems that produce failure alerts
  • Developers breaking up large features into small, incremental changes that area merged into trunk daily
  • Developers and operations regularly achieving win/win outcomes when they interact

If we want to compete in a world of ever shorter product cycles, central IT needs to be business unit’s trusted partner, not an order-taking cost center. In turn, IT needs to achieve higher levels of throughput while improving stability and quality and reducing costs. The complexity of existing enterprise IT environments, combined with the amount of planned and unplanned work that must be done to keep them running, are the chief barriers to achieving these outcomes.


Chapter 15 – Start where you are

The biggest barrier to success in changing the way you work is a conviction that your organization is too big or bureaucratic to change, or that your special context prevents adopting the particular practices we discuss. Always remember that each person, team, and business that started this journey was unsure of what paths to take and how it would end. The only accepted truth was that if they failed to take action, a more certain, negative ending lay ahead.

The only path to a culture of continuous improvement is to create an environment where learning new skills and getting better at what we do is considered valuable in its own right and is supported by management and leadership, thus reducing learning anxiety. We can use the Improvement kata (presented in chapter 6) to create this culture and drive continuous improvement.

pdcaContinuous evolution and adaption to change

The process of creating alignment and consensus between levels is critical. In strategy deployment, this process is described as catchball, a word chosen to evoke a collaborative exercise. The target conditions from one level should not be transcribed directly into the direction for teams working at the level below. Catchball is more about translation of strategy, with “each layer interpreting and translating what objectives from the level above mean for it”.

catchball.png
Using catchball to drive strategic alignment of objectives and initiatives

Begin your journey: use the following principles for getting started:

  • Ensure you have a clearly defined direction
  • Define and limit your initial scope
  • Pursue a high-performance culture of continuous improvement
  • Start with the right people
  • Find a way to deliver valuable, measurable results from early on

Creating a resilient, lean enterprise that can adapt rapidly to changing conditions relies on a culture of learning through experimentation. For this culture to thrive, the whole organization must be aware of its purpose and work continuously to understand the current conditions, set short-term target conditions, and enable people to experiment to achieve them.

We then reassess our current conditions, update our target conditions based on what we learned, and keep going. This behavior must become habitual and pervasive. That is how we create a mindset of continuous improvement focused on ever higher levels of customer service and quality at ever lower costs.

Link para compra do livro: Lean Enterprise

Lean Enterprise: How High Performance Organizations Innovate at Scale (English Edition) por [Jez Humble, Joanne Molesky, Barry O'Reilly]

DevOps e ligação com Kaizen, Lean, ITIL e Infra as code

Continuando o post anterior sobre DevOps e a ligação com outras práticas, segue abaixo um resumo de Extreme Programming (XP), Lean, Kaizen, Kanban, ITIL e Infrastructure as code.

eXtreme Programming (XP)

É uma metodologia de desenvolvimento de software focada em melhorar a qualidade e a capacidade de resposta à mudanças nos requisitos. Promove lançamentos frequentes.

Entre as principais práticas:

  • Small releases
  • Programação em pares
  • Integração contínua
  • Refatoração
  • TDD (test driven development)
  • 40 horas semanas (sustainable place)

 

xp

Lean

Visa melhorar o desempenho dos processos da empresa, identificando e eliminando o desperdício e a causa raiz do defeitos.

Princípios Lean

  • Produção puxada
  • Melhoria contínua
  • Valor na visão do cliente
  • Fluxo contínuo sem interrupção
  • Fluxo de valor e mapeamento

Gemba: é o local onde as coisas acontecem de verdade – “chão de fábrica”.

lean-hous

Kaizen: melhoria contínua

Kaizen é uma prática cultural que significa mudar para melhor. O foco é analisar o ambiente atual onde o valor é criado ou onde o problema:

▪ Não é reportado; não há métricas
▪ Não há discussão de processo; nem documentação sobre ele
▪ Olhar mesmo o que as pessoas estão fazendo, até revisar código, etc.

Princípios:

▪ Bons processos trazem bons resultados
▪ Providencie ações para controlar e corrigir causas raíz
▪ Gemba (go see for yourself)
▪ Converse com dados, gerencie por fatos
▪ Trabalhe como um time
▪ Kaizen é assunto de todos
▪ PDCA para a resolução de problemas
kaizen

Kanban

  • Sistema Kanban (pull | limites | valor): sistema puxado, limitado que permite visualizar o fluxo de trabalho em busca da geração de valor.
  • Método Kanban (transição | kaizen | gestão): abordagem evolutiva e incremental, implementando mudanças evolutivas e incrementais.

O objetivo do Kanban é tornar problemas explícitos e engajar pessoas na mudança. Entre as principais características:

  • Otimização de fluxos de trabalho
  • Melhorar a comunicação e colaboração
  • Transformação do ambiente de trabalho e evolução dos processos
  • Tornar o trabalho mais previsível e estável

kanban-board

Práticas

  • Visualize
  • Limite o trabalho em progresso (WIP)
  • Meça e gerencie o fluxo
  • Torne as políticas do processo explícitas
  • Implemente mecanismos de feedback
  • Melhore colaborativamente, evolua experimentalmente
evolucao-kaizen

WIP (trabalho em progresso)
O trabalho que está em execução naquele determinado ponto do processo. Sinaliza a capacidade de entrega do time. O tamanho precisa ser adequado a expectativa do cliente com a entrega.

Throughput
É uma métrica que demonstra a quantidade de tarefas entregues em um determinado período de tempo. Com isso, podemos avaliar a performance dos times. O vilão da produtividade são as filas.

Lead Time
É o tempo entre a abertura da requisição e o momento que ela entra em seu estado final. Lembre-se que esforço é diferente de prazo.

lead-time

ITIL

Guia completo para os processos de TI, incluindo gestão de incidentes, portfolio, capacidade e catálogo de serviços. É prescritivo e top down framework. Boa parte exige um modelo waterfall (push-drive model) – 5 livros e bem pesado.

  • ITIL: primeiro framework ITSM (IT Service Management)
    • 1ª versão: uma série de diretrizes de como gerenciar serviços (início anos 90)
    • 2001: ITIL v2 foi publicada com a intenção de ser usada por outros usuários
    • 2007: ITIL v3 a última versão (atualizada em 2011) – utiliza uma visão baseada no modelo de processo para controlar e gerenciar serviços.
Fases do ITIL

1- Service Strategy
2- Service Design
3- Service Transition
4- Service Operation

 

ITIL

Em 1999 o livro The Visible OPS (100 páginas) publica a implementação do ITIL em 4 passos práticos e auditáveis (2004):

visible-ops
  1. Core do ITIL: possui a maior parte das práticas de sucesso e um roadmap de como implementá-lo;
  2. A ideia é que você pode ter um processo de controle bem definido, auditável e compatível,  mas que pode ser leve e ágil e completamente oposto a maioria das implementações ITIL
  3. A recomendação é utilizar e aprender com o ITIL, mas analise bem antes de implementar um processo específico. Considere o objetivo do processo e como seria realizado com as práticas de DevOps
  4. No CI (do Chaos Monkey) há recomendações para buscar caminhos alternativos para atingir o objetivo esperado


Infraestrutura as
code

É uma prática importante a ser adotada, caso queira implementar DevOps na sua organização. Também é pré-requisito para o pipeline de implantação. Tratar a infraestrutura de TI como código permite o gerenciamento e provisionamento de infraestrutura por meio de arquivos.

Além disso, a adoção de práticas poderosas como controle de versão, entrega contínua, etc. Habilita a escala, load balance, disponibilidade e performance exigidas por aplicações modernas.

infra-as-code

Por fim, vale relembrar algumas práticas recomendadas por Martin Fowler:

  • Utilizar arquivos de definição (shell scripts ou Chef receipts, por exemplo) para evitar mudanças manuais em servidores.
  • Auto documentar sistemas e processos ao invés de instruções.
  • Versionamento de tudo (que for possível) para manter rastreamento e controle.
  • Frequência reduz a complexidade – quanto maior o tamanho do update, mais difícil será detectar o erro, se houver.
  • Manter serviços continuamente disponíveis, com melhorias para evitar  downtimes.
martin-fowler-praticas

 

Desafios organizacionais em entrega contínua – time-to-market e exponencial

Organizações Exponenciais
Como a tecnologia acelerada está mudando as organizações… “Uma Organização Exponencial é aquela cujo impacto (ou resultado) é desproporcionalmente grande – pelo menos dez vezes maior – comparado aos seus pares, devido ao uso de novas técnicas organizacionais que alavancam as tecnologias aceleradas”.

organizacoes-exponenciais

A habilitação da empresa p/ informação, entrelaçado c/ o ritmo da inovação acelera ainda mais o crescimento, até que as mudanças passam a ser exponenciais.

Este crescimento exponencial e a relação preço/desempenho dobra a cada um ou dois anos.

PMT – Propósito Máximo de Transformação
É muito comum encontrar o Proposito Transformador Massivo (PTM) em organizações exponenciais. O PTM é uma declaração do propósito da organização, ou seja, o motivo da existência do negócio. Na famosa organização TED, por exemplo, ideias que merecem ser espalhadas.

Este propósito singular é fundamental para desenvolver a capacidade de expandir e o mindset exponencial. Outros aspectos como o uso de tecnologias sociais, criação de equipes multidisciplinares, cultura de experimentação e aprendizado, inteligência artificial, métodos ágeis e práticas DevOps colaboram ao crescimento exponencial.

Existem cerca de 10 atributos comuns, agrupados dois lados:

  • Lado esquerdo: do acrônimo em inglês IDEAS, representa elementos de controle, ordem e estabilidade.
  • Lado direito: do acrônimo em inglês SCALE, representa elementos de criatividade, crescimento e incerteza.

ideas-escala

Lean Startup
O Lean Startup adapta os conceitos da lean manufacturing (Toyota – Taiichi Ohno), com base em tamanho de lotes menores e produção justin-time,  evitando construir algo sem valor (validated learning). Value Vs Waste.

Value Vs. Waste – “Lean thinking defines value as providing benefit to the customer; anything else is waste”. So, validated learning is backed up by empirical data collected from real customers, the essential unit of progress for startups. “Success is not delivering a feature; success is learning how to solve the customer’s problem”.

O Build-MeasureLearn loop e a validação de ideias no mercado (variação do usual Kaizen PDCA):

  • Build: foco em criar o MVP
  • Measure: progresso em relação aos objetivos
  • Learning: traz afirmações valiosas sobre a aceitação dos produtos e perspectivas de negócio

 

build-measure-learn-loop

Entre os principais benefícios da experimentação:

  • Aprendizado contínuo
  • Investimento direcionado
  • Validação de hipóteses são mais valiosas que previsões de mercado ou business plan


Case Studies
O caso das empresas Zappos e Dropbox foram exemplos do uso da experimentação, onde as empresas interagiram com os clientes e aprenderam sobre suas necessidades.

zappos Zappos (adquirida pela Amazon em 2009): a interação com os clientes e o aprendizado de suas necessidades através de experimentações foram essenciais.

O vídeo demonstrativo de três minutos da tecnologia Dropbox que sincroniza os arquivos, e levou centenas de milhares de pessoas ao site.

Validação da suposição pelo número de inscrições; não porque o disseram em um grupo de foco ou por causa de uma analogia promissora com outro negócio.

dropbox

 

Leituras recomendadas: Livros de DevOps e SRE

Há algum tempo, venho recebendo perguntas de algumas pessoas sobre a minha sugestão de leitura para aprofundar os conhecimentos em DevOps. Então, decidi compartilhar um resumo dos principais livros que li nesta minha jornada e assim, facilitar a escolha de qual caminho você pode dedicar seu tempo de estudos.

Segue abaixo minhas leituras recomendadas em DevOps e SRE:

continuous-delivery

Continuous Delivery
Escrito por Jez Humble e David Farley, considero o melhor livro para compreensão de conceitos DevOps. A parte I descreve configuration management, continuous integration e estratégia de testes. Na parte II, o Deployment Pipeline com Build, deploy e testes automatizados. A parte III aborda a gestão de infra e ambientes, dados, componentes e versionamento. Para iniciar, veja o resumo do livro.

book-the-phoenix-project The Phoenix Project
O livro traz uma história fictícia para apresentar um cenário de TI, considerando a complexidade e o uso do DevOps neste contexto. Ela é centrada em Bill (gerente de TI) que recebe o desafio do CEO para organizar o fluxo de trabalho e simplificar a comunicação entre os departamentos em 90 dias. Também aborda métricas e empresas low / high performers.
book-the-visible-ops

The Visible OPS
Publica a implementação do ITIL em 4 passos práticos e auditáveis. 1) Core do ITIL com práticas de sucesso e um roadmap de como implementá-lo; 2) Apresenta processos de controle bem definidos e que pode ser leve e ágil; 3) Aplicabilidade do ITIL e como seria realizado com as práticas DevOps; 4) Buscar caminhos alternativos para atingir o objetivo esperado (Chaos Monkey).

book-devops-handbook The DevOps Handbook
Aborda as melhores práticas pelos líderes do movimento DevOps. É um guia completo com recomendações de como integrar a gestão de produto, práticas DevOps e sistemas.  Também incentiva a competitividade na equipe e rentabilidade da empresa, trazendo a experiência de empresas como Amazon, Etsy e Netflix. Por fim, vale pelo direcionamento de como se tornar relevante no marketplace.
book-effective-devops Effective DevOps
Práticas para alinhamento em DevOps na organização e foco nos quatro pilares fundamentais da cultura com vários estudos de caso. Estas abordagens contribuem na quebra de silos de informação para melhorar a colaboração entre equipes. São elas: colaboração individual | afinidade dos times | ferramentas | DevOps em escala.
book-release-it Release It!
O livro escrito por Michael T. Nygard (programador e arquiteto) visa compartilhar a experiência prática em deploys de aplicações para a produção. O foco é em relação a arquitetura, fator multiplicador (negligência com recursos – usuários, sessão, etc.) e fator limite (custo e prazo com recursos novos).
book-lean-enterprise Lean Enterprise
É um guia prático que apresenta os princípios e padrões Lean e Ágil para conseguir responder rapidamente a mudanças de mercado. A parte I aborda estratégia, cultura e o ciclo de vida das inovações. Na parte II, verificar as ideias (coletando dados) e ser orientado a valor. A parte III foca na exploração das ideias validadas, e a parte IV como as empresas criam ambientes de aprendizado e experimentação.
book-SRE Site Reliability Engineering
Teoria e prática do SRE, compartilhando como o Google trata sistemas em produção. Também aborda a gestão do Google em relação a treinamento, comunicação e reuniões. As ferramentas APM e feedbacks loops são destaques pela contribuição em análises, métricas e identificação de gargalos e lentidões.
book-leading-transformation Leading the transformation
Por conta da importância do desenvolvimento de software nas organizações e as melhorias requeridas neste processo. Cita a transformação digital na Amazon e Google, aplicando Ágil e DevOps e os benefícios obtidos com a entrega mais rápida das aplicações. Foca na eficácia das equipes e na criação de uma estrutura clara para melhorar o desenvolvimento e a entrega.

Plataformas Digitais: Criando produtos e validando hipóteses no mercado com foco UX (experiência do usuário)

Arquivo PDF: 2018 1 Estrutura do TCC – ARTIGO CIENTÍFICO – Leonardo Matsumota

RESUMO
Este trabalho aborda a aplicação das técnicas Lean Inception, Lean UX e Agile (Scrum) para criar um modelo de experimentação enxuto e contínuo afim de validar hipóteses de produtos no mercado. As principais fases da Lean Inception são: escrever a visão do produto, o produto é/não é/faz/não faz, descrever as personas, features, revisão técnica e de negócio, exibir as jornadas de usuário, priorizar as features e construir o MVP Canvas. Com a determinação dos MVPs – features para o sistema de admissão de candidatos, o desenvolvimento do sistema dar-se-á com o uso do Scrum (framework ágil), trabalhando com ciclos adaptativos de forma iterativa e incremental. Este planejamento e inspeção frequentes visam reduzir as incertezas e riscos do projeto, devido a adequação de escopo e frequente validação das entregas. Por fim, utilizamos a Lean UX (user experience) como guia para o processo de experiência do usuário, ajustando o sistema de acordo com o aprendizado obtido com as técnicas Vision, Framing, and Outcomes; Collaborative Design, etc.

Palavras-chave:  MVP. Métodos Ágeis. UX. Lean Inception. Design Thinking.

ABSTRACT
This paper approach the use of Lean Inception, Lean UX and Agile (Scrum) to create a lean and continuous experimentation model to validate product hypotheses in the market. The main phases of Lean Inception are: writing the product vision, the product is / is / does / does not, describe the personas, features, technical and business review, display user journeys, prioritize the features and build the MVP Canvas. With the determination of the MVPs – features for the candidate in admission system, the development of the system will be through the use of Scrum (agile framework), working with adaptive cycles in an iterative and incremental way. This frequent planning and inspection is intended to reduce project uncertainties and risks, due to the suitability of scope and frequent validation of deliveries. Finally, we use the Lean UX (user experience) as a guide to the user experience process, adjusting the system according to the learning achieved with the techniques Vision, Framing, and Outcomes; Collaborative Design, etc.

Keywords:  MVP. Agile. UX. Lean Inception. Design Thinking.

 

INTRODUÇÃO

Com a evolução tecnológica acelerada e a transformação digital nos negócios, os usuários encontram cada vez mais opções de produtos disponíveis e ferramentas que auxiliam na hora da compra, como por exemplo, a avaliação de outros usuários.

Porém, com menos tempo e fidelidade às marcas, os usuários deparam com um alto volume de conteúdo na web, que precisam de relevância para conquistá-los e assim propiciar uma boa experiência ao longo da jornada de compra naquela plataforma. É necessário mostrar o seu valor para o consumidor!

E para isso, as empresas precisam compreender melhor seus pensamentos e atitudes, conectando-se a seus valores. A horizontalização auxilia neste aprendizado sobre o consumo, pois os usuários fornecem informações para a empresa, criando uma relação com os produtos e os serviços que adquire.

O Marketing 4.0 destaca a humanização da marca, o marketing de conteúdo, a experiência omnichannel e a estratégia dos 5 A’s – estratégia de exposição da empresa, desde a atenção até a advocacia da marca (KOTLER, Philip). Veja o modelo proposto na Figura 1.

5As
Figura 1 – 5A’s
Fonte: http://www.sebraemercados.com.br/marketing-4-0-oportunidades-e-tendencias-kotler-2017/

Outro ponto é adotar um modelo extremamente dinâmico para criar produtos e validar hipóteses no mercado, como os testes A/B por exemplo. Também viabilizar o time-to-market, trabalhando com entregas contínuas e criando MVPs (Minimum Viable Product) para validar as principais premissas do negócio.

Entre as principais vantagens do MVP:

  • Reduzir riscos de mercado, pois os investimentos vão de acordo com a aceitação dos usuários
  • Validação de hipóteses
  • Experimentação e aprendizado
  • Geração de valor acelerada
  • Avaliar a escalabilidade do produto

O modelo Build-Measure-Learn Feedback Loop é uma efetiva abordagem para desenvolvimento de startup, melhorando continuamente a criação de produtos, serviços e ideias com ótimo custo-benefício (RIES, Eric).

A figura 2 demonstra o ciclo de criação e teste de hipóteses, começando pequeno para clientes potenciais, medindo suas reações e aprendendo com os resultados. O objetivo é evoluir o produto para entregar exatamente o valor esperado para o cliente.

lean-startupFigura 2 – Build-Measure-Learn Feedback Loop
Fonte: http://theleanstartup.com/principles

E como ter uma abordagem criativa para criação de produtos? O Design Thinking busca de forma colaborativa (pessoas colocadas no centro do desenvolvimento do produto) encontrar soluções inovadoras para os problemas. O foco é em necessidades do mercado, e não em pressuposições estatísticas.

A abordagem Double Diamond no DT auxilia a compreender os clientes e seus problemas, utilizando dois diferentes tipos de pensamento:

  • Divergente: pensamento amplo, considerando qualquer ideia.
  • Convergente: pensamento estreito, identificando e focando em um ou dois dos principais problemas e soluções.

design-thinking.pngFigura 3The Double Diamond
Fonte: https://medium.com/seek-blog/

Boa parte das soluções em plataformas digitais consideram o desenvolvimento de software para construir o produto ou estruturar o suporte do negócio. Operar em nível avançado com práticas DevOps habilita o processo de entrega contínua de valor aos usuários e mantém os ambientes de produção mais estáveis, provendo credibilidade a marca.

Já a governança destes projetos com métodos ágeis, enfatiza a criação de times disciplinados focados em maximizar o valor para o cliente. O modelo ágil difere do tradicional por trabalhar com processos empíricos, realizando uma pequena quantidade de trabalho para adquirir experiência (iteração). Utiliza-se ciclos adaptativos de forma iterativa e incremental.

O processo empírico planeja frequentemente e JIT (just in time). Há inspeção frequente dos resultados. O planejamento tradicional usa técnicas para determinar prazo e custo no início do projeto, porém em um sistema adaptativo complexo, conforme o cone da incerteza (figura 4), quanto mais cedo, maiores são as incertezas.

cone-incertezaFigura 4 – Cone da Incerteza
Fonte: https://agilemomentum.files.wordpress.com/

 

1   Validação de hipóteses

 Lean Inception

A Lean Inception é utilizada para os times que precisam desenvolver iterativamente um MVP, escolhendo as funcionalidades que tenham valor aos usuários, com base em premissas obtidas em testes. É uma técnica que corrobora o entendimento do que é preciso para criar um produto de sucesso (CAROLI, 2017).

Não substitui sessões de ideação, pesquisa de clientes, revisão de arquitetura ou análise de competitividade. Aplicável a grandes projetos, trabalha orientada a Lean, com iterações e testes, descobrindo funcionalidades que tenham valor aos usuários. Em pequenas organizações, como startups, utilize para validar ideias com MVPs e evoluir para um produto de software.

1.1.1 Write the product vision
Esta atividade auxilia a definir colaborativamente a visão do produto, que é a essência do valor de negócio do produto e a mensagem convincente aos usuários.

  1. Escreva o template de visão do produto em um quadro branco ou flipchart para que o time veja facilmente.
  2. Divida o time em grupos menores e peça que todos preencham os slots disponíveis.
  3. Junte o resultado de cada grupo e consolide as informações.

O roteiro de criação da visão do produto:
For [final client],
whose [problem that needs to be solved],
the [name of the product]
is a [product category]
that [key-benefits, reason to buy it].
Different from [competition alternative],
our product [key-difference].

product-vision.pngFigura 5Product Vision

1.1.2 The product is – Is not – Does – Does not
Explicar o produto descrevendo o que ele não é facilita a exploração e entendimento do que será criado. Esta atividade ajuda a explicar o produto, formando um consenso sobre o produto faz e o que ele não faz.

  1. Divida o flipchart em quatro áreas: Is / Is not / Does / Does not.
  2. Escreva o nome do produto acima dos quadrantes
  3. Incentive os participantes a descreverem o produto com post-its­ nas áreas correspondentes.
  4. Leia e agrupe anotações similares.

product-is-is-notFigura 6The product is – is not – does – does not

1.1.3 Describe the Personas
A persona representa o usuário no sistema, descrevendo seu papel e necessidades. Nosso propósito é criar uma representação realística do usuário, ajudando a descrever as funcionalidades do ponto de vista de quem terá interação com o produto final.

  1. Divida o time em pares ou trios. Entregue um template de personas para cada grupo.
  2. Peça que cada grupo crie uma persona, utilizando o template como referência.
  3. Cada grupo apresenta suas personas para o time inteiro.
  4. Divida novamente o time em diferentes grupos e repita os passos acima.

É importante realizar esta atividade em grupo, repetindo quantas vezes necessário. Se há a criação de muitas personas, podemos combinar e priorizá-las. Os stakeholders que conhecem os objetivos do projeto devem participar ativamente de tudo isso, auxiliando o time a identificar as personas e revisando suas descrições.

persona-AFigura 7Describe the persona A

persona-BFigura 8 – Describe the persona B

1.1.4 Discover the Features
Descreve a interação do usuário com o produto (da forma mais simples possível) ou algumas ações que o produto deve realizar.

  1. Colocar os objetivos do produto como títulos de coluna em um feature canvas único. Priorizar os objetivos da esquerda para a direita, de cima para baixo.
  2. Colocar as personas como títulos de linhas, priorizando de cima para baixo.
  3. Todos devem sugerir funcionalidades e colocá-las nas discussões. Utilize as personas e os objetivos para guiarem a discussão. A principal questão é: “o que o produto precisa fazer para que esta persona alcance seu objetivo”.

discover-features.pngFigura 9Discover the features

* embora o canvas pareça uma matriz, não necessariamente teremos uma funcionalidade para cada combinação de objetivo e persona. Podemos ter várias funcionalidades para uma persona atingir um objetivo específico. Também ter personas que não precisam de uma funcionalidade para um determinado objetivo.

1.1.5. Technical and Business Review
É feita uma avaliação das features em termos de esforço, valor e incerteza. Utilizaremos o canvas que desenvolvemos durante a sessão Discover the Features. Para o esforço e valor do negócio, anotamos as features utilizando marcações na escala de um, dois ou três.

effort-business-valueFigura 10Effort and business value
Fonte: https://martinfowler.com/articles/lean-inception/tech-and-business-review.html

technical-review.png
Figura 11Technical and business review

Classificamos a feature considerando aspectos técnicos de desenvolvimento (technical certainty) e aceitação do negócio (business agreement). Combinamos as duas classificações de acordo com o nível de incerteza: vermelho (alto), amarelo (médio) e verde (baixo). Se a feature estiver na parte inferior esquerda da tabela, marque com um “X”, pois não é aplicável ao MVP.

technical-certaintyFigura 12Business Agreement x Technical Certainty
Fonte: https://martinfowler.com/articles/lean-inception/tech-and-business-review.html

business-agreeement-technical-certainty.pngFigura 13Business Agreement x Technical Certainty (Admission)

1.1.6 Show the User Journeys
Descreve a sequência de passos que o usuário percorre para atingir seu objetivo. Algum destes passos representam pontos de contato com o produto, demonstrando como o usuário interage com ele. O time levanta questões e alternativas sobre os desejos dos usuários e capacidades do produto.

  1. Selecione a persona
  2. Identifique um objetivo para esta persona.
  3. Escreva em post-it­ e coloque no topo à esquerda do
  4. Defina o ponto de partida e coloque em post-it­ no canvas. Questões de apoio: Como a persona começa seu dia? O que desperta a vontade de atingir seus objetivos?
  5. Descreva cada passo em sequência no post-it e coloque no canvas. Continue planejando os passos até a persona atingir seu objetivo.

user-journeyFigura 14User journey

1.1.7 Display Features in Journeys
Neste ponto temos uma lista de features que o produto deve ter, e as jornadas do usuário indicam como serão as interações com o produto. Integraremos então as duas perspectivas. Coloque as principais jornadas e features visíveis e lado a lado. Faça cada jornada, e para cada etapa, registre as features de que precisa.

features-in-journey.pngFigura 15Features in journey

Algumas jornadas estão faltando features: para isso, criamos cartões de feature, marcando o esforço, valor e incerteza. Algumas features não estão mapeadas na jornada: devemos desafiá-las, realmente precisamos se não participam das jornadas de nossos usuários?

1.1.8 Sequence the Features
Agora temos condições de trabalhar no primeiro MVP e nas iterações seguintes. Fazemos isso, definindo a Features Sequencer.

  1. Crie a Features Sequencer template (geralmente um flipchart com linhas numeradas)
  2. Explique as regras da Features Sequencer *
  3. Lembre todos do objetivo da atividade: definir a sequência de entrega das features do produto. O objetivo do MVP é aprender a cada iteração construindo um MVP que permitirá testar se o business case é efetivo.
  4. Todos devem colocar feature cards no sequencer, movendo eles enquanto exploramos as opções, até chegarmos a um acordo.
  5. O resultado mostra as features para cada iteração do MVP.

* as regras são: uma linha contém no máximo três features; uma linha não pode ter mais de uma feature com cartão vermelho (alta incerteza); cada linha deve ter ao menos um cartão verde (baixa incerteza); a contagem do esforço não pode adicionar mais que 5 Es; a contagem do valor deve somar pelo menos 4 $.

sequence-features.pngFigura 16Sequence the features

1.1.9 Build the MVP Canvas
Agora temos todo o conhecimento para construir o artefato final (MVP canvas) em cada iteração do MVP que definimos em Sequence the Features. O princípio é design centrado no usuário, considerando usuários e suas jornadas. Devemos trabalhar em ações que melhorem ou simplifiquem suas vidas e desenvolvendo hipóteses que podem testar o MVP.

  1. Visão do MVP: o que estamos tentando aprender?
  2. Declaração de resultado: o que acreditamos que este MVP irá alcançar? O que esperamos aprender?
  3. Métrica para validação de hipóteses de negócio: como você sabe quando pivotar e quando perseverar? O que determina sucesso ou falha? Quais dados devemos coletar?
  4. Personas e Plataformas: identificamos um grupo menor de personas que estaremos focando nesta iteração.
  5. Jornadas: revisão dos resultados de Show the User Journeys e Display Features in Journey.
  6. Features: relacionar as features para o MVP.
  7. Custos e prazos: em relação as features do MVP.

mvp-i.pngFigura 17 – MVP I

mvp-ii.pngFigura 18 – MVP II

 

2 UX (USER EXPERIENCE)

Utilizamos o Lean UX (user experience) como guia para o processo de experiência do usuário. Trata-se de uma evolução do design do produto, com intensa colaboração e cross-functional. O shared understanding é o engajamento contínuo do time para falar sobre o que funciona (não apenas documentos e features), obtendo feedbacks do mercado. Devemos mensurar o que funciona, aprender e ajustar.

Em geral, Lean UX aborda três frentes:

  • Facilita o entendimento como uma mudança de processo para designers
  • É um mindset que nos permite abordar o trabalho de novas formas
  • Também é um pensamento sobre gerenciamento de software

Entre os princípios do Lean UX estão:

  • Cross-Functional Teams: várias disciplinas envolvidas na criação do produto.
  • Small, dedicated, colocated: manter os times pequenos (até 10 pessoas) dedicados a um projeto para melhorar a comunicação, foco e ambiente de trabalho.
  • Progress = Outcomes, not Output: features e serviços são outputs; atingir os objetivos de negócio são outcomes.
  • ProblemFocused Teams: atribuição de um time, que ao invés de trabalhar em features, ficará dedicado a resolução do problema. Desperta o senso de ownership.
  • Small Batch Size: mantém o inventário baixo e de alta qualidade. Evita um grande inventário de ideias não testadas e não implementadas.
  • Continuous Discovery: processo contínuo de engajamento do usuário durante o processo de design e desenvolvimento.
  • GOOB – The new user-centricity: “getting out of the building” significa que as respostas devem ser buscadas fora do escritório, em marketplace, por exemplo.
  • Shared understanding: conhecimento evoluído (do coletivo) sobre o ambiente, produto e usuários.
  • Anti-pattern: Rockstars, Gurus and Ninjas: Lean UX defende a mentalidade baseada em time. Evite perfis que possam afastar a colaboração.
  • Externalizing your work: utilize quadros, lembretes, etc. para manter um ambiente propício a ideias e inspiração de outras pessoas.
  • Making over analysis: há mais valor em criar a primeira versão de uma ideia do que dedicar metade de um dia debatendo em reuniões.
  • Learning over Growth: foco em aprendizado primeiro; escalar em segundo.
  • Permission to fail: para encontrar a solução do negócio, o time precisa experimentar ideias. Muitas destas ideias irão falhar, por isso crie a cultura da experimentação.
  • Getting out of the deliverables business: documentos não resolvem o problema do usuário, bons produtos sim. O time deve estar focado em trabalhar nas features com maior impacto para os usuários, medindo a reação do mercado em relação a qualidade do produto.

A área de Vision, Framing, and Outcomes descreve como mudamos radicalmente a forma de trabalho, tendo como objetivo a criação de outcomes, e não somente entregáveis. Para isso, algumas ferramentas são utilizadas na confirmação da hipótese, tais como Business Assumptions Worksheet, Hypotheses (utilização do roteiro para confirmação da hipótese), Subhypotheses (quebra da hipótese em partes menores), Outcomes, Personas (uso da Proto-Personas e Persona Format para moldar quem estará utilizando) e Features.

O Collaborative Design aborda o processo de design com técnicas familiares, mas com ênfase no trabalho colaborativo. O objetivo inicial é a velocidade, priorizando o aprendizado e o uso do MVP como ferramenta chave. Entre as principais técnicas estão: Design Studio (coloca o time cross-functional para trabalhar juntos e visualizar potenciais soluções para o problema) e Style Guides (accessible, continually improved e actionable).  

Em MVPs and Experiments, os experimentos são utilizados para validar hipóteses no mercado e criar produtos baseado no aprendizado. E assim trabalhar na criação do MVP com ou sem protótipos. Com protótipos, existe o low-fidelity para expor ao time o senso de como o produto deve funcionar. Já mid and high-fidelity possuem mais detalhes e testam designs em nível de interação, visual e conteúdo similar a experiência do produto final.

Por fim, o Feedback and Research trabalha com inputs dos usuários (contínuos feedbacks) que contribuem para o processo de design, incorporando a iterações de produtos. As principais técnicas são: pesquisa contínua (Continuous Discovery) e colaborativa (Collaborative Discovery), artefatos de teste (Sketches), incorporar a opinião do usuário no ciclo Lean UX (static wireframes, mockups, prototypes), uso de testes A/B e reconciliar feedback de diferentes fontes.

 

3 GERENCIAMENTO ÁGIL

Embora o Lean UX tenha uma recomendação de integração com o Agile, vamos trabalhar com as práticas do framework ágil Scrum para execução do backlog e validação dos produtos que serão desenvolvidos com base nas técnicas citadas anteriormente. O Scrum é fundamentado no empirismo, empregando uma abordagem iterativa e incremental para melhorar a previsibilidade e controle de riscos.

Teremos quatro eventos formais para inspeção e adaptação da Sprint: Planning, daily, review e retrospective. O time será composto do time de desenvolvimento, Product Owner (PO) e Scrum Master (SM). O PO é o responsável por gerenciar o backlog do produto, enquanto o SM é um servo-líder para o time e o time de desenvolvimento realiza o trabalho de entregar uma versão usável do produto (incremento).

A Sprint é um time-boxed de dez dias úteis (em nosso caso) de trabalho para entregar a versão incremental potencialmente utilizável do produto. A Sprint Planning é a reunião colaborativa, que define o backlog a ser feito na Sprint. A Daily possui apenas 15 minutos e serve como inspeção do trabalho desde o dia anterior e o trabalho a ser feito até a próxima Daily.

A Review, executada no final da Sprint, promove a colaboração para identificar ajustes no backlog do produto. E a Retrospective inspeciona o próprio time e cria um plano de melhorias a serem aplicadas na próxima Sprint.

Sendo assim, o backlog do produto relaciona tudo que o produto deve ter, os itens selecionados para a Sprint junto ao plano para entregar o incremento do produto e atingir o objetivo da Sprint são chamados de backlog da Sprint. Por fim, o incremento representa todos os itens completados nas Sprints.

As práticas como burndown e burnup são representações usadas para prever o progresso. Embora muito úteis, não substituem a importância do empirismo e das reuniões mencionadas que contribuem para a inspeção e adaptação do projeto.

 

4 CONSIDERAÇÕES FINAIS

A competitividade no mercado digital propõe inúmeros desafios as empresas que precisam adotar um modelo dinâmico de criação produtos, entregando valor ao usuário e uma boa experiência nesta jornada de compra. Neste estudo, avaliamos as técnicas Lean Inception, Lean UX e Agile (Scrum), com o propósito de criar MVPs (Produto Mínimo Viável) e validar hipóteses no mercado. A experimentação e o aprendizado serviram como direcionadores de investimentos no negócio.

As três técnicas em conjunto contribuíram para criar um modelo de experimentação enxuto e contínuo, trabalhando desde a concepção do produto Admission (sistema de captação de candidatos para converter em matriculas) até a implementação de novas funcionalidades em produção. Escrevemos então a visão do produto, o que ele é e o que ele não é, as personas, jornadas, features e priorizamos de acordo com o valor para o negócio e dificuldade técnica.

Considerando a UX (experiência do usuário) e os feedbacks como imprescindíveis para aprender e ajustar a criação, mudança ou adequação de produtos. O gerenciamento ágil efetiva o time-to-market e o produto idealizado é executado em Sprints (time box de 2 semanas), conforme priorização do backlog. O backlog possui as atividades necessárias para desenvolvimento do produto acordado nas sessões. As reuniões diárias (dailys), retrospectiva, review e a demo são utilizadas para inspecionar o progresso do desenvolvimento e ajustes necessários.

 

REFERÊNCIAS

CAROLI, Paulo. Direto ao ponto: criando produtos de forma enxuta, 2015.

Design Thinking: ferramenta de inovação para empreendedores. Disponível em: <https://endeavor.org.br/tecnologia/design-thinking-inovacao/>. Acesso em: 19 jun. 2018.

Design Thinking 101 –  The Double Diamond Approach. Disponível em: <https://medium.com/seek-blog/design-thinking-101-the-double-diamond-approach-ii-4c0ce62f64c7>. Acesso em: 19 jun. 2018.

GOTHELF, Jeff; SEIDEN, Josh; Lean UX: Applying Lean Principles to Improve User Experience.

Lean Inception. Disponível em: <https://martinfowler.com/articles/lean-inception/>. Acesso em: 07 mai. 2018.

Marketing 4.0: do Tradicional ao Digital, passo a passo. Disponível em: <https://novaescolademarketing.com.br/marketing/marketing-4-0/>. Acesso em: 13 mai. 2018.

Marketing 4.0 – Oportunidades e Tendências. Kotler 2017. Disponível em: <http://www.sebraemercados.com.br/marketing-4-0-oportunidades-e-tendencias-kotler-2017/>. Acesso em: 15 mai. 2018.

Metodologias Ágeis. Disponível em: <https://agilemomentum.wordpress.com/>. Acesso em: 25 jun. 2018.

MVP: entenda as principais vantagens ao utilizá-lo. Disponível em: <http://blog.justdigital.com.br/mvp-entenda-as-principais-vantagens-ao-utiliza-lo/>. Acesso em 23 mai. 2018.

MVP: guia completo do Produto Viável Mínimo. Disponível em: <https://saiadolugar.com.br/mvp/>. Acesso em: 24 mai. 2018.

MVP: O que é e como fazer o produto mínimo viável? Disponível em: <https://conteudo.startse.com.br/para-startups/isabella/mvp-produto-minimo-viavel/>. Acesso em 24 mai. 2018.

RIES, Eric. Lean Startup. Crown Publishing Group, 2011.

Scrum.org. Disponível em: <https://www.scrum.org/>. Acesso em: 02 jul. 2018.

The Differences: Lean Startup vs Agile Methodology. Disponível em: <https://cabforward.com/the-differences-between-lean-startup-and-agile-methodology/>. Acesso em: 14 jun. 2018.

The Lean Startup. Disponível em <http://theleanstartup.com/principles>. Acesso em 11 jun. 2018.

UX Canvas. Disponível em: <https://ucdc.therectangles.com/#why>. Acesso em: 22 mai. 2018.

Lean UX – Book Summary (Applying Lean Principles to Improve User Experience)

Section I: Introduction and Principles

Chapter 1 – Why Lean UX?

Lean UX is the evolution of product design. It takes the best parts of the designer’s tool kit and recombines them in a way that makes them relevant to this new reality.

  • It’s deeply collaborative and cross-functional
  • We can’t continue to ask our teams to wait for us to figure it all out. We need daily, continuous engagement with our teams if we are going to be effective
  • Instead of talking about features and documents, we can talk about what works, and measure (market feedback) what works, learn, and adjust

Lean UX is three things:

  • It’s easiest to understand as a process change for designers
  • It’s a mindset that lets us approach our work in new ways
  • It’s also a way of thinking about managing software

 

Chapter 2 – Principles

Lean UX stands on three foundations

1. The Lean principles underlying Lean Startup apply to Lean UX in these ways:

  • They help us remove waste from our UX design process. We move away from heavily documented handoffs to a process that creates only the design artifacts we need to move the team’s learning forward.
  • Second, they drive us to harmonize our “system” of designers, developers, product managers, quality assurance engineers, marketers, and others in a transparent, cross-functional collaboration that brings nondesigners into our design process.
  • Last, and perhaps most important, is the mindset shift we gain from adopting a model based on experimentation. Instead of relying on a hero designer to divine the best solution from a single point of view, we use rapid experimentation and measurement to learn quickly how well (or not) our ideas meet our goals.

2. Design thinking: takes a solution focused approach to problem solving, working collaboratively to iterate an endless, shifting path toward perfection. It works toward product goals via specific ideation, prototyping, implementation, and learning steps to bring the appropriate solution to light.

3. Agile development philosophies: refocuses software development on value. It seeks to deliver working software to customers quickly and to adjust regularly to new learning along the way.

As you explore the Lean UX approach, keep these principles in mind. Think of your experience with Lean UX as a learning journey. Use these principles to keep you and your team on course:

  • Cross-Functional Teams | Small, Dedicated, Colocated | Progress = Outcomes, Not Output | Problem-Focused Teams | Removing Waste | Small Batch Size | Continuous Discovery | The New User-Centricity | Shared Understanding | Anti-Pattern: Rockstars, Gurus, and Ninjas | Externalizing Your Work | Making over Analysis | Learning over Growth | Permission to Fail | Getting Out of the Deliverables Business

 

Section II: Process

Chapter 3 – Vision, Framing and Outcomes

Describes how Lean UX radically shifts the way we frame our work. The goal is not to create a deliverable, it’s to change something in the world—to create an outcome. And how we can reframe our work in terms of outcomes to search for the best solutions to the problem at hand.

Declaring outcomes, an important process, means to start with the project’s problem statements and then acknowledge our assumptions, then transform these assumptions into hypotheses. Also how to write hypothesis statements that capture intended features, audience, and goals, and that are specific enough to be tested. You’ll end up with statements that will serve as the roadmap for the next step of the Lean UX process: collaborative design.

The hypothesis statement is a way of expressing assumptions in testable form. It is composed of the following elements: Assumptions, Vision, Framing, and Outcomes, Hypotheses, Outcomes, Personas and Features.

And the recommended tools to validate hypotheses are: Business Assumptions Worksheet, Subhypotheses, Outcomes, Personas e Features.

business-assumptions-worksheet

Chapter 4 – Collaborative Design

After written the hypothesis, it’s time to determine what you’ll need to test assumptions.

lean-ux-process

Describes the shift in the design process. Lean UX uses many techniques familiar to designers but shifts the emphasis of work, becoming more collaborative. We aim for speed first. We prioritize learning. We use a key tool to achieve this: the MVP.

It’s shown how the low-fidelity drawings created in Design Studio sessions can help teams generate many ideas and then converge on a set the entire team can get behind. And practical techniques that can be used to create shared understanding, the fundamental currency of Lean UX.

Using tools such as style guides (accessible, continually improved e actionable), Design Studio (example in image below), and simple conversation, your team members can build a shared understanding that allows them to move forward at a much faster pace than in traditional environments.

design-studio-output

 

Chapter 5 – MVPs and Experiments

Lean UX is based on the idea that we begin our work with an assumption. We use experiments to test our assumptions and then build on what we learn in those experiments. This chapter shows you how to orient your design process around experiments and learning.

In this chapter, we defined the Minimum Viable Product as the smallest thing you can make to learn whether your hypothesis is valid. In addition, we discussed the various forms an MVP can take, took a closer look at prototyping, and discussed tactics for learning that don’t require building prototypes. For example:

Low-Fidelity Prototypes: Paper and Clickable Wireframeslow-prototype.png

Mid- and High Fidelity Prototypes
mid-prototype

Hand-coded and live-data prototypes
There are two levels of fidelity for coded prototypes: hand-coded and live data:

  • Hand-coded prototypes: look and function like the end product, but don’t account for any kind of real-time data input, processing, or output. They are still just simulations.
  • Live-data prototypes: will connect with real-time data and process user input. These are often deployed to real customers and offer a level of analytical insight into customers’ usage of the prototype that is not available from hand-coded prototypes. They can also be used when A/B testing certain features or changes to the current workflow.

And finally there are Types of Non-Prototype MVPs as Email, Google Ad Words, Landing Page and the button to nowhere.

Chapter 6 – Feedback and Research

User Experience work in any form requires good input from users. Lean UX puts a premium on continuous feedback to help us guide our design process. This chapter shows techniques that Lean UX teams use to get feedback early and often, and how to incorporate that feedback into future product iterations.

It’s presented many ways to start validating the MVPs and experiments built around hypotheses. The main techniques are: Continuous Discovery, Collaborative Design, Sketches, Onsite Feedback Surveys, incorporate the voice of the customer throughout the Lean UX cycle (static wireframes, mockups, prototypes) and using A/B tests in your research.

And how to build a lean usability-testing process every week and covered what you should test and what to expect from those tests. These techniques, used in conjunction with the processes outlined in Chapters 3 through 5, make up the full Lean UX process loop. Your goal is to cycle through this loop as often as possible, refining your thinking with each iteration.

feedback-research.png

 

Section III: Making it work

Chapter 7 – Integrating Lean UX and Agile

Here will be demonstrated the tactics discussed in Section II and show exactly how they fit into a typical Scrum process and how they make it more effective. First of all, read more about Scrum and be familiar with definitions (user story, backlog, sprint, stand-up, retrospective, planning meeting).

Building Lean UX into the Rhythm of Scrum

Themes: many people frown on Scrum meetings, but if you use them as mileposts during your sprint, you can create an integrated Lean UX and Agile process in which the entire team is working on the same thing at the same time.

Kickoff Sessions for Sketching and Ideation: each theme should be kicked off with a series of brainstorming and validation exercises like the ones described in Section II. The point of this kickoff is to get the entire team sketching and ideating together, creating a backlog of ideas to test and learn from.

Iteration Planning Meeting: the output of the kickoff session should be brought to the IPM. You made the artifacts (sticky notes, sketches, wireframes, paper prototypes) together and because of that, you have the shared understanding necessary to extract stories from them. Then evaluate and prioritize the stories.

User Validation Schedule: to ensure a constant stream of customer voices to validate against, plan user sessions every single week. Your team will never be more than five business days away from customer validation but still your ideas will have ample time to react prior to the end of the sprint. Use the artifacts you created in the ideation sessions as the base material for your user tests. Remember that when the ideas are raw, you are testing for value (i.e., do people want to use my product?). Once you have established a desire for your product, subsequent tests with higher fidelity artifacts will reveal whether your solution is usable.

lean-ux-rhythm-of-scrum

In addition, we can see how cross-functional collaboration allows a team to move forward at a brisk pace and how to handle those pesky stakeholders and managers who always want to know what’s going on.

 

Chapter 8 – Making Organizational Shifts

In this chapter, we’ll discuss the following changes your organization may need to make in these areas. It’s not just software developers and designers who need to find a way to work together. Product managers, project managers—in short, your whole product development engine—is going to need to change if you want to create a truly Agile organization.

  • Shifting from output to outcomes
  • Moving from limited roles to collaborative capabilities
  • Embracing new skills
  • Creating cross-functional teams
  • Creating small teams
  • Creating open, collaborative workspaces
  • Not relying on heroes
  • Eliminating “Big Design Up Front”
  • Placing speed first, aesthetics second
  • Valuing problem solving
  • Embracing UX debt
  • Shifting agency culture
  • Working with third-party vendors
  • Navigating documentation standards
  • Being realistic about your environment
  • Managing up and out

organization-Lean_UX.png