It is not uncommon to hear people say that software development is non-repetitive work where the work always unique and rarely repeat. It is not uncommon to hear people say that software development is a craft, an act of design and even divine inspiration and that we therefore can learn from other industries that is described as repetitive.
I think this is a fallacy, a fallacy I call the Non-Repetitive Work Fallacy.
The second KataCon will soon take place in Hollywood, Florida. And for the second time
Gary Perkerwicz and I have the honor to host the Kata in Software Development panel. Just like last year we have a great lineup of panelists
Thank you all of you who attended my #Agile2014 session: How to improve Flow Efficiency, Remove the Red bricks! In this, and upcoming posts (part 2) I will answer some of the questions I have received after the session.
Q1: I was hoping to better understand how to improve flow efficiency when the number of resources varies on our scrum process. For example, we have more developers than testers. We typically have a bottleneck in the test step. Not sure I got my answer.
This question is not necessarily a flow efficiency question. It may be more of a balance demand to capacity question. Nevertheless, let us explore the flow efficiency side first, as this was the main focus of the session. First, a short description of flow efficiency.
Hakan Forss's Blog 