workshop: Otimizando o fluxo de trabalho em projetos ágeis

Neste workshop, falaremos sobre otimização do fluxo de trabalho em projetos ágeis. Os seguintes tópicos serão explorados em detalhe:

Workflow, Desenvolvimento de software Ágil e incremental, Card wall, Fluxo dos cartões na parede, Conceito de Action stage e Waiting stage, Parâmetros de fluxo (WIP, lead time, cycle time, batch size, throughput), Pull & Push System, Replenishment, Teoria das Restrições, combinação de Scrum com Kanban, gerenciamento visual (Story tracking, Bug Tracking, Cumulative Flow Diagram, Control Chart, Story Tracking Diagram), planejamento e tracking de projetos ágeis.

Este workshop inclui atividades práticas e simulações do dia a dia de projetos ágeis. A partir de tais atividades práticas, conversaremos sobre aspectos qauntitativos e qualitativos relacionados a melhoria do fluxo de trabalho.

Público alvo: agilistas, gerentes de projeto, executivos, analistas, desenvolvedores e QAs.

 fotos de workshops já realizados.

feedback de workshops anteriares.

Próximo agendamento: 4 de Setembro em São Paulo na Virada Ágil da  AgileBrazil 

http://www.agilebrazil.com/2012/pt/viradaagil/otimizando-o-fluxo-de-trabalho/

 

John Little, whiskey and flow

Here are the slides on my latest talk:

John little, whiskey and flow from paulocaroli

Scrum com Kanban na FISL13

Hoje, em Porto Alegre, estarei apresentando a palestra Scrum com Kanban na 13ª edição do FISL.

um dos slides da palestra (gráfico de lead time e cycle time)

"Há 13 anos, o Fórum Internacional Software Livre – fisl, vem crescendo e se consolidando como o mais significativo encontro de comunidades de Software  - e cultura! - livre na América Latina. Mundialmente reconhecido, o fisl já treze anos é o resultado do trabalho, da colaboração e do envolvimento de milhares de pessoas que acreditam no software livre e na força da comunidade, no Brasil e fora dele." http://softwarelivre.org/fisl13/sobre-o-evento

palestra: Scrum com Kanban; pequenos ajustes, grandes melhorias

Título

Scrum com Kanban; pequenos ajustes, grandes melhorias

Resumo

Kanban e Scrum não são ortogonais entre si, na verdade eles podem ser bastante complementares! Venha participar desta sessão e aprender como melhorar o framework Scrum via Kanban add-ons.

Descrição completa

Nesta apresentação, mostraremos o fluxo de trabalho que Scrum utiliza. Falamos sobre os beneficios de visualizar o workflow. Comentamos sobre as diferenças entre trabalho puxado e empurrado, e o impacto de cada uma para equipe que desenvolve o software. Comentaremos sobre limitar o trabalho em progresso para maximizar a vazão do trabalho. Compartilharemos ferramentas para monitorar lead time e cycle time, com o intuito de identificar gargalos e problemas que se repetem ao longo do processo.

Utilizamos exemplos simples e compreensíveis para explicar a teoria e as idéias. Incluímos cenários de projetos reais para ilustrar os pontos abordados durante a apresentação.

Bio e mais informações: www.kanbanandbeyond.com

Mecânica/Processo

Usamos um conjunto de slides com muitas imagens e figuras ilustrativas. O estilo de apresentação é muito fluído e visual.
A apresentação está disponível aqui: http://sites.google.com/site/kanbanandbeyond/examples/files

Benefícios

Você vai aprender:
- Uma visão clara sobre como Kanban complementa Scrum
- Duas maneiras simples de controlar lead and cycle time
- Como usar o lead time para ajudar com o planejamento do Sprint (em vez de usar apenas a velocidade – yesterday’s weather)
- A correlação entre limite de WIP e redução de lead time.
- As perspectivas de Scrum e Kanban sobre a curva S

Experiência com o assunto

Regulamente, apresentamos palestras e workshops sobre Kanban: sistema puxado, WIP, Little Law, monitorando lead time e cycle time. Este ano, fomos convidado para palestrar num evento de Scrum. Dado a nossa experiência com grandes programas de Scrum, decidimos criar uma apresentação para demonstrar como usamos Scrum com Kanban. Apresentamos esta sessão algumas vezes. O público adorou.

Workshop on Flow at the Agile Game night

Last week I participated on the Agile Games Night at Porto alegre, Brazil.

The event took place at the UniRitter university.

Congratulations to GUMA-RS and the amazing people running the Agile show in this region!

To name a few: @dwildt @lcparzianello @paulocaroli @jorgee_audy @flaviosteffens @rafaelpri

On this event, I run the Kanban And Beyond workshop as a 1 and ½ hour game.

The audience had a great time! (check out the results of the Return of Investment activity)

Below are some photos from this workshop instance.

Looking forward to the next workshop.

Kanban and Beyond at Agiles 2011

This week I was at Agiles 2011, the 4th Latin American Conference on Agile Methodologies.

I had the pleasure to give a 2 hour version of the Kanban and beyond workshop. It was very well received by the participants. I did do some improvements since the last time I run the workshop at a conference (the Agile Brazil 2011 conference).

For the 2 hour workshop at the Agiles conference, I decided to shorten the activity time and give only a taste of the full workshop. The results were superb! The participants really enjoyed it. The fact is that the workshop is better suitable for a 4 hours or a full day activity.

I have improved the presentation and the workshop. Now I have different versions of the workshop for different event slots. I have also created site for the workshop. www.KanbanAndBeyond.com on it you will find the workshop material, feedback, photos and much more.

Little Law, cycle time and throughput

In this blog entry I talk about whisky and Little Law. While sitting at my dining table I was thinking about a way to explain Little Law, cycle time and throughput. This idea came to mind once I did pour myself a glass of whisky. It was the last dose of a Macallan 12 bottle. I removed the empty bottle from the bar, and took a note to buy another one.

Problem Statement A: At home, I have 12 bottles of whisky at my bar. I consume and purchase an average of 6 whisky bottles per year. What is the average time each whisky bottle stays in my bar?

Or, stating the same problem in a different way:
Problem Statement B: At home, I have 12 bottles of whisky at my bar. In average, I finish (and purchase) one whisky bottle every two months. What is the average time each whisky bottle stays in my bar?

From the problem statements I can get the following parameters:
The inventory or WIP is 12 bottles. (Problem statement A and B)
Throughput is 6 bottles per 12 months (Problem statement A)
Average Cycle time is 2 months per bottle(Problem statement B)

And the question is the average lead time

I will solve the problem two ways:
Solution 1:
WIP = Throughput x Average Lead Time
12 bottles = 6 bottles /12 months x Average Lead Time,
Therefore, Average Lead Time = 24 months

Solution 2:
Average Lead Time = WIP x Average Cycle Time
Average Lead Time = 12 bottles x 2 months/bottle
Therefore, Average Lead Time = 24 months

The formulas used on both solutions are equivalent:

WIP = Throughtput x Lead time
<=>
Lead Time = WIP x Cycle Time

Here are the definitions for these equations’ parameters:

• lead time is the time between the initiation and delivery of a work item.
  
• cycle time is the time between two successive deliveries
• throughput is the rate at which items are passing through the system.
• WIP – Work in progress; the number of work items in the system. Work that has been started, but not yet completed

Although these formulas are intuitively reasonable, it's quite a remarkable result. And this is the main theorem in the Queuing Theory, which is also known as Little’s Law (It was described by John Little in 1961):

The average number of work items in a stable system is equal to their average completion rate, multiplied by their average time in the system.

The average completion rate can be represented by either throughput, or its inverse, average cycle time. This duality is shown at problem statements A and B. These equivalent statements are made in terms of, respectively, throughput and average cycle time.

I don’t know about you, but before digging into Lean, I was a little confused by Throughput and cycle time (and I did not measure it). I hope this blog post you a simple way to understand and explain it. I also hope more people start measuring such important parameters (I can’t believe I did not use these before going Lean!).

Lead time vs cycle time; from Manufacturing to SW development

I have seen different definitions for lead time and cycle time in the Agile and Kanban communities (for SW development).

From Lean manufacturing:

lead time is the time between the initiation and delivery of a work item.

cycle time is the time between two successive deliveries

In my opinion, this translates directly to Agile SW development like depicted in the photos below.

For a typical Agile development team the workflow is something like:

Backlog -> Ready for Dev -> In Dev -> Ready for Validation -> Validating -> To Be Deployed -> Deployed

Next is a sequence of photos from a card wall depicting these concepts. Please have in mind that I am only showing two stories for illustrative purpose.

lead time is the time between the initiation and delivery of a User Story; in our case it is the time a Story enters the Deployed stage minus the time the story has entered the Backlog stage. Story 34 has entered the Backlog in day 4, and enters the Deployed stage on day 11; lead time equals 7 days (day 11- day 4).

cycle time is the time between two successive deliveries; in our case it is the the time between two stories entering the last stage-- Deployed stage in this case. 34 enters the Deployed stage on day 11, then two days after, the next story-- Story 37--enters the Deployed stage; cycle time equals 2 days (day 13 – day 11).

These metrics should be collected for the set of Stories the team has delivered,. This way you can get the average lead time and average cycle time, two powerful process improvement metrics.

Varying the WIP limits on the workflow stages (assume the same set of Stories, and the same team members) will affect the average lead time and the average cycle time.

This is what the workshop I have been running is all about!

My hypothesis is that after people participate on the workshop they will have experienced the Little’s Law.

Little’s Law: Lead Time = Cycle Time x WIP

On the next blog entries I will write about the Little’s Law and the workshop.

Feedback from the workshop – Agile Brazil 2011

First of all, I want to thank each and everyone who gave feedback on the workshop and activity: Don’t limit yourself. Based on your feedback I will be able to improve the workshop: Don’t limit yourself workshop – Agile Brazil 2011.

I did collect feedback at the session itself. I followed the same style used on QCon Sao Paulo last year. At the end of the session I had a bow, a few pen and cards (blue, yellow and pink; respectively great, medium, bad). The workshop attendees could write a few lines of feedback on the chosen card and drop it at the bow.

Here is the feedback written on these cards (in no particular order):

• More time required for the activity
• Please talk about techniques on negotiating Kanban limits with a client
• Interesting topic; activity could be more organized
• The activity consumed too much time.
• The game was good, but I wanted to hear more about the results.
• Replenishment + +
• The presentation was excellent; not enough time for the activity.
• Suggestion: add a timer for the activity.
• Excellent! Best talk on Agile
• Congratulations!
• I really like the target idea. I will try to put it in practice. The activity should be more organized; I suggest more time and control.
• Congrats. It was very good!
• Really good activity; I will put it in practice!
• The unique point of view on the flow was very pertinent. The activity really cool and gave me a practical view of the flow theory.
• Really cool activity!
• Print out the activity rules, and have make the roles more defined. For instance, you could have the pizza dude making decisions on where people work. There were too many people on the team making/trying to make decisions.

Based on these feedback and more I did receive verbally, I will do the following for the future of this workshop.

• Keep a version of the presentation without the activity. The presentation was very well received, and the time was under control. I might use it again for talking about Kanban, flow, and the target-variance score. Perhaps I can add a few slides explaining that experiments (such as the workshop activity at Agile Brazil) have show good results.

• For the workshop activity I will do the following improvements:

1. Make reusable cards. It was too much work to prepare, and I will not be able to reuse these cards.

2. Add a mark for amount of work completed in each card (50% done and 100% done)

3. Add a timer for each half day (for example: 1 minute for each half-day)

4. Keep the same numbers of people involved (1 BA, 5 Devs, 2 testers), but reduce the number of people making decisions on who should work in which card and stage (at most 3 people for each team).

5. Time box the activity

6. Have enough time for discussing the results (10 minutes at the end)

7. Have the card wall for each team already prepared on each team table. This should include the cards already on play on day 1 (now renamed to day 3). The theory on limits and targets is already covered during the presentation.

8. Have avatar for each team member ready (BAs, Devs and testers)

9. Simplify the rules (consolidate it), and have it visible at the wall

10. Have a calendar to show the days passing by (again, visible on the wall)

11. Have one person for each two teams to answer questions (co-presenter)

Please let me know if oyu have any more feedback. And once again, thanks for the feedback!