1

NÃO entregar valor NÃO é opção em uma sprint

A cada dia em um projeto SCRUM é preciso relembrar Pareto (80 x 20), bem como buscar inspiração na técnica de caminho crítico. Desde o release plan, product backlog e sprint backlog, daily e pós-daily, review e retrô, o discurso de valor é legal, mas só vale se entregarmos valor.

Quando cito Pareto em projetos, tem o estratégico pela necessidade do cliente e usuários, o tático na complexidade e capacidade, tem o operacional de cada dia, a nível de tecnologia, requisitos, funcionalidades, regras, … temos então nossa rede mental e caminho crítico.

Pareto: A regra dos 80/20 ou Lei dos poucos vitais para muitos triviais, afirma que aproximadamente 80% dos efeitos vêm de 20% das causas. Um dos ícone do Lean, a lenda Joseph Moses Juran, sugeriu este princípio e o nomeou em homenagem a Vilfredo Pareto e seus estudos.

Áreas de Convergência/Divergência: O caminho crítico é uma sequencia de atividades que representa o caminho mais longo de um projeto. Área de Convergência é quando várias atividades devem concluir para outra iniciar, Área de Divergência é quando uma é pré-requisito de várias.

Assim como um bom gerente de projetos, uma equipe ágil lida diariamente com a possibilidade de tomada de decisões relacionadas a riscos, rede, fragmentação, inclusão e exclusão de atividades, paralelismo e sequenciamento, recursos essenciais para auto-organização e sucesso.

Em uma liberdade poética, trago uma rede e seu caminho crítico propostas pela UniversoProjeto para discutir conceitos de caminho crítico, não representa a estratégia de histórias e tarefas em uma sprint mas é didática quanto a caminho crítico e áreas de convergência e divergência:

Em Agile, cada história possui sua rede no sprint, gerando um desafio tático diário ao time, como na abstração que montei logo abaixo … a entrega do mínimo valor (vitais) de qualquer história não pode ser comprometida em função de entregas triviais de outras histórias:

Diariamente, a cada novo fonte, objeto, classe ou método é preciso perceber o caminho crítico e lembrar de evitar triviais antes de vitais, valorizando eliminar gargalos e garantir entregas antecipadas, parciais, essa é a nossa missão: Entregar valor!

As vezes usamos de dissonância cognitiva para justificar o porque não vai ser possível, esquecendo de se utilizar de uma visão holística, onde o todo é composto de partes … equipes ágeis de alta performance esforçam-se em entendê-las e tomam decisões para garantir entregas e valor.

Acredite, adaptar-se não é resignar-se a inevitabilidade das mudanças, é diariamente mitigar, contornar, fracionar, eliminar ou reduzir áreas de convergências e divergência, focar na essência, de forma que a adaptação não seja a negação do valor, mas a confirmação dele.

Cada SPRINT é um pacto por valor a ser entregue

Planejado na inception e materializado no product backlog, a sprint backlog é um pacto gerado pelo time entorno do mix de domínio, conhecimento, expertises e percepções de todos, levando em condição valor, prioridade, complexidade, riscos e oportunidades.

A cada Daily e pós-Daily, nossa missão é repactuar o sucesso de nossas entregas, mitigando riscos, sempre focados no mínimo entregável de valor suficiente, sempre investindo no vital e questionando o trivial, justificando assim o porque do método ágil que praticamos.

Na medida que o sprint avança, a responsabilidade e necessidade de planos de ação e responsabilidade na aplicação de árvores de decisões vais tornando-se cada vez mais premente. No 1° dia, 2° e 3° temos mais opções, a partir do 4° e do 7° temos menor margem para manobras.

Estudo de caso: Em um cenário adverso, no segundo dia foi discutido opções e assumidos certos riscos, no quarto dia já é preciso concentrar esforços e no sétimo dia muitas vezes temos que tomar decisões difíceis, mas responsáveis frente ao compromisso de entrega de valor.

Para ser mais claro, quando falamos no sprint planning sobre compromisso com a excelência combinada, características funcionais otimizadas, regras, automações, camadas, etc, isto NÃO pode ser mais importante que a entrega, validação com o cliente, fluxo e cadência.

Se decisões tiverem que ser tomadas, ok, vamos depois discutir o porque foi preciso, vamos aprender com elas, vamos nos esforçar por melhorar nos próximos sprints, vamos incluir a discussão sobre o resgate e refatoramento do gap entre o que foi previsto versus o que foi feito.

Falando em valor e sprints, cuidado com o que promete, pois és responsável por quem cativas e NÃO entregar o máximo de valor a cada sprint NÃO é opção! O desafio e a solução todos terem este princípio em mente, sem stress, mas antenados ao máximo de entregas de valor.

Nossa linguagem ubiqua foca em valor para o cliente, se você mesmo assim não abre mão de atrasos por excelência técnica, em detrimento de valor antecipado, validação e aprendizado – PDCL – Desculpa, mas talvez seja uma linguagem ambigua e não ubiqua.

Se leu até aqui, tenho certeza que vai curtir ler esse outro, garantcho:  https://jorgeaudy.com/2014/11/04/divida-tecnica-um-mal-necessario-mas-nao-e-um-carma/

2

Storytelling – Jorge Audy, 10 anos de Agile

Ao fazer um relato de meus três anos de DBserver, percebi que em 2008 há exatos 10 anos atrás eu desci para a área de produtos digitais. No dia anterior eu era coordenador do projeto MPS-Br no corporativo, no dia seguinte assumi equipes digitais que vinham tentando Agile … minha história começou a mudar e não parou desde então, o tempo passou, fiquei 10 anos mais velho e mesmo assim me sinto 20 anos mais jovem \o/

Para registro histórico, um storytelling navegando desde o ano de 2008 quando assumi a coordenação de desenvolvimento das equipes da área de produtos digitais do Grupo RBS até hoje. Quem quiser comentar, comenta aqui \o/

2008 – No ScrumBut até cair a ficha

Após 7 anos de ADP Brasil como coordenador de desenvolvimento corporativo, envolvido com equipes no ERP JDEdwards, operação, web corporativa e print center, fui contratado pelo Grupo RBS em 2007. Em 2008 troquei a TI corporativa pela coordenação de desenvolvimento da área de produtos digitais responsável pelo ClicRBS, ZH, Hagah, Pense, rádios, TV e jornais.

Praticamos um ScrumBut de 2008 a 2011, ano em que sob a direção do Alexandre Blauth, gerência do Marco Migliavacca, mentoria do Luiz Cláudio Parzianello e pareando com a colega Cintia Lima imergimos uns no Agile Brazil de Fortaleza e saímos outros do outro lado. Fui de gravata e espírito comando-controle e me ví na volta ainda no avião preparando um plano de ação revolucionário.

Estávamos em Julho, mas em Novembro nos mudaríamos para o quinto andar do prédio 99A do TecnoPUC, o desafio era praticarmos Agile e chegarmos aquele novo ambiente já com boas práticas ágeis ou esperar para nos mudarmos para um ecossistema ágil ainda com mindset tradicional e com muito a fazer … mudar, experimentar e aprender ou esperar a pressão do simbolismo da mudança?

2011 – Mudança em ritmo antecipado e acelerado

Entre Agosto de 2011 e Novembro, quando da mudança para o TecnoPUC, lançamos o desafio de treinar e começar a praticar, experimentar, aprender mais e nos desafiar estarmos prontos para um andar e um ecossistema que exigiria muito de todos nós. Eu e a Cintia realizamos dezenas de treinamentos Agile e Scrum, em três etapas, cinco turmas em cada.

Em Agosto foi um mínimo necessário de mindset, auto-organização e retrospecticvas, alguns destaques como a reversão de alguns projetos como o RuralBR e referência do piloto com o Hagah, seguido de todas as demais equipes, em Setembro foi Kanban e em Outubro foi a totalidade do método Scrum e Kanban.

2012 – Uma revolução em todos os sentidos

Os treinamentos e coaching que puxamos a partir de Agosto e a ida em Novembro para o TecnoPUC foi o precursor de uma revolução, nada mais foi o mesmo depois disto. Os treinamentos e rollout de metodologias ágeis, compartilhando nossos estudos e vivências não pararam mais, áreas corporativas e veículos com quem interagíamos a cada projeto eram treinadas e incentivadas à prática.

Daquela época, tenho até hoje grandes amigos que levaram a todo aquele aprendizado, outras empresas e áreas de atuação, um período em que comecei a participar de GU’s, CoP’s, eventos locais, regionais e nacionais, aprendendo com os grandes nomes do Agile brasileiro e compartilhando minhas experiências em Agile para pessoas e empresas.

Naquele ano iniciei a Comunidade de Práticas chamada TecnoTalks que hoje conta com 2500 integrantes, entrei para a equipe de coordenação do Grupo de Usuários de Métodos Ágeis da SUCESU-RS e lancei meu blog – http://JORGEAUDY.COM – que hoje conta com 900 posts, onde compartilho conteúdo, resenhas de livros e artigos, ebooks, propondo técnicas e team buildings, além de compartilhar uma agenda de eventos.

2013 – Mestrado e a busca por novos caminhos

Em 2013 eu iniciei o meu mestrado, pedi as contas no Grupo RBS e iniciei um trabalho como consultor e Agile Coach com a Software Process, realizando especialmente um trabalho na TNT/Mercúrio que em pouco mais de meio ano, pilotos e rollout com grandes profissionais, toda a área de TI estava na mesma batida, praticando Agile. Outro trabalho pela SW Process foi com a SABEMI.

Meu mestrado foi na FACE em Administração, na linha de pesquisa de Gestão da Informação, a dissertação foi com o tema “Adaptação à mudança nas características do trabalho : níveis de demanda e controle durante a adoção do método ágil SCRUM por equipes de desenvolvimento de software“, com estudos de casos em empresa privada e pública.

11822844_980444522008498_2202527865377809030_n

2014 – Em Julho iniciei na DBServer

O meu primeiro semestre na DB foi alucinante, iniciando com treinamento SCRUM 360º e consultoria para a Grendene no projeto piloto SCRUM de “Report de Qualidade” envolvendo a área de exportação e clientes estrangeiros, mas em Setembro iniciou a maratona do SERPRO, como Agile Coach, com treinamentos SCRUM 360° em regionais (SP, RJ, BA, BSB, SC, PE, AL, PR, RS), consultoria em 2 projetos piloto (SC, RJ) com procuradoria geral e tesouro nacional.

Neste ano lancei o livro SCRUM 360°, uma primeira edição independente e uma segunda com a Casa do Código, uma publicação diferente das demais que falam do todo, pois a proposta era falar de fundamentos, bases psicológicas e sociológicas, mais que técnicas e ferramentas, o que há por trás dos papéis, a natureza humana das timeboxes, artefatos e regras.

2015 a 2017 – FACIN, Livros, Eventos, Projetos

A partir de 2015, terminado o mestrado, fui convidado e sou professor na FACIN da PUCRS nas disciplinas de Tópicos Especiais em Engenharia de Software e Gerenciamento de Projetos, ao mesmo tempo em que consultorias, pilotos e coaching iam se desenrolando pela DBserver, aqui no RS principalmente, mas com interações em SC, PR e SP.

Em 2015 lancei meu segundo livro, chamado JOGOS 360°, ilustrado e colorido, com encarte A3 de referência, um livro em parceria com minha filha, ilustradora e graduanda de cinema na PUCRS responsável pelas ilustrações e encarte.

Em 2016 lancei o meu terceiro e último livro, uma franquia na verdade, TOOLBOX 360°, além dos posts no blog e o livro, em 2017 lancei o DESAFIO TOOLBOX 360°, apresentado em workshops nos principais eventos ágeis brasileiros.

Neste ínterim propus algumas técnicas, como alguns quadros de alçada, Diário de Bordo, o SCRUM SETUP CANVAS, uma técnica de análise de documentação e alguns ebooks úteis sobre teorias e modelos (Sobre os Ombros de Gigantes) e Guia Geral sobre adoção ágil.

Em 2017, também com minha filha é claro, lançamos as tirinhas do SAVANA SCRUM para falar das idiossincrasias e aprendizados ágeis na forma de personagens lúdicos e divertidos, com grande potencial de crescimento.

Um período intenso em participações como palestrante em eventos – DBTalks, TecnoTalks, Agile Brazil, Agile Trends (troféu de melhor Trend Talk), TDC’s POA e Floripa, NeoTalks NeoGrid, RAIAR, ADP Labs, Agile Day Gerdau, Conexão King Host, SEPRORGS, Quarta do Conhecimento PROCERGS, Fale com o Coach SERPRO, Semanas Acadêmicas e Feira das Profissões PUCRS e IFRS, FISL, Congressos do PMI-RS (IX, X, XI e XIV), BPW na FNAC, RED #1 e #2, GUMA, LA SALLE, UEBRS, Faculdade DOM BOSCO, entre outros.

Projetos mais significativos para mim entre 2015 e 2017:

DEFENSORIA PÚBLICA do RS – 2015 – Treinamento, consultoria e Agile Coach à equipe piloto do portal do defensor, com duração de um ano, desdobrado em um segundo piloto (Agenda).

DIMED – 2015 – Treinamento e consultoria para o projeto piloto SCRUM “Panvel na palma da mão” e planejamento do programa para a primeira Panvel em SP prevista para Abril de 2016 envolvendo projetos de todas as áreas da empresa;

PROCERGS – 2015/2016/2017 – Treinamento e consultoria Scrum junto a equipes da fábrica interna, sustentação e um processo continuado de Lean Thinking junto a DRC (equipe de analistas de negócios) ajudando a resignificar missão, visão, objetivos e planos de ação;

SICREDI – 2016/2017 – Já foram mais de 25 turmas com média de 30 participantes em um treinamento de Nivelamento Ágil que criei especialmente para mais de 700 profissionais. Para eles desenvolvi o jogo Banco Intergaláctico para experimentação lúdica de Release Plan e Sprints de um ATM em papelão e telas através de papel colorido, tesoura, cola, régua, … Além disso, planejamento e primeiro MVP projeto técnico para crédito rural.

PROCEMPA – 2016 – Agile Coach, treinamento e consultoria envolvendo quase todas as áreas da empresa, com projetos piloto Scrum em todas as equipes de desenvolvimento. Uma oportunidade única foi a facilitação de uma dinâmica de gestão de portfólio para os últimos três meses do governo municipal em 2016, com presença do prefeito e secretários municipais sobre projetos para o centro da capital;

SISPRO – 2016 – Treinamento e consultoria Scrum e Kanban nas equipes de ERP e serviços, com coaching a dois projetos-piloto;

RENNER – 2016 – Treinamento e consultoria Scrum em um projeto-piloto envolvendo a área de varejo, contando com treinamento de lideranças e interações junto a equipes de fábrica;

GETNET – 2016 – Desmistificando Agile, treinamento e consultoria em projeto piloto DSDM batizado de Falcão Peregrino, metodologia adotada por recomendação do Gartner;

UNICRED – 2016 – Treinamento e consultoria com dois projetos pilotos – gestor de negócios e evolutivo da solução de caixa;

ZAFFARI – 2016/2017 – Treinamento de todas as equipes de TI e consultoria em projetos Scrum para dois pilotos – jurídico e app;

GVDASA – 2017 – Agile Transformation do maior ERP brasileiro de educação, equipes Scrum para projetos, Kanban para sustentação e Lean Office para áreas de consultoria, suporte e apoio;

SOFTPLAN – 2017 – Consultoria em Scrum dentro de uma prática SAFe junto as áreas de procuradoria (3 equipes) e tribunais (10 equipes), além de coaching para adoção ágil na equipe de DevOps;

JCME e Rede Marista – 2017 – Facilitação no planejamento ágil de solução estratégica para congregações e inscrições escolares.

Afora estas oportunidades na disseminação e trocas de boas práticas, foram múltiplas palestras e workshops junto a outros clientes e prospects, a maioria no RS, mas muitos em outros estados, sempre sobre Agile, como Scrum, Kanban, Lean Office, Team Building Games, Toolbox, Agile Transformation, Liderança Ágil e facilitação.

Ainda tem muito 2017, mas já prevejo um 2018 cheio de novidades e desafios.  \o/

0

Tem o 5W2H, Managing Dojo, Learning 3.0, mas não esqueçam do A3 Report

É fundamental ter diferentes técnicas que orientem e organizem discussões para resolução de problemas, aproveitamento de oportunidades, desafios de inovação e superação. Eu chamo de Toolbox 360º, lancei um livro e um jogo de tabuleiro com este objetivo, provocar profissionais a refletirem sobre o mix de técnicas que domina e lança mão conforme necessidade.

Tenha e amplie sua toolbox permanentemente, lembre-se da alegoria da caverna de Platão e do ditado popular, porque para alguém que só conhece o martelo, todo problema parecerá um prego:

O uso de técnicas de gestão visual, mapas mentais, 5w2h, managing dojo, learning 3.0, entre outras, conta também com a dinâmica Lean conhecida como A3 Report. Trata-se do instanciamento dos princípios básicos do Lean – fracionar, descentralizar, antecipar mais valor, alta performance, eliminar desperdícios, aprender e melhorar continuamente, ver o todo, …

PDCA – Estabelecido um desafio, o tema da discussão, direcionamos a discussão a resultados, iniciando pelo entendimento, efeitos e causas, alternativas e plano de ação, como monitorar sua evolução e resultados, de forma iterativo-incremental, aprendendo e melhorando a cada ciclo.

Plan – Qual o desafio e sua relevância, valor; histórico, se algo já foi feito e se há contingenciamento; se possível incluindo algo explícito e visual como dados diagramáticos, números; com exercício de análise causal, 5W2H, CSD, Ishikawa ou Pareto;

Do – Frente as causas e efeitos analisados, qual o plano de ação, contando com aquelas informações necessárias para entendimento mínimo ne planejamento, como tempo, recursos e responsável, qual o resultado esperado a cada passo e final;

Chek – Quais as métricas e indicadores a serem utilizados para monitoramento e controle, com que frequência serão medidos, preferencialmente de forma auto-organizada pelo próprio time; favorecendo percepção de riscos e correções de rumo;

Act ou Learn – Aproximando participantes e stakeholders, com comunicação explícita e assertiva frente a objetivos de valor, com gestão do conhecimento (tácito-explícito) e conversão em aprendizado e correções para um novo ciclo de sucesso;

Ao procurar na internet por A3 report, explicitamente recebemos centenas de páginas sobre o uso desta técnica e assemelhadas, não só no contexto Lean fabril, mas até mesmo em referências ágeis como na Scrum Inc em um exercício sobre a não entrega de valor por sprint:

Uma página me chamou a atenção, com múltiplos exemplos e boa didática, impossível ler este post do Edson Miranda da Silva e não entender a técnica em sua plenitude – https://qualityway.wordpress.com/2017/05/04/a3-passo-a-passo-com-exemplos-reais-por-edson-miranda-da-silva/

 

0

Kirkpatrick – O que seria de nós se não soubéssemos das curvas?

Há diferentes teorias e curvas que reiteradamente discuto e que nos ajudam a entender o processo cognitivo e desafio relacionado ao aprendizado, mudança e melhoria, como a Curva de Tuckman para formação de um time, hoje vou compartilhar a Curva de Kirkpatrick.

Em 1994, Donald Kirkpatrick publicou um bestseller intitulado Avaliando Programas de Treinamento, apresentando quatro estágios relacionados aos possíveis desdobramentos de um treinamento, gerando o que chamou de reação, aprendizado, comportamento e resultados.

O entendimento de Tuckman, Ebbinghaus, Kirkpatrick e outras, nos ajudam a entender antecipadamente os porquês e de posse destas informações trabalharmos desde cedo com argumentos e ações para gerar maior efetividade na formação e evolução de nossos times.

Vejo isso a cada treinamento, a curva sobre a conversão de ensino em aprendizado e sua conversão em prática, os estudos de Kirkpatrick lançam luz e nos ajudam a melhorar enquanto palestrante, instrutor, professor, facilitador e/ou coach.

Vai além da Curva de Ebbinghaus sobre nossa capacidade e limitação de retenção e assimilação, também Edgar Schein, lembrando que a mudança gera desconforto quando percebemos que deixaremos o conhecido para tentar algo novo, que ainda não dominamos.

Eu tenho uma matriz temporal de condução para qualquer treinamento, conhecida por quem me acompanha, com um pré (organizar e instigar metas), há a execução (interagir e projetar) e um pós (experimentar, persistir e melhorar), onde acrescentei a curva de Kirkpatrick:

Em seu estudo Kirkpatrick estabeleceu ranges para cada etapa, mas como agilista eu acredito que cada pessoa, imerso em times e cultura organizacional, estabelecerá um ritmo para seu grupo, conforme liderança, metodologia, maturidade, domínio, etc.

Conhecer as diferentes curvas nos ajudam a agir para torná-las mais fluidas, gerando maior retenção e conversão em resultados práticos. Mantendo a reação em seus insights, o interesse no aprendizado, a pró-atividade do comportamento e persistência até os resultados:

1- Reação é quando o aluno ou participante percebe que aquele conteúdo tem a ver com ele e que pode ser útil de alguma forma, colaborando para possíveis melhorias no seu trabalho ou a ele enquanto pessoa. Refere-se a interesse e a maioria se motiva!

2- Aprendizado é quando o aluno ou participante se mostra interessado realmente, interagindo com o instrutor e demais participantes enquanto traça cenários imaginários de uso e projeção de resultados. Diz respeito a entendimento e planejamento!

3- Comportamento é quando o aluno ou participante estabelece uma experimentação e aprendizados, permitindo-se mudar para tanto. Diz respeito a vivência e validação, exigindo engajamento e persistência!

4- Resultados é quando estabelece-se aquilo que chamamos de melhoria contínua, os resultados já são percebidos e os mesmos são valorizados. Refere-se a evolução proposta pelas artes marciais como Ju-Ha-Ri, adaptando e tirando o máximo de benefícios.

Em treinamentos é preciso instigar pessoas a serem agentes de mudança, não desistirem e serem exemplo. A psicologia afirma que todo grupo humano possui lideranças ou formadores de opinião, o tempo e o sucesso de um processo de mudança depende muito do exemplo deles.

 

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.

1

Ao iniciar, mapeie seu contexto técnico, humano e metodológico

Um planejamento de Releases é feito em alto nível de abstração, baseado na percepção de complexidade sobre algo minimamente conhecido, mas para fazê-lo com sucesso é preciso estabelecer prévias combinações sobre tecnologia, humanas e metodológicas. No início, mapear quem somos e o que temos, maior será a probabilidade de cumprir entregas de valor. Muitos focam em histórias e Sprints, mas o que mais vejo pegar é pacto de time, transparência, autoconhecimento com realismo, desarmar egos e máscaras.

Usar metodologias ágeis não isenta da responsabilidade com o que está a sua disposição e que faz a diferença. Domínio? Restrições? Riscos? Tecnologia? Mapa de competências e expertise? Oportunidades? Expectativas? Buscar conscientemente o ponto de equilíbrio disso tudo. David Hussman propôs a Lei de Dude [Value = Why / How], se fizermos uma analogia com futebol, para jogar é preciso saber as regras e a mecânica de jogo, habilidades necessárias para montar um time, treinar fundamentos, acima de tudo é um exercício de trabalho em grupo.

dude-s-law

1. Dedique um turno para discutir e explicitar um diagrama de blocos ou mapa de tecnologia, esclareça arquitetura, ferramentas, boas práticas, método, como vocês irão construir software de qualidade e valor, cada opção tem riscos e oportunidades, acelera ou contêm. Isso pode ajudar a planejar Sprint Zero, Provas de Conceito, Spikes, incluir Buffers, parear com especialistas, treinamento, técnicas possíveis e factíveis, enquanto alguns preferem “ter pressa” e mascarar, auto-enganar-se por medo ou arrogância, alguns assumem, outros vão enrolando.

2. De posse de um mapa tecnológico, na forma que for, de blocos, hierárquico, floco de neve, podemos nele próprio identificar riscos e plano para aceitação, mitigação, transferência, o que evitar ou explorar, uma das opções é desdobrar em um mapa de competências. Uma técnica vencedora foca em todas estas competências em um time, quer conhecimentos, habilidades, atitude, cognição, modelos lastreados no interesse em sermos sinceros e realistas com o que somos e sabemos, alimentando planos de ação (use postits pequenos verdes, amarelos, vermelhos).

3. Finalmente, como regra para equipes ágeis que pretendem planejar um projeto, é preciso estabelecer formalmente os acordos sobre os quais balizaremos nossas estimativas e técnicas de planejamento, de forma assertiva sempre, clara, realista. Minha sugestão é o artefato abaixo, um canvas para as combinações iniciais, vivas, que sustentarão o racional para uma inception ou técnica que se escolha para planejamento. O objetivo não é um contrato, mas consenso naquilo que é mais importante, porque tecnologia em projetos também devem ter seu MVP.

Uma dica importante, evite incluir em um mesmo início de projeto novidades demais, se uma equipe idealizar demais assumirá o risco de nada entregar, pode até ser desejável, mas não é responsável. Garanto que as equipes que não procedem desta forma, sempre acabam achando como solução culpar alguém, um arquiteto, gestor, cliente, PO, SM. Não há agilidade que resista a só quando tudo der certo.

Agilidade é antecipar e acordar o que fazer com cada risco e oportunidade, não é disputa nem transferência, é convergência responsável! Um bom quebra-gelo pode ser uma SWOT com a imagem do barco (forças/fraquezas) com o iceberg (riscos) e a ilha (objetivo), desconheço o autor original, talvez o Paulo Caroli, mas eu curto muito a plasticidade da imagem.

 

0

Desculpa, mas agile não é trincheira … pronto, falei!

A maior quebra de paradigma do nosso tempo não é usar design thinking, lean startup ou métodos ágeis, nem Angular, NodesJS ou microserviços, o desafio é termos profissionais mais conscientes, colaborativos, transparentes e realistas.

Mudar de método de trabalho e adotar novas práticas é sim um desafio, porém se não mudarmos o modelo mental e hábitos ancestrais, será tão somente um novo processo de trabalho para servir de zona de conforto, cada um no seu quadrado.

A pergunta não é se somos ágeis, mas se trabalhamos para nos tornarmos equipes de alta performance, porque agilidade é meio, trabalho em equipe, valoroso, colaborativo, sustentável, positivo, os resultados são o fim.

Nossa crença é que esse meio, com ambientes e equipes ágeis, suscitaremos melhores resultados a todos. Sem resultados e valor, sua agilidade não se sustentará muito tempo.

Trincheiras

Mesmo entre aqueles que se dizem ágeis, muitos misturam “reclamação” com transparência, apontar culpados com “eu fiz a minha parte”, “alertam” problemas esquecendo que nosso papel é mitigar, contornar, resolver … ver um problema é só o primeiro passo.

Eu acredito muito na frase “Esperamos que as retrospectivas façam o seu trabalho!” mas, se o resultado recorrente de uma retrospectiva é listar problemas dos outros, não é retrospectiva, é trincheira.

Muitos agilistas reclamam de problemas que eles próprios viram começar, crescer e se estabelecer, apenas assumindo o papel de arautos da verdade dos outros, apontando o dedo e deixando o seu projeto ir pro beleléu, mesmo com opções de contorno.

Construção

Há uma estrada longa para colher o que não plantamos ainda, caso ainda não usemos Lean Business Analisys, DDD, BDD, clean code, XP, DevOps, haverá muito o que fazer e consolidar para aos poucos estabilizarmos nossa realidade.

Muitas vezes eu escuto de equipes que o seu cotidiano é estressante, mas ao averiguar, não é nada além do cotidiano de uma área que lida com a complexidade inerente a software e ao imediatismo no caso de problemas em produção (legados).

Se vamos trabalhar 8 horas por dia em projetos que mexem com os destinos de empresas, áreas, produtos, serviços, mas ainda não temos um bom pack de boas práticas, querer que não hajam momentos de tensão é impossível, temos que saber lidar com eles enquanto evoluímos.

Poupança

Muitas vezes eu comparo uma empresa ou equipe que começa a adotar Agile como alguém que abre uma poupança, teremos que fazer vários depósitos pequenos para hora dessas termos um montante legal … não é imediato.

Projetos e tecnologia é igual, temos um débito técnico gigantesco, legados, falta de boas práticas variadas a cada passo, mesmo assim muitos acham que o simples fato de decretarem que se tornaram ágil esse histórico desaparecerá …

Desculpa aí, mas é o mesmo que um eu de repente decidir usar calça número 39, para isso acontecer vou ter que me empenhar a baixar do 42 para o 39, melhorar hábitos alimentares, academia, retomar os percursos diários de bike.

Adotar Agile para o modelo de fluência do James Shore pode exigir de 4 a 5 anos de dedicação, porque envolve cultura, envolve gente, hábitos, costumes, é preciso crença e dedicação, flexibilidade, jogo de cintura, é preciso ser ágil na agilidade.

Agile é valor entregue

Se há algo errado, propomos alternativas, qual a melhor delas e argumentos, mesmo assim, quem decide as vezes pensa diferente, reclamar e emburrar não é solução, só piora, é preciso tentar fazer dar certo … o que estiver ao nosso alcance!

Toolbox, foco na entrega de valor, o objetivo é sempre buscar uma técnica que melhor enderece, o que pode ser feito para resolver ou mitigar? Se necessário, excepcionalmente, stop the line e replanejar.

Trabalhar em equipe ágil não quer dizer unanimidade de opinião, mas debate e tomada de decisão coletiva e colaborativa … depois é trabalhar nos termos que ficaram definidos, mantendo um ambiente positivo e profícuo.

Quer saber? Gostaria de ser uma mosca e poder assistir incógnito alguns agilistas de boutique se “adaptando” as idiossincrasias de suas empresas, contratos e clientes … porque agilidade na vida real exige muita resiliência até que teoria e prática se encontrem. Agilidade, sustentabilidade e sinergia não são disciplinas que acontecem por decreto … é algo que construímos aos poucos, um passo de cada vez, as vezes para a frente, as vezes para os lados ou mesmo para trás. Ficar idealizando, de mi-mi-mi, só empata mais ainda. Pode demorar anos, enquanto isso, temos que ir lá e fazer, ganhando créditos, avançando, baby steps, menos mi-mi-mi e mais pés no chão por favor!

mosca

Post difícil, tabu, dá vontade de escrever mais 2 laudas, mas até aqui já expressa por alto meu sentimento.