Dojo Boshú – A escolha da equipe e projeto piloto

Já tenho vários posts sobre minha proposta ao criar o conceito de Dojo Boshú, mas este aqui com esta abordagem e didática é especial. Dojo Boshú (seleção ou escolha em japonês) é uma técnica abrangente, adaptativa, criada por mim com o intuito de identificar o trabalho de reunir-se para escolher algo, quer seja um projeto, equipe, pessoa, técnica, parâmetros, … para início ou evolução de um trabalho relacionado a métodos ágeis.

O quórum tende a ser abrangente, reunidos por um par de horas, no máximo um turno, com lideranças e integrantes das equipes envolvidas, de TI e não TI. É adaptativo porque as técnicas e artefatos utilizados dependem do contexto e condições, podendo lançar mão de um mapa de projetos candidatos, mapa de equipes, tecnologias, Business ou Project Model Canvas, Scrum SetUp Canvas, etc.

Um bom Boshú sempre começa por um bom quebra-gelo, quer entre 5 ou 15 participantes, preferencialmente um jogo que provoque a galera a sair da zona de conforto, como o Marshmellow Challenge Ágil, o Boneco Ágil, de crriatividade como o da laranja, instigando a percepção de que todos devem interagir, gerando uma dinâmica tão descontraída quando produtiva.

1. Projetos – Uma sequência bem comum, frente a necessidade em selecionar um projeto para piloto SCRUM, pode ser mapear os projetos candidatos, o que está rolando ou está para começar. Procuramos uma oportunidade, um projeto da vida real, não necessariamente iniciando, mas que gere possibilidade de cumprir um planejamento e execução de alguns sprints:

2. Equipes – Algumas vezes, em meio ao processo de discussão e seleção do projeto para piloto, faz-se necessário também discutir conjuntamente a equipe, não só a equipe que executará mas eventuais ajustes na sua formação e disposição. Um exemplo clássico é incorporar um testador à equipe, que as vezes são profissionais que ficam em uma célula só de qualidade, separado das equipes com quem trabalham em projetos.

3. Tecnologia – Raramente é preciso discutir e selecionar tecnologia, mas já aconteceu de no Boshú haver uma discussão prática sobre as necessidades de um ou mais projetos, que tinham uma perspectiva por uso de uma plataforma, framework, integração, biblioteca ou tópico específico relacionado a engenharia de software. Assim como projetos e equipes, este tópico as vezes corre em paralelo com os dois primeiros e pode ser importante para a tomada de decisão ou ajudar a clarear premissas, restrições e riscos de um ou mais projetos.

Se o Boshú de vocês transcorreu bem até aqui, é provável que boa parte do PMC e SSC (abaixo apresentados) já estejam bem adiantados e preenchê-los será bem fácil, mas é importante fazê-lo com provocação e evitando sermos levianos na sua proposição, pois já vi Boshús retrocederem e mudarem a estratégia por percepções de restrições ou riscos que de início não tinham sido levantadas. Não que mudem drasticamente, mas esclarecem e favorecem pactos entre os presentes.

4. Project Model Canvas – Não tenho a pretensão de montar completa ou definitivamente o termo de abertura do projeto selecionado, mas apenas pincelar o que já se sabe sobre ele. Uma forma madura e consciente para confirmar se o projeto até aqui selecionado não possui riscos ou restrições inicialmente ocultas. Um exercício que muitas vezes é divertido e instrutivo para todos os participantes.

5. SCRUM SetUp Canvas – Assim como o PMC acima, o objetivo não é mapear conclusivamente o setup do projeto a luz de critérios do método SCRUM, mas apenas pincelar as principais características e pressupostos metodológicos para esclarecer tópicos como métricas, técnicas, percentuais de lotação, DoR e DoD. Estas definições poderão posteriormente serem refinadas na medida em que o projeto iniciar, mas são relevantes como alinhamento no primeiro passo.

Não é uma receita de bolo, mas este formato, tirando ou alterando a sequência, é bem consistente … eu sou bem flexível, não estresso nenhum artefato ou debate se vejo que ela é absolutamente irrelevante. Isto quer dizer que bom senso é um tempero muito importante, senso de oportunismo também, seja Lean e evite desperdicios, focando em um Boshú fluido e instigante.

Depois é Agile na veia, projetos SCRUM devem iniciar em sua essência, com muita transparência e consciência: