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

Re: [XP] Kanban vs Scrum

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.