Lean Coffee - São Paulo

Estive no Lean Software & Systems Conference 2012 #LSSC12. Evento fenomenal, lá entrei em contato com várias ideias novas e uma delas foi a do Jim Benson sobre Lean Coffee.

É um evento em que discute-se o tipo de assunto que eu adoro discutir (do tipo Leituras Ágeis). Então, procurei no Google e não encontrei um Lean Coffee São Paulo.

Junto com meus amigos e colegas de trabalho decidimos começar um em SP e convidamos a todos para tomar um café conosco dia 16/06, na rua Sumidoro, 555, próximo ao metrô Pinheiros.

Se você nunca ouviu falar de um Lean Coffe e quer saber como deve ser um, veja nosso blog sobre o evento.

Jogos de inovação - Parte 1, Podando a árvore do produto

English

Recentemente tenho buscado mais ferramentas para tentar ajudar na parte que o Scrum simplesmente trata como "Backlog do Produto" (nenhum demérito, afinal o Scrum é apenas um framework).

Como este Backlog deve ser gerido e priorizado? Como as histórias chegam lá? E se o Product Owner (PO) tiver que atender a vários stakeholders disputando um recurso obviamente finito que é o desenvolvimento, como ele deve fazer?

A idéia dos Jogos de Inovação é ajudar a resolver estes problemas. São maneiras lúdicas de se gerar insumos sobre um produto ou serviço.

Podar a árvore do produto (Prune the Product Tree)

Podar a árvore do produto

Visualizar o produto de forma linear e com representações inorgânicas de road maps parece mostrar o crescimento do produto como algo linear no decorrer do tempo, o que não parece representar a realidade. 

Este jogo melhora o entendimento de que o produto deve crescer de uma forma planejada, permitindo aos stakeholders modelar todos os aspectos do produto e não apenas dar feedback sobre um conjunto de funcionalidades em um road map.
Quando podamos uma árvore normalmente o objetivo é controlar o seu crescimento para que o mesmo seja equilibrado, para que a árvore seja mais saudável e assim possa gerar frutos de melhor qualidade. 

O principal é entender este processo de poda não como um "corte", mas sim como uma "modelagem". Esta metáfora é usada no jogo para ajudar a criar o produto que os stakeholders desejam.

O Jogo

Primeiro é necessário um quadro branco, flip-chart ou qualquer outro lugar em que se possa desenhar uma árvore de um tamanho razoável.

Represente as áreas de funcionalidade do sistema como galhos da árvore e as raízes como o que deveria dar suporte a toda árvore (suporte e infraestrutura). Cada release pode ser representada na copa da árvore com uma tonalidade diferente de verde, por exemplo. Representa-se na parte mais interna o que existe hoje no produto, e nas camadas mais externas, o que precisa ser feito no curto, médio e longo prazo (ver imagem).

Junte um grupo pequeno de stakeholders (de 4 a 15), pois grupos pequenos tendem a se auto-organizar de forma a gerar resultados melhores.

Recorte cartões em forma de folhas/frutos (se você estiver sem paciência, post-its servem) e peça aos stakeholders para escrever as funcionalidades desejadas neles e colar em alguma parte da árvore (você também pode imprimir algumas folhas com sugestões). Isto deve mostrar como seria, a princípio, o crescimento da árvore na próxima fase.

Incentive a discussão entre os stakeholders sobre prós e contras de cada funcionalidade, onde elas deveriam ser colocadas dentro da árvore e ainda se deveriam fazer parte desta release ou de uma próxima.

Peça aos participantes para além de inser, também retirar folhas de versões anteriores, significando funcionalidades que deveriam ser eliminadas do sistema. (Na figura, são as três folhas na parte verde escuro da árvore)

Repare se o crescimento está acontecendo de forma balanceada, pois pode haver algum galho que tenha recebido a maior parte do crescimento, ou então, algum galho anteriormente fraco está crescendo com mais vigor. Repare se as funcionalidades estão bem distribuídas entre curto, médio e longo prazo. Repare também se as raízes são fortes suficientes para aguentar o crescimento do restante da árvore.

Após a sessão, se possível, exponha o resultado em algum lugar de grande visibilidade. É provável que surjam ideias e/ou restrições mais tarde.

Variações

Algumas variações deste jogo não usam as raízes, e cartões no chão (onde na versão tradicional haveriam as raízes) representam funcionalidades consideradas de pouca importância.

Outra variação interessante é criar uma nuvem de dúvida, que serve como uma espécie de "parking lot" para funcionalidades pouco compreendidas ou que os stakeholders não sabem como usar.

Por que funciona?

As funcionalidades variam muito em importância e tendemos a querer colocar nossos esforços nas mais importantes, afinal são as que oferecem o maior valor para os clientes. Infelizmente, é comum que isto resulte em deixar de colocar esforço nas funcionalidades necessárias para completar o produto.

A ideia de se fazer este exercício é proporcionar uma forma de todos verem o produto como um todo, de forma bastante visual, e perceber se o mesmo está em equilíbrio. O resultado do pode inclusive ser mantido em algum lugar visível para servir como um radiador de informação.

---

Se você quer se aprofundar neste assunto, leia o livro "Innovation Games" de Luke Hohmann

Entrevista com Ken Schwaber - IT Martini

English

Ken Schwaber

Ken Schwaber, um dos criadores do Scrum, concedeu uma entrevista aberta para a revista digital IT Martini pelo LinkedIn, onde os participantes do grupo poderiam fazer perguntas para ele. Tive a oportunidade de fazer três perguntas (em azul escuro).

Esta informação é oferecida por meio do IT Martini.  Toda semana, líderes em tecnologia e suas perpectivas na indústria são publicadas no "IT Martini Weekly". No momento, dezenas de milhares de profissionais de TI estão conectados com o IT Martini - tanto pela rede quanto em pessoa.

Terreece M. Clarke: Aqui vai a primeira pergunta: Qual é o maior equívoco de compreensão em relação ao Scrum que os profissionais de TI tem?

Ken Schwaber: O maior equívoco é o de que o Scrum resolve os problemas quando tudo o que ele faz é tornar os problemas visíveis, de forma que possam ser tratados. O Scrum tira as pessoas de TI de seus estados de inconsciência elevando-as a um estado de consciência.

Atul Paradkar: Nossas histórias são geralmente funcionais. Por exemplo, criar um campo de formulário no site também requer uma nova coluna no banco de dados para armazenar o valor. As histórias tratariam das validações e regras de negócio. Então, como tratar usabilidade/design e tecnologia (gravar no banco de dados) usando histórias?

Ken Schwaber: Sempre que possível, tenha qualquer requisito não funcional ligado a alguma funcionalidade (mesmo que pequena). A funcionalidade prova que o desenvolvimento funcionou e permite às pessoas verem a tecnologia em ação.

Beth Bleimehl: Estou procurando alguns casos de estudo sobre gerenciamento de projeto/PMO e a adoção de Agile - especialmente Scrum. Com o que o gerenciamento de projeto/PMO se parece depois que a empresa passa a adotar o Scrum? O gerenciamento de projeto/PMO continua a operar como fazia no passado? O que muda?

Ken Schwaber: Não conheço estudos específicos. Contudo, a questão do gerente de projetos tem sido vastamente comentada. O gerente de projetos pode se tornar um  scrum master, um product owner, ou dentro de uma equipe Scrum. O papel de gerente de projetos não é parte do Scrum. O PMO normalmente se transforma para organizar o backlog do produto, tanto para os product owners quanto para as equipes de desenvolvimento. Apesar de não criar itens no backlog do produto (nem priorizá-los ou estimá-los), o backlog de produto tem várias facetas. Estas incluem o software de sistema, fluxos de trabalho, funcionalidades, decomposições e estruturas de negócio. Estas devem ser desenvolvidas e gerenciadas de forma que os product owners possam tomar as melhores decisões sobre qual o próximo item a ser feito.

Raazi Konkader (CSM): Os pontos de função (Cosmic por exemplo) são uma medida de tamanho/esforço valida no Scrum?

Ken Schwaber: Os pontos de função são uma medida de funcionalidade de software tão válidas no Scrum quanto em qualquer outro lugar.

Leonardo Campos: Onde trabalho, cada equipe é responsável por uma série de produtos diferentes. O PO normalmente prioriza histórias de cada um destes produtos em cada Sprint, tornando difícil criar uma meta decente de sprint. O PO simplesmente argumenta que as histórias são a meta (sem um propósito é difícil motivar). O que você pensa sobre este problema e qual você considera ser a melhor abordagem para tratá-lo?

Ken Schwaber: Eu trabalharia com o product owner para agrupar os backlogs dos produtos de forma que eles tratassem um objetivo de negócio ou estivessem na mesma área do software. Mostre para ele quanto seu trabalho seria facilitado, portanto a produtividade é maior, tornando o trabalho mais barato.

Leonardo Campos: O Kanban é projetado para ser muito pouco intrusivo e poder ser aplicado sobre outros frameworks, metodologias etc. Quão compatível você considera ser o Kanban em relação a sua aplicação com Scrum? Você consideraria viável ter uma "meta de sprint" em uma implementação de "Scrum-ban"?

Ken Schwaber: Não implemento Kanban por si só, de forma que não sei a respeito de metas de sprint.
O que eu realmente aprecio é usar o Kanban para ajudar equipes de desenvolvimento a aprender novas práticas, com raias como:
1. Desenvolver testes de aceitação
2. Desenvolver o design de projeto
3. Desenvolver testes automatizados, codificar e documentar
4. Testar de forma integrada para verificar se todos funcionam juntos
5. Corrigir a falhas
e por aí vai

Raazi Konkader (CSM): Quais são alguns indícios de que uma equipe seguindo as práticas, mas sem entender a teoria por trás de métodos ágeis com Scrum, XP ou Kanban? Como tratar isso de forma geral?

Ken Schwaber: A equipe tem um problema e não sabe como melhor tratá-lo. Se você entende a transparência, ajuda as pessoas a atingir o melhor delas, e entende a arte do possível (todas atitudes que vêm do empirismo e Lean), você consegue tomar decisões muito boas. Caso você não as conheça, suas decisões não tem base e são frequentemente contra-produtivas.

Leonardo Campos: Você tem planos para vir ao Brasil nos próximos 12 meses? 

Ken Schwaber: Não, não nos próximos 12 meses. Ainda estou me recuperando de toda comida que comi da última vez. 

Inspect & Adapt

English

Neste post curto falarei de uma receita bastante simples sobre inspeção e adaptação (ou kaizen, se você prefere um termo mais Lean) para tornar o seu dia-a-dia - ou processo - mais eficiente:

1. Dado um problema, concentre-se apenas na solução ideal (esqueça a realidade).
2. Confronte-a com a realidade. Ela continua válida? Atenderia todas as necessidades?
3. Agora, ou atualize sua percepção do que é ideal (volte ao passo 1), ou lute para atualizar sua realidade para torná-la ideal.
4. Caso você esteja aqui, quer dizer que está buscando melhorar a realidade. Continue verificando se os efeitos das suas ações estão, de fato, levando a uma melhoria do seu dia-a-dia e continue a  inspecionar e adaptar o tempo todo.

Por favor, deixem seus pensamentos e críticas.

Leituras Ágeis - Melhorando o conhecimento sobre Agile

English

Trabalho como ScrumMaster em uma grande empresa de comunicação.
Nosso departamento de Pesquisa & Desenvolvimento tem um programa para a criação de, entre outros, uma plataforma de gerenciamento de conteúdo (CMS) capaz de atender as mais diversas demandas das redações. Temos 7 times utilizando Scrum compondo uma grande equipe de aproximadamente 45 pessoas.

Dado este cenário, uma preocupação que costumo ter é a de como melhorar o conhecimento de todos da equipe (incluindo o meu próprio) sobre metodologias e ferramentas Ágeis.

Recentemente nós, os ScrumMasters desta equipe, decidimos adotar uma prática que tem rendido bons resultados, inclusive gerando melhorias nos nossos processos: uma reunião de uma hora, duas vezes por semana, em que lemos e discutimos um livro sobre algum assunto Ágil previamente selecionado - chamamos este encontro de "Leituras Ágeis - Tertúlias".

Começamos os encontros com a leitura do livro do Henrik Kniberg - Scrum e XP direto das trincheiras - pois era um livro excelente, apesar de bastante simples e que todos já haviam lido. Ele serviria como bom guia para cobrirmos pelo menos a maior parte das práticas do Scrum (este livro em particular cobre muito bem as práticas, mas é declaradamente superficial em relação a teorias, princípios e valores).

É interessante que todos tenham lido o livro, ou pelo menos os capítulos previamente combinados. Para este primeiro livro, não foi necessário fazer anotações, pois uma leitura rápida na hora já foi o suficiente para gerar as discussões, que é justamente o que tem gerado mais resultados. Tenho certeza de que o próximo livro que pretendemos ler vai exigir mais de nós (em outro post eu comento qual livro selecionamos).

Quando chegamos a algum ponto em que alguém tem algum comentário a fazer, interrompemos a leitura do livro para que a discussão aconteça. Normalmente tentamos chegar a um consenso sobre se o que o livro prega é o ideal, depois se é melhor do que nossa prática atual e por que, por fim decidimos se vale a pena mudar nossas práticas atuais (com ações e responsáveis).

Este encontro tem suas regras:

1. Deve acontecer sempre (mesmo que faltem alguns participantes)
   O objetivo dessa regra é gerar ritmo. Logo que começamos, éramos apenas dois participantes, eu e outro Scrum Master. Como éramos só dois, a falta de um invalidava o encontro, mas conforme mais participantes foram se juntando, foi possível criar o ritmo necessário. Havendo pelo menos 2 participantes, deve-se realizar o encontro.
2. Timebox
   Mantenha a reunião dentro do período determinado. Fazemos de uma hora, mas decida a melhor duração e atenha-se a ela (até todos decidirem mudar)
3. Deve ser incentivada a presença de representantes de todos os papéis do Scrum
   Hoje temos alguns Desenvolvedores, Scrum Masters e Product Owners. Ainda não há nenhum gerente, mas também seria extremamente positivo. Como cada um vê melhor os impactos sobre sua própria área de atuação, as discussões são mais ricas e as decisões tomadas são mais facilmente implementadas.
4. Deve ser incentivado o confronto de idéias. Veja o artigo "Managing Confrontation in Multicultural Teams"
   Realmente recomendo a leitura do artigo acima, mas caso você esteja sem paciência ou não saiba inglês, o resumo é mais ou menos o seguinte: O confronto de idéias traz novos conhecimentos para todos os participantes da discussão. Há algumas culturas em que isto é difícil, pois é considerado rude ou simples má-educação. Se for o caso, o artigo recomenda uma prática: cada um levanta suas idéias e passa para um representante que vai defendê-las de forma que não há um confronto direto.
   Uma dica aqui é manter sempre o respeito e não interpretar como "perdi a discussão" e sim "aprendi algo novo". Por sinal, já perdi, err, quer dizer, aprendi várias coisas novas.
5. Deve ser feito um registro da discussão, das conclusões e ações determinadas
   O registro mantém o conhecimento gerado, relembra os porquês das decisões e permite o acompanhamento sobre as ações.
   Utilizamos hoje o Confluence para o registro. Inclusive acontecem discussões posteriores nos comentários.
6. Deve haver um acompanhamento sobre as ações
   Este encontro é uma prática que visa melhorar o conhecimento e alinhar percepções, mas também visa gerar melhorias no processo, então é importante manter um acompanhamento sobre se as ações determinadas estão sendo executadas e se o resultado está sendo o esperado.

Espero a opinião de vocês, inclusive com sugestões e qualquer relato de experiências semelhantes.