Loading ...
Sorry, an error occurred while loading the content.

Kanban vs Scrum

Expand Messages
  • Gustavo Cebrian Garcia
    Hello, I am a little bit confused with Kanban. I do Scrum, I practice Kanban principles ( on progress, etc ) When people say that they are doing just kanban
    Message 1 of 23 , Jun 24, 2011
    • 0 Attachment
      Hello,

      I am a little bit confused with Kanban. I do Scrum, I practice Kanban
      principles ( on progress, etc )

      When people say that they are doing just kanban and not Scrum, how do they
      estimate,

      Is there some kind of time-boxing with Kanban? There is no kind of planning?

      Thanks.

      Gustavo.


      [Non-text portions of this message have been removed]
    • Torbjörn Gyllebring
      Hi Gustavo, the key point to remember is that Kanban isn t a process. You apply Kanban to something, sometimes that something is Scrum. My understanding is
      Message 2 of 23 , Jun 24, 2011
      • 0 Attachment
        Hi Gustavo,

        the key point to remember is that "Kanban" isn't a process.
        You apply Kanban to something, sometimes that something is Scrum.
        My understanding is that most people that claim "we do Kanban instead of
        Scrum/XP/..." they really mean
        "we have a unnamed process, to improve and explain parts of it we use the
        Kanban label".

        Kanban tells you to start with what you have, visualize the workflow, limit
        work in progress, manage flow and continuously improve.
        You can't start with Kanban, equally little is guidance on when/if/how to do
        estimation.
        That said, many teams that apply Kanban to their process find that the need
        for estimation vanish because of the data and feedback provided by the
        visualization and reduced variation.

        Did that help?

        //tobbe

        On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
        g.cebrian.garcia@...> wrote:

        >
        >
        > Hello,
        >
        > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
        > principles ( on progress, etc )
        >
        > When people say that they are doing just kanban and not Scrum, how do they
        > estimate,
        >
        > Is there some kind of time-boxing with Kanban? There is no kind of
        > planning?
        >
        > Thanks.
        >
        > Gustavo.
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Gustavo Cebrian Garcia
        OK, that is what I understood. What I get is that kanban is a visual process everyone can see the flow and applies the concepts you just said. I think, when
        Message 3 of 23 , Jun 24, 2011
        • 0 Attachment
          OK, that is what I understood.

          What I get is that kanban is a visual process everyone can see the flow and
          applies the concepts you just said. I think, when people say Kanban vs
          Scrum,

          they mean whether they want to do timeboxing or not...

          Yes, it helped a lot, thanks.

          ( I got confused becasue I heard from some people they estimate even when
          they do kanban )

          On 24 June 2011 12:25, Torbjörn Gyllebring <torbjorn.gyllebring@...>wrote:

          > Hi Gustavo,
          >
          > the key point to remember is that "Kanban" isn't a process.
          > You apply Kanban to something, sometimes that something is Scrum.
          > My understanding is that most people that claim "we do Kanban instead of
          > Scrum/XP/..." they really mean
          > "we have a unnamed process, to improve and explain parts of it we use the
          > Kanban label".
          >
          > Kanban tells you to start with what you have, visualize the workflow, limit
          > work in progress, manage flow and continuously improve.
          > You can't start with Kanban, equally little is guidance on when/if/how to
          > do
          > estimation.
          > That said, many teams that apply Kanban to their process find that the need
          > for estimation vanish because of the data and feedback provided by the
          > visualization and reduced variation.
          >
          > Did that help?
          >
          > //tobbe
          >
          > On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
          > g.cebrian.garcia@...> wrote:
          >
          > >
          > >
          > > Hello,
          > >
          > > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
          > > principles ( on progress, etc )
          > >
          > > When people say that they are doing just kanban and not Scrum, how do
          > they
          > > estimate,
          > >
          > > Is there some kind of time-boxing with Kanban? There is no kind of
          > > planning?
          > >
          > > Thanks.
          > >
          > > Gustavo.
          > >
          > > [Non-text portions of this message have been removed]
          > >
          > >
          > >
          >
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >
          > ------------------------------------
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.comYahoo! Groups Links
          >
          >
          >
          >


          [Non-text portions of this message have been removed]
        • George Dinwiddie
          Hi, Gustavo, ... As with many of the terms in our industry, I find that different people mean different things by the same term. When people say they are
          Message 4 of 23 , Jun 24, 2011
          • 0 Attachment
            Hi, Gustavo,

            On 6/24/11 4:58 AM, Gustavo Cebrian Garcia wrote:
            > Hello,
            >
            > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
            > principles ( on progress, etc )
            >
            > When people say that they are doing just kanban and not Scrum, how do they
            > estimate,
            >
            > Is there some kind of time-boxing with Kanban? There is no kind of planning?

            As with many of the terms in our industry, I find that different people
            mean different things by the same term. When people say they are doing
            just kanban, you might ask them what /they/ mean by that term.

            Arlo Belshee's 'Naked Planning' described the minimal planning that he
            and his team did. They let the marketing department fill the input
            queue (to capacity of 7) with the highest priority MMFs (Minimally
            Marketable Features). Using past cycle times as a guide, they labeled
            the end of the input queue with an estimated wait time from that point.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Ron Jeffries
            Hello, Gustavo. On Friday, June 24, 2011, at 4:58:41 AM, you ... Possibly you d like to address this question also to Kanban and Scrum groups. We do have
            Message 5 of 23 , Jun 24, 2011
            • 0 Attachment
              Hello, Gustavo. On Friday, June 24, 2011, at 4:58:41 AM, you
              wrote:

              > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
              > principles ( on progress, etc )

              Possibly you'd like to address this question also to Kanban and
              Scrum groups. We do have opinions, hwoever ...

              > When people say that they are doing just kanban and not Scrum, how do they
              > estimate,

              Kanban is used to describe the actual process one has: it does not
              dictate a process. Therefore people estimate however they have
              always done it, if they do it at all.

              > Is there some kind of time-boxing with Kanban? There is no kind of
              > planning?

              Again, kanban just models what teams do. They would do planning as
              they do it, and model it with kanban. It seems likely to me that
              time boxing might generate conflict with kanban's work in process
              limits but perhaps not.

              Ron Jeffries
              www.XProgramming.com
              Example isn't another way to teach, it is the only way to teach.
              --Albert Einstein
            • JeffGrigg
              ... What I ve seen from observing Kanban projects and talking with Kanban coaches makes me think that Kanban metrics are based on and designed to support an
              Message 6 of 23 , Jun 24, 2011
              • 0 Attachment
                > --- Gustavo wrote:
                >> Is there some kind of time-boxing with Kanban? There is no kind
                >> of planning?

                --- Ron Jeffries <ronjeffries@...> wrote:
                > Again, kanban just models what teams do. They would do planning as
                > they do it, and model it with kanban. It seems likely to me that
                > time boxing might generate conflict with kanban's work in process
                > limits but perhaps not.

                What I've seen from observing Kanban projects and talking with Kanban coaches makes me think that Kanban metrics are based on and designed to support an assumption of continuous flow. I find this incompatible with the assumptions of timeboxing. I've seen the two used together, but they don't seem to complement each other.

                I generally recommend one or the other: Kanban for flow-like work, such as for teams that primarily respond to ad-hoc requests. Timeboxing for knowledge work that can be planned in advance (like a week or two in advance) and which can be worked to completion (generally; in most cases) without getting pulled off to work on other priorities in the middle. As I see it, you can't timebox if the work and priorities aren't held constant from the start to end of the "time box."
              • Gustavo Cebrian Garcia
                To be honest, I think they are compatible... You can have Scrum, two weeks sprints, and try and maximize the flow. A lot of people do it already... ...
                Message 7 of 23 , Jun 24, 2011
                • 0 Attachment
                  To be honest, I think they are compatible...

                  You can have Scrum, two weeks sprints, and try and maximize the flow.

                  A lot of people do it already...

                  On 24 June 2011 19:10, JeffGrigg <jeffreytoddgrigg@...> wrote:

                  > **
                  >
                  >
                  > > --- Gustavo wrote:
                  > >> Is there some kind of time-boxing with Kanban? There is no kind
                  > >> of planning?
                  >
                  > --- Ron Jeffries <ronjeffries@...> wrote:
                  > > Again, kanban just models what teams do. They would do planning as
                  > > they do it, and model it with kanban. It seems likely to me that
                  > > time boxing might generate conflict with kanban's work in process
                  > > limits but perhaps not.
                  >
                  > What I've seen from observing Kanban projects and talking with Kanban
                  > coaches makes me think that Kanban metrics are based on and designed to
                  > support an assumption of continuous flow. I find this incompatible with the
                  > assumptions of timeboxing. I've seen the two used together, but they don't
                  > seem to complement each other.
                  >
                  > I generally recommend one or the other: Kanban for flow-like work, such as
                  > for teams that primarily respond to ad-hoc requests. Timeboxing for
                  > knowledge work that can be planned in advance (like a week or two in
                  > advance) and which can be worked to completion (generally; in most cases)
                  > without getting pulled off to work on other priorities in the middle. As I
                  > see it, you can't timebox if the work and priorities aren't held constant
                  > from the start to end of the "time box."
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Steven Gordon
                  ... And yet we know we should periodically during the iteration take the customer through what we have developed and respond to any feedback they have. And we
                  Message 8 of 23 , Jun 24, 2011
                  • 0 Attachment
                    On Fri, Jun 24, 2011 at 10:10 AM, JeffGrigg <jeffreytoddgrigg@...>wrote:

                    > **
                    >
                    >
                    > > --- Gustavo wrote:
                    > >> Is there some kind of time-boxing with Kanban? There is no kind
                    > >> of planning?
                    >
                    > --- Ron Jeffries <ronjeffries@...> wrote:
                    > > Again, kanban just models what teams do. They would do planning as
                    > > they do it, and model it with kanban. It seems likely to me that
                    > > time boxing might generate conflict with kanban's work in process
                    > > limits but perhaps not.
                    >
                    > What I've seen from observing Kanban projects and talking with Kanban
                    > coaches makes me think that Kanban metrics are based on and designed to
                    > support an assumption of continuous flow. I find this incompatible with the
                    > assumptions of timeboxing. I've seen the two used together, but they don't
                    > seem to complement each other.
                    >
                    > I generally recommend one or the other: Kanban for flow-like work, such as
                    > for teams that primarily respond to ad-hoc requests. Timeboxing for
                    > knowledge work that can be planned in advance (like a week or two in
                    > advance) and which can be worked to completion (generally; in most cases)
                    > without getting pulled off to work on other priorities in the middle. As I
                    > see it, you can't timebox if the work and priorities aren't held constant
                    > from the start to end of the "time box."
                    >
                    >
                    And yet we know we should periodically during the iteration take the
                    customer through what we have developed and respond to any feedback they
                    have. And we also should have no problem trading off a story we have not
                    started yet for one which is suddenly hot. And we also know we should not
                    have all the stories scheduled for an iteration all in progress as the same
                    time.

                    It seems to me dropping iterations for Kanban-style scheduling is a
                    reasonable next step for an XP team whose progress has plateaued. I just do
                    not see how a team could first get good enough at XP without the scaffolding
                    of iterations.

                    SteveG


                    [Non-text portions of this message have been removed]
                  • Adam Sroka
                    The most functional definition of Kanban is the one David Anderson gives in his training. It is a five step process: 1) visualize flow 2) limit work in process
                    Message 9 of 23 , Jun 24, 2011
                    • 0 Attachment
                      The most functional definition of Kanban is the one David Anderson gives in
                      his training. It is a five step process:

                      1) visualize flow
                      2) limit work in process (WIP)
                      3) manage flow
                      4) make process policies explicit
                      5) improve scientifically

                      The first and last steps are the most interesting to me. It is important to
                      note that we visualize the system as it currently is and then improve it. We
                      don't visualize what we want the system to be. This seems to be the most
                      common mistake.

                      Also, David makes a point that we use metrics and deduction to find areas to
                      improve. He dislikes the Agile notion of "what worked, what didn't, etc." He
                      says, "improve scientifically, not emotionally."

                      Outside of David's sphere of influence Kanban is often simply used to
                      describe the mere lack of timeboxed iterations. This is similar to overly
                      simplistic definitions of other things (like XP or Scrum.) Because of that,
                      I tend to agree with George that you need to ask what the individual speaker
                      means when they use the word.

                      ...

                      Also, there is added confusion because the word "kanban" is a Japanese word
                      that has a specific meaning, and it is manufacturing jargon that is used in
                      a few different ways. David distinguishes these other uses as little-K
                      kanban whereas his approach is big-K Kanban.
                      On Jun 24, 2011 6:22 AM, "Gustavo Cebrian Garcia" <
                      g.cebrian.garcia@...> wrote:


                      [Non-text portions of this message have been removed]
                    • JeffGrigg
                      ... The definition I seem to get most often from Certified Scrum Master full time coaches, and most others with a casual interest is... 1. Impose Work In
                      Message 10 of 23 , Jun 24, 2011
                      • 0 Attachment
                        --- Adam Sroka <adam.sroka@...> wrote:
                        > The most functional definition of Kanban is the one David
                        > Anderson gives in his training. ...

                        The definition I seem to get most often from Certified Scrum Master full time coaches, and most others with a casual interest is...

                        1. Impose Work In Process (WIP) limits on Queues.

                        IE: "You can't have more than 'N' items in this queue."

                        That's it.

                        I wouldn't have much of a problem with that (and even less with David Anderson's definition), but...

                        XP, done well, approaches one-piece flow, from what I've seen. IE: Little work is done on a story until it's nearly ready to go into an iteration. When selected for work, it's worked end-to-end without stop until it is ready for deployment. It's deployed to production as soon as practical. So I'd think that Anderson's Kanban analysis, done well, should say "Well done!" and maybe highlight a few minor rough edges that the team might have already been thinking about addressing anyway.

                        But what often seems to happen is that Certified Scrum Master coaches and team members insist that "Kanban is WIP Limits" -- so they insist on ***ADDING*** work queues to the process, so that they'll have something to "Manage with Kanban." Adding queues to a process that doesn't need them introduces waste. It's a bad thing. When team members are generalists, you don't need to put work into a queue. You just do the next step of the work.
                      • Charlie Poole
                        That s a good observation. Now that you mention it, I ve seen the same thing. Charlie ... [Non-text portions of this message have been removed]
                        Message 11 of 23 , Jun 24, 2011
                        • 0 Attachment
                          That's a good observation. Now that you mention it, I've seen the same
                          thing.

                          Charlie

                          On Fri, Jun 24, 2011 at 3:29 PM, JeffGrigg <jeffreytoddgrigg@...>wrote:

                          > **
                          >
                          >
                          > --- Adam Sroka <adam.sroka@...> wrote:
                          > > The most functional definition of Kanban is the one David
                          > > Anderson gives in his training. ...
                          >
                          > The definition I seem to get most often from Certified Scrum Master full
                          > time coaches, and most others with a casual interest is...
                          >
                          > 1. Impose Work In Process (WIP) limits on Queues.
                          >
                          > IE: "You can't have more than 'N' items in this queue."
                          >
                          > That's it.
                          >
                          > I wouldn't have much of a problem with that (and even less with David
                          > Anderson's definition), but...
                          >
                          > XP, done well, approaches one-piece flow, from what I've seen. IE: Little
                          > work is done on a story until it's nearly ready to go into an iteration.
                          > When selected for work, it's worked end-to-end without stop until it is
                          > ready for deployment. It's deployed to production as soon as practical. So
                          > I'd think that Anderson's Kanban analysis, done well, should say "Well
                          > done!" and maybe highlight a few minor rough edges that the team might have
                          > already been thinking about addressing anyway.
                          >
                          > But what often seems to happen is that Certified Scrum Master coaches and
                          > team members insist that "Kanban is WIP Limits" -- so they insist on
                          > ***ADDING*** work queues to the process, so that they'll have something to
                          > "Manage with Kanban." Adding queues to a process that doesn't need them
                          > introduces waste. It's a bad thing. When team members are generalists, you
                          > don't need to put work into a queue. You just do the next step of the work.
                          >
                          >
                          >


                          [Non-text portions of this message have been removed]
                        • Adam Sroka
                          That is one variation of what I meant by making the visualization conform to what you want the system to be (which is explicitly incorrect in big-K Kanban.) I
                          Message 12 of 23 , Jun 24, 2011
                          • 0 Attachment
                            That is one variation of what I meant by making the visualization conform to
                            what you want the system to be (which is explicitly incorrect in big-K
                            Kanban.)

                            I have a bit more to say but my plane is about to take off. I will write a
                            more detailed response (to Jeff) after I get back to LA.
                            On Jun 24, 2011 6:27 PM, "Charlie Poole" <charliepoole@...> wrote:
                            > That's a good observation. Now that you mention it, I've seen the same
                            > thing.
                            >
                            > Charlie
                            >
                            > On Fri, Jun 24, 2011 at 3:29 PM, JeffGrigg <jeffreytoddgrigg@...
                            >wrote:
                            >
                            >> **
                            >>
                            >>
                            >> --- Adam Sroka <adam.sroka@...> wrote:
                            >> > The most functional definition of Kanban is the one David
                            >> > Anderson gives in his training. ...
                            >>
                            >> The definition I seem to get most often from Certified Scrum Master full
                            >> time coaches, and most others with a casual interest is...
                            >>
                            >> 1. Impose Work In Process (WIP) limits on Queues.
                            >>
                            >> IE: "You can't have more than 'N' items in this queue."
                            >>
                            >> That's it.
                            >>
                            >> I wouldn't have much of a problem with that (and even less with David
                            >> Anderson's definition), but...
                            >>
                            >> XP, done well, approaches one-piece flow, from what I've seen. IE: Little
                            >> work is done on a story until it's nearly ready to go into an iteration.
                            >> When selected for work, it's worked end-to-end without stop until it is
                            >> ready for deployment. It's deployed to production as soon as practical.
                            So
                            >> I'd think that Anderson's Kanban analysis, done well, should say "Well
                            >> done!" and maybe highlight a few minor rough edges that the team might
                            have
                            >> already been thinking about addressing anyway.
                            >>
                            >> But what often seems to happen is that Certified Scrum Master coaches and
                            >> team members insist that "Kanban is WIP Limits" -- so they insist on
                            >> ***ADDING*** work queues to the process, so that they'll have something
                            to
                            >> "Manage with Kanban." Adding queues to a process that doesn't need them
                            >> introduces waste. It's a bad thing. When team members are generalists,
                            you
                            >> don't need to put work into a queue. You just do the next step of the
                            work.
                            >>
                            >>
                            >>
                            >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                            >
                            >
                            > ------------------------------------
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to:
                            extremeprogramming-unsubscribe@...
                            >
                            > ad-free courtesy of objectmentor.comYahoo! Groups Links
                            >
                            >
                            >


                            [Non-text portions of this message have been removed]
                          • JeffGrigg
                            ... Interesting. Considering the last few XP projects I ve worked on or with... ... Yep: Pretty much always pinned stories for an iteration in one place,
                            Message 13 of 23 , Jun 25, 2011
                            • 0 Attachment
                              --- Adam Sroka <adam.sroka@...> wrote:
                              > The most functional definition of Kanban is the one David
                              > Anderson gives in his training. It is a five step process:
                              >
                              > 1) visualize flow
                              > 2) limit work in process (WIP)
                              > 3) manage flow
                              > 4) make process policies explicit
                              > 5) improve scientifically
                              >
                              > The first and last steps are the most interesting to me. ...

                              Interesting. Considering the last few XP projects I've worked on or with...

                              > 1) visualize flow

                              Yep: Pretty much always pinned stories for an iteration in one place, moved them to another when working on them, and another when finished. Standups center around this story board.

                              I've also used Big Visible Charts for everything that seemed to be relevant. Burn-Up charts always. Big Visible Attendance chart when lateness to standups was a problem.

                              > 2) limit work in process (WIP)

                              I favor leaving stories unassigned until work starts on them: When a pair finishes their current work, they grab another story.

                              I've been doing "least competent developer" pair switching recently -- meaning that the whole team switches pairs at the same time, with the person who worked on a story the longest leaving, and people switching to pair partners they haven't worked with for the longest. This lead us to assign stories to machines, rather than people: Each machine has a story and two developers pair-programming on it. This limits WIP to the number of machines -- IE: half the number of developers. This is the minimum number of stories we can work on at a time (without splitting them into even smaller stories).

                              > 3) manage flow

                              It's not much to manage: Minimize work done before development work on a story starts. (IE: Enough, done relatively late, but not too much.) Work a story until it's complete. Done. Next story.

                              > 4) make process policies explicit

                              I think we've been pretty good at that. We can change the policies at any time for any reason. But we're always clear as to what they are. We never ignore them: If we to do something different, we say so, and why.

                              > 5) improve scientifically

                              Hmmm. Interesting. I like the idea, but haven't done it.

                              [I think I'll engage in some special pleading at this point...]
                              We don't do the same thing over and over; every task is different. So what few metrics we have are subjective and not very accurate. I've analyzed numbers from our projects; they're pretty noisy; hard to get a good signal out of them. So I think we have a practical need to make decisions based on inadequate and highly subjective data.

                              Having said that, I think we probably would benefit from being more rigorous -- making a habit of monitoring the longer term results of the practices we decide to keep.
                            • MarvinToll.com
                              Have not coached a PM for ten+ years... however, in support of the following assertion... used to tell PM s to use short iterations (no more than two weeks)
                              Message 14 of 23 , Jun 25, 2011
                              • 0 Attachment
                                Have not coached a PM for ten+ years... however, in support of the following assertion... used to tell PM's to use short iterations (no more than two weeks) and until they got good at it.

                                The notion was that it was (initially) more important to establish an effective (iterative) cadence than optimizing for the project.

                                So I'm also left wondering... if one jumps to Kanban... do you ever get the opportunity to 'feel' and value "cadence"?

                                Perhaps a 'team' does not need to learn... however, as a team member I trust a PM that understands "cadence leadership".

                                --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
                                >
                                > It seems to me dropping iterations for Kanban-style scheduling is a
                                > reasonable next step for an XP team whose progress has plateaued. I just do
                                > not see how a team could first get good enough at XP without the scaffolding
                                > of iterations.
                                >
                                > SteveG
                                >
                              • Adam Sroka
                                ... Yes, it does. The problem with XP, from a system transformation point of view, is that it doesn t provide a clear path to single piece flow from where most
                                Message 15 of 23 , Jun 25, 2011
                                • 0 Attachment
                                  On Fri, Jun 24, 2011 at 3:29 PM, JeffGrigg <jeffreytoddgrigg@...> wrote:
                                  >
                                  > XP, done well, approaches one-piece flow, from what I've seen. IE: Little work is done on a story until it's nearly ready to go into an iteration. When selected for work, it's worked end-to-end without stop until it is ready for deployment. It's deployed to production as soon as practical. So I'd think that Anderson's Kanban analysis, done well, should say "Well done!" and maybe highlight a few minor rough edges that the team might have already been thinking about addressing anyway.
                                  >

                                  Yes, it does. The problem with XP, from a system transformation point
                                  of view, is that it doesn't provide a clear path to single piece flow
                                  from where most organizations are today. However, if you put a Kanban
                                  system in place and start making incremental improvements you are
                                  naturally going to want to pull in techniques that you know work so
                                  that you can begin to eliminate bottlenecks and handoffs and other
                                  wastefulness.

                                  Since many of the techniques that work for me come from XP it is not
                                  unusual for me to see the system improving towards something that
                                  looks progressively more like XP. But, I never learned from XP how to
                                  guide myself and those I was coaching along that path in a way that is
                                  gentle and deliberate enough to show continuous progress. I am
                                  starting to learn that from Kanban now. What I *do* is still XP. The
                                  tool I reach for to get me there is almost always Kanban nowadays (For
                                  about the past two years.)

                                  > But what often seems to happen is that Certified Scrum Master coaches and team members insist that "Kanban is WIP Limits" -- so they insist on ***ADDING*** work queues to the process, so that they'll have something to "Manage with Kanban." Adding queues to a process that doesn't need them introduces waste. It's a bad thing. When team members are generalists, you don't need to put work into a queue. You just do the next step of the work.
                                  >

                                  My advice would be to stop listening to project managers who got their
                                  CSMs and started calling themselves coaches. There isn't much to learn
                                  there besides the fact that a little knowledge is dangerous and
                                  littler knowledge is dangerouser. ;-)
                                • Márton Mészáros
                                  Hi Gustavo, To address your original question: Sometimes estimating does make sense with Kanban too. Giving the product an insight on the impact of their
                                  Message 16 of 23 , Jun 28, 2011
                                  • 0 Attachment
                                    Hi Gustavo,

                                    To address your original question: Sometimes estimating does make sense with
                                    Kanban too. Giving the "product" an insight on the impact of their
                                    requirement can help them in prioritizing upcoming tasks. It's convenient to
                                    use t-shirt sizes or something with a low resolution (beer sizes for
                                    example). Having them requesting features that are relatively easy to
                                    develop speeds up the process, makes the every-day life more impulsive and
                                    fun. Having large stuff stuck in for weeks may lead to focus- and motivation
                                    loss.
                                    The important thing is - as in all agile implementations: collaborate. Not
                                    just with your fellow developers, but with the guys filling up the input
                                    queue.

                                    On 24 June 2011 12:41, Gustavo Cebrian Garcia <g.cebrian.garcia@...>wrote:

                                    > **
                                    >
                                    >
                                    > OK, that is what I understood.
                                    >
                                    > What I get is that kanban is a visual process everyone can see the flow and
                                    > applies the concepts you just said. I think, when people say Kanban vs
                                    > Scrum,
                                    >
                                    > they mean whether they want to do timeboxing or not...
                                    >
                                    > Yes, it helped a lot, thanks.
                                    >
                                    > ( I got confused becasue I heard from some people they estimate even when
                                    > they do kanban )
                                    >
                                    > On 24 June 2011 12:25, Torbjörn Gyllebring <torbjorn.gyllebring@...
                                    > >wrote:
                                    >
                                    >
                                    > > Hi Gustavo,
                                    > >
                                    > > the key point to remember is that "Kanban" isn't a process.
                                    > > You apply Kanban to something, sometimes that something is Scrum.
                                    > > My understanding is that most people that claim "we do Kanban instead of
                                    > > Scrum/XP/..." they really mean
                                    > > "we have a unnamed process, to improve and explain parts of it we use the
                                    > > Kanban label".
                                    > >
                                    > > Kanban tells you to start with what you have, visualize the workflow,
                                    > limit
                                    > > work in progress, manage flow and continuously improve.
                                    > > You can't start with Kanban, equally little is guidance on when/if/how to
                                    > > do
                                    > > estimation.
                                    > > That said, many teams that apply Kanban to their process find that the
                                    > need
                                    > > for estimation vanish because of the data and feedback provided by the
                                    > > visualization and reduced variation.
                                    > >
                                    > > Did that help?
                                    > >
                                    > > //tobbe
                                    > >
                                    > > On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
                                    > > g.cebrian.garcia@...> wrote:
                                    > >
                                    > > >
                                    > > >
                                    > > > Hello,
                                    > > >
                                    > > > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
                                    > > > principles ( on progress, etc )
                                    > > >
                                    > > > When people say that they are doing just kanban and not Scrum, how do
                                    > > they
                                    > > > estimate,
                                    > > >
                                    > > > Is there some kind of time-boxing with Kanban? There is no kind of
                                    > > > planning?
                                    > > >
                                    > > > Thanks.
                                    > > >
                                    > > > Gustavo.
                                    > > >
                                    > > > [Non-text portions of this message have been removed]
                                    > > >
                                    > > >
                                    > > >
                                    > >
                                    > >
                                    > > [Non-text portions of this message have been removed]
                                    > >
                                    > >
                                    > >
                                    > > ------------------------------------
                                    > >
                                    > > To Post a message, send it to: extremeprogramming@...
                                    > >
                                    > > To Unsubscribe, send a blank message to:
                                    > > extremeprogramming-unsubscribe@...
                                    > >
                                    > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                    > >
                                    > >
                                    > >
                                    > >
                                    >
                                    > [Non-text portions of this message have been removed]
                                    >
                                    >
                                    >

                                    Márton Mészáros
                                    *meza*
                                    ------------------------------
                                    skype: vsb-meza
                                    facebook: http://facebook.com/vsbmeza
                                    twitter: http://www.twitter.com/vsbmeza


                                    [Non-text portions of this message have been removed]
                                  • Chris
                                    To my mind, how hard something is shouldn t affect its priority. If the product owner says something is important but the developers estimate it will take a
                                    Message 17 of 23 , Jun 29, 2011
                                    • 0 Attachment
                                      To my mind, how hard something is shouldn't affect its priority. If the product owner says something is important but the developers estimate it will take a long time, then it's time to discuss splitting to get the most bang for the least buck as early as possible.

                                      --- In extremeprogramming@yahoogroups.com, Márton Mészáros <meza@...> wrote:
                                      >
                                      > Hi Gustavo,
                                      >
                                      > To address your original question: Sometimes estimating does make sense with
                                      > Kanban too. Giving the "product" an insight on the impact of their
                                      > requirement can help them in prioritizing upcoming tasks. It's convenient to
                                      > use t-shirt sizes or something with a low resolution (beer sizes for
                                      > example). Having them requesting features that are relatively easy to
                                      > develop speeds up the process, makes the every-day life more impulsive and
                                      > fun. Having large stuff stuck in for weeks may lead to focus- and motivation
                                      > loss.
                                      > The important thing is - as in all agile implementations: collaborate. Not
                                      > just with your fellow developers, but with the guys filling up the input
                                      > queue.
                                      >
                                      > On 24 June 2011 12:41, Gustavo Cebrian Garcia <g.cebrian.garcia@...>wrote:
                                      >
                                      > > **
                                      > >
                                      > >
                                      > > OK, that is what I understood.
                                      > >
                                      > > What I get is that kanban is a visual process everyone can see the flow and
                                      > > applies the concepts you just said. I think, when people say Kanban vs
                                      > > Scrum,
                                      > >
                                      > > they mean whether they want to do timeboxing or not...
                                      > >
                                      > > Yes, it helped a lot, thanks.
                                      > >
                                      > > ( I got confused becasue I heard from some people they estimate even when
                                      > > they do kanban )
                                      > >
                                      > > On 24 June 2011 12:25, Torbjörn Gyllebring <torbjorn.gyllebring@...
                                      > > >wrote:
                                      > >
                                      > >
                                      > > > Hi Gustavo,
                                      > > >
                                      > > > the key point to remember is that "Kanban" isn't a process.
                                      > > > You apply Kanban to something, sometimes that something is Scrum.
                                      > > > My understanding is that most people that claim "we do Kanban instead of
                                      > > > Scrum/XP/..." they really mean
                                      > > > "we have a unnamed process, to improve and explain parts of it we use the
                                      > > > Kanban label".
                                      > > >
                                      > > > Kanban tells you to start with what you have, visualize the workflow,
                                      > > limit
                                      > > > work in progress, manage flow and continuously improve.
                                      > > > You can't start with Kanban, equally little is guidance on when/if/how to
                                      > > > do
                                      > > > estimation.
                                      > > > That said, many teams that apply Kanban to their process find that the
                                      > > need
                                      > > > for estimation vanish because of the data and feedback provided by the
                                      > > > visualization and reduced variation.
                                      > > >
                                      > > > Did that help?
                                      > > >
                                      > > > //tobbe
                                      > > >
                                      > > > On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
                                      > > > g.cebrian.garcia@...> wrote:
                                      > > >
                                      > > > >
                                      > > > >
                                      > > > > Hello,
                                      > > > >
                                      > > > > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
                                      > > > > principles ( on progress, etc )
                                      > > > >
                                      > > > > When people say that they are doing just kanban and not Scrum, how do
                                      > > > they
                                      > > > > estimate,
                                      > > > >
                                      > > > > Is there some kind of time-boxing with Kanban? There is no kind of
                                      > > > > planning?
                                      > > > >
                                      > > > > Thanks.
                                      > > > >
                                      > > > > Gustavo.
                                      > > > >
                                      > > > > [Non-text portions of this message have been removed]
                                      > > > >
                                      > > > >
                                      > > > >
                                      > > >
                                      > > >
                                      > > > [Non-text portions of this message have been removed]
                                      > > >
                                      > > >
                                      > > >
                                      > > > ------------------------------------
                                      > > >
                                      > > > To Post a message, send it to: extremeprogramming@...
                                      > > >
                                      > > > To Unsubscribe, send a blank message to:
                                      > > > extremeprogramming-unsubscribe@...
                                      > > >
                                      > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                      > > >
                                      > > >
                                      > > >
                                      > > >
                                      > >
                                      > > [Non-text portions of this message have been removed]
                                      > >
                                      > >
                                      > >
                                      >
                                      > Márton Mészáros
                                      > *meza*
                                      > ------------------------------
                                      > skype: vsb-meza
                                      > facebook: http://facebook.com/vsbmeza
                                      > twitter: http://www.twitter.com/vsbmeza
                                      >
                                      >
                                      > [Non-text portions of this message have been removed]
                                      >
                                    • George Paci
                                      ... Cadence Leadership: I don t know but I ve been told... I DON T KNOW BUT I VE BEEN TOLD! ...this W.I.P. is way too old! THIS W.I.P. IS WAY TOO OLD!
                                      Message 18 of 23 , Jul 1, 2011
                                      • 0 Attachment
                                        On 6/25/11 9:16 PM, Marvin Toll wrote:
                                        > So I'm also left wondering... if one jumps to Kanban... do you ever
                                        > get the opportunity to 'feel' and value "cadence"?
                                        >
                                        > Perhaps a 'team' does not need to learn... however, as a team member I
                                        > trust a PM that understands "cadence leadership".
                                        >

                                        Cadence Leadership:

                                        "I don't know but I've been told..."

                                        "I DON'T KNOW BUT I'VE BEEN TOLD!"

                                        "...this W.I.P. is way too old!"

                                        "THIS W.I.P. IS WAY TOO OLD!"

                                        "Sound off!"

                                        "ONE, TWO..."


                                        --George

                                        Any technology that's ten years away is twenty years away.
                                      • Jeff Anderson
                                        Another way to look at estimating in Kanban is this. Teams starting out with Kanban will typically have a lot of variability in terms of work accepted by the
                                        Message 19 of 23 , Jul 2, 2011
                                        • 0 Attachment
                                          Another way to look at estimating in Kanban is this.

                                          Teams starting out with Kanban will typically have a lot of variability in terms of work accepted by the system of work/team/ project/ whatever.

                                          Ie big, small, web page, data change, brand new application, and any variation and combination .

                                          Teams overlaying Kanban on their existing methods will typically continue to estimate as they previously did.

                                          As team progress, work accepted will typically become categorized into better understood work types that have less variability. Ie team A might typically work on java enhancements, emergency defects, and canned reports.

                                          This is similar to mature agile teams, ranges of estimates are quite low, ie work is broken up into stories with points of 1-8 before work is started. Work has low variability in terms of effort.

                                          The big difference between Kanban and other methods is that Kanban states it's acceptable to not to estimate once you have low variability in work coming in the door. You dont need to care wether you have 1 or an 8, just make sure you broke up the work into stories that are between 1 and 8, call them all 4, and assume that the average will hold. If it doesn't over time, readjust the assumption to 5 or 3 or whatever your delivery metrics are telling you.

                                          In other words the most important part of estimating is breaking up the work into small pieces, once you've done that, the only reason to care about difference in the small range is to provoke discussion. That's why I do 1-8 range planning poker, not because I care about the result, but because I want the team to talk, and something about estimating promotes really good conversation.


                                          Jeff Anderson

                                          agileconsulting.blogspot.com
                                          http://twitter.com/thomasjeffrey


                                          On 2011-06-29, at 1:38 PM, "Chris" <c-riesbeck@...> wrote:

                                          > To my mind, how hard something is shouldn't affect its priority. If the product owner says something is important but the developers estimate it will take a long time, then it's time to discuss splitting to get the most bang for the least buck as early as possible.
                                          >
                                          > --- In extremeprogramming@yahoogroups.com, Márton Mészáros <meza@...> wrote:
                                          > >
                                          > > Hi Gustavo,
                                          > >
                                          > > To address your original question: Sometimes estimating does make sense with
                                          > > Kanban too. Giving the "product" an insight on the impact of their
                                          > > requirement can help them in prioritizing upcoming tasks. It's convenient to
                                          > > use t-shirt sizes or something with a low resolution (beer sizes for
                                          > > example). Having them requesting features that are relatively easy to
                                          > > develop speeds up the process, makes the every-day life more impulsive and
                                          > > fun. Having large stuff stuck in for weeks may lead to focus- and motivation
                                          > > loss.
                                          > > The important thing is - as in all agile implementations: collaborate. Not
                                          > > just with your fellow developers, but with the guys filling up the input
                                          > > queue.
                                          > >
                                          > > On 24 June 2011 12:41, Gustavo Cebrian Garcia <g.cebrian.garcia@...>wrote:
                                          > >
                                          > > > **
                                          > > >
                                          > > >
                                          > > > OK, that is what I understood.
                                          > > >
                                          > > > What I get is that kanban is a visual process everyone can see the flow and
                                          > > > applies the concepts you just said. I think, when people say Kanban vs
                                          > > > Scrum,
                                          > > >
                                          > > > they mean whether they want to do timeboxing or not...
                                          > > >
                                          > > > Yes, it helped a lot, thanks.
                                          > > >
                                          > > > ( I got confused becasue I heard from some people they estimate even when
                                          > > > they do kanban )
                                          > > >
                                          > > > On 24 June 2011 12:25, Torbjörn Gyllebring <torbjorn.gyllebring@...
                                          > > > >wrote:
                                          > > >
                                          > > >
                                          > > > > Hi Gustavo,
                                          > > > >
                                          > > > > the key point to remember is that "Kanban" isn't a process.
                                          > > > > You apply Kanban to something, sometimes that something is Scrum.
                                          > > > > My understanding is that most people that claim "we do Kanban instead of
                                          > > > > Scrum/XP/..." they really mean
                                          > > > > "we have a unnamed process, to improve and explain parts of it we use the
                                          > > > > Kanban label".
                                          > > > >
                                          > > > > Kanban tells you to start with what you have, visualize the workflow,
                                          > > > limit
                                          > > > > work in progress, manage flow and continuously improve.
                                          > > > > You can't start with Kanban, equally little is guidance on when/if/how to
                                          > > > > do
                                          > > > > estimation.
                                          > > > > That said, many teams that apply Kanban to their process find that the
                                          > > > need
                                          > > > > for estimation vanish because of the data and feedback provided by the
                                          > > > > visualization and reduced variation.
                                          > > > >
                                          > > > > Did that help?
                                          > > > >
                                          > > > > //tobbe
                                          > > > >
                                          > > > > On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
                                          > > > > g.cebrian.garcia@...> wrote:
                                          > > > >
                                          > > > > >
                                          > > > > >
                                          > > > > > Hello,
                                          > > > > >
                                          > > > > > I am a little bit confused with Kanban. I do Scrum, I practice Kanban
                                          > > > > > principles ( on progress, etc )
                                          > > > > >
                                          > > > > > When people say that they are doing just kanban and not Scrum, how do
                                          > > > > they
                                          > > > > > estimate,
                                          > > > > >
                                          > > > > > Is there some kind of time-boxing with Kanban? There is no kind of
                                          > > > > > planning?
                                          > > > > >
                                          > > > > > Thanks.
                                          > > > > >
                                          > > > > > Gustavo.
                                          > > > > >
                                          > > > > > [Non-text portions of this message have been removed]
                                          > > > > >
                                          > > > > >
                                          > > > > >
                                          > > > >
                                          > > > >
                                          > > > > [Non-text portions of this message have been removed]
                                          > > > >
                                          > > > >
                                          > > > >
                                          > > > > ------------------------------------
                                          > > > >
                                          > > > > To Post a message, send it to: extremeprogramming@...
                                          > > > >
                                          > > > > To Unsubscribe, send a blank message to:
                                          > > > > extremeprogramming-unsubscribe@...
                                          > > > >
                                          > > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                          > > > >
                                          > > > >
                                          > > > >
                                          > > > >
                                          > > >
                                          > > > [Non-text portions of this message have been removed]
                                          > > >
                                          > > >
                                          > > >
                                          > >
                                          > > Márton Mészáros
                                          > > *meza*
                                          > > ------------------------------
                                          > > skype: vsb-meza
                                          > > facebook: http://facebook.com/vsbmeza
                                          > > twitter: http://www.twitter.com/vsbmeza
                                          > >
                                          > >
                                          > > [Non-text portions of this message have been removed]
                                          > >
                                          >
                                          >


                                          [Non-text portions of this message have been removed]
                                        • Gustavo Cebrian Garcia
                                          Jen, 1-8 ( are you talking about days??? points ??? ... [Non-text portions of this message have been removed]
                                          Message 20 of 23 , Jul 3, 2011
                                          • 0 Attachment
                                            Jen, 1-8 ( are you talking about days??? points ???

                                            On 2 July 2011 18:45, Jeff Anderson <Thomasjeffreyandersontwin@...>wrote:

                                            > **
                                            >
                                            >
                                            > Another way to look at estimating in Kanban is this.
                                            >
                                            > Teams starting out with Kanban will typically have a lot of variability in
                                            > terms of work accepted by the system of work/team/ project/ whatever.
                                            >
                                            > Ie big, small, web page, data change, brand new application, and any
                                            > variation and combination .
                                            >
                                            > Teams overlaying Kanban on their existing methods will typically continue
                                            > to estimate as they previously did.
                                            >
                                            > As team progress, work accepted will typically become categorized into
                                            > better understood work types that have less variability. Ie team A might
                                            > typically work on java enhancements, emergency defects, and canned reports.
                                            >
                                            > This is similar to mature agile teams, ranges of estimates are quite low,
                                            > ie work is broken up into stories with points of 1-8 before work is started.
                                            > Work has low variability in terms of effort.
                                            >
                                            > The big difference between Kanban and other methods is that Kanban states
                                            > it's acceptable to not to estimate once you have low variability in work
                                            > coming in the door. You dont need to care wether you have 1 or an 8, just
                                            > make sure you broke up the work into stories that are between 1 and 8, call
                                            > them all 4, and assume that the average will hold. If it doesn't over time,
                                            > readjust the assumption to 5 or 3 or whatever your delivery metrics are
                                            > telling you.
                                            >
                                            > In other words the most important part of estimating is breaking up the
                                            > work into small pieces, once you've done that, the only reason to care about
                                            > difference in the small range is to provoke discussion. That's why I do 1-8
                                            > range planning poker, not because I care about the result, but because I
                                            > want the team to talk, and something about estimating promotes really good
                                            > conversation.
                                            >
                                            > Jeff Anderson
                                            >
                                            > agileconsulting.blogspot.com
                                            > http://twitter.com/thomasjeffrey
                                            >
                                            >
                                            > On 2011-06-29, at 1:38 PM, "Chris" <c-riesbeck@...> wrote:
                                            >
                                            > > To my mind, how hard something is shouldn't affect its priority. If the
                                            > product owner says something is important but the developers estimate it
                                            > will take a long time, then it's time to discuss splitting to get the most
                                            > bang for the least buck as early as possible.
                                            > >
                                            > > --- In extremeprogramming@yahoogroups.com, M��rton M��sz��ros <meza@...>
                                            > wrote:
                                            > > >
                                            > > > Hi Gustavo,
                                            > > >
                                            > > > To address your original question: Sometimes estimating does make sense
                                            > with
                                            > > > Kanban too. Giving the "product" an insight on the impact of their
                                            > > > requirement can help them in prioritizing upcoming tasks. It's
                                            > convenient to
                                            > > > use t-shirt sizes or something with a low resolution (beer sizes for
                                            > > > example). Having them requesting features that are relatively easy to
                                            > > > develop speeds up the process, makes the every-day life more impulsive
                                            > and
                                            > > > fun. Having large stuff stuck in for weeks may lead to focus- and
                                            > motivation
                                            > > > loss.
                                            > > > The important thing is - as in all agile implementations: collaborate.
                                            > Not
                                            > > > just with your fellow developers, but with the guys filling up the
                                            > input
                                            > > > queue.
                                            > > >
                                            > > > On 24 June 2011 12:41, Gustavo Cebrian Garcia <g.cebrian.garcia@
                                            > ...>wrote:
                                            > > >
                                            > > > > **
                                            > > > >
                                            > > > >
                                            > > > > OK, that is what I understood.
                                            > > > >
                                            > > > > What I get is that kanban is a visual process everyone can see the
                                            > flow and
                                            > > > > applies the concepts you just said. I think, when people say Kanban
                                            > vs
                                            > > > > Scrum,
                                            > > > >
                                            > > > > they mean whether they want to do timeboxing or not...
                                            > > > >
                                            > > > > Yes, it helped a lot, thanks.
                                            > > > >
                                            > > > > ( I got confused becasue I heard from some people they estimate even
                                            > when
                                            > > > > they do kanban )
                                            > > > >
                                            > > > > On 24 June 2011 12:25, Torbj��rn Gyllebring <torbjorn.gyllebring@...
                                            > > > > >wrote:
                                            > > > >
                                            > > > >
                                            > > > > > Hi Gustavo,
                                            > > > > >
                                            > > > > > the key point to remember is that "Kanban" isn't a process.
                                            > > > > > You apply Kanban to something, sometimes that something is Scrum.
                                            > > > > > My understanding is that most people that claim "we do Kanban
                                            > instead of
                                            > > > > > Scrum/XP/..." they really mean
                                            > > > > > "we have a unnamed process, to improve and explain parts of it we
                                            > use the
                                            > > > > > Kanban label".
                                            > > > > >
                                            > > > > > Kanban tells you to start with what you have, visualize the
                                            > workflow,
                                            > > > > limit
                                            > > > > > work in progress, manage flow and continuously improve.
                                            > > > > > You can't start with Kanban, equally little is guidance on
                                            > when/if/how to
                                            > > > > > do
                                            > > > > > estimation.
                                            > > > > > That said, many teams that apply Kanban to their process find that
                                            > the
                                            > > > > need
                                            > > > > > for estimation vanish because of the data and feedback provided by
                                            > the
                                            > > > > > visualization and reduced variation.
                                            > > > > >
                                            > > > > > Did that help?
                                            > > > > >
                                            > > > > > //tobbe
                                            > > > > >
                                            > > > > > On Fri, Jun 24, 2011 at 10:58 AM, Gustavo Cebrian Garcia <
                                            > > > > > g.cebrian.garcia@...> wrote:
                                            > > > > >
                                            > > > > > >
                                            > > > > > >
                                            > > > > > > Hello,
                                            > > > > > >
                                            > > > > > > I am a little bit confused with Kanban. I do Scrum, I practice
                                            > Kanban
                                            > > > > > > principles ( on progress, etc )
                                            > > > > > >
                                            > > > > > > When people say that they are doing just kanban and not Scrum,
                                            > how do
                                            > > > > > they
                                            > > > > > > estimate,
                                            > > > > > >
                                            > > > > > > Is there some kind of time-boxing with Kanban? There is no kind
                                            > of
                                            > > > > > > planning?
                                            > > > > > >
                                            > > > > > > Thanks.
                                            > > > > > >
                                            > > > > > > Gustavo.
                                            > > > > > >
                                            > > > > > > [Non-text portions of this message have been removed]
                                            > > > > > >
                                            > > > > > >
                                            > > > > > >
                                            > > > > >
                                            > > > > >
                                            > > > > > [Non-text portions of this message have been removed]
                                            > > > > >
                                            > > > > >
                                            > > > > >
                                            > > > > > ------------------------------------
                                            > > > > >
                                            > > > > > To Post a message, send it to: extremeprogramming@...
                                            > > > > >
                                            > > > > > To Unsubscribe, send a blank message to:
                                            > > > > > extremeprogramming-unsubscribe@...
                                            > > > > >
                                            > > > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                            > > > > >
                                            > > > > >
                                            > > > > >
                                            > > > > >
                                            > > > >
                                            > > > > [Non-text portions of this message have been removed]
                                            > > > >
                                            > > > >
                                            > > > >
                                            > > >
                                            > > > M��rton M��sz��ros
                                            > > > *meza*
                                            > > > ------------------------------
                                            > > > skype: vsb-meza
                                            > > > facebook: http://facebook.com/vsbmeza
                                            > > > twitter: http://www.twitter.com/vsbmeza
                                            > > >
                                            > > >
                                            > > > [Non-text portions of this message have been removed]
                                            > > >
                                            > >
                                            > >
                                            >
                                            > [Non-text portions of this message have been removed]
                                            >
                                            >
                                            >


                                            [Non-text portions of this message have been removed]
                                          • Steve Ropa
                                            Ahh.. the memories. From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] On Behalf Of George Paci Sent: Friday, July 01, 2011
                                            Message 21 of 23 , Jul 6, 2011
                                            • 0 Attachment
                                              Ahh.. the memories.



                                              From: extremeprogramming@yahoogroups.com
                                              [mailto:extremeprogramming@yahoogroups.com] On Behalf Of George Paci
                                              Sent: Friday, July 01, 2011 1:37 PM
                                              To: extremeprogramming@yahoogroups.com
                                              Subject: Re: [XP] Re: Kanban vs Scrum





                                              On 6/25/11 9:16 PM, Marvin Toll wrote:
                                              > So I'm also left wondering... if one jumps to Kanban... do you ever
                                              > get the opportunity to 'feel' and value "cadence"?
                                              >
                                              > Perhaps a 'team' does not need to learn... however, as a team member I
                                              > trust a PM that understands "cadence leadership".
                                              >

                                              Cadence Leadership:

                                              "I don't know but I've been told..."

                                              "I DON'T KNOW BUT I'VE BEEN TOLD!"

                                              "...this W.I.P. is way too old!"

                                              "THIS W.I.P. IS WAY TOO OLD!"

                                              "Sound off!"

                                              "ONE, TWO..."

                                              --George

                                              Any technology that's ten years away is twenty years away.





                                              [Non-text portions of this message have been removed]
                                            • phlipcpp
                                              ... Excuse my lacunae, but I feel the need to reveal that, for several years now, Kanban has ranked with Sudoku on my must avoid ever learning the first thing
                                              Message 22 of 23 , Aug 3, 2011
                                              • 0 Attachment
                                                > Another way to look at estimating in Kanban is this.

                                                Excuse my lacunae, but I feel the need to reveal that, for several years now, Kanban has ranked with Sudoku on my "must avoid ever learning the first thing about" list.

                                                Fight the good fight, y'all! I'm not knocking Kanban, because I CAN'T!
                                              • Steven Gordon
                                                ... And why should we care at all about what you think about things you do not want to even learn the first thing about? [Non-text portions of this message
                                                Message 23 of 23 , Aug 3, 2011
                                                • 0 Attachment
                                                  On Wed, Aug 3, 2011 at 11:06 AM, phlipcpp <phlip2005@...> wrote:

                                                  > **
                                                  >
                                                  >
                                                  > > Another way to look at estimating in Kanban is this.
                                                  >
                                                  > Excuse my lacunae, but I feel the need to reveal that, for several years
                                                  > now, Kanban has ranked with Sudoku on my "must avoid ever learning the first
                                                  > thing about" list.
                                                  >
                                                  > Fight the good fight, y'all! I'm not knocking Kanban, because I CAN'T!
                                                  >
                                                  >
                                                  And why should we care at all about what you think about things you do not
                                                  want to even learn the first thing about?


                                                  [Non-text portions of this message have been removed]
                                                Your message has been successfully submitted and would be delivered to recipients shortly.