Re: [scrumdevelopment] "Offending" Managers - Was There is not...
I was generalising but agree, point taken. Did not mean to offend any
Malcolm Anderson wrote:
> 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.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
> Yahoo! Groups Links
> Errr, actually, I was *working* at Microsoft at the time, the companySince my company got dragged into this discussion I think it is
> 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.
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.
VP of Business Development and Marketing
Net Objectives - www.netobjectives.com
Maximizing Product Development ROI