Nossa contribuição se expandiu. Palestras e workshops em eventos agile tornaram-se parte das atividades do nosso time, e para firmar nosso compromisso com a comunidade ágil, estamos patrocinando o Lean Kanban Brazil 2017. \o/

Lean Kanban Conferences

A Lean Kanban Conferences Internacional apoia conferências em diversos países, e Brasil está na lista. Com temas relacionados a gestão, a programação da segunda edição brasileira está dividida em três.

1. Webinars

Democrático e inclusivo, a organização preocupou-se em eliminar a restrição geográfica. Quem não pode participar do evento em São Paulo, tem opção de webinars pré-conferência.

No dia 17/10, nosso carismático agile consultant, Breno Campos falará sobre priorização de backlog e desenvolvimento de produtos/plataformas digitais no webinar Cost of Delay – Você perde por esperar. Ele vai mostrar que atrasos de projetos significam perda de grana $$$. Você levará um choque de realidade. o.O

2. Workshops

6 workshops focados em gestão, com duração de 4 horas, ocuparão salas no Espaço Franklin Covey (mapa).

Claro que o Raphael Albino — professor, mestre, doutorando, autor de livro e nosso agile consultant — estará lá no dia 27/10 promovendo o workshop Vamos falar sobre Métricas de Processo? Você não terá moleza. Vai por a mão na massa, praticar de verdade! Se conhecimento é poder, você será poderoso(a) depois dessa aula. :bulb:

3. Palestras

Estão dividas em 2 tracks, marcadas para o dia 28/10, no Grand Mercure Ibirapuera (mapa). Você terá oportunidade para networking nos coffee-breaks e almoço.

Pensa que acabou? Tem mais!

Nosso estande

Vamos compartilhar mais conhecimento nas Coaching Sessions que teremos no nosso estande.

Sério! Será imperdível! Sabe por quê? Porque não são coaching sessions sobre o que queremos ensinar. Abordaremos O QUE VOCÊ QUER APRENDER!

Para isso, você precisa nos ajudar a te ajudar (Tropa de Elite, caveiraaa!). Como? Basta responder neste formulário o tema do seu interesse.

Você quer o “faz-me rir” (faca na caveira)? Que tal 20% de desconto na compra da entrada?

Clique aqui e responda o que você quer ver nas Coaching Sessions

The post Estamos patrocinando o Lean Kanban Brazil 2017 first appeared on Plataformatec Blog.

We, at Plataformatec, used to measure LT by calculating the time that a story would take to move from a “Developing” column until the end, usually the “Done” column, which means that the story is in production. However, a past project made us question that definition.

We had a project in which the bottleneck of the process was before the developing process: the UX designing phase. We couldn’t see it in numbers, because it was not being measured. The only way it was possible to spot it was based on the team’s feelings. After the successful end of the project, we had an internal retrospective ceremony in which we’ve stated that if we had concrete information on the UX phase, we would be able to act on it earlier.

One of the alternatives that we found, would be to measure the LT of the whole process, from “Input” to “Done”. And that is what we did in our latest project, the new Elixir Radar channel project, and we would like to share our insights on it.

The Experiment

The project had the following Kanban board at the beginning:

We defined our LT as the time a story would take to go from “Refining” until “Done”. We chose “Refining” instead of “Input” because at that moment, we would only start working on a story from “Refining” on.

However, we saw that we still could not answer a question: “What are the next X stories that you want to be done in Y weeks?”. To do that we would need to limit the WIP of the “Input” column and start measuring the LT starting at that same column. So, as we explained in our wip-limit blog post, we limited the “Input” WIP, we cut off the “Refining” column, since a card would stay on it only for a few minutes (in our team a refining meeting had a very low cost to be done), and we started calculating the LT from “Input”.

Results

One of the results that we got from those changes was the fact that now we could inform the client (or the Product Owner) how much time it would take us to deliver something that he asked for. We believe that information is what really matters to him/her. Measuring from “Developing” to “Done” would not satisfy the P.O.’s question, because a lot of work is done before a feature is ready for development.

This little change in the measuring process also gave us extra information on the Lead Time Breakdown chart. As we could now see the amount of time spent in early stages of the process, we could also limit the WIP in columns like “Ready to UX” and “Ready to Dev”, which has lessened the time spent on those columns and reduced the total LT.

This extra information also helps the communication with high-level stakeholders that want to know where the time is being spent in your project.

We also noticed that extending the LT to all the parts of the process reinforced the image that everyone is working together on the project. That made the PO and UX designer of the project get much closer to the rest of the team.

On the other hand, it is important to say that measuring earlier stages of the process may scare the team at first, because the LT values will grow. The industry is used to have the feeling of productivity related to developing, testing and deploying cycle.

Therefore, we think that instead of making a complete transition from a developing-to-end LT to a whole-process LT, one should actually maintain both metrics at the same time. With both, you can still control your development team improvements (with all the historical data that you already have) and start monitoring the rest of the process.

We also had an insight that it may also make sense to calculate the LT of sub processes that make up a work system. For example, one could possibly calculate an UX LT by measuring the amount of time that a story spends to go through all stages related to UX. But that’s a subject for another blog post…

What about you? How do you measure lead time? Did you like our approach? Tell us what you think in the comments below.

The post Lead Time Experiment: Calculating Lead Time of the whole process first appeared on Plataformatec Blog.