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

Re: [kanbandev] Re: An Agile Workflow

Expand Messages
  • Brian Marick
    ... [snip] ... That is not a productive thing to say. It s also not true, at least in my case. Arlo explains things to his target audience better than the
    Message 1 of 21 , Mar 1, 2009
    View Source
    • 0 Attachment
      On Feb 27, 2009, at 4:58 AM, David J Anderson wrote:

      >
      > Strangely we've seen folks on this list say that Naked Planning is OK
      > while Kanban isn't.
      [snip]
      > What this really implies is that the advocates of
      > Naked Planning really likes Extreme Programming and rejects other
      > development processes as somehow old, inappropriate, not agile or
      > otherwise.

      That is not a productive thing to say. It's also not true, at least in
      my case. Arlo explains things to his target audience better than the
      people on this list seem to. I'm trying to help you kanban advocates
      understand why that is. Here's another piece of the puzzle:

      I heard about Naked Planning from Arlo fairly early on, I think. He
      explained it to Ron Jeffries and me at the first Agile Open Northwest.
      As I recall, he couched his explanation in terms of a widely-
      understood problem: it is hard to get stories small enough to estimate
      well while still making them seem useful to a business representative
      ("have business value").

      Arlo presented Naked Planning as a complete end run around the
      problem. Estimation hard? Then don't do it! But without estimates,
      how can you tell how many and which stories to put in an iteration?
      Don't have an iteration! The business never really cared about
      iterations -- they just cared about working software visible fast.

      Arlo did not require us to understand the metaphysics of pulling vs.
      pushing, which I think Karl Scotland has convinced me (perhaps without
      intending) is irrelevant at this scale. I think Arlo did use the term
      Minimal Marketable Feature, which is fine by me. It's not a perfect
      term, but it's a whole lot better than "story".

      He delivered to us the highest-value idea at that moment. If he had
      other ideas or terminology, he was waiting for a later, more
      responsible moment to add them to the mix. Easy does it. Identifying
      with the audience and its problems does it.

      -----
      Brian Marick, independent consultant
      Mostly on agile methods with a testing slant
      www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
    • Bas Vodde
      Hi, ... I wouldn t agree here. As much as possible, you ll want to get rid of separate test teams. In most large-scale products, that will take a lot of time
      Message 2 of 21 , Mar 1, 2009
      View Source
      • 0 Attachment
        Hi,

        > I've also heard some folks object to the idea that independent testing
        > is a bad thing. That the use of professional testers is bad. Or that
        > having a test activity after coding is bad. While the more extreme
        > agile folks may believe that no test team is ideal, it simply isn't
        > practical in many large scale situations. Some industries require
        > independent verification for regulatory reasons. At scale some
        > software systems are built in sections by various teams working
        > independently often in various locations spread around the world. The
        > integration of these elements invokes a series of integration tests.
        > Testing after development and the use of independent testers is both
        > inevitable and desirable in many cases.
        >
        I wouldn't agree here. As much as possible, you'll want to get rid of
        separate test teams. In most large-scale products, that will take a
        lot of time though (as you mentioned). But this scale is completely
        outside the current Kanban scope anyways. AFAIK, there has not even
        been expermiments on this scale, if there have, let me know. If not,
        then I wouldn't consider this any argument for/against anything
        (except that separate test teams are not a very good idea).

        Regulatory independence can also be reached without a separate test
        team.
        > While the agile community likes to promote the notion of continuous
        > integration and automated regression testing this simply isn't viable
        > on very large scale activities. For example, the system testing of a
        > cell phone with the network while both the cell phone platform code
        > and the network platform code are in development simultaneously.
        >
        Coming from that environment, yes.. CI on that scale is desirable, but
        takes many many years of improvements in test and test environments.

        That said, phones and networks are rarely developed in sync (in same
        project) and normally the above CI situation will not happen ever.
        Even non-CI, it won't happen.

        It does describe a challenging environment, though giving this example
        is somewhat unrealistic in Kanban context. Again, I'd love to see
        experiments done on such a scale, but I hate "speculation" that "it
        will work better" without having any experience.

        Bas
      • David J Anderson
        Would that be as early as March 2005 when I suggested we stop estimating because we are lousy at it?
        Message 3 of 21 , Mar 1, 2009
        View Source
        • 0 Attachment
          Would that be as early as March 2005 when I suggested we stop
          estimating because we are lousy at it?

          http://www.agilemanagement.net/Articles/Weblog/StopEstimating.html

          and that blog post was inspired by the Microsoft XIT case study that
          was an on-going initiative at that time.

          Thanks for reminding us that we need to keep reiterating this stuff.

          David
          http://www.agilemanagement.net/

          --- In kanbandev@yahoogroups.com, Brian Marick <marick@...> wrote:
          >
          > I heard about Naked Planning from Arlo fairly early on, I think. He
          > explained it to Ron Jeffries and me at the first Agile Open Northwest.
          > As I recall, he couched his explanation in terms of a widely-
          > understood problem: it is hard to get stories small enough to estimate
          > well while still making them seem useful to a business representative
          > ("have business value").
          >
          > Arlo presented Naked Planning as a complete end run around the
          > problem. Estimation hard? Then don't do it! But without estimates,
          > how can you tell how many and which stories to put in an iteration?
          > Don't have an iteration! The business never really cared about
          > iterations -- they just cared about working software visible fast.
          >
        • Karl Scotland
          2009/3/1 Brian Marick ... Yep. Unintentional :-) While I don t think its irrelevant, I m coming round to the idea that for the audience
          Message 4 of 21 , Mar 2, 2009
          View Source
          • 0 Attachment
            2009/3/1 Brian Marick <marick@...>

            Arlo did not require us to understand the metaphysics of pulling vs.
            pushing, which I think Karl Scotland has convinced me (perhaps without
            intending) is irrelevant at this scale.

            Yep.  Unintentional  :-)

            While I don't think its irrelevant, I'm coming round to the idea that for the audience we are generally explaining kanban to on this list (i.e. experienced and knowledgeable agilistas), the distinction between pull and push is so subtle that we should focus elsewhere.

            Karl
             
            --
            Karl Scotland
            Agile Coach
            http://availagility.wordpress.com/
          • Xavier Quesada Allue
            On Fri, Feb 27, 2009 at 11:58 AM, David J Anderson ... While these japanese guys like to promote the notion of fast setup changes, this simply isn t viable on
            Message 5 of 21 , Mar 2, 2009
            View Source
            • 0 Attachment
              On Fri, Feb 27, 2009 at 11:58 AM, David J Anderson
              <netherby_uk@...> wrote:
              >
              > While the agile community likes to promote the notion of continuous
              > integration and automated regression testing this simply isn't viable
              > on very large scale activities. For example, the system testing of a
              > cell phone with the network while both the cell phone platform code
              > and the network platform code are in development simultaneously.
              >

              "While these japanese guys like to promote the notion of fast setup
              changes, this simply isn't viable on very large scale activities. For
              example, this die press here next to me uses 3-ton dies and takes five
              foremen a full day to configure..."

              (Some forgotten Detroit engineer, circa 1950)
            • chrisjmatts1968
              Brian Have you attended a session on Kanban? I suspect the big difference is that you have spoken to Arlo face to face about Naked Planning but your main
              Message 6 of 21 , Mar 2, 2009
              View Source
              • 0 Attachment
                Brian

                Have you attended a session on Kanban? I suspect the big difference
                is that you have spoken to Arlo face to face about Naked Planning but
                your main interaction with Kanban is through the yahoo group.

                I have seen David give his Kanban presentation a few times. As a
                result, people have walked out of the room and implemented Kanban in
                hours. Kanban is a visual process.

                You say "Arlo explains things to his target audience better than the
                people on this list seem to." I think it would be interesting to see
                Arlo explain his process on this list as well so that we can perform
                a fair comparison. I'm not talking about a well thought out article,
                but rather an e:mail to the group in his lunch time.

                As for the audience, this group is now a couple of years old with
                varying levels of knowledge about the subject, from testers to
                experts ;-) It is easy to explain things at the appropriate level
                when you are talking face to face and can observe the reaction. A tad
                harder when you talking to a couple hundred people of vastly
                different experience through e:mail.

                As for the meta physics of push and pull, according to the ever more
                popular dreyfuss model. First we tell people pull is important, and
                then they learn for themselves why.

                Many people use e:mail groups to learn how to articulate an idea in
                their own way. Your comparison to a face to face conversation with
                Arlo is, well, curious.

                Chris

                --- In kanbandev@yahoogroups.com, Brian Marick <marick@...> wrote:
                >
                >
                > On Feb 27, 2009, at 4:58 AM, David J Anderson wrote:
                >
                > >
                > > Strangely we've seen folks on this list say that Naked Planning
                is OK
                > > while Kanban isn't.
                > [snip]
                > > What this really implies is that the advocates of
                > > Naked Planning really likes Extreme Programming and rejects other
                > > development processes as somehow old, inappropriate, not agile or
                > > otherwise.
                >
                > That is not a productive thing to say. It's also not true, at least
                in
                > my case. Arlo explains things to his target audience better than
                the
                > people on this list seem to. I'm trying to help you kanban
                advocates
                > understand why that is. Here's another piece of the puzzle:
                >
                > I heard about Naked Planning from Arlo fairly early on, I think.
                He
                > explained it to Ron Jeffries and me at the first Agile Open
                Northwest.
                > As I recall, he couched his explanation in terms of a widely-
                > understood problem: it is hard to get stories small enough to
                estimate
                > well while still making them seem useful to a business
                representative
                > ("have business value").
                >
                > Arlo presented Naked Planning as a complete end run around the
                > problem. Estimation hard? Then don't do it! But without
                estimates,
                > how can you tell how many and which stories to put in an
                iteration?
                > Don't have an iteration! The business never really cared about
                > iterations -- they just cared about working software visible fast.
                >
                > Arlo did not require us to understand the metaphysics of pulling
                vs.
                > pushing, which I think Karl Scotland has convinced me (perhaps
                without
                > intending) is irrelevant at this scale. I think Arlo did use the
                term
                > Minimal Marketable Feature, which is fine by me. It's not a
                perfect
                > term, but it's a whole lot better than "story".
                >
                > He delivered to us the highest-value idea at that moment. If he
                had
                > other ideas or terminology, he was waiting for a later, more
                > responsible moment to add them to the mix. Easy does it.
                Identifying
                > with the audience and its problems does it.
                >
                > -----
                > Brian Marick, independent consultant
                > Mostly on agile methods with a testing slant
                > www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
                >
              • Matt Wynne
                ... I think flow is probably a more important concept to focus on - at my presentation at XP Day we talked about flow beats batch and that seemed to resonate
                Message 7 of 21 , Mar 2, 2009
                View Source
                • 0 Attachment
                  On 2 Mar 2009, at 10:04, Karl Scotland wrote:

                  > 2009/3/1 Brian Marick <marick@...>
                  >
                  > Arlo did not require us to understand the metaphysics of pulling vs.
                  > pushing, which I think Karl Scotland has convinced me (perhaps without
                  > intending) is irrelevant at this scale.
                  >
                  > Yep. Unintentional :-)
                  >
                  > While I don't think its irrelevant, I'm coming round to the idea
                  > that for the audience we are generally explaining kanban to on this
                  > list (i.e. experienced and knowledgeable agilistas), the distinction
                  > between pull and push is so subtle that we should focus elsewhere.

                  I think flow is probably a more important concept to focus on - at my
                  presentation at XP Day we talked about 'flow beats batch' and that
                  seemed to resonate with people - but I think pull is an important
                  concept to understand as well.

                  The way I see pull is the same way I see TDD - I don't write any code
                  until there's a failing test that 'pulls' the code out of me.
                  Similarly in a Kanban system I don't plan a story or feature until
                  there's an empty slot in the planning lane that 'pulls' the story into
                  planning. I think this is just common sense, but I have had my head
                  around it for a while...

                  Matt Wynne
                  http://blog.mattwynne.net
                  http://www.songkick.com
                Your message has been successfully submitted and would be delivered to recipients shortly.