Arquivo da categoria: Metodologia

Se fossemos uma lavanderia, poderia ser uma lavanderia SCRUM

O blog http://cartoontester.blogspot.com.br não tem novos posts desde 2014, tem um traço muito próprio, mas eu tenho paixão pelo diagrama abaixo, alegoria ao método SCRUM caso nosso backlog fosse um enorme cesto de roupa suja. A beleza da simplicidade, impossível não entender o básico do SCRUM com ela.

É possível discernir facilmente cada etapa, inclusive é possível entender o que é valor, a relevância de um bom Release Plan, o que é o Selected Sprint Backlog, o próprio Sprint backlog, o conceito de sprint, a review e retrospectiva, até o pacote potencialmente entregável, daria para reescrever o guide de forma bem divertida.

Nada disso está no blog do Andy Glover (talvez parente do Danny), mas a primeira vez que olhei para essa alegoria, diagramada como abaixo, foi amor a primeira vista … todos os conceitos de timeboxes e artefatos pulam na frente, muito legal!

Poderia traçar analogia a N situações, acho que até meus avós entenderiam o que é esse tal de SCRUM, backlog, sprint, para ilustrar escolhi um cenário bem simples:

Pré-game: nosso PO chega na lavanderia SCRUM com um imeeeeenso cesto de roupa suja, mostra para a equipe e pede um planejamento para estimar o custo. O cesto é muito grande e a galera pergunta para o PO o que ele tinha ali, qual sua necessidade e expectativas, permitindo a equipe planejar e combinar o projeto.

Com o Scrum Setup Canvas eles percebem que precisarão de uma máquina de lavar, outra de secar e uma bancada de passar, dimensionamento de equipe, exigências de qualidade do serviço, pontos de atenção, cuidados, etc. Estimam que precisarão provavelmente 3 (três) sprint (rodadas na máquinas de lavar, secar e passar), mais 1 (um) de buffer na eventualidade de precisar de sete, pois dependendo do tamanho e peso das toalhas talvez seis fosse pouco.

O nosso PO diz que precisa para a primeira sprint de pelo menos uma toalha grande, pois está sem nenhuma e tem que tomar um banho para ir trabalhar e que até a segunda precisará de determinada calça de veludo, uma camisa azul e roupa de baixo para usar, determinando que para o terceiro precisaria de um smoking completo e roupa de baixo, meias pretas. De posse das informações a equipe planejou os itens a cada rodada de forma a atender as necessidades do cliente.

Ao final, está definido o nosso product backlog, entendido, priorizado, MVP, planejado em sprints, permitindo à equipe começar a trabalhar no primeiro sprint.

Sprint 1 – A equipe realiza o primeiro sprint, seguindo a prioridade do cliente, realizando cada máquina e serviços, mantendo o cliente informado do andamento e tendência. O cliente pôde passar no horário combinado e avalia o trabalho executado, comentando que esperava mais da dobradura de uma camisa, feedback depois discutido entre a equipe para que as próximas fiquem melhor.

Sprint 2 – O PO propõe alterar um pouco o sprint backlog, apontando outra calça como prioridade e incluindo mais uma toalha pequena que trouxe, mas que a equipe acredita que não impacta na previsão e por já ter entregue a toalha grande, avaliam a tendência e avisam o cliente que provavelmente não precisará do buffer. A entrega se confirma e o cliente elogia que a nova dobradura da camisa está muito melhor e a calça de brim escolhida será melhor para seu compromisso.

Sprint 3 – A cada sprint a equipe confirma com o cliente a priorização e condições, executa, entrega e ao final discute os feedbacks e percepções variadas de ocorrências. Já conhecem o cliente e estabelece-se uma relação de confiança, quer pela transparência, pela confirmação, parceria e resultados.

Quer tentar? Fecha os olhos e faça seu story board mental do projeto SCRUM da sua lavanderia com o seu cliente … acho que a galera do Savana Scrum vai abrir uma lavanderia na selva e vou postar algumas tirinhas das suas aventuras  \o/

Uma versão PDF para impressão A3 do Scrum Setup Canvas

Compartilho uma versão A3 para impressão e uso do Scrum Setup Canvas. Não é para ser só mais um quadro com postits na parede, ele é vital ao gerar um debate sobre acordos e pré-definições pouco antes da realização de um Release Plan.

É para ser um documento vivo, com combinações e pactos evolutivos, jamais para justificativas, mas para aprendizados e melhoria contínua. A maioria de seus campos são relevantes mas não constam em nenhum outro canvas ou artefato.

Para quem não acompanhou nem os posts anteriores nem as apresentações, o SSC é um quadro que formaliza as combinações e premissas essenciais que balizarão o Release Plan, para planejar é preciso definir as bases sobre as quais o faremos.

Eu gosto mais da minha versão colorida do SSC, mas alguns amigos, colegas e contatos tem me pedido uma versão A3 para uso, então criei uma para ser impresso em tamanho grande, de forma a usar postits pequenos como eu uso.

Arquivo tamanho A3 em pdf no dropbox – 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 em vídeo no Agile Trends 2017.

Clique aqui para acessar a apresentação em PDF a partir do DropBox.

Espero que seja útil aos que já o utilizam ou querem experimentar, igual fico a disposição no caso de dúvidas, aberto a sugestões ou críticas construtivas 🙂

6ª e 7ª aula de GP na FACIN

Este ano foi injusto com quem ministra aulas nas sextas feiras, pois tivemos 2 feriados e uma greve geral, na qual a universidade teve a sensibilidade de não exigir presença e evitar provas ou trabalhos, posto que não haveriam ônibus, trens e o risco de movimentação urbana com bloqueios de ruas e eventual violência.

Mas após um mês sem aulas, retomamos com uma boa revisão da matéria, os grupos tiveram um tempo para relembrar seus projetos, que ainda estavam em fase de modelagem inicial das ideias. A seguir retomamos de onde paramos, de lá para cá foram duas aulas e a realização da primeira prova, com boa média.

05/05/17 – 6ª AULA DE GP

Na quinta aula tínhamos chegado até o Termo de abertura do grupo de processo de Iniciação, usando para isso o artefato de Project Model Canvas. Aqui seguimos com a apresentação dos nossos stakeholders, oportunidade para discutir empatia além da formalidade, não só quem é, mas o que sente e quer.

A abordagem da empatia, trazendo uma visão típica do Design Thinking é porque gerenciamento de projetos de software no século XXI é fazer certo a coisa certa, inicia desde o entendimento do problema, da necessidade e não da solução. Então personas, empathy canvas e value proposition canvas são sim técnicas de GP, ou seguiremos com as mesmas charges infames do século XX sobre a galera de TI:

No último slot da aula fiz uma provocação sobre a área de INTEGRAÇÃO e seus processos, sobre o Termo de abertura da aula passada, sobre o plano de gerenciamento de projetos, as características do gerenciamento de mudanças e ao final as lições aprendidas. Discutimos especialmente o Plano de Gerenciamento para que na próxima aula após a prova entrássemos direto em ESCOPO.

12/05/17 – P1 (PROVA)

Entre a sexta e a sétima aula, tivemos a P1, onde ocupei dois créditos com estudo em grupos de três e uma revisão geral da matéria – conceitos de portfólio, programa, projetos, sub-projetos, operações, tipos de estrutura organizacional, governança, PMO, os 5 grupos de processos do PMBOK, diferenças entre o GP tradicional e ágil, as 10 áreas de conhecimento/planejamento do PMBOK.

19/05/17 – 7ª AULA DE GP

A sétima aula foi muito pegada, pois após feriados, greve e prova, tínhamos muito o que fazer para colocarmos a pauta em dia. Em linhas gerais, discutimos alguns dos fundamentos mais importantes sobre planejamento de escopo:

  • desenho de processo
  • funcionalidades
  • categorias de requisitos
  • épicos e histórias
  • tarefas

O exercício realizado logo no início que começamos a discutir requisitos é o clássico planejamento de um churrasco da turma, quer no formato de uma jornada de usuário, com pacotes de trabalho e estrutura semelhante a uma WBS ou em rede. O exercício ajudou a acordar os alunos mais cansados em uma noite de sexta.

A aula foi bem prática, evoluímos bem no entendimento por cada grupo sobre as funcionalidades possíveis em cada um dos projetos, alguns discutindo a nível de requisitos, outros em épicos e histórias. A meta era um grande brainstorming para que na próxima aula tenhamos a WBS/User Story Mapping materializadas.

Faltando ainda uma hora e meia para o final, optei por um quebra gelo famoso por produzir muita adrenalina, conhecido como Kaa e Bagheera no escotismo ou Snakes como Team Building Games. Descemos do terceiro para o térreo, fiz um briefing sobre sistemas empurrados e puxados, organizei as filas, expliquei o objetivo, as regras e usei uma tira de papel de 50 cm x 15 cm como rabichos.

A adesão e empenho foi muito legal, todos voltaram à aula muito acordados e dispostos a mais uma hora para o braisntorming de escopo … a opção pelo jogo me fez postergar a dinâmica de pitchs e reconstrução, mas valeu a pena. Na próxima aula cada grupo/projeto terá 30 minutos para organizar seu escopo e apresentá-lo, permitindo que todos os outros cinco grupos possam questionar, sugerir, ajudar.

Durante a aula relembrei a charge das árvores sobre requisitos em um projeto, insisti na minha abordagem de profissionais de perfil T ou Pi, sobre nem só fazer errado a coisa certa, nem fazer certo a coisa errada, nossa meta é fazer certo a coisa certa. É entender o problema, para mapear alternativas e trabalhar a solução.

  • Pizzaria – O cliente liga e pede o tamanho, a massa, o recheio, a borda, não cabe à pizzaria ficar questionando se por acaso o pedido é inadequado, se vai sobrar, se alguém é alérgico, …
  • Médicos – O paciente não chega pedindo uma injeção de terramicina, é o médico que deve levantar dados o suficiente para diagnosticar e receitar a melhor medicação (ou não) para o momento.

Quem você é? O que você faz? Você ainda faz software como no século XX, quando o cliente dizia o diagnóstico e especificava o que queria ou você faz levantamentos, discute, levanta alternativas para só então trabalhar naquela que parece ser a melhor solução, mesmo assim receita e pede que o paciente volte dali a duas semanas após tomar a medicação para certificar-se de que esta certo?

Daily e pós-daily só dá certo se souber porque dá certo

A técnica ágil mais praticada no mundo, conforme as pesquisas da Version One, é a Daily ou Stand Up Meeting. Parece ser algo trivial, mas é preciso algum esforço e dedicação para entender na prática o que é, para que serve, experimentação para fazer dar certo, diferenciar a Daily da Pós-Daily, achar o ponto de equilíbrio.

Trata-se de uma rápida reunião com menos de 15 minutos, preferencialmente no início da manhã, antes de entrarmos em fluxo. Uma reunião tática, que gera uma boa energia para o dia todo, lembrando a todos que estão todos unidos para o sucesso da sprint, iteração usualmente com duas semanas de trabalho.

Entender a Daily como um Status Report é sinal de que ainda temos mindset de comando-controle. Daily é dizer e ouvir o suficiente para concordarmos que estamos fazendo o melhor possível para a meta da sprint. É preciso ver a Daily como um pacto diário, focado naquilo que de melhor podemos fazer:

  • O que fiz desde a última e se isso contribuiu para a nossa meta;
  • O que pretendo fazer até a próxima para contribuir para a meta;
  • Se preciso de ajuda, tenho ou vejo impedimentos para a meta;
  • Se eu vejo uma oportunidade ou posso ajudar a irmos além.

Se algo não está de acordo ou há que se debater sobre algum risco, fato ou oportunidade … então encerre a Daily, libere quem não precisa ficar para esta conversa e inicie o que chamo de Pós-Daily!

Daily x Pós-Daily

Se a Daily é uma alinhamento de abstrações pessoais de atividades, risco e oportunidades, justifica-se então a presença obrigatória de toda a equipe de desenvolvimento … porque a meta, valor, produtividade, energia e Lean thinking de todos a cada dia é responsabilidade de todos.

Sempre que necessário for é possível fazer uma Pós-Daily, com a presença apenas de quem possa ou precise colaborar. Se na Daily a presença é obrigatória, no pós-Daily fica somente quem necessário, em comum acordo. Em uma equipe auto-organizada, a Daily e a pós-Daily são nosso choque diário de realidade.

São dois momentos que dizem respeito a relembrar que a meta é de todos, que estamos juntos nessa, que mais que contar com o apoio uns dos outros, é fundamental que estejamos de acordo que estamos todos gerando sinergia suficiente para que a auto-organização aconteça.

Não importa se presencial ou remoto, o fato é que uma conversa no inicio do dia reativa o foco, relembra que estamos todos juntos nessa, chama a atenção para o fluxo expresso no quadro e a tendência visualizadas nas métricas.

Querer que suas Daily Stand Up Meetings deem certo sem ter entendido porque e para que elas servem é análogo a querer uma vitamina no copo pela manhã só porque comprou um liquidificador … mas tem que comprar os ingredientes certos e preparar, senão é só peça de decoração.

14/06/17 – 1° Scrum Day Brasil, pela Scrum.org

Dá uma navegada no site da SCRUM.ORG e na página do Scrum Day 2017, porque será um momento histórico, primeiro grande evento organizado pela Scrum.Org no Brasil, em grande estilo … dedicado ao método ágil mais utilizado no mundo.

Um grande time de especialistas certificados pela Scrum.Org, muitos nomes que você com certeza conhece e acompanha em seus posts pelas redes. O valor é absolutamente irrisório, early birds a R$200 até o dia 14/06 e depois R$280.

Para quem é de SP não dá para perder, para quem não é temos quase dois meses para ver passagens acessíveis a todos nos sites de viagem, se sua empresa adquirir hoje vai gastar em ida e volta (POA-SP) e inscrição exatos R$800,00:

Serão palestras, relatos de casos, workshops e open spaces variados relacionados diretamente com a prática da metodologia ou do Scrum em escala, além de treinamentos oficiais com referências mundiais da própria Scrum Org.

Não tenho palavras em parear com um timaço de especialistas que admiro e considero meus gurus no primeiro grande evento da Scrum Org no Brasil. Será no Prodigy Grand Hotel & Suits Berrini em SP, organizado pela Scrum Org e pela Concrete Solutions – https://www.scrumday.com.br/

Vou aplicar o SCRUM Game criado por mim para os treinamentos da DBServer, batizado de Banco Intergaláctico. Uma hora e meia para exercitar papéis, timeboxes, artefatos e regras para um cliente tri-especial, que após seu último empreendimento resolveu sair do lado negro e regenerar-se em um negócio de muito potencial em fase de crescimento.

Aos agilistas da ponte SP – RJ, com certeza nos vemos por lá no dia 14/06, para os gaúchos e outros estados a inscrição hoje é R$200, mais passagem ida e volta adquirida agora disponível a R$600 … mas não fica procrastinando, fala com teu chefe, apresenta um plano de replicação que não tem como não dar certo.  \o/

 

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.

Time Ágil ou Time Ágil de Alta Performance?

Estamos atingindo um virtual ponto de saturação do termo “Times Ágeis”, cada vez mais diluído, frequentemente mal entendido. Creio fazer-se necessária uma mudança para reforçar e quebrar vícios inerentes a banalização de um termo que per si sempre teve múltiplas interpretações: O que é Ágil no dicionário?

No dicionário, ágil é aquilo que se move com facilidade, ligeiro, veloz; Algo desembaraçado, vivo, rápido; Eficiente, diligente, trabalhador.

Eu prefiro “Times Ágeis de Alta Performance“. Acho sinceramente que só o termo Ágil está carecendo de uma ajudinha explícita, para não mascarar ou confundir o amplo mix de equidade que queremos atingir – cliente, empresa, profissionais, tecnologia, valor, Lean, excelência, ambiente, satisfação, …

No dicionário, Alta Performance diz respeito a atingimento de todo seu potencial, poder desfrutar de tudo que suas habilidades possam proporcionar.

Tenho visto muita facilidade em nos considerarmos ágeis, mas ao mesmo tempo temos dificuldade em nos considerarmos equipes de alta performance.

É preciso idealizar menos, esforçar-se mais, agilidade é trabalho duro, persistente, de alta performance e sustentável. Vejo muitas convicções e trincheiras sobre agilidade, muita retórica, resignações, impedimentos, desmotivação porque o mundo não é o que deveria ser ou porque a lua não é de queijo.

A essência do mindset ágil diz respeito a geração de um ecossistema propício a geração de valor a todos os envolvidos, nasceu fundamentado nos princípios Lean, eliminação de todo e qualquer desperdício sem propósito. Por isso a pirâmide Lean, porque é preciso considerar estratégia, tática e técnica.

Tem uma brincadeira que faço em meus cursos, eu pergunto a alguém se ele se considera um bom profissional? Sempre dizem que sim, daí eu pergunto porque? Sempre me dizem que é porque entregam, são reconhecidos. Eu concluo pedindo para se compararem com equipes reconhecidas como de alta performance? A resposta sempre é um sorriso, um nem tanto, um sim mas!

Inexiste agilidade se estamos nos acomodando em meio a trincheiras: Se há retrabalho, se há desperdício, se falta poke-yoke e kaizen com cenários, automações, pair, peer review, se falta comunicação ativa e eficaz, se existem silos, trincheiras, ações motivadas pela busca de culpados e responsáveis, está na hora de sermos mais transparentes e realistas, puxando para nós o que é de nossa alçada.

Proponho uma reflexão, através de um auto-questionário:

  • 1ª – Você e sua equipe são ágeis?
  • 2ª – São uma equipe de alta performance?
  • 3ª – A resposta é que a culpa é dos outros?
  • 4ª – Você continua aprendendo e tentando ou se entrincheirou?

Há um exercício que promovo em equipes que já praticam e possuem muitas barreiras organizacionais, dificuldades, equipes que já encontraram defesas e explicações sobre cada desvio e causas de cada problema recorrente: Crie um quadro análogo ao abaixo, bem grande, na vertical temos “valor” à agilidade aumentando de baixo para cima e na horizontal a alçada. Para cada postit colocado a esquerda (responsabilidade do cliente ou da empresa/status quo), é preciso colocar um adicional a direita com o que estamos ou poderíamos estar fazendo para eliminar ou mitigar aquela carência.

É um warmup, um exercício de brainstorming, de ToolBox, visando encontrar técnicas de mitigação, de argumentação, de ações que nos levem adiante, mais um passo na eliminação de desperdícios, geração de maior valor e construção de um ecossistema sustentável no qual estamos inseridos. O desenho abaixo é ilustrativo, tentando ser didático, a direita podem ser variados tipos de ações, pró-ativas, engajadas, focadas em kaizen, assumindo protagonismo e fugindo dos silos:

É fácil culpar o cliente, o diretor, o gerente, outras áreas da empresa, o que é difícil é assumir o papel de agente da mudança, esse é o mote do conceito por tras do livro e jogo TOOLBOX 360°: Se nós estamos na vanguarda do entendimento do que ser ágil, ao invés de culpar alguém ou transferir e lavar as mãos, nosso papel é buscar técnicas, boas práticas, abordagens que ajudem a contornar o problema, mostrar para quem ainda não entendeu ou trazer a luz informações e conhecimentos que ajudem a darmos o próximo passo.

Você ainda é um agente da mudança? Ou desistiu em algum momento? Se alguém não entendeu e não contribui, você continua sendo ágil e tentando mudar ou em algum momento desmotivou e desistiu, se entrincheirou em explicações e justificativas?

Últimos posts sobre mindset