And I can't agree with you, David. The main purpose of the sprint is
define a feedback loop. Actually, two feedback loops, the Product review
and the Process review. Everything in scrum is about providing feedback
loops (well, almost). The natural cadence of feedback loops with
external stakeholders is of the main drivers for determining the length
of the sprint.

I agree that there are many different cyclic concepts here that scrum
artificially sets to be the same. The primary ones are: feedback cycle
with stakeholders, planning cycle, and time it takes to do work (work
cycle). In my view of scrum - the one I teach - the primary one is the
feedback loop. By changing the planning cycle to be managed by a WIP
board - no big deal. To make stories short so that we can review them
within a sprint of starting them - a big deal. So, adding WIP to scrum
provides a force to make the stories short enough so that they can be
reviewed within a sprint or two (this is a good thing), and has little
or no impact on our external stakeholders (also a good thing). And, it
is more lean, which is a good thing.

All good. All scrum. All the time ;)

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628



David J Anderson wrote:
>
>
> I'm sorry, Dan, but I can't agree with this...
>
> --- In kanbandev@yahoogroups.com <mailto:kanbandev%40yahoogroups.com>,
> Dan Rawsthorne <dan.rawsthorne@...> wrote:
> >
> > I see it as a very small change from scrum. There's no reason for
> > sprints to go away, as their main purpose is to provide a feedback loop
> > for both product and process inspect and adapt. This shouldn't change.
>
> Sprints/Iterations are batches of work. There main purpose is to be a
> batch. Batches can be efficient from a transaction and coordination
> cost perspective. The main purpose of Sprints is not to provide
> inspect and adapt. Smaller batches may provide opportunities to manage
> risk. Smaller batches provide convenient opportunities for inspect and
> adapt. Without small batches special consideration would need to be
> given for inspect and adapt.
>
> Time-boxed sprints are unnatural in most circumstances/domains/contexts.
>
> Why would it be that the natural cadence for coordination with the
> upstream function to prioritize and understand new work, would also be
> the same as the natural cadence for deployment/delivery downstream(/to
> the market)?
>
> Why would it be that natural size for a piece of work or set of work
> that represents an economic deliverable (the MMF - though I hate this
> term) would equally be the same as the cadence for the upstream and
> downstream coordination?
>
> This is ridiculous! It is forced and unnatural!
>
> As I said in my key note at Lean & Kanban 2009, I truly believe that
> in 5 years, the concept of a time-boxed iteration where the cadence of
> upstream coordination, downstream coordination and cycle time for
> economically deliverable batches are thought of similar, will be
> considered coincidental and only for niche applications.
>
> Freed from the constraint of a time-box, the natural cadences for
> different domains and contexts will emerge. We've given people
> permission to think and act differently and they are starting to do
> so. Time-boxes will eventually be squeezed out to the margins of our
> software engineering activities.
>
> Without time-boxes we still have plenty of opportunities for inspect
> and adapt. There is the upstream coordination meeting (typically
> happening at a regular cadence), the downstream coordination meetings
> (for release planning) and the actual release (ideal for a
> retrospective), the daily standup (another coordination meeting) and
> the regularly scheduled organization operations review. You don't need
> time-boxed Sprints to do inspect and adapt!
>
> David
> http://www.channelkanban.com/ <http://www.channelkanban.com/>
>
>