Inovação contínua – Design Thinking, Lean Startup, Agile e DevOps

Não somente as Startups, mas diversas empresas tem adotado o modelo Spotify (ou outros modelos), para ajudar na estruturação de times multifuncionais e orientados a produtos “produtizados”, afim de trabalhar na entrega de valor contínua aos clientes. Tudo isso, certamente em virtude de uma estratégia organizacional que desdobra ações para atingir seus principais objetivos, tais como aquisição de novos clientes, ROI, retenção, NPS (Net Promoter Score), etc.

squads

O livro Lean Enterprise – Enabling Innovative Culture traz conceitos fundamentais para melhorar a visão de negócio e criar um modelo de experimentação / validação de hipóteses na empresa. Assim como o livro The Lean Startup que aborda o Value Vs. Waste, onde o Lean thinking “define valor como um benefício para o cliente; qualquer outra coisa é desperdício”.

Se a reestruturação tem ocorrido da melhor forma? Em outros posts, acrescento conteúdos de Value Streams, Business Agility e gestão de dependência entre os times para complementar esses temas. O acordo por enquanto é que o processo de inovação engloba a cultura de aprendizado, pessoas colaborativas e experimentação – ou seja, modelar uma hipótese, testá-la rapidamente, aprender/ajustar e tentar novamente.

build-measure-learn-loop

Para isso, muitas empresas precisam de uma engrenagem que conduz o ciclo completo, desde a concepção até a entrega dos produtos (introduction – growth – maturity – decline) e entregar o produto que as pessoas precisam e querem comprar, termo conhecido como product / market fit. É isso que vamos falar mais adiante nesse post.

Antes de escolher o seu toolbox ou as melhores metodologias, verifique a aplicabilidade delas, mediante o seu contexto. O Cynefin Framework é utilizado para entender e distribuir os projetos e portfólios no domínio de acordo com a sua complexidade. Esse é o caminho inicial para avaliar o uso das melhores práticas, em meio a análise estratégica.

cynefin-framework

time to value é quando os clientes começam a perceber o valor em seus produtos, podendo utilizar e se beneficiar da inovação. O ideal é poder inovar e entregar continuamente. Por isso, muitas organizações estão mudando sua abordagem de “projeto” para “gerenciamento de produto”. Entre as principais diferenças:

project-manager-vs-product-manager

E como orquestrar as fases compreendidas no processo de inovação? Ao criar novos produtos, em geral, ainda não existem hipóteses validadas com dados reais para análise e revisão. A construção da Value Proposition declara os principais motivos pelos quais seus produtos/serviços satisfazem as necessidades dos clientes.

Com essa visão do produto, da estratégia, customer understanding e product execution, algumas abordagens foram criadas para representar os ciclos iterativos e experimental, oriundos de práticas como Design Thinking, Lean Startup, Lean UX, Agile, Growth Hacking e DevOps. A ideia é conectar desde a concepção das ideias até a liberação dos produtos aos usuários. Façam seus comentários e quais ajustes são aplicados em sua organização para os modelos abaixo:

design-thinking-lean-agile-growth-hacking

Um breve resumo sobre cada fase:

Discovery e Inception
Traz abordagens de criação de produtos e soluções inovadoras para os problemas. Será discutido o problema do cliente a ser resolvido, valor entregue do produto,  abordagens de customer acquisition, MVP (Minimum Viable Product) e customer understanding (como os clientes vão interagir com o produto – jornadas, personas, pesquisas, funcionalidades e métricas de validação).

O Design Thinking busca de forma colaborativa (com pessoas ao centro do desenvolvimento do produto) encontrar soluções inovadoras para os problemas. O foco está em necessidades do mercado, e não em pressuposições estatísticas. Utiliza 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-II

Lean Startup
Criação de um modelo dinâmico para 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.

O modelo Build-Measure-Learn Feedback Loop habilita 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-startup


Agile
Utiliza abordagem incremental e iterativa. A cadência baseada em Sprints maximiza as oportunidades para feedback e previsibilidade, entregando um incremento potencialmente liberável do produto “Pronto”.

Entre alguns benefícios da gestão ágil:

  • Visibilidade: visibilidade e transparência durante todo o ciclo.
  • Adaptabilidade: planejamento iterativo torna fácil a adaptação em caso de mudança de requisitos.
  • Business Value: o planejamento e feedback contínuo trazem entrega de valor desde o início do projeto.
  • Risco: e assim diminuem os riscos associados ao desenvolvimento.

dad-safe-scrum

DevOps
A habilitação de DevOps é fundamental na transformação digital e entregas contínua com atuação nos pilares pessoas, processos e produtos. As práticas essenciais do DevOps incluem planejamento ágil, integração contínua (CI), entrega contínua (CD) e monitoramento de aplicativos.

O termo pipeline é muito utilizado em DevOps, pois é onde está o foco em automatizar os processos e garantir a entrega contínua de aplicações em produção com eficiência e confiabilidade. O Fluxo de valor cobre desde a concepção do produto até a geração de valor para a empresa.

As práticas DevOps são essenciais para criar o pipeline de implantação, disponibilizando novas versões de software o tempo todo ao cliente. O Feedback contínuo vai guiando a estratégia da empresa, eliminando barreiras entre os departamentos. Isso permite a colaboração entre as pessoas para gerar valor ao cliente.

principios-derivados

Growth Hacking
É o marketing orientado a experimentos, ou seja, o Growth Hacking é uma prática que promove o crescimento acelerado, através da descoberta de gatilhos. Visa encontrar oportunidades/brechas (hacks) e criar estratégias de resultados rápidos para o crescimento (growth) da empresa.

O Growth Hacking é totalmente focado na experimentação, seguindo o funil  de Dave McClure – AARRR (Acquisition – Activation – Retention – Revenue – Referral) Pirate Funnel Metrics.

AARRR

Como o funil do Growth Hacking não tem demarcação de fronteira, para alguns produtos/serviços a Retention e Revenue podem andar juntas. Por exemplo, quando o cliente continua utilizando algum serviço e continua pagando (receita). Identifique em quais estágios estão os problemas de maior urgência. É um bom meio de começar a aplicar o Growth Hacking. Em resumo, o processo compreende:

  • Geração de ideias
  • Seleção de ideias
  • Modelagem de experimentos
  • Realização de experimentos
  • Análise de resultados
 
 
Leitura recomendada

Priorização de requisitos e projetos – product management

Com a evolução contínua no modelo de negócios, onde as empresas precisam de adaptação rápida e time to market, um bom critério de priorização é primordial para avaliar os projetos (ou requisitos dos times) e evitar desperdícios, além de maximizar ao máximo a entrega de valor ao negócio.

Muitas empresas ainda estão viciadas no ciclo de receber/trabalhar/entregar muita demanda, porém isso entrega valor ao negócio? E quanto aos critérios de priorização? Desta forma, vamos abordar algumas técnicas de priorização que ajudam a direcionar o esforço das equipes, baseado em critérios.

Outro ponto é a aplicabilidade. As técnicas abaixo foram criadas com um propósito específico (a serem utilizadas em projetos ou requisitos), mas podem ser adaptadas a outros níveis (time, programa ou portfólio). Também vale avaliar se o mercado é B2C ou B2B, pois a validação de hipóteses com os usuários finais podem gerar indicadores que servem como critério de priorização (tais como conversão, churn, uso, etc.).

MoSCoW

O MoSCoW (Must haveShould haveCould have and Won’t have) é uma das técnicas de priorização, geralmente utilizada com timeboxing – deadline fixado e o foco é nos requisitos mais importantes. Ajuda a comunicar o que será feito de imediato ou não.

  • Must Have (Deve Ter): são as funcionalidades imprescindíveis para o projeto. Devem ser refinadas (ou aprofundadas) para melhorar o entendimento do time.
  • Should Have (Deveria Ter): é importante ter, mas não são imprescindíveis.
  • Could Have (Poderia Ter): seria bom ter, mas não são essenciais. Porém, entregá-las pode ser um diferencial ao cliente.
  • Won’t Have for Now (Não Terá por Enquanto): por hora não será feito, já que não gera valor ao negócio naquele momento.

moscow

RICE

Outro acrônimo para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e divididos pelo último. Isso ajuda a medir o impacto de cada tarefa no todo e a determinar a prioridade mais alta do backlog.

Fórmula: R * I * C / E

  • Reach: qual o alcance desta tarefa (pessoas impactadas)?
  • Impact: o grau do impacto nas pessoas
    • Impacto Massivo: 3
    • Grande Impacto: 2
    • Médio: 1
    • Baixo: 0,5
    • Impacto Mínimo: 0,25
  • Confidence: quão confiante estamos nas estimativas
    • Alta confiança: 100%
    • Confiança média: 80%
    • Baixa confiança: 50%
    • Mínima confiança: 20% ou menor
  • Effort: o tempo necessário para concluir a tarefa

BASICO

A BASICO possui seis critérios que apoiam a priorização de projetos e processos. Cada critério é pontuado de 1 a 5 e o resultado é a soma dos critérios (1 = pior cenário; 5 = melhor cenário). As maiores notas são priorizadas.

  • Benefícios para a empresa
  • Abrangência dos resultados
  • Satisfação do cliente interno
  • Investimento necessário
  • Cliente externo satisfeito
  • Operacionalidade simples

GUT

Outra opção é a GUT que possui três critérios e pontuação de 1 a 5 também para classificar a prioridade dos projetos.

  • Gravidade: classifica as ações que você precisa realizar conforme o impacto que elas terão em outras atividades ou projetos;
  • Urgência: considera o tempo restante para resolver cada situação;
  • Tendência: é uma projeção da velocidade que um problema não resolvido pode levar para piorar.

gut

WSJF (Weighted Shortest Job First)

A técnica WSJF, criada por Don Reinertsen e recomendada no SAFe, apoia a priorização de features, maximizando o custo do atraso (COD – Cost of Delay) e a duração do trabalho. E assim, em regra geral:

  • Features com a mesma duração = priorizar as que possuem maior custo do atraso, pois assim minimizaria o custo total.
  • Features com o mesmo custo de atraso = priorizar as que podem ser lançadas mais rapidamente, pois assim minimizaria o custo do atraso.

Como o custo do atraso e duração das features podem variar muito de uma para outra, o WSJF contribui muito na priorização com a seguinte fórmula:

  • WSJF = Cost of Delay / Job Duration (Job size)

E o custo de atraso é calculado da seguinte forma:

  • Cost of Delay = User Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

WSJFFonte: SAFe (Scaled Agile Framework)

Technical Certainty x Business Agreement

Entre as diversas matrizes que existem para priorização de requisitos, a matriz da Tech and Business Review da Lean Inception é uma que sintetiza bem o valor do negócio x esforço para construção das features. Possui nove quadrantes.

  • Technical Certainty: como o time de desenvolvimento avalia a complexidade para criar a funcionalidade.
  • Business Agreement: quão bem o negócio concorda com o que entra na feature.

As features de certeza técnica baixa (E) e valor de negócio baixo ($) são descartadas do MVP de imediato. Assim como, certeza técnica média (EE) e valor de negócio baixo ($); também são descartadas as features do quadrante certeza técnica baixa (E) e valor de negócio médio ($$). As demais serão avaliadas conforme a técnica da Lean Inception.

business-effort-matriz

Outras técnicas

  • Modelo Kano
  • QFD (Quality Function Deployment)
  • Opportunity Scoring
  • Buy a feature
  • Matriz de Eisenhower (Urgência X Importância)
  • Matriz Esforço x Impacto
  • Matriz de Custo x Benefício

Leitura recomendada

Bimodal TI e Gartner

Com a dinâmica do mundo digital, as organizações precisam evoluir constantemente seus processos internos, adequando a velocidade de entrega com a expectativa de novas releases aos usuários. Outro ponto é a estabilidade dos ambientes, uma black friday, por exemplo, prejudicada por indisponibilidade ou erro em deploy, certamente irá comprometer o resultado financeiro daquele ano.

O Bimodal é a prática de gerenciar estes dois estilos de trabalho separados, mas coerentes – um focado em previsibilidade e o outro em exploração. Ambos são essenciais para a geração de valor e mudança organizacional significativa. Nenhum deles é estático. A essência da capacidade bimodal está em combinar a evolução mais previsível de produtos e tecnologias (modo 1) com o novo e inovador (modo 2).

  • Modo 1: é direcionado a áreas mais previsíveis e bem compreendidas. Concentra-se na exploração do conhecido e abordagem linear de mudanças com ênfase em previsibilidade, estabilidade, precisão e confiabilidade.
  • Modo 2: otimizado para as áreas de incerteza e experimentação para resolver novos problemas. As iniciativas geralmente baseiam-se em hipóteses que são validadas e adequadas conforme necessário.

Em pesquisa realizada por Gartner, o gerenciamento da incerteza (capacidade de mover adiante mesmo quando o futuro é incerto) é fundamental para o sucesso na era digital. Mais de 40% das organizações descrevem já ter iniciado esta jornada, assim como 3/4 das organizações já estariam em algum nível de maturidade do Bimodal em 2017.

Entre as principais vantagens do modelo Bimodal estão:

  • Promover a inovação na empresa, mesmo em cenários que exigem estabilidade e predominância de sistemas legados
  • Adequar a área de TI como estratégica, permitindo a organização manter-se competitiva no mercado
  • Em pesquisa da Red Hat, 70% dos entrevistados acreditam que o bimodal apresenta maior agilidade em relação ao modelo tradicional
  • E também 44% perceberam redução no time to market

Outro ponto é a gestão e comunicação do modelo Bimodal para não criar bifurcação ou desentendimento do propósito. A interação de posições operacionais com projetos de inovação pode ser bem vista do ponto de desenvolvimento e engajamento dos colaboradores, além de ajudar a manter todo o stack tecnológico atualizado.

Por fim, considere o apoio e patrocínio onipresente para a mudança, devido as mudanças significativas nas políticas internas e na forma como os recursos serão gerenciados. O engajamento da equipe e parcerias estratégicas também são imprescindíveis nesta implementação.

Três diferenças da gestão tradicional e ágil

Como os projetos são gerenciados na sua organização? Qual o melhor modelo de gestão? Tradicional, ágil ou híbrido? Este tipo de discussão já não é nenhuma novidade em eventos,  artigos, treinamentos e internamente nas empresas. Ambos trazem ótimos resultados, claro que o contexto e a aplicabilidade são determinantes para eleger o que utilizar dentro do seu ambiente.

Os métodos ágeis ganharam notoriedade há algum tempo na área de gestão de projetos e desenvolvimento de sistemas, vide a necessidade de time to market e adaptação as mudanças (principalmente na forma em fazer negócios). E assim, a adoção de modelos que habilitam estas mudanças na mesma intensidade estão sendo cada vez mais alavancados dentro das organizações.

Além dos valores do manifesto ágil, outros princípios como teamworktime boxing,  colaboração e a flexibilidade para responder a mudanças rapidamente são abordagens importantes utilizadas em desenvolvimento de sistemas. O planejamento iterativo e incremental, dividido em Sprints, caracteriza períodos de trabalho curtos e inspeção frequentes para melhorar a previsibilidade e controle de riscos.

Já na gestão de projetos tradicional, o ciclo sequencial, composto das fases de iniciação, planejamento, execução, monitoramento/controle e encerramento, enfatiza o processo linear, documentações e o upfront planning. A tríplice restrição em projetos tradicionais é estruturada com o tempo e custo variáveis, já o escopo fixo (com alterações via change request). O PMBOK descreve as principais técnicas e ferramentas utilizadas por gerente de projetos.

Após esta breve contextualização da Gestão Ágil e Tradicional, compartilho abaixo três diferenças que considero determinante:

1. Tradicional x Ágil: principais características

Entre as características de cada gestão (figura abaixo), pode-se destacar a definição dos requisitos e o escopo que de um lado (tradicional) exige maior esforço no início do projeto, e por outro lado (ágil) ao longo do projeto com possibilidade de ajustes contínuos.

agil-tradicional-01

2. Tríplice restrição: escopo, tempo e custo

A tríplice restrição é outro aspecto que caracteriza a Gestão Tradicional e Ágil de forma bem distinta. Se na gestão tradicional, o escopo é fixo, tempo e custo são variáveis, na gestão ágil, o tempo e custo são fixos, e o escopo é variável (continuamente refinado e discutido nas cerimônias).

waterfall-agil

3. Build Incrementally: Accelerate Value

Tradicional

  • Estágios lineares e sequenciais
  • Planejamento no início e documentação detalhada
  • Envolvimento do negócio no início e no final

Incremental Delivery

  • Ciclos contínuos
  • Times colaborativos, pequenos e alto desempenho
  • Desenvolvimento incremental
  • Evolução contínua
  • Envolvimento do negócio do começo ao final

waterfall-agil-01

Em outra visão comparativa dos gráficos abaixo:

  • Visibilidade e transparência em todo o ciclo.
  • Adaptabilidade: em métodos ágeis, o planejamento iterativo facilita a adaptação em caso de mudança de requisitos.
  • Business Value: o planejamento e feedback contínuo trazem entrega de valor desde o início do projeto em gestão ágil. No modelo tradicional, o compromisso maior é com o cumprimento do plano.
  • Risco: os built-in controls, utilizados em gestão ágil, minimizam o risco de produzir desperdício.

agile-customer-needs

Alguns números interessantes sobre o esforço despendido em elaboração de requisitos, mudanças em relação ao escopo e utilização das features colocadas em produção (que raramente são utilizadas).

caracteristicas-projetos.png

Conclusão

Por fim, observamos que ao utilizar a gestão tradicional (waterfall), os requisitos são bem detalhados na fase inicial do projeto, possuindo um maior custo de mudança. É recomendável para projetos de baixa incerteza nos quais a solução já é conhecida (poucas mudanças de escopo) ou quando não faz sentido implementações incrementais, por exemplo, em sistemas com módulos altamente dependentes.

Por outro lado, a Gestão Ágil, segundo pesquisa, destaca-se nos seguintes aspectos:

beneficios-agil

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

 

DevOps e ligação com Scrum e SAFe

Neste post você encontra um resumo da ligação do DevOps com outras práticas, tais como: Scrum, SAFe, Extreme Programming (XP), Lean, Kaizen, Kanban, ITIL e Infrastructure as code.

Manifesto Ágil

O manifesto ágil não inclui entre os doze princípios a colaboração de Ops. O The Agile Admin entende ser em função do tempo, pois há dez anos atrás, a maioria das aplicações eram desktop. Também não menciona nada sobre a última parte do pipeline de entrega de software (onde as aplicações são publicadas e mantidas em produção).

manifesto-agilE assim, foi criado o Manifesto DevOps por Jez Humble:manifesto-agil-principios-01manifesto-agil-principios-02

Agile addresses perfectly customer’s needs

  • Visibility: visibilidade e transparência durante todo o ciclo.
  • Adaptability: planejamento iterativo torna fácil a adaptação em caso de mudança de requisitos.

  • Business Value: o planejamento e feedback contínuo trazem entrega de valor desde o início do projeto.
  • Risk: e assim diminuem os riscos associados ao desenvolvimento.

agile-customer-needs

Os dois princípios derivados:

1. Automatize quase tudo

  • Processo de Build até o ponto onde é necessário intervenção humana
  • Processo de deployment
  • Testes de aceitação
  • Upgrades and downgrades de base de dados
  • Infra estrutura e até mesmo configurações de rede e firewall

2. Mantenha tudo que for necessário para o build, deploy, testes e release em seu controle de versão.

Create a Repeatable, Reliable Process for Releasing Software

releasing software should be easy (as simple as pressing a button), because you’ve tested every single part of the release process many times before”.

principios-derivados

SCRUM

É um framework para desenvolver, entregar e manter produtos complexos. Consiste de times Scrum associados a papéis, eventos, artefatos e regras. Os três pilares são transparência, inspeção e adaptação. E os cinco valores são comprometimento, coragem, foco, transparência e respeito.

scrum.png

  • Time Scrum:  auto organizáveis e multifuncionais. É composto do Product Owner, Time de Desenvolvimento e Scrum Master.
  • Eventos: todos os eventos são time-boxed. São eles: Sprint, Planning, Daily, Review e Retrospective.
  • Artefatos: Backlog do Produto, Backlog da Sprint e Incremento.

As práticas como burn-downs, burn-ups, ou fluxos cumulativos são utilizadas para prever o progresso.

Take an economic view: increase value
O Scrum emprega uma abordagem incremental e iterativa, maximizando as oportunidades para feedback e previsibilidade. Ao final de cada Sprint, o time de desenvolvimento entrega um incremento potencialmente liberável do produto “Pronto”.

economic-view-scrum

Os built-in controls minimizam o risco de produzir desperdício e falta de progresso:

  • Eventos
  • Inspeções
  • Guardião Scrum (Scrum Master)
  • DoD (definition of done)

Entre os benefícios estão:

  • Maior frequência de entregas de valor
  • Maior visibilidade nas tarefas que estão sendo concluídas
  • Maior capacidade de adaptação às mudanças
  • Maior alinhamento com prioridades do negócio (tanto no planejamento quanto na execução)
  • Maior foco na qualidade por time box
  • Maior previsibilidade em time boxes menores
  • Maior compreensão dos riscos, incertezas e impedimentos
  • Maior foco na redução de desperdícios

SAFe (Scaled Agile Framework)

SAFe é um framework para trabalhar com ágil em larga escala que sincroniza alinhamento, colaboração e entrega para grande número de times. Também reflete em pensamento Lean-Agile e práticas DevOps. Os valores fundamentais são:

  1. Built-in Quality: “you can’t scale crappy code”
  2. Program Execution: product portfolio
  3. Alignment
  4. Transparency

SAFe-blueprint.png

SAFe principles:

#1 – Take an economic view
#2 – Apply systems thinking
#3 – Assume variability; preserve options
#4 – Build incrementally with fast, integrated learning cycles
#5 – Base milestones on objective evaluation of working systems
#6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths
#7 – Apply cadence, synchronize with cross-domain planning
#8 – Unlock the intrinsic motivation of knowledge worker
#9 – Decentralize decision-making

Diagrama de Kano

No último post, abordamos os desafios organizacionais em entrega contínua – time-to-market e exponencial, e conceitos importantes das organizações exponenciais, tais como  PMT (Propósito Máximo de Transformação) e Value Vs Waste.

Ainda sobre os conceitos de crescimento exponencial e entrega contínua de valor, o Diagrama de Kano, famosa teoria de  desenvolvimento de produtos e satisfação do cliente, encoraja a abordagem “menos é mais”.

O ponto é que a adição de novos recursos (para um produto) pode ser dispendiosa e apenas aumentar a complexidade sem aumentar a satisfação do cliente. Então, o Diagrama de Kano ajuda a categorizar e priorizar os diferentes atributos de desempenho de um produto ou serviço.

diagrama-kano.jpg

Esta análise é muito poderosa para a priorização, pois ajuda a identificar o nível de importância de cada funcionalidade para o seu cliente. Entre as categorias de desempenho estão:

  • Funcionalidades Obrigatórias: normalmente o cliente já considera como parte do produto ou serviço. A ausência destas funcionalidades deixa o cliente insatisfeito ou sem sentido o uso.

  • Funcionalidades Lineares: a satisfação do cliente é proporcional à quantidade de funcionalidades disponíveis. E assim, a satisfação do cliente é maior com mais funcionalidades deste tipo.
  • Funcionalidades Atrativas: influenciam mais na satisfação do cliente, porém dificilmente são explicitados pelo cliente. Representam um diferencial para a fidelização do cliente, pois proporcionam uma maior satisfação.

Pergunte aos clientes o que realmente eles valorizam. Um brainstorming de todos os recursos (do produto ou serviço) é uma boa dinâmica, classificando em:

  • Must to have
  • Quanto mais melhor
  • Atributos encantadores
  • Não relevante

Em suma, vimos como o Diagrama de Kano pode ajudar na priorização do desenvolvimento de novas funcionalidades. Em organizações que vivem transformação digital, com entregas contínuas de valor (benefícios obtidos com DevOps), isso é essencial para colocar no pipeline funcionalidades que aumentam a satisfação do cliente.

Transformação digital – análise e tendências

Neste artigo vou compartilhar um pouco do que tenho visto em fóruns, eventos e cases de empresas sobre transformação digital. O objetivo aqui é relacionar os principais pontos de estruturação da mudança e o propósito de realização na empresa.

CONCEITOS INICIAIS
Em suma, a transformação digital é vista nas organizações como a mudança que utiliza tecnologias e modelos de negócios para alavancar o desempenho da empresa e a experiência do cliente. O foco é na melhoria estratégica, desempenho financeiro e resposta à ruptura digital. Atualmente, também há muita relação com o poder de gerar mudanças com tecnologias poderosas como big data, mobile, IoT, IA (inteligência artificial), etc.

Existem diversas leituras e cases de implementação digital nas empresas. Um dos pontos centrais é a mudança organizacional, considerando o por que transformar, o que deve ser feito e como fazer as mudanças necessárias. Outro ponto é o time-to-market e a disrupção nas empresas, permitindo entregar valor continuamente aos clientes. Por fim, o contexto e a maturidade da organização são bem considerados em transformações.

livros-transformacao-digital.png

MUDANÇA ORGANIZACIONAL

  • Por que transformar? Há inúmeros motivos e cada empresa possui uma razão mais clara, desde o aprimoramento de serviços ao diferencial competitivo (como em serviços inovadores).
  • O que deve ser feito: entre os temas que ganham prioridade na cadeia de valor organizacional – o modelo de negócios, os processos, as pessoas, a estrutura, os produtos (ofertas) e o engajamento.
  • Como fazer: a “agilidade digital de negócios” vem sendo a principal capacidade de desenvolvimento nas organizações. É composta por três componentes:
    • Consciência das tendências: capacidade de reconhecer tendências futuras que impactarão a organização. O caso da Blockbuster, por exemplo, ficou bem conhecido por não ter detectado a mudança para streaming de vídeo como uma alternativa aos DVDs.
    • Tomada de decisão informada: capacidade de analisar ativamente as informações coletadas nas tendências (analytics, redes sociais, etc.). Adotar uma boa infraestrutura (cloud, etc.) e governança apoiam na colaboração e gerenciamento do conhecimento.
    • Execução rápida: a capacidade de execução rápida, criando a cultura de aprendizado contínuo (mais tolerante a falhas). Os conceitos de DevOps, métodos ágeis e MVPs (produto mínimo viável) são bem aplicáveis. Também deve ter prioridade a quebra de silos e burocracia organizacional.


OUTROS ASPECTOS

O livro “Transformação Digital: repensando o seu negócio para a Era Digital” (David L. Rogers) relaciona 5 domínios estratégicos em mutação para observarmos mais de perto – clientes, competição, dados, inovação e valor.

O i-scoop traz alguns conceitos do desenvolvimento de habilidades core em várias áreas de negócio (relacionadas no desenho abaixo), conectando os pontos e superando os silos internos em direção aos objetivos. O Digital Disruption (também no desenho abaixo) traz uma visão holística da transformação digital com várias fontes de disrupção, colocando aspectos como customer experience, evoluções tecnológicas e inovação com um propósito claro são elementos cruciais.

A pesquisa da Capgemini traz alguns mitos sobre a transformação digital:

Mito Realidade
Tudo se resume a customer experience Existem oportunidades em eficiência, produtividade e pessoas
Digital é principalmente para empresas de tecnologia ou B2C Oportunidades existem em todas as indústrias, sem exceção
A transformação digital irá acontecer independente da TI A relação entre TI e negócios é chave de sucesso e deve ser melhorada
A transformação vem de iniciativas pequenas A transformação precisa vir do topo para ter entendimento claro do que é esperado nesta transição

ANÁLISE & IMPACTO
O relatório The Global State of Digital do Hootsuite, revela o impacto da transformação digital em 2019 nas atividades dos consumidores no Brasil:

  • 61% usam mobile banking
  • 38% usam meios de pagamento mobile
  • 45% realizam compras online utilizando o mobile

Já o Business Insider, demonstra que mais de 85% das interações com clientes serão gerenciadas por chatbots até 2020, um aumento expressivo da inteligência artificial. Em pesquisa patrocinada pela Dell Technologies, algumas iniciativas foram mencionadas com o apoio de alavancagem:

  • 67% utilizam a tecnologia digital para acelerar o desenvolvimento de novos produtos e serviços
  • 53% adotam o desenvolvimento ágil
  • 70% possuem iniciativas de desenvolvimento das habilidades necessárias para a força de trabalho
  • 63% compartilham conhecimento entre as funções

Em pesquisa realizada por Gartner, envolvendo 460 executivos, demonstra que 62% possuem iniciativas para transformar o negócio mais digital. Em outra pesquisa, de Grant Thornton, revela que mais de 2/3 dos CFOs e executivos financeiros seniores, planejam aumentar o investimento em tecnologia para acelerar a mudança no negócio.

This slideshow requires JavaScript.

A pesquisa da Forrester revela que 46% dos entrevistados acreditam que ao menos metade da receita será influenciada por Digital até 2020. Já o Fórum Econômico Mundial sugere que o valor da transformação digital para a sociedade e indústria pode atingir cerca de $ 100 trilhões até 2025. Outra pesquisa, feita pela IDC:

API-IDC


TENDÊNCIAS PARA 2019
Em pesquisa realizada por Gartner, a transformação digital passa a ser mainstream e lidera entre as prioridades dos CIOs para 2019, sendo que 33% das empresas nas etapas de escala ou refino de maturidade. Apenas 4% das empresas não terão iniciativa digital  para este ano. Entre as principais iniciativas:

  • Adoção da cultura data driven
  • Marketing – estímulo a experimentação e tolerância ao risco
  • Inteligência Artificial
  • Empoderamento de equipes – com times multidisciplinares para acelerar a entrega de produtos de alto valor

Definição de pronto – DoD (Definition of done)

Neste post vamos falar sobre a Definição de pronto, também conhecida como DoD (Definition of Done). Ao adotarmos métodos ágeis, este é um conceito-chave, pois ao final de cada iteração, um incremento de produto deve estar pronto pelo time. No Scrum, por exemplo, o pilar de transparência*, menciona que “aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do trabalho devem compartilhar uma definição comum de Pronto”.

* os três pilares que apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação

incremento

Definição de pronto
O Scrum então resume os principais aspectos a serem considerados na DoD:

  • Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa, pois será usado pelo time para assegurar quando o trabalho está completado no incremento do produto.
  • Ela orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint.
  • Como o time de desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo imediatamente.
  • Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.
  • Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.

Considerando todos os itens mencionados acima, o desenho abaixo representa um resumo para a definição de pronto :

pronto

E alguns exemplos utilizando a Definição de Pronto:

dod-exemplos

Por fim, a Definição de Pronto traz benefícios ao seu ambiente de trabalho por aumentar a transparência previsibilidade dos incrementos. Entre os principais, podemos destacar:

  • Todos interessados sabem exatamente o que significa um produto pronto
  • As entregas passam a ser mais previsíveis
  • Serve como um acordo entre o PO e time desenvolvimento
  • Ajuda a assegurar que o incremento esteja em condições de ser liberado para produção ao final da iteração
  • Ajuda o time no planejamento da sprint