Re: [scrumdevelopment] There is not, and never has been an "Agile Methodology" - Was "who the hell"
> > Great point, but I will submit that even with all the differentErrr, let's back up. How much experience have you had in trying to
> > 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?
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,Everything.
> 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. AreYes, yes I am.
> you saying that without the brands it would be even worse?
> I'm all for making clear what Agile is, and for pointing out when theAs far as I'm concerned, this is the definitive definition
> name is used for things that don't look like something I'd call Agile.
> I'm not sure that it needs brands to do that. In fact I think it couldGreat. Make as many as you want. All I care about is that someone
> be argued that the existence of different brands might very well induce
> - or at least legitimate - the creation of even more brands.
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
> 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