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.
Scrum and the Kanban method use different forces to achieve this same goal of creating the most possible value over time for the organization by continuously inspecting and adapting the processes and tools.
In Scrum the main forces are the time boxed Sprints and the cross-functional team. In the Kanban method the main forces are visualizing work and limit the work-in-process (WIP).
In Scrum the main forces for improvements are achieved by the time boxed Sprints and the cross-functional team.
It is in the time boxed Sprint the team are supposed to build a potential releasable increment of your product. By setting a fixed time box in which a product increment shall completed including all steps like analysis, design, development and testing will force the increments to be small enough to fit the time box. This will most often reduce risk by the smaller steps with validation of the increment at the end of the time box in the Sprint Review.
The members of the cross-functional Scrum team are the only ones that should work on the product increment. This will force the organization to have all the necessary competence in the team so it can deliver the intended product increment.
In the Kanban method the main forces for improvements are achieved by visualizing work and limit the work-in-process.
Visualizing and making the work visible is used to make people in the process aware of how work is done and the amount of work that is in the process. Humans are very good at processing visual information and making meaning of it as a very large part of the human brain is dedicated to it. The saying that a picture says more than thousand words is a very good description how the brain works. By visualizing and making the work visible the Kanban method the created understanding and understanding can force the organization to make improvements of how work is done.
The goal of limiting work-in-process is to create an even and continuous flow of work. This is done by reducing the work-in-process in small steps over time. This will force process problems to the surface and together with the visualization it will be visible. Limiting the amount of work in the process will often reduce risk as less work is done in parallel and the focus on getting work done before new work is started.
Scrum and the Kanban method use different forces to achieve this same goal. Depending on the context the forces will have different catalytic effects on your organization. Based on your current context choose one or the other or combine them to achieve the goal of your organization.
Hakan Forss's Blog 