Vinte e cinco anos do Manifesto Ágil e os métodos ágeis são um padrão no mercado, mas mesmo o hibrido conhecido como ScrumBan (*) sendo a metodologia mais praticada no mundo por equipes de desenvolvimento de software, é incrível como “auto-organização” e gestão visual ainda são mal entendidas e mal praticadas.
(*) Scrum ainda é o método que mais inspira processos de desenvolvimento de software, mas inexiste na prática Scrum sem Kanban. Todos os praticantes do método Scrum, sempre usam quadros kanban e a partir deles adotam muitos de seus princípios e práticas … poucos admitem, mas todos são de fato mais hibridos Scrumbans que Scrum ou Kanbans.
Quanto a auto-organização, é fácil ficar na superfície, adotar um método, fazer lean inceptions, usar sprints (**), papéis e reuniões, usar quadros de tarefas e outras práticas. Mas, acabam mascarando a essência da agilidade, a antecipação de aprendizados, adaptação e melhoria contínua – transparência, inspeção e adaptação.
(**) Não importa se chamam de Sprint ou Iteração, são ciclos iterativo-incrementais normalmente de duas semanas, um instanciamento do conceito básico do ancestral ciclo PDCA (plan-do-check-act). Tenho um post de 2018 que explica o porque não basta ser iterativo-incremental, é preciso ser iterativo-incremental-articulado (inspect and adapt).
Desde a pandemia, o uso dos quadros brancos virtuais se tornaram uma presença constante, entretanto, seu uso é ainda muito primário. Todo projeto deveria ter um whiteboard (ex: Miro) e todos eles deveriam ser uma a sua central nevralgica, multimídia, hipertexto. A alusão é de um diário de bordo … se é importante, estará lá!
No quadro abaixo, o board de um pequeno projeto que organizei semana passada e facilitarei esta semana. Ele está em sua segunda sprint e não tinha um quadro que centralizasse e facilitasse sua condução. Ainda faltam informações, que estou colhendo para resgate e registro inicial, mas temos da esquerda para a direita:
- Preparação – Informações, links, arquivos, vídeos, pesquisas, etc;
- Inception – Briefing, visão, personas, jornadas, features, combinações e plano;
- Baselines – Desde a baseline #1, abrindo novas conforme o plano mude;
- Regras – Manual do processo, roteiros, responsabilidades e regras explícitas;
- Links – Todos os links de artefatos e ferramentas (repos, wiki, boards, guias, etc);
- Sprints – Neste caso, usam Scrum, logo, temos espaços fixos para:
- Refinamento e Planning (dados da selected backlog e sprint backlog);
- Diário de bordo (registro de ocorrências, impedimentos e métricas);
- Sprint Review (Ata da review, especialmente entrega x feedbacks);
- Retrospectiva (registro das dinâmicas e plano de ação / itens de ação).

Esta abordagem pode variar e potencializar o quadro conforme aspectos e práticas singulares de cada projeto, mas independente de método ou abordagem, adaptasse e oferece uma visão 360° de todo o projeto. Isso garante organização, rastreabilidade, é ferramenta essencial para a auto-organização, e gera um encadeamento incrível de causa-efeito.
Nunca cheguei ao limite do Miro em espaço ou elementos, logo, o desafio é de organização espacial, os elementos não podem estar dispersos de forma não estruturada. É importante usar boxes, frames, títulos, cores, … afinal, o board não pode ser dependente de quem criou, deve ser facil para qualquer um se localizar, interpretar e dar continuidade.
PREPARAÇÃO OU PRÉVIAS
Cada vez mais temos projetos com uma etapa robusta de Design Thinking, alguns projetos possuem fases específicas de pesquisa e preparação. Este quadro pode e deve estruturar de forma organizada e inteligível estas fases preliminares ou gerar um bom e assertivo resumo, oferecendo os links para os Miros ou Materiais originais.
No caso de treinamentos, idem, é possível resumir, embedar ou oferecer os links dos materiais didáticos de forma a potencializar seu uso. O Miro permite inclusive a importação acionável de PDF’s ou mesmo apresentação página a página. A preparação pode ter sua própria estrutura a esquerda.
INCEPTIONS
A dinâmica de Inception deve estar inclusa no board, pois é parte fundamental a rastreabilidade de suas dinâmicas, informações e resultados. Não importa a técnica, se uma Inception customizada (como eu sempre adoto), se uma Lean Inception ou Product Backlog Building, o Miro tem todos os recursos.
Quando realizo Inceptions presenciais, sempre há uma ata ou relatório final com fotos e principais informações desde o briefing até o plano final, que eu incluo no boar de projeto. Mesmo que sejam apenas fotos (nunca é), o registro é importante no quesito transparência, colaboração e sempre nos fará refletir, aprender e melhorar.
BASELINES
A primeira baseline tem no quadro de justificativa as regras para a criação de novas, nas seguintes este espaço contará com o registro dos fatos que nos levaram a sua criação (negociação, impedimentos, ausências, desvios, etc). O importante é copiar a última baseline, colá-la abaixo, fazer as mudanças (inclusões, exclusões, alterações) e registrar a justificativa.

SPRINTS OU ITERAÇÕES
Tem diferentes formas de estruturar as Srints ou iterações, mas manter um registro mínimo de cada um dos passos (planejamento-diário de bordo-review-retrô) é muito importante e retroalimenta possíveis novas Baselines. A cada nova Baseline é importante manter o frame de justificativa, contextualização ou negociação.
O ideal é que o time perceba o valor agregado por este registro, se apropriando disto. Não é papel do agilista, facilitador ou scrum master, todos podem e devem contribuir. Durante uma reunião, é comum um facilitador fazer registros e prints, mas na ausência de um, qualquer integrante pode puxar para si … o tempo dedicado ou perda é mínimo.

REGRAS EXPLÍCITAS e LINKS ÚTEIS
Para efeito didático e oferecer mecanismos que facilitem qualquer um entender, participar ou mesmo eventualmente conduzir cada momento, os quadros de Regras e Links devem garantir que todos tenham fácil acesso a estas informações de forma organizada e estruturada no próprio board.
Cada time tem suas próprias regras, quer sejam inspiradas no Scrum, Kanban ou hibridos. O importante é debatê-las no início, registrá-las e melhorá-las explicitamente sempre que possível, provavelmente fruto das retrospectivas. Qualquer integrante deve se sentir dono, pode alterá-las, mas deve ser resultado de uma discussão do time.

