Arquivo da tag: kanban

0

Value Stream Mapping

|

A criação de um mapa de fluxo de valor de estado atual é um passo importante quando estamos debatendo nosso processo de trabalho, mas a meu ver é fundamental que entendamos os conceitos, os processemos e a luz de nossa realidade adaptemos ou simplifiquemos à nossa necessidade.

Tenho cases bem legais em áreas como financeiro, contratos, compras, RH, educação, conteúdo, baseados em “Genchi Gembutsu” e “Gemba Walk”, que traduzem o conceito de verificar in loco onde as coisas acontecem, com quem faz acontecer. Porque o primeiro passo é não tomar decisões sem convidar para o debate quem faz acontecer, inexiste entendimento sem envolver as pessoas.

O mapa de fluxo de valor do estado atual é um trabalho onde a equipe, com ajuda de um facilitador, debate e mapeia os limites e passos do processo, os dados e fluxo, os tempos de execução e transição, tudo isso para debater gargalos, problemas e oportunidades para planejar e experimentar melhoria.

No slideshare encontrei este desenho de processo para execução iterativo-incremental de mapeamento e melhoria do mapa de fluxo de valor (Lean Webinar Series):

Eu muito usei este conceito ajudando áreas de escritório (Lean Office) a mapear e tentar melhorar seus fluxos de valor, mas para ilustrar este post eu procurei exemplos de desenvolvimento de software para tornar mais legível para a maioria, exemplo de indústria há milhares no gloogle.

O que é VSM

Mapeamos o fluxo de valor do estado atual com o intuito de enxugá-lo e construirmos o estado ideal ou futuro, para tanto representamos o passo-a-passo de cada um de nossos fluxos de trabalho, entendendo atores, responsabilidades, informações, recursos e tempos médios.

Trata-se de um exercício coletivo e colaborativo, envolvendo representantes de todas as áreas e equipes, todos temos condições de fazê-lo se desapegarmos de notações, foque no fluxo e não no formato, debata e ao mesmo tempo registre diagramaticamente de forma clara aos presentes.

Um rabiscoframe legível e claro a todos os presentes vale muito mais que um diagrama cheio de regras e notações, quando perdemos tempo abertos a comentários e rec
lamações que nada agregam em valor ao assunto, apenas a regras de representação absolutamente dispensáveis.

Quem nós somos e o que fazemos?

Sugestão, use um Role Model Canvas, um Design Ops Canvas, inicie alinhando quem nós somos, qual é a nossa missão, restrições, informações, ferramentas, … liste os principais fluxos de trabalho, escolha aquele que mais tem a agregar se o analisarmos e enxugarmos.

A escolha diz respeito a Pareto, queremos mapear um fluxo de projeto, operação, relacionado a um produto ou serviço, interno ou externo, frequentemente diz respeito a algo que está gerando problemas, mas pode ser algo novo, um desafio ou objetivo organizacional em enxugar.

Quem fará a facilitação?

É importante ter alguém que faça a facilitação, mediação, provavelmente alguém com alguma experiência ou habilidade na diagramação de mapas de valor ou processos, podendo ou não ser alguém do time ou (frequentemente) um profissional dedicado a este tipo de trabalho.

Ele alinhará de início algumas regras e técnicas Lean ou Ágeis para debates colaborativos, registrará o objetivo e criará alguns quadros auxiliares, bem como combinará em comum acordo alguns acordos sobre simbologia, significado de cores, postits, etc.

Essas combinações são essenciais para direcionar os debates, diz respeito a fazer um pacto de trabalho, delimitando algumas balizas e restrições, acordando o(s) principal(is) foco(s) de atenção e dedicação.

Desenhando o fluxo?

O desenho incia invariavelmente por um storytelling, com key-users, usuários e operadores contando como realizam este trabalho, onde ele inicia, por onde passa, suas operações, filas, transformações, evitando entrar a nível de tarefas ou detalhamento de atividades.

É muito importante neste momento incluir os fluxos de informação envolvidos, solicitações, registros, workflows, aprovações, aguardando, manipulações, sempre a partir de um paradigma de operação e não detalhando atividades, mergulharemos nela mais adiante se necessário.

Esta discussão tem valor per si, o simples fato de colocar as pessoas para discutir seus trabalho atual explicitam eventuais desperdícios ocultos, alguns preconizados pelo Lean desde a década de 50, como estoques de inacabados, deslocamento desnecessário, complexidade desnecessária.

Se a equipe for provocada desde o início a sair da caixa, analisar críticamente sem prévios conceitos e questionando regras e hábitos, é muito provável que todo e qualquer fluxo terá desdobramentos para otimização e enxugamento de seus passos, potencializando seus recursos e tempo.

Dados, medidas e informações?

Agregue informações pertinentes a métricas do seu fluxo, de cada passo e entre eles, mas evitem percepções abstratas ou históricas, gere informações atualizadas e reais para evitar birras e distorções pessoais ou mesmo coletivas.

Ao registrarmos tempos médios, se necessário também mínimos e máximos, muito do valor pertinente a demora e oportunidades de redução se explicitam automaticamente, informações básicas do Lean são Lead Time (desde a requisição inicial) e Cycle Time (tempo de execução).

No mapeamento de fluxo de valor dedicamos algum tempo na análise de tempo, quer no de execução de uma operação quanto no tempo de fila ou aguardando algo, o que muitas vezes se reflete em desperdícios.

Obs: A imagem abaixo retirei de um post em que Al Shalloway destaca que um bom Kanban com seus status visíveis de fluxo seria um passo dado para incrementar médias e informações para análise de gargalos, algo que tentamos fazer sem explicitar um VSM, mas usando quadros auxiliares com Lead Time, Cycle Time, Throughput, …

Como criar o mapa de fluxo de valor do estado ideal?

Iniciamos combinando qual é o ideal que queremos ou necessitamos, para então começar ciclos de análise, debate, proposição a partir dos pontos de maior desperdício ou “dor”. Iniciamos debatendo o ponto em comum acordo que é onde maior valor agregaria se o otimizassemos e assim por diante.

Aqui entra em ação nossa Toolbox, apoiados por frameworks, técnicas e boas práticas para otimização de cada operação analisada, como o uso de quadros Kanban para eliminar desperdícios de tempo e estabelecer um fluxo puxado.

Naturalmente vamos planejar algumas melhorias, priorizadamente, em ciclos evolutivos, iterativo-incrementais-articulados, para avaliar, planejar o próximo passo e seguir adiante. A técnica recomenda que demarquemos os pontos que estão sendo priorizados e a ação que está sendo realizada a cada novo passo (kaizen Burst).

As vezes temos resultados imediatos, mas para atingir um estado ideal otimizado é preciso persistência e dedicação.

0

Um quadro estratégico e tático inter-equipes

|

Em uma consultoria recente os PO’s e analistas me pediram ajuda para organizar um product backlog compartilhado entre 6 equipes especialistas em suites de uma solução digital corporativa – financeiro, contábil, backoffice, etc.

Me baseei em um quadro de features por equipes do framework SAFe, onde temos cada equipe com suas features para o Train, garantindo uma visão tática por equipe x feature que dá suporte para algumas reuniões táticas e escaladas.

A necessidade era baseada em um backlog sendo priorizado por diferentes clientes e pela própria empresa para evolução e manutenção do produto. Queriamos um artefato que os ajudasse a ter uma visão clara transversal estratégica e tática para distribuição e acompanhamento.

Eu já havia ajudado a introduzir há alguns meses Scrum e Scrum of Scrums, que vinham trazendo bons resultados, mas agora os PO’s e analistas precisavam algo mais visual para o backlog nos próximos meses.

Diagramaticamente, reorganizamos os postits utilizados por eles em uma reunião recente de priorização com clientes, quando usaram um quadro de valor x esforço, com cores para 5 diferentes naturezas de ítens.

Simbolizei na imagem a principal diferenciação destacada, pois para cada time temos duas trilhas, uma para projetos (azul) e outra para sustentação (reserva técnica). O quadro visual é apenas para priorização e abstração em uma escala de tempo mensal.

O quadro ficará em um desses cavaletes com rodinhas, a granularidade dos tickets será por conveniência, coisas muito pequenas não serão representadas individualmente e o formato privilegiará selos com marcos, riscos e lembretes.

Cada postits azul representando projetos, no momento apropriado, terão sua própria inception e seu quadro de Release Plan junto ao(s) time(s) envolvidos, ficando aqui registrado apenas seus MVP’s e Releases.

O número de meses/sprints representados no quadro será um ponto de equilíbrio com foco em que o quadro facilite reuniões de estratégia com as equipes, diretoria e clientes. Também será um facilitador na mudança em curso para Agile no que diz respeito a gestão visual transversal, no plano estratégico e tático, compartilhada entre todos os envolvidos e interessados, inclusive stakeholders.

Relato GVDASA

Uma empresa de atuação nacional que vem fazendo sua transformação digital, com total apoio da alta direção, da gestão e equipes ágeis praticando Scrum, Kanban e realizando reuniões transversais seguindo Scrum of Scrums.

A mais de ano, cada equipe, desde a adoção, contando com profissionais que vem se empenhando em serem ágeis, agregar valor, evoluindo a cada ciclo, melhorando suas práticas ágeis através de experimentação x resultados.

“Já queria te dar um primeiro feedback. Recebemos um pedido de priorização de outra área, o item estava em 7º lugar no backlog, marquei um momento para discussão com os envolvidos e direção e utilizamos a técnica de comparação, ou seja o item a ser priorizado é mais importante que o 1º, 2º, 3º e assim sucessivamente. O resultado foi que todos concordaram que a priorização estava correta e deram um feedback positivo a respeito da clareza e transparência das prioridades que estão sendo trabalhadas.”

Vinicius Iager – coordenado de desenvolvimento GVDASA – Gestão educacional integrada, solução completa para a otimização dos processos acadêmicos e administrativos da sua instituição – http://gvdasa.com.br/

logotipo GVDasa

Conclusão

Não só as equipes envolvidas, mas a participação de clientes, líderes e executivos sempre é muito positivo ao se depararem com um quadro de portfólio, programa, ciclo ou Release Plan. Eles veem ali materializado seus objetivos, desejos, sonhos e expectativas.

Muito da alta pressão, “natural” em projetos de TI, é existir diferentes percepções e entendimentos relativos a prioridades e possibilidades. Ao estabelecer um quadro estratégico ou tático, toda a discussão sobre priorização (e mudanças) geram um único entendimento.

Não há regras pétrias de ticketagem (postits) ao iniciar o uso, tanto granularidade quanto diferenciação irão adaptar-se a realidade do tipo de portfólio, programa, ciclo, tecnologia, complexidade, volumes, equipes, pessoas, etc … Dê o primeiro passo, explicite e deixe que as retrospectivas se encarregarão de melhora-lo cada vez mais.

0

O que é Reserva Técnica?

|

Já citei várias vezes o conceito de reserva técnica em equipes SCRUM, a utilizo sob esta designação desde 2011, mas apesar de sua importância e efetividade para o sucesso de uma sprint, nunca tinha dedicado um post para explicar com detalhes. Isso acontece as vezes, algumas coisas parecem óbvias de tanto que falo no dia-a-dia e por isso acabo esquecendo de compartilhar.

Nos treinamentos sempre dedico um slot para seu entendimento na teoria e na prática, utilizo em todos os projetos com diferentes percentuais e insumos, mas refletindo sobre um bom post no LinkedIn do amigo José Alberto Esteves do Nascimento, CEO da Dura-Lex Sistemas, aqui vai um post mais detalhado sobre o uso da Reserva Técnica em equipes SCRUM.

O começo de tudo

Release Plan é o marco que divide o pré-game do game, quando finalmente botamos a mão na massa e geramos código de qualidade e valor em ciclos iterativo-incrementais-articulados. A técnica pode ser Inception, Direto ao Ponto ou outra, conforme crenças e conveniência.

Antes do início de um Release Plan, é preciso estabelecer os critérios e parâmetros que estão postos ou precisam estar postos para balizar um bom planejamento. Para isto eu venho utilizando o Project Model Canvas do Prof Finocchio e o meu SCRUM Setup Canvas para mapear o que um time SCRUM precisa saber.

pmc

scrum-model-canvas-vazio-vii

Durante um Release Plan, utilizaremos direta ou indiretamente as informações destes dois Canvas para bem conduzir e planejar nosso projeto, levando em consideração expectativas, premissas, restrições e riscos, bem como os parâmetros de setup que balizam um projeto SCRUM, explicitamente debatidas na construção de um SCRUM SetUp Canvas.

No final de um Release Plan queremos que seja possível termos um bom planejamento de Sprints e Releases, nem otimista e nem pessimista, mas um planejamento realista, baseado nas melhores informações e projeções que o capital intelectual de todos os presentes puderam compôr a partir dos insumos necessários e que vinham sendo coletados, trabalhados e refinados a algum tempo.

Tenho muitos posts sobre quase tudo, mas estava devendo um bom post sobre Reserva Técnica, premissa para um bom planejamento, pois sem levá-la em consideração correremos o risco de passados apenas um ou dois sprints vermos todo nosso planejamento ir para o ralo por fatos e situações que são de nosso conhecimento, mas que por desinformação, preguiça ou insegurança não usamos.

Reserva técnica

Auto-conhecimento é valor, como levantar uma média histórica ou fazer uma projeção de cenários que levam em consideração o tempo ou percentual que NÃO teremos de disponibilidade do time para o projeto que iremos planejar. Levamos em consideração dedicação a outros afazeres, como sustentação, atendimento, sazonalidade, alocações previsíveis e relevantes para os próximos meses. Alguns são duradouros, outros esporádicos, como prever um pico no sprint seguinte a uma entrega em produção, atendimentos, manutenção a treinamentos.

Creio que mais de 80% das equipes com quem trabalho se utilizam de reserva técnica, pois dão sustentação a solução que hora estão aprimorando ou evoluindo ou o fazem para outras soluções em produção, até mesmo legados. O índice varia muito, usualmente fica em torno de 25%, mas tenho variações de 10% a 50% … e funciona muito bem, inclusive planos de ação para entendê-la e reduzi-la sempre tem bom feedback em nossas sprints review.

O primeiro passo em uma iteração é o Sprint Planning, dinâmica destinada a entender melhor, validar a estimativa e expectativa inicial, a partir agora de uma especificação (DoR) mais clara. Projeções de presenças e ausências, confirmação da Reserva Técnica, inicio do uso técnicas que inicialmente impactem em produtividade, etc. Ao final saímos com um quadro Kanban montado com tarefas para construção do Sprint Backlog e eventuais tarefas técnicas.

Usualmente em quadros Kanban físicos eu crio raias para as histórias terem suas tarefas evoluindo de forma visualmente explícita, facilitando a leitura do Kanban, mas a imagem abaixo mostra um esquema sem ter as raias de histórias, somente a de Reserva Técnica, que no exemplo está com 25%, apenas para ilustrar:

pag 98 - 2

A cada reunião Diária, as quatro frases quanto ao que fez e vai fazer para o sucesso da sprint desde a última e até a próxima daily, se vê riscos ou se vê oportunidades para o sucesso do sprint. Avaliando a evolução da sprint, tendência e equilíbrio entre projeto e reserva técnica, de forma a tomar decisões de acionamento, planos de ação, comunicação e o que mais for necessário para garantir o máximo de valor possível a cada sprint.

Eu tenho uma frase que costumo usar em treinamentos e já compartilhei em posts sobre a reunião diária: Se passarem algumas diárias e tudo estiver perfeito, é porque um ou todos estão mentindo ou foram excessivamente pessimistas nas estimativas. Só dá tudo absolutamente certo se colocamos um enorme CC no planejamento, porque quem tenta acertar acaba errando para cima e para baixo, acertamos na média e não na tampa … disso eu não tenho dúvida!

O maior “segredo” de um time ágil é o senso de pertença na auto-organização, logo, é da alçada do time avaliar cada dia trabalhado e buscar o seu equilíbrio de forma pró-ativa e efetiva, gerando valor, evitando desperdício, buscando ajuda, blindando, antecipando, etc. Tudo isso de forma 100% transparente, contando com o PO e SM, indiretamente dos stakeholders quando preciso, sempre com o intuito de atingir o melhor resultado a cada iteração.

Ao final de cada sprint, em cada sprint review e em cada retrô, o prazer de participar de algo em que todos juntos temos orgulho de ter feito o nosso melhor, aprendido e buscar a cada passo melhorar ainda mais. A reserva técnica é um insumo do processo de auto-organização e kaizen que exige auto-conhecimento e comprometimento, porque há ocorrências inevitáveis, mas há muito de divida técnica, de treinamento, de falta de qualidade, falta de automação de testes, …

Em equipes SCRUM de projeto, quer seja por algo novo, pacote de evolutivas ou corretivas, é um privilégio equipes dedicadas exclusivamente a um projeto, mas mesmos estas a partir da primeira entrega já entram em ritmo de sustentação, um ritmo mitigado quanto maior a qualidade e excelência, desde o planejamento, DoR, DoD, engenharia de software e interação, mas nada disso funciona a contento sem muita auto-organização e senso de pertença … lembre disso!

A tempo, tenho muitos cases e exemplos práticos e este post é uma introdução ao tema, logo, como sempre, fico a disposição por aqui ou pelas redes … agradeço a parceria e até a próxima!

4

Relato do 1° workshop ToolBox 360º

|

Registro da primeira edição do workshop ToolBox 360°, um Sábado inteiro de compartilhamento em que o objetivo era demonstrar os diferentes usos e oportunidades dos 70 tópicos descritos no meu terceiro livro. O treinamento teve um custo de R$100, recebendo uma unidade do livro com seu encarte sintético e mais de oito horas de práxis e exercícios.

Só tenho a agradecer o apoio da DBServer ao acreditar no valor que meus livros poderiam agregar a nosso ecossistema. Foram iniciativas independentes que contaram com diferentes formatos de patrocínio ou aquisição de até 25% da primeira edição com o objetivo de viabilizar os projetos – SCRUM 360°, JOGOS 360° e TOOLBOX 360°.

A primeira edição do workshop TOOLBOX 360° só se viabilizou pela logística proporcionada mais uma vez pela DBServer. Se o livro é um guia de 70 boas práticas em projetos, operações e escritório, o treinamento busca explicar como juntar as peças, alguns roteiros conforme contexto, riscos e oportunidades.

mural-fotos-toolbox-1
Fotos: Claudio Dias Junior

A programação foi seguindo a ordem proposta pelo livro, iniciando pelas premissas e modelo mental, seguindo com uma primeira layer de cada uma das metodologias-base que usamos (SCRUM, Kanban, Lean, Design Thinking e Lean Startup) para falar de princípios, colaboração, empatia e outras paradas.

Nessa viagem, falamos um pouco de cada estação, técnicas e artefatos para ideação, visão, estratégia, modelagem, planejamento, discovery e delivery, fechando com um tanto de gestão do conhecimento, desde retrospectivas a comunidades de prática, com o bom e velho Modelo Seci dos meus gurus máximos – Takeushi & Nonaka.

Os participantes foram: Adriana Germani, André Luis da Silveira, André Santos, Augusto, Carlos Giovani Rodrigues, Cássio Antoniazzi, Catarina Nogueira, Catarina Nogueira, Claudio da Silva Dias Junior, Cristiane Nogueira dos Reis, Denise da Silva Dariva, Eduardo Oliveira, Francielle Vareira, Gabriela Antunes, Gustavo Nogueira dos Reis, Henrique Zmuda da Silva, Joao Vicente, Luiz Carlos Santos Jr, Manoela, Marcelo Meruvia, Michel Gomes da Silva, Rafael Szarblewski, Renato Severo, Rodrigo Boehl e Thiago pinheiro.

Além destes, tive o prazer da presença dos colegas Cássio Trindade da PUCRS, Denize Vásques e Jonatan Baptista da DBServer, sempre parceiros de viagem.

A foto abaixo não contou com todos porque foi tirada apenas após o término, mas me dei conta apenas após alguns já terem ido embora … mas nas muitas fotos padrão profissionais tiradas pelo Claudio Dias Junior, acho que todos aparecem.

unnamed

Menção honrosa para o Business Model You do Batman, só podia ter DBServantes no meio dessa equipe  🙂  rsrsrsrsrsrsrsrs

BMY do batman

O maior insight que tive foi a oportunidade de em futuras edições fazer turmas segmentadas, com pessoas com interesse de igual interesse. Essencialmente interessados em projetos e operações relativo a desenvolvimento de software e outros como startups e iniciativas não TI, pois assim aprofundaria alguns temas.

2

Quadros táticos em um case de adoção ágil

|

Um exemplo merecedor de atenção, uma empresa de médio porte 100% empenhada em adotar Scrum, Kanban e Lean Office em todas as suas equipes. Treinamentos a colaboradores de desenvolvimento e infra, mas também, RH, financeiro, compras, etc. Diretores, gerentes, supervisores e integrantes de todas as equipes interessados em entender os princípios ágeis e métodos para que possam encontrar o melhor momento para iniciar a experimentação.

A proposta e crença é não haver receita pré-definida para diferentes casos, cada equipe com a responsabilidade de entender e modelar como quer começar, respeitando características de cada uma, projeto, cliente e tecnologia. Sem imposição, ao invés disso muita discussão e modelagem, rodando, a cada retrospectiva ajustando e melhorando. Privilégio estar participando de mais um trabalho de apoio com esta característica e natureza.

Em meio a este quadro absolutamente inspirador, temos não só diferentes áreas como diferentes níveis hierárquicos empenhados em experimentar boas práticas de gestão visual e incentivo a delegação e colaboração na manutenção desta gestão. Assim, já temos quadros estratégicos, táticos e de tarefas, em desenvolvimento, infraestrutura e não TI, em projetos, manutenção e otimização de processos.

#1. Um primeiro exemplo é um quadro de portfólio com marcação mensal de entregas por algumas equipes, inicialmente usando cores ou ícones para identificar os projetos de cada equipe e uma legenda. Releases, pacotes, MVP’s, cada entrega identificada com um postit. A atualização do quadro como portfólio de projetos e suas entregas deve ficar a encargo das próprias equipes, que devem a cada Sprint confirmar a projeção de suas entregas. Esta regra garante que o quadro fique defasado, comum se a sua atualização ficar a encargo de uma pessoa ou área.

portfolio

2. O segundo artefato é uma convicção minha, um Agile Subway Map, estamos desenvolvendo um mapa com todas as técnicas, tecnologias e boas práticas utilizadas pelas equipes de desenvolvimento de software. A ideia é demarcar o processo básico ou essencial e aos poucos incrementá-lo com boas práticas condicionais à características do projeto, cliente, equipe ou plataforma. O primeiro passo já foi dado, agora evoluirá aos poucos, com a ajuda de todos.

subway

3. O terceiro artefato estratégico proporciona um Dashboard metodológico e tecnológico, um mapa em que cada projeto tem apontamento sobre técnicas e boas práticas escolhidas como essenciais ou desejadas. Uma forma de rastrear e entender quais técnicas estão sendo usadas por quem, nem tudo é mapeado, mas tudo o que é importante, especialmente em um período de mudança como a adoção de metodologias ágeis.

dashboard

Para breve, começaremos um segundo mapa, 100% tecnológico, elencando plataformas, linguagens, frameworks, ferramentas, … tecnologias. É uma forma de termos facilmente uma visão de quem está usando o que, facilitando revisão permanente da estratégia em tecnologia aplicada, rastreabilidade e identificação de pontos de contato, oportunidades de treinamento e reciclagem.

O ponto de partida será algo muito parecido ao desenvolvido e publicado recentemente sobre o projeto da Defensoria Pública do Estado do RS, onde tive a oportunidade de facilitar o mapeamento tecnológico realizado pelo arquiteto de soluções Matheus Alagia … imagino aquele trabalho realizado em variadas equipes de plataforma Java que possamos mapear quem usa o que.

Compartilharei outras percepções em um caso realmente singular, como os diferentes quadros Kanbans para equipes de manutenção ou os casos de áreas compostas de Euquipes, Doisquipe e Trêsquipe … em que quadros táticos estão sendo utilizados, bem como para projetos temos quadros de Project Model Canvas, Release Plan, Sprint e retrospectiva. Papo para outros posts o/

 

4

Spotify é um case 360° de agilidade

|

Através de sinônimos, analogias, alegorias e muita criatividade, o Spotify utilizou e renomeou métodos e conceitos, para chamar de seu, utilizando como base Scrum, Scrum de Scrum, Kanban, DevOps e Gestão do Conhecimento, atribuindo nomes como Squad, Tribe, Guild, Chapter, … Na falta de um pacote com visão completa do ciclo de vida, transversal, o Spotify fez um patchwork com o que há de melhor em métodos e boas práticas ágeis.

Estou lendo sobre o processo Spotify para desenvolvimento de produtos e serviços digitais, um mix fascinante que instancia e compatibiliza o método Scrum na sua íntegra, escalando com Scrum de Scrum, com gestão visual através de kanban, portfólios e dashboards, DevOps na prática, trazendo operações para dentro do fluxo cotidiano de projetos e manutenção, além de GC a exemplo dos grandes players de tecnologia e inovação.

O sentimento ao analisar o processo de trabalho do Spotify é que o business model deles tinha a meta de estabelecer um processo próprio, baseado em práticas vencedoras, mas sem perder a identidade. Provavelmente a etapa final de um SHU-HA-RI bem executado, inicialmente praticando cada uma, ajustando, acoplando, dando-lhes nome e sobrenome, gerando energia e senso de pertença.

Esta análise foi principalmente baseada no artigo do Paulo Rebelo na InfoQ com o título “Escalando o Agile na Spotify: exemplo de sucesso de Lean Startup, Scrum e Kanban” e na Scrum Alliance com o título de “Scaling Agile Using Spotify’s Framework“, além de um vídeo bem interessante disponível no Youtube e que anexei logo abaixo, com o título “Spotify Engineering Culture part 1 (Agile Enterprise Transition with Scrum and Kanban)“.

Não deixaram Lean Startup e Design Thinking de fora, menos ainda o conceito de Exploration x Exploitation, de Capacidade Absortiva, não só por eventos práticos de GC ou artefatos, mas também com o incentivo a inovação e empreendedorismo em todos os níveis, fazer diferente e melhor, solucionar problemas, surpreender.

Provavelmente se eu pegar meus últimos 30 posts ou 2 palestras, teremos cada um dos ingredientes deste banquete, é absolutamente sensacional, não tem como não ficar contente em saber que minhas percepções não poderiam estar mais certas, apenas no caso do Spotify tenho que ter um DE-PARA ou glossário, como:

T Shaped – Indivíduos, times e organizações, profundidade com amplitude;
Squad – É o nosso time ágeil Scrum ou Kanban, auto-organizado;
Tribo – Um conjunto de Squads juntas por oportunidades de negócio;
Chapter – CoP’s internas às Tribos;
Guild – CoP’s transversais a diferentes Tribos, são organizacionais.

Vale a pena dar uma olhada e refletir um pouco, para mim é impossível não lembrar de vários de nossos clientes, onde entro falando de perfil T, competências pessoais, coletivas, organizacionais e ambientais, base para Scrum e Kanban, que necessitam de GC aplicada através de artefatos como dashboards e portfólios, tanto quanto GU’s e CoP’s intra e inter.

Go Ahead!  \o/

0

Um dia diferente para desenhar um novo processo

|

No dia 18/03 tive a oportunidade de facilitar um dia de construção prática de um novo processo de trabalho baseado em ScrumBan e boas práticas ágeis. Durante a manhã seguimos um roteiro crescente de auto-conhecimento e entendimento de riscos e oportunidades, crenças e valores.

Uma equipe excepcionalmente consciente, contando com profissionais de mais e menos tempo de casa, mas com muita vontade de entender e construir, evitando adoção pura e simples, focando cada passo no valor que ele pode proporcionar em diferentes forma de instanciamento. A premissa é NÃO ao by-the-book!

Analistas, desenvolvedores, testador e gestão, todos no desafio de discutir e definir o primeiro passo na adoção de ciclos iterativo-incrementais curtos e organizados, com planejamento, reuniões de alinhamento, um quadro de alto significado e valor, review diferenciada e retrospectiva. Parte das atividades orientadas a projeto e parte em manutenção, consultoria e atendimento em um projeto de alto impacto em meia centena de organizações.

8278_1091724497547166_5731544767141273544_n

O roteiro foi básicamente o seguinte:

1. Apresentações com expectativas, o que cada um tinha de expectativa, inquietação e metas sobre o dia de hoje. Cada profissional presente relatou e na medida em que acontecia eu montava bullets em um mapa que nortearia e nos norteou;

2. Debatemos o cotidiano da equipe e do projeto que eles estavam envolvidos, histórico, características, clientes, aspectos hierarquicos, stakeholders e tudo o que eles consideravam pertinente, inclusive suas experiências metodológicas;

3. A cada oportunidade, questionamento ou necessidade, fui desenvolvendo algumas pequenas inserções sobre métodos ágeis, boas práticas e técnicas que poderiam ajudar a equipe a iniciar, prosseguir ou desejar atingir, sem preconceitos ou pré-conceitos … tudo o que rolou eu materializei em mapas e bullets em folhas de flipchart e fui colando nas paredes laterais;

4. Com a ajuda de todos, desenhei na parede um quadro inicial e distribui postits a todos e pedi que cada um criasse um postit para cada atividade, feature ou tarefas em que estavam envolvidos, uma forma de acelerar a tarefa de construir coletivamente um bom quadro, adequado a realidade do time e projeto, com as colunas de status apropriadas e trilhas para projetos ou manutenção;

5. Todos foram convidados a irem até o nosso quadro básico e colarem seus postits nos quadros de Discovery ou no de Delivery, cada qual com colunas e linhas básicas que viriam a mudar com o andar da dinâmica. Feito isso eu li e organizei de forma colaborativa cada coluna, surgindo algumas novas como aguardando e pré-teste, bem como quatro linhas horizontais para projetos e manutenção;

6. Almoço em restaurante próximo com a participação de todos;

7. A tarde iniciamos por uma análise e pequenos treinamentos sobre outras técnicas e oportunidades, chegando-se a um quadro bastante apurado e que todos confirmaram como um primeiro passo bem acoplado, onde todos se sentiam representados e sem desconfortos em relação as regras auto-organizadas sobre planejamento, atualização e condução cotidiana;

8. Mais para o meio da tarde, fechamos o que seria um sprint típico, suas características relacionadas a review e retrospectiva, interação com o cliente, nomenclaturas, selos e explicitação das regras inicialmente combinadas em um pacto de time;

9. A semana que vem tem 3,5 dias em função da Páscoa e todos concordaram que seria conveniente iniciar o primeiro ciclo na segunda-feira da semana seguinte, até lá a cada dia todos lembrando de exercitar a dinâmica do quadro, mantendo-o atualizado e colocando postits no quadro de retrospectiva com insights que venham a ter durante os próximos dias.

O feedback foi muito legal, muita energia e uma boa expectativa, agora é colocar para rodar e melhorar a cada novo ciclo, acoplando cada vez mais o processo às características peculiares da equipe, do projeto e dos aprendizados que surgirão e gerarão no dia-a-dia insights e novos argumentos. Foi um início primoroso, sem disputas ou preciosismos, com muita interação e descontração buscando convergência a cada novo passo no processo desenhado.

Sempre tem o que melhorar, mas as vezes o sentimento ao final do dia é se tentar melhorar estraga! O primeiro passo a gente nunca esquece, ainda mais se gerar um sentimento de satisfação e orgulho em fazer e com quem se faz. \o/