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

Re: [scrumdevelopment] There is not, and never has been an "Agile Methodology" - Was "who the hell"

Expand Messages
  • Malcolm Anderson
    ... Errr, let s back up. How much experience have you had in trying to implement Agile practices into a waterfall environment. Also what is your background,
    Message 1 of 44 , Nov 2, 2006
      > > Great point, but I will submit that even with all the different
      > > breeds, everyone will still be able to agree, "Yep, that's a
      > > squirrel". Right now, people are pointing to an obviously soon to be
      > > road killed opossum, and saying "That's an example of a healthy
      > > squirrel"
      > Well, yes. So?

      Errr, let's back up. How much experience have you had in trying to
      implement Agile practices into a waterfall environment.
      Also what is your background, are you a developer, manager, or up in
      the CXO ranks?

      It all makes a difference.

      > And I don't understand at all how management buy in entered the stage,
      > why you get waterfall when you don't have it, and what that has to do
      > with the non-existence of an "Agile method".


      > Well, that's obviously already happening with the brands existing. Are
      > you saying that without the brands it would be even worse?

      Yes, yes I am.

      > I'm all for making clear what Agile is, and for pointing out when the
      > name is used for things that don't look like something I'd call Agile.

      As far as I'm concerned, this is the definitive definition

      > I'm not sure that it needs brands to do that. In fact I think it could
      > be argued that the existence of different brands might very well induce
      > - or at least legitimate - the creation of even more brands.

      Great. Make as many as you want. All I care about is that someone
      *pick one*.

      I say that by picking one, they are more likely to get infected by the
      culture, and that is what we are really talking about here a huge
      cultural shift.
    • bhartman_netobjectives
      ... Since my company got dragged into this discussion I think it is appropriate for me to respond. I m pretty sure that wasn t one of our books since no one
      Message 44 of 44 , Nov 9, 2006
        > Errr, actually, I was *working* at Microsoft at the time, the company
        > name on the course work was (I think) Net Objectives.
        > There was nothing wrong with the course work, it was a pretty solid
        > catalog of agile practices. The problem was that it was a bunch of
        > parts that needed assembly.
        > The complaint that I heard was, "We learned a lot, but we couldn't
        > figure out how to get started".
        > Scrum gives you a path
        > Lean gives you a path
        > XP gives you a path.

        Since my company got dragged into this discussion I think it is
        appropriate for me to respond. I'm pretty sure that wasn't one of our
        books since no one here can remember ever calling something an Agile
        Methodology, but it is certainly possible. We mostly do a lot of
        design patterns and test driven development courses at Microsoft, so
        our name is definitely on material there. This particular course book
        seems a little out of character unless it is pretty old.

        Just so no one is confused, let me clarify the way my company
        perceives agile and it's place in development. We at Net Objectives
        believe in maximizing product development ROI. We believe to do that
        requires more than just an agile process, it involves an entire
        organization. That doesn't mean that you can't get significant
        benefit by only addressing one piece of the whole, simply that you
        won't maximize the whole without addressing everything. We have what
        we call the 3 P's:

        1. Lean Principles - organization-wide principles based on lean
        development that help everyone understand how to maximize business value.
        2. Agile Processes - team centric processes that help the development
        piece of the organization be more effective (Scrum, XP)
        3. Best Development Practices - things each person on the development
        team can learn and practice to improve individual performance (TDD,
        design patterns, etc.)

        We believe that organizations properly executing the 3 P's will
        generate 2 additional P's - Great Products and Smarter People. I left
        off the P standing for Larger Profit, but when you maximize your ROI
        it seems obvious you would also increase profit.

        We also believe that while any of these things can be taught, it is
        often necessary to follow up teaching with actual "doing." The
        "doing" portion is best accomplished with an experienced coach/mentor
        that can smooth out the rough edges and make sure the theories are
        properly being put into practice. A good coach recognizes that not
        every organization is the same and some things that are good in theory
        need to be tweaked in a real world environment. The quoted message
        above makes this exact point - gaining the knowledge and not having a
        good way to put it into practice with someone helping can sometimes
        lead to futility. Remember, if you could just read a book and then do
        it perfectly, then everyone would! Let's be realistic, none of this
        is that easy to implement on your own even after you've read a book!
        It is much easier to do it when you are getting some help from people
        that have more experience.

        In the past 2 years we've trained many, many companies in these
        principles, processes and/or practices and we have an excellent track
        record. Because we take a bigger picture view of things, we are able
        to help companies pinpoint their worst pain and help them solve short
        term problems while keeping the long term perspective in mind.
        Everyone says there is no magic bullet, but then a lot of people try
        to use one anyway. Often they believe some sort of agile process will
        be the magic bullet. That is a failed approach that continues to get
        teams into trouble. It requires knowledge, dedication and effort to
        make these things work and that is true no matter which piece of the
        puzzle you look at. In order to most effectively implement change
        takes someone that has experience doing it so the people that are just
        learning it don't have to make the toughest decisions and solve the
        toughest problems. Someone can say "Been there, done that, I believe
        this thing should be done this way to be most effective." That saves
        time, energy and money in the long run.

        Bob Hartman
        VP of Business Development and Marketing
        Net Objectives - www.netobjectives.com
        Maximizing Product Development ROI
      Your message has been successfully submitted and would be delivered to recipients shortly.