Building Minds - o Blog da OnCast

What should you, as a developer, deliver at the end of each iteration?

Usually developers using Scrum are concerned with measuring velocity and providing visiblity over the evolution of the iteration by using story points. Therefore, what they are really concerned is to deliver that right amount of story points at the end of the iteration. Is there something wrong with that? Well, maybe! let’s see:

The agile manifesto says that:

Working software is the unique measure of progress.

Most of developers that are starting doing agile strugle to deliver working software every iteration. They also have a speciall attention in doing “correct” estimates, so that they can provide visibility of what is going on. In the other hand, the customer will also be happy due to the fact that he knows that, at the end of the iteration, he will get 35 story points delivered as planned by the team. In fact there is nothing wrong with measuring velocity and keeping a good level of visibility for what is going on your project. The problem happens when you deliver working software that corresponds to the velocity that you’ve estimated, but this working software does not deliver value to the customer.

This sometimes is simply a misunderstading of what value really means to the customer. If the team practices a little bit of empathy, you may get this problem solved very quickly. However, if the problem is caused by a lack of a common vision of the product, you probably are incurring in a much worse problem. If developers are just being told by the product owner customer what to do and they can’t see the whole, they certainly won’t be able to understand what value really is. In this case, a cultural change might be needed in order to deliver value. In both ways, selecting the right priorization criteria will actually determine that value you deliver.

So, the answer for the question is: developers should must deliver value at the end of each iteration, not only story points. Think about that!

A big thank you to David Hussman who gave me these insights at Ágiles2009.

Samuel Crescêncio Metodologia

Uma experiência interessante: Pegue uma pulga, a coloque em um pote e o tampe. O que você vai observar é que durante um tempo esta pulga ficará pulando e batendo contra a tampa na esperança de fugir. Passado algum tempo a pulga se condicionará a não pular tão alto já que pular alto não está se provando eficiente (a menos que o objetivo seja ter uma dor de cabeça).

O que acabou de acontecer com a pulga é o estabelecimento de um paradigma, um conjunto de regras que levam a uma conclusão, no caso “Pular alto não me levará a lugar algum”.

Abra a tampa e o que acontece? Ao contrário do esperado a pulga não vai fugir. O condicionamento impõe à pulga que ela não pule alto, o paradigma em que ela vive diz que pular alto não é uma boa prática.

Leia mais…

Rodrigo Machado Metáforas

Now that most of the labor related to the two best conferences that I’ve ever been has gone, I’ll take time to organize my thoughts and share with you. I’m talking about Agile2009 Conference that took place in Chicago, which I had the opportunity to work as a volunteer, and Ágiles2009, the second Latin American Conference about agile methodologies. This last one took place in my beautiful Florianópolis, and I had the honor to be the Chairman. I’m gonna first describe my experience about Agile2009 in Chicago.

“I’m gonna write in English from now on in order to make it possible to friends that I’ve made abroad communicate with us through this blog.”

I’ve really learned a tremendous amount of new things this year, specially  by dedicating a considerable part of my time working to make these conferences a great experience to myself and to everyone that had the opportunity to attend to them.

Volunteers applying Lean Principles

As a volunteer in Chicago, I could work on the backstage of the one that is the most famous agile conference in the world, and learn how they’ve organized such a great conference. I could then apply what I learned in the Ágiles2009 organization. As I’ve never organized a conference before, every detail that I could learn in Chicago was tremendously valuable for me. One of the greatest experiences I had there, was applying Lean principles in the bag assembly. We, as a whole team of volunteers, created a production line, applying the concepts of continuous flow and an integrated chain of material suppliers. Also, sometimes we used the stop the line concept during the work, aiming to continuously improve the process. One of the goals for this production line was to keep small inventories of materials in the assembling line.

I remember that there was a box full of books boring me in my way, therefore preventing me to be faster. I was not responsible to provide materials for the production line, this was a task of another group of volunteers. My job was to work in the production line assembling bags. As that box was really boring me, I decided to stop what I was doing, take the books out of the box and put them in the production line. Then, the guy who was responsible to keep the inventory in the production line arrived with another bunch of books and noticed that something was wrong. There was too many books in the line now. He looked to me with that face, and I said: opssss! I broke the system :s - sorry. This was one of the times that we stopped to analyze the root cause of the problem and improve the system. That box placed in the wrong place was the root couse of the problem. It was very funny, productive and an outstanding way to check out new Lean ideas, while working and making new friends.

What we brougt from Agile2009 to improve Ágiles2009

Keynote - Alistair Coockburn - photo by Tom Poppendieck

The Agile2009 conference joined more than 1.300 professionals that were there to learn, teach and to improve their networking. With this big number of people, keeping things flowing smoothly amongst speakers, volunteers, organizers and attendees is a really hard job, and I also wanted to learn how they did that. This conference is incomparable with Ágiles2009 in terms of budget, structure and size. Consequently, it’s a perfect place to learn from. I can securely affirm that the success of the volunteers organization at Ágiles2009 came from what I learned at Agile2009 as a volunteer. I just gave the tips to the volunteers leads and they have really done a good job. Thank Alex, Rafael and all the team for that. The Jam Session we had at Ágiles2009 was a smaller and different version of the Music Mastik that we had in Chicago. And the open spaces that we created for Ágiles2009, well, this idea originally was created in the first Ágiles2008, but I also saw that in Chicago, and wanted to repeat at Ágiles2009. One of the most famous guy that used this space was Brian Marick while pair programing with other guys. Awesome!  I want these conferences to be a great place for management to learn, but also a perfect environment to geeks dig deeply into the code and really do agile development.

In Chicago I could meet and talk to gurus such as Alistair Cockburn, Martin Fowler, Diana Larsen, David Hussman, Brian Marick and several other guys that are my favorites sources of knowledge.

From Left to Right, Pedro and Thiago from São Paulo, Eduardo a very nice guy that is from Floripa but lives in Chicago, Alistair Coockburn, Rodrigo and Samuel from OnCast and Hugo from São Paulo.

Another priceless opportunity was to meet again Mary and Tom Poppendieck, and to have a break fest at the venue with them. Rodrigo (my partner) and I enjoyed this time to talk about what would be the best release time-frame for a complex product that we want to develop at OnCast. With this conversation we discovered that our thoughts regarding release time were correct

Also, as I’m a wannabe photographer, I asked some questions to Tom about what would be the best first professional camera to buy, and following his suggestions I bought a Cannon Rable XS before leaving Chicago.

Me getting photografic tips with Tom Poppendieck

I’ll soon take more time to post more information about the specific sessions that I’ve attended at both conferences, as well as to dedicate a post like this to Ágiles2009. Hope you enjoyed this first introduction.

Samuel Crescêncio Comunicação

Outubro está sendo um mês voltado para a Gestão do Conhecimento para a Florianópolis e, principalmente, para a OnCast.

Inciamos o mês com o sucesso do ÁGILES 2009 e concluiremos com uma participação especial no “IV Fórum de Governança em TI”. O tema central do fórum será sobre o “Alinhamento da TI ao Negócio Utilizando na Governança e Gestão Ferramentas e Metodologias Inovadoras”. Teremos, portanto, a aplicação de metodologias e ferramentas internacionalmente consolidadas e atuais utilizadas nas melhores práticas de Governança e Gestão de Tecnologia da Informação e Comunicação.

Um evento rico em palestras e workshops ministrado por profissionais experientes. Uma das palestras será ministrada pelo CEO da OnCast, Samuel Crescêncio que apresentará o tema “Lean Software Development: Da gestão estratégica à operacional” no dia 23 de Outubro às 14h45, no CELTA - Centro de Eventos Renato Archer.

Confira a programação no site do evento e faça já a sua INSCRIÇÃO.

Mirela Rzatki Outros

Atualmente, muitas empresas estão adotando metodologias ágeis e em especial o Scrum com o objetivo de melhorar a gestão de seus projetos de software. No inicio, os projetos utilizam um workflow simplificado para sinalizar o andamento da iteração. Esse fluxo normalmente é composto por 3 estados:

• TO DO: Estórias selecionadas para o backlog da iteração que estão aguardando para serem iniciadas.
• IN PROGRESS: Estórias em andamento, sendo executadas pelo time no momento.
• DONE: Estórias prontas para serem entregues.

Segue abaixo um exemplo de um Scrum board com um fluxo simplificado:

Com o passar do tempo, surge a necessidade de amadurecer esse workflow, mapeando ações técnicas e de qualidade que reunidas formam o conceito de Definição de Pronto (ou Definition Of Done).

A Definição de Pronto reúne os critérios que o time deve seguir para que uma funcionalidade possa ser realmente considerada pronta, não só técnicamente mas também com qualidade. Essa definição é composta por uma lista de ações como: escrever testes de aceitação, codificar, revisar o código, validar o que foi feito com o product owner, fazer o deploy no servidor de produção ou qualquer outra coisa que precise ser feita para que a funcionalidade possa ser entregue atendendo as necessidades de negócio. Com a evolução do projeto, é importante estar sempre observando e adaptando esses critérios para que eles possam acompanhar a realidade projeto, estando alinhados com as expectativas do cliente.

Os problemas surgem quando algumas ou muitas dessas ações não são executadas corretamente e assim muitas estórias consideradas prontas pela equipe acabam tendo problemas na hora da revisão com o product owner, não sendo aceitas. Um fator que contribui para isso é a utilização de estados nebulosos no workflow do projeto. Decompor o estado “in progress” em estados que representem importantes ações da Definição de Pronto aumenta a visibilidade do time sobre qual etapa do processo está sendo executada e facilita a identificação e remoção de gargalos, aumentando a eficiência do processo.

Segue abaixo um exemplo de Scrum board com um workflow contendo os estados de codificação, revisão de código e deploy :

Para manter o fluxo constante, é importante evitar o acumulo excessivo de estórias em cada estado. Estes acumulos criam estoques que diminuem o ritmo e a freqüência de entregas, incentivando um comportamento multitarefa que contribui para um fluxo ineficiente e com desperdícios.

Segue abaixo um exemplo de Scrum board com acumulo de estórias em revisão de código causando a demora do deploy de varias estórias já codificadas:

O número de estórias em cada estado é denominado WIP (Work in Progress). Limitar o valor do WIP contribui para impedir a sobrecarga do sistema e faze-lo trabalhar com a sua capacidade real. Assim, as demandas começam a se adequar a capacidade de produção do sistema e não o contrário. Além disso, a ocorrência de impedimentos acaba causando uma interrupção no processo (ou stop the line), afetando o trabalho de toda a equipe e fazendo com que os impedimentos sejam resolvidos rapidamente.

Para entender melhor sobre a dinâmica da teoria das filas que a limitação do WIP proporciona é fundamental acessar uma simulação completa do funcionamento do kanban em: http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

Segue abaixo um exemplo de Scrum board com limite do WIP em 1 para o estado de codificação, em 1 para o de revisão de código e em 3 para o de deploy. Dessa forma, nunca poderá haver mais de uma estória em codificação, uma estória em revisão de código e três estórias em deploy, aumentando a colaboração da equipe e a utilização de técnicas como o pair programming. Lembrando que esses valores variam dependendo do objetivo e quantidade de pessoas na equipe. A alteração dessas variáveis pode ajustar o processo, afetando a produtividade do sistema.

Dessa forma é possível criar um workflow que prioriza a visibilidade do trabalho em execução, evidenciando impedimentos e gargalos, além de manter o sistema estável e constantemente otimizado. Com isso é possível entregar com mais freqüência e com mais qualidade, melhorando a percepção do cliente e criando um ambiente de desenvolvimento melhor para todos.

Segue abaixo alguns links para blogs importantes que falam sobre o assunto:

http://www.limitedwipsociety.org/

http://blog.crisp.se/henrikkniberg/

http://leansoftwareengineering.com/

http://www.alissonvale.com/englishblog/

http://damonpoole.blogspot.com/

Segue também uma lista de ferramentas e padrões utilizados no processo:

• Value Stream Mapping
• Visual Management
• Pull System & Single Piece Flow
• Limited WIP
• Buffers & Queue Limits
• Classes of Service
• Leveling Work
• Two tiered Systems (Expand/Collapse)
• Swimlanes/Expediting
• Triggers
• Priority Filters
• Perpetual Multivote

Rodrigo Branas Ferramentas, Metáforas

O resultado do trabalho de uma equipe tem relação direta com o comportamento e as atitudes de cada membro do time durante o desenvolvimento do projeto. Com o objetivo de conquistar mais maturidade após cada iteração, melhorando continuamente os processos de estimativa e a qualidade das entregas, é preciso estar inserido em um ambiente colaborativo, flexível e principalmente auto-organizado, que consiga despertar a pró-atividade e responsabilidade dentro da equipe.

Se auto-gerenciar sem dúvida é um grande desafio. Desde que nascemos, nos acostumamos com relações de comando e controle com nossos pais e professores, não assumindo na maior parte do tempo grandes responsabilidades. Com o tempo e a entrada no mercado de trabalho, o medo de errar acaba sendo um incentivador para permanecer nessa zona de conforto, confiando a outras pessoas o gerenciamento de nossas ações e responsabilidade pelos nossos resultados. É preciso ter coragem e força de vontade para superar o medo e vencer o desafio de se expor, assumindo os riscos de um comportamento pró-ativo e inovador.

Mas antes de tentar modificar o comportamento das pessoas, é preciso tratar os vícios de arquiteturas organizacionais verticalizadas, burocráticas e sem foco no cliente. Pensando em liderança servidora, a adoção de um modelo de gestão mais flexível e colaborativo é fundamental. Ao estimular a participação do time, substituindo a figura do gerente pela de um líder, a preocupação deixa de ser em determinar como, quando e em que ordem pré-determinada cada pessoa deve agir dentro do processo produtivo e passa a ser em como traçar objetivos claros, remover bloqueios e cuidar para que interferências externas não prejudiquem o trabalho da equipe.

A utilização de especificações detalhadas cria uma relação de dependência da área de negócio, diminuindo a comunicação e colaboração dentro do time de desenvolvimento. Combinado com a imposição de estimativas, propicia um ambiente altamente robotizado, insustentável e com alto índice de rotatividade em decorrência da falta de motivação.

Ter um objetivo é fundamental para motivar as pessoas a pensarem. Fazer com que o produto evolua com mais qualidade exige que a comunicação seja intensificada envolvendo o cliente no processo de desenvolvimento, dando a ele a oportunidade de confrontar suas idéias, raciocinando sobre como cada funcionalidade se encaixa dentro do produto e se realmente ela é importante para gerar o valor necessário ao seu negócio e aumentando seu grau de satisfação.

Criar ambientes multidisciplinares ajuda a reduzir os silos, convergindo todo o potencial produtivo de pessoas de diferentes áreas de conhecimento de forma sincronizada e assertiva. A mistura de uma arquitetura organizacional servidora e focada nas expectativas do cliente com uma equipe multidisciplinar guiada por objetivos claros, auto-organizada e sincronizada propicia um ambiente ideal.

Como resultados e benefícios temos:

• Melhoria da comunicação interna e agilidade na tomada de decisão.
• Foco dos gestores na estratégia da empresa deixando as decisões importantes dos projetos para as equipes.
• Aumento da satisfação dos funcionários em um ambiente melhor para se trabalhar.
• Surgimento de líderes fazendo com que a empresa possa assumir novos projetos.
• Qualidade e confiabilidade nas entregas aumentando o grau de satisfação do cliente.
• Aumento da participação no mercado e da lucratividade da empresa.

Rodrigo Branas Auto-gestão