- Hi Alan and all, I have been so busy coaching Agile/Lean teams in the trenches to add my contribution until now but now that the weekend has arrived, pleaseMessage 1 of 1 , Dec 3, 2011View SourceHi Alan and all,
I have been so busy coaching Agile/Lean teams in the trenches to add my contribution until now but now that the weekend has arrived, please let me just say, in agreement with Don and Alan, that the one piece flow is only a theoretical construct with no practical application in serious corporate software environments.
For having been a director of project management, technical IT director, chief architect and VP over software development in a variety of corporations of different sizes, I have not seen it applied anywhere, even in the best shops. (Eventually, we could use it in a one or two member web start-ups, like the one someone I know has created recently with his friend, but that will be it.)
Even though I am an admirer of Agile and Scrum, which I coach teams to use regularly in the trenches (while modifying it to get it to work depending on the contexts and projects), I am not impressed by this new Agile one-piece flow approach. This is not a serious nor practical discussion worth of our corporate practitioners' time.
Author of Scrum in Action, Agile Project Management and Development in the Real-World
and of "Business-Driven IT-Wide Agile (Scrum) and/or Kanban (Lean) Implementation" (reviewed and upcoming)On Fri, Nov 25, 2011 at 2:46 AM, alshalloway <alshall@...> wrote:
I have heard one-piece flow mentioned several times in the agile community. I have also heard Don Reinertsen say one-piece flow is something that often does not make any sense. The reality is you want to maximize flow. One-piece flow can often be difficult to do for a variety of reasons in the software arena. The two main reasons for this are:
1) work varies (in size and who needs to work on it)
2) the skill sets and backgrounds necessary to do the work rarely exactly match the work coming in.
In manufacturing, you can achieve one-piece flow because the work is reasonable stable (even when they interchange cars) and because you can reasonably inexpensively cross-train folks as necessary. In software development, these situations are often not true. In software there are also certain advantages to batching in many different situations relating to test, release and consumption (and these are often not development related but business related issues).
I suspect it is not a coincidence that these two assumptions also underlie methods that insist on having cross-functional teams.
There is no doubt in my mind that the ideal case is having cross-functional teams and steady size of work and being in a market where continual delivery is possible. When these are available, knowing Lean-Flow is still valuable. When not, then Kanban as a transition method is especially valuable.
There is a huge difference between a single team development project that is focused on discovering what to build for a new product than what is typically found in software development.
I think the power of Kanban is that it can be used in more than the simplest development case I know where one-piece flow is readily achievable.
CEO, Net Objectives