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

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

Expand Messages
  • 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 1 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
    • 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.