Modelo de maturidade do Kanban e STATIK

No último post, compartilhei um Overview do Kanban com os conceitos, práticas, cadência, métricas entre outros. Neste aqui, vou adicionar outros dois importantes conceitos: o Modelo de maturidade do Kanban para avaliar como está sua organização e STATIK (Abordagem pensamento sistêmico para iniciar o Kanban) para ajudar na implementação do Kanban.

Modelo de maturidade do Kanban
O Kanban Maturity Model (KMM) é uma ferramenta de avaliação que apoia as organizações em melhorias utilizando o método Kanban.

  • ML0: necessita de alinhamentos. A baixa maturidade também é caracterizada pela falta de métricas, CFD, etc.
  • ML1: trabalho visível com foco em serviços. São características deste nível: melhoria no processo, transparência, colaboração e engajamento.
  • ML2: a transição caracteriza-se pela maturidade no fluxo de valor que direciona a priorização. O foco é no time.
  • ML3: foco no cliente (não importa a estrutura). O fluxo de valor influencia a estrutura (e não o contrário).

kanban-maturity-model.png

STATIK (Systems Thinking Approach to Introduce Kanban)
Abordagem pensamento sistêmico para iniciar o Kanban.

statik

1. Entender o que faz um serviço ser ajustado ao propósito do cliente
Expectativa e propósito do cliente – Livro Fit for purpose (Alexei Zheglov).

2. Entender a origem das insatisfações do processo atual
Levantar as insatisfações internas e externas e causa raiz.

3. Analisar a demanda
Natureza da demanda, o que precisa ser entregue, origem da demanda, volumetria, sazonalidade, etc.

4. Analisar a capacidade
Histórico para cada tipo de demanda. O CFD (Cumulative Flow Diagram) por exemplo, visualiza a capacidade de entrega.

5. Modelar o fluxo de trabalho
Analise o workflow (ticket – por onde passa para ser entregue).

6. Descobrir Classes de Serviço
Expedite, Fixed-date e Normal.

7- Projetar o sistema Kanban
Defina o sistema visual (quadro, etapas, cartão, cadências, etc.). Precisa refletir o melhor modelo para o Delivery

8- Socializar o design e negociar a implementação
Na falta de capital político, etc.

Overview Kanban – WIP, Throughput e Lead Time

Os conceitos iniciais de Kanban, produção empurrada e puxada em sistemas de TI surgiram há bastante tempo como um meio para suportar o “Just in Time” (método de produção da Toyota). O Kanban de produção e de requisição se tornaram os mais importantes neste período.

  • 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. Atualmente, os conceitos de Kanban são amplamente utilizados na área de TI, entre as principais razões:

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

kanban-board

Lean Kanban
A adoção do Lean combina as duas práticas para fornecer valor e trabalho criativo o mais rápido possível. O foco é maximizar a entrega de valor, definido pelo cliente. O Fluxo de Valor (Lean Thinking), um dos princípios Lean, ajuda a identificar as etapas que agregam valor ao produto. Os desperdícios devem ser eliminados. E a pergunta que fica é: sua equipe está trabalhando muito, mas entregando valor?

Entre as principais características:

  • Baby Steps: forma ágil de lidar com mudanças
  • Menos resistência
  • Resultados mais rápidos
  • Maior engajamento e confiança na transição
  • Foco no modelo de transição
  • Design do processo sob medida
  • Mudança incremental evolucionária
  • Alcance em toda a empresa
  • Melhoria Contínua

Começando com o Kanban na sua empresa
Como o Kanban não é prescritivo, a ideia é progredir começando com o que você já faz hoje. Isso significa utilizar os papeis e técnicas existentes, implementando mudanças evolutivas e incrementais, focadas em valor. O livro Scrumban do Corey Ladas é uma leitura adicional recomendada.

Concorde em buscar a mudança evolucionária (Kaizen), encorajando a mudança. Alguns princípios da ToC (Theory of Constraints)* também são utilizados neste contexto. Encoraje atos de liderança em todos os níveis da sua empresa. O proto-kanban é outro conceito que sugiro ser aprofundado para fortalecer que os indivíduos vejam gradualmente o ganho de cada prática do Kanban em seu dia a dia.

* a corrente de valor deve ser balanceada de acordo com o seu gargalo.

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 (Work in progress)
O WIP é o trabalho em progresso, ou seja, o que está em execução naquele determinado ponto do processo. Ele é importante no Kanban por sinalizar o número de tarefas em andamento e capacidade de entrega do time. O tamanho do WIP precisa ser adequado e está mais relacionado a expectativa do cliente com a entrega. Em alguns casos, quando o tempo de entrega não atende o cliente, os times aumentam o WIP.

Algumas razões para limitar o WIP:

  • Torna o trabalho mais previsível e estável. Não trabalhar acima da capacidade ajuda a dar confiabilidade nas entregas.
  • O WIP alto exige alta coordenação e filas maiores, aumentando o risco.
  • Muito do que existe no backlog é especulativo enquanto está no Upstream.
  • Menor variabilidade no Throughput.

flow-vsts

O CFD (Cumulative Flow Diagram) propicia visualizar a capacidade de entrega, através do status das tarefas. Ajuda a identificar gargalos ou impedimentos nos times. O eixo vertical é a quantidade de tarefas, e no eixo horizontal, a linha do tempo. Em um bom fluxo, as linhas inclinam-se suavemente, sem quebras ou saltos.

Com o fluxo estabelecido, tudo aquilo que entra no Kanban (equipe Delivery) é uma decisão crítica. Lembre-se que tempo é dinheiro e existem os tipos de classes de serviço (Expedite | Fixed-date | Normal) para ajudar a priorizar as atividades.

E as equipes Kanban abandonam as estimativas?
No Kanban, a previsibilidade é obtida através do comportamento observado do sistema, que é obtido com dados históricos. Por isso, cerca de 40 amostras ajudam a dar mais confiança. Se o sistema é complexo demais, tentar prever o comportamento dele não é uma boa prática.

Throughput
É uma métrica muito considerada no Kanban, por demonstrar 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. A compreensão das filas é essencial para tornar as coisas mais rápidas em produção. 

Donald Reinertsen: nenhuma fila é grátis!

throughput-lead-time

Como aumentar o Throughput?

  • Melhorar a qualidade (tempo de checagem de itens anteriores ao gargalo precisa ser menor)
  • Priorizar
  • Remover etapa
  • Tipo ticket (classe de serviço)

O que causa a variabilidade do Throughput?

  • WIP não limitado
  • Variabilidade no tamanho dos lotes
  • Especialização (Silos)
  • Indisponibilidades temporárias

Antes de se preocupar com o tamanho (esforço) dos lotes, observe a variabilidade. Veja se a variabilidade atual atende as suas necessidades econômicas de previsibilidade. A variabilidade geralmente é explicada pelas Políticas Explicitas.

Exemplos de Políticas Explícitas:

  • Nós limitamos WIP
  • Deploy só às quartas
  • Reunião de status toda terça-feira


Cadência

Entre as principais reuniões do Kanban estão:

  • Kanban Discovery (upstream): discute opções para priorizar as atividades ao time de Delivery.
  • Kanban Delivery (downstream): converte opções e executa o backlog.
  • Kanban Meeting: é a standup meeting utilizada para tomar decisões e fluir o trabalho.
  • Delivery Planning: reunião de decisão para a entrega ocorrer.

Existe o ponto de comprometimento (entre o upstream e downstream) para definir o critério de mudança da etapa ou no ponto de comprometimento.

kanban-cadence


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. Você pode concluir uma tarefa em 1 dia, mas se o Lead Time estiver alto, esta tarefa vai demorar para ser entregue ao cliente.

O que geralmente causa variabilidade no Lead Time?

  • WIP não limitado
  • Bloqueios
  • Tipo da Demanda

O Lead Time Control Chart e o Histograma são gráficos que ajudam a acompanhar esta métrica.

Resultado de imagem para lead time control chart

E por fim, visualizações, Métricas e Kaizen vão puxar comportamentos mais nobres na equipe como SWARMING.

Integração ServiceNow Change Management com Azure Pipelines – Parte II

Na parte I deste tópico, vimos como realizar a instalação das seguintes extensões:

  • ServiceNow Change Management (no Azure DevOps)
  • Criar uma nova instância no ServiceNow (no ServiceNow Developers)
  • Azure Pipelines (no ServiceNow)

A parte II será direcionada a configuração da integração entre o Azure DevOps e ServiceNow, desde a abertura de uma mudança no ServiceNow (a partir do pipeline no Azure DevOps) e também da atualização do status da mudança, por exemplo, colocar como concluída no ServiceNow, caso a release tenha sido publicada no Azure DevOps.

Azure DevOps
Após a instalação do ServiceNow Change Management (demonstrado na parte I), crie um novo Service Connection no Azure DevOps (Project Settings > Pipelines > Service connections). Defina as seguintes configurações:

  • Connection name: insira o nome desejado para a conexão com o ServiceNow
  • ServiceNow Url: é a URL da instância que será utilizada (também criada na parte I)
  • Username: usuário criado (ou configurado) na parte I com a permissão já definida
  • Password: a senha definida na configuração do usuário (no ServiceNow)

service-connection-vsts

Na Release Pipeline, adicione um pre-deployment gate, incluindo a conexão que acabamos de criar. É o campo ServiceNow connection. A documentação da Microsoft possui uma descrição para o preenchimento de todos os campos. Estas configurações permitem a abertura de uma mudança no ServiceNow. Entre os principais inputs:

  • Category:  a categoria da mudança (HardwareNetworkSoftware)
  • Priority: a prioridade da mudança
  • Risk: o risco da mudança
  • Impact: o impacto da mudança no negócio
  • Configuration Item: o item de configuração da mudança

gates-azure-devops

O Gates produz variáveis de output, como por exemplo:

  • CHANGE_REQUEST_NUMBER: número da mudança criada no ServiceNow
  • CHANGE_SYSTEM_ID: ID da mudança criada no ServiceNow

Esta variável de output pode ser acessada utilizando o prefixo PREDEPLOYGATE. Por exemplo, a variável gate-servicenow (definida no campo reference name) pode ser utilizada com a sintaxe $(PREDEPLOYGATE.gate-servicenow.CHANGE_REQUEST_NUMBER).

new-release-pipeline

Ao executar o deploy da release, uma nova mudança será criada no ServiceNow. Como o Success Criteria (tela anterior) está definido em “Implement”, a mudança será liberada quando for alterada para este status no ServiceNow.

ServiceNow
Então, por exemplo, quando o gestor da mudança acessar a ferramenta do ServiceNow, haverá uma nova mudança em sua fila. Ao colocar a mudança em “Implement”, a condição pre-deployment configurada no Gates será disparada, liberando a release.

service-management

Azure DevOps
Em seguida, adicione um novo Agentless job com a extensão Update ServiceNow Change Request ao final do seu release pipeline. Novamente, utilize a conexão criada anteriormente em ServiceNow connection e o status que deseja colocar a mudança após a implementação da release. No meu exemplo, coloquei o status como “Closed”.

agentless-job-azure-devops

Após a execução , o status do Deployment Gates fica disponível e se bem sucedida, a mudança será fechada automaticamente no ServiceNow.

pre-deployment-gates

Integração ServiceNow Change Management com Azure Pipelines – Parte I

Já abordamos em posts anteriores os temas – Habilitando o Continuous Deployment em empresas regidas por SOX e Change Management e DevSOXOps com Azure DevOps para discutir como as empresas regidas por compliance realizam frequentemente deploys de releases, em meio ao processo de change management.

Se por um lado, o Azure DevOps possui o Pipeline de Build e Release para criar as esteiras de implementação e gerenciar o ciclo de vida da aplicação, o ServiceNow é uma solução completa de IT Service Management, possuindo entre outros, o Incident Management, Problem Management, Change and Release Management, Request Management, etc.

Resultado de imagem para the visible ops

O livro The Visible OPS publica a implementação do ITIL em quatro passos práticos e auditáveis: 1) Core do ITIL 2) Processo de controle bem definido, mas que pode ser leve e ágil 3) O objetivo do processo e intersecções com DevOps 4) Buscar caminhos alternativos para atingir o objetivo esperado.

A Microsoft lançou a integração do Azure DevOps com o ServiceNow, incluindo a extensão do ServiceNow no pipeline de release. A ideia é reduzir os riscos associados ao processo de gestão da mudança, incorporando os benefícios de práticas DevOps como redução do tempo de deploy, intervenções manuais etc com os controles de gestão de serviços.

E assim, podemos por exemplo, criar uma nova requisição ou atualizar o status de uma change, utilizando o recurso de Gates do Azure DevOps. Vamos começar pelas instalações! Os primeiros passos são:

1. Instalação da extensão do ServiceNow no Azure DevOps

service-now-change-mgt-extension

2. Solicitar uma nova instância no ServiceNow Developers no ServiceNow. Esta instância deve ser non-developer.

service-now-developers

3. Instalação do App Azure Pipelines no ServiceNow. Necessita de HI credentials (algum administrador da conta no ServiceNow pode conceder esta permissão) ou ser Technology Partner Program.

service-now-store

E atribuir a permissão de x_mioms_azpipeline.pipelinesExecution ao usuário que será utilizado no Service Connection do Azure DevOps (para criar a conexão com o ServiceNow).

user-role-sn

E a Parte I encerra aqui… no próximo post vamos compartilhar as configurações necessárias no Azure DevOps e ServiceNow para concluir a integração.

 

CertiProf – Resumo das certificações Scrum (SFPC) e DevOps (DEPC)

Neste post vou compartilhar algumas dicas para quem deseja realizar os testes de certificação da Certiprof. A empresa liberou por tempo indeterminado o acesso gratuito a estes dois exames online:

1. Scrum Foundation Professional Certificate (SFPC)

O guia de preparação é dividido em 4 partes:

  • Parte 1: introdução dos conceitos de Ágil, Manifesto Ágil, tipos de projeto e Scrum.
  • Parte 2: teoria do Scrum – três pilares (transparência, inspeção e adaptação), valores e essência do Scrum.
  • Parte 3: papéis e responsabilidades dos times.
  • Parte 4: principais conceitos – user story, time-boxing, sprint, eventos e artefatos.

Realize os simulados antes de fazer o teste de certificação. A prova é bem simples para quem já conhece o Scrum Guide e os conceitos de agilidade. Uma revisão no guia de preparação também é recomendado.


2. DevOps Essentials Professional Certificate (DEPC)

O guia de preparação é dividido da seguinte forma:

  • Introdução: conceitos, história, objetivo, benefícios e pilares do DevOps.
  • Conceitos: princípios, papéis e responsabilidades, desafios organizacionais, gerenciamento de configuração, Entrega contínua e Integração contínua.
  • DevOps e outras práticas recomendadas: Agile, Scrum e ITSM (ITIL).
  • Culturas DevOps e Adoção incremental de DevOps
  • Ferramentas DevOps: Eclipse, JIRA, Maven/Ant, Git/GitHub, Chef, Docker, Puppet, Jenkins/Bamboo, Nexus/Artifactory, New Relic, Splunk, Nagios, etc.
  • Modelo Gartner DevOps: pessoas, processos, tecnologia e cultura
  • Modelo de maturidade e autoavaliação

Gerenciando dependências de Work Items no Azure DevOps

Como você gerencia a dependência das atividades entre seus times? Ou até mesmo dentro do próprio time? Quando abordamos ágil em larga escala utilizando o SAFe e Azure DevOps nos projetos, vimos a importância de gerenciar as dependências e como os eventos de PO Sync e SoS (Scrum of Scrums) podem apoiar neste ponto.

Azure DevOps possui o recurso Link no Work Item que permite referenciar:
link Work items –com– Work items
link Work items –com– Test cases (Test cases –com– Test items e Test results)
link Work items –com– code-related objects (branches, commits, pull requests, etc.)
link Git code-related objects –com– builds
link Work items –com– link na web
link Work items –com– Diagramas de arquitetura

Work item link typesImagem: Docs Microsoft

Link entre Work Items
As referências podem então ser utilizadas para gerenciar as dependências entre as atividades. O link Predecessor-Successor define que o work item precisa ser concluído antes do início de outros (muito utilizado quando o plano de trabalho é feito no Project). O link Related é utilizado para relacionar work item do mesmo nível com features que se sobrepõem (por exemplo entre user stories) ou em diferentes projetos / times.

link-related

Em Boards > Sprints podemos visualizar as referências criadas. Para isso, adicione a coluna “Related Link Count” e será exibida a quantidade de links daquele work item. Clicando no próprio work item (exemplo: user story 01), podemos visualizar quais são os work items relacionados a ele.

related-wi

Quando há mais de um work item aberto com o mesmo propósito, o link  Duplicate ajuda a controlar os itens duplicados. Você pode manter apenas um ativo e identificar os demais como duplicate. O link Parent/Child é usado para quebrar work items em tarefas menores, por exemplo, features em user stories.

Ao adicionar uma nova Task na Sprint, se estiver abaixo de uma User Story, a relação (related work) do tipo Parent já é automaticamente criada entre a Task e a User Story.

wi-azure-devops

Para mais detalhes sobre o uso de links e referências, recomendo este site da Microsoft: Link Type Reference.

Link entre Work items e artefatos de código e builds
Outro tipo de link interessante é relacionar os Work items com o código-fonte da aplicação. Isso ajuda o rastreamento e inspeção das modificações realizadas no código-fonte. O link pode ser feito no Work item com os artefatos (como demonstrado anteriormente) ou inserindo o ID do Work item em uma das operações suportadas pelo Git ou TFVC (commit, pull request, changeset, etc.).

Artifact-to-artifact link typesImagem: Docs Microsoft