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

Re: [XP] Re: New Agile Vehicles

Expand Messages
  • Gary Brown
    ... From: Joshua Kerievsky To: Sent: Thursday, December 02, 2010 11:01 AM Subject: Re: [XP]
    Message 1 of 216 , Dec 2, 2010
      ----- Original Message -----
      From: "Joshua Kerievsky" <joshua@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Thursday, December 02, 2010 11:01 AM
      Subject: Re: [XP] Re: New Agile Vehicles

      > On Thu, Dec 2, 2010 at 5:05 AM, Gary Brown <glbrown@...> wrote:
      >> If I have more than one idea, and I work on the most important one first,
      >> isn't that a prioritized backlog? Even if it is just in my head?
      > We make priority decisions everyday. We don't build up long lists of
      > stuff
      > and try to prioritize them, as we found that to be wasteful.
      > "Given such engagement, I think even beginners can learn to evolve
      > software
      >> from a small group of critical stories, without building a backlog."
      >> Isn't a small group of critical stories a backlog?
      > To me, the real issue is not having much time between selecting work to do
      > and doing it.
      >> "We've jettisoned estimates, iterations, backlogs, release plans, index
      >> cards, planning boards, standups, product demos, formal retrospectives."
      >> That seems reasonable in your context. Do you think that would be a good
      >> starting point for a medium to large organization that is transitioning
      >> to
      >> Agile?
      > Such organizations struggle with how to produce small, important pieces of
      > quality work in a reasonably short amount of time. Does that time need to
      > be fixed? I don't think it matters so long as it is short - e.g. 2 - 5
      > days.
      > Learning to take large pieces of work and break them into small, important
      > pieces that add value is a critical skill - yet we don't need to teach
      > folks
      > story point estimating to teach that. In fact, I've found that the
      > estimation process confuses people and makes them uncomfortable. So what
      > good stuff can we do without it? Turns out, giving up iteration-level
      > estimates, even for beginners, isn't a show stopper. They do fine without
      > them and still get closer to the goal of producing small pieces of
      > valuable,
      > quality software.
      > Our goal is to be as useful to customers as possible. Removing process,
      > rather than adding to it or keeping it static, has helped with that goal.
      > It helps to not begin with a large process, since folks tend to have
      > trouble letting go of things they learned to do (un-learning, as Laurent
      > was
      > calling it). So what is the least amount of process we can begin with to
      > get the desired results? Perhaps some of the traditional agile rituals
      > and
      > practices aren't needed after all? One way to find out is by
      > experimenting
      > to distinguish what is indeed critical and what is unnecessary in your
      > context.

      Yeah, agree with all that. But of course there is a but ...

      Josh, you have earned your chops. You don't need to seek permission to kick
      Agile up a few notches. Do it and report your results. I can't speak for
      anyone else here, but I am always looking for a better way!

      Here is what I know from my context. Upper management wants to know what
      projects are going to cost and what the expected result is before they
      approve them. The only way to do that in my context, is to create some kind
      of high level backlog of ideas and ballpark an estimate. On the
      Customer/Product Owner side, that can take some effort. On the Developer
      side, not so much. I would prefer a different process, but our culture
      isn't there yet. I don't think we are unique on that front. 8^)

    • Steven Gordon
      On Mon, Jan 24, 2011 at 4:11 AM, D.André Dhondt ... Alternative interpretation: Domains that consider themselves scientific tend to require formal proof
      Message 216 of 216 , Jan 24, 2011
        On Mon, Jan 24, 2011 at 4:11 AM, D.André Dhondt
        <d.andre.dhondt@...> wrote:
        > On Mon, Jan 24, 2011 at 2:08 AM, Amir Kolsky <kolsky@...> wrote:
        >>   And again, one is reminded of Ignaz Philipp Semmelweis…
        > Meaning that people tend to reject new ideas just because they're new?
        > (Semmelweis suggested surgeons should wash hands with chlorine between
        > patients).

        Alternative interpretation:

        Domains that consider themselves scientific tend to require formal
        proof instead of empirical success before accepting new ideas.

        > --
        > D. André Dhondt
        > mobile: 215-805-0819
        > skype: d.andre.dhondt
        > twitter: adhondt   http://dhondtsayitsagile.blogspot.com/
        > Support low-cost conferences -- http://AgileTour.org/
        > If you're in the area, join Agile Philly http://www.AgilePhilly.com
        > [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
      Your message has been successfully submitted and would be delivered to recipients shortly.