Comments on: Time-boxed iteration: an idea whose time has come and gone http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/ Essays on the Continuous Delivery of High Quality Information Systems Wed, 01 Feb 2012 18:32:04 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Iteration should not be reduced to Scrum time-boxed cycle | Agile or Waterfall http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-26051 Iteration should not be reduced to Scrum time-boxed cycle | Agile or Waterfall Wed, 13 Jul 2011 05:45:35 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-26051 [...] seems to be some rebellions against scrum time-boxed iterations like on leansoftwareengineering. Some have been willing to announce her death sentence. This latter title was clearly meant to be [...] [...] seems to be some rebellions against scrum time-boxed iterations like on leansoftwareengineering. Some have been willing to announce her death sentence. This latter title was clearly meant to be [...]

]]> By: Agile or Waterfall http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-25892 Agile or Waterfall Mon, 11 Jul 2011 21:32:40 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-25892 I think it's a semantic game: if you go back to the origin of Agile as I wrote here http://lepinekong.com/the-hidden-origin-of-agile/ it comes from Lean which comes from Deming who is the father of Continuous Improvment. And Iteration in his spirit is less about Time Cycle as Scrum methodology tends to make believe, than INDUCTION/DEDUCTION phases which was a scientific concept too difficult to grasp for the masses that's why the concept of Iteration through the Deming PDCA cycle (Plan Do Check Action) was created. I think it’s a semantic game: if you go back to the origin of Agile as I wrote here http://lepinekong.com/the-hidden-origin-of-agile/ it comes from Lean which comes from Deming who is the father of Continuous Improvment. And Iteration in his spirit is less about Time Cycle as Scrum methodology tends to make believe, than INDUCTION/DEDUCTION phases which was a scientific concept too difficult to grasp for the masses that’s why the concept of Iteration through the Deming PDCA cycle (Plan Do Check Action) was created.

]]> By: Fourth Medium Consulting Inc. http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-6072 Fourth Medium Consulting Inc. Mon, 14 Sep 2009 15:34:14 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-6072 [...] blogs related to software engineering methodology, I ran across a great post from Corey Ladas – “Time-boxed-Iteration: an idea whose time has come and gone”.  It represents a very pragmatic reflection on how the evolution of modern software engineering [...] [...] blogs related to software engineering methodology, I ran across a great post from Corey Ladas – “Time-boxed-Iteration: an idea whose time has come and gone”.  It represents a very pragmatic reflection on how the evolution of modern software engineering [...]

]]> By: Iterações pra que te quero! at Mergulhando no Caos http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-3574 Iterações pra que te quero! at Mergulhando no Caos Fri, 03 Oct 2008 00:47:12 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-3574 [...] há quem fale sobre a obsolescência das iterações como as conhecemos. Um dos maiores “culpados” por esse novo movimento [...] [...] há quem fale sobre a obsolescência das iterações como as conhecemos. Um dos maiores “culpados” por esse novo movimento [...]

]]> By: NO OPeration: Complexity of Software Projects http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-1992 NO OPeration: Complexity of Software Projects Mon, 25 Feb 2008 22:02:58 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-1992 <strong>To Iterate or Not to Iterate...</strong> I love it when the experts don't agree. It makes me feel smarter. Because, by not agreeing with any of the experts, I actually feel like I am one of them. This is the notion I got today when starting... To Iterate or Not to Iterate…

I love it when the experts don’t agree. It makes me feel smarter. Because, by not agreeing with any of the experts, I actually feel like I am one of them. This is the notion I got today when starting…

]]> By: Corey Ladas http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-370 Corey Ladas Wed, 31 Oct 2007 21:32:42 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-370 Yes, in one way pull scheduling is a return to scope-driven iteration, but the scope is always one work item. Good planning discipline means setting an upper limit on size and rejecting work requests that exceed the limit. We have one project where incoming requirements are broken up into component "features" which are also tracked on the board. We have another project where the incoming work requests are not broken up. I think how you scope work items depends on the situation. What matters is that they are of a similar size, and have clear criteria for completion. The time-in-process of any work item will vary, but there are always multiple work items in process, in parallel. Throughput is the rate of completion of work items, and the system is tuned for the average sized work item. WIP limits and buffers can be set to accomodate any reasonable variation in size. Unreasonable variation would be handled by a change in the analysis and planning process. In a time-boxed iteration, the work spends a lot of time sitting around in a backlog, waiting. Yes, in one way pull scheduling is a return to scope-driven iteration, but the scope is always one work item. Good planning discipline means setting an upper limit on size and rejecting work requests that exceed the limit.

We have one project where incoming requirements are broken up into component “features” which are also tracked on the board. We have another project where the incoming work requests are not broken up. I think how you scope work items depends on the situation. What matters is that they are of a similar size, and have clear criteria for completion.

The time-in-process of any work item will vary, but there are always multiple work items in process, in parallel. Throughput is the rate of completion of work items, and the system is tuned for the average sized work item. WIP limits and buffers can be set to accomodate any reasonable variation in size. Unreasonable variation would be handled by a change in the analysis and planning process.

In a time-boxed iteration, the work spends a lot of time sitting around in a backlog, waiting.

]]> By: andreister http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-368 andreister Wed, 31 Oct 2007 17:46:27 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-368 Yes, exactly, each requirement is an iteration. It is what I meant. So, this brings up a question. Imagine, you get a requirement, split it up to small tasks for every developer and kick off the "pull" step. Requirements would vary, and either would subtasks, so you end up having a set of manifold work items to be implemented within the current "pull" step. To me, it makes only one difference to usual "iterative" approach: in your case, pull steps WILL be various in terms of time, while in the other case workload is restricted by the predefined length of the iteration. Is this true, do I get the point? Any other things to mention? Yes, exactly, each requirement is an iteration. It is what I meant.

So, this brings up a question. Imagine, you get a requirement, split it up to small tasks for every developer and kick off the “pull” step. Requirements would vary, and either would subtasks, so you end up having a set of manifold work items to be implemented within the current “pull” step.

To me, it makes only one difference to usual “iterative” approach: in your case, pull steps WILL be various in terms of time, while in the other case workload is restricted by the predefined length of the iteration.

Is this true, do I get the point? Any other things to mention?

]]> By: Corey Ladas http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-365 Corey Ladas Wed, 31 Oct 2007 15:52:27 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-365 There are a couple of approaches to refactoring. One would be reserved capacity, that you have an ongoing effort to optimize the system, with a fixed or maximum resource allocation. So, if you have 10 developers, then perhaps one or two of them are always working on design optimization. Another approach is as you suggest, to create refactoring requirements. How long it takes to implement a requirement depends on how big it is. One of our projects currently has a ~20 day cycle time. Another is a little larger. Work items are sized differently between those projects, so they're not comparable. The goal with this kind of system is to make each requirement an "iteration." Where else do you see one? There are a couple of approaches to refactoring. One would be reserved capacity, that you have an ongoing effort to optimize the system, with a fixed or maximum resource allocation. So, if you have 10 developers, then perhaps one or two of them are always working on design optimization. Another approach is as you suggest, to create refactoring requirements.

How long it takes to implement a requirement depends on how big it is. One of our projects currently has a ~20 day cycle time. Another is a little larger. Work items are sized differently between those projects, so they’re not comparable.

The goal with this kind of system is to make each requirement an “iteration.” Where else do you see one?

]]> By: andreister http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-364 andreister Wed, 31 Oct 2007 15:27:13 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-364 Corey, so do you "enqueue" refactoring/redesigning/etc as general requirements? How long do you usually implement a single requirement? And, finally: do you REALLY think you don't use iterations at all? To me, it looks like you still use them but just don't call them iterations :) Corey, so do you “enqueue” refactoring/redesigning/etc as general requirements?

How long do you usually implement a single requirement?

And, finally: do you REALLY think you don’t use iterations at all? To me, it looks like you still use them but just don’t call them iterations :)

]]> By: Corey http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/comment-page-1/#comment-307 Corey Thu, 25 Oct 2007 00:50:00 +0000 http://leansoftwareengineering.com/2007/10/05/time-boxed-iteration-an-idea-whose-time-has-come-and-gone/#comment-307 We are absolutely using it. Kanban/Andon boards have sprouted all over the building like weeds. Everything from individuals, to small teams, to major projects with 50+ people. The real <em>technical</em> challenge is in correctly sizing and specifying incoming requirements. But all Agile methods suffer from that challenge. Another technical challenge, again common to all agile methods, is preserving design integrity across successive increments. Some kind of ongoing, systematic refactoring is still the primary strategy. The greater challenges come from effective leadership and management, and most of all, overcoming old habits. Most people have been trained to push, so they have to be retrained to pull. That's hard for some people to grok. I think that Lean development (proper) requires greater management skill than Scrum or the like. I don't see that as a bad thing, however. We are absolutely using it. Kanban/Andon boards have sprouted all over the building like weeds. Everything from individuals, to small teams, to major projects with 50+ people.

The real technical challenge is in correctly sizing and specifying incoming requirements. But all Agile methods suffer from that challenge. Another technical challenge, again common to all agile methods, is preserving design integrity across successive increments. Some kind of ongoing, systematic refactoring is still the primary strategy.

The greater challenges come from effective leadership and management, and most of all, overcoming old habits. Most people have been trained to push, so they have to be retrained to pull. That’s hard for some people to grok. I think that Lean development (proper) requires greater management skill than Scrum or the like. I don’t see that as a bad thing, however.

]]>