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

When wouldn't you do Agile?

Expand Messages
  • Nick Gassman
    The question cropped up today - are there any types of development that you wouldn t use Agile for? * Nick Gassman - Usability and Standards Manager -
    Message 1 of 67 , Aug 11, 2008
    • 0 Attachment
      The question cropped up today - are there any types of development
      that you wouldn't use Agile for?

      * Nick Gassman - Usability and Standards Manager - http://ba.com *
    • Robert Biddle
      Ok, but I think we mean the same thing. My main point was that going beyond a beginner state is not the same as never having reached the beginner state. Robt
      Message 67 of 67 , Aug 15, 2008
      • 0 Attachment
        Ok, but I think we mean the same thing.
        My main point was that going beyond a beginner state is
        not the same as never having reached the beginner state.
        Robt


        William Pietri wrote:
        >
        > Robert Biddle wrote:
        > > I have read about the concept (beginner's mind).
        > > It seems to me, though, that this is not at all having
        > > "no architecture in mind".
        > > In fact, it's more like having "all architectures in mind":
        > > does that seem reasonable to you?
        > >
        >
        > I would say it's the opposite. At the very least the experience is
        > described oppositely. One is supposed to empty one's mind, to be present
        > in the moment, not fill it with everything that might relate. For
        > example, there is this Zen parable:
        >
        > > A university professor went to visit a famous Zen master. While the
        > > master quietly served tea, the professor talked about Zen. The master
        > > poured the visitor's cup to the brim, and then kept pouring. The
        > > professor watched the overflowing cup until he could no longer
        > > restrain himself. "It's overfull! No more will go in!" the professor
        > > blurted. "You are like this cup," the master replied, "How can I show
        > > you Zen unless you first empty your cup.
        >
        > And I would add that even our best experts are unlikely to have all
        > architectures in mind. Software is a relatively young field, and it
        > would surprise me a lot if 100 years from now a lot of what we do isn't
        > looked at as primitive, even for the hardware we're using. But mistaking
        > "everything we know"for "everything interesting" is one of the traps
        > that beginner's mind tries to get past:
        >
        > "In the beginner's mind there are many possibilities, but in the
        > expert's there are few." - Shunryo Suzuki
        >
        > > I think we do not emphasise this enough in our discussions of agile
        > methods.
        > > If I'm wrong, could someone please point me at somewhere that addresses
        > > this well?
        > >
        >
        > I'd say we don't talk about it much, but that might still be enough.
        >
        > I don't think Agile methods need to tell you everything to do. I think
        > there function is simpler: to create a context where you realize what
        > you need to do. If you start to build a compiler, you may not know that
        > is hard at first. After a few stories, I'm betting you will struggle
        > some and say, "Gosh, maybe I should do a little Google search."
        >
        > I see agile developers behave that way all the time. When something gets
        > hard, they ask the team. When the team doesn't know, they dig further.
        >
        > Also, Agile methods tend to take the people as a given. If anybody asks,
        > we tell them they should have the best developers they can get, and
        > there should be at least one expert in the room. I've seen Ron and
        > others give that answer quite a bit. But I think it's hard to give
        > general advice about who you should have on your team. Instead, we give
        > them opportunities to learn early how well the team is suited to the task.
        >
        > William
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.