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

Re: [scrumdevelopment] "Offending" Managers - Was There is not...

Expand Messages
  • Graeme Matthew
    Malcolm I was generalising but agree, point taken. Did not mean to offend any managers :-))
    Message 1 of 44 , Nov 3, 2006
    • 0 Attachment
      Malcolm

      I was generalising but agree, point taken. Did not mean to offend any
      managers :-))

      Malcolm Anderson wrote:
      > Graeme
      >
      > I will agree with you that our cultural tendency is to punish failure.
      > But you can't slam the managers too hard.
      >
      > First off, as Steve pointed out, it's not true of all managers, I
      > figure that it's true for much less than 50% of the managerial
      > population. It's just that we only remember the really good ones, and
      > the really bad ones.
      >
      > On 11/3/06, Graeme Matthew <scrum@...> wrote:
      >
      >
      >> Why are managers too busy trying to keep their jobs?
      >>
      >
      > Well, off the top of my head, here are a few understandable ones.
      >
      > Bad leadership above them, personal weakness, lack of courage, they're
      > over 50, they have a new house that they can barely afford, they have
      > a brand new baby, they just got married, they just got divorced, their
      > child has just been accepted to Harvard, they're on an H1 visa, their
      > daughter just got divorced and moved in with her 3 kids, their
      > girlfriend just got pregnant ...
      >
      > I could go on here.
      >
      > It comes down to feeling vulnerable, combined with not having great
      > prospects to jump to in case of being fired.
      >
      > Malcolm
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
    • 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
      • 0 Attachment
        > 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.