0

Do A3 Report previsto à reinterpretação do Role Model Canvas

Retornei à Curitiba com o briefing de facilitar uma reunião da equipe de staff de uma associação internacional de médicos com foco em ensino, disseminação de conhecimento e melhores práticas. A primeira foi no início de 2017 e contou também com o board latino-americano.

Fui com a intenção de utilizar uma técnica de brainstorming para focar o(s) principal(is) pontos de melhoria e depois usar um A3 Report para instanciar um canvas contendo premissas, planejamento, plano de ação, comunicação e melhoria contínua, mas … chegando lá, mudei.

Estava previsto um alinhamento sobre objetivos, contexto, riscos e oportunidades no dia anterior ao evento. Não Teríamos um planejamento de projeto ou tarefas, mas focaríamos em auto-conhecimento e oportunidades de melhoria em quatro papéis e suas interdependências.

A partir de nossa conversa, me propus a utilizar para cada uma das áreas, envolvendo de dois a três profissionais, uma jornada de auto-conhecimento, reflexão e priorização, para então realizar um exercício de pontos de melhoria e priorização de ações até Janeiro de 2018.

De volta ao hotel, optei por usar um canvas alemão de modelagem de papéis, mas ajustado para focar em processos, fluxos de trabalho e suas oportunidades de melhoria. O canvas (alemão) “Role Model Canvas” foi desenvolvido por Christan Botta (abaixo um dos links, todos alemães).

Não o usei de forma literal, o adaptei a minha necessidade, mas mantive o mérito ao autor. O reinterpretei visualmente de forma a privilegiar o que era para nós mais importante, por isso reorganizei e propus uma abordagem dirigida para preenchimento e abstração, conforme segue:

1º. Missão, antes de mais nada, o que é esperado, resultados esperados, porque de sua existência;
2º. Restrições conhecidas, as principais, tendo surgido algo quanto a alçada, budget, equipe, dependências;
3º. Parcerias essenciais, internas ou externas com quem a área ou processo ou programa conta ou depende;
4º. Informação que lhes são cobradas, métricas, metas, indicadores e quem as solicita ou exige;
5º. Ferramentas, de forma a deixar claro quais são e eventual contextualização;
6º. Trabalho, principais jornadas, procedimentos, com selos de valor, oportunidade e prioridade.

Tivemos duas rodadas, uma com três grupos e depois com dois reagrupamentos. As diferentes áreas de atuação da equipe, sendo ensino, marketing, pesquisa e comunidade, também se optando por discutir um processo (ANA) e um programa específico de ensino;

Na verdade, iniciamos com uma lightning talk e objetivos esperados para o evento conforme o chair do board latino-americano, realizamos um quebra-gelo divertido remetendo a importância da interação e participação ativa de todos, para então fazer uma talk de uma hora com debates.

Durante a primeira hora fiz um overview metodológico, conceitual, debatendo algumas técnicas e métodos de trabalho baseados no Lean e Agile, com bastante interação e contribuições, inclusive relatos do uso de práticas semelhantes em eventos do board internacional.

Assim que decidiram os grupos de trabalho, a primeira rodada encerrou as 13:00, contando com uma apresentação e debate do mapeamento realizado por cada grupo, gerando muita interação, insights e cenários alternativos conforme percepções, conhecimento e vivências de cada um.

A tarde uma segunda rodada, redistribuindo os grupos para mais dois canvas e apresentações. Na sequência, um conceito de clusterização para tópicos mais relevantes, no quadro abaixo ao canvas, tivemos a manifestação dos pontos de melhorias mais relevantes por duplas ou individual.

O mais votado recebeu um exercício ilustrativo de brainstorming em grupo, mostrando o potencial de melhorias, certezas, dúvidas e suposições, concluindo com meia dúzias de ações distribuídas de hoje até Janeiro de 2018 para preparação de propostas de mudanças ao board ou mudar.

A ideai é estabelecer um novo mindset de equipe, baseado em princípios Lean e ágeis, com maior domínio sobre planejamento x execução x aprendizado x replanejamento, baseado em modelos PDCL e muita auto-organização.

Os feedbacks foram positivos, as perspectivas e expectativas são muito consistentes com a necessidade de mudança exigir tempo e esforço, não por deficiências, mas por realismo, em uma equipe que performa e é bem avaliada, introduzindo-se Lean Thinking para melhorar ainda mais.

Links relacionados:

 

0

Lencioni – As 5 disfunções passíveis de medir em um time

O mais famoso livro de Patrick Lencioni (2002) discorre sobre a existência de cinco disfunções a serem trabalhadas para o desenvolvimento de uma equipe de alta performance, um paradigma muito utilizado desde então, desde o meio esportivo ao de equipes em empresas.

Assim como tantas outras teorias e disciplinas que compartilho, ao convergirem aos mesmos princípios e fundamentos que balizam a formação de times ágeis, vem a corroborar metodologias e boas práticas fundamentadas em equipes auto-organizadas.

Parto do princípio de que o uso de uma metodologia ágil não garante a inexistência destas disfunções, mas um time que busca melhorar a partir dos princípios ágeis e o modelo mental cooperativo e colaborativo tende a resolver ou mitigar diariamente eventuais desvios.

É impossível não perceber o quanto cada disfunção tem a ver com princípios e fundamentos Lean, quanto a valor, auto-organização, gemba, kaizen, ainda mais se imaginarmos um time Scrum em seu ciclo contínuo de PDCL, iterativo-incremental-articulado.

Se falarmos de princípios, papéis, timeboxes, regras e artefatos, todos eles convergem para a constante pauta de uma equipe de alta performance, privilegiando confiança, confronto de ideais, comprometimento, responsabilidade coletiva e foco em entrega continuada de valor.

1. Ausência de confiança (Absence of Trust) – Confiança está no topo da pirâmide Lean do grande Samuel Crescêncio, base de qualquer princípio ágil, na transparência com realismo, inexistente se não houver confiança uns nos outros, entre os integrantes do time tanto quanto com todas as partes envolvidas e interessadas. É a base de cada reunião proposta pelo método Scrum, esperando que todos confiem uns nos outros;

2. Medo do conflito (Fear of Conflicts) – É estabelecer sempre uma saudável discussão de ideias a procura da melhor solução, base cíclica para melhoria contínua. É estabelecer objetivos comuns, fugir da zona de conforto e expressar sua opinião de forma positiva, evitar levar qualquer divergência para o lado pessoal, tanto quanto possível usar o aprendizado passado para resignificar e replanejar o futuro;

3. A falta de compromisso (Lack of Commitment) – O planejamento, a execução e resultados são comuns, coletivos, é fugir do status quo onde existe a “sua” parte e tomar consciência coletiva de que somos um time e que o resultado é a soma total de suas partes. É a base de qualquer time de alta performance, times ágeis, participar e sair de qualquer reunião com senso de pertença e compromisso uno;

4. Evitar a responsabilização (Avoidance of Accountability) – Se o resultado é de todos, se é colaborativo, cabe a cada um incentivar, apoiar, contrapôr, ajudar, questionar tudo sempre que necessário, até que a soma de conhecimentos e expertises gere a cada dia o máximo de sinergia possível. É acima de tudo relembrar o engajamento coletivo em seu máximo potencial e resultados, diferente de pressão ou imposição;

5. Falta de atenção aos resultados (Inattention to Results) – Evitar o individualismo, dispersão e desperdício, é comprometer-se do início ao fim a entrega de valor, com qualidade, de forma sustentável, mas privilegiando sempre resultados e entregas significativas. Para isso usamos ciclos iterativo-incrementais-articulados, privilegiando feedback constantes e planos de ação com foco em valor.

Em um modelo mais tradicional de liderança, a opção era estabelecer metas, métricas e monitoramento, durante décadas estabelecer pressão e exigências era a estratégia recomendada. Em Agile o investimento é no desenvolvimento de equipes e pessoas, cerne da auto-organização.

Uma tradução não literal está proposta abaixo:

1. Somos apaixonados e abertos a discussão sobre questões do time.
2. Apontamos deficiências uns dos outros de forma sincera e livre.
3. Sabemos no que colegas estão trabalhando e como contribuem para o todo.
4. Pedimos desculpas imediatas e genuínas entre nós se necessário.
5. Fazemos voluntariamente sacrifícios para o bem do time.
6. Admitimos abertamente nossas fraquezas e erros.
7. As reuniões da equipe são atraentes (não são chatas).
8. Estamos comprometido com as decisões, mesmo com inicial desacordo.
9. A moral é significativamente afetada pela incapacidade de atingir os objetivos.
10. Em reuniões, as questões mais relevantes são colocadas a mesa.
11. Nos preocupamos frente a perspectiva de não poder ajudar nossos pares.
12. Sabemos das predileções uns dos outros e estamos confortáveis em discuti-las.
13. Terminamos as discussões com resoluções e chamadas claras à ação.
14. Os membros da equipe desafiam uns aos outros sobre seus planos e abordagens.
15. O conjunto fica acima do individualismo.

0

Guia de uso para o SSC – Scrum Setup Canvas – Ed 5

Fiz um manual(zinho) para iniciantes, justificando cada campo do Scrum Setup Canvas, exemplificando estas definições pouco antes da realização de um Release Plan. Elas poderão mudar, mas precisam ser conscientes para embasar o planejamento e execução.

Boa sorte, customize, me avise se fizer alterações pois eu mesmo já o alterei bastante desde a primeira versão, agradeço a oportunidade de melhorá-lo ou pelo menos de saber de variações existentes. Coloquei lá no Dropbox, como fiz com os outros, é só baixar.

Manual do SSC – https://www.dropbox.com
Canvas em A3 – https://www.dropbox.com

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

Clique aqui para assistir a apresentação gravada por colegas no Agile Trends 2017.

 

1

Documentação é inversamente proporcional às suas boas práticas ágeis

O volume de documentação que uma empresa precisa é inversamente proporcional ao número de boas práticas ágeis que pratica, desde a relação de confiança com o cliente, interação entre as pessoas, auto-organização, qualidade, especificação tardia e excelência técnica.

No século XX tínhamos contratos rígidos, escopo prévio, preditivo e extensivo, muita desconfiança, bônus e penalidades, comando-controle e muito tempo em change management. Isso gerava baixa efetividade e qualidade, decorrente do stress e zonas de conforto gerados por isso.

No século XXI temos orientação à relacionamento, equilibrando valor e excelência, buscando eliminar todos os desperdícios visíveis em prol de valor entregue no tempo e custo, com documentação mínima, necessária e viva, valorizando boas práticas em engenharia de SW.

Confiança é a base

A mudança de paradigma faz com que clientes e usuários apropriem-se de seus projetos, participando ativamente ao invés de terceirizar o trabalho com a TI. A TI ao invés de se ver como fornecedor, assume o papel de parceiro, colaborando ativamente para seu sucesso.

O vetor mais relevante é a retirada do teatro das relações interpessoais e comerciais, assumindo-se uma posição cooperativa, mitigando a Lei do Gerson (tirar vantagem), a Lei Ricúpero (enganação), na troca de uma relação pautada na desconfiança por uma de confiança e sinergia.


imagem – http://nathandonaldson.com

Temporário ou Perene

É importante saber distinguir para si o que é documentação temporária ou documentação perene, pois usamos documentos, quadros e mapas mentais no dia-a-dia, a maioria deles de utilidade volátil a medida que o projeto segue adiante, então: Descarte o descartável.

Quanto a necessidade, é preciso entender o problema, ao invés de perguntar o que se quer, usar de empatia para colocar-se no lugar do cliente, usuários, stakeholders e equipe, entender o 5W2H dos desafios, a cada passo, temos um entendimento, alternativas e best choice.

Se você não usa conceitos convergentes, tal como domain driven design (DDD), behave driven development (BDD), Service-Oriented Architecture (SOA), código limpo e auto-documentado, … é pouco provável que documentação mínima e mapas mentais sejam suficiente;

O que vejo por aí? Documento de visão, termo de abertura, inception, casos de usos, histórias do usuário, product backlog, mapa de arquitetura, integrações, regras de negócio, protótipos com principais regras funcionais, plano e cenários de testes, mapas mentais, canvas, etc.

Novos Paradigmas

O método, tanto quanto documentação trabalham para o valor a ser gerado, jamais o contrário. O contrato e combinações é para serem usados como baliza do trabalho do time e partes interessadas, empenhadas em fazer o seu melhor dentro do custo, tempo e escopo-base;

Agile – Planejamento baseado em alto nível de abstração e complexidade, ciclos iterativo-incrementais-articulados, detalhar e tomar decisões no último momento responsável, se a arquitetura e arquitetura for legível, a documentação será mais leve e talvez temporária;

Enxuto – Privilegiar o vital e não o trivial, registrar o óbvio é inútil, foquemos no desconhecido de alto impacto, é desnecessário registrar o óbvio. Quanto mais enxuto e relevante melhor. Valor está no uso e quanto maior, menor o uso, maior o custo relativo e mais rápido caduca;

5W2H – É fundamental mapear entre os envolvidos, racionalmente cada artefato ou documento, a quem ele interessa, qual a alternativa ideal, o que é e porque existe, quanto custa a sua atualização, por quanto tempo será útil, quando deve ser feita e se permanece ou será descartada.

Referências

Há algumas cláusulas pétrias quando falamos de documentação ágil, como YAGNI (You Aren’t Gonna Need It), KISS (Keep it simple stupid), auto-documentação enquanto excelência em engenharia de SW, menor assombro (seguir padrões), DRY (não redundância), garantia de links estáveis, especialização (foco), dependências estáveis, fácil de manter, fácil de encontrar – www.agilemodeling.comwww.smartics.eunathandonaldson.com.

Documentação tem a ver com a cultura da organização, relacionamento e tecnologia, por isso tem a ver com boas práticas ágeis. A regra é trabalhar de forma fluida, sem tanto desperdício, seguindo a máxima de Pareto – Poucos Vitais para muitos triviais.

Conclusão

Sem boa engenharia de software, domain driven design (DDD), behave driven development (BDD), arquitetura orientada a serviços, código limpo e auto-documentado, … é pouco provável que uma documentação mínima e mapas mentais sejam suficientes;

Use o conceito de “Gemba” do Lean, pergunte a quem está onde as coisas acontecem, não faça documentação por idealização de quem não as constrói, mantém ou usa. Documentação boa é documentação útil, ela tem que informar coisas relevantes e serem confiáveis.

Pare de buscar receitas mágicas e aprenda a cozinhar, estabeleça uma discussão sobre sua documentação atual, perenes ou temporárias, se está lendo este post é porque já sabe o suficiente para pensar Lean, experimentar, aprender e melhorar.

0

Savana Scrum – Use a receita, experimente, aprenda e melhore

Uma equipe ágil de alta performance deve estar sempre aberta a discutir e experimentar novas ou mesmo velhas receitas na intenção de melhorar, trata-se de um modelo mental voltado a melhoria contínua, redução de zonas de conforto.

Novas e talvez velhas receitas, porque nunca somos os mesmos, como a parábola do rio no ditado chinês, pode ser que técnicas tentadas antes agora tenham sucesso, porque desde então aprendemos, crescemos e talvez agora dê certo.

Pedra que rola não cria limo!

Uma equipe que “acha” que já faz o seu melhor e recusa sugestões para tentativa de melhoria indica haver uma grande zona de conforto ágil, uma trincheira ágil, o mundo de software precisa de profissionais de olhos abertos a inquietos.

É como uma receita típica, algumas perpetuam-se, mas sempre estarão sujeitas a serem o ponto de partida para novas receitas, com novos ingredientes, não porque a receita mudou, mas porque nós mudamos e queremos experimentar.

Não é incomum ver equipes ditas ágeis entrincheiradas, alheias a percepção ou acomodadas com seus pequenos e inevitáveis desperdícios. Todo o substrato ágil baseia-se no Lean, em princípios como Gemba e Kaizen … em continuum.

Por isso ciclos iterativo-incrementais-articulados, para nos lembrar que pequenas experimentações, uma dose quinzenal de inquietação nos faz lembrar o quanto ainda temos pequenos desperdícios ou oportunidades de crescimento.

Já falei sobre a inevitabilidade de ter um formador de opinião em cada time, é importante que ele tenha consciência de que o time não é seu, que sua experiência e influência deve ser do bem, aberto, incentivando e apoiando outras opiniões.

O ideal é equilíbrio, sempre com foco em adequado valor entregue em equidade, atendendo o negócio, com qualidade e excelência, sustentável, transparentes e realistas … inspiradas em missão, visão e objetivos acordados e monitorados.

Em TI é inevitável jamais estarmos no estado da arte, esta condição não é para gerar frustração, mas engajamento ao se ter consciência do mix de oportunidades que ainda não aproveitamos. Dinâmicos em baby steps, cadenciado, confortável.

Por essas e outras é que SCRUM continua sendo o método ágil mais utilizado no mundo, porque ele  não pressupõe idealizações, mas sugere ciclos, timeboxes, que bem aproveitados manterão a equipe ligada, alerta, disposta a experimentar.

Small Project Philosophy, um pequeno projeto de cada vez, cliente e fornecedor de outros projetos em programas e portfólios. Com releases plans, sprints, experimentando, curtindo, atendendo, entregando, aprendendo e melhorando.

0

Vídeo sobre liderança ágil no Conexão KingHost OnLine deste ano

Aqui está a minha palestra sobre liderança ágil no Conexão Kinghost Online deste ano de 2017/1, mas não é só ela, no canal de vídeos do evento estão todas as palestras, vale a pena assistir, tem muito bons conteúdos – Canal Youtube

Marcelo Manuel Quádrio Raposo
51:26 – performance do banco em dia de desenvolvimento
Felipe Olivaes
57:18 – KingHost: Infraestrutura por trás do seu site
Felipe Sayão
37:38 – Utilizando Docker em Ambiente de Produção
Jorge Audy
47:28 – Liderança Ágil
José Vahl
49:10 – Os mandamentos da APIs como estratégia
Livia Lampert
38:05 – OKRs: Desenvolvimento orientado a resultados
Bruno Cambraia e Eduardo Gouvêa
47:20 – Desenvolvendo com Design Thinking
Ari Stopassola Junior e Fernando Silva
50:04 – Painel Modern PHP
Patrícia Sperk
29:52 – SEO para Dessenvolvedores
Bruno Pazzim
34:30 – Minha Experiência com o Serenata
André Brasil
35:14 – WordPress Além do Blog
Daniel Archer
34:13 – Framework e Microframeworks
Caren Cazorla
36:41 – 5 ideias para uma carreira realizadora em TI

Daniel Archer
22:38 – Painel: Segurança em WordPress
Desiree Santos
22:38 – Internet das coisas

 

0

TTalks – Keep Calm and Trust Your Product Owner

Hoje rolou o quinto dia de evento TecnoTalks 2017, os três primeiros foram três abordagens sobre planejamento de carreira, networking, meninas na TI e uma oficina, o quarto foi sobre o papel de Scrum Master e o quinto hoje foi o papel de Product Owner.

Nenhum dos cinco possui uma receita de bolo, mas todos os cinco contaram com muita gente boa, com muitos debatedores e participantes com muita experiência no assunto da rodada. As técnicas e formato a cada dia foi diferente e mesmo quando igual, melhorado ou tentamos melhorar …

O evento desta noite “Keep Calm and Trust Your Product Owner” discutiu no mesmo formato de ontem, pequenos grupos propuseram temas que desejavam discutir, clusterizamos (agrupamos sugestões semelhantes) e os clusters que tiveram mais votos foram o próprio papel e outros papéis alinhados a negócio, seguido de questões pertinentes a definição, prioridade e mudanças … valor.

20170210_002509

A primeira parte gravada em Face Live focou no que é o papel do Product Owner e o quanto outros papéis acima ou abaixo de sua alçada foram se compondo com o passar do tempo, como Chief PO, Business Owner, Analista de Negócios, entre outras siglas e funções.

O que mais se destacou no meio da discussão é o quanto diferentes contextos nos permitem defender uma abordagem, mas não que seja o melhor em qualquer contexto, há muitas diferenças que geram reflexos na melhor opção de perfil e atuação do PO, time e papeis adjacentes.

Continuação, porque minha bateria acabou, neste momento mais focados na abordagem de business, de tomada de decisão, responsabilidade na definição, mudança, negociação, para entrega de valor a cada sprint, release, até o final do projeto. Iterativo-incremental-articulado!

Novamente a discussão não era para achar uma receita de bolo ou solução mágica, mas compartilhar vivências e debater ideias, experiências e convicções, de forma que cada um dos participantes pudessem levar um mix de informações e oportunidades, acoplando a sua realidade conforme aderência e possibilidades.

Continuação parte II, porque me atrapalhei e encerrei o vídeo, mas a Andrea Balle percebeu e começou a compartilhar na sua timeline, ainda no tópico valor para o negócio, adaptação a mudanças necessárias, ROI, …

 

Ao final da noite registramos com uma foto oficial, alguns já tinham saído, mas a maioria marcou presença na foto de fechamento:

20170209_213728p

Link compartilhado pelo Parzianello – 7-skills-to-be-a-great-product-owner

Link compartilhado pelo Motta – PO-x-BA-x-analista-de-sistemas