Agile Scrum Lean
XP eXtreme Programming Peru Ágil Agile Outsourcing Agile Training Agile Coaching Optimización de Procesos Desarrollo Agile ScrumMaster BPM Kanban
Blog
Dare 2013!Posted in Blog on Mayo 08, 2013 by Manolo Mazan
Dare 2013 in Belgium is a promising conference with speakers of the calibre of Jim benson and Dean Leffingwell among other experts in Lean and Agile. I'm delighted to be accepted as a speaker! Following my "How to recover a chaotic..." series, in this opportunity I leave the software development domain to present "Recovering a chaotic recruitment process using Lean and the Kanban method" See you soon!
Case Study: Recovering a Chaotic Software Development Project using Lean and the Kanban methodPosted in Blog on Septiembre 27, 2012 by Manolo Mazan For the benefit of the Lean and Kanban community I'm enclosing a complete industry case study in English. The paper is based upon data collected for over 1.5 years. This is the way "software factories" should operate showing profound respect to the human beings doing knowledge work while adapting to change at a sustainable pace. This case study was presented at the Lean Kanban Southern Europe Madrid 2012 conference (http://lkse12.leanssc.org) and Agiles 2012 in Argentina (http://agiles2012.agiles.org/?lang=en), also it has being featured at the front of prestigious Software Gurú magazine http://hulk.sg.com.mx:8085/downloads/pdfs/SG35-BigData.pdf
As an appendix I have added a Kiveat-style diagram showing depth of Kanban implementation. You can download the English version of the case in PDF here
I would like to thank Dr. Arne Roock for his feedback!
Table of contents
Table of Contents
1. Abstract
2. Introduction
3. The company
4. The Situation
5. Why Lean and Kanban
6. Start by identifying team values
7. Define a team vision
8. Kaikaku
9. Waste in conversations
10. Waste in code
11. Cultural change
12. Emergence of Systems Thinking
13. Daily stand-ups
14. Retrospectives
15. Advanced retrospectives
16. Estimating using story points in Kanban is waste
17. Evolution to an advanced kanban board
18. 5 Whys
19. Kaizen
20. Problems with Kanban
21. Measuring Lead Time and Cycle Time
22. CFD (Cumulative Flow Diagram)
23. SPC (Statistical Process Control)
24. Conclusions
25. About the Author
26. Brickell Key Award
27. References
APPENDIX - Kiveat-style diagram showing depth of Kanban
1. Abstract 2. Introduction 3. The company 4. The Situation 5. Why Lean and Kanban 6. Start by identifying team values 7. Define a team vision 8. Kaikaku 9. Waste in conversations 10. Waste in code 11. Cultural change 12. Emergence of Systems Thinking 13. Daily stand-ups 14. Retrospectives 15. Advanced retrospectives 16. Estimating using story points in Kanban is waste 17. Evolution to an advanced kanban board 18. 5 Whys 19. Kaizen 20. Problems with Kanban 21. Measuring Lead Time and Cycle Time 22. CFD (Cumulative Flow Diagram) 23. SPC (Statistical Process Control) 24. Conclusions 25. About the Author 26. Brickell Key Award 27. References APPENDIX - Kiveat-style diagram showing depth of Kanban
Understanding Kanban Thinking with The Ball Flow GamePosted in Blog on Septiembre 10, 2012 by Manolo Mazan Last week I decided to try Karl Scotland's "Ball Flow Game"
so I facilitated the game with a colleage at Taller Technologies.
The aim of the game was to experiment flow, WIP limits and a
systemic approach to continuous improvement.
This game is a variation of the classic "Ball Point Game"
used to teach Scrum and make the participants feel what working
in a Scrum environment is like.
Interesting enough the "Ball Flow Game" generated a different team dynamic
compared to the "Ball Point Game". Conversations had a systemic approach and were based upon quantitative analysis according to statistics collected from passing 20 balls in
the shortest possible Lead Time in 5 rounds.
We run the 5 rounds pretty much following the same rules as descrided by Karl Scotland, I decided however to introduce 3 roles: the team, the product owner (in charge of feeding balls to an INPUT bin and respecting the capacity agreed for the system) and a me as Coach (in charge of the interpretation of the statistic), so let's see below what happened in each experiment!
ROUND 1
We let the team self-organize before starting. This round was a bit sloppy since we started to learn how to work as a team, basically the Product Owner filled out the INPUT bin and one team member started to "push" balls into the system as fast as he could. After the second ball we could say that cycle time improved and remain pretty much constant up until losing up coordination at some stage. Throughput had a maximum of 2 balls per every 10 seconds and if you look at the Cummulative Flow Diagram it was pretty obvious that the system was underutilized with a WIP of 1-2 balls at a time for a team of 10 people. Therefore there was a lot of slack in the system and it was very clear that the person collecting the balls from the INPUT bin and returning them back to the OUPUT bin was the bottleneck in the system. The last ball came out at 2 minutes 23 seconds.
ROUND 2
First reaction was again allow the team to self-organize and let them decide changing the team member who was the bottleneck. This time the team collaboratively brought the discussion to a whiteboad with the aim of looking at the best system design to reduce the lead time for the 20 balls. Round 2 started a bit chaotic with an increase in lead time (43 seconds) for the 5th ball followed by an aggressive reduction up until reaching a point of "stabilization" (10th ball onwards) thanks to a better degree of coordination. As a result we had a clear improvement in throughput compared to round 1. Chaos is reflected in the graphic as per the first few balls however after 60 seconds have elapsed the Cumulative Flow Diagram showed better utilization of resources due to removal of the bottleneck and improvement of flow. The replacing team member introduced balls faster, the average WIP increased to almost 4 balls at a time, less slack and a better system design improved the whole. The overall lead time for the 20 balls improved to 1 minute 48 seconds
ROUND 3
In this round we suggested to put a WIP limit of 5 balls at a time (without batching them). The Product Owner dropped 5 balls to the INPUT bin for a memmber of the team start feeding the system up til the first ball coming out signalled the Product Owner to feed the INPUT bin again at a rate of one ball at a time. Despite having an unpredictable process mainly due to a bad system design which hindered coordination and caused a significant amount of "bugs" (balls falling off) limiting the work in progress improved cycle time times for each ball (with the highest spike at 26 seconds) compared to round 2 (with the highest at 44 seconds). The whole was improved and overall lead time for the 20 balls went down to 1 minute 36 seconds
ROUND 4
We reflected upon the previous round work system design and discovered the benefits of experimenting with explicit WIP limits. This time we increased the WIP limit to 6 balls since we believed we still had a bit of slack in the system. Throughput was high right from an early start and the analysis showed a high level of certainty. The Cumulative Flow Diagram also reflected this predictability and overall we had a reduction in Lead time to 1 minute 5 seconds, much better than the previous rounds!
ROUND 5
This round was the best of all, the team self organized and decided to try out again changing the person in charge of the INPUT/OUTPUT bins, we increased the limit to 7 balls. This time we achieved the best coordination of all rounds, no bugs (balls falling down), statistics show that variation was reduced to a minimum around the mean, the average lead time was just 8 seconds and the throuput after 20 seconds was kept constant at 4 balls every 10 seconds up until flushing the last 3 balls out from the system. The Cumulative Flow Diagram is steeper compared to the previous round reflecting the fact that now we have a very smooth flow. The process is now highly predictable and is completely under control, this is what customers like, right? Imagine telling the customer that every week you are deliverying 4 features consistently. Overall time went down to 57 seconds!. Each round we improved not just based in anecdotical data but in concrete quantitave data analysis studying what our current system was capable to deliver and experimenting with changes to make it more predictable. We achieve higher quality and productivity and this is what we aim for when we develop software in today's world of uncertainty.
Last week I decided to run Karl Scotland's "Ball Flow Game" at Taller Technologies. The aim of the game is to experiment flow, WIP limits and a systemic approach to continuous improvement. This game is a variation of the classic Ball Point Game used to teach Scrum and make the participants feel the inspect and adapt mechanism.
With no iterations, the aim of the game is to pass 20 balls through the whole team in the shortest possible time. It was interesting enough how the "Ball Flow Game" generated a different perspective and team dynamics compared to the "Ball Point Game". Suggestions for improvements were supported by quantitative analysis based upon statistical data collected in a per round basis.
We ran the 5 rounds pretty much following the same original rules, however I decided to make 3 roles explicit: the team, the customer (in charge of feeding balls to an INPUT bin and respecting the capacity agreed by the team) and me as the Coach (in charge of the collection and interpretation of the statistics available in each round), so let's see below what happened since each round was an experiment!
ROUND 1
We let the team self-organize before starting. This round was a bit sloppy since we started to learn how to work as a team, basically the customer filled out the INPUT bin and one team member started to "push" balls into the system as fast as he could. After the second ball we could say that cycle time improved and remain pretty much constant up until losing up a bit of coordination at some stage. Throughput had a maximum of 2 balls per every 10 seconds and if you look at the Cummulative Flow Diagram it was pretty obvious that the system was underutilized with a WIP of 1-2 balls at a time for a 10 people size team. Therefore there was a lot of slack in the system and it was very clear that the person collecting the balls from the INPUT bin and returning them back to the OUPUT bin was the bottleneck. The last ball came out at 2 minutes 23 seconds.
ROUND 2
I again let the team self-organize and decide changing the team member who was the bottleneck. This time the team collaboratively brought the discussion to a whiteboad with the aim of looking at the best system design to reduce the lead time for the 20 balls. Round 2 started a bit chaotic with an increase in cycle time (43 seconds) for the 5th ball followed by an aggressive reduction up until reaching a point of "stabilization" (10th ball onwards) thanks to a better degree of coordination. As a result we had a clear improvement in throughput compared to round 1. Chaos is reflected in the Cumulative Flow Diagram as per the first few balls; however after 60 seconds have elapsed it shows better utilization of people due to removal of the bottleneck and improvement of flow. The replaced team member introduced balls faster, the average WIP increased to almost 4 balls at a time, less slack and a better system design improved the whole. The overall lead time for the 20 balls improved to 1 minute 48 seconds.
ROUND 3 In this round we suggested to put a WIP limit of 5 balls at a time (without batching them). The customer dropped 5 balls to the INPUT bin so a team member could feed the system at the rate of one-in one-out. Despite having an unpredictable process mainly due to a bad system design which hindered coordination and caused a significant amount of "bugs" (balls falling off) limiting the work in progress improved cycle time per ball (with the highest spike at 26 seconds) compared to round 2 (with the highest at 44 seconds). The whole was improved and overall lead time for the 20 balls went down to 1 minute 36 seconds!.
ROUND 4
We reflected upon the previous round work system design and discovered the benefits of experimenting with explicit WIP limits. This time we increased the WIP limit to 6 balls since we believed we still had a bit of slack we could take advantage of. Throughput was high right from an early start and the analysis showed a high level of certainty. The Cumulative Flow Diagram also reflected this predictability and overall we had a reduction in Lead time to 1 minute 5 seconds, much better compared to the previous rounds!
ROUND 5
This round was the best of all, the team self organized and decided to try out again changing the person in charge of the INPUT/OUTPUT bins. We increased the limit to 7 balls to see how far we could stretch out the system. This time we achieved the highest degree of coordination, no bugs (balls falling down), statistics showed minimum fluctuation around the mean, the average lead time was just 8 seconds and the throughput after 20 seconds was kept constant at 4 balls every 10 seconds up until flushing the last 3 balls out from the system. The Cumulative Flow Diagram is steeper compared to the previous round reflecting the fact that now we have a very smooth flow. The process is now highly predictable and completely under control, this is what customers like, right? Imagine the level of trust you would generate if based on facts you tell your customer that every week you are consistently deliverying 4 features at a sustainable pace. Overall time went down to 57 seconds!.
Conclusions
Each round we improved based in a concrete quantitave data analysis, we studied and understand the capability of our system to deliver and we experimented with changes in order to make it more predictable as we progressed. We achieved higher quality and productivity, this is what we aim for when we develop software in today's world of uncertainty don't you agree? ;)
Lean y Kanban aplicado a la gestión de un proyecto caótico (Case Study)Posted in Blog on Febrero 08, 2012 by Manolo Mazan Para beneficio de la comunidad ágil hispano hablante adjunto el paper "RECUPERANDO UN PROYECTO DE DESARROLLO DE SOFTWARE CAÓTICO CON LEAN Y EL MÉTODO KANBAN". Este paper es un caso de estudio sobre la aplicación de Lean y Kanban en un proyecto de desarrollo de software. El caso refleja la manera efectiva como una "fábrica de software" debería operar cuando se trata de trabajo basado en el conocimiento y el respeto profundo hacia los individuos parte del sistema de trabajo . El caso ha sido presentado en la conferencia Lean Kanban Southern Europe Madrid 2012 (http://lkse12.leanssc.org) y Agiles 2012 (http://agiles2012.agiles.org/?lang=en) . También ha sido presentado en portada de la prestigiosa revista Software Gurú en http://hulk.sg.com.mx:8085/downloads/pdfs/SG35-BigData.pdf ...a continuación la tabla de contenidos:
1. Sumario 2. Introducción 3. La Empresa 4. La Situación 5. Por qué Lean y Kanban 6. Empieza identificando los valores de equipo 7. Define la visión del equipo 8. Kaikaku 9. Desperdicio en las conversaciones 10. Desperdicio en la programación 11. Cambio en la cultura 12. Emergencia del pensamiento sistémico 13. Retrospectivas simples 14. Retrospectivas avanzadas 15. Estimar con Kanban en puntos historia es desperdicio 16. Evolución de un tablero simple hacia uno avanzado 17. Técnica de "5 Whys" 18. Kaizen 19. Problemas con Kanban 20. Medición del "Lead Time" y "Cycle Time" 21. CFD (Cumulative Flow Diagram) 22. SPC (Statistical Process Control) 23. Conclusiones 24. Sobre Agiland 25. Sobre el autor 26. Brickell Key Award 27. Referencias
El caso de estudio lo podrán obtener de KanbanCasoEstudioPeru .... los comentarios son bienvenidos. la versión en inglés que recomiendo por ser mas reciente, mas completa y actualizada la puede bajar en el mismo blog Tasks within kanban boardsPosted in Blog on Agosto 16, 2011 by Manolo Mazan
WIP limits, capacity allocation, buffers, classes of service, explicit policies, etc evolves empirically within the Kanban method. As a team´s maturity increases at some stage you might find useful to break down MMF (Minimum Marketable Features) or user stories into tasks within software development projects.
It is not about tracking tasks or report on their progress, it is about getting as much visibility as possible to take self-organization to its maximum level during design and development. Within a software development project with a low-maturity team, design and development might consume most of the cycle time for each user story (it is the case for my project). I can affirm that a Scrum-like board within the main kanban board or what some members of the Agile community call "an advanced kanban board" to accommodate the tasks of the design and development phase is very useful.
|
15/03/2012 - Agiland presente en la conferencia Lean & Kanban Southern Europe 2012
04/08/2011 - Agiland becomes member of the Peruvian-Irish Chamber of Commerce
29/06/2011 - 2do Agile Open Lima 2011
25/11/2010 - Curso Desarrollo de Software Lean-Agile del 6 al 13 de Diciembre del 2010
08/09/2010 - Conferencia sobre metodologías ágiles en Lima: del 4 al 7 de Octubre del 2010
14/05/2010 - Agiland organiza curso abierto de especialización en metodologías ágiles
15/04/2010 - Agiland auspicia el Lima Agile Day 2010
07/04/2010 - Yell (Páginas Amarillas) apuesta por las metodologías ágiles (noticia completa)
