Como foi a meetup Mob Programming Workshop?

O que é Mob Programming?

Mob Programming é uma abordagem de trabalho em time, incluindo não apenas pessoas que desenvolvem código, mas também todos que fazem parte da criação do produto como designers, testadores, ScrumMasters, Product Owners. Tanto pessoas técnicas e quanto pessoas de negócio.

Imagine todo o time trabalhando na mesma coisa, ao mesmo tempo, no mesmo espaço, e no mesmo computador. É uma técnica de trabalho realmente em time, que além de gerar uma solução de alta qualidade, o compartilhamento de conhecimento é constante.

A meetup de Mob Programming

Dia 31/01 nos encontramos em Porto Alegre pela Meetup Agile Open Space, no espaço gentilmente cedido pela DBC Company. Por 2 horas discutimos Mob Programming e obviamente codificamos. Inclusive pessoas que nunca programaram na vida, nem em cursos.

Apresentei um problema real a eles, que realmente os engajassem. O problema era que eu sortearia uma inscrição para o workshop de um dia todo, que acontecerá dia 09/02.

Tínhamos 13 pessoas, incluindo eu, o facilitador que também iria programar. Pedi a todos organizarem suas cadeiras em forma de U em volta do telão, para que todos pudessem olhar os outros e também ficarem confortáveis ao olhar para o código projetado na TV.

Isso já faz com que as pessoas se movimentem, e ajudem no próprio espaço do workshop, um dos primeiros passos para engajarem as pessoas. Essa é uma dica de facilitação: todos ajudam e todos colaboram. Pessoas são serem sociais naturalmente, e quando ajudam o próprio grupo se sentem engajadas por um propósito. Fiz isso parecido no TDC 2018 em Poa, na trilha de XP. Evoluir o design físico pedido ajuda e feedback rápido dos participantes.

Pessoas que não codificam ou não sabem codificar participando do Mob Programming como drivers?

Questionei os participantes e descobri que haviam duas pessoas que nunca programaram, além da maioria não conhecer ou dominar Java, a linguagem que utilizamos no workshop. Isso era uma preocupação dessas pessoas, então questionei também se eles queriam participar voluntariamente como driver (quem codifica no teclado), além de serem navegadores (que guiam o driver). O legal é que todos se voluntariaram a serem drives, inclusive quem não sabia codificar!

Isso é realmente impressionante!

Fiquei bastante contente com isso, e com uma atenção em especial ao grupo todo para fluir bem na criação de um ambiente seguro, porque todos ali iriam expor suas habilidades, ou a ausência delas. A busca por ambiente seguro é absolutamente essencial em Mob Programming. Tanto que os valores de Mob Programming são Gentileza (Kindness), Consideração e Respeito. Por isso também que retrospectivas diárias são importantes em Mob Programming. Sim, diariamente. Pode ser no final ou no início do dia, como o time decidir. Ah, e não há reuniões diárias tradicionais, porque todos já trabalham juntos e a comunicação é a todo momento.

A rotação era de 3 minutos, com 13 pessoas, fecharia um ciclo de todos participarem e ainda teríamos tempo para uma retrospectiva de fechamento. Perfeitamente após o ciclo, completamos a solução com Test-Driven Development (TDD). Criamos dois testes em JUnit bastante significativos. Ok, não tivemos tempo para melhorar o código com refatoração, isso é algo que sabemos que faltou tempo, e que faríamos com certeza se houvesse um próximo ciclo de Mob Programming. Isso ficou na consciência do time, a importância de clean code. O código está no GitHub em https://github.com/dsmoura/mob-programming-workshop-pocket

A rotação do driver acontece num período maior de 3 minutos num time já utilizando Mob Programming há um bom tempo, normalmente entre 7 e 10 minutos. O tempo de rotação em 3 minutos é para tornar a melhoria contínua do processo mais rápida. Por isso uma retrospectiva a cada ciclo inicial de Mob Programming.

O time precisa usar Mob Programming o tempo todo?

Não. Mob Programming é uma forma de trabalho que o time precisa aprender e decidir quando melhor utilizá-la. Dentro da cultura da organização, se o time quiser utilizar Mob Programming o tempo todo, tendo antes experimentado e mostrado que a qualidade da solução é aprimorada e a produtividade está boa, quem sabe até excelente, por que não?

O que sugiro é o time experimentar Mob Programming um turno por semana, ou um turno por iteração/sprint. Quem sabe decidir quais tipos de tarefas ou histórias de usuário/requisitos serão melhor desenvolvidas com Mob Programming. Ou quem sabe para troca de conhecimento? Ou melhoria do padrão de código? O time deve experimentar e então decidir.

Mob Programming, tornando pessoas incríveis!

A expressão bastante utilizada pelo Woody Zuill, um dos que estavam presentes no time que criou Mob Programming, utiliza bastante a expressão Turn Up the Good (Aumente o que é Bom). Focar nas melhores qualidades das pessoas e do time. Isso vem muito de Psicologia Positiva, de se focar no que há de melhor nos indivíduos, nos times e nas organizações, e não tanto em problemas. Isso faz com que as pessoas se tornem e se sintam realmente incríveis. Agradeço a presença de todos participantes, na foto abaixo!

Como é um dia de trabalho num time e numa organização em Mob Programming?

Veja como é um dia de trabalho de um time em Mob Programming:
https://www.youtube.com/watch?v=p_pvslS4gEI

E veja como é diversos times trabalhando numa empresa em Mob Programming:
https://www.youtube.com/watch?v=dVqUcNKVbYg

Quer aprender na prática Mob Programming?

Dia 09/02/2019 haverá o workshop de Mob Programming em Porto Alegre https://www.sympla.com.br/workshop-de-mob-programming-uma-abordagem-agil-com-o-time-todo__446273

Você gostaria de praticar Mob Programming? Envie-me uma mensagem direta pelas redes sociais que com certeza lhe ajudarei.

Acompanhe os eventos, meetups e treinamentos que facilito em https://dionatanmoura.com/eventos/

Meetup Agile Open Space, Porto Alegre

Nova meetup Agile Open Space, Porto Alegre! https://www.meetup.com/Agile-Open-Space-Porto-Alegre/

A ideia é fazer open spaces e workshops, ou seja, tudo o que haja aprendizado ativo! E não aprendizado passivo (chato até).

Além do mais, sabemos que agilidade valoriza mais indivíduos e interações. Então ter palestras ou eventos de agilidade com pouca interação pode ser um tanto contraditório.

Palestras podem ser úteis, porém não geram tanto aprendizado.  Veja no cone/pirâmide de aprendizado onde a meetup Agile Open Space tem foco:

E dia 17/01 já tem um agile game! XP Playing Cards Game – Aprendendo eXtreme Programming com diversão! https://www.meetup.com/pt-BR/Agile-Open-Space-Porto-Alegre/events/257767540/

Vai ficar de fora?

The importance of Test Automation for Business Time to Market

Right after I woked up today, I read this Dan North’s tweet:

Screenshot from 2018-09-23 13:48:42

Trunk-based development makes the development teams integrate and test on a single code, which is the trunk (or master in Git). It is the base for Continuous Integration and Continuous Delivery. This approach brings software releases early, reducing time to market. At the extreme, Lean Startups.

Two weeks ago I was coaching an agile team for the first time, they use feature branches, having a slow cadence of deliveries. They are working on a single product with other three teams in their organization, plus other three organizations. In this case, code integration is a mess and its code is fragile. After a short time, business cannot have fast time to market anymore.

So what is missing?

It is virtually impossible having trunk-based development without test automation. When you need to integrated code, you need to test the feature and every thing related. So doing it manually is insanity. Manual testing can be easy in the beginning, but the software becomes more and more complex. You need test automation.

First of all, your team have to understand the need of test automation. Secondly, they have to learn and practice test automation. Why not try coding dojos or mob programming?

Based on the Redundancy principle of eXtreme Programming, your team can automate tests on critical features, difficult problems, so it can be approached in many ways. Developers focus on unit and integration code mostly, even functional tests. Testers automate functional and many other types of tests. They help each other. There is no right division on that.

Keep something in your mind: “Legacy code is simply code without tests” by Michael Feathers. So every code you commit without tests, it is legacy code.

So cheers for good practices on software development…

2018-08-01_10-37-45
Dionatan Moura (me, left) and Dan North (BDD creator, right) in the conference Agile on the Beach 2017. Falmouth, England.

 

TDD is a practice like swimming

A reader of our eXtreme Programming book asked us a guide to move from 0% TDD programming to 100% (or almost) TDD programming. But, there’s no manual that will really teach TDD, because it’s a practice. We could use a metaphor to explain it, TDD is like swimming, an activity that we practice.

Yes, TDD can be very hard at first time. Like swimming, you might not have enough breathing discipline, getting tired faster and giving it up. And after say “I didn’t like swimming, swimming is not for me”.

As a swimmer needs to jump in the water, a programmer needs to start with a failing test, write code until the test works, and refactor. And repeat these steps a lot of times. It’s a cycle, it’s a mantra:

image
TDD mantra: write a failing Test, Code until pass the test, so Refactor.

After a lot of TDD cycles, you will be understanding how to practice TDD. So, please, jump in the water and enjoy TDD.

— Thanks to Guilherme Motta for the review.

Kanban, pizza e agile no GUMA-RS

Dia 03/11/2015 (terça-feira) haverá o workshop GUMA Pizza Kanban facilitado pelo Cristiano Basso, no horário das 18:30 às 21:30, na PUCRS. Esse evento é organizado pelo GUMA-RS, o Grupo de Usuários de Métodos Ágeis do Rio Grande do Sul. A ideia é aprender lean e kanban na prática, construindo pizzas (feitas de papel). Show! Né? 🙂

Inscrições

A inscrição é realizada pelo link:

GUMA Pizza Kanban

Quer saber mais sobre o Kanban Pizza Game? Então siga lendo…

Kanban Pizza Game

Pizza Small6163012549_7c7934aa5e-1_1
Kanban Pizza Game. Fonte da imagem: agile42 – http://www.agile42.com/en/training/kanban-pizza-game/

O Kanban Pizza Game é uma dinâmica do agile42, e mostra na prática os princípios do lean, agile e kanban, numa divertida de um jogo. Veja só como fica o quadro de kanban durante o jogo:

kpg - visualize on a flipchart
Fonte da imagem: agile42 – http://www.agile42.com/en/training/kanban-pizza-game/

Aprendendo sobre Kanban

O kanban para desenvolvimento de software foi formulado pelo David J. Anderson (@lki_dja), em seu livro Kanban – Successful Evolutionary Change for Your Technology Business:

Existe também o mini book do Jesper Boeg, Kanban em 10 Passos, disponibilizado gratuitamente na InfoQ:

Kanban10PassosCapa

Aprendendo sobre Lean

Para aprender mais sobre Lean, veja os slides de uma palestra que fiz sobre Lean Thinking:

Sobre o facilitador do workshop

Esse game será facilitado pelo Cristiano Basso (@csbasso), um amigo desde a época do PoA-OSUG (Porto Alegre – OpenSolaris User Group). O Cristiano Basso já facilitou esse workshop na ESPM, veja só a notícia que saiu:
http://hubnews.espm.br/noticias/acontece-no-campus/935-cristiano-basso-fala-sobre-kanban-no-workshop-da-atletica

Buscando algumas memórias, lembro do FISL 2009 onde estávamos no estande do OpenSolaris (vide fotos a seguir). Naquele ano, o pessoal da Sun compareceu em peso, e veio até o ex-presidente Lula visitar o FISL, ele colocou o boné do OpenSolaris e assinou a camiseta do OpenSolaris! Bom, mesmo anos depois, a participação dele na comunidade de TI permace, dessa vez com uma dinâmica para mostrar o kanban e o ágil na prática.

IMG_2419
Cristiano Basso ao centro da foto.
IMG_2468
O ex-presidente Lula no estande do OpenSolaris no FISL em 2009.
IMG_2511
Camiseta assinada pelo ex-presidente Lula.

Então, aproveite o workshop! Inscrições em:

http://www.sucesurs.org.br/evento/guma-pizza-kanban-2

 

Lean para Potencializar a Qualidade no Software – Palestra na InfoQ Brasil

Saiu na InfoQ Brasil a palestra que fiz na trilha de Testes do TDC 2014! Nesta palestra, falo de como o Lean pode potencializar a Qualidade no Software. Segue o link:

http://www.infoq.com/br/presentations/lean-para-potencializar-a-qualidade-no-software

Lean Beer Porto Alegre (Lean Coffee)

Ontem (23/07/2015) realizamos o Lean Beer em Porto Alegre, no mezanino do Lagom Brewery & Pub do bairro Moinhos, unindo o GUMA-RS e o Lean Coffee Porto Alegre. O Lean Beer possui a mesma dinâmica que o Lean Coffee, porém com cerveja! 😉

20150722_213423
Lean Beer Porto Alegre. Da esquerda para a direita: Alejandro Olchik, Diogo Lucas, Dionatan Moura, Eduardo Klein e Cristiano Basso.

O Lean Coffee, ou Lean Beer, é uma forma inovadora de discutir assuntos, um modelo muito enxuto em relação às reuniões tradicionais, que por vezes desperdiça tempo e energia das pessoas, além de dinheiro.

A sensação de participar de um Lean Coffee é a de querer mais, os assuntos fluem com foco de uma maneira muito eficiente.

Assuntos discutidos

IMG-20150723-WA0030
Quadro de kanban com os assuntos discutidos no Lean Beer.

Os assuntos discutidos foram nesta ordem:

  1. Quais os problemas de gestão que mais incomodam?
  2. Como ser criativo mantendo a produtividade no trabalho, com qualidade de vida?
  3. Aplicação de ágil fora da área de software.
  4. Como escalar o Lean Beer?

O único assunto que ficou de fora, por falta de tempo, foi sobre Management 3.0: salários e considerar desempenho?

Como funciona um Lean Coffee?

Basicamente, o grupo de pessoas realiza os passos:

  1. Definir o escopo dos assuntos (normalmente qualquer assunto é válido).
  2. Escrever em post-its os assuntos que desejam discutir;
  3. Colar os post-its num quadro de kanban com as três raias: todo/a discutir, doing/discutindo e done/discutido;
  4. Cada pessoa vota uma numa quantidade fixa de assuntos. Normalmente, são dois a três votos.
  5. Ordenar os post-its no quadro de kanban de acordo com a quantidade de votação. Quanto mais votos, mais no topo estará na raia todo/a discutir.
  6. Movimenta-se o post-it de maior prioridade para a raia doing no quadro de kanban, discutindo-se abertamente o assunto entre o grupo num período cronometrado de 5 a 10 minutos. Preferencialmente, quem deu a ideia do assunto pode fazer um briefing, explicando a importância daquele assunto.
  7. Ao finalizar-se o tempo (5-10min), o grupo vota caso desejar mais um ciclo de 3 a 5 minutos para continuar discutindo o assunto. Caso a maioria vote que não deseja continuar, então o post-it atual é movimentado para a raia done e volta-se ao passo 6 e discutindo o próximo assunto de maior votação.

Onde posso aplicar um Lean Coffee?

É possível utilizá-lo em muitas situações, basta que se encaixe bem no contexto. Eu já utilizei na minha empresa para discutir assuntos gerais e ideias para a própria empresa. Foi uma ótima fonte de incentivar a inovação. Sei que times ágeis que utilizam para realizar retrospectivas, principalmente quando se tem muitos assuntos para conversar. E participei ontem, no Lean Beer.

Como escalar um Lean Coffee?

O que se faz quando houver mais de 15 ou 20 pessoas para discutir os assuntos? Bom, existem diversas alternativas. Eis algumas:

  • Restringir o escopo;
  • Restringir a quantidade de assuntos por pessoa;
  • Restringir o tempo para escrever os assuntos em poucos minutos;
  • Agrupar os assuntos em clusters;
  • Utilizar um fishbowl.

Existem muitas maneiras de escalar, então analise bem o contexto e adapte a dinâmica. 🙂

Mais informações: