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

Re: [XP] Re: Kanban vs Scrum

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 of 23 , Aug 3 11:06 AM
            • 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 6 of 23 , Aug 3 12:57 PM
              • 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.