I've given quite a few "elevator speeches" about Agile. After giving each speech, I've either failed to deliver my message, or my audience failed to understand.
Well, I'm giving up on them. If I can't be successful then I don't want to add to the confusing cacophony of messages about Agile.
Stop Advocating?
No, I am too passionate about software and software teams to give up advocating Agile. So here is my plan.
I'm going to explain the prizes. It's too hard to explain the tools, so I'll give them the good stuff up front.
Why? Because it's too complex (and important) of a topic to discuss in short time. So in paraphrase here is what I'll tell them:
When constructing software as a team, I don't care what methodology you're using as long as the team can achieve these goals:
1) Fail fast.
2) Continuously improve the team.
3) Continuously reduce and eliminate waste.
4) Indicate (visually or otherwise) the teams progress.
5) Embrace change.Agile happens to have some pretty practical tools that will get us there. If you'd like to join me for lunch, I'd be happy to tell you more!!
4 comments:
Solid reminder Steve, thanks! I might also add the need for the team to iterate and not get caught up in the big walls of architecture and major refractors.
The focus of any development, Agile or other, SHOULD be ono results and "prizes", and not slavish adherence to methodology.
Overemphasis on methodology leads to "cargo-cult" development.
http://en.wikipedia.org/wiki/Cargo_cult_programming
Glad to hear you are preaching the gospel! My agile elevator speech usually takes the form of a question: "Would you like to have greater efficiency, visibility, and control over your software development process?"
They always answer yes, but the tough part is convincing them that you know how to get them the above benefits. Helps to start small with stand ups or continuous integration and gain momentum before giving the elevator pitch.
My 2 cents.
Hi Steve!
There's a lot that I don't really understand about agile programming, I feel like My team hits those bulett points (and also the _joel test_) pretty well, but as far as agile methods go, I'm out of it.
Post a Comment