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.
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.
The Leader’s Guide to Radical Management by Steve Denning is an interesting read about agile described in a more business oriented languish.