Notes:
Remember, this is the slide that's supposed to have a funny title.
These are my personal conclusions based on limited data. The research
on software methodologies is full of emotion and inconclusive evidence.
No one is going to be able to prove that one methodology is better than
another. There are simply too many variables, and you can't repeatedly
test the same team on the same project using different methodologies.
As I noted on the previous slide, I don't think anybody knows how to
solve a particular software problem unless they have solved it before.
That's not a case for any methodology.
One thing that most business people seem to understand is that we need
to listen to our customers. Programmers need to listen to their tests.
Marketeers need to listen to sales results. And so on. That's what this
picture represents: iterate over your listen-benchmark-adapt-measure
cycle as rapidly as possible. When you do, you'll evolve the right
solution, business, marketing campaign, etc.
This closed feedback loop is called many things. Programmers call it
compile-debug. Michael Bloomberg calls it, "listen, question, test, think".
My son's science fair handbook calls it, "hypothesize, procedure,
results, conclusion". (By the way, does anybody want to hire a 10 year-old?
Xcel Energy, are you listening?)
The Adapt in the picture is about adapt-or-die. You are constantly getting
feedback, and if you aren't listening to it, you'll fail to evolve and
change. Each iteration isn't likely to improve anything. Adapations are
educated or sometimes random guesses. Jim Collins, author of
Built to Last
and
Good toGreat
calls this, "Try a lot of stuff and keep what works".
If you aren't listening for feedback, however, there's no point in trying.
